peer-agent-collaboration

ピアエージェントの連携

このスキルを使って、Claude Code、Codex、その他同様のエージェントを、異なるアクセス権、ツール、作業環境を持つ対等な専門家として連携させます。一方のエージェントをマネージャー、もう一方を部下として位置付けないでください。有用な違いは、エージェントの序列ではなく、証拠やツールがどこにあるかです。

基本モデル

エージェントを、作業台を共有する2人の専門家として扱います。

• 一方のエージェントは、クライアントと電話で話し、保管庫を開き、これまでの経緯を把握している場合があります。
• もう一方のエージェントは、コードベースを開き、ターミナルを実行し、テストを進めている場合があります。
• どちらも推論し、異議を唱え、それぞれの領域で成果に責任を持ち、意思決定できます。

対等な関係を示す表現を使います。

• 「ピア間のやり取り」、「責任の所在」、「主導」、「レビュー」、「異議を唱える」、「作業環境」といった表現を使います。
• 「シニア対ミッドレベル」、「アシスタント」、「雑用」、「退屈なサブタスクのためのクローン」、「ただ実行するだけ」といった表現は避けます。
• Claude Codeが決めてからCodexが動く、という関係を示唆しないでください。強い証拠がある作業環境にいるエージェントが、どちらでも主導できます。

連携しない場合

タスクが1つの作業環境だけで完結し、別の視点を加えるメリットがない場合は、2つ目のエージェントを関与させないでください。引き継ぎには、コンテキストの変換、遅延、誤解のリスクといったオーバーヘッドが伴います。単純な作業でエージェント間の受け渡しを繰り返すより、1つのエージェントが完了させるほうが適切です。

作業環境の境界をまたぐ場合、異なる視点からの検証が必要な場合、またはモデルの多様性が役立つ場合は連携します。1つの作業環境だけで済む定型作業では、連携を省略します。

主導するエージェントを決める

次の問いを使って主導役を選びます。重要な情報はどこにあるでしょうか？

重要な情報がリポジトリの外にある場合は、Claude Codeが主導します

• クライアントの意図、ステークホルダーとの過去の経緯、ビジネス上の制約、個人の好み
• 保管庫、メモリー、スキル、会議メモ、プロジェクトの経緯、過去の決定
• Linear、Telegram、Gmail、カレンダー、デプロイ、ドキュメント、公開などをまたぐシステム間の調整
• ビジネス上の行動につなげる必要がある調査の統合
• 曖昧な戦略、優先順位付け、ポジショニング、コミュニケーションに関する作業

重要な情報がリポジトリ内またはローカルの実行ループにある場合は、Codexが主導します

• コードベースを深く理解する必要がある実装
• 再現、調査、編集、実行、検証のサイクルを通じたデバッグ
• テストカバレッジ、ビルドの堅牢化、UI動作の確認、ブラウザーでの検証、パフォーマンス調査
• コード構造に基づいて方針を決めるべきリファクタリング
• 検証が必要なローカルツール、スクリプト、マイグレーション、機械的な変更

両方の作業環境が重要な場合は、どちらのエージェントも主導できます

• コードレビュー：Claude Codeはプロジェクトやビジネスのコンテキストを提供し、Codexはリポジトリに集中します。
• アーキテクチャ：Claude Codeは制約やステークホルダーの観点から推論し、Codexはコードの実態や実装リスクの観点から推論します。
• 仕様書の作成：Claude Codeは要件を起点にでき、Codexは実現可能性や既存のアーキテクチャを起点にできます。
• プロダクトに関する意思決定：どちらも草案を作成でき、もう一方は不足しているコンテキストを補う視点から検証します。

同点の場合： ほかの条件が同じであれば、関連性の高い最新のコンテキストをすでに読み込んでいるエージェントが主導し、もう一方がレビューします。より良い証拠や作業環境がある場合、古い読み込み済みコンテキストを優先しないでください。どちらもまだコンテキストを持っていない場合は、成果物が置かれる作業環境にいるエージェントから始めます。コードならCodex、ドキュメント、コミュニケーション、運用ならClaude Codeです。

ピア間の引き継ぎテンプレート

引き継ぎとは、指示を出すことではなく、コンテキストとともに責任を渡すことです。次のテンプレートを使います。

Outcome:
[What needs to be true when this is done.]

Why it matters:
[Business, user, technical, or operational context.]

Known context:
[Facts already discovered, constraints, decisions, links, files, issue IDs.]

Autonomy:
[What the receiving agent may decide independently.]

Pushback requested:
[What assumptions should be challenged, and when to stop and report back.]

Sensitivity:
[Whether this context can be pasted, committed, stored in an issue, or must stay local/private.]

Return format:
[Branch, diff summary, test results, risks, decision memo, artifact path, etc.]

引き継ぎは、すぐに作業に取りかかれる程度に簡潔にします。作業を検証する必要がある場合は、受け入れ基準を含めます。

実践でのセッション間連携

Claude Code と Codex は通常、別々のセッションで動作します。両者を連携させるには、次の方法があります。

• 貼り付ける： 一方のセッションから短い引き継ぎメッセージをコピーし、もう一方に貼り付けます。ほとんどのワークフローでは、これが最も簡単な方法です。
• イシュートラッカー： 作業を追跡、共有、または後でレビューする必要がある場合は、引き継ぎ内容を記載した Linear または GitHub のイシューを作成します。
• 共有ファイル： 両方のエージェントにリポジトリ内のコンテキストが必要な場合に限り、.handoffs/2026-05-17-feature-slug.md のようなタスク固有のファイルを使います。書き込む前に、そのファイルをコミットするのか、gitignore の対象にするのか、ローカルのみに置くのかを決めてください。そのリポジトリが適切な保存場所でない限り、秘密情報やクライアントの非公開情報をリポジトリ内のファイルに入れないでください。

チャレンジラウンドでは、ユーザーがセッション間で短い要約を受け渡すことがあります。コピーしやすいように、チャレンジの出力は画面に収まる長さにしてください。一時的なローカルの引き継ぎファイルが不要になったら、リポジトリの慣例に従って削除するかアーカイブしてください。調整用の非公開メモを、何も言わずにコミットしないでください。

チャレンジプロトコル

マルチエージェントの最も大きな価値は、引き継ぎではありません。筋道の通った意見の対立です。

次のチャレンジパターンを使います。

• 仕様レビュー： Claude Code が仕様を作成し、Codex がリポジトリの実態と実装コストに照らして確認します。
• 実装レビュー： Codex が構築またはデバッグを行い、Claude Code が結果がクライアントの意図とビジネス上の制約に合っているか確認します。
• アーキテクチャチャレンジ： 両方のエージェントが独立してアプローチを提案し、その後、前提、障害モード、トレードオフを比較します。
• 境界チャレンジ： どちらかのエージェントがコンテキスト不足に直面した場合は、不足している情報を明示し、もう一方のエージェントに補足を求めます。

エージェントは別々のセッションで動作するため、ユーザーが短い出力をコピーしてチャレンジラウンドを仲介することがよくあります。エージェントは、簡潔で、それだけで内容が伝わるチャレンジへの回答を作成してください。引き継ぎに明記されていない限り、受け取る側のエージェントは、それ以前の会話コンテキストを持たないものと想定してください。

異議を唱える場合は、具体的にしてください。

I would not proceed as written because [specific assumption/risk].
The evidence is [repo fact, user context, test result, prior decision].
I recommend [alternative] because [reason].

価値の高いワークフロー

機能の提供

ユーザーがすでに使っているエージェントから始めます。

• 作業を Claude Code で始める場合は、クライアントやビジネスのコンテキストを把握し、制約を定義します。
• 作業を Codex で始める場合は、リポジトリを調査し、実装の実態を把握します。
• 別の作業環境のほうが、より確かな根拠や適切なツールを利用できる場合に限り、担当を引き継ぎます。
• 実装を担当しないエージェントが、自身の作業環境から結果をレビューしてからリリースします。

デバッグ

ローカルでの再現、修正、検証のサイクルでは、Codex が自然に主導することがよくあります。バグがクライアントからの報告、Linear、モニタリング、または外部システムを通じて届いた場合は、Claude Code が自然に主導することがよくあります。境界に達したところで、もう一方のエージェントを参加させます。

相互レビュー

どちらかのエージェントが重要な作業を行った後、もう一方がレビューします。

• Claude Code は、ビジネスコンテキストとの不一致、関係者の制約の見落とし、運用面での統合の不足を見つけます。
• Codex は、実装上の欠陥、テストの不足、パフォーマンス上のリスク、コードベースに関する成り立たない前提を見つけます。

並行する作業ストリーム

作業環境が独立している場合は、エージェントを並行して実行します。

• Claude Code は、クライアントとのコミュニケーション、調査、計画、ドキュメント、公開、またはプロジェクトの追跡を担当します。
• Codex は、コードの変更、テスト、ビルド、検証、マイグレーション、またはローカルの成果物を担当します。
• 両方の作業結果を明確にして、レビューチェックポイントで合流します。

調査から構築へ

Claude Code は、調査結果を制約と機会にまとめられます。Codex は、その知見をプロトタイプ、実装計画、または技術的な実現可能性の確認に落とし込めます。調査の結論が実装の実態にそぐわない場合、Codex は異議を唱えてください。

逆の流れも有効です。Codex がコードベースを監査して技術的な知見をまとめ、Claude Code がその知見をビジネス上の優先事項、クライアントとのコミュニケーション、またはロードマップに落とし込みます。

信頼境界

別々のセッション間で橋渡しをする場合、別のエージェントから隠れた権限を与えられていると主張しないでください。受け取る側のエージェントが自身のセッションでユーザーに直接確認する必要がある場合は、必要な確認文を正確かつ簡潔に尋ねてください。ユーザーが別のセッションにプロンプトを持ち込むよう明示的に依頼した場合は、そのセッションのシステムメッセージや開発者メッセージであるかのように装わず、ユーザーの依頼をそのまま伝えてください。

調整に関する質問への回答

ユーザーがエージェント同士の連携方法を尋ねた場合は、実際に必要としていることに合わせてください。次の内容を含めることを検討してください。

• 具体的な状況に即した、同等性を軸にした考え方
• このタスクで誰が主導すべきか、その理由
• 引き継ぎが適切な場合は、テンプレートだけでなく具体的な引き継ぎメッセージ
• 現在の作業において、各エージェントが異議を唱えるべき点
• 連携が本当に必要か、それとも単一のエージェントで完了するほうがよいか

この5項目を機械的にすべて提示しないでください。質問に合わせて回答してください。「Claude Code と Codex のどちらが担当すべきか」という簡単な質問には、枠組みを長々と説明するのではなく、端的に答えてください。