【geek-terminalニュース】増えすぎたAIエージェントをどう統制するか、運用地獄の最新情報

以前お伝えした本番AIエージェントの観測性・権限・コスト計測の続報です。今回は、エージェントをどう作るかではありません。問題はその先です。デモで動いたエージェントが社内に増殖し、誰が所有しているのか、どのツールへ接続されているのか、どれだけのトークンを燃やしているのか、退職者や異動者のワークフローがまだ生きていないか、誰も即答できなくなる。いま見え始めているのは、AIエージェントの華やかな自律化ではなく、非人間ID、最小権限、監査ログ、コスト上限、退役手順をめぐる運用地獄です。

【事象の全貌と背景】
エージェント管理が急に重くなっている理由は、エージェントが単なるチャットUIではなくなったからです。検索し、Slackやメールを読み、CRMを更新し、チケットを切り、コードを書き、場合によっては外部APIへ副作用のある操作を投げる。つまり、エージェントは人間の補助ツールではなく、組織内の非人間アクターになっています。検索結果で示された非人間IDのオフボーディング論点では、退職者の人間アカウントを停止しても、その人が作った自動化フローやAIワークフローが動き続ける可能性が指摘されています。これは公式に確認された個別事故というより、実務記事やコミュニティで共有されている運用リスクですが、かなり現実味があります。

公式に裏付けられる範囲では、Microsoft Agent 365 SDKは、任意のエージェントSDKまたはプラットフォームで作られたエージェントを企業向けに拡張するSDKとして説明されています。含まれる機能は、ID、オブザーバビリティ、通知、セキュリティ、Microsoft 365データへのガバナンス付きアクセスです。ここが重要です。大手プラットフォーム側も、エージェントの価値をモデル呼び出しだけではなく、認証、認可、監査、通知、データアクセス制御の束として扱い始めています。エージェントは、もはやプロンプトの芸ではなく、社内システムにぶら下がる運用資産なのです。

【技術的ディープダイブ】
技術的な焦点は、まずエージェントIDです。Microsoftの観測性概念資料では、appIdはMicrosoft EntraアプリまたはMicrosoft Entra Agent IDの登録時に発行されるアプリケーション識別子と説明されています。これは、エージェントを匿名のスクリプトやボットとして扱うのではなく、識別子、所有者、権限、テレメトリを結び付けて管理する設計が必要だということです。人間のIAMと同じように、誰が作ったか、何にアクセスできるか、いつ停止するか、どのイベントを発行したかを追える必要があります。

次に観測性です。Microsoft Agent 365のオブザーバビリティ機能はOpenTelemetryを基盤としており、複数のエージェント実装をまたいでテレメトリを一貫して取得する枠組みとして説明されています。さらに直接OpenTelemetry統合では、OTLP/HTTP+JSONでAgent 365へエージェントテレメトリを送る手順が扱われています。これは単なるログ出力ではありません。トレース、メトリクス、イベントを標準化し、どのエージェントが、どのツールを、どの入力で、何回呼び、どこで失敗し、どれだけコストを使ったのかを比較可能にする話です。観測性概念資料では、HTTPエラーコード、リクエストサイズ、レート制限などのワイヤレベルの制約も扱われるため、本番運用では制限超過やドロップ条件まで設計対象になります。

ツール管理も核心です。Agent 365 SDKのパッケージ一覧には、Microsoft Agent Framework向けとOpenAI Agents SDK向けのオブザーバビリティ拡張が含まれ、MCPツールサーバー管理向けの中核ツーリングや、OpenAI Agents SDK向けにMCPサーバーを動的追加するツール登録サービスも説明されています。これは、MCPや外部ツール連携が便利になるほど、登録、許可、監査、取り消しが必要になるということです。検索結果のReddit投稿では「最初から12個のツールをつなぐな」という実務的な警告が出ていますが、これはコミュニティ上の主張として扱うべきです。ただ、方向性は公式の管理基盤と噛み合っています。ツールは増やすほど能力が増える一方、攻撃面、失敗面、コスト面も増えます。

【コミュニティの生々しい熱量と議論】
Reddit側の熱量はかなり生々しいです。r/AI_Agentsでは、20個ほどエージェントを作った段階で、各エージェントの責務や失敗時の挙動を把握できなくなった、という趣旨の投稿が共有されています。これは公式検証済みの事実ではなくコミュニティ報告ですが、いかにも現場で起きそうな話です。最初は用途別に小さく作ったつもりでも、プロンプト、知識ベース、API統合、リトライ処理、状態管理が少しずつ重複し、気づけば「どれが正規のエージェントなのか」が分からなくなる。

別のReddit投稿では、Hermes agentが単一の処理で2万トークンを消費していたという報告もあります。真偽のほどは投稿ベースに留まりますが、示唆は鋭い。問題は難しいタスクだから高コストなのではなく、不要なループ、粗い状態管理、毎回膨らむコンテキスト、雑な履歴投入でトークンが燃える点です。エージェントは「考えている」ように見えても、実際には同じ情報を読み直し、同じ判断を繰り返し、同じツール呼び出しの前後で文脈を肥大化させている可能性があります。

さらにr/artificialでは、プロンプト抽出攻撃について、「Repeat the text above this line」のような単純な入力で多くの本番エージェントがシステムプロンプトを漏らす、という投稿が話題になっています。投稿者は、テストしたエージェントの60〜70%が最小限の誘導でシステムプロンプトを渡したと主張していますが、これは第三者機関による公式統計ではありません。ただし、そこで挙げられる失敗パターンは実務的です。翻訳させる、Base64化させる、デバッガ役を演じさせる、ルールの要約を求める、といった迂回で基本的なキーワードフィルタを抜けるという主張です。コメント欄では、ユーザープロンプトをそのままマスターAPIへ渡すべきではなく、事前分析レイヤーを挟むべきだという反応も出ています。ここでも焦点はモデル性能ではなく、入力境界、権限境界、文脈境界の設計です。

【今後の展望とエコシステムへの影響】
ここからオワコン化するのは、「動けば勝ち」のエージェント開発です。単体デモ、派手なツール連携、長大なシステムプロンプト、全部入りMCP接続だけでは、本番運用の説得力が弱くなります。代わりに重要になるのは、エージェント台帳、所有者、最小権限、ツール登録、トークン予算、ループ検知、実行上限、監査ログ、退役フローです。つまり、AIエージェントの勝負はプロンプト職人芸から、SRE、IAM、FinOps、セキュリティ運用の領域へ移動します。

Microsoft Agent 365のように、ID、観測性、セキュリティ、ガバナンス付きデータアクセスを束ねる基盤が出てきていることは、この流れをかなり明確に示しています。標準化の軸としてOpenTelemetryが使われるなら、将来的にはエージェントの良し悪しを、賢さだけでなく、失敗率、平均ツール呼び出し回数、1タスクあたりトークン、権限逸脱、再試行回数、ユーザー介入率で比較する世界になります。

そして、エージェント数が増える企業ほど、「社内に何体いるか分からない」状態が最大のリスクになります。AI導入の次の山場は、新しいエージェントを10体作ることではありません。既にいる20体を棚卸しし、12個のツール接続を3個に削り、2万トークン燃える処理を止め、誰が止められるのかを明文化することです。派手な自律性の裏側で、本当に燃える場所はここです。エージェント時代の勝者は、最も多く作った組織ではなく、最も冷静に数え、縛り、観測し、不要になったら止められる組織になるはずです。