Gemini API を本番で回し始めると、最初に気になるのはトークン数とレイテンシです。けれど少し運用が続くと、もっと手前で知りたいことが出てきます。「この呼び出しの出力は、結局のところ最後まで使われたのか」という結果の行方です。
数値の平均はきれいに出ます。ただ、平均だけを眺めていても改善の手は動きません。私が Google AI Studio のログ＆データセット機能を実務で使ってよかったと感じたのは、派手な分析よりも、この「残ったか・捨てたか」を一覧で追えるようになった点でした。本稿は、その視点でログを読み直すための実運用メモです。
ログに最初から残すべきは「結果の列」
ログ設計で遠回りしやすいのは、記録する項目を機能の一覧から選んでしまうことです。トークン数もレイテンシもモデル名も、たしかに記録できます。ですが、それらは「いくらかかったか」「どれだけ待ったか」を答えてくれても、「良かったか」には答えてくれません。
私のおすすめは、最初の一列として「その出力がどうなったか」を表す独自フィールドを足すことです。公開まで残ったのか、品質チェックで弾いたのか、人手で書き直したのか。この一列があるだけで、後からログを開いたときに読める情報量がまるで変わります。標準で記録される項目は、その結果を裏づける材料として後ろに置く。私はこの順番に落ち着いてから、ログを開く回数が自然と増えました。
自動で記録される項目と、そこから何を読むか
リクエストとレスポンスは自動で記録されます。記録される主な項目と、私が実際にそこから何を読んでいるかを並べておきます。
| 記録項目 | そこから読むこと |
|---|---|
| 入力プロンプト（テキスト・画像・動画） | 弾かれた出力に共通する言い回しの癖 |
| 出力レスポンス | テンプレ化・逐語重複が起きやすいパターン |
| 使用トークン数 | コストの高い呼び出しの偏り |
| レイテンシ | 待たされる処理がユーザー体験を削っていないか |
| モデル名・バージョン | Pro と Flash の使い分けが妥当か |
| エラー情報 | 過負荷やレート超過の起きる時間帯 |
項目そのものより、「その項目から何を判断したいか」を決めてから記録範囲を絞るほうが、ログは軽く保てます。何でも残すと、後で読む気が失せるほど膨らみます。
ログからデータセットを作って評価に回す
蓄積したログは、そのまま評価やファインチューニングの材料になります。日付やモデルで絞り込んでデータセット化しておくと、後の比較が一気に楽になります。
import google.generativeai as genai
genai.configure(api_key="YOUR_API_KEY")
# ログからデータセットを作成
dataset = genai.datasets.create(
name="customer-support-logs",
description="カスタマーサポートのAPI呼び出しログ",
source="logs",
filter={
"date_range": {"start": "2026-03-01", "end": "2026-03-12"},
"model": "gemini-2.5-pro"
}
)同じプロンプトセットを複数モデルに通して、品質・レイテンシ・コストを横並びにできます。Pro を当たり前に使っていた処理が、実は Flash で十分だったと気づくのはたいていこの段階です。
# データセットを使ったモデル比較
evaluation = genai.evaluations.run(
dataset="customer-support-logs",
models=["gemini-2.5-pro", "gemini-2.5-flash"],
metrics=["quality", "latency", "cost"]
)
print(evaluation.summary())私がログ設計で遠回りした話
私は個人開発で、Gemini や Claude を使ったコンテンツ生成のパイプラインを複数のサイトで並行して回しています。私自身、当初のログにはトークン数とレイテンシしか残しておらず、「どんなプロンプトが弾かれやすいか」がまるで見えていませんでした。
私のパイプラインには、生成した文章を機械的に弾く品質ゲートが何段か入っています。テンプレ的な定型文や、他の記事と逐語的に重複する段落を検出すると、その出力は破棄して書き直す仕組みです。そこで各リクエストのメタデータに passed_gate（合格・不合格）という独自フィールドを足して記録したところ、傾向がはっきり出ました。
「網羅的に解説してください」「完全な形でまとめて」といった包括を求める指示を含むプロンプトほど、定型的で薄い出力になりやすく、ゲートで弾かれる割合が目に見えて高かったのです。逆に、具体的な場面や制約を一つ与えたプロンプトは、合格率が安定して高くなりました。evaluations.run は品質スコアを返してくれますが、私のように「自分の基準を通過したか」という二値を見たい場合は、filter でスコアの低い帯だけを抜き出し、そこに集まるプロンプトの言い回しを一つずつ読むのが一番の近道でした。
コストとキーの安全をログ起点で締める
ログを「結果の列」で読めるようになると、自然とコストとキーの管理にもつながります。2026年に入ってからの Gemini API 周りでは、プロジェクト単位で月間の支出上限を設ける Project Spend Caps が使えるようになりました。ログでコストの高い呼び出しの偏りを掴んだうえで上限を引いておくと、想定外の請求を構造的に止められます。
あわせて点検しておきたいのがAPIキーの素性です。2026年6月19日以降、利用制限のかかっていない（unrestricted な）キーからのリクエストは遮断される方針が示されました。ログにモデル名やエラー情報が残っていれば、どのキーが何を叩いているかを後から辿れます。放置されたキーや、どの環境から使われているか分からない呼び出しがあれば、この機会に用途ごとにキーを分け、許可するモデルやリファラを絞っておくのが安全です。ログ・コスト上限・キー制限は、別々の作業に見えて、実際には同じ「運用を放置しないための点検」の三辺です。
Google AI Studio での見方
- Google AI Studio にアクセスします
- 左メニューから「Logs & Datasets」を選びます
- ダッシュボードでログの概要を確認します
- 必要に応じてフィルタを適用し、詳細を追います
最初に開くべきは、レスポンス品質スコアが低い帯です。エラーの多い時間帯よりも、静かに品質を落としているプロンプトのほうが、見つけにくく、改善の余地も大きいからです。
保持期間とプライバシーで気をつけること
- ログデータはプロジェクトに紐づき、他のユーザーからはアクセスできません
- 機密データを含むログは暗号化されて保存されます
- 保持期間はデフォルトで30日で、必要に応じて調整できます
- ログ機能は提供形態が変わることがあるため、本番運用では保持期間とコストの設定を定期的に見直すのが無難です
大量のログが溜まればストレージコストが発生します。何でも残すのではなく、結果の判断に効く項目だけを選んで残す、という最初の方針がここでも効いてきます。
次の一歩
まずは本番で実際に投げている数十件分のログをダッシュボードで開き、レスポンス品質スコアが低い帯のプロンプトを5つだけ読んでみてください。共通する言い回しが見つかれば、それがあなたのプロンプトテンプレートで最初に直すべき箇所です。その勢いのまま、コストの高い呼び出しに上限を引き、用途の分からないキーを一つ整理できれば、運用はだいぶ静かになります。
お読みいただきありがとうございました。同じように API を本番運用されている方の、ログ設計の一助になれば幸いです。