homula社内でAIエージェントが「増えすぎて、誰が何を触っているか分からない」——この"エージェント・スプロール（agent sprawl）"が、2026年後半のエンタープライズAIで最大の運用課題になりつつある。homula がエンタープライズのエージェント導入で一貫して言ってきたのは、「つなぐ」より先に「誰が・何を・どこまでできるか」を設計せよ、ということだった。その論点が、いままさに大手ベンダーの製品戦略の中心に躍り出ている。
2026年10月27日、IBMは年次イベント TechXchange 2026（米アトランタ）で、企業向けエージェント管理基盤 watsonx Orchestrate に関する一連の新機能を発表した。核にあるのは「エージェントに身元（identity）と鍵（credential）を配り、使い終わったら回収する」という、きわめて古典的で、しかしこれまでAIエージェントには欠けていた統制の考え方だ。本稿では発表の要点を事実ベースで整理し、日本企業が設計で押さえるべき勘所を読み解く。
IBMが発表したもの：身元の付与と、短命な鍵の払い出し
今回の発表は複数の構成要素からなる。報道各社の情報を突き合わせると、提供状況（GA＝一般提供／テクニカルプレビュー）は次のように整理できる。
| 構成要素 | 役割 | 提供状況 |
|---|---|---|
| IBM Agent Identity | エージェントに身元（identity）と認可コンテキストを与える | 一般提供（GA） |
| HashiCorp Vault 2.2 | エージェントに短命クレデンシャルを払い出し、自動更新・最小権限を担保 | 一般提供（GA） |
| IDプロバイダ連携 | Microsoft Entra / IBM Verify を人間・非人間（エージェント）双方のIdPとして接続 | 提供 |
| Discover / Contain | 他基盤（例: Amazon Bedrock）上のエージェントを発見し、隔離サンドボックス・キルスイッチで封じ込め | テクニカルプレビュー |
役割分担が明快だ。Agent Identity が「このエージェントは何者で、何を許されているか」という身元と認可の文脈を持ち、Vault が「その身元に対し、必要な範囲の鍵を、必要な間だけ渡す」というクレデンシャル供給を担う。Vault 2.2 ではエージェントごとに専用のセキュア・アカウントが与えられ、クレデンシャルは自動更新され、ポスト量子暗号にも対応するとされる。鍵は"配りっぱなし"ではなく、短命（short-lived）で、使い終われば失効する。
ポイントは「GAされたのは身元と鍵の部分（Agent Identity / Vault 2.2）」で、「他基盤のエージェントを横断的に発見・封じ込める部分（Discover / Contain）はまだプレビュー」ということ。発見・隔離・キルスイッチといった派手な機能はまだ検証段階だと理解しておくと、過剰な期待を避けられる。
なぜ「身元と鍵」なのか——非人間IDという盲点
従来、企業の認証・認可は「人間のユーザー」を前提に積み上げられてきた。だが自律的に動くAIエージェントは、人間の代わりにAPIを叩き、DBを読み、外部SaaSを操作する**非人間の実行主体（non-human identity, NHI）**だ。ここに、見過ごされがちな盲点が3つある。
- 権限が人間に紐づいたまま：エージェントが人間の認証情報やトークンを"借用"して動くと、人間以上の速度と並列度で広範囲に作用してしまう。誰の権限で動いたのかも曖昧になる。
- 鍵が長生きする：長期有効なAPIキーやトークンを埋め込むと、漏洩時の被害が青天井になる。プロンプトインジェクションで鍵を抜かれれば、その鍵が生きている限り悪用され続ける。
- 数が人間を超えてスケールする：エージェントは分単位で生成・複製される。手作業の棚卸しでは、もう追いつかない。
IBMのアプローチは、この3点に正面から答える。エージェント一つひとつに固有の身元を与え（＝人間から切り離す）、鍵は短命にして自動失効させ（＝漏洩の被害窓を狭める）、IdPに統合して発行・棚卸しを自動化する（＝スケールに追従する）。特別に新奇な概念ではない——人間のアクセス管理で長年培われた「最小権限」「短命クレデンシャル」「ID基盤への集約」を、非人間の主体に拡張しただけだ。だからこそ、エンタープライズの運用現場に馴染みやすい現実解になっている。
自律性の高さではなく、「身元と鍵をどう配り、どう回収するか」。エージェント統制の重心は、モデルの賢さから運用の規律へと静かに移っている。
落とし穴：統制点が増えるほど「どこで効くのか」が曖昧になる
一方で、この手の"フルスタック統制"には構造的な注意点がある。身元・認可・鍵・発見・封じ込め・監査……と機能が充実するほど、ポリシーの効き所が複数の製品に分散する。IBMの構成でも、認可はAgent Identity、ID連携はVerifyやEntra、鍵はVault、実行はOrchestrate、さらに全社ガバナンスやゲートウェイ製品……と、ポリシーが載る場所が増える。
統制点が増えること自体は悪くない。問題は「複数のポリシーが矛盾したとき、どれが優先されるのか」が設計で明示されていないと、運用の現場で"誰も把握していない抜け道"が生まれることだ。これは特定製品の欠陥ではなく、統制レイヤーを多層に積むとき普遍的に起きる。重要なのは、分散した統制点の上に**「最終的に効く一枚のポリシー」を誰が握るか**を、最初に決めておくことだ。
これは homula の見立てだが、ベンダーが用意する統制スタックが優れているほど、企業は「自社の統制設計図」をそのベンダーの製品群の中に溶かし込みやすくなる。IBMで固めればIBMの中で、別のクラウドで固めればそのクラウドの中で——気づけば、統制のかたちがベンダー境界に沿って分断されていく。マルチベンダーが前提の日本企業ほど、この分断は効いてくる。
homulaの観点：統制レイヤーは、ベンダー横断で自社が握る
今回のIBMの発表が示すのは、エージェント時代の勝負どころがモデルの賢さではなく「身元・鍵・監査」の運用設計にあるという方向性だ。この認識自体は、homula がエンタープライズ導入で一貫して置いてきた設計思想と重なる。
homula のプロダクト構成はまさにこの層を狙っている。接続基盤である Agens（MCPを活用し、200以上のツールと構築ゼロで接続）が「つなぐ」を担い、Agens Control が「誰が・何を・どこまで」を押さえる——承認フロー・DLP・5年分の監査ログ・RBAC。重要なのは、この統制レイヤーを特定ベンダーのエージェント基盤に閉じ込めないことだ。IBMのエージェントも、クラウド各社のエージェントも、n8n のワークフローも、外部から入ってくるエージェントも、同じ統制レイヤーの上で一元的に扱える設計にしておく。そうして初めて、前節で述べた「ポリシーの分断」を自社の側で束ね直せる。
実務の順序としては、次の進め方が現実的だ。
- 身元から始める：エージェントに人間とは別の固有IDを与え、人間の認証情報の借用をやめる。
- 鍵を短命にする：長期有効なキーの埋め込みを棚卸しし、短命・自動失効のクレデンシャルに置き換える。読み取り系から段階的に。
- 不可逆操作に承認ゲート：金額発生・外部送信・削除など取り返しのつかない操作には、必ず人間の承認を挟む。
- 最初から監査を仕込む：誰が・どのエージェントが・何を・いつ実行したかを、後付けではなく初期設計で記録する。
自社だけで一気に設計するのが難しければ、業務棚卸しからプロトタイプ構築・ROI試算までを3〜5日で回す AIエージェント・ブートキャンプで、小さく検証しながら統制の型を作るのが近道になる。処理時間 93%削減のような成果も、まずは統制の効いた小さな検証から積み上がる。
まとめ：配るかどうかではなく、「誰が鍵束を握るか」
IBMが TechXchange 2026 で示したのは、「AIエージェントにも人間同様の身元管理と鍵管理が要る」という、地に足のついた現実解だった。Agent Identity と Vault 2.2 のGAは、エージェント統制が研究や理想論の段階を過ぎ、既存のアクセス管理の延長線上で今すぐ着手できる運用課題になったことを意味する。
ただし、統制機能が充実するほど、ポリシーの効き所は分散する。最後に問われるのは「どの製品を入れたか」ではなく、分散した統制点の上に効く一枚のポリシーを、ベンダーを横断して自社が握れているかだ。身元と鍵を配る仕組みはベンダーから買える。だが、その鍵束を最終的に誰が握るのかという設計図だけは、自社の手に残しておく——それが、エージェントが社員の数を超えていく時代の、現実的な構えになる。
社内で増え続けるエージェントに、どんな身元と鍵と記録を備えるか。ベンダーに依存しない統制レイヤーの設計を、実行境界の棚卸しから一緒に始めてみませんか。