ai.ros Asset Store

← AI駆動開発 マスター講座 | Lesson 8 / 30
8

2-2 司令塔Claudeと実行部隊Claude Code

第2章 1人で巨大企業型AI組織をつくる

想定学習時間: 14分

AI駆動開発における役割分担の重要性

AI駆動開発において、一人で大規模なプロジェクトを進めるためには、AIエージェントの役割分担を明確に理解することが重要です。特に「Claudeプロジェクト」と「Claude Code」という二つのAIエージェントの役割を混同すると、開発プロセスが不安定になる可能性があります。

司令塔としてのClaudeプロジェクト

Claudeプロジェクトは、AIエージェント組織における「司令塔」の役割を担います。これは、プロジェクトの全体像を把握し、戦略を立て、実行部隊への指示書を作成する場です。具体的には、いきなりコードを書かせるのではなく、以下の点を整理します。

つまり、Claudeプロジェクトは「作戦会議の場」であり、AIエージェント組織らしい考え方として、複数の役割を担わせることができます。例えば、PM、CTO、CFO、営業責任者、CS責任者、法務担当、運用監視担当といった視点から、同じプロダクトを多角的に検討させることが可能です。

新しい営業自動化機能を開発する際を例にとると、Claudeプロジェクトは以下のような視点から検討を行います。

これらの多角的な視点での検討は、一人の人間がすべてをこなすのは困難です。しかし、Claudeプロジェクトを司令塔とすることで、これらの視点を順番に呼び出し、必要に応じて複数の立場から反論させることも可能になります。これは、人間の会議に近いプロセスをAI上で再現するものです。人数調整や日程調整、会議室の準備も不要で、議事録も自動で残り、深夜や移動中でも利用できる点が、一人で巨大企業型AI組織を構築する上での大きな強みとなります。

ただし、司令塔であるClaudeプロジェクトにも弱点があります。それは、実際のファイルや本番環境の状況を常に正確に把握しているわけではないという点です。事業の文脈や設計の整理には強いものの、サーバー上のファイルの状態、実際のエラー内容、導入されているパッケージ、ビルドの成否といった実行環境の具体的な状況は、現場を見なければ分かりません。

そこで必要となるのが、実行部隊である「Claude Code」です。

実行部隊としてのClaude Code

Claude Codeは、開発現場の担当者として機能します。現場の状況を直接確認し、具体的な作業を実行します。その役割は以下の通りです。

Claude Codeは強力な実行能力を持ち、コードを読み、ファイルを修正し、エラーを追い、テストを実行し、実装を進めてくれます。まるで目の前に優秀なエンジニアがいるかのような感覚で作業を進めることができます。

しかし、Claude Codeに「このサービスを作って」「このエラーを直して」「いい感じに実装して」といった曖昧な指示を最初から投げると、たとえ優秀であっても迷いが生じ、意図しない結果につながる可能性があります。実行部隊に戦略や目的、制約を渡さずに突撃させれば、現場は混乱し、最終的に事故につながるリスクがあるのです。

司令塔と実行部隊の連携

AI駆動開発を安定させるためには、司令塔であるClaudeプロジェクトと実行部隊であるClaude Codeの間の連携ループが極めて重要です。

  1. 司令塔Claudeプロジェクトが作戦を立てる。
  2. Claude Codeが現場で実行する。
  3. Claude Codeが実行結果を報告する。
  4. その報告を司令塔Claudeプロジェクトに戻す。
  5. 司令塔Claudeプロジェクトが報告内容を評価し、次の判断をする。

このループにおいて重要なのは、Claude Codeからの報告をそのまま完了とせず、必ずClaudeプロジェクトに戻して評価させることです。「Claude Codeからこの報告がありました。内容を確認し、次に何をすべきか判断してください」と指示することで、Claudeプロジェクトは報告内容を多角的に評価し、不足している確認事項や、次に取るべき行動を指示します。

この流れを確立しないと、Claude Codeが現場判断で広範囲な変更を行ったり、既存仕様を変えてしまったり、不必要なライブラリを追加したりするなど、全体の思想から逸脱した実装を進めてしまうリスクがあります。これは、人間の現場担当者が目の前の問題解決に集中しすぎて、会社全体の方針や長期的な運用を見落とすことと似ています。

AIエージェント組織の三層構造

安定したAI駆動開発を実現するための最終的な構造は、以下の三層で構成されます。

  1. 人間: 経営者、承認者、最終責任者としての役割。目的を決定し、最終的な承認を行います。
  2. Claudeプロジェクト: 司令塔、PM、事業企画部、設計部としての役割。人間の目的に基づき、具体的な設計や計画を立てます。
  3. Claude Code: 実行部隊、開発現場としての役割。Claudeプロジェクトの指示書に基づき、実装や修正を行います。

この流れは「人間が目的を決め、Claudeプロジェクトが設計し、Claude Codeが実装し、Claude Codeが報告し、Claudeプロジェクトが評価し、人間が承認する」となります。

ここで重要なのは、人間がすべてを手作業で確認する必要があるわけではない、という点です。ログの要約、差分の説明、テスト項目の整理、次の指示書の作成など、AIに任せられる部分は多くあります。しかし、最後に止める権限、つまり承認権限は人間が持つべきです。特に、送信、公開、課金、削除、本番DBの変更、外部APIの大量呼び出し、ユーザーへの通知、お金に関わる判断といった危険な処理は、AIだけで勝手に進めてはいけません。

このため、「人間承認ゲート」の設計が不可欠です。AIエージェント組織では、「何を自動化するか」よりも「どこで止めるか」が重要になります。例えば、営業文の作成はAIに任せても、送信前の確認は人間が行う。SNS投稿案はAIが作っても、公開前には人間が承認する。コスト試算はAIに任せても、高額APIを使う判断は人間が行う、といった具合です。

これは、リアルな会社組織における権限分担と同じ考え方です。AIに自由を与え続けるのではなく、役割を与え、権限を分け、承認ルートを作ることで、AIを組織として機能させます。

AIエージェントへの命名と指示書の活用

AIエージェントに名前を付けることは、単なる遊びではなく、役割を明確にし、責任範囲を定める上で非常に有効です。例えば、自社プロダクトでは、歴史上の偉人や物語の登場人物をAIメンターとして蘇らせるあるサービスを運営しており、運営側のAIエージェント組織にも偉人の名前を付けています。

このように名前を付けることで、Claudeプロジェクトは「誰か、これを見て」ではなく、「プロダクト本部長として、この残務を整理せよ」「デザイン責任者として、この画面の世界観を統一せよ」といった具体的な指示を、ピンポイントで担当エージェントへ出せるようになります。名前は、AIに人格を与えるだけでなく、「役割の記憶装置」として機能するのです。

そして、この役割分担を具体的に運用するのが「指示書」です。例えば、Claude Codeのセッションが途中で中断した場合、以下のような構造の指示書を作成し、Claudeプロジェクトを通じてClaude Codeに渡します。(具体的なVM名、パス、コミット、DB、マイグレーション、スクリーンショット、ログなどの情報は伏せています)

「セッション再開・継続指示書」プロダクト本部長 織田信長殿へ

対象:自社プロダクト/対象VM:[伏字]/対象プロジェクト:[伏字]/技術構成:Next.js + Fastify + PostgreSQL + Prisma

発信:総合プロデューサー 柴亮太

件名:中断した午後タスクの継続作業

上様。

Claude Code側でAPIエラーが発生し、午後の指示書の作業が中断した。
新セッションで、ここから再開せよ。

既に完了している作業

件②:メンター詳細画面の不要ボタン削除
中断前に、対象ファイルの修正は完了済み。
ただし、未コミット・未デプロイのため、再開時には以下を確認すること。
1. git statusで変更が残っていることを確認
2. 変更が消えていれば再修正
3. 変更が残っていれば、他作業とまとめてコミット

件③:設定画面の不要UI削除
別担当エージェントが既に対応済み。
重複作業は禁止。最新状態を確認し、既存作業を上書きしないこと。

残り作業

件①:非表示退避処理の本番反映
作成済みマイグレーションファイルの存在確認。
本番DBに対する安全なマイグレーション実行。
対象メニューが非表示になっていることをSQLと実機で確認。
証跡:
マイグレーション実行ログ。
更新前後のSELECT結果。
実機スクリーンショット。

件④:テスト機能メニューの出し分け修正
テストアカウントのみに表示すべき項目が、一般ユーザーに見えていないか確認。
一般ユーザーには、テスト機能の存在自体を見せない。
テストアカウントと一般アカウントで、それぞれ実機確認を行う。
証跡:
修正箇所のgit diff。
テストアカウント時のスクリーンショット。
一般アカウント時のスクリーンショット。

件⑤:履歴リセット仕様の統一
この件は最重要である。
実装前に、必ずPhase 1報告を上げること。
Phase 1で報告する内容:
現在リセット処理が触っているテーブル一覧。
触っていないが、本来触るべきテーブル一覧。
漏れがある場合の修正方針。
柴P承認後に実装へ進むこと。
承認前の実装は禁止。

件⑥:外部API連携の動作確認
対象APIが実際に動作しているかを実機検証。
「動いている」「動いていない」「一部のみ」を明確に結論づける。
修正が必要な場合は、別途指示書を待つ。

厳守事項

既に完了している作業を重複実施しないこと。
最新ブランチを確認してから作業すること。
フロントエンドのデプロイは指定スクリプトのみ使用。
DB操作は単一セッションで慎重に実施。
破壊的コマンドは禁止。
本番DBの変更は必ず証跡を残す。
自己申告の「完了しました」のみは不受理。
証跡セットで報告すること。

上様、ここから残務を片付けるべし。

— 柴亮太

このような詳細な指示書には、対象プロジェクト、完了済み作業、残り作業、証跡の要件、そして最重要タスクに対する人間承認ゲート(Phase 1報告)などが含まれます。これにより、AIエージェントは単なるチャット相手ではなく、前回の作業を引き継ぎ、他エージェントの作業を尊重し、証跡を持って報告する「担当者」として機能します。

一人巨大企業型AI組織の可能性

この司令塔と実行部隊の分業構造を持つことで、一人で複数のプロジェクトを同時に進めることが可能になります。あなたはすべてのコードを書いたり、資料をゼロから作ったり、壁打ちを一人で行ったりする必要がなくなります。司令塔Claudeプロジェクトが考え、Claude Codeが動き、あなたが最終判断を下す。この分業によって、一人の時間は何倍にも広がります。

この組織は場所に縛られません。事務所も会議室も不要で、インターネットさえあればどこからでも作業を進められます。あなたが映画を観ている間にもClaude Codeが作業を進め、家族とレジャーに出かけていてもスマホから指示書を確認できる、といった自由な働き方が実現します。これは、組織の形が物理的な制約からクラウドベースへと移行することを意味します。

ただし、AIに任せる部分が増えるほど、人間の「設計力」が問われることを忘れてはいけません。曖昧な目的を渡せば曖昧な実装になり、危険な処理を止めなければ事故につながり、確認を怠れば問題が本番環境に進んでしまいます。

AI駆動開発の本質は、AIに丸投げすることではなく、AIを組織として動かすことです。Claudeプロジェクトは司令塔、Claude Codeは実行部隊、そして人間は経営者であり承認者、最後の責任者。この三層構造を構築できるようになると、一人での開発は大きく変わり、あなたは「手を動かす人」から「組織を動かす人」へ、「作業者」から「設計者」へ、「依頼者」から「指揮官」へと役割をシフトさせることができるでしょう。

人にたとえると

大規模な建設プロジェクトを進める会社での一幕です。

本社にいる設計部門は、建物の全体像を構想し、詳細な設計図や工程表を作成します。現場の作業チームは、その指示書に基づいて実際に建材を運び、組み立て、配線を行います。作業チームは進捗や問題点を設計部門に報告し、設計部門はそれを受けて次の作業指示を出したり、計画を修正したりします。最終的に、会社の社長が完成した建物の品質や安全性を確認し、引き渡しを承認します。

司令塔の役割を持つ部署=Claudeプロジェクト
現場の作業チーム=Claude Code
最終的な承認者=人間
全体計画や設計図=指示書
建設現場=実行環境