GoogleはGemini APIのInteractions API呼び出しをDeveloper logsで確認できるようにした。AI Studioではプロンプト、応答、前のターンの文脈、previous_interaction_idへのリンクを閲覧できる。
重要なのはAPIごとに既定の保存動作が違う点である。Interactions APIはサーバー側状態管理を簡単にするため既定でstore=true、GenerateContent APIは既定でstore=falseである。ログ機能の有効化は単なる観測設定ではなく、会話継続とデータ保持へ影響する。
何が変わったか
Interactions APIの対応リクエストがAI Studioのログ画面で閲覧可能になった。ログからdatasetを作成し、CSV、JSONL、Google Sheetsへ出力して評価へ使える。
変更前後の差
| 項目 | GenerateContent | Interactions API |
|---|---|---|
| 既定のstore | false | true |
| 会話状態 | クライアント管理中心 | サーバー側状態を利用可能 |
| ログ表示 | 有効化が必要 | 対応呼び出しを表示 |
| 保持 | 設定に従う | 設定に従う |
| logging無効化 | 保存しない | 自動履歴取得へ影響 |
| dataset化 | 可能 | 可能 |
誰に影響するか
顧客問い合わせ、社内アシスタント、医療・人事・法務など個人情報を扱うシステム、ログから評価セットを作る開発チーム、OpenAI互換エンドポイントを使う組織に影響する。無料利用ではなく、ログ保存は有料tierプロジェクトが対象である。
期限
強制期限はない。ただし、Interactions APIを導入済みの組織は、既定で保存されることを前提に即時棚卸しすべきである。
必要な対応
API別にstoreの既定値を文書化し、リクエスト単位で明示する。ログは既定55日で削除対象となり、7、14、28、55日に設定できる。一方、datasetへ保存したデータは期限切れしないため、評価目的のコピーを通常ログと同じ保持と誤認しない。
実装・移行手順
- 利用APIと
store指定の有無をコード検索する。 - 機密用途では
store=falseを明示し、会話状態を別管理する。 - 会話継続が必要な経路だけ
store=trueを承認する。 - プロジェクトの保持期間をデータ分類に合わせて設定する。
- AI Studioログへのアクセス権を最小化する。
- dataset作成時に所有者、目的、削除日を記録する。
- ログ非対応の動画、GIF、PDF、公開プレビューAgent等を監視対象外として補完する。
失敗しやすい点
GenerateContentとInteractionsの既定値を同じと考える、AI Studioでloggingを切れば会話履歴がそのまま動くと仮定する、datasetにも55日上限があると誤認する、評価データを個人情報除去せず共有することが問題になる。
リスク
個人情報や秘密情報の長期保存、datasetへの無期限コピー、ログ閲覧権限の過剰付与、logging無効化による会話継続障害がある。また一部モデル・入力はログ対象外で、監視が完全だと誤認するリスクもある。
評価方法
- store明示率
- API別の保存リクエスト件数
- 保持期間を超えたログ件数
- 所有者・削除日がないdataset数
- ログ閲覧権限者数
- 削除要求の完了時間
- logging変更後の会話再開成功率
- 対応外リクエストを別監視できた率
ロールバック
ログ設定変更で会話履歴が壊れた場合、対象プロジェクトまたはリクエストだけstore=trueへ戻し、履歴取得を復旧する。プライバシー上の問題がある場合は新規保存を停止し、既存ログとdatasetを別々に棚卸し・削除する。
編集部分析
ログ機能は観測性を高めるが、Interactions APIでは状態管理機能と結び付いている。運用担当者が「ログを切る」、開発者が「会話を保持する」を別々に決めると障害になる。保持、履歴、評価、共有を一つのデータライフサイクルとして設計すべきである。
実務チェックリスト
- [ ] APIごとのstore既定値を確認した
- [ ] 機密経路でstoreを明示した
- [ ] 7・14・28・55日の保持方針を決めた
- [ ] datasetが期限切れしないことを認識した
- [ ] AI Studioの閲覧権限を限定した
- [ ] 削除要求の手順を試験した
- [ ] ログ非対応入力の代替監視がある