何が起きたか

Intuitはエージェント型AIの先行企業ですが、その道のりは直線ではありませんでした。同社はエージェントの設計思想を約4カ月で2度作り直しています。最初は個別タスクに特化した「専門エージェントの群れ」から、タスクを内部で振り分ける中央オーケストレーション層へ移行。しかしそのオーケストレーターが自らの複雑さで破綻し始めたため、今度はそれを捨てて「スキルとツール」を組み合わせる方式へと切り替えました。2度目の再構築は60日で完了し、最初に動くバージョンは20日未満で仕上がっています。

なぜオーケストレーターは壊れたか

専門エージェント方式が生まれたきっかけは、顧客からの不満でした。エージェントが複数あっても「どのタスクにどのエージェントを使うか」を顧客自身が選ばねばならなかったのです。Intuitは、顧客に選ばせずタスクを内部で振り分ける仕組みで応えました。

この中央オーケストレーション層は約3カ月持ちこたえましたが、破綻の理由は処理能力ではなく構造にありました。オーケストレーション方式では、エージェント同士が結果を自然言語で受け渡します。Ho氏は「10個のエージェントが互いに受け渡すと、その受け渡しのたびに誤りが増幅する」と語りました。1回の受け渡し（ホップ）ごとにコンテキストが欠落し、誤差が積み重なっていくのです。

説得と作り直しの実務

退役対象の専門エージェントは、Ho氏のチーム外にいる数百人のエンジニアが作ったものでした。彼らへの依頼は「自分のエージェントを個々のスキルとツールに分解してほしい」というものです。説得材料はスケールでした。単体エージェントは狭い問題を1つ解くだけですが、共有可能なスキルやツールは、その機能に触れるすべての顧客に効きます。経営層の承認を得るためには、本番環境から取り出した実際の顧客クエリで新方式のデモを組み、既存システムより高い性能を示しました。

この転換で、パートナーチームの焦点は「エージェントを作る」ことから「評価（eval）を回す」ことへ移りました。新方式が機能しているかを測る手段は、もはや評価しかなかったからです。

💼 事業会社視点：これは自社にどう効くか

この事例は、日本企業のAIエージェント内製プロジェクトに直接刺さります。多くの現場が「業務ごとに専門エージェントを並べ、上位で振り分ける」設計に飛びつきますが、Intuitは同じ構成が構造的に壊れることを示しました。エージェント間を自然言語で連携させるほど、ホップごとに文脈が落ち誤差が積み上がる——SaaSや受託開発でマルチエージェントを提案・構築する立場なら、この一点は設計レビューの必須チェック項目です。役員が問うべきは「何個のエージェントを作ったか」ではなく「連携の受け渡し回数はいくつか」。打ち手は、機能を顧客ごとに再利用できる共有スキル／ツールへ分解し、KPIをエージェント数から評価（eval）の網羅性へ移すこと。Intuitですら中央方式を約3カ月で捨てた事実は、初期アーキテクチャに固執せず60日で作り直せる体制と権限設計を先に用意しておく重要性を物語ります。人手引き継ぎや操作の許可・監査ログといった信頼設計も、金融・EC領域では先送りできません。