Claude Code/Codexのコンテキストを社内で共有する方法｜GitHub×Google Driveの2層構成を実物公開

最初に、私のPCから64GBが消えた話をさせてください。今年の6月末、PCの空き容量がなぜか毎日減っていく。調べたら、犯人はAIエージェント用の作業フォルダでした。OneDriveの同期フォルダの中にGit（版管理の仕組み）の管理データを置いていたせいで、同期処理とGitの内部ファイルが干渉して、管理データが64GBまで膨れ上がっていたのです。半日かけて185MBまで掃除して、ほっとした翌日——また3.7GBに戻っていました。結局、リポジトリごとOneDriveの外に引っ越す恒久対策までやって、ようやく止まった。チームでAIのコンテキストを共有する仕組みは、私はこういう失敗を一個ずつ踏みながら作ってきました。

この記事のテーマは、Claude CodeやCodexに読ませるコンテキスト（会社のルール・情報・仕事の型）を、社内メンバーと一緒に構築して共有していく方法です。1人でAIを使えるようになった会社が次にぶつかる壁は、ほぼ例外なくここです。「Aさんが作った便利なルール、みんなのAIにも読ませたい」「メンバーごとにAIの賢さが違う」——この壁の越え方を、私が自社で実際に運用している構成（GitHub×Google Driveの2層）と、顧問先で敷いている段階的な導入まで、失敗談込みで公開します。

※本記事は2026年7月10日時点の運用に基づいています。ツールの画面や機能は変わることがありますが、本文の設計原則はツールが変わっても使えるように書いています。

執筆・監修 AiWiLL株式会社 代表取締役 赤堀亘

日本テレビ・Bitget等でのB2Bマーケティング実務を経て、2023年にSHIFT AI創業へ参画。コミュニティ・スクール責任者として2年で3万人規模へのグロースを主導。2026年、静岡県熱海市でAiWiLL株式会社を創業。生成AI顧問「WiLLAGENT」として、防災設備・不動産管理・旅館・飲食など現場型の中小企業に入り、売り上げ向上に寄与するマーケティングや営業施策をどうAIで質を上げ、数を増やすかを一緒に考え抜き、人手不足のなか報告書・見積・マニュアルづくりといった実務をいかにAIで省くかといった、AIを使った事業づくりを伴走支援している。生成AI研修・Eラーニングの監修も担当。企画したイベント・ウェビナーは累計112件、参加者は1万人超。

AIエージェント・新規事業リサーチ・マーケティングの実践セミナー3本の本編と、WiLLAGENTのサービス説明PDFを、無料の資料セットとして公開しています。→ 無料資料セットを受け取る

なぜ共有するのか：コンテキストは「会社の教科書」だから

Claude CodeもCodexも、起動したフォルダにあるルールファイル（Claude CodeならCLAUDE.md、CodexならAGENTS.md）と参照資料を読んでから働きます。このコンテキストの量と質が、そのままAIの仕事の質を決めます。同じモデルでも、会社の情報が濃いフォルダで働くAIと、空っぽのフォルダで働くAIでは、別人のような差が出る——ここまでは、1人で使っていても気づきます。

問題はチームに広げたときです。何もしないと、コンテキストが人に張り付きます。AさんのCLAUDE.mdには3ヶ月分の改善が蓄積されているのに、先週始めたBさんのAIは会社のことを何も知らない。同じ会社なのに、人によってAI社員の賢さがバラバラ。この状態を放置すると、「AIが使える人」と「使えない人」の差がそのまま固定されます。

だから共有します。目指す状態は一つで、「全員のAIが、同じ最新の”会社の教科書”を読んでから働く」こと。ちなみにClaude CodeとCodexを併用していても、教科書は1冊で足ります。私の運用ではAGENTS.mdを全AI共通の正系にして、CLAUDE.mdにはClaude Code固有の差分だけを書いています。ツールごとに教科書を二重管理し始めると、必ずどちらかが古くなります。

先に失敗パターンから：私が実際に踏んだ2つの地雷

地雷①：「コピーして配る」は必ず崩壊する

最初に誰もが思いつくのは、ルールファイルをチャットやメールでコピー配布する方法です。断言しますが、これは崩壊します。配った瞬間からコピーは古くなり始め、誰かが手元で直した内容は他の人に届かず、「どれが最新版？」の迷子が始まる。さらに複数人が同じファイルを直すと、後から保存した人が前の人の変更を消す上書き事故が起きます。ファイル名が「ルール_最新_v2_修正版.md」みたいになってきたら、それは崩壊のサインです。

地雷②：クラウド同期フォルダとGitを重ねる（＝冒頭の64GB事件）

版管理にGitを使うのは正解なのですが、その置き場所で私は冒頭の64GB事件を起こしました。気づいた瞬間のことは今でも覚えています。夜、PCの容量警告が出て、フォルダサイズを大きい順に並べたら、見覚えのある作業フォルダが一番上にいる。中を開くと、普段は意識すらしない「.git」という隠しフォルダが1つで64GB。作業ファイル本体は数百MBしかないのに、です。血の気が引くというより、しばらく意味が分かりませんでした。

原因を調べて分かったのが、この構造です。OneDriveやDropboxの同期フォルダの中にGitリポジトリを置くと、同期処理とGitの内部ファイルが干渉して、容量の異常肥大や履歴の破損を招くことがあります。私の場合は一晩で数GB単位の再発でした。共有はGit、ファイル同期はクラウド——役割を重ねない。AIエージェントのワークスペース自体も、クラウド同期の外に作る。これは教材にも太字で書いている、身銭を切った教訓です。

設計3原則：正系は1つ × 同期は自動 × 操作はAIに任せる

失敗を潰していった結果、残った原則は3つだけでした。

特に③が、この仕組みの発明ポイントです。Gitは「誰がいつ何を変えたか」を全部記録し、同時修正も安全に合流できる、現時点で唯一の実用解です。ただ、非エンジニアのチームにGitを覚えさせようとすると、そこで止まります。だから「人間はGitを覚えなくていい。版管理も、AI社員の仕事にする」。Gitの堅牢さだけを享受して、Gitの学習コストをゼロにする——この構成が成立するのが、AIエージェント時代の面白いところです。

導入は3段階：チームに合わせてレベルを選ぶ

仕組みには軽い順に3つのレベルがあります。いきなり完成形を目指す必要はありません。

選び方はシンプルです。「みんなで育てたい」ならLEVEL 1（現場の学びを吸い上げてルールを育てる）。「本部が配りたい」ならLEVEL 2を重ねる。迷ったらLEVEL 1。正直に添えると、LEVEL 2のプラグイン配布は私もまだ顧問先で本格導入していません（自社で検証中の段階です）。この記事で「実物」と言えるのはLEVEL 0・1と2層構成までで、LEVEL 2は選択肢の紹介に留めます。そして私が自社で実証して、実務の最終形だと考えているのが——幹部はLEVEL 1（双方向リポジトリ）×スタッフはLEVEL 0相当（読み取り専用ミラー配布）の2層併用です。次で全体像を見せます。

全体像：GitHub（幹部）× Google Drive（スタッフ）の2層構成

全スタッフにGitHubアカウントを配るのは、多くの会社で過剰です。AIを本格的に使い、ルールを育てる側に回る幹部・コアメンバーはリポジトリで双方向。閲覧して使えれば十分なスタッフには、クラウドドライブで読み取り専用のコピーを配る。これが2層構成です。

【正系】管理者PCの共有コンテキスト
   │
   ├─ git push ──────▶ GitHubリポジトリ（幹部）
   │                    └ 双方向・全部入り・AI任せで反映
   │
   └─ 自動ミラー ────▶ Google Drive「会社共有」（スタッフ）
                        └ 読み取り専用・機微情報を除外して配布

私の会社では2026年7月からこの形で運用しています。幹部側はGitHubの非公開リポジトリ（テキストのみ・クリーンな履歴）、スタッフ側はGoogle Driveの共有ドライブへの一方向ミラー。同じ正系から、立場に応じて2つの形で配る——これで「育てる人」と「使う人」の両方が回ります。

GitHub側のセットアップ：メンバーの作業は2つだけ

管理者がやることは、①非公開リポジトリを作る、②初期コンテンツを入れる、③メンバーを招待する、の3つ。リポジトリ作成もAIに頼めるので、実作業は30分もかかりません。初期コンテンツの構成は、私はこの形を標準にしています。

team-context/            ← 共有リポジトリ（会社の教科書）
├ CLAUDE.md / AGENTS.md  ← チーム共通ルール（品質基準・確認手順・禁止事項）
├ 会社概要.md            ← 事業説明・サービス一覧・トーン&マナー
├ 用語集.md              ← 社内用語・顧客業界の用語
├ 業務の型/              ← よく使う定型手順・スキル
├ 置き場所の地図.md      ← 主要資料がどこにあるかのパス案内
└ CHANGELOG.md           ← 変更履歴（いつ・誰が・何を・なぜ）

ポイントは「置き場所の地図」です。資料そのものを全部リポジトリに入れるのではなく、大きなファイルや動画は地図（パスの案内）だけを置く。教科書は薄く保つほうが、AIの読み込みも人間のメンテも軽くなります。

「管理者は誰がやるべきか」もよく聞かれます。役職で選ばないでください。私の顧問先で定着が速いのは、社内でいちばんAIを面白がっている人が管理者をやるパターンです。仕組みの立ち上げ期は「ルールを1行直したら全員に届いた」という小さな成功体験を積む人が要で、それは肩書きよりも熱量のある人が向いています。経営者の仕事は、管理者をやることではなく、その人に時間と権限を渡すことです。

一方、メンバーがやることは「GitHubアカウントを作る」と「初回にAIへセットアップを頼む」の2つだけです。実際のAIへの頼み方も、教材からそのまま載せます。

▲ メンバー初回セットアップのAIとのやり取り（再現イメージ）。人間はGitコマンドを1つも打っていません

裏側で効いているのが、起動時の自動更新です。AIエージェントの起動フックに「開始時にチーム共有フォルダを最新化する」設定を1行入れておくと、毎回の起動時に手元が自動で最新になります。設定の実物はこれだけです（これもAIに「設定して」と頼めば済みます）。

{ "type": "command", "command": "git -C ~/team-context pull --rebase --autostash" }

日々の運用も同じ調子です。ルールを変えたくなったら、AIに一言。

▲ ルール更新のやり取り（再現イメージ）。ここでも人間はGitコマンドを打っていません

翌日から全員のAIがそのルールを読んで働きます。共有の仕組みは日常の中で完全に透明になり、意識すら必要なくなる——ここまで来ると、チームのコンテキストは勝手に育ち始めます。回り始めたサインも分かりやすくて、CHANGELOG（変更履歴）に自分以外の名前が並び始めたら成功です。私は週に一度、この履歴を眺めるのを楽しみにしています。自分が知らないうちに会社の教科書が1ページ増えている——この感覚は、正直、癖になります。

Google Drive側のセットアップ：一方向ミラー＋除外リスト

スタッフ配布側は、正系フォルダからGoogle Driveへの一方向・全上書きコピー（ミラー）で作ります。「コピー配布は崩壊する」と言ったばかりですが、崩壊するのは人が・手で・双方向にコピーするからです。機械が・一方向に・全上書きするミラーは「正系の写像」なので、最新版迷子も上書き事故も起きません。Windowsならrobocopyで、機微情報を除外しながらこう書けます。

robocopy "共有コンテキスト" "G:\マイドライブ\会社共有" /MIR /XJ ^
  /XD "経営戦略" "顧客別" "契約書" "商談メモ" "人事" ^
  /XF ".env" "*.pem" "*商談メモ*"

実運用で効いてくる注意点を4つ。これも全部、自分で運用して気づいたものです。

• 除外は「名前」で判定される — 機微情報のフォルダ名は「顧客別」「契約書」「商談メモ」のような命名規則に揃える。規則に沿わない名前で作った機微フォルダは、配布に混ざります。
• 除外を後から足しても、配布済みは消えない — 除外の追加は、配布先からの手動削除までワンセット。
• 共有リンク（URL）ではAIは読めない — Web版ドライブはログイン必須のWebアプリなので、AIエージェントは中身を読めません。スタッフ側のPCにはドライブのデスクトップアプリを入れ、ローカルのフォルダとして見える状態にして初めてAIが参照できます。
• 個人ドライブではなく会社の共有ドライブに置く — 所有者が会社になり、閲覧者権限で「読み取り専用」を仕組みとして担保できます。ルートには「はじめに」の1枚ガイドを置き、禁止事項（コピー持ち出し・直接書き込み・社外への再共有）を明記しておきます。

共有の線引き：共有した瞬間、閲覧範囲が広がる

仕組みができたら、最後は「何を入れて、何を入れないか」です。大前提として、共有した瞬間に、閲覧範囲が個人からチームへ広がります。入れるのは「全員のAIが読んでいてほしい、会社の教科書」——共通ルール・会社概要・用語集・業務の型・資料の置き場所の地図。入れないのは、顧客の機密・個人情報・人事評価、そしてAPIキーや認証情報は「一度も」入れない（非公開リポジトリでも履歴に全部残ります。誤って入れたら削除ではなくキーの無効化・再発行です）。

「非公開リポジトリだから大丈夫」という感覚も、一度疑ってください。非公開はあくまで社外に対しての話で、社内では招待したメンバー全員が全履歴を見られます。人事評価や給与のように社内でも閲覧範囲を限定すべき情報は、そもそも全員の教科書に載せる情報ではありません。

迷ったら「これは①チーム共有層・②プロジェクト層・③個人層のどの情報か？」と一度問う。この線引きの詳細と、AIに入力してよい情報の3段階の考え方は、AI導入のセキュリティと情報入力の考え方の記事に教材ごと公開しているので、あわせて読んでください。

現場ではいきなり完成形にしない：顧問先での段階的な進め方

ここまで読んで「うちにはハードルが高い」と感じた方も多いはずです。実際の現場では、私はいきなりこの完成形を作りません。顧問先の防災点検会社・WECSでは、幹部向けのAI導入講座で、まず各幹部のPCのローカルに同じ形のワークスペースを1部ずつ配置するところから始めました。会社共通の情報を更新したら、当面は手動の上書きコピーで揃える。共有リポジトリ方式は、運用が回り始めてから次の段階として検討する——そう決めて進めています。

これは手抜きではなく、順番の設計です。共有の仕組みは、共有したくなる中身が育ってから入れるほうが定着します。最初の1〜2ヶ月は「会社の教科書」の中身づくり（経営方針・業務水準・用語の棚卸し）に集中し、ファイルが育って「これを全員に配りたい」という欲求が生まれた瞬間が、仕組み導入のベストタイミングです。私自身、自社の2層構成にたどり着くまでに、コピー配布→クラウド直置き→64GB事件→現在の形、と4段階を踏んでいます。最初から正解に行けた訳ではありません。

よくある質問（導入支援で実際に聞かれる順）

Q1. Gitを知らないメンバーばかりですが、本当に運用できますか？

できます。この仕組みは「人間がGitを覚えない」前提で設計されています。メンバーの作業はGitHubアカウントの作成と、初回にAIへセットアップを頼むことの2つだけ。以後の更新・反映・競合解消はすべてAIが実行します。私の顧問先でも、Gitという単語を知らないメンバーが普通に使っています。

Q2. 誰でもルールを変えられると、勝手な変更が心配です

全変更が履歴に残ります——誰が・いつ・何を・なぜ。勝手な変更は必ず見つかり、ワンクリックで元に戻せます。それでも心配なら、承認制（変更提案を管理者がレビューしてから反映する運用）へ後から引き上げられます。最初は性善説＋履歴で始めるのが、私のおすすめです。

Q3. GitHubは有料ですか？

非公開リポジトリを含め、この用途なら無料枠で始められます（2026年7月時点）。コストよりも「アカウントを作る」という心理的ハードルのほうが実際の障壁で、だからこそスタッフ側はアカウント不要のドライブ配布にする2層構成が効きます。

Q4. Google Drive（またはOneDrive）の共有フォルダだけではだめですか？

全員が直接参照するLEVEL 0なら、小規模・低頻度更新の入口として成立します。だめなのは「コピーして配って、直したら戻す」運用（崩壊します）と、Gitリポジトリをクラウド同期フォルダの中に置くこと（私の64GB事件です）。この2つを避ければ、ドライブ起点で始めて、育ってきたらLEVEL 1へ引っ越すのは良い進め方です。

Q5. Claude CodeとCodexを併用しています。教科書は別々に作るのですか？

1つで足ります。私の運用は「AGENTS.md＝全AI共通の正系、CLAUDE.md＝Claude Code固有の差分だけ」。同じ共有リポジトリを両方のAIが読むので、ツールを乗り換えてもコンテキスト資産はそのまま残ります。コンテキストはツールではなく会社に帰属させる——これが二重管理を防ぐ唯一の考え方です。

Q6. 2人が同時に同じルールを直したら、どうなりますか？

Gitの合流機能が働くので、別々の箇所の修正なら自動で両方活きます。同じ行を同時に直した場合だけ「衝突」となりますが、その解消もAIに「競合を解消して」と頼めば、両方の意図を確認しながら合流してくれます。手動コピー運用なら確実に片方が消えていた場面が、「両方残って合流される」に変わる——これがGitを土台にする最大の理由です。

Q7. 何人くらいから、この仕組みが必要になりますか？

AIを本格的に使う人が2人になった瞬間からです。1人ならフォルダが正系ですが、2人目が現れた時点で「どっちのルールが最新か」問題は始まります。逆に、まだ1人しか使っていないなら、仕組みより先に教科書の中身（棚卸しとフォルダ設計）を育ててください。

持ち帰り用：チーム共有の導入チェックリスト

1. 共有したいコンテキスト（ルール・会社情報・業務の型）が、すでに1人分は育っている
2. 正系の置き場所を1箇所に決めた（迷ったらGitHub非公開リポジトリ）
3. ワークスペースとGitリポジトリをクラウド同期フォルダの外に置いた
4. CLAUDE.md／AGENTS.mdの役割分担を決めた（正系1つ＋ツール差分）
5. APIキー・認証情報・顧客機密・人事情報が共有物に含まれていないことを確認した
6. メンバーの初回セットアップ手順（AIへの頼み方の例文）を配った
7. 更新はAI経由で行い、変更履歴を残す運用にした
8. スタッフ配布が必要なら、一方向ミラー＋除外リスト＋命名規則を設定した
9. スタッフ側PCにドライブのデスクトップアプリを入れた（リンクでは読めない）
10. 配布先ルートに「はじめに」ガイド（禁止事項3つ）を置いた

まとめ：コンテキストを「人の資産」から「会社の資産」へ

チームでのコンテキスト共有は、突き詰めると「正系は1つ・同期は自動・操作はAIに任せる」の3原則に尽きます。形は3レベルから選べて、迷ったらGitHub非公開リポジトリの双方向共有（LEVEL 1）、スタッフが多いならGoogle Driveミラーを重ねた2層構成。そして仕組みより先に、教科書の中身を育てること。

私はこの形にたどり着くまでに、コピー配布の崩壊も、64GBの肥大化事件も、一通り自分で踏みました。だから断言できるのは、この仕組みの価値は「効率化」ではないということです。1人の学びが、翌日には全員のAIの学びになる——個人に張り付いていたノウハウが、会社の資産に変わる。AI活用で本当に差がつくのは、モデルの選び方ではなく、この蓄積の仕組みを持っているかどうかだと、私は考えています。

自社の教科書づくり（棚卸しとフォルダ設計）から一緒に進めたい方向けに、無料の資料セットを用意しています。全体像はこちらからどうぞ。