AIエージェント基盤が出そろった｜モデルは差し替えられても、権限設計を作り込んだ後の引っ越しはできない

結論：選んでいるのは製品ではなく、数年間の運用のかたちである

企業向けAIエージェントの「基盤」が、この数週間で相次いで動きました。OpenAIは2026年7月22日に、顧客対応や社内ITサービスなどの業務にAIエージェントを組み込むための製品「Presence」を発表しています。その少し前の7月17日には、Google CloudがGemini Enterprise Agent Platformについて13本のハンズオンデモを公開しました。内容は、エージェントの構築（ADK、承認を挟む人間介在型、MCPによるデータ接続）、拡張（実行基盤への配備、長時間実行、本番展開）、統制（Agent Gatewayによる実行時ガバナンス、mTLSや認証、Model Armor）、最適化（品質評価、複数エージェント連携、フレームワーク間の相互運用）の4分類にわたります。エージェントの設計パターンが、実演を通じて標準化されつつある段階です。報道では、他の大手も同種の基盤を提供しているとされています。

ここで、多くの中堅企業の経営者が抱く感想は「どれを選べばいいのか分からない」でしょう。しかし本記事の主張は、その問いの立て方自体を変えるべきだ、というものです。

AIエージェントの基盤を選ぶという行為は、モデル（AIそのもの）を選ぶ行為とは性質が異なります。

モデルは、比較的差し替えやすい部品です。呼び出す先を変え、出力の品質を検証すれば、乗り換えは成立します。実際、この一年で複数のモデルが値下げと性能向上を繰り返しており、乗り換えを前提とした設計が推奨されるようになっています。

一方、エージェント基盤で作り込むのは、誰が何をしてよいかの権限設計、承認が必要な操作の定義、ガードレール（やってはいけないことの線引き）、実行結果の評価の仕組み、社内システムとの接続です。 これらは業務そのものの写し取りであり、製品ごとに表現の仕方が異なります。だから、作り込んだ後の引っ越しは、単なる置き換えでは済みません。

3行サマリー（先に結論）

• OpenAIのPresence（7月22日）、Google CloudのGemini Enterprise Agent Platformのハンズオンデモ13本公開（7月17日）など、企業向けエージェント基盤の提供が本格化。
• モデル（API）は差し替えやすいが、権限設計・承認フロー・ガードレール・評価基盤・システム接続を作り込んだ後の乗り換えコストは桁違いに高い。
• したがって最初に決めるべきは製品ではなく、①どの業務から着手するか ②どこまでできたら成功とするか ③どうなったら撤退するか、の3点。

2026年8月更新：最長7日動くなら「長い処理」ではなく「長い権限委任」になる

Google CloudのGemini Enterprise Agent Platform リリースノートでは、2026年4月22日の初回リリースとして、Vertex AI関連機能の再編と名称変更を掲載している。Agent EngineはAgent Runtime、Agent Builder SessionsはAgent Platform Sessions、Memory BankはAgent Platform Memory Bankとなった。

同じ初回リリースには、Agent Runtimeの最長7日の長時間処理、サブ秒のコールドスタート、1分未満へのプロビジョニング短縮、独自コンテナ、Agent IdentityとリモートMCPサーバーの一般提供等が並びました。Agent Registryはこの時点ではPublic Previewであり、一般提供の列挙には含まれません。名称変更は表示だけでなく、契約、設計書、監視、API、障害手順で旧名と新名を照合する作業を生みます。

7日動けることは、7日自動運転してよいことを意味しない。長時間の処理では、途中で価格、在庫、権限、対象データ、承認者が変わり得る。「開始時に許可したから終了まで有効」ではなく、確認点ごとに権限と業務条件を再評価します。

7日処理の8項目

8項目のうち、確認点、停止、手動復旧が空欄なら、7日処理を本番許可しません。短い処理で成功したPoCを、そのまま長時間処理へ拡張するのも止めます。

リリースノートの「GA」と「Preview」を混ぜない

同じ初回リリースでも、Agent IdentityとリモートMCPサーバーは一般提供、Agent Registryは公開プレビュー、Agent Gatewayと新しいIAMガバナンスポリシーは限定プレビュー、Agent Observabilityはプレビューとして記載されていました。その後、Agent Registry、Agent Gateway、Agent Observabilityは2026年6月18日に一般提供へ移っています。製品群全体を一括せず、採用時点における機能ごとの提供段階、リージョン、SLA、変更可能性を提案書へ書きます。

また、初回リリースに記載されたGemini Embedding 2の音声トラック抽出に関する既知問題は、公開履歴上で2026年5月6日に修正済みと掲載されています。古い既知問題を現在も未修正と決めず、採用時点の公開履歴を再取得します。

要点表：エージェント基盤で作り込まれるもの

上4行と下4行で、乗り換えやすさが明確に分かれます。投資が重いのは下4行のほうです。

なぜ「PoCで終わる」のか

AIエージェントの導入で最も多い結末は、実は失敗ではなく「PoC（実証実験）で終わる」ことです。動くものはできた。デモも成功した。しかし本番には至らない。この現象には、いくつかの共通した原因があります。

原因1：対象業務が「デモ映えする業務」で選ばれている 分かりやすく成果が見える業務が選ばれがちですが、それが実際に工数を食っている業務とは限りません。結果、「動いたけれど、これが自動化されても大して楽にならない」という結論になります。

原因2：例外処理の存在が見えていない 定型業務に見えても、実務には例外があります。「この取引先だけは別の様式」「月末だけ手順が違う」。PoCでは代表的なケースだけを扱うため、例外の存在が本番直前に発覚し、そこで止まります。

原因3：責任の所在が決まっていない エージェントが誤った処理をしたとき、誰が責任を負うのか。承認を挟むのか、事後にチェックするのか。この設計をせずに本番に出せる業務は多くありません。

原因4：撤退条件がないため、判断できない 最も見過ごされている原因です。「どうなったらやめるか」を決めずに始めると、うまくいかない状態が続いても止める判断ができません。追加の改善を重ねながら、いつのまにか自然消滅する。これが最も費用を無駄にする終わり方です。

最初に決めるべき3つのこと

製品比較の前に、次の3点を社内で決めてください。ここが決まっていれば、どの基盤を選んでも大きくは外しません。逆に、ここが空白のまま基盤を選ぶと、何を評価すればよいかも分かりません。

決定1：どの業務から着手するか

選定の基準は「デモ映え」ではなく、次の4条件です。

• 発生頻度が高い（週に何度も発生する）。
• 手順が文書化されている、または文書化できる。
• 間違えたときの影響が回復可能である（取り返しがつかない処理でない）。
• 現在それをやっている人が、改善に協力してくれる。

4つ目が特に重要です。自動化される側の協力がないと、例外処理の情報が出てきません。「あなたの仕事をなくします」ではなく「あなたが本来やるべき仕事に時間を戻します」という文脈を作れるかどうかが、成否を分けます。

決定2：どこまでできたら成功とするか

「業務が楽になった」では評価できません。着手前に、次の形式で目標を書いてください。

○○業務について、現在は月△時間かかっている。エージェント導入後、□ヶ月以内に月◇時間まで削減する。品質基準は、誤り率×%以下とする。

数字が入っていれば、途中で判断できます。数字がなければ、いつまでも「もう少しで良くなりそう」が続きます。

決定3：どうなったら撤退するか

これを先に決めておくことに、大きな意味があります。例えば次のような形です。

3ヶ月経過時点で削減時間が目標の半分に達していない場合、または誤り率が基準を上回り続けている場合は、本番展開を中止し、原因を整理した上で別のアプローチを検討する。

撤退条件があると、担当者が「失敗を認める」重圧から解放されます。あらかじめ決めたルールに従うだけになるからです。これは組織的にも重要な効果です。

基盤を比較するときの評価軸

上の3点が決まったら、製品の比較に進めます。中堅企業の実情に即した評価軸を挙げます。

最後の「出口」は、契約前に必ず聞いてください。答えられないベンダーもありますが、その反応自体が情報になります。

「大手が出したから安心」ではない理由

大手の基盤を選ぶことには合理性があります。継続性、サポート体制、他社事例の蓄積。中堅企業にとっては、この安心感は実質的な価値です。

ただし、二つだけ注意点があります。

注意点1：セルフサービスで完結しない場合がある 企業向けのエージェント基盤には、自社だけで契約して使い始められるものと、導入支援を伴う提供形態のものがあります。後者の場合、実際に使えるようになるまでの期間と費用が、想像より大きくなることがあります。「発表されたから、すぐ使える」とは限りません。

注意点2：製品は統合されるが、業務は統合されない 基盤側がどれだけ優れていても、自社の業務が整理されていなければ、エージェントに何をさせるかを定義できません。「AIを入れたら業務が整理される」という順序は成立しません。順序は逆で、整理された業務にしかAIは載りません。

この2点目は、多くの企業が高い授業料を払って学ぶところです。基盤の検討と並行して、対象業務の手順を文書化する作業を進めてください。文書化の過程で「そもそもこの作業は不要では」という発見が出てくることも珍しくなく、それ自体が成果になります。

業務手順を文書化する——AIに渡せる形にする

「整理された業務にしかAIは載らない」と書きました。では、どう整理するのか。実務で使える型を示します。特別な手法は不要で、次の5項目を書き出すだけです。

項目1：きっかけ（トリガー） その作業は何をきっかけに始まるか。メールが届いたとき、システムに登録されたとき、毎月◯日、電話がかかってきたとき。

項目2：手順 何を、どの順序で行うか。番号付きの箇条書きで、1行1動作を目安に書きます。「システムAを開く」「◯◯の条件で検索する」「結果をExcelに貼る」といった粒度です。

項目3：判断が入る箇所 手順の中で、人が判断している箇所に印を付けます。「金額が◯万円を超える場合は上長に確認」「取引先が新規の場合は与信を確認」。ここがAIに任せられるかどうかの分かれ目になります。

項目4：例外 「ただし、この場合は違う」という例外を列挙します。ここが最も重要で、最も抜けやすい部分です。担当者は例外を無意識にこなしているため、聞かないと出てきません。

聞き出すコツは、「先月やった作業のうち、いつもと違ったものはありますか」と具体的に聞くことです。「例外はありますか」と抽象的に聞くと「特にありません」と返ってきます。

項目5：完了の条件 何をもってその作業が終わったと言えるか。「システムBに登録された状態」「担当者にメールを送った状態」。

この5項目を、対象業務について1〜2ページにまとめます。作業時間は、担当者へのヒアリングを含めて半日程度です。

副次的な効果

この文書化には、AI導入とは別の効果があります。第一に、業務の引き継ぎ資料としてそのまま使えます。第二に、書き出す過程で「この確認作業は本当に必要か」という疑問が出てきます。第三に、複数の担当者が同じ作業をしている場合、やり方が違っていることが判明します。

つまり、AIを導入しなかったとしても、この作業には価値があります。 だから最初にやるべき工程として推奨できます。

監査ログで何を見るか

エージェントを本番で動かすようになったら、その動作を確認する必要があります。何を見るべきかを整理します。

特に「人の介入」の推移が重要です。導入初期は介入が多く、慣れるにつれて減っていくのが健全な姿です。逆に、時間が経っても介入率が下がらないなら、その業務はエージェントに向いていない可能性があります。

また、「ガードレール作動」がゼロのまま続く場合も注意が必要です。本当に一度も逸脱していないのか、それともガードレールが機能していないのか。定期的にテストで確認する仕組みを持ってください。

責任の設計——誰が承認し、誰が責任を負うか

エージェントが業務を実行するということは、これまで人が担っていた判断の一部を機械に委ねるということです。ここで責任の所在を曖昧にすると、事故が起きたときに組織が混乱します。

設計1：操作を3段階に分ける

すべてを事前承認にすると効率が上がりません。すべてを自動実行にすると事故のリスクが上がります。業務ごとに、この3段階のどれに当たるかを決めます。

設計2：承認者を明示する

事前承認が必要な操作について、誰が承認するのかを決めます。その人が不在のときの代行者も決めておきます。承認者が決まっていないと、承認待ちで業務が止まります。

設計3：責任は人に残す

「エージェントが間違えた」は、対外的には通用しません。最終的な責任は、その業務を所管する部署と、承認した人に残ります。この前提を明示しておくことで、承認が形骸化するのを防げます。

設計4：停止権限を広く持たせる

異常に気づいた人が、誰でも即座に止められる状態にしておきます。停止の権限を管理者だけに限定すると、夜間や休日に異常が起きたときに止められません。

中堅企業にとっての現実的な進め方

すべてを一度にやろうとせず、次の順序を推奨します。

第1段階（1ヶ月）：業務の棚卸しと対象の選定 主要な部署で、時間を食っている業務を洗い出します。前掲の4条件に照らして、最初の対象を1つ決めます。この段階では基盤の選定は行いません。

第2段階（2週間）：目標と撤退条件の設定 現状の所要時間を実測し、目標値と撤退条件を文書にします。経営会議で承認を取ります。

第3段階（1ヶ月）：小さく試す この段階で初めて基盤を選びます。ただし、いきなり本格導入せず、既存の生成AIサービスや小規模な構成で、業務が本当に自動化できるかを確かめます。ここで例外処理の存在が洗い出されます。

第4段階：基盤の本格選定 第3段階の結果を持って、基盤を比較します。実際に何が必要かが分かった状態での比較なので、提案の良し悪しを判断できます。

第5段階：段階的な展開 一部門から始め、監査ログを見ながら範囲を広げます。

この順序の要点は、基盤の選定を第4段階まで遅らせることです。 何が必要か分からない状態で基盤を選ぶと、ベンダーの提案の言葉でしか評価できません。

FAQ

Q1. まずどの基盤を試すべきですか。 A. その問いに答える前に、対象業務を決めてください。業務が決まれば、必要な接続先（グループウェア、基幹システム等）が決まり、選択肢は自然に絞られます。

Q2. 小規模な会社でもエージェント基盤は必要ですか。 A. 必ずしも必要ではありません。1つ2つの業務であれば、既存の生成AIサービスと簡易な自動化で足りる場合があります。基盤が必要になるのは、複数の業務を統制のもとで運用する段階からです。

Q3. すでにPoCを実施していますが、本番に進めません。 A. 対象業務の選定、例外処理の洗い出し、責任の所在、撤退条件のいずれかが欠けている可能性が高いです。技術的な問題ではないことが多く、まず4点を点検してください。

Q4. ロックインが心配です。避ける方法はありますか。 A. 完全に避けることはできません。現実的な対応は、①評価用データを自社で持つ ②業務手順の文書を自社で持つ ③接続の仕様を把握しておく、の3点です。これらがあれば、乗り換え時の作り直しの範囲が限定されます。

Q5. 費用はどれくらいを見込めばよいですか。 A. 基盤の利用料だけでなく、業務整理・接続開発・運用体制の費用が発生します。基盤利用料だけで予算を組むと、必ず不足します。第3段階の小規模実験の段階で、実際の作業量を測ってください。

Q6. 社内に技術者がいません。それでも進められますか。 A. 業務の棚卸しと対象選定、目標と撤退条件の設定は、技術者がいなくてもできます。むしろ、この部分は業務を知っている人にしかできません。技術的な部分は外部の支援を得る形で構いません。

Q7. 発表された製品は日本でも使えますか。 A. 提供形態・提供地域は製品ごとに異なり、発表直後は限定的な場合があります。導入を検討する際は、日本国内での提供状況とサポート体制を確認してください。

関連する判断は3つの記事に分けている

本稿は「基盤選定という意思決定の性質」を扱っています。隣接する判断は、それぞれ別の記事で掘り下げました。

• 提案書が本物のエージェントかを見抜く：ベンダーの「AIエージェント対応」という表現が、実際には既存機能の言い換えである場合があります。RFPで聞くべき質問はAgent Washingを見抜くRFP質問集にまとめました。
• PoCから本番へ進む条件：本稿の「撤退条件を先に決める」と対になる論点です。何が満たせたら本番判断してよいかはAgentic AIのPoC卒業チェックリストで12項目に分解しています。
• 権限設計の具体項目：ロックインの中心は権限とガードレールの作り込みです。承認、監査ログ、停止条件の設計項目はAIエージェント導入前チェックリスト（権限設計）にあります。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、製品選定の前に整理することをおすすめします。

• AIエージェントを導入したいが、どの業務から始めるべきか決められない。
• ベンダーから基盤の提案を受けているが、自社に必要な機能かどうか判断できない。
• PoCは動いたが、本番展開の判断ができないまま止まっている。
• 撤退条件や責任の所在を、どう決めればよいか分からない。

GXOは特定のエージェント基盤を販売する立場ではないため、「導入しない」「まだ早い」という結論も含めて整理できます。 まずAI導入診断で、対象業務、7日処理の停止・承認、MCP接続、費用、出口を第三者評価します。実装へ進む場合はAIエージェント導入の相談、AI開発・活用の相談、社内準備の確認はAI導入レディネス診断へ分流できます。

基盤選びは、製品の優劣を当てるゲームではありません。自社の業務のどこにAIを差し込むかを決める作業であり、その答えはベンダーの提案書の中にはありません。

参考文献

• OpenAI「Introducing OpenAI Presence」（一次・公式、2026年7月22日）: https://openai.com/index/introducing-openai-presence/
• Google Cloud Blog「13 demos on Gemini Enterprise Agent Platform」（一次・公式、2026年7月17日。デモの分類・内容は本記事執筆時に当該ページで確認）: https://cloud.google.com/blog/products/ai-machine-learning/13-demos-on-gemini-enterprise-agent-platform
• Google Cloud「Gemini Enterprise Agent Platform 公開履歴」（一次・公式、2026年8月31日確認。4月22日の名称変更、最長7日処理、機能別提供段階、5月6日の音声トラック抽出修正）: https://docs.cloud.google.com/gemini-enterprise-agent-platform/release-notes

※各製品の提供形態、提供地域、機能の詳細については、提供各社の公式情報を一次情報としてご確認ください。報道で言及されている他社の同種製品については、公式発表を確認できた範囲に記述を限定しています。初回記述は2026年7月24日、Google Cloud更新部分は2026年8月31日時点です。