この記事は、デライト・ベンチャーズ立花さんが企画した「AIVCリレー連載」（VC 9社が自社のAI活用を持ち回りで公開）の7本目です。企画ページはこちら、前回はHAKOBUNE栗島さんの記事です。
Coral Capitalは20人のチームで、エンジニア経験があるのは僕一人です。2025年5月のオフサイトをAIをテーマに開催して以来、組織全体でのAI活用をトップダウンで進めてきました。今では全員が相当程度AIを日々の業務に使っています。ただ、個人がAIを使いこなす段階と、組織としてAIの使い方を育てていく段階の間には、はっきりした壁がありました。
本稿では、その壁をどう越えたかを書きます。題材はClaudeの「スキル」です。Anthropicの説明を借りると、スキルとは「Claudeが動的に読み込んで特定のタスクのパフォーマンスを向上させるための命令、スクリプト、リソースのフォルダです」とされています。平たく言えば、Claudeに読ませる手順書のテキストファイルで、話しかけた内容に応じてClaudeが勝手に参照します。Coralでは、このスキルに「Coralのやり方」を書き込んでいます。
ただ、スキルという道具があるだけでは壁は越えられません。問題は、それを誰が書き、誰が直すかです。
答えは「全員で」です。
裏側ではGitHubが動いています。GitHubはソフトウェア開発者がソースコードの変更を共同で管理するためのサービスで、本来は非エンジニアにはとっつきにくいものです。そのため、メンバーがGitHubの画面を見るのは最初にアカウントを作るときだけで、日々の作業では一度も開かないように仕組みを整えました。
前半は仕組みの考え方を、後半はGitが分かる人向けの詳細と、初期に派手に詰まった話を書きます。スキルの置き場所の選び方だけ知りたい方は、最後の節に整理しました。
問題は「組織として改善サイクルが回らない」こと
2026年8月前半まで、Coralのスキルを追加できるのは僕だけでした。Claudeの管理画面にある「組織スキル」を僕が書き、全員に配る形です。実際、スキルは僕が作ったものしか増えませんでした。一方で、Operationsのメンバーは投資条件をHubSpotに入力する手順を自分用のスキルにして使いこなしていました。それをチームのスキルに入れる手段がなかったのです。
個人のAI活用は、放っておいても上手くなります。詰まるのはその先です。誰かが見つけた「うまいやり方」を全員のClaudeに入れ、使った人が気づいた点を書き戻し、それがまた全員に配られる。このサイクルが回らないと、各自のClaudeはその人が教えたことしか知らない状態にとどまります。20人いれば20通りのClaudeがいて、同じ業務を少しずつ違うやり方でこなし、誰かの改善は誰にも届きません。それは個人の「便利なアシスタント」ではあっても、「Coralのやり方を知っている同僚」ではありません。
人が知識を共同で育てる方式は、大きく3つあります。
| Wiki方式 | 管理者方式 | Git方式 | |
|---|---|---|---|
| 誰が書けるか | 全員が直接書き換える | 管理者だけ | 全員が変更案を出せる |
| 誰が確定するか | 書いた人（確定という概念がない） | 管理者 | 承認者だけ |
| 履歴と差分 | 残らない、または追いにくい | 管理者の手元にしかない | 誰がどこを変えたか全部残り、戻せる |
| 身近な例 | 全員が編集できる共有ドキュメント | 総務しか改訂できない社内規程 | オープンソースソフトウェアの開発 |
| 弱点 | 壊れても気づけない | 現場の気づきが管理者待ちで止まる | 道具が難しく、エンジニア以外に広がらない |
Coralでも、GitHubに移る前にいくつか試しました。スキルのMarkdownファイルをSlackやDriveで直接渡し合うのは、Wiki方式にすらなりません。コピーが増えて、どれが正本か分からなくなります。管理画面の組織スキルは管理者方式そのもので、上に書いたとおり僕待ちになりました。Google Driveに置けば履歴は残りますが、差分が見えず、レビューをする場所もありません。
つまり欲しいのはGit方式の統制で、要らないのはGitの操作です。GitHubを使うが、非エンジニアにはGitHubを見せない。 これがCoralの答えになりました。
仕組み: メンバーはClaudeに話すだけ、GitHubは裏側に
上の段がメンバーから見える流れ、下の段が裏側です。メンバーが触るのは左端の1つだけです。
メンバーから見た日々の動きは、こうです。Claudeに日本語で「さっきのやり方、良かったから今後もこうしてほしい。スキルに反映して」と話す。Claudeが変更内容を見せて確認を取り、本人名義で変更案を作る。同時にSlackの #ai-skills に、何が変わるか・きっかけ・変更案へのリンクが数行で届く。承認者がレビューし、必要なら直して取り込む。すると全員のClaudeに自動で配布される。通知には「提案中」「取り込み済み」の状態がemojiで付くので、今どこにあるかは一目で分かります。やることは最初の一文を話すことだけで、残りはClaudeと承認者の仕事です。
実際の通知は、たとえばこんな形です。
投稿者はOperationsのメンバーで、Claudeが本人名義で作っています。この例では、NDA交渉で蓄積した知見（条項ごとの先方の反応とCoralの対応）を次のレビューで再利用できるよう、過去事例のDBを参照する手順を足しています。「きっかけ」の欄に、なぜ直したかが一行で残るのがこの型の良いところです。左上の「提案」が状態を示すemojiで、取り込まれるとリアクションで「マージ済」が付きます。
もう1つ、同じOperationsの別のメンバーの例です。
こちらは全社共通のスキルへの提案で、資本政策表や株主名簿のファイル名に付ける日付を、最終更新日ではなく書類に書かれた日付を優先する、という変更です。ルールとしては小さな話です。ただ、この種のズレは気づいた本人がその場で直さないと二度と直らず、これまでは「気づいた人が澤山に言う」以外の経路がありませんでした。本人が気づいたその日に、本人の名前で全社のルールに入ったのがこの提案です。
この仕組みが成り立つ前提は、メンバー側の準備が2つだけで済むことです。1つはGitHubのアカウントを持つこと。これはGitを使うためではなく、「誰が提案したか」を本人の名前で記録し、誰がどこに提案できるかをGitHub側の権限で決めるためです。もう1つは、そのアカウントでClaudeにGitHubのコネクタ（ClaudeをGitHubにつなぐ設定）を接続すること。これでClaudeが本人の権限で動き、変更案は本人名義で作られます。
どちらも一度きりで、合わせて5分ほどです。以後、メンバーがGitHubの画面を開くことはなく、ブランチやプルリクエストといった言葉も知らなくて構いません。メンバーに残る接点は、Claudeに話すことと、Slackに通知が届くことの2つだけです。
裏側では、スキルを2層に分けて管理しています。1つは「守らせる層」で、ブランド規定、ファイルの命名規則、CRM利用時のガイドラインといった、必ず守るルールだけを置きます。書けるのは僕一人で、全員に必須で配布されます。もう1つは「みんなで育てる層」で、Investment、Operations、Ecosystem、Executive Officeといったチームごとの日々のノウハウです。こちらは全員が提案を出せます。分けている理由は単純で、全員が編集できる場所に「危ない操作を止める仕掛け」を置くと、その仕掛け自体を編集で外せてしまうからです。
7週間でスキルは26本から56本に、提案の2割弱がメンバーから
仕組みを全社に広げたのが2026年8月19日です。それから10月5日までの約7週間で、スキルは26本から56本に増えました。この間に出た変更提案は129本で、うち23本は僕以外のメンバーが出したものです。Operationsの2人が21本と大半を占めていますが、他のチームからも出始めています。
中身で一番大きいのは、個人のスキルがチームに引き上がる動きです。Operationsでは、自分の定型業務を順にスキル化していた人が、9月だけで10本以上をチームのスキル集に移しました。キャピタルコールの比率を提案する手順、LPの担当者変更、投資先のオンボーディングとオフボーディング、NDAレビュー、月次の請求書更新。Asanaのタスクやマニュアルに書かれていたものもありますが、常に最新だったかというと怪しく、実際の手順は担当者の頭の中にありました。
もう1つ良かったのは、実運用の失敗がそのままスキルに落ちることです。たとえば、投資先の株主総会の委任状をClaudeで作った際、Wordで届いた書類をClaude側でPDF化したらフォントがゴシック体に置き換わってしまった。その日のうちに「WordのみのものはWordでPDF化する」という1行がスキルに入りました。別の例では、月次でLPに報告する投資件数を機械的に数えたら32件、確定値は30件で、差の2件は追加投資とセカンダリでした。この「数え方」の定義もスキルに明記され、翌月から同じ数え方になります。個人的には、こういう地味な1行の積み重ねこそが「組織のやり方」なのだと思っています。
詳細: Gitが分かる人向け
ここから先は、同じことをやろうとする人向けの実装メモです。興味のない方は次の節まで飛ばしてください。
構成。 リポジトリは8本で、守らせる層が1本、育てる層が全社共通の1本とチーム別の6本です。各リポジトリはClaude Codeのプラグイン形式で、plugin.json のバージョンを上げないとキャッシュが差し替わりません（これを知らずに、coreが0.1.0のまま5回分の変更を取りこぼしました）。Claude Desktopとclaude.aiへはOrganization Pluginsとして登録し、自動配布しています。
権限。 組織のベース権限はreadで、writeはGitHub Teamの単位で付けています。Operationsのメンバーは自チームのリポジトリと全社共通のリポジトリに書ける、という具合です。GitHub Freeプランのprivateリポジトリではブランチ保護もCODEOWNERSも効かないため、「マージは承認者だけ」は技術的な強制ではなく運用ルールです。リポジトリをpublicにすれば無料でも保護が使えますが、スキルはCoralのノウハウそのものなので、publicにする選択肢はありません。
提案を作るスキル自体を守らせる層に置く。 PRの作り方を書いた skill-improvement というスキルがあり、ブランチ命名、PR本文の型、Slack通知のテンプレート、重複PRのチェック、descriptionの文字数チェック、バージョン更新までを担っています。これを全員が編集できる場所に置くと、「自分でマージしない」という統制のルールを編集で外せてしまうので、coreに置いています。
ハマりどころ。 スキルのdescriptionが1,024文字を超えると、プラグイン画面には出るのにセッションに読み込まれません。41本を監査したら3本が黙って死んでいました。通知先チャンネルを改名したら、スキルに旧名が書いてあったためClaudeが投稿先を見失いました。同じ内容のPRが2本並び、後から出した方を先にマージしたこともあります。どれも気づけばスキルに1行足して終わる話ですが、気づくまでが長いのが特徴です。
初期に詰まったのは、ClaudeとGitHubの接続
最後に、仕組みが回り出すまでに5日かかった話を残しておきます。8月18日の夜、Operationsのメンバーが最初の提案を出そうとして止まります。書き込み権限がなく、forkも無効化されていて、提案を作る手段がない。これは単純な招待漏れで、すぐ直りました。翌日、別のメンバーが同じことをしようとして、今度は「このセッションからはこのリポジトリにアクセスできない」というエラーで止まります。最初のメンバーも、権限が付いた後はコネクタを接続しても反映されず、アプリを再起動しても認識されず、最終的にClaude in ChromeでGitHubの画面を直接操作する手に出ました。
非エンジニアからは全部「ClaudeがGitHubにアクセスできない」という1つの症状に見えました。実際には原因が4層に分かれていました。
- GitHubの権限: チームへの招待漏れ、fork無効
- Claudeのコネクタ: 一覧に「GitHub連携」と「GitHub MCP」の2つが並び、前者は僕のDesktopでしか動かず、後者はAnthropic製のGitHub Appを組織にインストールしないと組織のリポジトリが全部404になる。認証は通るのにリポが見えない
- Claudeの面: Desktopのチャットでは動くのに、同じ依頼がCoworkでは通らない
- Slackの@Claude: 管理コンソールでリポジトリ単位の許可が別に要り、しかもマージ操作だけはできない
僕自身の切り分けも迷走しました。組織のOAuth制限を疑ってOAuthアプリまで作りましたが、コネクタに入れたClient IDとSecretはフローで完全に無視されていました。正体はGitHub Appの未インストールで、8月22日に入れた瞬間に開通しました（インストール時に「state: Field required」というエラー画面が出ますが、実は成功しています）。
ここから学んだのは、「隠蔽」は接続の層まで含めて設計しないと破れる、ということです。GitHubの操作を隠しても、GitHubへの接続で詰まればメンバーはGitHubの画面を自分で開きに行きます。切り分けの記録はリポジトリのdocsに残し、準備手順のページには「接続するのはGitHub MCPのほう」と赤字で書くことになりました。
限界と、次にやること
一方で、まだ解けていないことも書いておきます。
Claude Codeには自動で届かない。 Claude Codeは、ユーザーが追加したマーケットプレイスを起動時に自動更新しません。自動更新されるのは公式のものだけです。これに気づいたのは9月中旬で、僕自身の端末ですらプラグインが数か月分古いままで、1つは一度も入っていませんでした。設定で autoUpdate を有効にし、起動時にプラグインの鮮度を見て警告する仕掛けを足し、リポジトリのプロジェクト設定にも登録しましたが、Claude Codeを使うメンバーには別の配布経路が要る、というのが現状です。
配布そのものが怪しいときがある。 管理コンソール側でも、おそらく実行ファイルを含むなど一定の条件を満たす変更は管理者の承認が必要になるようで、画面上は「同期完了」と出るのに必須プラグインが誰にも届いていない期間がありました。しかも、その承認をするUIが見当たりません。Claudeの配布の挙動はまだ安定していないので、「配られたはず」を信じず、受け取り側で確かめる仕組みが要ります。
承認者が一人。 マージ権限は運用ルールで、承認者も現状は僕だけです。ここは早晩ボトルネックになるので、各チームのリーダーに権限を移していくつもりです。提案の品質が上がってきたことと、レビューの下読みをClaudeに任せられるようになったことで、移譲できる条件は整いつつあります。
おまけ: Claudeのスキルには置き場所が4つある
ちなみに、Claudeのスキルには置き場所が4種類あり、使い分けで迷っている方も多いと思うので整理しておきます。
- 個人スキル: 自分のClaudeだけに入る。管理画面から直接編集できる。試作と、本人専用のもの向け
- 共有スキル: 作った人が他のメンバーに共有する。配布は楽だが、更新するのは作った人だけ
- 組織スキル: 管理者が全員に配る。管理者方式そのもので、改善が管理者待ちになる
- GitHub経由のプラグイン: リポジトリをマーケットプレイスとして登録し、中のスキルを配る。履歴・差分・レビューが使える代わりに、GitHubの準備が要る
Coralでは、本人にしか意味のないスキル（自分のカレンダーのどれが本体か、複数あるメールアカウントのどれを使うか、といった自分の環境の読み方など）だけを個人スキルに残し、それ以外は全部GitHub経由にしています。管理画面側の組織スキル・共有スキルは使っていません。二重に持つと内容がズレるからです。逆に言えば、2〜3人のチームや、改善を一人が握って困らない規模なら、組織スキルで十分だと思います。GitHub経由が効いてくるのは、「直したい人が複数いる」と感じ始めてからです。
おわりに
8月19日に全社へ告知したとき、こう書きました。誰かが見つけた「うまいやり方」が個人の中に閉じず、スキルとして全員のClaudeに入る。使った人が気づいた点を書き戻すと、また全員に配られる。このサイクルが回り出すと、Claudeは「便利なアシスタント」から「Coralのやり方を知っている同僚」に変わる、と。言いたかったのは、AIの活用を個人技で終わらせない、ということです。7週間たって、サイクルは回り始めています。まだ承認者は一人で、Claude Codeへの配布も手がかかりますが、少なくともスキルを直す人は僕一人ではなくなりました。
VCは少人数の組織がほとんどで、エンジニアがいないファームの方が多いはずです。Git方式の統制はエンジニアの専売特許のように見えますが、操作をAIに任せてしまえば、統制の部分だけを非エンジニアの組織に持ち込めます。同じことを試そうとしている方がいれば、ぜひ情報交換させてください。
Written by
