重要なポイント
Gemini Interactions API の本質は、新しい endpoint が増えたことではありません。Google が Gemini を、単なるモデル呼び出し API から agent runtime へ寄せていることが重要です。
従来の API パターンは、アプリが prompt を送り、応答を受け取り、会話履歴を自分で保存するものでした。これは要約、分類、短いチャットには十分です。しかし、長時間の調査、ツール呼び出し、ファイル操作、コード実行、リトライ、バックグラウンド処理を含む agent には不向きです。
Interactions API では Interaction が中心になります。1 つの interaction は、モデル出力、tool call、tool result、function call、function result、最終出力を含む実行記録として扱えます。さらに previous_interaction_id を渡すことで、前回の interaction から状態を引き継げます。
これにより、アプリ側で毎回すべての履歴を再構成する負担を減らせます。もちろん、ユーザー権限、監査ログ、業務データ、承認フローはアプリ側で管理する必要があります。
Managed Agents はさらに一段進んだ仕組みです。Google が管理する隔離 Linux sandbox の中で Antigravity agent を動かし、ツール、コード実行、ファイル読み書きを行えます。AGENTS.md や SKILL.md を使って、agent の振る舞いをバージョン管理された形で定義できます。
移行すべきケース
単発のテキスト生成、分類、短い抽出だけなら generateContent で十分です。既存システムが安定しているなら、急いで移行する必要はありません。
一方、複数ターンの作業、バックグラウンド job、ドキュメント処理、コード生成、ツール orchestration、継続的なユーザー支援が必要なら Interactions API が合います。状態を API レベルで扱えるため、agent の実行モデルをより自然に表現できます。
Managed Agents は、実際の作業環境が必要な場合に使います。リポジトリを調べて patch を作る、テストを実行する、複数ファイルを読み書きする、長い調査を行う、といったケースです。
運用前の注意点
agent に何を読ませ、何を変更させるかを先に決めるべきです。外部メール送信、コードの merge、データ削除、請求変更、インフラ更新などは、人間の承認を必須にするのが現実的です。
各 tool には schema、timeout、retry、最小権限、監査ログを用意します。外部 web page、issue、PDF、ユーザーアップロードは信頼できない入力として扱い、prompt injection が tool 権限に広がらないようにします。
結論
Gemini Interactions API と Managed Agents は、AI 開発がモデル品質だけでなく実行基盤の競争になっていることを示しています。開発者にとって重要なのは、agent に何でも任せることではなく、状態、tool、sandbox、承認、ログを設計したうえで限定された仕事を任せることです。
参考リンク：
- https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/
- https://ai.google.dev/gemini-api/docs/interactions/interactions-overview
- https://ai.google.dev/gemini-api/docs/custom-agents
- https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/
- https://io.google/2026/explore/technical-session-40
