複数人・複数PCで
「第二の脳」を運用するコツ

CHAPTER 1

まず全体像 — 保険から「共有の脳」へ

一人で第二の脳を使うと、GitHubの役割は保険です（PCが壊れたら戻す）。これを会社・チームで使うと、同じ仕組みのまま「みんなの共有の脳（ハブ）」に格上げできます。GitHubはもともと大勢で1つの物を共有するための道具なので、作り直しはいりません。

FIG. 中央に共有リポ、各PCがpull/pushでつながる

CHAPTER 2

コツ① 知識は共有・鍵は共有しない（最重要）

共有の脳に鍵やログイン情報を絶対に入れないこと。1回の不用意な操作で全員に鍵が漏れるからです。一人運用よりも、会社運用のほうがこの事故は致命的になります。

• 全員が自分のPCで自分のClaude Codeにログインする（認証は一人ずつ・共有しない）。
• .gitignore に .env *.key *.pem .credentials* *credentials*.json settings*.json を入れて自動で除外。
• ~/.claude 直下そのものをリポにしない（settings.jsonや.credentials.jsonが同居する“秘密の温床”。丸ごと上げると流出する）。リポにするのは memory\ と skills\ の中だけ。
• git add . は使わない（秘密を巻き込む）。ファイルは個別指定。

CHAPTER 3

コツ② 「脳の管理人」を1人置く

複数人が同じファイルを同時に編集して両方pushすると、gitが「どっちが正解？」と衝突（コンフリクト）を出します。エンジニアには日常でも、非エンジニアには怖い。そこで役割を分けます。

• CLAUDE.md（会社ルール）・memory（共有ナレッジ）を整える主担当を1人置く＝脳の管理人。
• 他のメンバーは基本 pull（読む・使う）中心。追加したいことは管理人に渡す／管理人が反映する。
• これで「みんなが好き勝手に本線を書き換える」混乱を防げます。

CHAPTER 4

コツ③ 自動pushはハブ1台／他はpull

2時間ごとの自動バックアップ（OSタスクスケジューラ）を全員のPCで回すと衝突の温床になります。

• 自動push＝ハブ役の1台（管理人PC）だけにする。
• 他のメンバーのPCは「使う前に git pull」の運用（最新の共有脳を取り込んでから作業）。

なお、各自の“個人脳リポ”の置き先は1つ＝本人の個人アカウントのPrivateリポ（全員・雇用形態を問わず）。理由：memoryはその人の全活動を写す手帳（一本化すると他社案件・私用の文脈も同じノートに溜まる）なので、会社のOrganizationに置くと ①複業・業務委託メンバーの他社案件の情報がうちの箱に自動流入する（逆方向も然り） ②オーナーが全員の手帳を読める＝「④個人の脳は自由」と矛盾 ③退職時に“本人の手帳が会社に残る”後始末が発生。会社に残すべき知識はこれで欠けません——会社の資産は「共有脳＋各プロジェクトのリポ」で担保する設計で、⑤知見の納品は義務のまま。一般企業のルール「会社のデータは会社の箱にしか置かせない」は業務プロジェクトと共有脳に適用します（こちらはOrganization一択・例外なし）。仕事手帳やペンケースまで会社の金庫に入れる会社がないのと同じ線引きです。

会社運用の全体図 — 教科書と成果は会社の箱・手帳は各自の箱

社員のmemory/skillsを全員共通の1つに混ぜてはいけません（①同じ箱への複数自動push＝衝突する ②memoryは“その人の仕事の文脈”を覚える個人の手帳＝混ぜると記憶が混線する）。そして混ぜないだけでなく、手帳の箱そのものを会社のOrganizationの外＝本人の個人アカウントに置きます。

FIG. 会社運用の完成形 — 手帳（記憶・道具）は自分の箱、教科書と成果は会社の箱

社員同士でナレッジを使いたいとき（回し方）

社員Aが社員Bの知見を使いたい場合、Bの脳を直接覗くのではなく、共有脳を経由します。

直接覗かせない理由は権限だけではありません。個人のmemoryは“その人の作業文脈の手帳”で、他人が読む前提で書かれていない（「例の件は△△で対応」は本人にしか分からない）。他人に使わせる知識は、共有用に整えて共有脳へ。どうしても必要なら、オーナーは権限で「特定のプロジェクトリポを特定の人に見せる」こともできますが、基本は共有脳経由が正解です（なお脳リポは各自の個人アカウントにあるため、オーナーにも見えません）。

FIG. 全員が守る1本のリズム

CHAPTER 5

「管理人が退職したら？」— 本当の急所はリポの持ち主

「ハブPCの人が辞めたら脳が消えるのでは」と心配になりますが、向きが逆です。ハブPCは“データの本体”ではありません。

• 本体はGitHub上のリポ。ハブPCは「2時間ごとに送るボタンを押す係」にすぎない。
• メンバー全員のPCにもclone（写し）が残っている＝全員が分散バックアップ。
• だから管理人の退職・PC故障は怖くない：新しい管理人のPCで clone → スケジューラ登録（数分）で交代完了。失うのは最大でも直近数時間分。管理人が社長である必要もありません（誰でも交代できる軽い“係”）。

招待のやり方は2通り——A. 個人アカウントのまま Collaborator 招待（今すぐ・ただし読み取り専用にできないので「メンバーはpushしない」はルールで守る）／B. 無料の Organization を作って移す（Readロールでpull専用を仕組みで強制できる）。推奨はまずA → 必要になったらB。クリック手順は教材「はじめてのGitHub設定（補足D：複数人で使う）」にまとめてあります。

CHAPTER 6

衝突が出たら — 慌てない・予防が9割

• 出ても壊れません。gitが「ここが食い違っている」と教えてくれるだけ。
• 非エンジニアの対処：Claude Codeに「コンフリクトを解消して」と頼むか、管理人に渡す。

CHAPTER 7

段階的に始める（pull専用から）

いきなり「全員が本線に自由にpush」は非エンジニアには難しい。pull専用から始めて、少しずつ書き手を増やすのが安全です。

1. まず管理人1人が今の第二の脳をそのまま運用（一人PCと同じ）。
2. 他メンバーは git clone して pull 専用（読む・使うだけ）。ここまでで「全員が同じ会社ルールでAIを使える」が実現し、衝突ゼロ。
3. 慣れてきたら担当を分けて一部メンバーもpush（1ファイル1トピックで衝突を避ける）。

CHAPTER 8

新しいメンバーの迎え方 — 強制と自由の線引き

メンバー（特に、既に自分のやり方を持つエンジニア）に第二の脳を“押し付ける”と嫌がられます。原則は「アウトプット（知見の納品）は義務・ツール（個人の脳の作り方）は自由」。

知見の残し方（非エンジニアもできる・最後は管理人が承認）

個人のmemory/skillsを“そのまま”共有脳にアップはしません（個人の手帳は本人にしか読めない書き方だから）。共有用に整えた1枚のMarkdownにしてから入れます。整えるときの注意が1つ：共有脳に入れる知見は“それだけ読めば分かる完結した形”で書くこと。個人memoryのような「詳細は◯◯リポを見ろ」という付箋型のままだと、そのリポを読む権限がないメンバーには役に立たない（権限は最小限が基本のため）。方法は難易度順に3つ——どれでもOK：

PR＝「この追加を本線に入れてください」という申請（承認制の投書箱）。a/b/cどれでも最後に管理人が承認（マージ）して初めて共有脳に入るので、共有脳が荒れません。

迎え入れの順番 — 個人アカウント → 即・組織 → 最初の作品から組織へ

組織に入るにも個人アカウントが必須（招待は個人アカウント宛て）。だから順番は一本です：

「個人リポで練習してから」は挟まない——①ルールが1本になる（業務で作るものは最初から会社の箱・例外なし。後から移すのは手戻り＆忘れる）②git操作は組織内でも全く同じ ③初日から「会社の資産を作っている」意識になる。個人アカウントは私物・個人の学習メモ・自分の第二の脳の控え（memory-〈名前〉/skills-〈名前〉）の置き場として並存（＝業務＝組織／私物と手帳＝個人）。共有脳がまだ空でも、組織の中で作らせるだけで「退職しても残る・開発物が会社に貯まる」＝それだけで導入価値があります。※招待画面の「SAML single sign-on（Enterprise 30日トライアル）」の勧誘や「Invite a billing manager」は不要・無視してOK。

渡す物は相手で変える（プロンプトは2本作らない）

• 非エンジニア → 完全版初期設定プロンプト1本（導入ロードマップ掲載のもの。メンバー分岐入り）。
• エンジニア → プロンプトは渡さない（環境構築をAIに頼む必要がない人たち）。代わりに1枚の「参加ガイド」：①業務リポはOrganizationに ②鍵は上げない ③共有脳はここ・pullして参照 ④知見はPRで共有脳へ（＝昇格フローのエンジニア版。管理人がマージ） ⑤第二の脳のやり方は任意・教材リンク。既に持っている本人の流儀（フォルダ整理・git・鍵管理）は触らない。

参加ガイドのコピペ用の雛形はカリキュラム setup/github/メンバー参加ガイド_雛形.md にあります。置き場所＝共有脳リポのREADME（メンバーがcloneした瞬間に最初に読む場所）。会社名を差し替えてそのまま使えます。

ライト層は「Claude Code契約なし」でも参加できる（2階建て）

全員にClaude Codeを契約させる必要はありません。

FIG. 2階建て — ライト層はbot経由（契約不要）／作る人だけClaude Codeの席

• ライト層（質問・報告・定型業務）＝ Slack/Discordだけ。契約・セットアップ・学習コスト不要。
• ヘビー層（自分のPCでAIに作らせる人）＝ その人だけClaude Codeの席を買う。

なお「ライト層がSlackでAIを使う」だけなら、自作せずAnthropic公式の「Claude Tag」を使う道もあります（Claude Team／Enterprise契約が必要・導入はSlackアプリを追加するだけ）。自作の常駐エージェントとの向き不向きの比較は教材「Slackで誰でもAIを使う「Claude Tag」」へ。

おまけ：クラウド実行（スマホ／Web版）との関係

Claude Codeには「Local（自分のPC）／クラウド（Claudeのサーバー）」の実行場所の選択がありますが、チーム運用のためにクラウドを選ぶ必要はありません（各自Local＋共有リポのpull/pushで完結）。知っておくのは2点だけ：①クラウド実行はGitHubからリポを取り込んで動くため、各自のPCの~/.claude（個人の脳）は読まれない——第二の脳の恩恵をフルに受けるのはLocal実行で、クラウドの成果はブランチ→PRで返る。「脳はGitHubにバックアップしてあるから読めるのでは？」も誤解で、クラウドが取り込むのは“作業対象のリポ1つ”だけ。バックアップリポを勝手に取りに行く仕組みはなく、「起動時に~/.claudeを必ず読む」という組み込みの習慣はローカル専用（バックアップ＝保険箱に控えを預けてあるだけで、支社のAIが毎朝取りに行ってくれるわけではない）。②ただしリポの中に置いたCLAUDE.mdはクラウド実行でも読まれる（公式仕様）＝「どの環境でも全員に効かせたい会社ルール」は共有リポ内のCLAUDE.mdに書くのが正解。

CHAPTER 9

早見表 — 1人運用から会社運用へ、変わる設定と「AIが読むもの」

1人運用と会社運用で「変わる設定・注意点」早見表

同じ仕組みでも、1人（①）と会社（②）では設定と注意点が少し変わります。移行するとき・教えるときはここを見直す：

ごちゃつき防止の整理表 — ②のとき、メンバーのPCで「AIが読むもの」は5つ

「CLAUDE.mdが2つ？共有脳の中には何が入ってる？」と混乱しやすいので、実物の場所で整理します：

※共有脳リポ（shared-brain）の中身は③と④だけ。個人のmemory・MEMORY.mdは共有脳には入っていません（それは②＝各自の~/.claudeにあり、控えは各自の個人アカウントのmemory-◯◯リポへ自動push）。ファイル単位の完全な地図は → 教材「AIの記憶と第二の脳」の“完全版の完成形”の図。

役割分担の確定版マトリクス — 誰が何をするか（1枚）

※手帳のバックアップは標準手順に含める（初期設定プロンプトが実施する）が、強制ではない（④個人の脳は自由の原則。嫌なら飛ばせる。ただしPC故障で脳が消える保険なので非エンジニアには勧める）。

規模の節目 — 「このサインが出たら見直す」早見表

この設計（Free・Base permissions=None・手帳は個人アカウント）は、オーナー中心で「開発する人が数人まで」の組織に合わせた形です。寿命は組織の人数ではなく、下のサインが出たかどうかで決まります（各行は独立したサイン・上から順に来るとは限らない。サインが出るまで先回りして作り込まない）：

※上2段は運用の話・下3段はGitHubの契約プランの話。下に行くほど「信頼で回す」から「仕組みで縛る」へ変わります。料金は2026-07時点＝変わりやすいので契約前に公式確認を。