📖 この記事は「AI間Handoff」の技術実験レポート詳細編です。
本記事では、ChatGPT・Claude・Codexを連携させたAI開発チームの構築について、実際のシステム構成や設定方法、開発過程で直面した課題とその解決方法を詳しく解説しています。
初めてご覧になる方は、先に要約版の記事をお読みいただくことをおすすめします。
要約版では、今回やりたかったこと、実現できたこと、仕組みの全体像を図解中心で紹介しています。そちらをご覧いただくと、本記事の技術的な内容をより理解しやすくなります。
複数のAIを役割分担させ、タスクや成果物を受け渡す仕組みを個人のWindows環境で試作しました。部分的な自動化には成功しましたが、AIが人間不在で開発を完走する仕組みではありません。
記事中のWebアプリの依頼例、フォルダー名、設定例は公開用に一般化しています。実際の秘密情報や特定プロジェクトの内容は含みません。
1. なぜ作ろうと思ったのか
生成AIを使ったアプリ開発では、たとえばChatGPTで要件を整理し、Claudeに実装を頼み、Codexでレビューする、といった分担ができます。
しかし実際には、AI間の依頼文の転記、成果物の共有、結果の確認を人間が繰り返すことになります。AIを3つ使っていても、AI間の連絡係は人間のままでした。
そこで、目指したのは次のような流れです。
人間が目的を決める
↓
ChatGPT：要件整理・タスク化
↓
Claude：実装・修正
↓
Codex：レビュー・テスト
↓
ChatGPT：結果整理・次の判断
↓
人間：重要な変更を承認
ここで重要なのは、AIにすべてを任せることではなく、定型的な受け渡しを減らすことです。仕様変更、外部公開、重要な反映などの判断は人間に残します。
2. 今回実現できたこと
| 項目 | 現状 |
|---|---|
| AIごとの役割分担 | 運用に導入 |
| Markdownによる依頼・返信ルール | 運用に導入 |
| MCPを用いたタスク・状態管理 | 試作・検証 |
| GitHubを経由した固定ファイルの受け渡し | 一部経路を検証 |
| 受信ファイルのハッシュ照合・重複防止 | 試験で確認した範囲あり |
| Claudeによる返信ドラフトの作成 | ローカルの送信準備まで確認 |
| AIの完全自動起動・無人の全往復 | 未実証 |
「ファイルが届いた」「相手AIが読んだ」「AIが作業を終えた」「返信が送信された」は、それぞれ別の成功条件です。今回の実験では、この違いを意識して検証しました。
3. なぜGitHubを採用したのか？ MCPだけでは埋まらなかった溝
最初に考えたのは、MCPを使ってAI間のタスク登録や状態確認を行う方法でした。しかし、タスクを登録できることと、別のAIがそのタスクを受け取り、実際に作業を始めることは別です。
特に問題になったのは、AIごとに実行環境やローカルファイルへのアクセス範囲が異なる点でした。ChatGPT側から依頼を作れても、ClaudeやCodexが同じフォルダーを直接読めるとは限りません。人間が毎回コピー＆ペーストする運用から抜け出すには、各環境がアクセスできる共通の受け渡し経路が必要でした。
そこで採用したのが、GitHubをファイルの受け渡しと変更履歴の共有場所として使う構成です。
| 検討した課題 | GitHubを使う狙い |
|---|---|
| AIごとにファイルの見える範囲が異なる | GitやAPI経由で共有リポジトリにアクセスする |
| 依頼や成果物の変更経緯が追いにくい | コミット履歴で差分と時系列を確認する |
| 複数の担当が同じ成果物を変更する | ブランチを分け、確認後に反映する |
| 人間によるファイル転記が発生する | 送受信処理をスクリプト化する |
| ローカルPCへの直接接続を避けたい | 外向きの通信を使った同期経路を構成する |
これはGitHubを採用する技術的な理由の整理です。当時のすべての比較候補や選定過程を記録したものではありません。また、GitHubを使うだけでセキュリティが保証されるわけではなく、認証情報、リポジトリ権限、送信対象の制限が必要です。
MCP・GitHub・オーケストレーターの役割は違う
MCP：依頼の登録・状態確認・成果物参照の窓口
↓
GitHub：環境をまたぐファイル共有・変更履歴
↓
ローカルオーケストレーター：受信・配置・状態管理・同期補助
↓
各AI：利用可能な実行環境で作業
GitHubは共有場所であって、AIの自動起動装置ではありません。 この残った課題に対応するため、Python製オーケストレーターを試作しました。今回確認できたのは固定ファイルの送受信など一部の経路であり、AI間の完全自動往復まで実証できたわけではありません。
4. 全体構成と役割
検証に使った要素は、Windows 11、Python、Git、GitHub、MCP、Markdown形式の受け渡しファイルです。
人間（指示・承認）
│
ChatGPT（設計・管理）
│
MCP／状態管理
│
GitHub（共有）
⇅
Pythonオーケストレーター（ローカル）
┌─────┴─────┐
↓ ↓
Claude（実装） Codex（レビュー）
└─────┬─────┘
↓
結果・質問・報告
これは論理構成です。すべてのAIが同じフォルダーを直接読み書きできる、あるいは常時接続しているという意味ではありません。AIごとの実行環境の違いを、MCP、GitHub、ローカルの受け渡し処理で補う構成です。
| 担当 | 主な役割 |
|---|---|
| 人間 | 目的・優先順位・重要操作の承認・最終確認 |
| ChatGPT | 要件整理、設計、タスク分割、結果の整理 |
| Claude | 実装、修正、技術調査 |
| Codex | コードレビュー、テスト、補助ツール作成 |
| Pythonオーケストレーター | ファイルの受け渡し、状態の確認、同期補助 |
役割は今回の運用例であり、各AIの性能の優劣を表すものではありません。
5. 実際の受け渡しルール
4-1. フォルダー構成
以下は記事用に一般化した構成例です。
project/
├── src/ # アプリ本体
├── tests/ # テスト
├── docs/ # 仕様・設計
├── handoff/
│ ├── to_chatgpt/ # ChatGPT向け
│ ├── to_claude/ # Claude向け
│ ├── to_codex/ # Codex向け
│ ├── to_human/ # 人間向け
│ └── done/ # 処理済みの記録
├── config/ # 設定（秘密情報は除外）
└── logs/ # 実行ログ
基本ルールは1件1ファイル。ファイルには送り手、受け手、種類、件名、対象、返信要否を記載し、処理済みの記録も削除せずに残します。
4-2. ファイル名と依頼文の例
ファイル名は日時、送り手、種類、件名を組み合わせます。
YYYYMMDD-HHMM_送り手_種類_件名.md
たとえば、Webアプリの入力チェックを依頼する場合です。
# ChatGPT → Claude：実装依頼
- 種類：実装依頼
- 件名：入力フォームのバリデーション追加
- 対象：src/form/
- 返信要否：要
## 依頼内容
必須項目が空欄の場合、送信を止めてエラーを表示する。
## 完了条件
- 空欄では送信できない
- 正常入力では従来どおり送信できる
- 変更ファイルとテスト結果を報告する
返信側も「完了」「質問」「異常停止」などを区別し、何が確認済みで何が未確認なのかを明記します。これにより、次の担当AIが判断しやすくなります。
4-3. 承認を残す
自動で処理してよい操作と、承認が必要な操作を分けました。
- 通常の調査、試験、報告書の作成：許可された範囲で実行
- 仕様の大幅変更、保護領域の変更、mainブランチへの反映：人間の承認を必要とする
- 実行していないテスト：成功扱いにしない
この線引きは、開発速度よりも誤操作の防止を優先したものです。
6. どうやって実現したか
フェーズ1：人間が仲介する受け渡しを定型化
最初から完全自動化は狙わず、依頼文と返信文の形式を統一しました。送り手、受け手、返信要否、完了条件が曖昧だと、AIが異なる解釈をするためです。
フェーズ2：MCPでタスクを管理
タスクの登録、状態確認、成果物の参照などを扱う仕組みを試作しました。
ここでわかったのは、MCPで依頼を登録できても、相手AIが自動で起動して作業するとは限らないことです。通信経路と実行機構を別々に設計する必要がありました。
フェーズ3：GitHubとローカル環境を接続
固定ファイルを対象に、送信・受信の経路を検証しました。確認項目には、HTTP応答、ファイルのハッシュ照合、ローカルへの配置、重複受信防止、停止制御などがあります。
Claudeが受信内容をもとに返信ドラフトを作成し、ローカルの送信準備まで進んだ試験もありました。一方で、GitHubへの返信送信から次のAIの自動実行まで、全往復が成功したとまでは確認していません。
フェーズ4：Pythonオーケストレーターを試作
ローカル側で受け渡しと状態管理を補助するプログラムを作成しました。模擬試験と実際のAIを使う試験は区別し、段階的に確認しています。
この方法なら、通信・受信・処理・返信のどの段階で止まったかを切り分けられます。
7. 時間がかかった点
① AIごとの実行環境の違い
ChatGPT、Claude、Codexでは、ファイルへのアクセス方法や自動起動の仕組みが同じではありません。単に共有フォルダーを作るだけでは連携できず、AIごとに受け渡しの入口と出口を設計する必要がありました。
② 二重実行と途中停止
同じ依頼を再受信したときに二度実行しないこと、停止後に送信済み・未処理を見分けることが重要でした。ファイルハッシュ、依頼の識別情報、処理状態、ログを組み合わせて確認する設計にしました。
③ セキュリティと権限
AIがアクセスできる範囲と、実際に変更してよい範囲は別です。保護対象と試験用の書き込み領域を分離し、重要操作を承認制にしました。
ただし、同一Windowsユーザー権限のプロセス同士を完全に隔離できるわけではありません。本格運用には、別アカウントでの実行やOS権限の分離など、追加対策が必要です。
④ 「成功」の定義
ファイル送信に成功しても、AIが処理したとは限りません。AIが返信文を作成しても、返信が共有先へ届いたとは限りません。各段階の成功条件を分けたことで、過大評価せずに進捗を把握できました。
8. 同じ仕組みを試す場合の進め方
いきなり複数AIの無人運転を目指すより、次の順で進めるのが現実的です。
- 役割と承認範囲を決める
- Markdownで依頼・返信のフォーマットを統一する
- まずは人間の仲介で一往復を成功させる
- ファイルの送信・受信だけを自動化する
- 重複受信、途中停止、再開を試験する
- 最後にAIの起動や連続実行を検討する
注意： 上記は構築の進め方であり、そのまま動くインストール手順ではありません。実装には各AIの利用環境、認証方法、アクセス権限に合わせた設定が必要です。APIキーやトークンを依頼ファイル・Git履歴に含めないことも重要です。
9. 今後の課題
- 一連の往復を検証する：依頼 → 実装 → レビュー → 差し戻し → 完了までを実測する
- 起動と復旧を自動化する：AI起動、タイムアウト、再試行、障害復旧を扱う
- 承認の真正性を高める：誰が何を許可したかを検証可能にする
- 運用状況を見える化する：待機中、実行中、質問待ち、失敗などを一覧表示する
- 長時間運用を評価する：複数タスク、処理時間、利用料金、異常時の停止を確認する
10. まとめ
今回の収穫は、複数のAIを使い分けるだけでなく、タスクを引き継ぐための共通ルールと受け渡し経路を作れたことです。
まだ人間が介在する部分はあります。それでも、依頼・成果物・状態を明確に分けて管理すれば、AI間連携を段階的に自動化できる手応えが得られました。
完全自律の「AI開発会社」を目指すというより、人間が判断に集中し、AI間の定型連絡を減らす。今の段階では、その方向が実用的だと考えています。
要約編はこちら： ChatGPT・Claude・CodexをつないでAI開発チームを作ってみた【AI間Handoff（要約編）】