次の AI 企業バトルはモデルではなく『エージェント制御基盤』 — 守る側の 4 つの論点

2023〜2025 年、生成 AI を巡る企業間競争は「モデル性能の競争」だった。GPT-4 と Claude 3 と Gemini Ultra のベンチマーク差を 1 ポイント単位で議論し、コンテキスト長と推論速度と料金を比較する記事が業界誌を埋め尽くした。だが 2026 年に入ると、その軸が崩れ始めている。モデル性能の差は実務上の意思決定要因として急速に縮小し、各社の戦略は「どのモデルを売るか」から「そのモデルが業務でどう動くか」へと重心を移した。本稿が指す次の競争軸は エージェント制御基盤（agent control plane） である。

モデル戦争の収束 — 3 つの構造的要因

モデル性能の競争が収束に向かう要因は 3 つある。第一に、性能差の実務感応度の低下。Claude 4、GPT-5、Gemini 2 の三者は、業務応用上のほとんどのユースケースで「どれも合格点」を出す段階に到達した。1〜2 ポイント差のベンチマーク勝敗は、現場の意思決定者には響かない。第二に、調達側の合理化圧力。一企業が複数モデルを併用する「モデル・マルチソース化」が当たり前になり、特定モデルへの依存度を下げる方針が定着している。第三に、性能の伸び代の質的変化。推論性能や知識量だけでなく、「ツールを呼べるか」「複数ステップを連鎖できるか」「長期タスクを継続できるか」というエージェント能力が新たな勝敗軸になっている。

エージェント制御基盤とは何か

エージェント制御基盤とは、LLM 単体ではなく、モデルが業務環境で自律的に行動するための基盤レイヤーのことだ。具体的には、ツール（API・ブラウザ・社内システム）への接続規約、エージェント間のタスク委譲、状態と記憶の管理、人間承認の挟み込み、ログと監査の取得、失敗時のロールバック、複数モデルの統合といった機能群を指す。「モデルが何を言うか」より「モデルに何をさせて、どこで止めるか」の設計に重きが置かれる。

各社の戦略マップ

Anthropic — MCP + Skills + Computer Use の積み上げ

Anthropic は Model Context Protocol（MCP） をオープン規格として推進している。MCP は LLM と外部ツール（社内システム・SaaS・ファイルシステム）の接続を標準化する仕様で、競合他社も含めて広く採用されつつある。これに加え、Claude Code、Computer Use、Skills、Claude Agent SDK を組み合わせ、「エージェントが計算機を直接操作する」シナリオを実装する基盤を整えている。さらに 2026 年 4 月の Claude Mythos Preview は、エージェントが脆弱性発見まで自律的に行うレベルの能力を示した。Anthropic の戦略は、「制御基盤の規格を握り、その上で最も能力の高いモデルを提供する」という二段構えで進む。

OpenAI — Operator / GPTs / Assistants の縦統合

OpenAI は、ブラウザを操作する Operator、ユーザー定義エージェントを共有する GPTs、API での Assistants 等、自社内で一貫した縦統合戦略を採る。コンシューマー側（ChatGPT）からエンタープライズ側（Enterprise / API）まで、同じエージェント概念を流通させ、開発者と利用者の双方を抱え込む。Anthropic の MCP のような外部規格化には消極的で、囲い込みによる規模の経済を追う。

Google — Project Mariner と Vertex AI の連携

Google は Project Mariner でブラウザ自律操作、Gemini ベースのエージェント開発キット（ADK）、Vertex AI 上のエージェント基盤を組み合わせる。強みは クラウド基盤（GCP）との一体化。エージェントが扱うデータの保管、IAM、監査ログを Google Cloud のセキュリティ基盤の上に乗せられる点で、エンタープライズ顧客への訴求力を持つ。

Microsoft — Copilot Studio + AutoGen の二層構造

Microsoft は Copilot Studio で「業務員でも組めるエージェント」を、AutoGen で「開発者向けマルチエージェント」を提供する。Microsoft 365 / Dynamics / Power Platform という既存業務基盤との接続が圧倒的に強く、「既に使っている SaaS の上に AI エージェントが乗ってくる」形での普及を狙う。OpenAI との資本関係を背景に、モデルとしては GPT 系を選びつつ、制御基盤としては独自のレイヤーを保持する。

守る側の 4 つの論点

1. ベンダーロックインの再来

制御基盤は、データベース・OS・クラウドと同じく「一度導入したら抜けにくい」性質を持つ。エージェント定義、接続したツール、蓄積した実行ログ、業務員が習得したスキル、すべてが基盤ごとに固有化する。MCP のようなオープン規格は緩和要因になるが、各社が独自拡張を加えれば結局はロックインに収束する。調達段階で「いつ・どう移行できるか」を契約事項に書き込むのがいい。

2. 制御基盤自体のセキュリティ

エージェント基盤は「業務情報の通り道」になる。先日報じられた PraisonAI CVE-2026-44338 のように、基盤自体に未認証 RCE 級の脆弱性が混入すると、配下のすべてのエージェントが汚染される。各社の制御基盤の脆弱性対応 SLA・サードパーティ監査の状況・コードベースの透明性は、調達評価項目の上位に置くべきだ。

3. 監査・ガバナンスの可視性

「エージェントが何をしたか」のログを、人間が後から検証できる粒度で保管できるか。これは、各基盤の API 仕様・ログフォーマット・保持期間・エクスポート可能性によって大きく差がつく。SOC 2 や ISO 27001 の監査要件を満たす形で記録できるか、内部監査人が読める形でレポートを出せるか。ガバナンス可視性は基盤選定の決定的論点になる。

4. 責任分界点の曖昧化

エージェント A の出力がエージェント B のツール呼び出しを誤動作させ、その結果として業務影響が発生したとき、責任は誰が負うか。基盤提供者か、エージェント設計者か、利用部門か、業務委託先か。現行の契約・SLA・利用規約はこの問いに正面から答えられない。制御基盤を採用する段階で、責任分界の文書化を法務部門と進めるのが、後の紛争を避ける唯一の方法である。

編集部の見立て

2026 年後半から 2027 年にかけて、企業向け AI の「決定的な競争軸」は、モデル性能ではなく制御基盤になる。CISO・情シス・経営層が今すぐ着手すべきことは三つある。第一に、自社で導入中・検討中の AI 製品が「どの制御基盤の上に乗っているか」を棚卸しすること。第二に、その制御基盤の脆弱性対応・監査可能性・データ取扱を、ベンダー単体ではなく基盤レベルで評価する仕組みを作ること。第三に、複数基盤への分散投資と、特定基盤への完全依存の 境界線を社内で合意しておくこと。

モデルは今後も進化を続ける。しかし、組織が業務で使うのは「モデル」ではなく「モデルが業務環境で何をどう動かすか」を制御する基盤である。次の数年、決定的な意思決定は、ベンチマーク表の比較ではなく、基盤選定の地味な精査の中で行われる。

本稿は Omamori AI 編集部による独自論考である。各社の公開情報・製品発表・編集部観察に基づき構造化したもので、特定企業の戦略を保証するものではない。