一言で言うと
今回の変更は、単なる開発者向けの窓口変更ではありません。
これまでのGemini APIは、ざっくり言えば「AIに依頼文を送り、返事を受け取る」作りでした。文章を書かせる、要約させる、チャットするにはこれで足ります。
しかしAIエージェントは違います。調べる、道具を呼び出す、途中結果を覚える、長い処理を裏で続ける、失敗したらやり直す。こうした一連の動きを扱うには、従来の窓口だけでは開発者側の管理が重くなります。
そこでGoogleは、Geminiの使い方を「古い窓口」と「新しい窓口」に分けました。古い窓口がgenerateContentです。これは、依頼を送って返事を受け取る基本的な仕組みです。新しい窓口がInteractions APIです。こちらには、AIエージェントが手順を踏んで動くための機能が集められています。古い窓口をすぐ閉じるのではなく、便利な機能を新しい窓口に置いた。そこが今回のポイントです。
何が起きているのか
GoogleはGemini向けInteractions APIを2025年12月にベータ版として公開し、2026年6月22日に一般提供へ移行しました。
APIとはアプリケーション・プログラミング・インターフェイス（API: Application Programming Interface）のことで、ソフトウェア同士をつなぐ窓口にあたります。たとえばアプリがGeminiに文章生成を依頼するとき、その依頼と返事の通り道になります。
従来のgenerateContent APIは、この窓口の中でも分かりやすい形でした。依頼を送る。AIが返す。基本はこの往復です。普通のチャットや要約なら、この作りで大きな問題はありません。
ただし、AIエージェントを作ると話が変わります。エージェントは一度返事をして終わりではありません。検索する、関数を呼び出す、地図や外部サービスを使う、コードを安全な場所で実行する、時間のかかる作業を裏で続ける。こうした動きをまとめて扱う必要があります。
Interactions APIでは、ユーザーの入力、AIの返答、関数の呼び出しなどが、すべて「ステップ」として管理されます。何をしたのか、次に何をするのかが、構造として残りやすくなります。
新しい機能もInteractions API側に集まっています。Googleが管理する実行環境でエージェントを動かすManaged Agents、長時間のバックグラウンド実行、Google SearchやMapsとの連携、画像・音楽・音声の生成機能などです。
料金や速度の選び方も加わりました。Flexモードはコストを50%下げる設計で、Priorityモードは速度を優先します。これらの新機能は、Interactions APIを通じて使う形になります。
一方、従来のgenerateContent APIは廃止されません。Googleは移行ガイドを公開しており、既存の実装はそのまま動き続けます。
AI業界の文脈では
このニュースは、エンジニアでなければ「APIが変わったらしい」で終わりがちです。
でも本質は、名前の変更ではありません。AIの使われ方が変わってきたことに、Google側の窓口が追いつこうとしているという話です。
以前の中心は「AIに一回聞いて、一回返してもらう」でした。これは、人間がチャット欄に質問する使い方に近いものです。
これから増えるのは「AIに仕事の一部を任せる」使い方です。たとえば、調査して、必要な資料を取りに行き、途中で道具を使い、処理が終わったら結果をまとめる。こうなると、単なる一問一答の窓口では足りません。
開発者にとって不便だったのは、こうした途中経過の管理を自分たちでかなり抱えなければならなかった点です。どの手順まで進んだか。どの道具を呼んだか。失敗したらどこから再開するか。長時間処理をどう待つか。これらをアプリ側で組み立てる必要がありました。
Interactions APIは、この不便さをGoogle側の標準構造に寄せるものです。言い換えると、Geminiを「返事をするAI」から「手順を踏んで仕事をするAI」として扱いやすくする変更です。
もうひとつ重要なのは、Googleが古いAPIを壊していない点です。壊して移行させるのではなく、新しい便利機能をInteractions APIに集める。これは開発者の反発を抑えながら、自然に新しい標準へ移していくやり方です。
私の見立て
人間の行動から見ると、これはかなり現実的な移行設計です。動いているシステムをわざわざ作り直す人は多くありません。generateContentが残るなら、既存の利用者はしばらくそのまま使うでしょう。
一方で、新しくGeminiを使い始める人は、Google AI Studioやドキュメントが示す標準に従います。そこがInteractions APIに切り替われば、新しい開発者は最初からその書き方で覚えます。
経済面では、Flexモードが効きます。エージェントは一回の返答で終わらないため、処理時間も呼び出し回数も増えがちです。コストを下げる選択肢があるなら、実験しやすくなります。
情報の流れという点では、Managed Agentsの実行環境も見逃せません。Googleの管理する環境でエージェントが動くなら、どの処理をどこまでGoogle側に任せるのかという判断が必要になります。社内データや機密情報を扱う場合は、便利さだけで選ぶわけにはいきません。
→ 何が変わるか: Geminiを使う開発者の標準的な作り方が、少しずつInteractions APIへ移っていきます。すぐに古いAPIが使えなくなるわけではありません。ただ、エージェント開発をするなら、新機能がある場所へ自然に寄っていく流れになります。
→ 何をすべきか: Gemini APIを使っている、または使う予定がある場合は、まず「自分たちの用途が一問一答なのか、エージェントなのか」を分けて考えるとよいです。単純な文章生成なら急ぐ必要はありません。検索、道具の呼び出し、長時間処理、社内データを使った自動作業を考えているなら、Interactions APIの移行ガイドとManaged Agentsの実行環境を早めに確認しておく価値があります。