VentureBeatが先月実施した、40のエンタープライズ企業を対象とする調査によると、意思決定者の72%の組織は、自社の「主要」レイヤーとして特定しているAIプラットフォームを2つ以上持っていると主張しており、セキュリティと統制における実際の大きなギャップが明らかになった。
エンタープライズのマネジメント層や技術リーダー、そしてとりわけセキュリティリーダーにとって、これら複数のAIプラットフォームは、AIを悪用した攻撃がますます強力になっている時期に、多くの企業の攻撃対象領域を拡大させている。
複数のプラットフォームには、Microsoft Azure、Google、OpenAI、AnthropicのようなハイパースケーラーやAIラボの提供が含まれるほか、Epic、Workday、ServiceNowのような大手アプリケーション企業の提供も含まれる。これらは、巨大なソフトウェア提供事業者が、自社のAIを企業顧客に提供しようと急いでいることに伴って生まれてきた「拡散（スプロール）」の状態を反映している。
そうした顧客側も、AIを拡大しようと急ぐあまり、単一の戦略を構築できていないことがわかっている。実際には、相互に矛盾するものの寄せ集めを作ってしまっている可能性さえある。
戦略上の逆説：なぜ先進企業はベンダーの周りに構築してしまうのか
例えば、従業員9万人を抱え、マサチューセッツ州で最大の雇用主でもある、マサチューセッツ総合病院（Mass General Brigham：MGB）の直面する戦略上の逆説を見てみよう。2023年、病院システムは、従業員がAIプロジェクトにのめり込むにつれて社内に増殖していった、無制御の数の社内PoC（Proof of Concept）を停止せざるを得なかったという。これは、AIのスケールに伴う課題に焦点を当てた、3月26日のボストンでのVentureBeat AI Impactイベントで、CTOのNallan「Sri」Sriramanが述べた内容だ。
その代わりに同社は、既に使っているソフトウェアの巨大企業が、自社のAIロードマップを確実に実現するまで待つほうがよいと判断した。これらの企業は資源が非常に豊富で、そもそも自分たち自身がAIを最優先にしていたのだから、MGBが重複することになる自社のAIレイヤーを構築しようとするのは意味がない、と彼は語った。彼は「なぜ自分たちで作る必要があるのか？」と問い、「活用すべきだ」と述べた。
しかしそれでも、Sriramanのチームは、そうした企業が十分に対応できていない部分について、回避策を作り込まざるを得なかった。
例えば、MGBは現在、MicrosoftのCopilotを中心に「フルスケール」のカスタム構築を完了させた。目的は、当該ツールが提供するほぼすべてを利用できるようにするため、Copilotの周りに「スキン」をかぶせて、主要なモデル提供事業者がまだ十分に習得できていない安全性とデータのプライバシーに関する懸念に対応することだ。具体的には、従業員がAIにプロンプトを出しても、保護された医療情報（PHI）が、CopilotのLLMプロバイダであるOpenAIへ漏えいしない仕組みが必要だった。最大で3万人のユーザーを支えられる新しいセキュアなプラットフォームは、まさに究極の矛盾を体現している。つまり、より大手の企業が提供するAIを活用することを社内で義務づけられているにもかかわらず、その企業の失敗（不足）に回り込むために自分たちで作り込む必要があるのだ。
この矛盾はさらに深まる。MGBが使うソフトウェアベンダー（Epic、Workday、ServiceNowも含む）はすべて、自社のAIに対してエージェントを構築し始めており、それぞれが異なる仕組みで動作している。したがってMGBは、これらすべてのエージェントを「調整し、オーケストレーションする制御プレーン」を構築する投資を行わなければならない、とSriramanは述べた。「その領域に、私たちの投資が向かうことになります。」
彼は、こうした企業は「環境が変わり続ける中で、発見し、試行錯誤している」状態だと指摘した。市場は「まだ未成熟」である、と彼は言う。そのため判断が難しくなる。
「六人の盲人」の問題
Sriramanは、現在のベンダー環境をたとえ話で説明した。「六人の盲人に象に触らせて、『この象はどんな見た目だ？』と聞くとします。どうなるでしょうか」と彼は言った。「6人それぞれ、まったく違う答えが返ってくることになるでしょう。」
VentureBeatが第1四半期に行った調査結果と、ボストンでの出来事のような会話から見えてくるのは、私たちVentureBeatが「ガバナンスの蜃気楼（governance mirage）」と呼んでいる状況だ。多くの企業が十分なガバナンスがあると言っている一方で、実際には、ガバナンスを担保するための明確な説明責任や具体的なガードレール、評価プロセス、セキュリティ手順が作られていない。
断絶のデータ：確信 vs. 体系的な監督
この調査は、1月、2月、3月にかけてVentureBeatが行った、従業員100人以上のエンタープライズ企業を対象とした調査から得られた。各トピック領域ごとに40〜70名の有資格回答者があり、エージェントによるオーケストレーション、AIセキュリティ、RAG、ガバナンスをカバーしている。多くの領域でデータに統計的な有意性はなく、方向性を示すものとして扱うべきだ。
ガバナンスに関する調査では、大半、つまり56%の回答者が「不正に振る舞うAIモデルを検知できることに非常に自信がある」と回答しており、ほとんどの意思決定者が、自社には十分な基本的ガバナンスがあると考えていることを示唆している。
しかし、回答者のほぼ3分の1は、AIの不正な挙動を検知するための体系的な仕組みを持っていない。問題が、ユーザーや監査を通じて表面化して初めて判明するという。テレメトリ漏えいがGenAIインシデントの34%を占める世界では（Wiz）、そしてデータ侵害の世界平均コストが4.4百万ドルに達している状況では（IBM 2025 Cost of a Data Breach）、被害が起きた後に分かることが、多くの企業にとってデフォルトになっている。
さらに、43%の回答者は、AIガバナンスを所有するのは中核となるチームだと答えている。これは安心材料のように聞こえるが、他の領域で何が起きているかを見ると話は別だ。23%は、ガバナンスがチーム間で不明確、または積極的に争われていると回答している。20%は、各プラットフォームチームが独自にガバナンスしているという。6%は、誰もそれに対して正式に取り組んでいないと答えた。残りは、誰がそれを所有しているのか分からないとしている。
より決定的なのは障壁（バリア）のデータだ。プラットフォーム横断でAIをガバナンスする際の最大の障害を尋ねたところ、「単一のオーナーや説明責任のあるチームがいない」が29%で2番目に位置している—ベンダーの不透明さに次ぐ形だ。説明責任の構造と、ベンダーの透明性不足という2つの失敗パターンが支配的で、互いに増幅し合う。中央のオーナーがいないと、ベンダーに対して透明性を要求するための権限が誰にもないからだ。
Day2の請求書：スプロール、増殖、ロックインの管理
スケールの罠：Red Hatからの警告
Red Hatのシニア・ディレクターで、先月のVentureBeatボストンイベントでも登壇したBrian Gracelyは、このスプロールのインフラ面に焦点を当て、多くの企業が「欺瞞的な初期の勝ち」に陥る罠に入っていると警告した。
Gracelyは、参入障壁は最初にはほとんど存在しないと指摘した。クレジットカードとAPIキーさえあれば、ほぼ誰でもプロジェクトを立ち上げられるのだ。「Day zeroはとても、とても簡単です」とGracelyは言った。「Day twoになって初めて、請求書が回ってきます。」
Red Hatは、自社のソフトウェアレイヤー（OpenShift AI）を、企業が単一プロバイダの独自エコシステムに埋もれてしまうのを防ぐために必要なバッファとして位置づけている。Gracelyの主張は明快だ。あなたの統制システムが、完全に1つのクラウドプロバイダのツールセットの中に構築されているなら、実質的に「檻を借りている」ことになる。初期のパイロット段階で感じるスピードの錯覚は、AI作業を別のプラットフォームへ移そうとした瞬間に明白になる技術的負債を、しばしば見えなくしている。
Gracelyは、最近の具体例でこれを示した。Red Hatの集中型CTOオフィスに所属するあるシニアリーダーが、休暇の一部を、OpenClawというオープンソースのエージェントプロジェクトに貢献することに費やした。これは第1四半期に広く人気を博した。彼女の名前がプロジェクトのメンテナーとして掲載されてから数日もしないうちに、Red Hatはニューヨークの大手銀行からの問い合わせに対応していた。彼らの問題はすぐに明らかになった。すでに、自社のインフラに「claws」（エージェントベースのツール）を持ち込むために、1万以上の従業員が関与していたにもかかわらず、中央集権的な監督はゼロだったのだ。
従業員がこの種の未承認技術に取り組むことで引き起こされる侵害（ブリーチ）は、コストがかさみます。IBMによると、いわゆる「シャドーAI（shadow AI）」のインシデントは、標準的なインシデントより平均で$670K多くの損害をもたらします。
Red HatのGracelyは、これらの未承認ポートを停止しようとすることは可能だが、最終的にはそれらを生産的で安全に運用する方法を突き止めなければならない、と指摘しました。そのためには、オーケストレーション層、あるいはプラットフォーム層への深刻な投資が必要になります。
動的ディフェンス：MassMutualの賭けない方針
一部のエンタープライズ企業は、すべてのAI技術やアプリを統括する「AIオペレーティングシステム」を求める一方で、単にその支払いをすることを拒む企業もあります。MassMutualのCIOでエンタープライズ・テクノロジー責任者であるSears Merrittは、意図的に高い速度で柔軟に変化できる状態を維持することで、ガバナンス上のジレンマを管理しています。
「状況がこれほど動的だと、どのAIベンダーが最終的に勝ち残るのかを見極めるのは難しいんです」と、Merrittはボストンでのイベントで述べました。そのためMassMutualは、AIベンダーとの長期契約への参入を拒否しています。Merrittの「動的ディフェンス」戦略は、私たちの調査の中核的な発見を浮き彫りにしています。すなわち、ベンダーの人気は月ごとに劇的に変わる、という点です。
たとえばAnthropicは、1月に0%だったのが2月には6%近くまで上昇しました。これは、どのエージェントのオーケストレーション技術を使用しているかを報告した回答者の割合の話です。なお、サンプルサイズは70人と小さかったものの、それでも方向性として、ダイナミックに変わる状況は「今日の“主戦の勝者”を選ぶ」ことが愚かな取り組みになり得ることを示唆しています。
1月の数字は、おそらく調査の構成を反映しているのでしょう。回答者は、Anthropicが強い初期の伸びを見せている開発者コミュニティではなく、より広いエンタープライズ市場を代表しています。
つい最近までは、多くの組織が、Copilotで先行していたことから、主要なオーケストレーション提供者としてMicrosoftやOpenAIのようなリーダーに早期から参加していました。しかし、Anthropicがエンタープライズ向けエージェントのオーケストレーションに今まさに踏み込んでいることを示す私たちの発見は、そのプラットフォームをめぐる直近の熱気を裏づけるものかもしれません。
考えられる説明の1つは、モデルの推論にClaudeをすでに使っている企業が、第三者のフレームワークではなくAnthropicのネイティブ・ツールに経路を切り替えている可能性があることです。ただしサンプルが小さすぎるため、確かな結論は導けません。
「プラットフォーム・クリープ（platform creep）」の台頭
主要な提供者は、Anthropicの最近の発表に表れているように、「マネージド・エージェント」へも移行しています。この提供は、OpenAIやAnthropicがより多くのAIインフラを担っていく、といった継続的なプラットフォーム・クリープの可能性を示しています。とりわけこのケースでは、エージェントのエージェンティックなセッション詳細のメモリです。そしてそこに罠が仕掛けられています。いったんセッションデータとオーケストレーションが提供者の独自データベースの中で動くようになると、あなたは単にモデルを利用しているだけではなく、そのエコシステムの中で暮らしていることになります。
さらに、永続的なエージェントメモリは、今後のあらゆるやり取りに影響を与える注入命令による「メモリ・ポイズニング（memory poisoning）」の格好の標的です。そして、そのメモリが提供者のデータベースにある場合、自分自身のフォレンジック（鑑識）能力を失ってしまいます。
セキュリティの皮肉：養鶏場を守るキツネ
私たちは、データの中にもこのプラットフォーム・クリープが現れているのを見ています。Q1データで最も衝撃的だったのは、私たちが「セキュリティの皮肉（Security Irony）」と呼ぶものです。すなわち、エンタープライズのAIリスクを生み出すことに最も責任が大きい提供者が、そのリスクを管理するために企業が使っている同じ提供者である、という事実です。
回答者によれば、AIオーケストレーション・プラットフォームのトップの選定基準は「一般的なセキュリティと権限」（37.1%）でした。これは、コスト、柔軟性、統制、開発のしやすさといった他の基準を上回っています。ところが、市場は主権よりも利便性を選んでいます。私たちの調査によると、2月のエンタープライズの26%が、主要なセキュリティ解決策としてOpenAIを使っていました。リスクを生み出しているのと同じ提供者です。確保しようとしているリスクの元凶である、その提供者です。この傾向は3月でも強まっているように見えましたが、前述のとおり注意が必要です。サンプルサイズが小さく、このデータはあくまで方向性として捉えるべきです。
企業がセキュリティ解決策としてOpenAIを選んでいるのか、それとも、（2024年にCopilotソリューションを積極的に押し出した際にOpenAIと提携していた）Microsoft Azureが提供する組み込みのセキュリティ機能に単に依存しているのかは明確ではありません。そもそも顧客がすでにそのプラットフォーム上にいた、というだけかもしれません。
データの先にあるものとして、OpenAIのエンタープライズでの立ち位置が変わりつつあるという逸話的な兆候もあります。今年初め、AnthropicのClaude CodeはClaude 4.6モデルと並んで、開発者の間で大きな注目を集めました。その後のセキュリティに焦点を当てたモデルであるMythosの発表は、脆弱性を特定できることから、エンタープライズのセキュリティチームから関心を呼びました。OpenAIもまた、セキュリティに焦点を当てたモデル、GPT-5.4-Cyberを発表しています。
私たちのデータは、いくつかのエンタープライズAIカテゴリにおいてOpenAIの相対的な位置づけが低下していることも示しているかもしれません。その一領域がデータ検索（データ・リトリーブ）で、OpenAIは第三者提供者の中で再び先頭に立っていますが、一方で、検索のために社内ソリューションを使う回答者の数が増えているのも確認できました。おそらくこれは、AIモデルやエージェントが、既存のデータベースに対して直接呼び出しを行うためのツールを、ネイティブに利用できるようになってきている可能性、そしてこの実装がカスタムコードによって行われているケースが多いことの表れなのかもしれません。ただしここでも、現時点では私たちのデータはせいぜい方向性にとどまると考えています。
私たちはキツネに養鶏場を守らせています。大規模クラウド事業者のセキュリティ機能（OpenAI、Azure、Googleのようなもの）が勝っているのは、それらが、すでに企業が使っているプラットフォームに組み込まれているからです。しかし、それは単一提供者への依存を生みます。エージェントがドキュメントを修正し、APIを呼び出し、データベースにアクセスする力を獲得するにつれ、「ガバナンスの蜃気楼（governance mirage）」は、私たちに統制があるかのように思わせます。一方でデータは、私たちがただ、大規模クラウド事業者が提示する内容に対して「同意する」をクリックしているだけだということを示しています。とはいえ生じるリスクには、コンテンツ・インジェクション、権限昇格、そしてデータの持ち出し（データ・エクスフィルトレーション）が含まれます。
前に進む道：統一されたコントロールプレーンへ
「AIのDynatrace」を探して
では、抜け道は何でしょうか。Sriramanは業界が切実に必要としているのは、「モデルのドリフトや安全性のためのプロンプト」、エージェントの行動分析、権限昇格のアラート、フォレンジック・ログなどを含む、完全なエンドツーエンドの可視性を提供する「中央のオブザーバビリティ・プラットフォーム」——「AIのDynatrace」——だと主張しました。彼は現在、これを実現するために複数の有力な提供者候補と協力しています。
「スイベルチェア」の警告
Sriramanは、統一されたコントロールプレーンがなければ、企業は断片化した「スイベルチェア」世界へ逆戻りする危険があると警告しました。これは、ロボティック・プロセス・オートメーション（RPA）の初期の、非効率な時代を彷彿とさせます。当時は、従業員が単一のワークフローを完了させるために、別々に切り離されたAIツール間を絶えず行き来することを強いられていました。「ここで何かをするためにいったん切り替えて、それから別のことでまたプラットフォームへ戻らなければならない世界は作りたくありません」と彼は述べました。
しかし、単一のコントロールプレーンへの欲求は、ロックインを避けたいという欲求と相反します。私たちのデータによると、市場は「ハイブリッド・コントロールプレーン」に落ち着いています。言い換えれば、回答者の中で最も多かった状況（34.3%）は、一部のワークフローでは Copilot Studio や OpenAI のアシスタントのようなモデル提供事業者ネイティブのソリューションを使いながら、その他では LangGraph やカスタムのオーケストレーションといった外部オプションも併用する、というものでした。ここでより頑なだと報告した企業は少数でした。たとえば、意図的にモデル提供事業者をオーケストレーション層から完全に排除する場合、カスタムのオーケストレーションツールだけに頼る場合、あるいはモデル提供事業者の技術だけに頼る場合などです。
エンタープライズは、単一のプロバイダーに十分な信頼を置いて完全なコントロールを委ねることはできない一方で、ゼロから完全に作り上げるためのエンジニアリング能力も欠いています。
結論： 「巨大な赤いボタン」
可視性と統合は、戦いの半分にすぎません。医療のような高リスクな業界では、スリラマンは、正当なコントロールプレーンにはハードストップ機能も備わっている必要があると主張しています。「私たちは巨大な赤いボタンが必要です」と彼は言いました。「それを殺す。……それができるべきです。そうでなければ、運用環境に何も入れないでください。」実際、そのようなキルスイッチは、セキュリティコミュニティの OWASP が、推奨するセキュリティの枠組みの一部として、正式に求めています。
「ガバナンスの蜃気楼」とは、誰がコントロールおよびセキュリティのプレーンを所有するのかを決めずに、AIをスケールできると考えることです。
複数の「主要」プラットフォームがあると主張している組織の 72% の一員であるなら注意が必要です。そこには戦略がない可能性があり、利益相反が生じているかもしれません。これは、AI の巨人たち――OpenAI、Anthropic、Google、Microsoft など――の間の戦争の勝者が、必ずしも最良のモデルを持つ会社とは限らない、という示唆でもあります。むしろ、モデルの上に立って、エンタープライズが「単一の真実」のバージョンを強制できるように支援できる会社が勝つ、ということです。ただし、単一のプレイヤーとのロックインを企業が望まないため、この目標の達成は難しいかもしれません。
データは、エンタープライズがすでにその結果に抵抗していることを示しており、そして、その抵抗を形式知化する必要があるかもしれません。エンタープライズは、ベンダーにその役割を任せて待つのではなく、独立したセキュリティ計測（インストゥルメンテーション）によって自分たちでコントロールプレーンを所有する必要があると言えます。
