Gemini Interactions APIとは？generateContent後継の統一API・料金・移行手順を解説

Gemini Interactions API（インタラクションズAPI）は、Googleが2025年12月にpublic betaで発表し、2026年6月に一般提供（GA）を開始した、Gemini モデルとエージェントを扱うための統一APIです。
従来の 「generateContent」 API の後継として位置づけられ、サーバー側で会話履歴を保持する Stateful 設計、実行ステップを記録する Steps レスポンス、Managed Agents、Background 実行などを1本のエンドポイントに集約しています。

本記事では、Interactions API の中核設計（Stepsレスポンスとサーバー側状態管理）、主要機能、Managed Agents、対応モデルと料金体系、generateContent からの移行手順、OpenAI Responses API・Anthropic Managed Agents との違い、そして移行判断で押さえるべき論点までを、2026年6月時点の最新情報で体系的に解説します。

Gemini Interactions APIとは？Gemini向けの統一エージェントAPI

Gemini Interactions API（インタラクションズAPI）は、Geminiモデルとエージェントを単一エンドポイントで扱うための統一APIです。

これまでの 「generateContent」 はチャット完結型で、エージェント的に動かそうとすると会話履歴の組み立てやツール呼び出しの後処理がアプリ側に積み上がっていました。
Interactions APIは、会話履歴をサーバー側で保持し、実行ステップを構造化レスポンスで返し、Managed AgentsやBackground実行までを1本のエンドポイントに集約する設計で、エージェントを動かすために自前で組んでいた配管をAPI側に寄せられます。

Interactions APIで刷新された2つの中核設計

Interactions APIは機能を増やしただけのアップデートではなく、「generateContent」 の前提をStepsレスポンス構造とサーバー側状態管理の2か所で書き換えた設計刷新です。

実行ステップを記録する Steps レスポンス

「generateContent」 のレスポンスは、「response.candidates[0].content.parts[0].text」 のように「最終出力テキスト」を取り出す形でした。

モデルが裏側でどのツールを呼んでどう判断したかは、「groundingMetadata」 などに散らばっていて、エージェント的に動かそうとすると後処理が大きくなります。

Interactions API ではレスポンスが 「steps」 という配列に置き換わり、モデルが結論に至るまでの実行プロセスが時系列でそのまま記録されます。

各 Step は以下の型を取ります。

• user_input
  ユーザーから渡された入力（テキスト・画像・ファイル等）
  
  

• thought
  モデル内部の推論ステップ（Thinking 対応モデルのみ。公式スキーマでは thought step、ログ・UIには thinking summary / thought summary として現れる）
  
  

• function_call
  モデルが呼び出したツール（Google Search・カスタム関数 等）と引数
  
  

• model_output
  モデルが返した最終出力

レスポンス全体は 「interaction.output_text」 という便利プロパティで最終テキストだけ取り出すこともできますが、エージェント挙動を可視化・デバッグしたい場合は 「interaction.steps」 を順に追っていけば、モデルの思考・ツール呼び出し・出力をそのまま再構築できます。

これは、UIに「モデルがいま何をしているか」を中間状態として描画する用途、あるいは内部監査ログとして実行プロセスを残す用途に直接効きます。

サーバー側で会話履歴を保持する設計

「generateContent」 の時代、マルチターン会話は「全履歴を 「contents」 配列に詰めて毎ターン送信する」のが基本パターンでした。会話が長引くほど入力トークンが膨らみ、API料金とレイテンシの両方を悪化させる構造です。

Interactions API では 「store=true」（デフォルト）でサーバー側に会話履歴を保存し、次のターンは前ターンの 「id」 を 「previous_interaction_id」 に渡すだけで履歴を引き継げます。

Python の例で比較すると以下のとおりです。

# generateContent（旧）: 履歴をクライアント側で組み立てる
chat = client.chats.create(model="gemini-2.5-flash")
r1 = chat.send_message("家に犬が2匹います")
r2 = chat.send_message("家には何本の足がありますか？")  # 履歴は内部で送り直し

# Interactions API（新）: サーバー側に履歴を保持
r1 = client.interactions.create(
    model="gemini-3.5-flash",
    input="家に犬が2匹います",
)
r2 = client.interactions.create(
    model="gemini-3.5-flash",
    input="家には何本の足がありますか？",
    previous_interaction_id=r1.id,
)

この設計変更により、履歴を組み立てて再送するクライアント側の実装負担が大きく下がります。さらに同一履歴で繰り返し呼び出すケースでは implicit caching が効きやすくなり、レイテンシ・コストの両面で改善が期待できる構造です。

「store=false」 を指定すればサーバー側に保存しない選択もでき、機密データを扱う場合は明示的にオフにできる設計です。ただし 「store=false」 は 「background=true」 および 「previous_interaction_id」 と併用できない制約があり、サーバー側状態を残さない代わりにこれらの機能も使えなくなる点に注意が必要です。

サーバー側に保存された Interaction は、Paid Tier では既定で55日間保持される設計です。長期に保持したくないデータは 「store=false」 を選ぶか、明示的に削除（「DELETE /v1beta/interactions/{id}」）する運用を組み込んでおくのが安全です。

Interactions APIの主要機能

Stepsレスポンスとサーバー側状態管理を土台に、Interactions API は3つの主要機能を新しい呼び出し方で提供します。

本セクションでは、Background 実行・Tool 統合・マルチモーダル生成を順に整理します。

Background 実行とポーリング設計

Deep Research のような background 実行対応の長時間処理を、HTTPの単一リクエストで待ち続けるのは現実的ではありません。

Interactions API は 「background=true」 を渡すとサーバー側で非同期実行を開始し、即座に部分的な Interaction オブジェクトを返す設計を採用しています。

呼び出し側は返された 「id」 を使って 「GET /v1beta/interactions/{id}」 をポーリングし、「status」 が 「completed」・「failed」・「cancelled」 のいずれかになったら結果を取り出します。

# Deep Research タスクを非同期で起動
interaction = client.interactions.create(
    agent="deep-research-preview-04-2026",
    input="医療分野におけるAIエージェントの影響を詳しく分析してください",
    background=True,
)

# 完了までポーリング
while True:
    result = client.interactions.get(interaction.id)
    if result.status == "completed":
        print(result.output_text)
        break
    time.sleep(5)

「background=True」 が必須なのは Deep Research です（同期呼び出しはエラーになる）。

一方、Antigravity は現時点で 「background=True」 をサポートしていません。Antigravity を呼ぶ場合は同期呼び出しを前提に、SDK のタイムアウトを十分長く設定し、ストリーミングイベント（SSE）で進行状況を監視する構成で扱うのが基本です。途中でキャンセルしたい場合は 「POST /v1beta/interactions/{id}/cancel」 でジョブを止められます。

Google Search・Maps とカスタム関数を1リクエストで併用

「generateContent」 の Function Calling では、サーバー側組み込みツール（Google Search 等）と自作の関数を同一リクエスト内で混在させることに制約がありました。

Interactions API ではこの制約が取り払われ、「tools」 配列に「Googleの組み込みツール（「{"type": "google_search"}」 等）」と「自作関数定義」を並べるだけで、モデルが必要に応じて呼び分けます。

interaction = client.interactions.create(
    model="gemini-3.5-flash",
    input="ボストンの天気を調べて、現地の最新ニュースとあわせて要約して",
    tools=[
        {"type": "google_search"},                # Google公式ツール
        {"type": "function", "name": "get_weather", "parameters": {...}},  # 自作関数
    ],
)

もう1つの変化として、ツールの戻り値に画像とテキストを併用できるようになりました。

生成AIに画像チャートを返すような自作ツールを書く場合、戻り値の構造がそのまま画像を扱えるため、エージェントが視覚情報を含んだ参照を保持しやすくなります。

画像・音声・音楽の生成も同じAPIから

これまで Imagen（画像）・Lyria（音楽）・TTS（音声）はそれぞれ別エンドポイントで提供されてきましたが、Interactions API は1本のエンドポイントから呼び分けられる構造になっています。

「response_format」 に出力モダリティを指定すれば、テキスト生成と同じ書き味でメディア生成を起動できます。

• 画像生成
  Gemini 3 Pro Image・Gemini 3.1 Flash Image・Nano Banana 2 等を 「model」 で指定。「response_format={"type": "image", "aspect_ratio": "16:9"}」 で出力比率を制御
  
  

• 音楽生成
  Lyria 3 Clip Preview・Lyria 3 Pro Preview を 「model」 で指定
  
  

• 音声合成
  Gemini 3.1 Flash TTS Preview でマルチスピーカーTTSを生成

クライアントから見ると、APIキーやリクエスト構築のコードは1本に集約され、生成系の選択が「「model」 パラメータの差し替え」だけで済みます。

Managed Agents で何ができるか

Managed Agents は、Googleがホストする実行環境上でエージェントを動かし、1回のAPI呼び出しで複雑なタスクを完結させる仕組みです。

Antigravity はリモートLinuxサンドボックスを自動でプロビジョニングして任意のコマンド・ファイル操作を実行し、Deep Research は Google 検索・URL Context・Code Execution などの組み込みツールを使って調査を進める、というように、エージェントごとに動作環境のスタンスが異なります。

Managed Agents 発表ブログのヒーロー。サブエージェントを Cron で定期実行するオーケストレーション画面が映る（出典：Google Blog）

ヒーローの中身を読み解くと、Managed Agents が「単発のタスク実行」ではなく「複数サブエージェントを継続稼働させるオーケストレーション層」として設計されていることが分かります。

Cron での定期実行と 「@to mention」 でのコール、「/for actions」 でのアクション呼び出しが同じUI上に並んでおり、後述の Antigravity・Deep Research・カスタムエージェントを単一の入口で管理する構図が前提になっています。

本セクションでは、現時点で利用できる Antigravity・Deep Research と、独自エージェントの作り方を整理します。

Antigravity エージェント

Antigravity（アンチグラビティ）は、コード実行・ファイル操作・Web 検索ができる汎用 Managed Agent です。エージェントIDは 「antigravity-preview-05-2026」 で、ベースモデルは Gemini 3.5 Flash です。

公式ドキュメントによれば、できることは以下に集約されます。

• Bash・Python・Node.js コマンドの実行
• ファイルの読み書き・編集・検索・一覧
• Google 検索とURL取得
• 約135kトークンで自動コンテキスト圧縮

呼び出しは 「agent="antigravity-preview-05-2026"」 と 「environment="remote"」 を渡すだけで、サンドボックス環境はGoogleが自動でプロビジョニングします。

Antigravity の新規プロジェクト作成画面。「Ask anything, @ to mention, / for actions」 の入力欄の下に、モデル選択（Gemini 3.5 Flash）と Worktree 指定（Local / New Worktree）の切り替えが並ぶ（出典：Antigravity）

new-project 入力UIで注目したいのは、Worktreeの選択肢に「Local」と「New Worktree」が並んでいる点です。

既存のローカル環境と新規 git worktree を切り替えながら作業できる前提で設計されており、Interactions API から 「environment="remote"」 で呼び出した場合は Antigravity IDE と同じハーネスがリモートの Linux sandbox を作成・再利用します。

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="フィボナッチ数列を生成して fib.py に保存してください",
    environment="remote",
)

このエージェントは「Antigravity IDE と同じハーネスで動作」と説明されており、IDE側の作業フローをAPI経由でそのまま再現できます。

料金は基盤モデルのトークン消費＋ツール使用量で、1インタラクションあたり概ね$0.25〜$5の幅。プレビュー期間中はサンドボックスのコンピュート費用が無料です。

Antigravity CLI の起動画面。左にカラースキーム選択、右に自然言語プロンプトへの差分提案が並ぶ（出典：Antigravity）

CLI を起動するとカラースキームの初期設定から入り、そのまま自然言語のプロンプトで関数追加・リファクタリングを指示できます。差分は「赤＝削除」「緑＝追加」の見慣れた形式で提示されるため、Antigravity IDE を立ち上げなくてもターミナル内だけで Managed Agent 相当の作業を回せます。

Interactions API 経由で同じハーネスが動くことを考えると、CI/CD やバッチ環境にエージェントを組み込む際の挙動イメージとしてもこの画面が参考になります。

温度・top_p・max_output_tokens といった生成パラメータや、structured outputs・computer_use・google_maps はプレビュー時点では未対応で、入力もテキスト・画像に限定される制約があります。

Deep Research の Speed版と Depth版

Deep Researchは、調査タスクを自律実行するためのエージェントです。1つのタスクが反復的な検索・読解と数分の処理時間を伴うため、「background=True」 の運用が前提になります。

Interactions API GA に合わせて、Deep Research には2つのバリアントが用意されました。

共通機能として、協調プランニング（Collaborative Planning）、ネイティブのチャート・インフォグラフィック生成、画像・PDF・音声を組み合わせたマルチモーダル・グラウンディングが追加されています。

社内ドキュメントを Files API 経由で渡して、外部のWeb情報と社内情報を統合してレポートにまとめる、というユースケースが代表例です。

AGENTS.md / SKILL.md でのカスタムエージェント定義

組み込みエージェント以外に、Managed Agents は**「AGENTS.md」 と 「SKILL.md」 というMarkdownファイルで独自エージェントを定義**できる仕組みを持っています。

Google は実例として 「google-gemini/gemini-skills」 リポジトリを公開しており、Gemini Interactions API 用のスキル（自動移行コマンド等）が同フォーマットで配布されています。

スキルファイルのメタデータは以下のような構造です。

• name：スキル識別子（例: 「gemini-interactions-api」）
• description：スキルの目的・トリガー条件
• Critical Rules：訓練データを上書きする重要ルール
• Quick Start：言語別の最小実装例
• Documentation Pages：詳細ドキュメントへのリンク一覧

この 「SKILL.md」 形式は Anthropic が先行して提唱した Agent Skills の規格と互換があり、Google・Anthropic 双方のエージェント間でスキル定義の流用が可能になりつつあります。

組織で独自のセキュリティポリシーや業務手順をエージェントに反映させたい場合、スキルファイルを Git で管理し、「AGENTS.md」 経由で複数エージェントに継承する設計が現実的な選択肢になります。

Interactions API の対応モデルと料金体系

Interactions API は2026年6月時点で複数のGeminiモデルと3つのエージェント（Antigravity・Deep Research 2版）に対応しており、料金は Standard・Flex・Priority の実行モード単位で設定されています（対応モードはモデルごとに異なるため、最終単価は公式Pricingで確認）。

本セクションでは、対応モデル・料金モードの違い・実コストの試算を整理します。

対応モデル一覧

公式Overviewに掲載されている対応モデルから、用途別の主要モデルを抜粋して整理しました（最新の全リストは公式ドキュメントを参照）。

新規開発では、推論性能とコストのバランスで gemini-3.5-flash を起点に、より高度な推論が必要なら gemini-3.1-pro-preview に切り替える運用が標準的です。

旧世代の 「gemini-2.0-」 および 「gemini-1.5-」 は既に廃止済みで、Interactions API からは呼び出せません。レガシーコードを移行する際は、「gemini-3.5-flash」 への置き換えが推奨ルートです。

Standard・Flex・Priority の3実行モード

Interactions API では Standard・Flex・Priority の3つの実行モードが用意されており、用途に応じて選択します。

どのモデルでどのモードが使えるかはモデルごとに異なるため、最終的な対応モードと単価は 公式Pricing を直接確認するのが確実です。

• Standard
  通常のリアルタイム実行。デフォルト動作で、レイテンシと料金のバランス型
  
  

• Flex
  柔軟な推論モード。低レイテンシ要件を緩める代わりにコストを下げる選択肢
  
  

• Priority
  高速・優先処理モード。Standard より追加料金がかかる代わりにレイテンシを優先

なお、Gemini API 全体には「Batch API」と呼ばれる一括処理向けの別最適化があり、入出力ともに50%割引で実行できますが、Batch API は2026年6月時点で Interactions API では未対応です。一括処理ジョブをBatch APIで安く回したい場合は、当面 「generateContent」 系のBatch APIを使う構成になります。

「日中の対話処理だけ Priority で高速化する」のように、同じモデルでも実行モードを使い分けることで、月間コストを変動させられます。

主要モデルの料金例

Gemini API pricing に掲載されている Standard単価を、代表的なモデルでまとめました。

リージョン概念のないSaaS型のため、価格表示は2026年6月時点のものです。

Interactions API では Flex を選ぶことでStandardより安く実行できますが、具体的な割引率は公式pricingページに記載のモデル別単価を直接確認するのが確実です。Batch API（一律50%割引）は前述のとおりInteractions API側では未対応のため、本表のStandard単価を起点に試算します。

Managed Agents の料金は「基盤モデル推論は標準Gemini料金、ツール使用は既存ツール価格」が原則で、サンドボックス環境のコンピュート費用はプレビュー期間中は無料です。

本番想定で見積もる場合、プレビュー終了後のコンピュート課金は別途見込んでおく必要があります。

マルチターン会話で効くコスト構造

サーバー側状態管理の恩恵が最も大きいのが、マルチターン会話で発生する入力トークンの削減です。

例えば、ユーザーとモデルで合計10ターンの会話を回す場合、「generateContent」 ではターンごとに「これまでの全履歴＋新規メッセージ」を再送するため、10ターン目には1ターン目の入力が10回送信されています。Interactions API では 「previous_interaction_id」 を渡すだけで履歴がサーバー側に保持され、クライアント側で再送する負荷がなくなります。

加えて、同じ履歴を起点に何度も呼び出すケースでは implicit caching が効きやすくなり、レイテンシ・実効コストの両面で改善が期待できると公式は説明しています。具体的な削減率はモデル・履歴の構造・キャッシュヒット率で変動するため、自社の代表的なフロー1本で実測したうえで運用設計に反映するのが現実的です。

エージェント前提の用途では、Standard 単価そのものよりも「マルチターンの履歴扱いをサーバー側に寄せられるか」がコストインパクトを左右します。

generateContent からの移行手順

Interactions API GA に伴い、「generateContent」 ベースのコードからの移行ルートが 公式の移行ガイド として整備されました。

本セクションでは、メソッドとレスポンスの変換マップ、Breaking changes のスケジュール、自動移行スキルを順に整理します。

主要メソッド・レスポンス構造の変換マップ

実装レベルで最初に書き換える対象は以下の対応関係です。

レスポンス側の最大の違いは、結果が 「candidates[0].content.parts[]」 から 「steps[].content[]」 に置き換わる点です。最終出力だけ欲しい場合は 「interaction.output_text」 を使えば1行で取り出せますが、Streaming イベントの取り扱いと Function Calling の戻り提出は仕組みごと変わるため、各実装の動作確認は必須です。

ストリーミングは旧 「content.delta」 から新 「step.delta」 へ、Function Calling の結果提出は旧 「contents」 配列追加から新 「input=[{"type": "function_result", ...}]」 形式へと変わります。

Breaking changes スケジュール（2026年5月〜6月）

2026年5月のBreaking changesガイドによれば、Interactions API のスキーマは段階的に切り替えられ、2026年6月8日にレガシースキーマが完全削除されました。

本記事執筆時点（2026年6月24日）では、すでにレガシースキーマは利用できません。旧スキーマからの移行には Python・JavaScript SDK の 1.x.x から 2.0.0 以上へのアップグレードが必要で、「outputs」 配列から 「steps」 配列への変更、「response_mime_type」 の 「response_format」 統合、ストリーミングイベント型の変更などが入っています。

現行 Interactions API を使う場合は最新SDK（Overview ページでは 2.3.0 以降が案内されています）を入れておけば、新スキーマ＋将来の差分追加にそのまま追従できます。

特に注意すべきは、「image_config」 が 「generation_config」 から 「response_format」 へ移動した点と、「response_modalities」 が 「response_format」 の指定で代替される点です。画像生成系のコードは確実に書き換えが必要になります。

gemini-skills スキルで自動移行を走らせる

実装移行のコストを抑えるため、Google は「google-gemini/gemini-skills」 リポジトリで自動移行用のスキルを公開しています。

Gemini CLI または Jules（コーディングエージェント）に Gemini Interactions API スキルをインストールし、以下のようなコマンドを実行すれば、リポジトリ全体を一括で書き換えられます。

/gemini-interactions-api migrate my app to the interactions api

スキル内部では 「migration.md」 を参照してチェックリスト形式で変換ルールを適用するため、レビュー時にも変更点が追いやすい設計です。

自動移行が刺さるのは「単純な生成呼び出しとマルチターンチャット」までで、Function Calling の戻り提出やストリーミング処理は手動レビューが必要です。コーディングエージェントに移行を任せた後、tools・stream まわりは必ずテストを通すフローを組んでおくと安全です。

OpenAI Responses API・Anthropic Managed Agents との違い

「ステートフル＋エージェント前提のAPI」という方向性は、Google だけでなくOpenAI・Anthropic も同じ方向に動いています。

本セクションでは、3社が同時期に出した類似APIの設計思想・機能・料金を横並びで整理します。

3社の設計思想の違い

各社のエージェント前提APIは、土台となる単位概念が少しずつ違います。

共通項は「サーバー側に履歴・状態を寄せ、エージェント実行を1APIで扱えるようにする」方向性で、3社とも MCP（Model Context Protocol）を採用してツール接続を標準化しています。

差分が出るのはエージェント実行の実装で、Google は Linuxサンドボックスに直接コードを実行させる Antigravity、OpenAI は Agents SDK で複数エージェントをオーケストレーションする設計、Anthropic は Skills・Cowork で人間と協働するワークフローを中心に据える、というスタンスの違いがあります。

機能対応マトリクス

主要機能を3社で並べると以下のとおりです。

Anthropic 主導で標準化が進んでいる Agent Skills 規格に Google が 「SKILL.md」 を採用したことで、3社のうち2社のスキル定義は同じフォーマットで書ける状況になっています。

料金水準の横並び

代表的なフラグシップ／ミドルレンジモデルの単価を整理しました（2026年6月時点・Standard 単価）。

公式Pricing上、Gemini 3.5 Flash の Standard 単価は入力$1.50・出力$9.00 で、GPT-5.5・Claude Opus 4.8（いずれも入力$5.00・出力$25〜$30）と比べるとフラグシップ帯のなかでは最安水準です。第三者比較記事 でも「Gemini wins on price-per-token at the low end」と整理されており、コスト最適化が効きやすい構造です。

逆に GPT-5.5-pro や Claude Opus 4.8 Fast mode は高価格帯で、用途（コーディング、長文推論、エージェント自動化）と単価の見合いで使い分ける流れが業界の通常運転になっています。

Interactions API の導入で押さえる3つの判断軸

Interactions API は GA とはいえ、すべての既存システムを今すぐ移行すべきかというと話は別です。

本セクションでは、AI総研が実際に支援している案件で論点になっている3つの判断軸を整理します。

既存 generateContent を維持するか・移行するかの分かれ目

新規プロジェクトは Google 自身が推奨するとおり Interactions API 一択で迷うところはありません。問題は既に 「generateContent」 で動いている本番システムをどう扱うかです。

判断軸として効くのは以下です。

• 新機能を取りに行く必要があるか
  Managed Agents・Background実行・新Tool統合などの長時間実行・エージェント系フロンティア機能は Interactions API に集まる方針。これらが必要なロードマップなら早期移行が合理的（「generateContent」 自体は引き続き完全サポート＋メインライン Gemini モデルの提供は継続）
  
  

• マルチターン会話のトークンコストが膨らんでいるか
  チャット履歴を毎回再送している実装で、入力トークン課金が月間予算の主要因になっているなら、「previous_interaction_id」 ベースに移すだけでコスト構造が変わる
  
  

• エージェント化の計画があるか
  近い将来 Antigravity や Deep Research を業務に組み込む計画があるなら、最初から Interactions API で書いておくほうが移行コストが分散される

逆に、単発のテキスト生成だけで完結する小規模ツール、コスト影響が軽微な検証スクリプトなどは、急いで移行する必要は薄く、次の機能改修タイミングに合わせて切り替える判断で十分です。

プレビュー機能を本番投入する際の注意

Interactions API 本体は GA ですが、周辺の Managed Agents や一部モデルは依然として Preview ステータスです。Preview と GA がモデル単位で混在している点を見落とすと、本番投入後にスキーマ変更で動かなくなるリスクがあります。

具体的には、Antigravity は 「antigravity-preview-05-2026」、Deep Research は 「deep-research-preview-04-2026」、TTS は 「gemini-3.1-flash-tts-preview」、Gemini 3.1 Pro Preview など、ID自体に 「preview」 を含むものは Preview ステータスです。一方で、画像系の 「gemini-3-pro-image」・「gemini-3.1-flash-image」 などはID上もPricing上も Preview 表記ではなく、安定運用扱いになっています。

プレビュー機能の典型的なリスクは以下です。

• スキーマ・引数仕様が予告なく変わる可能性がある
• SLA 上の可用性保証がない
• プレビュー終了後にサンドボックスのコンピュート料金が課金開始される

業務クリティカルな用途で投入する場合、SLA要件と料金変動を契約・予算計画に織り込んだうえで使うのが現実的です。AI総研の支援現場でも、Managed Agents は社内ナレッジ整備・調査自動化のような「結果が遅れても致命傷にならない」用途で先行採用するケースが目立っています。

Tool・Streaming 回りの実装で詰まりやすい論点

「generateContent」 から Interactions API へ書き換える際、最も詰まりやすいのは Tool 戻り提出と Streaming 周りです。

公式の移行ガイドにも明記されていますが、以下は手動レビュー必須です。

• Function Calling の戻り値提出
  旧来の 「contents」 配列に 「functionResponse」 を足す形から、「input=[{"type": "function_result", "call_id": ..., ...}]」 を渡す形に変わる。「call_id」 を取り違えると次の 「interactions.create()」 が失敗する
  
  

• Streaming 中のツール呼び出し
  旧来は完全なFunction Callオブジェクトが返ってきたが、Interactions API では 「step.delta」 で引数が文字単位でストリームされる。「interaction.requires_action」 で一時停止して、「call_id」 単位でツールを実行・結果を提出する設計が必要
  
  

• 「output_text」 が空になるケース
  複雑なマルチモーダル応答や Tool 呼び出しが挟まる場合、「output_text」 に意図したテキストが入らないことがある。確実に取り出したいなら 「interaction.steps」 を手動イテレートして 「step.content[].text」 を結合する

これらは 「gemini-skills」 の自動移行スキルでもカバーしきれない領域です。本番投入前に Tool 連携の動作テスト・Streaming のフェイルセーフを必ず回す必要があります。

Managed Agentsを自社テナント内で運用する設計を整える

Interactions API のような「ベンダー側クラウドでエージェントを動かす」マネージドサービスは、検証フェーズの速度を劇的に上げてくれる一方、機密データを扱う本番業務では「自社のセキュリティ・ガバナンス要件に収まる場所でエージェントを動かしたい」という要件と衝突しがちです。

ここで効いてくるのが、ベンダー側で素早く試作したエージェント設計を、自社のAzureテナント内へそのまま持ち込んで本番運用するハイブリッド進め方です。AI総合研究所の AI Agent Hub は、Azure Managed Applications として顧客テナント内に構築し、Teams から呼び出せる AI エージェント基盤として、業務システム接続・実行ログ・権限管理を一元で担います。

AI総合研究所の専任チームが、Managed Agents での検証から自社テナント内での本番運用設計まで、進め方の全体像を AI Agent Hub の LP で具体例とあわせてご確認ください。

Managed Agentsを自社テナント運用へ

検証はベンダー側、本番は自社環境

Interactions APIのManaged Agentsで業務エージェントを試作した後、機密データを扱う本番運用は自社のAzureテナント内に持ち込む——このハイブリッド設計を AI Agent Hub が支援します。LPで業務システム接続・実行ログ・権限管理の全体像をご確認ください。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、2026年6月にGAした Gemini Interactions API について、設計刷新（Stepsレスポンス・サーバー側状態管理）、主要機能、Managed Agents、対応モデルと料金、generateContent からの移行、OpenAI・Anthropic との違い、移行判断の3つの軸まで、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• Interactions API は generateContent の後継として GA した統一APIで、ステートフル＋エージェント前提の設計刷新が中核。長時間実行モデル・エージェント系のフロンティア機能は今後 Interactions API 側に集まる方針（generateContent はメインライン Gemini モデルのサポートを継続）
  
  

• Stepsレスポンスとサーバー側状態管理が2つの中核設計で、特にマルチターン会話では履歴再送の実装負担が消え、implicit caching でレイテンシ・コスト改善が期待できる構造に変わる
  
  

• Managed Agents は1回のAPI呼び出しでGoogleホストの実行環境を立ち上げる仕組みで、AntigravityはリモートLinuxサンドボックス、Deep Researchは検索＋URL Context＋Code Executionで動作する別タイプ。AGENTS.md / SKILL.md による独自エージェント定義も可能
  
  

• 料金は Standard・Flex・Priority の3実行モード構成（Batch APIは現時点 Interactions API 未対応・generateContent 側で別最適化）。Gemini 3.5 Flash の Standard 単価は入力$1.50・出力$9.00 で、GPT-5.5・Claude Opus 4.8 など競合フラグシップ帯のなかでは最安水準
  
  

• 既存 generateContent 利用者は、新機能取得・マルチターンコスト・エージェント化計画の3軸で移行タイミングを判断するのが現実的。旧 outputs スキーマからの移行には SDK 2.0.0 以上が必須（2026年6月8日に旧スキーマ完全削除済み）、現行 Interactions API 利用は最新SDK（Overview 上は 2.3.0 以降）を入れておけば追従できる

Interactions API はGAしたばかりですが、Google が「すべての新規開発で推奨」と明示し、エージェント系フロンティア機能を Interactions API に集約する方針を打ち出した時点で、Gemini を本格利用する開発者にとっては事実上の標準になっています。新規プロジェクトでは迷わず採用し、既存システムについては「マルチターンコストの大きさ」と「エージェント化の計画」を起点に移行ロードマップを描くのが、当面の現実的な進め方になります。