責任が2回回ったとき、AIは部品から組織になる

たらいが回るのは、失敗ではない。境界が曖昧だという告知だ

「この仕事、誰が持つのか」を決めきれない瞬間がある。人間の組織でも起きるし、AIシステムでも起きる。最初はひとつの役割に見えたものが、実際に動かしてみると、判断、整形、検証、例外処理、再試行のように、いくつもの責任へ分裂する。すると仕事はたらいのように回り始める。

ここで大事なのは、たらい回しを単なる混乱として見るか、それとも新しい境界が必要だというシグナルとして見るかだ。2回まわったなら、それは「担当者が悪い」のではなく、「責任の切り方が間違っている」可能性を示している。役割の線引きが曖昧なままでは、誰も最後まで持てない。

AIのマルチエージェント設計もまったく同じだ。ひとつのモデルに何でもやらせると、出力は一見まとまる。しかし少し複雑になると、構造化、分岐、再評価、監督、修正が必要になる。そこで登場するのが、監督役、パーサー、実行役という分業だ。けれど分業を増やせば解決するわけでもない。たらいが増えるだけでは、責任はむしろ見えにくくなる。

だから本当に問うべきなのは、どの仕事を分けるべきかではない。どこで責任が2回回ったら、そこを新しいポジションとして切り出すべきかだ。これは組織設計の話であり、AIアーキテクチャの話であり、同時に認知の話でもある。

---

ひとつのモデルで全部やると、なぜ破綻するのか

多くの人は、マルチエージェントを「賢いモデルを複数つなげる技術」と考える。しかし本質はそこではない。マルチエージェント化の価値は、知能の増加よりも、責任の分解にある。ひとつのモデルは、質問に答えることはできるが、答えの妥当性を保証する責任、形式を守る責任、失敗時にやり直す責任まで自然に持つわけではない。

たとえば、採用候補者の面接要約を作るAIを考えてみる。単一モデルであれば、会話ログを読んで、要約して、推薦コメントまで一気に書けるかもしれない。だが実運用では、要約文がJSONであること、評価項目が漏れていないこと、ネガティブな表現が過剰でないこと、最終的に人間が判断しやすいことが別々の要件になる。ここをひとつの処理に押し込めると、失敗したときにどこが悪かったのか分からない。

これはソフトウェアの古典的な問題でもある。モノリスは単純に見えるが、少し大きくなると、変更の影響が広がり、障害の原因が追いづらくなる。逆に、境界を切って責任を分けると、各部分は明確になる。だが分割しすぎると、今度は連携コストが増える。つまり設計の本質は、分けることそのものではなく、責任の最小単位を見つけることだ。

役割分担は、効率化のためではなく、失敗の場所を発見するためにある。

この視点に立つと、マルチエージェントの価値は劇的に変わる。複数のエージェントがいるから賢いのではない。複数のエージェントがいるから、どこで迷い、どこで壊れ、どこで修正すべきかが見える。言い換えれば、エージェント設計は知能の設計ではなく、責任の可視化の設計だ。

---

「structured output」は便利機能ではなく、責任の境界線である

ここで重要になるのが、構造化出力だ。多くの人はこれを「JSONを吐かせるためのテクニック」と見なすが、実際にはもっと深い意味を持つ。構造化出力とは、モデルの自由な生成を、機械が扱える責任の形式へ変換することだ。つまり、曖昧な思考を、検証可能な契約に変える。

たとえば、監督役が次のアクションを決める場面を考えよう。自由文で「次はパーサーに回してください」と出すより、next_agent: parser のように形式を固定したほうが、後段の処理は安定する。これは単に実装が楽になるという話ではない。出力の形式を固定した瞬間に、責任の受け渡しが明確になるのだ。

この点で、構造化出力は人間組織の職務記述書に似ている。たとえば営業からカスタマーサクセスへ案件を渡すとき、「いい感じにフォローしてください」では責任が曖昧すぎる。一方で、「顧客名、課題、合意済み事項、未解決事項、次回期限」を埋めて引き継ぐなら、次の担当者はすぐ動ける。AIでも同じで、自由形式の言語だけでは引き継ぎが不完全になりやすい。

ここで見落とされがちな点がある。構造化出力は、モデルを縛るためのものではなく、モデルの自由度を後工程に接続可能な形へ圧縮するためのものだ。むやみに自由度を残すと、後で人間が解釈する負担が増える。逆に、早い段階で形式を決めれば、後続のエージェントやツールが安全に動ける。

形式は創造性の敵ではない。責任を渡すための容器である。

ここで「with_structured_output()を使えば解決するのでは？」という問いは、実はかなり本質的だ。なぜなら、その問いは実装の最適化に見えて、実際には設計哲学を突いているからだ。パーサーを後付けで頑張るのではなく、最初から出力契約を中心にシステムを組むべきではないか、という問いである。

---

2回回ったら新ポジション、これはAIにも人間にも効く設計原則だ

たらいが2回回ったら新ポジション、という発想の強さは、問題を感覚ではなく観測可能なイベントに変えることにある。1回の行き違いは偶然かもしれない。2回繰り返されたら、それは偶然ではなく構造の問題だとみなせる。ここに、実務で使える強いルールがある。

AIシステムに置き換えると、このルールはこうなる。ある処理が2回以上同じ場所を往復したら、その間に独立した責任者を置く。たとえば、生成結果をそのまま次工程へ流すのではなく、1回目は生成、2回目は検証、3回目は修正という流れにする。すると、単なる一発勝負ではなく、役割を持ったループになる。

この考え方は、設計における「新ポジション」の作り方を教えてくれる。人間組織でも、何でも既存メンバーが兼務し続けると、仕事は一応回る。しかし2回以上たらいが回るなら、その責任はもう個人の善意で吸収できない。新しい役割を作るか、明確な引き継ぎルールを設計するべきだ。AIでも、プロンプトを少し調整するだけでは足りず、監督エージェントやパーサーを分離したほうがよい局面がある。

ここで役立つのが、責任境界の三層モデルだ。

1. 生成層: 何かを生み出す。文章、候補、案、仮説を出す。
2. 検証層: 形式、整合性、制約、リスクを確認する。
3. 移送層: 次の担当者やツールが使える形に整える。

多くの失敗は、この三層がひとつに混ざることで起きる。生成と検証が同居すると、出した本人が自分の答えを甘く評価しやすい。移送がないと、正しい答えでも次に渡せない。だから、たらいが2回回った地点は、単なるボトルネックではなく、三層のどこが未分化かを示す発見点になる。

このモデルを使うと、設計レビューの見え方が変わる。問題は「AIは正しいか」ではない。問題は「どの責任が一つの箱に詰め込まれ、そこからこぼれているか」だ。答えが悪いときは、モデルの性能よりも、責任の箱が大きすぎることが多い。

---

マルチエージェントの本当の価値は、組織の学習装置になること

面白いのは、こうした設計が単にエラーを減らすだけでなく、組織が学習する速度を上げることだ。責任が分かれていれば、どこで何が起きたかを観測できる。観測できれば改善できる。改善できれば、同じ失敗を次に持ち越さない。

人間の組織でも、役割が曖昧なときは失敗が「誰かのせい」になりやすい。役割が明確だと、失敗は「どの境界に欠陥があったか」という設計課題になる。AIでも同じで、単一モデルの失敗は、ただの不出来に見える。だが分業されたシステムの失敗は、どのエージェントが、どの入力で、どの形式を壊したかまで追跡できる。

つまり、マルチエージェントは出力品質を上げるだけの仕組みではない。組織の反省を速くするための仕組みでもある。これは重要だ。なぜなら、賢さの差はしばしば「正解率」ではなく、「学習速度」に現れるからだ。失敗を早く局所化できる組織は、次の試行が速い。

良い設計とは、正解を増やすことではなく、誤りが学習に変わる速度を上げることだ。

ここで、構造化出力とポジション設計がひとつにつながる。出力を構造化するのは、単に機械処理のためではない。後から見たときに、どの責任がどこで果たされ、どこで破られたかを辿れるようにするためだ。たらいが回ったという事実は、嫌な現象ではあるが、同時に設計の改善点を教えてくれる最良の計測器でもある。

---

Key Takeaways

• 2回回ったら設計を疑う: 同じ仕事が2回以上たらい回しになるなら、個人の頑張りではなく責任境界の設計問題として扱う。
• 構造化出力は契約である: JSON化は単なる整形ではなく、次工程へ責任を安全に渡すための明示的な契約にする。
• 生成、検証、移送を分ける: ひとつのエージェントに全部やらせず、役割を分離することで失敗点を局所化できる。
• 分業の目的は効率化だけではない: 分けることで、どこで壊れたかが見え、改善速度が上がる。
• 新ポジションは例外ではなく学習の結果: たらいが繰り返し回る場所に、新しい責任者や新しいエージェントを置くのが本当の最適化。

---

結論: AIを賢くするより先に、責任を見える化せよ

私たちはつい、AIをもっと賢くすれば問題は消えると思ってしまう。だが実際には、賢さが増すほど、責任の置き場が曖昧な設計はむしろ壊れやすくなる。なぜなら、何でもできるモデルほど、何をすべきだったのかがぼやけるからだ。

本当に強いシステムは、万能な一人ではなく、責任が明確に渡る複数の役割でできている。たらいが2回回ったら新ポジション、という感覚は、そのままAI設計の核心になる。どこで回り始めたかではなく、どこで止めるべきかを決める。それが、組織にもAIにも必要な成熟だ。

そして最終的に問うべきなのは、こうだ。あなたのシステムは、答えを出しているのか。それとも、責任を渡せる形で世界を理解しているのか。