AI Studio のログのページを開いて、表が空のままだったことがあります。
呼び出しは通っていました。応答も返っていました。それなのに、一件も並びません。キーの権限を疑い、プロジェクトの選択を疑い、しばらく遠回りをしてから、ようやく原因にたどり着きました。ログの設定を触っていなかったのではなく、そもそも記録される既定値が API ごとに逆だったのです。
同じ場所に並ぶログでも、generateContent と Interactions API では、保存されるかどうかの出発点が違います。そしてこの設定は、単なる観測のスイッチではありません。切り方を間違えると、会話の続きが返らなくなります。
ログが空なら、API ごとの既定値を先に疑います
公式ドキュメントに書かれている既定値は、次のとおりです。
| API | store の既定 | 意味 |
|---|---|---|
| Interactions API | store=true | 既定で保存される。サーバー側の会話状態を扱いやすくするため |
Generate Content API(generateContent) | store=false | 既定では保存されない。リクエスト単位かプロジェクト単位で有効化が要る |
私が踏んだのは下の行でした。generateContent で組んだ機能をいくら回しても、既定のままではログに残りません。「ログ機能が使えない」のではなく「まだ有効にしていない」状態です。
もうひとつ、見落としやすい前提があります。Gemini API のログの保存は、有料ティアのプロジェクトでのみ利用できます。無料枠で試している段階では、設定を正しく入れても表は埋まりません。ここを確かめずにキーやスコープを疑い始めると、時間だけが溶けます。
有効化はリクエスト単位でも、AI Studio の設定パネルからプロジェクト単位でも行えます。generateContent と Interactions API で個別に切り替えられる構造になっています。
設定トグルは、観測だけのスイッチではありません
ここが、この記事でいちばんお伝えしたい点です。
AI Studio の設定パネルで Interactions API のログを off にすると、会話履歴の自動的な保存と取り出しまで止まります。リクエストごとに明示的に上書きしない限り、サーバー側で前のターンを保持してくれなくなるということです。
Interactions API は、previous_interaction_id を渡して会話を継ぐ設計になっています。その「前のターンが残っている」という前提を支えているのが、まさに store=true です。つまりログの保存と会話状態の保持が、同じスイッチにぶら下がっています。
観測のつもりで off にして、しばらくしてから「文脈が続かない」という報告が届きます。原因と症状が時間的に離れているぶん、あとから結びつけるのがむずかしい種類の事故です。私はこの手の設定を、あとで理由を思い出せる形にしておきたいと考えるようになりました。個人開発だと設定を触った記録が自分の頭の中にしか残らないので、なおさら厄介でした。
プライバシーやコストの都合でログを絞りたい場面はあります。その場合も、プロジェクト全体のトグルを落とすのではなく、次の節のように呼び出し側で決めるほうが安全だと私は考えています。
呼び出しごとに store を明示して、プロジェクト設定から切り離す
既定値に頼らず、コード側で毎回はっきり指定してしまうのが確実です。プロジェクトの設定を誰かが(あるいは数ヶ月後の自分が)変えても、挙動が動かなくなります。
from google import genai
client = genai.Client()
# generateContent は既定で store=False。
# ログを残したい呼び出しでは明示的に True にします。
response = client.models.generate_content(
model="gemini-3.7-flash",
contents="Explain quantum entanglement in simple terms.",
config={"store": True},
)
print(response.text)Interactions API 側は逆向きです。既定が store=True なので、残したくない呼び出しだけ False にします。ただし前述のとおり、False にした呼び出しは会話状態も保持されません。単発の問い合わせにだけ使う指定だと考えるのが安全です。
from google import genai
client = genai.Client()
# 会話を継がない単発の呼び出し。
# store=False にすると履歴も残らないため、previous_interaction_id では継げません。
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="Explain quantum entanglement in simple terms.",
store=False,
)
print(interaction.outputs[-1].text)JavaScript でも同じ考え方です。
import { GoogleGenAI } from '@google/genai';
const client = new GoogleGenAI({});
// 会話を継ぐ呼び出しでは store を落とさない。
const interaction = await client.interactions.create({
model: 'gemini-3.7-flash',
input: 'Explain quantum entanglement in simple terms.',
store: true,
});
console.log(interaction.outputs[interaction.outputs.length - 1].text);私自身は、store を「機能ごとに1回だけ決める値」として扱うようにしました。会話を継ぐ機能では固定で true、使い捨ての分類や要約では固定で false。呼び出し口を一箇所にまとめておくと、この判断がコードの一行として残ります。呼び出し口の集約そのものについては、散らばった呼び出し口を一つに畳む — Interactions API を自動運用の正面玄関にする移行設計で扱っています。
鍵を1本も残さないプロジェクトは、ログが見えなくなります
もうひとつ、事故の起きやすい仕様があります。
ログを表示するには、そのプロジェクトに有効な API キーが少なくとも1本必要です。 プロジェクト内のキーをすべて削除すると、ログの可視性を失います。
これが効いてくるのは、漏洩したキーを消すときです。うっかり公開してしまったキーを急いで無効化します。それがそのプロジェクトに残っていた最後の1本だったとしますと、まさに「そのキーで何が呼ばれたか」を確かめたい瞬間に、履歴が見えなくなります。
対処自体は単純で、削除する前に新しいキーを作っておくだけです。順番を逆にしないこと。慌てている場面ほど順番が入れ替わります。個人開発では鍵の管理も自分ひとりで抱えることになりますから、手順書に一行入れておく価値があります。
残らない入力と、55日で消える前提
ログに載らないものも先に把握しておくと、切り分けが速くなります。公式に挙げられている対象外は次のとおりです。
| 対象外 | 補足 |
|---|---|
| Imagen・Veo | 画像生成・動画生成の各モデル |
| Gemini の埋め込みモデル | embedding 系の呼び出し |
| Gemini Robotics モデル | ロボティクス向けモデル |
| 動画・GIF・PDF を含む入力 | 入力にこれらを含む呼び出し全体が対象外 |
| Gemini API の Public Preview Agents | Managed Agents の呼び出しもログ対象外 |
PDF を投げる処理を組んでいると、この行が効きます。テキストの呼び出しは並ぶのに、PDF を含む呼び出しだけ並ばない。設定の問題に見えて、仕様どおりの挙動です。
保持期間も先に決めておきたい値です。既定は55日で、その後は削除の対象になります。プロジェクト単位で7日・14日・28日・55日から選べます。データセットとして保存したログは期限で消えません。フィルタで絞り込んで選択し、データセットを作れば、CSV・JSONL・Google スプレッドシートへ書き出せます。
つまり AI Studio のログは、恒久的な保管場所ではありません。3週間前の1件を追う運用を考えているなら、ダッシュボードとは別に自前の記録を持つ設計が要ります。その分け方はAI Studio の開発者ログを本番の正本にしない — Interactions API を二層で観測する設計で詳しく書きました。
まとめ
まず、いま動かしている機能の store がコード上で明示されているかを確認してみてください。既定値に任せている箇所があれば、そこが将来いちばん説明のつかない挙動になります。
応答が空で返る側の切り分けは、Gemini API の空応答を finish_reason から逆引きするが入口になります。ログが出ない問題と空応答の問題は、原因の層が違うので、分けて追うほうが早く終わります。
設定ひとつで会話の前提が変わる箇所は、まだ他にもありそうだと感じています。気づいたものから書き足していきます。お読みいただきありがとうございました。