homulaAIエージェントの議論は、この1年で「作れるか」から「運用できるか」へ急速に軸足を移しました。homula がエンタープライズの現場で繰り返し見てきたのも、PoC が通った後に本番で崩れるのはモデルの賢さではなく、権限とコストの設計だという事実です。そして2026年10月27日、その現実を裏づける二つの出来事が同じ日に起きました。
同じ日に起きた二つのこと——“関所”を敷いたベンダーと、権限を剥がした企業
一つは製品側の動きです。Salesforce は同日、エージェント運用基盤 Agent Fabric を拡張し、コスト制御と**評価（Evals）**の機能群を発表しました（Salesforce / VentureBeat）。訴求の中心は「暴走するコストとエージェントの失敗を、顧客に影響する前に止める」こと。すでに提供されているのは FinOps ダッシュボード、支出を束ねる Model Wallet、コストポリシー、そして予算超過前にリクエストを止める Agent Kill Switch（キルスイッチ） です。
もう一つは需要側の現実です。ID セキュリティ企業 Frontegg が同じ10月27日に公表した調査は、**78%の CISO/CSO が「本番で動いているAIエージェントから、すでに権限を剥がした経験がある」**と回答したと報じました（PR Newswire / SecureWorld）。調査は従業員500人以上の米国企業の CISO/CSO 300名を対象に、独立調査会社 Cint が9月24〜27日に実施したものです。
つまり、ベンダーが「本番で止める仕組み」を製品化し始めたのと、企業が「本番で過剰だった権限を慌てて絞り始めた」のが、同じタイミングで表面化した。これは偶然ではなく、エージェント運用が Day2（本番運用）の問題へ移ったことの表れです。
なぜ本番で権限は過剰になるのか——スコープ設計の不在
Frontegg の調査は、権限剥がしが「例外対応」ではなく常態であることを示しています。同調査では、**49%が「本来持つべきでないアクセス権を持ったエージェントを本番で発見した」**と答え、**タスクに応じてアクセス権を絞っている企業はわずか37%**にとどまりました。さらに、**エージェント起因のインシデントの責任をセキュリティ部門が負う企業は48%ある一方、エージェントそのものを所有・管理しているのは23%**という、責任と権限のねじれも浮かびます。
同じ方向を指す調査は他にもあります。Saviynt の「2026 CISO AI Risk Report」では、92%のセキュリティ責任者が自社のエージェントIDを完全には可視化できておらず、95%が侵害されたエージェントを検知・封じ込められるか疑わしいと回答したと報じられています（beri.net）。VentureBeat の別調査でも、権限を強制していると答えたチームの多くが依然として認証情報を共有しており、数分以内にアクセスを失効できる企業は少数でした（VentureBeat）。
過剰権限が生まれる構造はシンプルです。PoC では「とりあえず動かす」ために広い権限を付与しがちで、本番移行時にそれを**タスク単位まで絞り直す工程（スコープ設計）**が抜け落ちる。結果として、人間なら絶対に渡さない範囲のアクセスが、エージェントには暗黙のうちに残ります。
「止める」「測る」「絞る」——実行時統制の3層
今回の二つのニュースを重ねると、本番でエージェントを御すための要素が見えてきます。homula はこれを実行時統制の3層として整理しています。
| 層 | 問い | 具体的な仕組み | 今回の対応 |
|---|---|---|---|
| 止める | 暴走を即座に遮断できるか | キルスイッチ、支出ハードリミット、承認ゲート | Salesforce の Agent Kill Switch / Model Wallet |
| 測る | 品質と逸脱を継続的に検知できるか | 本番評価（Evals）、監査ログ、可観測性 | Salesforce の Agent Evals / API Evals |
| 絞る | 権限をタスク最小にできるか | RBAC、最小権限、ID のライフサイクル管理 | 企業側の「権限剥がし」= 事後対応 |
注意したいのは、Salesforce の評価駆動の自動停止はまだ出荷されていない点です。Agent Evals と API Evals はベータが11月、一般提供は2027年1月の予定で、「評価に失敗したら自動で止める」自動化はロードマップ上の機能にとどまります（VentureBeat / Superpower Daily）。評価の中身としては、Agent Evals はデプロイ前にテストを自動生成し、本番でエージェント・LLM・MCP サーバーを品質しきい値に照らして評価、API Evals は API 仕様から機能・性能テストを生成して破壊的変更を本番前に捕捉する設計です。
重要なのは、この3層は特定ベンダーに閉じた話ではないということ。Salesforce のエコシステム内なら Agent Fabric で完結しますが、現実の企業は n8n・Dify・各社の SaaS・自前実装が混在します。層の設計思想を、マルチベンダーの横断基盤として自社に敷けるかが勝負どころです。
コストも“実行時”の統制対象になった
もう一つの示唆は、コストがセキュリティと並ぶ「実行時の統制対象」になったことです。Salesforce は FinOps ダッシュボードと Model Wallet で支出を可視化・上限化し、エージェントの MCP/API 呼び出しに Flex Credit を課金する方向を示しています（Salesforce Ben）。
常時稼働・長時間稼働するエージェントは、1リクエストの単価が小さくても、呼び出し回数 × トークン × ツール連携で容易に想定を超えます。「止める」に支出ハードリミットが含まれるのはこのためで、品質の暴走とコストの暴走は、同じ実行時ゲートで同時に扱うべき問題です。homula でも、エージェント導入の費用対効果を測る際は、モデル費だけでなくツール呼び出しと自律実行の累積まで織り込んだ原価設計を前提にしています。
homula の観点：スケール前に“実行時の関所”を敷く
78%という数字が示すのは、多くの企業が「本番に出してから」権限を剥がしているという順序の問題です。あるべきは逆で、スケールさせる前に実行時の関所を設計しておくこと。homula はエンタープライズ向けの AIエージェント・インテグレーターとして、ここを一気通貫で支援します。
- スコープ設計を上流に：AIエージェント・ブートキャンプ（3〜5日）で業務を棚卸しし、各エージェントを「どのタスクに、どの権限で」を定義してから本番に進めます。事後の権限剥がしを前提にしない設計です。
- 実行時の関所を標準装備に：Agens Control は承認フロー・DLP・5年分の監査ログ・RBAC を提供します。前述の3層でいえば「止める（承認ゲート）」「測る（監査ログ）」「絞る（RBAC）」を、特定ベンダーに依存しない横断レイヤーとして敷けます。
- 200以上のツールへゼロ構築で接続：Agens は MCP を活用し、200以上のツールと構築ゼロで接続します。接続の広さと統制の強さはトレードオフにしない——つなぐと同時に、誰が・何を・どこまでを定義する前提です。
MCP でのツール接続を安全に広げる設計は、エージェントのツール単位の承認ゲートやAIエージェントに最小権限を与える非人間アイデンティティの考え方、コスト面ではAI支出のガバナンスもあわせて参照してください。
まとめ
2026年10月27日の二つの出来事は、エージェント運用の論点が**「賢さ」から「運用の御し方」へ**移ったことを示しました。Salesforce が実行時のコスト制御とキルスイッチを製品化し、企業の78%が本番で権限を剥がしている——この対比が示す教訓は明快です。止める・測る・絞るの3層を、スケール前に、ベンダー横断で設計しておくこと。権限の剥がし直しや、評価の自動化待ちを「本番で」やることになる前に、関所の場所を先に決めておくのが、Day2を乗り切るエージェント統制の設計です。
まずは自社のエージェントが「どのタスクに、どの権限で、いくらで」動いているかを棚卸しするところから。実行時の関所をスケール前に敷く設計を、homula が伴走します。