Gemini のドキュメントからコードをコピーすると、これまでとは違うものが貼り付くようになった。リクエストの形が変わっただけではない。会話の状態を「誰が持つか」という前提そのものが入れ替わっている。
2026年6月22日、Google は Interactions API を一般提供(GA)にし、Gemini モデルとエージェントを扱うための既定インターフェースに格上げした。2025年12月のベータ公開から半年での昇格で、AI Studio も Gemini API も公式ドキュメントも、すべてこの新APIをデフォルト表示に切り替えた(スニペットを旧形式に戻すトグルは残っている)。これまで Gemini を叩く標準だった generateContent が「正」ではなくなった、と考えてよい。
サーバーが状態を持つ、という地味で大きな変更
何が変わったのかは、generateContent の使い勝手を思い出すと分かりやすい。あれは完全にステートレスだった。会話を続けたければ、毎ターン過去のやりとり全部をリクエストに詰めて送り直す。短いチャットなら問題ないが、ツールを何度も呼びながら数分から数時間動き続けるエージェントだと、この「全履歴を毎回再送する」モデルは破綻する。トークンは膨らみ、状態管理はアプリ側の責任になる。
Interactions API はここを反転させた。会話の状態をサーバー側に保存し、続きを送るときは直前のやりとりの ID を渡すだけでよい。鍵になるのが previous_interaction_id というパラメータだ。
from google import genai
client = genai.Client()
# 1ターン目。store はデフォルト true なので状態はサーバーに残る
first = client.interactions.create(
model="gemini-3.5-flash",
input="日本の祝日を3つ挙げて",
)
# 2ターン目。履歴を再送せず、前の interaction の ID を渡すだけ
second = client.interactions.create(
model="gemini-3.5-flash",
input="その中で一番新しいものは?",
previous_interaction_id=first.id,
)
REST で見るとエンドポイントもシンプルだ。
curl "https://generativelanguage.googleapis.com/v1beta/interactions" \
-H "x-goog-api-key: $GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gemini-3.5-flash",
"input": "日本の祝日を3つ挙げて"
}'
地味に効くのは、previous_interaction_id で繋ぐと会話履歴の暗黙キャッシュが効きやすくなり、レイテンシとコストが下がるという点だ。状態を渡し直さない設計が、そのまま課金面の最適化につながっている。
二つの API の性格の違いを並べるとこうなる。
| generateContent(旧) | Interactions API(新) | |
|---|---|---|
| 状態 | ステートレス(毎回全履歴を再送) | サーバー側に保存、previous_interaction_id で継続 |
| 応答の構造 | ロール(user / model)ベース | 型付きの「ステップ」列 |
| 長時間タスク | 同期リクエスト前提 |
background=true で非同期実行 |
| 保持期間 | なし(送った分だけ) | 有料55日 / 無料1日 |
| 位置づけ | 当面サポート継続 | 既定。新エージェント機能はこちらに集約 |
「ロール」から「ステップ」へ
スキーマ側でも面白い変更が入った。これまでの user / model というロールの並びが、Interaction の中の型付き ステップ の列に置き換わっている(Interactions API のドキュメント)。レスポンスの steps には、モデルの思考、function_call(ツール呼び出し)、function_result(ツールの結果)、model_output といった一つひとつの動作が、それぞれ独立したステップとして並ぶ。
これは UI 描画とデバッグにそのまま効く。エージェントが「いま何をしているか」をステップ単位で観測できるので、思考やツール呼び出しの途中経過を画面に出したり、どこで失敗したかを追ったりするのが楽になる。出力を一枚のテキストとして受け取り、構造を自前でパースしていた頃と比べると、実装の手触りがかなり変わる。
1回のAPI呼び出しで Linux サンドボックスが立ち上がる
GA で目を引いたのが Managed Agents だ。公式ブログの説明はこうだ。
A single API call provisions a remote Linux sandbox where an agent can reason, execute code, browse the web and manage files.
つまり、API を1回呼ぶだけでリモートの Linux サンドボックスが立ち上がり、その中でエージェントがコードを実行し、ウェブを見て、ファイルを操作する。既定では Antigravity エージェントが載り、カスタムエージェントも差せる。サンドボックスの調達や寿命管理を自前のインフラで抱えずに済むのは、実務では地味にありがたい。
長時間動くタスク向けには background=true がある。これを付けて投げるとサーバー側が非同期で処理を進め、こちらは interactions.get で後から取りに行く。
job = client.interactions.create(
model="gemini-3.5-flash",
input="リポジトリ全体を読んでテスト失敗の原因を調べて",
background=True,
)
# 後でポーリングして結果を取得する
result = client.interactions.get(job.id)
ただし store=false と background=true は併用できない。非同期実行は状態をサーバーに残すことが前提だからだ。コスト面では速度寄りの Priority と費用を約50%抑える Flex の二段が用意されている(API リファレンス)。
移行すべきか、何が引っかかるか
私の見立てでは、これは Google だけの話ではなく業界の収束点だ。ステートレスな単発呼び出しから、状態をサーバーが持ち、実行がステップとして観測でき、サンドボックスまで含めて面倒を見るエージェント向けインターフェースへ。同じ方向の変化を別のプラットフォームでも見てきたエンジニアは多いはずで、Gemini もそこに揃えにきた、と読むのが自然だろう。
実利は分かりやすい。会話履歴の再送が消え、background で長時間タスクが投げっぱなしにでき、ステップ単位で中身が見える。エージェント的なものを Gemini で組むなら、新規はもう Interactions API で始めるのが順当だ。
引っかかる点も正直に書いておく。状態をサーバーが持つということは、その状態がプラットフォームに紐づくということでもある。previous_interaction_id を前提に組むほど、可搬性は下がる。保持期間が有料でも55日である以上、長く参照したい文脈は結局アプリ側にも持つ必要がある。generateContent は当面サポートされるが、Google 自身が「フロンティアのエージェント機能は新APIに集約していく」と明言しているので、旧APIに留まる選択は機能面で徐々に不利になる。今すぐ全面移行を迫られるわけではないが、新しく書くコードの既定をどちらに置くかは、いま決めておく価値がある。