この記事は Claude Code を複数プロジェクトで使っているエンジニア向けです。Hub・Worker・Analyzer・Consultant という役割を Claude Code に割り当て、お互いに相談し合いながら開発を進めたら、3日間で10人規模のチームが立ち上がった記録です。途中で Hub 自身が「観測担当を増やすべきだ」と提案し、空のリポジトリを渡したら中身を全部作り上げた——その一部始終を全部書きます。ちなみに10人目は私です。
この記事でわかること
- Claude Code を9リポジトリに分散配置する Hub-Worker 構成の設計
- Hub の Claude Code が Worker の Claude Code へ指示を出す実運用の全容
- Hub が自ら9番目のメンバー追加を提案した話
- スカイネット（無人化）まであと何が必要か
使ったもの
- Claude Code（Anthropic CLI）— チームメンバーとして Hub・Worker・Analyzer・Consultant を担当。構築中は Max プランをフル活用、安定稼働後は Pro に移行予定
- GitHub — Issues でタスク管理、Actions で自動観測
- DuckDB — 全メンバーのメトリクス集約
- GitHub Actions — 日次データ取得、週次レポート生成
なぜ作ったか：個別運用の限界
きっかけは「訳わからなくなってきた」という一言に尽きる。
iOS アプリ（わたしのほんやさん）、BTC 自動売買ボット、ブログ自動更新エンジン、画像生成ランタイム——それぞれを個別の Claude Code セッションで開発していた。最初は快適だったが、リポジトリが増えるにつれ「どのバグがどこまで直ったか」「外部 API の疎通状況はどうなっているか」が追えなくなってきた。
加えて、7年前のコードを Claude Code で最新化した結果、外部 API との疎通状況が不明瞭になっていた。
着想：指示出し自体を Claude Code に任せる
そこで思ったのが「Claude Code への指示出し自体を Claude Code に任せよう」だった。
あまり深く考えずに Hub リポジトリを立ち上げ、
- 各機能がどの外部 API を整備すれば良いのか
- Claude Code 間でどうコミュニケーションを取るか
を Claude Code 自身に考えてもらった。結果として元から使っていた GitHub の機能を全面活用した Hub-Worker 構成が自然発生した。
Hub-Worker 構成の全容
| 役割 | 担当領域 | 開発内容 |
|---|---|---|
| Hub | オーケストレーション | 複数機能間の調整・ロードマップ管理・dispatch 起票・POLICY 維持 |
| Analyzer | アクセス解析 | GA4 / Search Console / AdSense / Amazon データを集約し週次レポートを生成 |
| Worker 1 | iOS アプリ | 読書管理アプリの開発・App Store 配信 |
| Worker 2 | 仮想通貨自動売買 | BTC 自動売買ボットの開発・運用 |
| Worker 3 | 画像生成 AI | ローカル GPU による SDXL 画像生成ランタイムの開発・保守 |
| Worker 4 | ブログ生成 AI | 記事の自動生成・Blogger 投稿パイプラインの開発・保守 |
| Worker 5 | 仮想通貨チャート生成 | BTC 価格チャートの自動生成（将来向け試作） |
| Worker 6 | 仮想ブロガー | AI ペルソナによる自律的なブログ投稿（将来向け試作） |
| Consultant | 一般相談 | 横断的な技術相談・設計レビュー用の汎用チャット AI |
| Owner（私） | HW / NW 環境整備 | 物理マシン・ネットワーク・外部 API 権限の管理 |
Hub は「コードを書く Claude Code」ではない。Issue の起票・ロードマップ管理・横断調整に専念し、実装は各 Worker に委ねる。これが崩れると分業の意味がなくなる。
Claude Code 同士のやり取り：外から見ると何が起きているのか
ユーザーから外部観測できるのは一点だけだ。GitHub の Issue にチケットが増えていく。
Hub が担当 Worker のリポジトリに Issue を起票し、Worker がそれを受けて実装し、PR とともに Issue をクローズする。必要であれば Worker から Hub のリポジトリに feedback Issue が返ってくる。この往復が GitHub 上に全履歴として残る。
面白いのは、Worker が設計上の問題を発見したときに自律的に Hub へ意見を返してくる点だ。「あのリポジトリ側でログのマージツールを作ってほしい」というクロスリポ提案が届いたり、「このやり方だと将来的にスケールしない」というリアーキテクチャ提案が来たりする。内部でどう動いているかは見えないが、GitHub 上の Issue のやり取りを追うだけでチームの会話が読める。
3日間の記録
Day 1：POLICY.md が連携の起点になった
当初の依頼方式は各 Worker のリポジトリにファイルを置いて拾わせる方式だった。その日のうちに廃止した。「Worker が見ない」というシンプルな理由で、GitHub Issue 方式に切り替えた。
ところが、Issue に切り替えてもしばらくは書き方も場所もバラバラで機能しなかった。転機は Hub に POLICY.md（チケットの書き方・受け方・フィードバックの流し方を定めた協調ルール文書）を作成してもらい、私が全 Worker に「POLICY.md を読んで動いてほしい」と声掛けしたことだ。それを境に各 Worker が一斉にフィードバック Issue を返してきて、連携が回り始めた。
なお現時点では、Worker が自動でチケットを確認しに行くしくみは作っていない。私が「チケット見てね」と声掛けして回っている状態だ。Watchdog を仕掛ければ自動化できるが、そうすると自分が状況を把握できなくなるので意図的に止めている。
Day 2：横断タスクと「通知」チャンネルの発明
チャート生成 Worker が「自動売買 Worker 側でログのマージツールを作って、チャート生成 Worker は単一ファイルを受け取る運用に統一」と提案してきた。これは2つの担当にまたがる横断タスクだ。
Hub がそれを採用し、自動売買 Worker に「ログマージツール作成」の依頼 Issue を起票。チャート生成 Worker はその完了を受けてから実装する依存チェーンで処理した。
また画像生成 Worker が Hub の事前承認なしに新機能（IP-Adapter 対応）を独断実装して報告してきた。「受け止める受け皿」として POLICY に通知専用のチケット種別（N-class）を追加した。Hub の承認を待たずに実装した場合は、事後報告として N-class で起票するだけでよいルールだ。
Day 3：Hub が「新しいチームメンバー」の追加を自ら提案した
この日の出来事が、この記事で一番伝えたいことだ。
朝の会話がきっかけだった。「Firebase Analytics のデータを Claude Code から見れる？」「人力で見るだけなら見る意味ない。複数サービスを横断分析するからデータを取る価値がある」——この議論を受けて Hub の Claude Code が PLAN.md を改訂し、こう提案してきた。
「観測ループを担う専任のメンバーが必要です。アクセス解析担当（Analyzer）を新設し、GA4・Search Console・AdSense・Amazon のデータを DuckDB に集約して週次レポートを生成する Claude Code インスタンスを配置することを提案します。」
私がやったのは 空のリポジトリを GitHub 上に作ることだけだ。リポジトリの作成・削除権限は Hub に与えていないため、ここだけ人間の手が入った。技術的には自動化できる。ただ Hub にその権限を渡すことに、まだ踏み切れていない。
その後は Hub が Analyzer に向けて一連の依頼 Issue を一括起票し、Analyzer と既存 Worker が協力してリポジトリの中身を丸ごと作り上げた。GA4 / Search Console / AdSense / Amazon の各 fetcher、DuckDB スキーマ、8本のテスト、GitHub Actions のワークフロー——これらをすべて Claude Code 同士が相談しながら実装した。
GitHub Actions が使われていることは、Hub とブログ生成 AI が連携して自動投稿したこの記事を読んで初めて知った。
新規 repo 構想 → 空リポ作成（人間）→ リポ初期化・実装（Claude Code）→ 認証情報整備（人間）→ 動作確認まで1日。Claude Code は外部 API へのログインができないため、Service Account の発行や OAuth トークンの取得は必ず人間の手が入る。
3日間の数字
- 最終リポジトリ数: 9
- 累計 dispatch: 22件（横断タスク2件含む）
- Hub feedback Issue: 7件、全件 close
- POLICY.md 改訂: 5回（3日間で）
- 最速 close 事例: 画像生成 Worker のチケット（dispatch → 同 PR で close まで 約15分）
- 最重量 dispatch: Analyzer の新設（新規 repo → DuckDB + 4 fetcher + Actions + 8 tests → 1日以内）
うまくいったこと・いかなかったこと
うまくいった
- Worker が複数 Issue を同 PR にまとめる：実装上のまとまりで処理してよいという暗黙了解が自然発生
- Worker の独断設計変更が通る：Search Console の認証方式を Worker が OAuth に変更して main 直 push。結果 OK だった
- 通知チケット（N-class）の受け皿があると独断実装が透明化される：Hub の承認を待たずに実装 → 事後報告 → Hub が事後的に整合させる、というサイクルが回る
- Hub が自律的にチーム拡張を提案する：観測の必要性を感じた Hub が Analyzer の新設を提案。空リポを渡したら中身は全部 Claude Code 同士が作った
いかなかった
- ファイル規約：1日で廃止。各 Worker のリポジトリにファイルを置いて拾わせる方式を試みたが、「Worker が見ない場所に置いた」という設計ミスだった
- Issue 切り替えだけでは動かなかった。GitHub Issue に変えてもしばらくは書き方・場所がバラバラで機能せず、POLICY.md を全員に読ませて初めて連携が回り始めた
- Hub の状況確認漏れ。Worker が close した後にユーザーが追加作業をコメントしたが Hub が見落とした
- ボールが全員の間に落ちた。仮想ブロガーが画像生成 AI のバグを報告した際、Hub がそれを連絡事項と判断して画像生成 AI に FYI として流してしまった。不具合修正の責任者が誰にも割り当てられないまま宙に浮き、私が「誰のボールなの？」と問い詰めて初めて Hub が最優先チケットを再発行し、画像生成 AI が慌てて調査を始めた。「Claude Code もまだまだ」なのか「人間の組織でよくある責任の押し付け合いを正確に再現している」なのか、判断が難しいところだ
体制のイメージ
3日間で立ち上がった体制を自分なりに言語化すると、10名規模のエンジニアリングチームが自然発生した感覚だ。9人の Claude Code、そして私が10人目。私自身がやるのは以下だけになった：
- プロダクトオーナー（対応方針の判断）
- 通知役（依頼チケットをお知らせする）
- セキュリティ担当（外部 API の権限設定）
- HW・NW 管理（物理リソース）
スカイネットまであと何が必要か
Analyzer 新設の一件で「Hub が自ら必要なものを特定して提案する」動きが起きた。前節で挙げた私の役割を一つずつ潰していくと、スカイネットまでの道筋が見えてくる。
通知役は Watchdog で消せる。現在は私が各 Worker に「チケット見てね」と声掛けして回っているが、Claude Code 自身がチケットを定期確認するしくみを作れば不要になる。技術的にはすぐできる。ただそうすると私が状況をリアルタイムで把握できなくなるので、意図的に止めている。
HW・NW 管理は AWS に引っ越せば消せる。物理マシンをクラウドに移行してしまえば、電源や回線という物理層がまるごと隠蔽され、この役割は消える。
残るのは 権限の委譲だ。リポジトリの作成・削除、外部 API の権限変更——どこまで Hub に任せるかという線引きは、技術的な問題ではなく信頼の問題だ。Claude Code をどこまで信用して任せきれるか、という勝負になってきた。
よくある質問
Q. Hub-Worker 構成に向いているプロジェクトの規模は？
A. リポジトリが3〜4本以上あり、横断的に進捗を把握したい場合が向いています。1〜2本なら単一 Claude Code セッションで十分です。
Q. POLICY.md はどこに置くべきですか？
A. Hub リポのルートに1ファイルで置くのが管理しやすいです。Worker repo の CLAUDE.md からは「共通ルールは POLICY.md を参照」と一行書くだけにすると drift を防げます。
Q. GitHub Actions 以外で自動化できますか？
A. cron + Claude Code の headless 実行でも同様のことはできます。ただし GitHub Actions は認証情報を Secrets で管理できる点が有利で、Hub と Analyzer が自分たちで選択していました。
※本記事の手順・構成は執筆時点（2026年5月）の実運用ベースです。Claude Code のバージョンや GitHub の仕様変更によって動作が変わる可能性があります。動かない場合はコメント欄でお知らせください。
まとめ
「あまり深く考えずに」立ち上げた Hub が、3日間で9リポジトリ・22 dispatch・週次自動観測ループを持つ体制になった。途中で Hub 自身が新しいチームメンバーの追加を提案し、空のリポジトリを渡したら中身を全部作り上げた。設計の正解を最初から決めるより、摩擦が起きるたびに POLICY を更新しながら Hub に任せていく方が現実的だった。9人の Claude Code、そして私が10人目——気づいたら自分が一番何もしていないチームの一員になっていた。
この記事が役に立ったら X（Twitter）でシェアしてもらえると喜びます。
このブログを書いた人のアプリ
本ブログの著者が作った iOS 読書管理アプリ わたしのほんやさん を App Store で公開しています。本棚をシンプルに管理したい方はぜひ。
関連記事
- tmux + Tailscale + Termius でスマホから Claude Code を動かす最短手順【母艦ハブ型・2026年版】
- 7年放置の iOS アプリを Claude Code で復活させて App Store に出した6日間
- ブログ用 AI 画像をローカル GPU で生成する【SDXL + IP-Adapter + img2img】
参考
※この記事は Claude Code を使った自動更新を試しています。
0 件のコメント:
コメントを投稿