【geek-terminalニュース】27体のAIエージェントを3体へ削る設計論の最新情報

以前お伝えしたAgentOpsやHarness設計の続報です。今回の焦点は、AIエージェントをどんどん増やして専門部隊化する話ではありません。むしろ逆です。Redditのr/AI_Agentsで「27個のエージェントを止め、3個中心に作り直した」という問題提起が出ており、真偽や詳細な実装はコミュニティ投稿ベースに留まるものの、刺さるポイントはかなり現場寄りです。つまり、本番のAIエージェント運用では、エージェント数を増やすほど賢くなるのではなく、評価不能、権限過多、状態爆発、ログ追跡不能、責任境界の曖昧化が同時に増える、という泥臭い現実です。

【事象の全貌と背景】
今回の議論は、AIエージェントを「役割ごとにたくさん作ればよい」という初期の熱狂への揺り戻しです。営業調査エージェント、要約エージェント、コンテンツ生成エージェント、品質確認エージェント、投稿エージェント、通知エージェント、と分けていくと、デモでは一見きれいに見えます。しかし本番では、どのエージェントがどの失敗を起こしたのか、どの権限で外部システムに触ったのか、どのプロンプト変更が回帰を起こしたのかが急速に見えなくなります。

Reddit上の議論では、27体から3体へ削ったという主張そのものは公式に検証された事実ではなく、コミュニティ発の設計経験談として扱うべきです。ただし方向性は、Microsoftの公式発表とも重なります。Microsoftは2026年9月24日のAzure Blogで、Microsoft Foundryをモデルやハーネスに依存しないエージェント構築・運用基盤として説明し、production tracesを使ってinstructions、skills、tools、model choiceを品質、レイテンシ、コストの観点で継続改善する流れを示しています。特に重要なのは、同社が「Enterprise agents don’t need every document, tool, and procedure in every interaction」と明記している点です。全ツール、全文書、全手順を毎回エージェントに渡すほど、コスト、遅延、予測不能性が増える。これは「27体を3体に削る」話と同じ方向を向いています。

【技術的ディープダイブ】
技術的には、今回のキモは“agentを減らしてtoolを増やす”ことです。エージェントを思考主体として増殖させるのではなく、少数の中核エージェントに、明示的なパイプライン、ツール呼び出し、状態管理、評価ハーネス、権限制御を接続する。コンテンツ生成の例でも、生成器を独立エージェントにするか、既存ワークフロー内の工程にするかが議論されています。入力、草稿、修正、短縮、検査をチャット窓の手作業コピーではなく工程化するなら、それは“人格を持った別エージェント”ではなく、パイプライン上のtoolやstepとして扱う方が監査しやすい、という発想です。

公式に確認できる数値として、MicrosoftのToolboxesはopt-in discoveryとtool-level guardrailsを提供し、Toolboxesのtool searchは一般提供になっています。同社は44,000超のツールと7,000件のクエリを使った内部評価で、50ツール構成では入力トークン消費を60%以上、1,000ツール構成では97%以上削減したと発表しています。比較対象は、全ツールカタログを事前に読み込むprompt-cached baselineです。これはかなり重要です。エージェント数削減の本質は、単に「少人数化」ではなく、「必要な時に必要なツールだけ発見し、呼び、記録する」構造へ移すことだからです。

権限面も同じです。Redditでは「エージェントがやってはいけないことをどう止めるか」という議論が起きていますが、ここも公式側の方向性は明確です。Microsoft Foundry agentsはMicrosoft EntraとAgent 365から来るblocking、disabling、deleting、restoring、owner assignmentなどの操作をFoundry runtimeで強制すると説明されています。さらにNetwork egress controlsは、ホスト型エージェントがアクセスできる送信先をallow/deny rulesで制御し、outbound headersの変更、リクエストのリダイレクト、監査モード、Azure Application Insightsへの判断記録を提供します。つまり「エージェントに止まれとプロンプトで頼む」のではなく、ネットワーク、ID、ランタイム、監査ログ側で止める設計です。

評価についても、プロンプト修正だけでは足りません。Microsoftはopen-source run-assert-eval Skillを発表し、Clarity、ASSERT、Agent Control Specificationを順に動かして、リスクの表面化、測定可能な評価、失敗箇所へのtargeted runtime controlsを行うと説明しています。ASSERTのGitHubでは、LiteLLM経由で100以上のモデルエンドポイントをテストでき、OpenInference統合によりLangGraph、CrewAI、OpenAI Agents SDK、DSPy、LlamaIndex、AutoGen、Python callable、hosted modelなどを評価できるとされています。さらに危険なアクションをDocker sandbox内で試し、ツール呼び出しをpass/mock/blockし、直接インターネットアクセスを拒否し、試行行動と監査済みegressを保存できる。これは、失敗を“雰囲気で反省”するのではなく、再現可能な評価、ポリシー、再測定へ落とす流れです。

【コミュニティの生々しい熱量と議論】
コミュニティ側の空気はかなり実務的です。Redditの主題は、華やかなマルチエージェント劇場ではなく、「増やしすぎた結果、誰も全体を評価できない」という痛みです。別スレッドでは、evalが失敗を捕まえた後に何をするのか、しきい値や検出条件がプロンプト散文に埋もれると監査不能になるのではないか、という問題意識が共有されています。ここが本当においしいところで、失敗検知はゴールではなく、失敗モード分類、再現テスト、状態管理、権限縮小、回帰テストへ接続して初めて運用になります。

検索結果に含まれるHN側の反応は直接このReddit投稿だけへの反応ではありませんが、AIエージェントを実務で使う温度感をよく表しています。あるユーザーは「AI agent that I use every day at work would rather install a tool or library than spend tokens recreating software」と述べ、エージェントが何でも自前で考えるより、既存ツールを使う方が自然だとしています。これは今回のtool化論と相性が良い声です。別のユーザーは、AIのおかげでopen source Frigateを自分の環境に合わせて改造できたとし、「time」が最大の障壁だったと語っています。一方で、AIによってオープンソースが爆発するという楽観には、「most of them low quality slop」という冷めた反論もあります。つまり熱量は二層です。AIは既存ソフトウェアやツールを使う能力を広げる。しかし、雑にエージェントやプロジェクトを増やすと、低品質な残骸も増える。この矛盾が、まさに今回の「削る設計」へつながっています。

【今後の展望とエコシステムへの影響】
今後オワコン化しそうなのは、“エージェントを増やせば賢く見える”タイプのデモ設計です。専門名をつけたエージェントが大量に会話し、最終的にそれっぽい出力を出すだけでは、本番の評価、権限、コスト、監査に耐えません。逆に価値が上がるのは、少数の中核エージェント、オンデマンドtool discovery、tool-level guardrails、egress制御、Docker sandbox、production traces、回帰評価、ポリシー再適用を束ねるAgentOps基盤です。

パラダイムシフトは、AIエージェントを“賢い同僚の群れ”として設計する段階から、“制御された実行基盤の上で動く判断ループ”として設計する段階への移行です。3体に削る、という数字そのものが本質ではありません。本質は、推論主体を増やさず、能力をtool、pipeline、policy、eval、runtime controlへ分解することです。プロンプトは仕様書ではなく、監査可能な制御面の一部に下がっていく。エージェントは万能労働者ではなく、制限された権限、観測可能なログ、再現可能な失敗、測定可能な改善ループの中で初めてプロダクトになります。

今回の続報は、AgentOpsがいよいよ“かっこいい自律性”から“地味な運用工学”へ降りてきたサインです。27体を3体へ、というコミュニティ発の言い方は少し乱暴ですが、示している方向は鋭い。これからの勝ち筋は、エージェントを増やすことではなく、エージェントに持たせるべきでない判断、権限、手順、ツール一覧をどれだけ外へ追い出せるかにあります。