TL;DR：一つのインターフェースで複数のAgentを操作することが、まず解決するのはツールの切り替えとコンテキスト運搬の摩擦だ。さらに一段深いところでは、ユーザーがタスクの場面に応じて適切なAgentを選び、Claude、Codex、Antigravity、Grokに共同で作業を完成させることを可能にする。モデルページは選択肢を絞り込む役割を担い、統合インターフェースは調整と引き継ぎを担う。そして人間は権限・証拠・最終判断を保持し続ける。

現在、私の作業環境は一つのインターフェースの上で複数のAgentを操作することを実現している。この体験はきわめて不思議で、まるで『射鵰英雄伝』の郭靖が、降龍十八掌・七十二路空明拳・左右互搏術・易筋鍛骨章・九陰真経総綱・療傷篇・上天梯・蛇行狸翻・飛絮勁・収筋縮骨法・移魂大法・大伏魔拳法・手揮五弦・摧堅神爪・白蟒鞭法・全真内功・金雁功・天罡北斗陣・南山拳法・開山掌法・分筋錯骨手・空空拳・越女剣法・伏魔杖法・金龍鞭法・南山刀法・呼延槍法・金鐘罩鉄布衫・哲別神箭術・モンゴル相撲・逍遙遊・奇門遁甲、そして武穆遺書といった、ありとあらゆる絶学を一身に集めてしまったかのようだ。

Claudeは Codexを操作でき、Codexも Claudeを操作できる。この作業方式をさらに広げれば、AntigravityやGrokも参加させることができる。

表面的には、これはツールの選択肢が少し増えただけのように見える。しかし実際に変わっているのは、AIを使う際の基本的な方法そのものだ。

これまで複数のAIツールを使う際には、通常その間の摩擦を自分自身で処理する必要があった。

図1｜複数ツールの切り替えが作業をどう中断させるか

flowchart LR
    A[疑問を思いつく] --> B[最初のツールを開く]
    B --> C[内容をコピーする]
    C --> D[二つ目のツールに切り替える]
    D --> E[背景を改めて説明する]
    E --> F[さらに他のツールに切り替える]
    F --> G[複数の出力を整理する]
    G --> H[元の作業に戻る]

どのツールもそれぞれ強力かもしれないが、ユーザーは常に内容の運搬、コンテキストの維持、作業進捗の記憶、そしてどの出力を次のツールに渡すべきかの判断を自分で担わなければならない。

現在の変化は、これらのAgentが同一の操作面の中に置けるようになったことだ。

図2｜単一のインターフェースが複数のAgentを同じ作業文脈に置く

flowchart TB
    U[ユーザー]
    I[統合操作インターフェース]
    C[Claude]
    X[Codex]
    A[Antigravity]
    G[Grok]
    U --> I
    I --> C
    I --> X
    I --> A
    I --> G

開くウィンドウの数が減ることは、表面的な結果にすぎない。

それによってユーザーは「あるひとつのAIを使う」という発想から、「互いに協働できる一群のAgentを調整する」という発想へと移行し始める。

真の利便性とは、作業が切り刻まれなくなること

複数のAIツールが同時に存在することは、もともと選択の自由だったはずが、操作の負担に転じることもある。

ツールが一つ増えるたびに、それぞれのインターフェース、操作方法、コンテキストの集合、出力フォーマットが増えていく可能性がある。働き手は一見より多くの能力を手にしているように見えて、実際にはツール自体の管理により多くの時間を費やしてしまう。

ここには少なくとも四種類の摩擦がある。

一つ目はインターフェースの摩擦だ。

ユーザーは異なるウィンドウを絶えず開き、閉じ、切り替え続けなければならない。これらの動作自体は価値を生まないのに、思考を中断させてしまう。

二つ目はコンテキストの摩擦だ。

同じタスクを異なるAgentに渡すとき、ユーザーはしばしば背景・目標・制約・現在の進捗を改めて説明しなければならない。その情報のどこか一部でも伝わらなければ、次のAgentは誤った前提から作業を始めてしまいかねない。

三つ目はフローの摩擦だ。

ユーザーは、どのAgentがすでに何を終えたか、次はどこに渡すべきか、どの出力がすでに確認済みで、どの内容がまだ提案に過ぎないかを自分で覚えておく必要がある。

四つ目は責任の摩擦だ。

複数の結果が異なるツールに散らばっているとき、ユーザーは振り返って追跡することが難しくなる。どのAgentがどの判断を下したのか。どの部分が元データで、どの部分が推論なのか。どの結果が人間の検収を経たものなのか。

したがって、一つのインターフェースで複数のAgentを操作することの価値は、まずツールの摩擦を減らし、人間の作業がツールによって切り刻まれないようにする点にある。

「一つのAIが答える」から「一つの作業ネットワーク」へ

従来のAIの使い方は、おおよそ次のようなものだった。

図3｜従来型の一問一答式のAI利用方法

flowchart LR
    H[人が質問を出す] --> M[一つのAIが答えを生成する]
    M --> J[人が採用するかどうかを判断する]

クロスエージェント・ワークフローは、これよりも次のような構造に近い。

図4｜クロスエージェント作業ネットワークの基本構造

flowchart TB
    H[人がタスクを出す] --> I[統合インターフェースがタスクを受け取る]
    I --> P[タスクの分解と役割分担]
    P --> E[異なるAgentがそれぞれ実行する]
    E --> T[Agent間で結果を引き継ぐ]
    T --> R[統合インターフェースが進捗を統合する]
    R --> J[人間が検収し判断する]

この変化の核心は、作業が異なるAgentの間を流動できるかどうかにある。

あるAgentは問題の理解を担当し、別のAgentは実行を担当し、三つ目のAgentは誤りを見つける役割を担い、四つ目のAgentは独立した視点を提供する。最後に、ユーザーあるいは指定された統合役のAgentが結果を収束させる。

このような構造の中では、AIはもはや質問に答えるだけの道具ではなく、作業ネットワークの中の異なるノードにもなる。

以前、〈三つのClaude、一つのループ：デザイン探索を実装のリリースにどうつなげたか〉という記事を書いたことがある。あのときは、異なるClaudeのインターフェース同士がmock・spec・screenshotを介してどう一つのループに接続されるかを論じた。今回のクロスエージェント・ワークフローは、そこからさらに一歩進んでいる。引き継ぎの相手はもはや同じプロダクトの異なるインターフェースだけではなく、異なるシステム、異なるモデル、異なる権限環境にあるAgentである可能性もある。

モデル選択はブランドではなく場面に従うべき

私は毎週二回、定期的にモデル最前線リアルタイムダッシュボードを更新している。このページは固定的なモデルランキングではなく、一種の選択マップだ。執筆・調査・プログラム開発・日常業務といった観点から、現時点で検討に値するモデルとコストを整理している。

この点はクロスエージェント・ワークフローにとって重要だ。モデルは更新され続け、価格は変動し、同じモデルであっても異なるタスクでのパフォーマンスは変わりうる。今日あるロールに適したモデルが、次の更新後にはより良い選択肢に取って代わられているかもしれない。

したがって、記事の中でClaudeを常に「プランナー」、Codexを常に「実行者」と書くべきではないし、AntigravityやGrokをある種の固定した性格に決めつけるべきでもない。より正確な言い方をすれば、まずタスクを見て、次にその時点でのモデルのデータを見て、最後にどのAgentが今回の作業でどの役割を担うかを決める、ということになる。

モデルページが現在採用している読み方の順序は、そのままクロスエージェントの選択フローに転用できる。まず能力差が誤差の範囲を超えているかどうかを見る。スコアが近ければコストを比較する。次にベンチマークが本当に自分のタスクに対応しているかを確認する。最後にデータ主権と安全リスクを判断に組み込む。

図5｜タスクの場面に応じて今回のAgentを選ぶ

flowchart TB
    A[タスクの場面を入力する] --> B[モデル選択マップを確認する]
    B --> C{主な制約は何か？}
    C --> D[能力とタスクの適合性]
    C --> E[コストと利用頻度]
    C --> F[汎化能力と未知の問題への対応]
    C --> G[安全性とプロンプトインジェクションのリスク]
    D --> H[今回のAgentを選ぶ]
    E --> H
    F --> H
    G --> H
    H --> I[役割と権限を設定する]
    I --> J[実行・引き継ぎ・検収]

このマップはユーザーに代わって最終決定を下すためのものではない。その役割は、まず選択肢の範囲を絞り込み、ユーザーが自分自身のタスクでさらに検証できるようにすることにある。特に注意すべきなのは、長時間の agentic コーディングの結果を、日常の対話・執筆・調査における総合ランキングとしてそのまま扱うべきではないという点だ。コストについても計算基準を確認する必要がある。API利用のコストとチャットのサブスクリプション料金は同じものではない。

これはつまり、モデルの役割は一種の作業構成であって、ブランドの本質ではないということでもある。

異なるAgentは同一の作業の中で分業できる

クロスエージェント協働の前提は、すべてのAgentを同じ種類の道具として扱わないことだ。

一つのタスクの中で、Agentは異なる役割を担うことができる。

役割主な仕事
プランナー要件を理解し、タスクを分解し、順序を組み立てる
実行者コードを書き、データを整理し、文書を出力する
レビュアー誤りを見つけ、反例を提示し、抜け漏れを点検する
外部アドバイザー別のシステムやモデルの視点を提供する
統合者結果を比較し、矛盾を処理し、最終的な出力を形成する

同じAgentであっても、異なるタスクでは異なる役割を演じることがある。

たとえば、ある一回のタスクでは次のようなフローを取ることができる。

図6｜同一の作業の中で異なるAgentが担う役割分担

flowchart LR
    H[ユーザーがタスクを出す] --> C[Claude：理解とプランニング]
    C --> X[Codex：実行または修正]
    X --> G[Grok：独立した視点の提示]
    G --> A[Antigravity：点検や拡張の補助]
    A --> C2[Claude：結果の統合]
    C2 --> H2[ユーザー：採用するかどうかの確認]

この図はあくまで役割の例示であり、実際のフローはタスクの内容に応じて決めるべきものであって、同じ経路に固定する必要はない。

ここで本当に問うべきなのは「今のこのステップを担当するのにふさわしいのはどのAgentか」ということだ。

作業が異なる段階に分解されると、Agentの価値はもはや一度きりの回答の質だけでは決まらなくなる。タスクを正しく受け取り、結果を引き渡し、次のAgentが作業を継続できるようにできるかどうかも含まれるようになる。

ClaudeとCodexの双方向操作

現在すでに、より協働に近い関係性を見ることができる。Claudeは提案を出すこともできるし、作業をCodexに渡すこともできる。Codexは独立して実行し、結果をClaudeに戻すこともできる。

このフローは次のように表せる。

図7｜ClaudeとCodexの正方向の引き継ぎフロー

sequenceDiagram
    participant U as ユーザー
    participant C as Claude
    participant X as Codex
    participant I as 統合インターフェース

    U->>I: 作業目標を提示する
    I->>C: Claudeに分析を任せる
    C->>I: タスク分解を報告する
    C->>X: 具体的な作業を引き継ぐ
    X->>I: 実行結果と証拠を報告する
    I->>C: 統合用に結果を提供する
    C->>U: 次のステップまたは確認事項を提示する

逆方向のフローは次のとおりだ。

図8｜実行から分析に戻る逆方向のフィードバックフロー

flowchart LR
    X[Codexが実行中] --> Q[再分析が必要な問題を発見する]
    Q --> C[Claudeに整理を任せる]
    C --> D[Claudeが判断や代替案を提示する]
    D --> X2[Codexが実行を続ける]
    X2 --> U[ユーザーが検収する]

ここでの要点は、タスクが円滑に流動できるかどうかだ。

本当に重要なのは、タスクがあるひとつのツールの中で終わる必要はないということだ。プランニングから実行に入り、実行から分析に戻り、最終的に人間が検収できる結果を形成することができる。

この作業方式は、以前CodexにClaudeをレビューさせた経験の延長線上にもある。あの〈私はcodexにClaudeの誤りを指摘させるが、その言いなりにはならない〉という記事で論じたのは、セカンドオピニオンの独立性をどう保つかということだった。今回はさらに一歩進んで、二つ目のAgentが単にレビューするだけでなく同じワークフローに組み込まれるとき、引き継ぎと権限をどう設計すべきかを扱っている。

また、〈Claude CodeにCodex CLIを借りて画像生成させる〉は、すでに具体的なクロスエージェントの事例になっている。ある作業環境内のAgentが、別のAgentの能力を借りて、単一のツールの中には収まらないタスクを完成させるというものだ。本稿が扱う範囲はそれよりも広く、単一の能力の借用から、一つのインターフェースの中での複数Agentの調整へと広がっている。

一つのインターフェースが担うのは作業のコントロールプレーン

統合インターフェースの重要な役割は、異なるブランドのボタンを一か所に並べることではなく、ユーザーが作業全体の状態を把握できるようにすることにある。

理想的な操作面は、少なくとも次のことを人に見えるようにすべきだ。

図9｜統合インターフェースが示すべき作業状態

flowchart TB
    T[現在のタスク] --> R[現在担当しているAgent]
    R --> P[現在の進捗]
    P --> D[すでに完了した作業]
    D --> N[次に引き継ぐ相手]
    N --> H[人間の確認が必要な箇所]

したがって、統合インターフェースは一種の作業コントロールプレーンとして理解することができる。

図10｜クロスエージェント作業のコントロールプレーンとしての統合インターフェース

flowchart TB
    U[ユーザー]
    I[統合作業コントロールプレーン]
    T[タスクプランニング]
    S[Agent選択]
    P[権限管理]
    V[進捗トラッキング]
    R[結果統合]
    H[人間による検収]
    U --> I
    I --> T
    I --> S
    I --> P
    I --> V
    I --> R
    I --> H

このコントロールプレーンは、異なるAgentの能力を同一の作業文脈の中に置く。

ユーザーはまず自分が何を完成させたいかを説明し、それからこの作業をどのAgentに任せるべきかを決めることができ、「今どのツールを開くべきか」を先に考える必要はない。

これは大きな違いだ。

ツール志向の作業方式は、人間がツールに合わせるものだった。

タスク志向の作業方式は、ツールがタスクに合わせるものになる。

一回のクロスエージェント・タスクの完全なフロー

比較的完全なクロスエージェント・ワークフローは、九つのステップに分けることができる。

図11｜一回のクロスエージェント・タスクにおける九段階のフロー

flowchart TB
    A[1. 要件を入力する] --> B[2. タスクを分解する]
    B --> C[3. 適したAgentを選ぶ]
    C --> D[4. コンテキストと権限を設定する]
    D --> E[5. Agentが実行する]
    E --> F[6. 出力と証拠を引き継ぐ]
    F --> G[7. 別のAgentがレビューまたは拡張する]
    G --> H[8. 統合インターフェースが統合する]
    H --> I[9. 人間が検収し、継続または停止する]

各ステップにはそれぞれの責任がある。

「要件を入力する」が扱うのは目標だ。

「タスクを分解する」が扱うのは作業の順序だ。

「Agentを選ぶ」が扱うのは役割分担だ。

「コンテキストと権限を設定する」が扱うのは境界線だ。

「出力と証拠を引き継ぐ」が扱うのは追跡可能性だ。

「人間の検収」が扱うのは最終的な責任だ。

もしこれらのフローがないまま複数のAgentをただ並べるだけなら、最終的には複数の答えが並んで現れるだけになりかねない。タスク・データ・責任が実際に伝達されて初めて、真のワークフローになる。

Agentの引き継ぎはチャット履歴のコピーだけでは成立しない

クロスエージェント作業で最も起きやすい問題は、チャット履歴をまるごと次のAgentに渡してしまうことだ。

これは一見コンテキストを完全に保持しているように見えるが、必ずしも本当に役立つとは限らない。次のAgentは依然として自分で次のことを判断しなければならない。

  • どの一文がタスクなのか
  • どの一文が背景なのか
  • どの一文が議論の中の単なるアイデアなのか
  • どの内容がすでに確認済みなのか
  • どの内容が一時的な仮定にすぎないのか
  • どの事項は実行してはいけないのか

したがって、Agentの引き継ぎはシンプルな作業契約として整理すべきだ。

タスクの目標：
現在の進捗：
既知のコンテキスト：
利用可能なデータ：
利用不可・外部に出してはならないデータ：
許可された操作：
禁止された操作：
期待される出力：
検収条件：
停止条件：
次の引き継ぎ相手：

この引き継ぎ資料の価値は、次のAgentが作業の境界線を改めて推測する必要をなくす点にある。

より完全な引き継ぎフローは次のとおりだ。

図12｜AgentAからAgentBへの引き継ぎ情報フロー

flowchart LR
    A[AgentA]
    B[タスクの目標を整理する]
    C[既知のコンテキストを整理する]
    D[証拠と要確認事項を明示する]
    E[権限と制約を明示する]
    F[AgentBに引き継ぐ]
    G[AgentBが結果と根拠を出力する]
    H[統合インターフェースに戻す]
    I[人間または別のAgentが検収する]
    A --> B --> C --> D --> E --> F --> G --> H --> I

良い引き継ぎとは、次のステップの作業に本当に必要な情報を伝えることであって、すべてのチャット履歴を丸ごと運ぶことではない。

利便性が高まるほど、権限の境界線はより重要になる

一つのインターフェースで複数のAgentを操作できることは、利用のハードルを大きく下げる。しかしこの利便性は新たな問題も生み出す。

もしAgentが他のAgentを操作できるなら、その権限を誰が決めるのか。

もし一つのAgentが別のAgentを起動できるなら、その権限は際限なく拡大しないのか。

もし複数のAgentが同じデータを見られるなら、どの内容を共有してよく、どの内容は元の作業範囲から出してはいけないのか。

したがって、クロスエージェント・ワークフローは「できるかどうか」を確認するだけでなく、「どこまで許されるか」も処理する必要がある。

権限はいくつかの階層に分けることができる。

図13｜情報の閲覧から対外的な行動へと段階的に近づく権限

flowchart TB
    A[情報を閲覧する] --> B[情報を分析する]
    B --> C[提案を出す]
    C --> D[作業内容を修正する]
    D --> E[外部操作を実行する]
    E --> F[ユーザーに代わって対外的に行動する]
    F --> H[人間の確認]

対外的な世界に近づくほど、人間の確認がより必要になる。

たとえば、以下の事項はワークフローが円滑だからといって、そのまま自動で完了させるべきではない。

  • アカウントへのログイン
  • 個人データの使用
  • 機密情報の読み取りや伝達
  • APIキーの使用
  • 対外的なメッセージの送信
  • 支払いの実行
  • コンテンツの公開
  • ウェブサイトのデプロイ
  • 不可逆な削除や変更の実行

統合インターフェースはこれらの操作を一か所に集約できるが、集約することは野放しにすることとイコールではない。

インターフェースは、今どのAgentが作業しているか、それがどの権限を使っているか、そして次の動作に本人の確認が必要かどうかを、ユーザーにより明確に見せるべきだ。

Agentの数が増えても、判断の信頼性が上がるとは限らない

複数のAgentは異なる視点を見つける助けにはなるが、数そのものが自動的に正しい答えを生み出すわけではない。

それらは同じ誤った前提を共有していることもあれば、同じコンテキストのために似たような誤った結論に一緒にたどり着くこともある。

したがって、クロスエージェント協働では次の三つのものを区別する必要がある。

図14｜元データ・Agentの分析・人間の判断の階層

flowchart TB
    A[元データ] --> B[Agentの分析]
    B --> C[ユーザーまたは別のAgentの判断]
    A -. 出典を必ず保持する .-> C

この三つを混同してはならない。

引き継ぎの際には、次の点を明示するのが望ましい。

  • どの内容がすでに確認済みか
  • どの内容が元データに由来するか
  • どの内容がAgentの推論か
  • どの内容がまだ未検証か
  • どの内容が単なる暫定的な方向性にすぎないか

これが、私が「複数のAgentが同意している」ことをそのまま証明として扱わない理由でもある。

合意は確信を高めることはできるが、証拠に取って代わることはできない。

統合インターフェースにも失敗時の退路が必要だ

成功パスしかないワークフローは、まだ完全とは言えない。

クロスエージェント協働は、さまざまな場所で中断しうる。あるAgentが使えない、権限が不足している、コンテキストが不完全である、出力フォーマットが合わない、外部サービスが応答しない、あるいは異なるAgentが同じ問題について互いに矛盾する判断を下す、といった具合だ。

したがって、フローの中にはあらかじめ退路を用意しておくべきだ。

図15｜Agentが失敗したときの修正・転送・人間による引き取り

flowchart TB
    A[Agentが実行する] --> B{結果は検収条件を満たしているか？}
    B -->|はい| C[次のステップに渡す]
    B -->|いいえ| D{問題は修正可能か？}
    D -->|はい| E[元のAgentに戻して修正する]
    D -->|いいえ| F[別のAgentにレビューを任せる]
    F --> G{人間の判断が必要か？}
    G -->|いいえ| C
    G -->|はい| H[停止してユーザーに戻す]

この設計には一つ重要な意味がある。Agentが失敗したとき、システムはその失敗を明確に表示すべきであり、フローが順調に見えるようにするためにタスクの目標をこっそり変えたり、検収基準を下げたりしてはならない。

ユーザーにとって、「今ここで私の判断が必要だ」ということ自体が、一つの有効な結果なのだ。

複数モデルの利用から、クロスエージェントの作業システムへ

Claude、Codex、Antigravity、Grokの存在は、私たちがタスクに応じて異なるAgentを配置できるようにしてくれる。

さらに注目すべきなのは、これらのツールがどのようなシステムの中に置かれているかということだ。

成熟したクロスエージェント作業システムは、次のものを備えているべきだ。

図16｜成熟したクロスエージェント作業システムの中核構成

flowchart TB
    A[統合インターフェース] --> B[明確なタスク分解]
    B --> C[明確な役割分担]
    C --> D[追跡可能なAgentの引き継ぎ]
    D --> E[制御された権限の境界線]
    E --> F[検収可能な出力]
    F --> G[人間による判断の保持]

このシステムの中心は、依然として人間である。

人間はすべてのステップを自ら完成させる必要はないが、各ステップで何が起きているかを知る必要があり、また重要な箇所では停止と修正の能力を保持しておく必要がある。

私にとって最も価値のある変化は、一つのインターフェースの中で異なるAgentを同じ作業に参加させ、タスクをプランニングから実行へ、さらに点検と統合へと流していけることにある。

人間は自分自身のAgent作業環境を設計し始めている

かつて私たちが問うていたのは、次のことだった。

どのAIが自分に最も適しているか？

今、より問う価値があるのは、次のことだ。

一つのインターフェースの中で、異なるAgentにそれぞれ自分に合った作業を完成させることができるだろうか？

この問いへの答えは、モデルの能力、インターフェースの設計、タスクの引き継ぎ、権限管理、そして人間の判断がどのように組み合わされるかにかかっている。

ClaudeがCodexを操作でき、CodexがClaudeに戻ることができ、作業がさらにAntigravityやGrokにまで広がるとき、AIの使い方はもはや「一つのチャットウィンドウを開いて、一つの答えを待つ」ことだけではなくなる。

私と私の周囲の同じような層の人々は、すでに、人間が方向を定め、複数のAgentが協働して完成させる作業環境の構築を始めている。

・一つのインターフェースがツール切り替えの問題を解決した。 ・クロスエージェントの引き継ぎが作業の流動性の問題を解決した。

そして権限と人間による検収が、このシステムが信頼に値するかどうかを決める。重要なのは、複数のAgentを明確な境界線の中で、同じ一つの作業のためにリレーさせられるかどうかだ。ポストAI時代のすべての働き手は、自分自身の作業スタイルとフローに最も適したシステムを、自ら設計し最適化していく必要がある。