投稿者 投稿日: カテゴリー Gemini
Gemini Enterprise Agent Platformとは、旧Vertex AIを継ぐGoogleのエージェント開発基盤のことです。
自社のEC業務にAIエージェントを入れたいとき、Googleの基盤を選ぶべきかどうかは、「社内にAPIを触れる技術担当がいるか」と「業務データがすでにGoogle Cloudにあるか」の2点でほぼ決まります。Googleは2026年4月のGoogle Cloud Next ’26で、Vertex AIのサービスを統合した「Gemini Enterprise Agent Platform」を発表し、今後のVertex AIの機能追加はこの基盤を通じて提供すると説明しました。200以上のAIモデルを選べ、エージェントの権限管理や監視の仕組みまでそろっている一方、対象はあくまで技術チームです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、EC業務のどこにこの基盤が向き、どこには向かないのかを、構築手順とプロンプト5本を交えて整理します。
Vertex AIから何が変わったのか
Gemini Enterprise Agent Platformの最大の変化は、AIモデルを呼び出す基盤だったVertex AIが、エージェントを作り、動かし、統制するための基盤にまとめ直された点です。Googleの公式ブログは2026年4月22日付で、この基盤を「自律的なエージェントのためのワンストップの場所」と位置づけ、Vertex AIのモデル構築・調整機能に、エージェントの連携、セキュリティ、運用の機能を加えたものだと説明しています。
構成要素は多岐にわたります。豪州のeCommerceNewsの報道によると、ノーコードに近い操作でエージェントを作る「Agent Studio」、コードで細かく作り込む「Agent Development Kit（ADK）」、数日間動き続けるエージェントにも対応するよう作り直された実行環境「Agent Runtime」、長期間の文脈を保持する「Memory Bank」、請求書処理などのひな形を集めた「Agent Garden」が用意されています。統制の面では、エージェントごとに暗号学的な識別子を割り当てる「Agent Identity」、承認済みのエージェントやツールを登録する「Agent Registry」、セキュリティポリシーを強制する「Agent Gateway」があり、異常な振る舞いを検知する仕組みや、公開前の試験を行う「Agent Simulation」「Agent Evaluation」、稼働中の会話や処理経路を確認する「Agent Observability」までそろっています。
選べるモデルは、Model Gardenを通じて200以上です。Google自身のGemini 3.1 Pro、画像生成のGemini 3.1 Flash Image、音楽生成のLyria 3、オープンモデルのGemma 4に加え、AnthropicのClaude Opus、Sonnet、Haikuも名前が挙がっています（発表時点の情報。その後Gemini 4系などの新モデルも登場しており、基盤上での提供状況は公式の最新情報で要確認）。社内のデータやツールへの接続に加え、BigQueryやPub/Subを使ったバッチ処理やイベント駆動の処理にも対応しています。
導入企業としては、PayPal、Comcast、L’Oréalなどとともに、日本のぐるなびも名前が挙がりました。PayPalは、AIエージェントによる支払いの仕組みであるAP2（Agent Payment Protocol）を使ってエージェントを本番運用していると紹介されています。ADKはGeminiモデル上で月6兆トークン以上を処理しているとGoogleは説明しており、開発者向けの基盤としてすでに大きな利用規模があることがうかがえます。
日本のEC事業者から見ると、この基盤は「自社のデータとシステムにつながった業務エージェントを、権限と監視つきで動かす場所」です。ChatGPTやClaudeの画面で個人が使うAIとは、目的も導入の重さも違います。この違いを押さえておかないと、過剰な投資にも、逆に統制のない野良エージェントの乱立にもつながります。
EC業務で向く業務、向かない業務
この基盤が向くのは、「データがすでにGoogle Cloudにあり、毎日同じ判断を大量に繰り返す業務」です。反対に、少人数の店舗で、担当者がブラウザで管理画面を触っている業務の多くは、ここまでの基盤を必要としません。
向く業務の1つ目は、受注や問い合わせの一次仕分けです。楽天市場、Amazon、自社ECの受注データをBigQueryに集約している事業者なら、新しい注文や問い合わせが入るたびにPub/Subで通知を受け、エージェントが「通常処理」「住所不備の確認」「キャンセル希望」「クレーム」に仕分ける流れを組めます。Agent Observabilityで判断の経路を後から追えるため、誤った仕分けの原因も調べやすくなります。
2つ目は、数日単位で続く監視業務です。Agent Runtimeが長時間稼働に対応したことで、セール期間中の在庫や価格を見張り、閾値を割ったら担当者に知らせるといった使い方が現実的になりました。楽天スーパーSALEやAmazonのブラックフライデーのように、数日間にわたって状況が動き続けるイベントとの相性は良好です。
3つ目は、請求書や仕入れ書類の処理です。Agent Gardenに請求書処理のひな形が用意されているため、仕入先から届くPDFの請求書を読み取り、発注データと金額を突き合わせる業務は、最初の題材として取り組みやすい部類に入ります。直近の支援案件で観測したのは、仕入れ先が20社を超えたあたりから、照合作業が経理担当の月末を圧迫しはじめるというパターンでした。
向かない業務もはっきりしています。まず、技術担当がいない少人数の店舗です。この基盤は技術チーム向けと明言されており、一般の社員にはGemini Enterpriseアプリを入口として使わせる設計です。商品説明文の作成やレビューの要約のような個人作業なら、Gemini、ChatGPT、Claudeの通常の画面で十分にこなせます。
次に、モールの管理画面をブラウザで操作することが前提の業務です。楽天RMSやAmazon Seller Centralの画面をエージェントに直接操作させるより、楽天のRMS WEB SERVICEやAmazonのSP-API、ShopifyのAdmin APIといった公式のAPIを通じてデータをやり取りするほうが、権限管理と安定性の両面で安全です。APIで取れないデータを無理にエージェントで取りにいく設計は、規約面の確認も含めて慎重に判断してください。
最後に、支払いを伴う判断をいきなりエージェントに任せることです。AP2のような仕組みは整いつつありますが、返金や仕入れの発注といったお金が動く処理は、まず人の承認を挟む設計から始めるのが定石です。
構築手順と、設計に使うプロンプト5本
構築は、「業務の棚卸し」「指示書づくり」「試験」「権限設計」「運用の振り返り」の5段階で進めると迷いません。基盤の操作そのものより、各段階で何を決めるかのほうが成否を分けます。以下のプロンプトは、設計資料を作る段階でGemini、ChatGPT、Claudeのいずれでも使える形にしてあります。
最初の段階は、エージェント化する業務の選定です。全業務を一度に対象にせず、判断基準が明文化できる業務から選びます。
プロンプト1：エージェント化候補の業務棚卸し
あなたはEC事業の業務改善コンサルタントです。以下の業務一覧について、AIエージェントに任せる候補としての適性を評価してください。
評価軸：
1. 判断基準を文章で書けるか（書ける／一部書ける／書けない）
2. 1日あたりの処理件数
3. 誤判断したときの損害（小／中／大）
4. 必要なデータがAPIまたはデータベースで取得できるか
出力：業務ごとに4軸の評価と、「最初に着手すべき」「後回し」「人が続けるべき」のいずれかの結論を1行で
業務一覧：{業務名と概要を列挙}
2つ目の段階は、エージェントへの指示書（システム指示）づくりです。受注や問い合わせの仕分けなら、仕分け先ごとの条件と、迷ったときの扱いを明記します。
プロンプト2：問い合わせ仕分けエージェントの指示書作成
以下の条件で、問い合わせ仕分けエージェントに与える指示書を作成してください。
仕分け先：{通常回答、配送確認、返品・交換、クレーム、その他}
条件：
1. 各仕分け先の判定条件を、問い合わせ文に含まれる語や状況で具体的に書く
2. 判定に迷う場合は「その他」に回し、推測で振り分けない
3. 顧客への返信文は作成しない（仕分けと理由の記録だけを行う）
4. 個人情報（氏名、住所、電話番号）は記録に転記しない
5. 出力は「仕分け先／判定理由／確信度（高・中・低）」の3項目
3つ目の段階は、公開前の試験です。Agent SimulationやAgent Evaluationに投入するテストケースを、意地の悪い例も含めて用意します。
プロンプト3：評価用テストケースの生成
問い合わせ仕分けエージェントを試験するためのテストケースを30件作成してください。
内訳：
・判定が明確な典型例 15件
・複数の仕分け先にまたがる例 8件
・皮肉や遠回しな表現を含む例 4件
・仕分け先のどれにも当てはまらない例 3件
各ケースに「問い合わせ文」「期待する仕分け先」「この例で確かめたいこと」を付けてください。
商品ジャンル：{ジャンル}
4つ目の段階は、権限の設計です。Agent IdentityやAgent Gatewayで設定する内容を、先に文章で決めておきます。
プロンプト4：最小権限の設計書
以下のエージェントについて、必要最小限の権限を設計してください。
エージェントの役割：{役割}
接続するシステム：{BigQueryのデータセット名、受注システム、チャットツールなど}
出力：
1. 読み取りだけ許可するデータ
2. 書き込みを許可する操作（理由付き）
3. 明示的に禁止する操作（返金、価格変更、顧客データの外部送信など）
4. 人の承認を必須にする操作
5. 権限を見直す頻度と担当者
5つ目の段階は、運用ログの振り返りです。Agent Observabilityで確認したログをまとめ、週に1度、指示書を直す材料にします。
プロンプト5：運用ログの週次レビュー
以下は今週のエージェントの判定ログ（個人情報は削除済み）と、人が修正した結果です。
次の3点を分析してください。
1. 人が修正したケースに共通する特徴
2. 指示書のどの条件が曖昧だったか
3. 指示書の修正案（変更前と変更後を並べて提示）
修正案は、判定基準を緩めるのではなく、条件を具体化する方向で作ってください。
判定ログ：{ログ}
5本のうち、最も効果が大きいのはプロンプト3です。編集部で実際に運用しているプロンプトでも、意地の悪いテストケースを最初に用意しておいたエージェントほど、本番で想定外の判定を出す回数が少なくなりました。
失敗例と回避策
エージェント基盤の導入で起きやすい失敗は、技術よりも業務設計の側にあります。現場で繰り返し見るのは、次の3つです。
1つ目は、対象業務を広げすぎる失敗です。「問い合わせ対応を全部エージェントに」と始めると、判定基準が書けない例外対応まで抱え込み、結局は人がすべて確認する状態に戻ります。回避策は、プロンプト1で「判断基準を文章で書ける」業務だけを選び、仕分けのような小さな役割から始めることです。返信文の自動作成は、仕分けの精度が安定してから次の段階として検討します。
2つ目は、権限を広く渡しすぎる失敗です。開発中の手間を省くために、管理者に近い権限のままエージェントを動かすと、誤作動したときに価格や在庫を書き換えてしまう危険があります。Agent IdentityとAgent Gatewayを使い、プロンプト4で決めた最小権限から始めてください。返金や価格変更のようにお金と直結する操作は、当面は人の承認を必須にするのが望ましい設計です。
3つ目は、顧客情報の扱いを後回しにする失敗です。問い合わせ文や受注データには、氏名や住所が含まれます。エージェントのログや記録に個人情報が残る設計にすると、保存期間や閲覧権限の管理が必要になります。楽天市場やAmazonから預かった購入者情報には、それぞれのモールが定める取り扱いのルールもあるため、ログに転記しない指示を指示書に入れ、社内規程と出店規約の両方を確認したうえで運用してください。
KPI設計と費用・工数の目安
KPIは、「エージェントが処理した件数」ではなく「人が修正せずに済んだ割合」と「担当者の作業時間の減少」で見るのが基本です。処理件数だけを追うと、誤判定の多いエージェントでも成果が出ているように見えてしまいます。
補助的な指標として、プロンプト2で出力させている「確信度」の分布も記録しておくと役に立ちます。確信度が「低」と判定されたケースの割合が週を追うごとに下がっていれば、指示書の条件が具体的になってきた証拠です。逆に、確信度が「高」なのに人が修正したケースは、指示書の条件そのものが誤っている可能性が高いため、最優先で見直す対象になります。こうした数字を毎週の定例で5分だけ確認する習慣をつけると、エージェントの品質を属人的な感覚に頼らずに管理できます。
問い合わせ仕分けを例にすると、最初の1か月は人の修正率を週ごとに記録し、修正率が一定水準を下回ってから、人の確認を抜き取り方式に切り替える流れが現実的です。5,000社支援の中で何度も再現したパターンとして、最初の2週間は修正率が高く、指示書を3〜4回直したあたりで安定してくる、という推移があります。
費用は、今回確認した公式ブログや報道では基盤全体の料金が示されておらず、利用するモデルのトークン量や実行環境の利用量などに応じた従量課金になると見られます（具体的な単価はGoogle Cloudの公式料金ページで要確認）。小さな仕分けエージェントであれば、モデルの利用料は月数千円から数万円の範囲に収まるケースが多いと見ていますが、処理件数と選ぶモデルで大きく変わります。
工数のほうが費用より重くなりがちです。業務の棚卸しから試験運用までを技術担当1人で進める場合、業務の複雑さにもよりますが、1〜2か月を見込むのが目安です。社内に技術担当がいない場合は、外部の開発会社と組むか、まずはGemini、ChatGPT、Claudeの通常プラン（いずれも個人向け有料プランは月額20米ドル前後が目安、最新価格は各社公式で要確認）で業務の型を作るところから始めるほうが、投資の回収は早くなります。
今後の展望と独自考察
今後の注目点は、エージェント同士の取引と支払いの標準化です。PayPalがAP2を使ってエージェントによる支払いを本番運用していることは、AIエージェントが商品を探して決済まで進める時代が、実験段階を抜けつつあることを示しています。うるチカラでも、ShopifyのShop MCPのように、AIエージェントが商品検索から決済まで完結させる動きを追いかけてきました。
EC事業者にとっての意味は2つあります。1つは、自社の業務を自動化する「内向きのエージェント」です。もう1つは、顧客側のAIエージェントが自社の商品を探しに来る「外向きのエージェント対応」です。Gemini Enterprise Agent Platformのような基盤は主に前者のためのものですが、後者に備えるうえでも、商品データや在庫データをAPIで正しく出せる状態にしておくことが共通の土台になります。
もう1つの論点は、モデルを1社に固定しない設計です。この基盤ではGeminiだけでなくClaudeも選べるため、仕分けは安価なモデル、難しい判断は上位モデルという組み合わせが1つの基盤の中で組めます。AIモデルは数か月単位で入れ替わっており、2026年秋にもGemini 4系やClaude Opus 5.5、GPT-6系が相次いで登場しました。特定のモデルの性能を前提に業務を組むより、モデルを差し替えても指示書と評価ケースが使い回せる設計にしておくことが、長く使える仕組みにつながると判断します。
よくある質問
Gemini Enterprise Agent Platformとは何ですか？
Gemini Enterprise Agent Platformとは、Googleが2026年4月に発表した、AIエージェントを作り、動かし、統制するための開発基盤のことです。従来のVertex AIのサービスを統合しており、今後のVertex AIの機能追加はこの基盤を通じて提供されます。
Vertex AIを使っていた場合、何か対応が必要ですか？
はい、今後の機能追加がこの基盤経由になるため、管理画面や名称の変化を把握しておく必要があります。報道では、既存のVertex AI利用者向けの後継として位置づけられています。具体的な移行手順や影響は、Google Cloudの公式ドキュメントで確認してください。
小規模なEC店舗でも使うべきですか？
いいえ、技術担当がいない小規模店舗では、まず通常のAIチャットで十分です。この基盤は技術チーム向けと明言されており、一般社員向けには別のGemini Enterpriseアプリが用意されています。業務の型ができ、データ連携が必要になった段階で検討するのが現実的です。
Claudeなど他社のモデルも使えますか？
はい、Model Gardenを通じて200以上のモデルが使え、AnthropicのClaude Opus、Sonnet、Haikuも挙げられています。用途に応じて、安価なモデルと上位モデルを使い分ける設計が可能です。最新の提供モデルは公式情報で確認してください。
楽天RMSやSeller Centralの操作をエージェントに任せられますか？
画面操作を直接任せるより、公式APIを通じたデータ連携を基本にすべきです。楽天のRMS WEB SERVICE、AmazonのSP-API、ShopifyのAdmin APIを使えば、権限を絞ったうえで安定してデータをやり取りできます。お金が動く操作は人の承認を挟んでください。
費用はどのくらいかかりますか？
基盤全体の料金は公式発表で明示されておらず、利用するモデルや実行環境の量に応じた従量課金になると見られます。小さな仕分けエージェントならモデル利用料は大きくなりにくい一方、設計と試験にかかる人件費のほうが重くなりがちです。正確な単価は公式の料金ページで確認してください。
まとめ
Gemini Enterprise Agent Platformは、Vertex AIを統合し、エージェントの構築から権限管理、監視までをそろえたGoogleの開発基盤です。EC業務では、BigQueryに集約した受注や問い合わせの仕分け、セール期間中の監視、請求書の照合のように、判断基準が書けて件数の多い業務に向いています。一方で、技術担当のいない小規模店舗や、管理画面の操作が前提の業務、お金が動く判断には、まだ慎重であるべきです。
最初の一歩は、プロンプト1で自社の業務を棚卸しし、「判断基準を文章で書ける」業務を1つ選ぶことです。モデルの比較はGemini 4 Argon・Claude Opus 5.5・GPT-6 Astraの比較記事、Gemini系の画面操作機能はGemini Computer Useの一般提供の解説、エージェント決済の流れはShopify Shop MCPの解説もあわせて参考にしてください。
参考文献
- Google公式ブログ「Gemini Enterprise Agent Platform」
- eCommerceNews Australia「Google Cloud launches Gemini Enterprise Agent Platform」
- THE Journal「Google Announces New Gemini Enterprise Agent Platform」
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
