Codex・Claude Codeのマルチエージェント活用｜仕事の分け方と失敗を防ぐ依頼方法

CodexやClaude Codeを活用して、開発や業務調査を複数のエージェントに分担させたいと考えていないでしょうか。このとき、単に役職名を与えて多層的な依頼を丸投げしてしまうと、各エージェントによる同じファイルへの編集が競合したり、不要な手戻りが発生したりして失敗を招きます。

役職名だけの依頼を改める結論は、あいまいな指示をやめ、「誰がどの範囲を独立して担当し、どのような成果物を戻すのか」が分かる形へと依頼文を書き直すことです。

扱うのは、読み取り中心の並列作業を起点とするCodexのサブエージェントや、独立した文脈で分業できるClaude CodeのAgent Teamsを用いた、実務での依頼と報告確認の組み立て方です。コーディングや業務調査における仕事の切り出し方から、成果物の品質・時間・費用をもとに分業体制を見直す判断までを範囲とします。

管理役を増やす前に、誰が何を進めるかを確かめる

マルチエージェントを活用して開発や業務調査を進める際、管理役（マネージャー）となるエージェントを無計画に増やす前に、まずは人間が「誰にどの範囲を独立して進めさせ、どのような成果物を親へ返させるか」を整理する必要があります。単に役職名をつけて仕事を丸投げするのではなく、お互いの作業が干渉しない問いへと仕事を切り分けることが分業の失敗を防ぐ結論です。

CodexやClaude Codeで複数のエージェントを動かす場合、各担当はそれぞれ独立した文脈（コンテキスト）を持って作業にあたります。並列に分けるときは、同じファイルを同時に編集させる書き込み作業ではなく、コードの探索、テストの実行、ログの分析といった「読み取り中心」の独立した作業から切り出すのが安全です。

Claude Codeの「Agent Teams」機能も同様に、独立して進められるタスクに適しています。この機能は既定では無効となっている実験的な機能ですが、チームメイトへ前の担当者の完了を待つような逐次作業や、同一ファイルの同時編集を任せると、調整負担やトークンの使用量が大きくなる点に注意が必要です。

たとえば、調査の課題を親が二人の担当へ丸投げしてしまうと、両者が同じ資料を調べて報告が重複する可能性があります。この場合は、「原因が含まれるファイルを探す担当」と「影響を受ける入出力を探す担当」のように、答えてほしい問いを事前に分けておくことで、親が報告を照合しやすくなります。

「プロジェクトマネージャー」や「フロントエンドエンジニア」といった役職名を付与すること自体が誤りというわけではありません。OpenAIのワークフロー構築例では、PM、デザイナー、開発担当、テスターといった役割を用いています。これらは「どんな成果物を作成し、次の工程へどう渡すか」という具体的な受け渡し条件と結びつくことで成立しています。

役職の響きに頼るのではなく、実際の作業工程と成果物ベースで仕事を定義することが求められます。

親となるエージェントから他の担当へ仕事を委任する際は、「誰がどの範囲を担うのか（分担）」「何を待つ必要があるのか（待機条件）」「最終的に親へ何を返すのか（結果）」を明確にしなければなりません。これらの条件を人間が事前に確かめたうえで、次のステップでは、一つの仕事をエージェントが迷わず動ける具体的な依頼文へと直していきます。

一つの依頼を、担当範囲と成果物が分かる形に直す

役職名だけの依頼から脱却する結論は、「シニアエンジニアとして不具合を直して」といった役職の響きに頼る曖昧な指示をやめ、具体的な作業範囲と求める成果物をセットにした依頼文へと書き換えることです。

OpenAIのマルチエージェント向け資料でも示されているように、複数のエージェントを連携させる際は、それぞれの担当に対して「明確な問い」と「期待する結果」を渡す設計が重要になります。

依頼文を具体化する際に意識すべきなのは、呼び出されるエージェントが「独立した文脈」で作業を始めるという点です。Claude CodeのサブエージェントやCodexのサブエージェントは、独立してタスクを進め、呼び出し元の親エージェントへ結果を戻します。親がそれまで重ねてきた会話履歴を、担当のエージェントがすべて知っているという前提は置けません。

そのため、「例の件をお願い」と委任するのではなく、どのファイルを対象とするかという分担範囲、親が何を待つのかという待機条件、最終的にどのような形式で結果を返すのかという受取条件を依頼文で明示する必要があります。

ここで、一件の丸投げされた依頼文を具体的な形へ直す過程を架空の例で見てみましょう。たとえば「CSVファイルの取り込み後、取引先コードの『00042』が『42』に変わってしまった」という不具合の報告を受けたとします。これをそのまま「取引先コードが42になる不具合を調査し、CSV処理を修正して」とエージェントへ委任するのは避けるべきです。

Python標準のcsvモジュールなどはデータを文字列として返す仕様であり、CSVの読み込みだけを原因と決めつけてコードの編集まで頼んでしまうと、不要な箇所の書き換えや作業の競合を招く恐れがあります。この曖昧な依頼は、次のように「担当範囲」と「成果物」が分かる形へ直します。

「取引先コードの先頭のゼロが消える事象について調査を依頼します。担当者はCSVファイルの読み込みから表示までの処理フローを追い、取引先コードの値が変わる候補の箇所を確認してください。今回はコードの直接修正は行わず、原因となっているファイル名と該当箇所、および推測される要因のテキスト報告を成果物として返してください」

このように「どこからどこまでを調べるか」という範囲と、「コードは直さず、テキストによる報告だけを求める」という枠組みを明示することで、担当エージェントは推測や脱線を防ぎ、独立した文脈でも親へ戻すべき内容を揃えやすくなります。

誰が何を調べ、親にどう戻すかという基本構造が整えば、複数のエージェントへ安全に実務を割り当てられます。次はこの「担当範囲と成果物の明確化」を前提として、実際のコーディング作業ではどのように調査・修正・統合の担当を分ければよいのかを見ていきましょう。

コーディングでは調査を分け、修正と統合の担当を決める

コーディング作業を複数のエージェントへ委任する際に失敗を防ぐ結論は、「コードやデータの調査」のみを複数の担当へ並列に行わせ、「ファイルの修正と統合」は一人の担当（通常は親エージェント）に集約することです。

開発を急ぐあまり、全員に手分けして直接コードを書かせたくなるかもしれません。しかし、Codexのサブエージェントは独立したコードの探索やテストの実行を並列に分担できる一方で、複数の担当が同じファイルを同時に編集すると競合が発生し、その調整負担が大きくなります。

同様に、Claude CodeのAgent Teams機能に関する資料においても、同一ファイルの編集や、前の作業の完了を待つような逐次依存の仕事は、分業による調整のコストがかさむことが示されています。そのため、ファイルの書き換えは一人の修正担当が担い、他の担当には該当箇所の特定と修正方針の提案を依頼することで、同一ファイルの編集競合を避けやすくなります。

前段で触れた「CSV取り込み後、取引先コードの『00042』が『42』に変わってしまう」という架空のバグ報告を例に、分業から統合までの工程を追ってみましょう。親エージェントは、ファイルのどこでデータが変化しているのかを突き止めるため、複数の担当へ並列に調査を割り振ります。

入力から変換、保存、そして表示のどの段階で変化が起きたかを特定するには、実際の処理コードと元CSVの構造を照合する必要があります。そのため、各担当にはコードを一切書き換えさせず、「調査結果と、推測される修正コードのテキスト提案」だけを成果物として親へ提出させます。

たとえば、担当Aには「標準機能でのデータ読み込み処理」を調査させます。Python標準のcsvモジュールは、各フィールドをそのまま文字列として返す仕様であるため、CSV形式の読み込み処理自体を先頭のゼロが消える原因とは直ちに断定できません。

同時に担当Bへは「データ解析ライブラリの処理部」を確認させます。もしコード内でpandas.read_csvが使われている場合、dtype引数による型の指定がないと、データが自動で数値型として解釈され、ゼロが抜け落ちてしまう可能性があります。

個別の調査報告が出揃った段階で、親エージェントが結果を集めて採否を判断します。ここでは、担当Bから上がってきた「pandas.read_csvの引数に文字列型の指定が欠けている」という報告を親が採用したとします。

親エージェント自身が該当ファイルを開いてdtype={'取引先コード': str}という修正を書き込み、スクリプトを実行して修正後の出力と元のCSVデータを照合します。ゼロ落ちが解消され、意図した通りの文字列として扱われていることを親が確認したうえで、一連の修正作業を完了させます。

この分業手順が、常に最速の解決をもたらすとは限りません。しかし、「調べる役割」と「書く役割」を明確に切り離すことで、不意なファイル競合による手戻りを防ぎ、親が結果を吟味したうえで着実に修正を統合できます。この「担当ごとに調査を分けて結果を集約する」という考え方は、コーディングに限らず、条件に基づいて情報を集める業務調査のタスクにも応用できます。

業務調査では共通条件を先に渡し、不足した結果だけを戻す

業務調査を複数のエージェントへ委任する際に失敗を防ぐ結論は、各担当へ共通の調査項目と出力形式をあらかじめ渡し、集まった報告の照合と不足分の再依頼を親エージェントに集約することです。

前節のコーディング作業で「調べる役割」と「直す役割」を分けたように、情報の比較調査においても「個別の対象を独立して調べる役割」と「集まった情報を比較表にまとめる役割」を明確に切り離します。

Codexのサブエージェントを利用する場合、独立した探索を並列に各担当へ分け、それぞれの報告を親エージェントが集約するワークフローを構築できます。このとき、親エージェントは単に仕事を丸投げするのではなく、担当者の作業範囲、待機する条件、そして最終的にどのような形式で結果を戻すのかを委任時に示さなければなりません。

これは、OpenAIのAPIを利用したマルチエージェント設計において、各担当へ明確な問いと期待する結果を与えるべきとされている考え方とも一致します。

具体的な業務調査の設計として、架空のSaaSツール3社（A社、B社、C社）の料金プランと機能を比較するケースを想定してみましょう。ここで親が「3社のサービスを調べて比較表を作って」とだけ指示してしまうと、エージェントごとに注目する機能や価格帯の基準がずれ、親が情報を統合できなくなるリスクがあります。

これを防ぐためには、エージェントごとに1社ずつ担当を割り当てたうえで、次のような共通条件と出力形式を渡して調査させます。

「対象サービスの公式サイトを調べ、確認日、初期費用、最安プランの月額料金、電話サポートの有無を抽出してください。料金には金額、通貨、税区分、課金周期を明記してください。親エージェントが事実確認できるよう、それぞれの項目に公式サイトの参照URLを添えて、箇条書きで戻してください」

Claude CodeのAgent Teams機能を利用する場合、チームメイトは独立した文脈で共有タスクを持ち、相互に連絡を取ることができます。しかし、異なる担当者が個別に調べた結果が、自動的に比較可能な条件や単位へと綺麗に揃う仕様が提供されているわけではありません。

そのため、並行調査が終わった後は、親エージェントが各担当からの報告を並べて読み、提示した条件通りに比較可能な状態になっているかを判断する役割を担います。

もし照合の過程で、「C社の報告にだけ電話サポートの参照URLが書かれていない」といった不足が見つかったとします。この場合、最初から全社の調査をやり直させる必要はありません。

親エージェントは統合文を書き始める前に、C社の担当に対して「電話サポートの参照URLが不足しているため、該当するURLのみを探して戻してください」と、不足している結果に絞って再依頼を行います。

このように、共通の条件と原典の提出を義務付けて調べさせ、結果が揃わなければ不足分だけを確かめる手順を踏むことで、不要な推測による手戻りを最小限に抑えられます。では、こうした具体的な作業の委任や結果の回収を、実際のツール上でどう進めればよいのでしょうか。

次は、CodexとClaude Codeの現行機能を用いて、どのように依頼・連絡・完了確認を行っていくのかを見ていきます。

CodexとClaude Codeで依頼・連絡・完了確認を行う

前節のように、共通の調査条件を渡して不足した結果だけを戻させる手順を実際のツールで進めるには、製品ごとに委任と報告の仕組みを正しく設定する必要があります。CodexとClaude Codeのどちらでも、「担当エージェントが親の会話履歴をすべて知っている」と決めつけず、担当範囲、待機条件と期待する成果物を依頼文で明示し、親が成果物を照合して完了確認を行います。

作業を委任する前に、利用中の認証方法と請求先を確認します。OpenAIの認証案内によれば、CodexはChatGPTでのサインインとAPIキーでの利用に対応しており、APIキーの利用はAPI料金として請求されます。

また、Anthropicの案内によれば、Claude CodeでAPIキーの環境変数が設定されていると、サブスクリプションの利用枠ではなくAPI料金が適用されます。管理役や担当者を無計画に増やす前に、実際に使うアカウントと利用枠を確かめておくことが大切です。

Codexを利用する場合、親となるチャットからサブエージェントに対して独立した仕事を明示的に委任します。このとき、サブエージェントは親が使用しているサンドボックス環境や承認設定を引き継いで動きますが、これは自動的に安全な読み取り専用環境が作られるという意味ではありません。

ファイルの書き換えを避ける場合は、前段の架空例で触れたように「コードは直さずテキスト報告のみを成果物とする」という制約を、人間が依頼文へ明確に記述する必要があります。作業後、親は子の活動内容と結果を確認できるため、提出された報告を照合して完了か再依頼かを判断します。

Claude Codeのサブエージェント機能を利用する場合も、呼び出されたエージェントは親とは独立した個別の文脈（コンテキスト）を持って作業を始めます。親の会話履歴をすべて知っているとは限らないため、依頼時には背景情報を漏れなく渡す明示的な呼び出しが必要です。

一件の委任ごとにカスタム定義ファイルを用意しなくても、都度の呼び出しで必要な指示や条件を渡す運用が可能です。

また、Claude Codeには、複数のエージェントを連携させるAgent Teamsという実験機能も用意されています。実行環境でCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を設定して有効化すると、チームメイト同士が直接連絡を取り合い、Taskツールを利用できる環境では共有タスクを使うことが可能になります。

ただし、ここでも担当が親の会話履歴をすべて知っているとは限らないため、依頼構造が複雑になりすぎないよう、最初の委任時に必要な前提をすべて渡し切ることが求められます。

どちらの製品を使用するにしても、確実な完了確認は「依頼時に指定した成果物がすべて揃ったか」を親エージェントが集約して判断する形をとります。親が各担当からの報告を読み、参照URLの提示や箇条書きといった指定条件を満たしているかを照合し、不足が見つかれば該当する担当へ不足箇所を具体的に伝えて再依頼を行います。

このように、機能の特性と制約を踏まえて依頼と連絡の経路を整えれば、報告の不足を見つけて着実に完了確認を進めることができます。しかし、システム上でうまくエージェントへ依頼を出し、完了まで導けたからといって、その分業体制が実務において常に最適であるとは限りません。

次は、得られた成果物の品質や手戻りの状況から、設定した管理役や分業体制を維持すべきかどうかを評価する方法について見ていきます。

その管理役と分業を残すか、成果物と手戻りから決める

マルチエージェントによる分業体制を構築したあとは、その体制が本当に効率的だったのかを、最終的な成果物の品質と手戻りの状況から評価して継続を判断するのが失敗を防ぐ結論です。エージェントを増やして管理役を置くアプローチは万能ではなく、かえって時間や費用の無駄を生むケースもあるからです。

エージェントの数を増やせば、システム上の調整や通信にかかる作業も増えます。Codexの公式資料によれば、サブエージェントを利用した場合、単一のエージェントで実行するよりも多くのトークンを消費することが明記されています。とくに、書き込みを伴う作業を並行して任せると編集内容の競合が発生しやすく、その調整負担が増大するため注意が求められます。

同様に、Claude CodeのAgent Teams機能も、単独のセッションや通常のサブエージェントと比べてチームメイト間の連絡や調整が増えるため、結果としてトークンの利用量が大きくなります。前の作業が終わるのを待たなければならない逐次的なタスクや、同じファイルを共同で編集するような作業には不向きです。

複数エージェントによる分業には、こうした連絡や調整のコストが常に伴います。OpenAIのAPI向け導入チェック資料では、具体的で境界が明確な仕事を選び、成果の「品質」「時間」「費用」を測定して評価するよう推奨しています。

これは特定のアプリの性能実測ではなく導入時の一般的な指針ですが、エージェントを用いた開発や調査の運用で分業の効果を判断する際にも、この三つの項目を確かめます。

これを前段までの架空例に当てはめてみましょう。もしSaaS 3社の業務調査を複数の担当に並列に依頼し、親エージェントがその結果を統合し、単独作業と比べて品質を保ちながら所要時間を短縮できたなら、その分業は価値を生んでおり、その分業体制を続ける理由になります。

一方で、CSVの「取引先コード」の不具合のようなコード修正において、調査と修正の境界をうまく引けずに管理役と担当エージェントを立ち上げたとします。結果としてエージェント同士のすり合わせや修正のやり直し（手戻り）が多発し、多くのトークンと時間を費やしてしまったのであれば、それは過剰な分業です。

その場合は不要な管理役を廃止し、ひとつのエージェントへ具体的な指示を出して単独で作業させる構成へと戻すことを検討します。

「とりあえず役職名をつけて管理させる」というアプローチを定期的に見直し、得られた成果物と費やしたコストのバランスを測ること。それが、CodexやClaude Codeを実務で効果的に使い続けるための重要なステップとなります。この記事の最後では、依頼の組み立てや見直しにおいて生じやすい疑問をQ&A形式で整理します。

よくある質問

Q. 役職名を与えずに、どのように依頼文を書けばよいですか？

結論から言うと、決まったテンプレートはありませんが、「担当する作業範囲」「親が待機・完了とする条件」「期待する成果物の形式」の3要素を明示することが分業を成功させる鍵となります。「プロジェクトマネージャーとして進めて」といった曖昧な指示は避けましょう。

本文の架空例で触れたように、「CSVの読み込みから表示までを調査範囲とし、コードは修正せず、該当箇所と推測要因のテキスト報告を成果物として親へ返すこと」といった具体的な作業と受取条件へ書き換えます。そうすれば、エージェントは独立した文脈でも迷わずに作業を進められます。

Q. Codexで「コードを書き換えないで」と指示すれば、ファイルはシステム的に保護されますか？

いいえ、システム的に読み取り専用の権限が新たに設定されるわけではありません。Codexのサブエージェントは、親エージェントのサンドボックス環境や承認設定を引き継いで動作します。依頼文での「書き換えないで」という指定はあくまでプロンプト上の指示にすぎません。

不意の変更を確実に防ぐには、依頼時に「テキスト報告のみを成果物とする」という枠組みを徹底するとともに、親の段階で書き込み承認を必須にしておくなどの安全策が求められます。

Q. Claude Codeを使う際、親エージェントの会話履歴は担当へ自動で引き継がれますか？

通常のサブエージェントは新規文脈で始まり、会話をforkして作る場合は親の会話を引き継ぐため、委任時には必要な前提を確認してください。Claude Codeのサブエージェントや、実験機能であるAgent Teamsのチームメイトは、親とは異なる個別の文脈（コンテキスト）を持って独立した作業を始めます。

そのため、親エージェントがこれまでの会話で把握している前提知識であっても、「どのファイルを確認すべきか」「どのような背景や共通条件があるか」は、委任する際に必要な部分を明示的に渡す必要があります。

Q. 複数のエージェントを動かすとトークン消費が心配です。節約の基準はありますか？

もっとも確実な対策は、最終的な成果物と手戻りの状況を評価し、「無駄な分業をやめる」ことです。CodexのサブエージェントとClaude CodeのAgent Teamsを利用すると、単独作業より多くのトークンを消費することが両社の公式資料で明記されています。

前の作業完了を待つ必要がある逐次タスクや同一ファイルの編集はひとつのエージェントに集約し、独立して進められる読み取り中心の「並行調査」に絞って担当を分けることが、品質を保ちながら時間と費用を抑えるポイントになります。