01同僚はいる。会話がつながらない。
コードを書くAIがいる。それを点検するAIもいる。別の画面では、もう一つのAIが次の仕事を進めている。ひとつずつ見れば、ずいぶん頼もしい。だが、その間で何が起きているかを見ると、景色が変わる。
こちらの結果を、あちらに伝える。あちらの指摘を、こちらに戻す。止まった処理を見つけて、続きを促す。人間の仕事は減ったはずなのに、伝言の件数は増えている。
10月19日のインタビューでJCが語ったのは、この隔たりだった。彼の開発環境では、複数のAIをコマンドライン経由でつなぐ試みはすでに進んでいる。それでも、やり取りを始めるきっかけや、返答を次の仕事へ戻す場面に、人の介在が残る。目指しているのは、異なる提供元のAIが、仕事の途中で直接相談し合える状態だ。
これは、返事を少し速くするだけの話ではない。人間が一度席を外しても、必要な問いが必要な相手へ届くか。その問いに答えが来たとき、仕事が続きを取り戻せるか。リアルタイムという言葉の中には、会話が仕事の流れから切れない、という要求がある。
02ひとつに揃えると、失うものがある。
JCがこだわるのは、それぞれのAIが使っている純正の開発環境を生かすことだ。共通の仕組みへ載せ替える方法だけを考えているのではない。
AIが仕事をする環境には、モデルへ質問を送る以上のものがある。ファイルを読んだり、処理を実行したり、途中の状態を持ち越したりするための道具と手順だ。こうした足場は、ハーネスと呼ばれる。JCは、それぞれのモデルと純正環境の結びつきに価値を見ている。
接続のために全員を同じ箱へ入れれば、箱の中のルールは揃う。しかし、もともと得意だった働き方まで平らにしてしまわないか。彼が探っているのは、各環境の強みを残したまま、その間をつなぐ道である。
会社でも、部署を統合すれば協働が始まるとは限らない。開発環境を統一することと、仕事をつなぐことも、同じではないのだろう。ここで必要なのは、優秀な道具の品揃えに加え、道具同士が何を受け渡すかという設計だ。
03もう一度読む。同じ目ではなく。
では、なぜ複数のAIが必要なのか。ひとつのモデルに、実装もレビューも任せれば済むのではないか。
JCの答えは、日々の開発で得た観察にある。同じモデルでも、セッションを変えてレビューさせれば厳しい指摘が出る。それでも、隣で別のモデルに見直させると、違うレビューになることがあるという。
重要なのは、毎回どちらかが勝つことではない。最初の読み手が見ていなかったものを、次の読み手が見ることだ。
この経験だけで、複数モデルの方が常に正確だとは言えない。別の指摘が出ることと、その指摘が正しいことは別だからだ。それでも、同じ対象への視線が変わるという発見は、設計の出発点になる。違いを消して扱いやすくするのか。違いを残して、その食い違いを仕事に使うのか。
協働の価値は、全員の答えが揃った瞬間だけにあるとは限らない。
04仕事を続ける役と、手を動かす役。
違いは、レビューの内容だけに現れるわけではない。JCの運用では、確認を求めて止まる場面の多い環境と、長い処理の反復を続けやすい環境がある。そのため、あるAIのセッションを、別のAIに進行管理させる構想が生まれた。
ただし、長く動けばよいわけでもない。使い続ければ、トークン消費や利用枠が効いてくる。継続性、並列性、費用。何を誰に任せるかは、ひとつの性能指標では決まらない。これらは彼の現在の環境での観察であり、各製品の固定的な性格を決めつける話でもない。
経営の言葉に置き換えるなら、専門家を採用した後に残る問題に近い。誰が手を動かすのか。誰が全体の進み具合を見るのか。仕事が止まったとき、誰がその理由を引き受けるのか。
この問題に対し、業界もいくつかの入口を用意している。MCPは、AIが外部の道具や情報を利用する接続を共通化する。A2Aは、独立したエージェント同士が仕事を依頼し、状態や成果物を受け渡すための仕組みだ。後者では、相手の内部をすべて同じ設計に揃える必要はない。それぞれの仕事場を残してつなぎたい、という発想と重なる。1
ただ、接続口の名前だけでは、何を引き継げるかは分からない。たとえばClaude CodeをMCPサーバーにする機能が公開するのは、そのツールだ。Claudeの会話や自律的な進行まで、丸ごと相手へ渡すという意味ではない。2
一方、OpenAIはCodexの仕事をプログラムから動かすSDKを提供し、会話履歴、承認、進行中のイベントまで扱う統合にはapp serverを案内している。3 ここで見えてくるのは、モデルへの問い合わせを共通化する道と、すでに仕事をしているエージェントを、その状態ごと接続する道の違いだ。JCの関心は、後者に近い。
先行事例もある。Anthropicが公開したResearchの仕組みでは、リード役が調査を分け、複数のサブエージェントが並列に探索する。ただし、同社は、互いへの依存が大きいコーディング作業などでは同じ方式が当てはまりにくいとも説明している。4 分ければ速くなる仕事と、分けるほど調整が増える仕事がある。調査を束ねる成功例を、そのまま共同開発へ移すことはできない。
CIOが確かめたいのは、対応プロトコルの一覧だけではない。どの前提で考え、どの版のファイルを見て、何を試したのか。それを次の担当が受け取れるか。レビューの指摘は変更と再検証まで戻ってくるか。返事がないとき、処理中なのか停止なのかを判別し、二重実行を避けられるか。標準が用意する通信や状態の表現を、自社の仕事の意味に結びつける設計が残る。
経営から見れば、その設計に投資する理由は、人間の調整負担をどこまで減らせるかにある。AIの稼働時間が増えても、人の付き添い時間まで増えるなら、働き方はまだ変わり切っていない。会話できるAIと、一緒に仕事を終えられるAIの間には、この距離がある。
前回の『Inside the Geek』では、AIにとって仕事の「完了」がどこにあるのかを考えた。今回は、その手前にある問いだ。仕事を終わりまで運ぶために、複数のAIの間で、何が途切れてはいけないのか。
05自律性には、役割がいる。
この必要性が具体的になったのが、JCが進めるセキュリティ検証の設計だった。
弱点を探るレッドチームと、防御を担うブルーチーム。その間に、両者の連携を担うパープルチームの役割を置く。彼の構想では、何を試すかの判断、実行前の確認、実際の処理、検証結果を防御側へ渡す仕事を、一続きの仕組みとして考える。
そこで、判断するAIと、実行を担うプログラムを分ける発想が出てくる。さらに、複数の処理を動かす能力と、その全体を継続して進める能力も、同じ担当へ押し込まない。どこで何を確かめ、どの条件で先へ進めるのかを、役割の間に置く。
これは完成したシステムの報告ではない。インタビュー時点では、異なるモデルをまたぐ協働へ向けた設計の途中だ。だからこそ、興味深い。AIが勝手に働く未来を語るときには省かれがちな、仕事の継ぎ目が見えるからである。
AIを増やすことは、次第に簡単になっていく。だが、増えたAIがひとつの仕事を進めるには、誰が何を知り、誰に問い、何をもって次へ渡すかを決めなければならない。
人間が伝言係を降りる日、そこに必要なのは、もう一人の天才だろうか。それとも、天才たちが一緒に働ける場所だろうか。