投稿者 投稿日: カテゴリー Gemini
Managed Agents APIとは、Gemini APIの1回の呼び出しでAIエージェントを実行環境ごと起動できる機能のことです。
2026年5月19日、GoogleはI/O 2026でAntigravity 2.0とManaged Agentsを同時発表しました。前者は複数のAIエージェントを並列に走らせる常駐型のデスクトップアプリ、後者はGemini APIの1回の呼び出しでエージェントの実行環境ごと立ち上がるAPI機能です。この2つがそろったことで、在庫監視・受注チェック・CS返信ドラフトといったECの定常業務を「複数のエージェントに分担させて同時に回す」構成が、自社でサーバを組まなくても検討できる段階に入りました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。公式発表で確認できた仕様を先に整理し、そのうえで在庫・受注・CS・商品データの4業務への当てはめ方と、AGENTS.md・SKILL.md・実行指示の設定・プロンプト例4本を実装します。読み終えた時点で、自店のどの業務から試すかを判断できる構成にしました。
Antigravity 2.0とManaged Agentsの登場で何が変わったのか
変化の核心は、AIエージェントの「実行環境」をGoogleが丸ごと引き受けるようになった点です。2026年5月19日付のGoogle公式ブログによれば、Managed Agentsは、推論・ツール利用・コード実行を隔離されたLinuxサンドボックス内で行うエージェントを、1回のAPI呼び出しで起動できる機能です。Interactions API経由とGoogle AI Studio上の両方から利用でき、2026年7月時点ではプレビュー提供という位置づけになっています。エージェントは標準でコード実行とWeb閲覧（ページの取得・処理）ができ、各インタラクションが生成した環境はファイルや状態を保持したまま後続の呼び出しで再開できます。つまり「昨日の作業の続き」をエージェントに引き継がせる運用が、APIの標準機能として用意されたわけです。
初代Antigravityは2025年11月に公開されたエディタ中心の開発環境でしたが、2.0では設計思想が入れ替わりました。主役はコードエディタではなくエージェントの管理画面です。公式発表では、複数エージェントの並列実行、処理を枝分かれさせる動的サブエージェント、決まった時刻にバックグラウンドで動くスケジュールタスク、Google AI Studio・Android・Firebaseとの連携が2.0の柱として挙げられています。初代からの経緯やデスクトップアプリとしての基本機能はGoogle Antigravity 2.0の概要記事で解説済みなので、本記事はManaged Agents API側との組み合わせに絞って進めます。
基盤モデルはGemini 3.5 Flashです。Googleの発表では、Gemini 3.1 Proをほぼすべてのベンチマークで上回りながら、他のフロンティアモデル比で4倍速いとされています。エージェント用途では1つのタスクの裏で何十回もモデル呼び出しが走るため、単発の賢さ以上に速度が業務の待ち時間へ直結します。
周辺の動きも押さえておく必要があります。TechCrunchの報道によれば、Gemini CLIの利用者は2026年6月18日までにAntigravity CLIへ移行する必要があり、それ以降Gemini CLIは動作しなくなります。ターミナル派向けのAntigravity CLI、Googleのエージェントハーネス（エージェントの実行制御基盤）を自社インフラで動かせるAntigravity SDKも同時に公開されました。料金面では、Antigravityの利用上限がGoogle AI Proプランの5倍になる月額100米ドルのGoogle AI Ultraプランが新設されています。
EC事業者にとっての意味を言い切ると、「エージェントを業務に常駐させる」ためのインフラ構築が要らなくなった、ということです。これまではサンドボックスの用意・監視・スケール対応が前提で、専任エンジニアのいない店舗には縁遠い話でした。Googleはこの複雑さを抽象化したと公式に明言しています。なお名称について1点補足すると、「Managed Agents API」という独立したAPIが存在するわけではなく、正式にはGemini APIのInteractions API経由で使う「Managed Agents」という機能です。本記事では検索されやすい呼び名としてManaged Agents APIという表記も併用します。
在庫・受注・CS・商品データ：EC業務のどこから当てるか
先に順序を示すと、最初に当てるべきは「読み取り中心で、失敗してもすぐ気づける業務」です。具体的には在庫監視と商品データ検査が先、受注処理とCS返信は人間の確認を挟むドラフト生成までが、2026年7月時点の現実的な線と判断します。Managed Agentsのエージェントはコード実行・ファイル操作・Web閲覧を自律的に行うぶん、書き込み権限まで渡した場合の事故の影響範囲が広いためです。現場で繰り返し見るのは、最初から全部任せようとして検証が追いつかず、結局使われなくなるパターンでした。
在庫監視は最も入りやすい入口です。楽天RMSやAmazonセラーセントラルからダウンロードした在庫CSVをサンドボックスに渡し、閾値割れSKUの抽出、直近の出荷ペースからの欠品予測日の計算、担当者向けアラート文の生成までを1回のインタラクションで行わせます。環境がファイルと状態を保持するため、翌日は当日分のCSVだけ渡して「昨日との差分」を出させる運用が組めます。ある食品ジャンルの中規模店舗の事例では、繁忙期の在庫目視チェックに毎朝40分前後かかっていました。この種の定型確認は、コード実行型エージェントの守備範囲にきれいに収まります。
受注処理では、注文データの突合と異常検知が本命です。複数モールの受注CSVを読み込ませ、住所不備、同一人物の注文重複、のし・ギフト指定の見落とし、送料設定の矛盾といった異常候補を洗い出させます。ここで出荷指示の作成まで自動化するのではなく、「異常候補リストを人間がレビューする」段階で止める設計が安全です。誤出荷は1件あたりの再送コストと信頼毀損が大きく、検知率9割の自動化より、見落としゼロに近づける半自動化のほうが費用対効果で勝るケースが多く見られます。
CS対応は、問い合わせの分類と返信ドラフト生成に絞ります。後述するSKILL.mdに自店のトーン、返金・交換ポリシー、使ってはいけない表現を書いておくと、担当者ごとにばらつきがちな一次返信の品質がそろいます。自動送信までは踏み込まないのが定石です。誤送信のリスクに加えて、モールのメッセージ運用ルールとの整合を毎回確認する手間を考えると、送信ボタンは人間が押す設計に利があります。
商品データ整備は、コード実行との相性が特に良い領域です。商品名の文字数超過（楽天市場は半角255文字、Amazon.co.jpは半角200文字が上限）、規約上使えない最大級表現の混入、必須属性の欠落といった検査は、数千SKUあっても機械的に回せます。どのAIをこの用途の軸に据えるかは、Gemini・ChatGPT・Claudeの比較記事で整理した判断軸がそのまま使えます。すでにGoogle Workspaceでリサーチや資料作成を回している店舗なら、NotebookLMからGemini Notebookへの改名に見られるようにGoogleがエコシステムの統合を急いでいる流れに乗り、Google系へ寄せる判断に合理性があります。
実装手順：AGENTS.mdとSKILL.mdでEC用エージェントを定義する（設定・プロンプト4本）
この章では、設定・プロンプト例を4本実装します。内訳は、AGENTS.mdによるエージェント定義が1本、SKILL.mdによるスキル定義が1本、Interactions APIまたはAI Studioに渡す実行指示プロンプトが2本です。Managed Agentsの特徴は、複雑なオーケストレーションコードを書く代わりに、エージェントの振る舞いをMarkdownファイルとして定義できる点にあります。公式の開発者ドキュメントにはカスタムエージェントのテンプレートも用意されているので、ゼロから書く必要はありません。
手順はシンプルです。第一に、Google AI StudioのPlaygroundでManaged Agentsのカスタムテンプレートを開き、動作を確かめます。プログラミング不要で試せるのはこの経路です。第二に、AGENTS.mdへエージェントの役割・制約・出力形式を書き、カスタムエージェントとして登録します。第三に、繰り返し使う専門処理をSKILL.mdへ切り出します。第四に、Interactions APIから呼び出し、返ってきた環境IDを保存して翌日以降のインタラクションで再利用します。以下、EC業務向けの実装例です。
（用途タイトル：在庫監視エージェントの定義）
まずAGENTS.mdの例です。エージェントに「何をしてよいか」だけでなく「何をしてはいけないか」を明記するのが、業務投入時の要点になります。
プロンプト1：AGENTS.md（在庫監視エージェント定義）
# 在庫監視エージェント
## 役割
あなたは日本のEC店舗の在庫監視を担当するエージェントです。
アップロードされた在庫CSV（列: SKU, 商品名, 現在庫数, 過去7日出荷数, 発注リードタイム日数）を分析します。
## 実行すること
1. 現在庫数 ÷ 1日平均出荷数 で在庫日数を計算する
2. 在庫日数が発注リードタイム日数を下回るSKUを「発注推奨」として抽出する
3. 現在庫数が {閾値} 個未満のSKUを「緊急」として抽出する
4. 前回実行時のCSVが環境内に残っている場合は、出荷ペースが前回比150%以上に
急伸したSKUを「急伸アラート」として別枠で報告する
## 禁止事項
- 発注や在庫数の更新など、外部システムへの書き込みは行わない
- CSVに存在しないSKUや数値を推測で補わない。欠損は「データ欠損」と明記する
## 出力形式
緊急 → 発注推奨 → 急伸アラート の順に、SKU・商品名・根拠数値を1行ずつ。
最後に「本日の要対応件数: N件」で締める。
（用途タイトル：CS返信ドラフトのスキル化）
次にSKILL.mdです。店舗ごとのポリシーをスキルとして固定しておくと、誰が呼び出しても同じ品質の一次ドラフトが返ります。
プロンプト2：SKILL.md（CS返信ドラフト生成スキル）
# スキル名: cs-reply-draft
## 概要
日本のEC店舗の問い合わせメールに対する返信ドラフトを生成する。
## 手順
1. 問い合わせ本文を「配送」「返品・交換」「商品仕様」「その他」に分類する
2. 分類に応じて、下記ポリシーの範囲内で返信ドラフトを1通作成する
3. ポリシーで判断できない要求が含まれる場合は、ドラフトを作らず
「要エスカレーション」とだけ出力し、理由を1行添える
## 店舗ポリシー
- 返品・交換: 未開封のみ到着後 {日数} 日以内、送料は {負担区分}
- 配送: 出荷は営業日 {時刻} 締め、追跡番号は出荷当日中に通知
- 文体: ですます調。冒頭は「お問い合わせありがとうございます」で統一
## 禁止事項
- 値引き・補償の約束をしない
- 「必ず」「確実に」など断定的な納期表現を使わない
- レビュー投稿の依頼文を入れない
（用途タイトル：商品データの一括検査）
3本目は実行指示プロンプトです。Google AI StudioのPlaygroundに貼るか、Interactions APIのリクエスト本文として送ります。コード実行を前提にした指示の書き方がポイントで、判定基準を数値で渡すほど結果が安定します。
プロンプト3：実行指示（商品CSVの規約・文字数一括検査）
アップロードした商品CSV（列: 商品管理番号, 商品名, キャッチコピー, 販売価格）を
コードで検査し、以下の違反候補を抽出してください。
検査項目:
1. 商品名が半角255文字（全角換算127文字）を超える行（楽天市場の上限）
2. 商品名・キャッチコピーに以下の語を含む行:
「日本一」「完璧」「業界初」（根拠資料が登録されていないため使用不可）
3. キャッチコピーが半角174文字を超える行
4. 販売価格が0円または空欄の行
出力:
- 検査項目ごとに該当の商品管理番号を列挙し、修正案を1行ずつ添える
- 全件数と違反率（%）をまとめる
- 該当ゼロの項目は「問題なし」とだけ書く
注意: CSVにない情報を推測で補わないこと。
（用途タイトル：受注突合と環境の再利用）
4本目は、環境の保持を前提にした受注チェックの指示です。初回に前提ファイルを渡しておき、2回目以降は当日分だけ追加する運用を想定しています。
プロンプト4：実行指示（受注データの異常検知・前回環境の再利用）
この環境には前回までの受注チェック結果（checked_orders.csv）が保存されています。
本日アップロードした受注CSV（列: 注文番号, 氏名, 住所, 電話番号, 商品コード,
個数, のし指定, 支払方法）を追加で検査してください。
検査内容:
1. 住所の欠損・番地なし・郵便番号と都道府県の不一致
2. 同一の氏名・住所・商品コードで24時間以内に重複した注文
3. のし指定ありなのに備考欄が空の注文
4. checked_orders.csv に既に存在する注文番号（二重取り込みの疑い）
出力:
- 異常候補のみを注文番号つきで列挙し、疑いの理由を1行ずつ添える
- 異常がなければ「本日の異常候補: 0件」と書く
- 検査済みの注文番号を checked_orders.csv に追記して保存する
この結果は人間がレビューします。出荷可否の最終判断はしないでください。
仕上げに、Antigravity 2.0デスクトップアプリ側のスケジュールタスクへこれらを載せると、毎朝の実行が自動化されます。編集部で実際に運用しているプロンプトでは、実行結果の末尾に「要対応件数」を必ず出させる形式にしており、担当者は件数がゼロなら本文を読まずに次の業務へ移れます。
失敗例と回避策
直近の支援案件で観測したのは、技術よりも設計の失敗です。よくある3パターンを回避策とセットで挙げます。
1つ目は、初日から書き込み権限を渡してしまうケースです。在庫更新や注文ステータス変更までエージェントに任せると、判定ミスが実害に直結し、原因調査にも時間がかかります。回避策は明快で、最初の1〜2か月は「読み取り＋レポート生成」に限定し、エージェントの判定精度をログで確認してから範囲を広げる段階設計にすることです。プロンプト1・4に禁止事項を明記したのはこのためです。
2つ目は、モール規約に触れる処理を自動化してしまうケースです。CS返信にレビュー投稿の依頼を差し込む、楽天市場のメッセージに外部サイトへの誘導を入れる、といった処理が該当します。Amazonでは特典と引き換えのレビュー依頼が規約違反にあたり、楽天市場では店舗ページやメールからの外部誘導が認められていません。回避策は、SKILL.mdの禁止事項に規約由来のNGを明文化し、規約が絡む出力は必ず人間の承認を挟むフローにすることです。
3つ目は、エージェントの出力を無検証で業務に反映するケースです。Managed Agentsはコード実行で数値処理の再現性が高い一方、CSVの列取り違えや文字コード起因の読み込み不良が起きると、もっともらしい誤集計が返ることがあります。回避策として、導入初期は同じデータを従来の手作業と並走させて突合し、乖離ゼロを2週間程度確認してから片寄せする移行手順が望ましい。検算用に合計値と件数を必ず出力させる指示も有効です。
KPI設計と費用・工数の目安
費用は2段構えで考えます。個人・小規模で試すなら、Google AI Proが月額19.99米ドル、Antigravityの利用上限が5倍になるGoogle AI Ultraが月額100米ドルです（2026年7月時点）。Managed Agents機能自体はプレビュー提供のため、API従量課金の確定単価は公式ドキュメントでの要確認事項です。比較対象として、ChatGPT Plusは月額20米ドル、Claude Proも月額20米ドルで、エージェント常駐型の運用に踏み込む場合の月額コスト感は各社とも数十〜100米ドル帯に収まります。
KPIは「削減時間」と「検知件数」の2軸で置くのが実務的です。削減時間の例では、在庫の目視チェック毎朝40分がレポート確認10分になれば月10時間の削減、CS一次返信のドラフト作成が1通8分から2分になれば、月300通の店舗で30時間の削減という計算になります（いずれも導入前の実測を基準にした目安）。検知件数の側は、受注異常の検知数、商品データの規約違反候補の検出数を月次で記録し、人間のダブルチェックで見つかった「エージェントの見落とし」件数と並べて精度を追います。5,000社支援の中で何度も再現したパターンとして、削減時間だけをKPIにすると精度劣化に気づくのが遅れるため、見落とし件数の記録は省かないことを勧めます。
工数面では、初期設定に2〜3営業日を見込むのが現場感覚です。AGENTS.md・SKILL.mdの初稿づくりに半日、テストデータでの検証と修正に1〜2日、既存業務フローへの組み込み説明に半日という配分が目安になります。外注せずに済む水準まで敷居が下がったことこそ、この仕組みの価値と言えます。
今後の展望：エージェント並列が標準になったあとのEC運営
モデル側の進化は止まっていません。2026年7月17日にはGemini 3.5 Proが公開され、200万トークンのコンテキストを扱えるようになりました。全SKUの商品データと過去の受注履歴をまとめて1つの文脈に載せる分析が視野に入る規模です。競合も、OpenAIが7月9日にGPT-5.6ファミリー（Sol・Terra・Luna）を投入し、AnthropicはClaude Opus 4.8やSonnet 5に加えてフラッグシップのFable 5を展開しています。そのなかでGoogleはAntigravityでデスクトップ・CLI・SDK・APIの4面を一気にそろえ、EC事業者から見ると入口の多さで頭ひとつ抜けた構成になりました。
構造的な変化として押さえたいのは、AI活用の単位が「1回の質問」から「常駐する担当」へ移っていることです。従来のChatGPT活用は、人間が思いついたときに聞きに行く道具でした。スケジュールタスクと状態を保持する環境がそろうと、エージェントは毎朝決まった時刻に自分の担当業務を済ませて報告してくる存在に変わります。店長の仕事は作業そのものから、エージェントの成果物をレビューし、AGENTS.mdという「業務マニュアル」を改訂することへ寄っていきます。マニュアル整備が苦手な店舗ほど恩恵が薄くなる、という逆説がここに生まれます。
もう1点、Tier2の競合メディアがまだ書けていない論点として、Managed Agentsは「業務手順の資産化」を強制する仕組みだと捉えています。AGENTS.mdやSKILL.mdは、属人化していた判断基準をテキストに書き下ろさない限り機能しません。逆に言うと、書き下ろした店舗はモデルが世代交代しても定義ファイルを持ち運べます。プレビュー段階の機能に今から触れておく意味は、API仕様の先取りよりも、この「自店の業務を機械可読にしておく」訓練にあると考えます。仕様変更やSLAなしのプレビュー提供という但し書きを踏まえても、読み取り専用の検査業務から着手するぶんにはリスクは限定的です。
よくある質問
Managed Agents APIは無料で使えますか
はい、試すだけならGoogle AI StudioのPlaygroundで無料枠から始められます。Managed Agentsは2026年7月時点でプレビュー提供のため、API利用時の確定単価は公式ドキュメントでの要確認事項です。業務で常用する場合は、Google AI Pro（月額19.99米ドル）またはAI Ultra（月額100米ドル）を軸に検討するのが現実的です。
Antigravity 2.0とManaged Agents APIはどう違いますか
Antigravity 2.0とは、複数エージェントを並列管理するデスクトップアプリのことで、Managed AgentsはGemini API経由で同じエージェント基盤を呼び出す機能です。人間が画面で操作するならAntigravity 2.0、自社のツールや業務システムに組み込むならManaged Agentsという使い分けになります。両者は同じAntigravityエージェントハーネスを共有しています。
プログラミングの知識がなくても使えますか
はい、Google AI StudioのPlaygroundとカスタムテンプレートを使えば、コードを書かずに試せます。エージェントの定義もAGENTS.md・SKILL.mdというMarkdownの文章ファイルで済むため、必要なのはプログラミングよりも自店の業務手順を言語化する力です。API連携まで進む段階で、はじめて開発の知識が要ります。
Gemini CLIを使っていた場合はどうなりますか
いいえ、そのままでは使い続けられません。TechCrunchの報道によれば、Gemini CLIは2026年6月18日以降動作しなくなり、Antigravity CLIへの移行が必要です。移行後は、CLIからも新しいエージェント作成が行えるため、ターミナル中心の運用は維持できます。
ChatGPTやClaudeのエージェント機能と何が違いますか
最大の違いは、隔離されたLinux実行環境と状態の保持がAPIの標準機能として付いてくる点です。各社ともエージェント機能の強化を競っていますが、Googleはデスクトップ・CLI・SDK・APIの4つの入口を同一のハーネスでそろえました。モデル単体の性能比較や自店に合う選び方は、本文で触れた比較記事の判断軸が参考になります。
楽天RMSやAmazonセラーセントラルに直接つなげられますか
いいえ、公式にモール管理画面と直結する連携が用意されているわけではありません（2026年7月時点）。現実的な運用は、RMSやセラーセントラルからダウンロードしたCSVをエージェントの環境に渡す方式です。楽天RMSのWEB APIやAmazonのSP-APIと接続する構成は技術的には検討できますが、認証情報の管理を含めて開発案件になるため、まずはCSV運用から始めるのが安全です。
まとめ：最初の一歩は「読み取り専用の検査業務」から
Antigravity 2.0とManaged Agents APIの組み合わせは、エージェント活用の敷居をインフラ構築ゼロまで下げました。始め方の答えはシンプルで、在庫監視か商品データ検査のどちらかを選び、本記事のプロンプト1または3を自店の列名に書き換えて、Google AI Studioで2週間並走させることです。そこで精度と削減時間の実測が取れたら、受注突合、CS返信ドラフトへと広げていく。書き込み権限は最後まで慎重に、という順番さえ守れば、プレビュー段階でも得られるものは大きいはずです。
参考文献
- Google公式ブログ「Introducing Managed Agents in the Gemini API」
- Google公式ブログ「Building the agentic future: Developer highlights from I/O 2026」
- Google AI for Developers「Interactions API」
- TechCrunch「Google launches Antigravity 2.0 with an updated desktop app and CLI tool at IO 2026」
著者：齋藤竹紘（株式会社オルセル 編集長／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実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
