エンタープライズのAI導入は、この1年で「モデルを選ぶ」から「エージェントを作る」へ、そしていま「増えたエージェントをどう管理するか」へと重心を移しつつあります。作るための基盤——AWS Bedrock、Google Vertex、Microsoft Copilot Studio、Salesforce Agentforce、Snowflake Cortex——はどれも整いました。ところが、それぞれの基盤で作られたエージェントを横断してひとつの台帳に載せ、リスクで並べ、危ないものを止める層は、これまで製品として存在しませんでした。2026年9月24日、その空白が「エージェント管理（Agent Management）」という名の製品カテゴリとして立ち上がりました。homula は普段から「機能を載せる前に統制の器を作る」順序を勧めていますが、今週の動きはその器が市場で標準化し始めた合図です。
この1週間で「エージェント管理」が製品になった
データサイエンス基盤の Dataiku は9月24日、年次カンファレンス「Dataiku Succeed」で Agent Management を単体製品として発表しました（一般提供は2026年10月予定）。要点は「特定のビルド基盤に縛られない」ことです。報道によれば、この製品は次の基盤に接続してエージェントを走査し、ひとつのインベントリにまとめます(BigDATAwire、Help Net Security)。
- AWS Bedrock、Databricks Agents、Google Vertex
- Microsoft Copilot Studio / Azure Foundry
- Salesforce Agentforce、Snowflake Cortex、Dataiku 自身
- 独自環境は OpenTelemetry 経由で取り込み
機能面では、エージェントの発見・所有者の記録・依存するモデルとツールの可視化・ビジネス／技術両面のパフォーマンス計測を行います。さらにリスク階層付けを備え、最もリスクの高いエージェントには認証（certification）ステータスと具体的なリスクの記録を持たせ、それらへのテストを定期的に再実行して、監査人や規制当局に示せる証跡を残す、とされています。課金はインスタンス単位の年額に加え、監視はエージェント単位の従量制です。
ここで注目すべきは「単体・横断・中立」という設計思想です。ビルド基盤の中に閉じた監視機能ではなく、複数ベンダーの基盤をまたいで管理する層を、独立した製品として切り出した点に新しさがあります。同社は同時に、エージェント構築を担う「Cobuild」も拡張しており、「作る」と「管理する」を分けて両輪で押さえにきています。
「棚卸しできている」96.4%と、事故を起こした66.7%
なぜいま管理が製品化するのか。背景には、確信と統制のあいだに開いたギャップがあります。Guild.ai が公表した調査レポート「The AI Agent Management Gap」(Guild.ai、プレスリリース）は、その断層を数字で描きます。調査は2026年8月4〜9日、従業員100人以上の組織のIT意思決定者362名を対象に実施されました（誤差±5ポイント）。自己申告値である点は割り引く必要がありますが、傾向は明確です。
| 項目 | 割合 |
|---|---|
| AIエージェントの「完全で正確な台帳がある」と確信 | 96.4% |
| 過去12か月にエージェント起因の運用上の問題を経験 | 66.7% |
| 中央集権的なダッシュボード／監視ツールを保有 | 42.7% |
| ログ／監査証跡を保有 | 39.8% |
| 暴走したエージェントを自動で即時停止できる | 31% |
ほぼ全員が「把握できている」と答えるのに、3社に2社が実際には事故を経験している——この乖離こそが「管理ギャップ」です。台帳への自信（96.4%）と、止める手段（自動キルスイッチ31%）や証跡（監査ログ39.8%）の実装率が、まるで噛み合っていません。
同じ結論は他社調査でも繰り返されています。Kore.ai の調査では、企業の **72%が「自社のAIエージェントは管理されないリスクを抱えて動き、新たな運用負担を生んでいる」**と回答しました(Kore.ai)。Harness のレポートも「エージェントへの自信が、実際の統制で裏打ちされていない」と同じ断層を指摘しています(Harness)。ベンダーもテーマも違うのに、指し示す方向が揃っている——これが「管理」が独立カテゴリになった理由です。
「棚卸しができている」という自己認識は、しばしば最大の死角になります。人が手で作った一覧は、作った瞬間から古くなり、別基盤で新設されたエージェントや、業務部門が勝手に立てた“シャドー”な構成を取りこぼします。台帳の存在ではなく、台帳が自動で・横断で・継続的に更新されるかを問うべきです。
なぜ管理は「ビルド基盤の外」に置くべきか
ここで日本企業が判断を誤りやすいのが、「エージェントを作った基盤の管理機能で足りるのではないか」という発想です。結論から言えば、単一ベンダーの中に閉じた管理は、実態に追いつきません。理由は3つあります。
第一に、現実はすでにマルチ基盤だからです。営業は Agentforce、社内文書は Copilot Studio、データ分析は Vertex や Cortex——という具合に、部門ごとに別の基盤でエージェントが立ち上がるのが普通です。各基盤の管理コンソールは自分の庭しか見えないため、組織全体の「何体あって、誰が持ち、何に繋がっているか」は、どの一社のコンソールにも映りません。Dataiku がわざわざ横断製品を出したのは、この構造的な死角があるからです。
第二に、囲い込みのリスクです。管理をビルド基盤に委ねると、その基盤を替えにくくなります。エージェントの台帳・リスク評価・監査証跡がベンダー固有の形式に閉じると、乗り換えや相見積もりのたびに統制がリセットされます。homula が繰り返し指摘してきた「名前付きエージェントの囲い込みと中立設計」の論点は、管理層でこそ効いてきます。
第三に、監査と規制は「組織単位」で問われるからです。監査人や当局が知りたいのは「Bedrockのエージェントは安全か」ではなく「御社のエージェント全体はどう統制されているか」です。証跡が基盤ごとにバラバラでは、その問いに一枚の絵で答えられません。ここは、モデルやツールを増やすほど価値が上がる論点で、非人間アイデンティティと最小権限の設計とも直結します。
発見の次に必要な4つの層
「見えないものは統べられない」という発見（ディスカバリ）の議論は、もはや出発点にすぎません。今週の製品化が示したのは、発見の次に積むべき層です。管理層を自社に落とすなら、次の4段で設計すると抜けが出にくくなります。
| 層 | 問い | 具体策 |
|---|---|---|
| ①棚卸し（横断） | 何体あり、誰が持ち、何に繋がるか | 基盤横断で自動発見。所有者・依存モデル・依存ツールを台帳化 |
| ②リスク階層 | どれが最も危ないか | 権限・データ範囲・自律度でティア分け。危険な一手は実行前ゲート |
| ③継続再検証 | いま基準を満たしているか | 認証ステータスを付与し、テストを定期再実行して証跡を残す |
| ④停止・封じ込め | 壊れたら止められるか | 自動キルスイッチと復旧手順。「止める・戻す」を対で設計 |
とくに③と④は、多くの企業で最も薄い層です。前述の調査でも、キルスイッチを備える企業は31%にとどまりました。エージェントは一度動き出すと自律的に振る舞うため、「戻せる・止められる」を平時から設計しておかないと、事故時にコンソールの前で手が止まります。「作ってから管理を後付けする」のではなく、この4層を要件として先に置くのが、規模が増えたときの破綻を避ける唯一の順序です。
homulaの観点——「管理層」を先に、横断で持つ
homula は、AIエージェント・インテグレーターとして、導入を「便利な自動化を足す」話ではなく、横断・中立の管理層を先に組んでから機能を載せる順序で設計します。今週製品化した「エージェント管理」の要件は、homula が提供する統制の領域とそのまま重なります。
- 証跡と権限を、基盤をまたいで一枚岩で持つ: Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供します。上表④の「止める」と③の「証跡」を、ビルド基盤ごとにバラバラに作るのではなく、組織横断の一つの管理層として持てるのが要点です。監査や規制が「組織単位」で問う以上、証跡は組織単位で束ねておく必要があります。
- 接続は絞って、管理の設計に人手を回す: Agens は MCP を活用し、200以上のツールと構築ゼロで接続します。接続そのものを作り込まずに用意できるぶん、①の棚卸しと②のリスク階層づけ——「どれを実行前に止め、何を全件監査するか」——の設計に時間を割けます。
- リスク階層でゲートを作り分ける: n8n / Dify / LangGraph を組み合わせ、実行前スクリーニングと人手エスカレーションを、業務の重要度に応じて実装します。「全部止める／全部任せる」の二択ではなく、階層で強弱をつけます。
- 着手前に管理指標を定義する: AIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結します。このとき「何体を横断で台帳化し、どのティアを実行前に止め、週に何件を人が見るか」を最初の要件として置くことが、数が増えたときの管理ギャップを防ぎます。
処理時間の大幅削減（例えば 93%削減）のような成果は、エージェントが数体のうちは機能追加だけで取りにいけます。しかし数十・数百に広がった瞬間、成果を安全に維持できるかは管理層があるかどうかで決まります。順序を逆にすると、増えた群れの前でキルスイッチも台帳も間に合わない——調査の66.7%が示すのは、まさにその後付けの帰結です。
まとめ
9月24日の Dataiku の発表が示したのは、「エージェントが賢くなった」という話ではありません。示されたのは、エージェント管理が独立した製品カテゴリになったという市場の転換です。作る基盤はマルチベンダーで出そろい、次の勝負どころは「横断して束ね、リスクで並べ、危ないものを止め、証跡を残す」管理層に移りました。
「台帳はある」と96.4%が答えるのに66.7%が事故を経験する——この確信と統制のギャップは、単一基盤の管理機能では埋まりません。日本企業がいま準備すべきは、特定ベンダーの管理コンソールに任せることではなく、基盤をまたぐ中立の管理層を、機能より先に自社サイズで組むことです。棚卸し・リスク階層・継続再検証・停止の4層を先に決めておけば、エージェントを増やすことは「怖いもの」ではなく「広げていけるもの」になります。管理は、スピードを落とす足かせではなく、群れを安全に増やすための前提条件です。
「便利だが、基盤ごとに散らばって御しきれない」を、「横断で管理できる統制」に変えませんか。homula は、横断台帳・リスク階層・全件監査・停止設計を備えたエージェント管理層づくりを、業務棚卸しからROI試算まで一気通貫で支援します。