Gemini API File Searchのマルチモーダル化はゲームNPCの記憶にも使えそう
目次
Googleが2026年5月5日に、Gemini APIの File Searchをマルチモーダル対応にした と発表した。
画像とテキストを同じ検索対象に入れられるようになり、custom metadataとページ単位のcitationも追加された。
普通に読むと、PDFや画像入り社内文書向けのRAG更新だ。
でもゲームエンジン側から見ると、NPCが「世界を覚えている」ための部品にも見える。
会話ログだけでなく、スクリーンショット、マップ、キャラ設定、イベント進行表を同じ検索棚に入れられるなら、ゲーム内AIの作り方が少し変わる。
File Search側で増えたもの
発表で挙がっている追加は、画像とテキストを一緒に処理するマルチモーダル検索、ファイルにkey-valueのmetadataを付けて検索時に絞り込む機能、回答が参照した元ページを示すcitationだ。
ドキュメント側を見ると、マルチモーダルFile Searchでは FileSearchStore 作成時に models/gemini-embedding-2 を指定する。
デフォルトのテキスト専用embeddingではなく、画像とテキストを処理できるモデルに差し替える必要がある。
File Searchの内部は、アップロードしたファイルをchunkへ分け、embeddingに変換し、File Search storeへ保存する流れになっている。
元のFile API上のファイルは48時間で消えるが、File Search storeへ取り込まれたデータは手動削除まで残る。
この差は運用で地味に効く。生ファイル置き場ではなく、検索用に加工された永続インデックスとして扱うほうが近い。
custom metadataは、たとえば author や year のような値をファイルへ付け、検索時に metadata_filter で絞る機能だ。
ゲーム用途なら、章、ステージ、キャラクターID、ワールド状態、公開ビルド番号あたりが候補になる。
NPCの記憶は長いプロンプトだけではきつい
以前、AI APIでキャラクター設定を入れる記事では、Gemini、Claude、OpenAIにsystem promptや構造化出力を入れて、ゲームNPCっぽい応答を作る方法を試した。
あれは「人格を固定する」話だった。
今回のFile Searchは、人格ではなく「何を覚えているか」を外部に持たせる話になる。
ゲームNPCに必要な記憶は、単なる会話履歴だけではない。
プレイヤーが前に渡したアイテム、どのクエストを中断したか、画面上でどの場所を見ていたか、過去イベントの演出で何が起きたか。
これらはテキストログ、JSON、スクリーンショット、マップ画像、会話台本に分散する。
長いコンテキストへ全部入れる方法もあるが、常に全部を読むNPCは高いし遅い。
しかも、無関係な情報を大量に入れると、モデルが古い会話や別ステージの状態を拾って変な返答をする。
必要な場面だけ検索して戻すほうが、ゲームループには合う。
graph TD
A[ゲーム状態] --> B[会話ログ]
A --> C[スクリーンショット]
A --> D[マップと設定資料]
B --> E[File Search store]
C --> E
D --> E
F[NPCへの入力] --> G[metadataで章やキャラを絞る]
G --> E
E --> H[関連する記憶だけ取得]
H --> I[GeminiでNPC応答を生成]OCR-Memoryの記事で読んだ方式も、似た問題を別角度から扱っていた。
OCR-Memoryはエージェント履歴を画像として保存し、関係する場所だけ探して元ログを戻す。
Gemini File Searchの更新は、そこまで研究寄りに自前実装しなくても、画像とテキストの混在検索をマネージドAPI側へ寄せられる話だ。
ゲームエンジンに直接入れるならmetadataが主役になる
マルチモーダル検索の派手さに目が行くが、ゲーム側で効くのはmetadataのほうだ。
RPGやADVでは、同じキャラクターでも章、ルート、好感度、ワールド状態で参照してよい記憶が変わる。
たとえば第3章のNPCに、第5章の真相を検索で拾わせたら終わりだ。
画像検索の精度以前に、検索対象を絞る境界が必要になる。
File Searchのmetadata filterは、その境界をAPI側の検索前に入れられる。
| metadata | 使いどころ |
|---|---|
character_id | NPCごとの記憶を分ける |
chapter | 未来のイベントを拾わせない |
route | 分岐シナリオの混線を避ける |
scene_id | 直近の場所や演出に寄せる |
build | 開発中ビルドと公開ビルドの資料を分ける |
自作ゲームエンジンやGodot/Unity側に組み込むなら、検索storeをそのまま巨大な記憶箱にしないほうがいい。
イベント進行やキャラ状態はゲーム側の正規データとして持ち、File Searchは「関連資料を引く」役に寄せる。
状態遷移までLLMに任せると、再現性とデバッグがつらくなる。
RAGとしてはPageIndexと逆向きの選択肢
PageIndexの記事では、ベクトル検索を使わず、LLMに文書構造を読ませてツリーRAGを作るアプローチを見た。
PageIndexは「文書のどの章を見るか」を構造から辿る。
Gemini File Searchは、embeddingで近いchunkを探す。
ゲームの設定資料やシナリオ台本は、両方の性質を持つ。
章立てがきれいな世界設定資料なら、PageIndex的なツリーが向く。
一方で、スクリーンショット、背景ラフ、UI画像、マップ断片、会話ログが混ざると、階層だけでは探しにくい。
今回のFile Search更新は後者に寄っている。
ここで画像が入る意味は大きい。
「青い看板のある酒場」「赤い橋の近くで会ったキャラ」「このUIパネルに出ているクエスト名」のような検索は、テキストだけのRAGだと前処理が面倒だった。
画像をcaption化して別indexに入れる手もあるが、captionの時点で情報が落ちる。
File Search側で画像をnativeにembeddingできるなら、少なくともプロトタイプではその前処理を省ける。
まだゲーム向けの記憶基盤そのものではない
公式ドキュメントには制限がいくつかある。
File SearchはLive APIでは使えず、Google Search groundingやURL Contextなど他のtoolとは現時点で組み合わせられない。
ファイル単位の上限は100MB。
料金面も気になる。
File Searchの課金ポイントは、index作成時のembedding、検索時のembedding、取得された文書tokenの3箇所だ。
index作成時のembeddingは1Mトークンあたり$0.15。
マルチモーダルで gemini-embedding-2 を使う場合はモデル側の料金が適用され、テキストが1Mトークンあたり$0.20、画像は1枚あたり約$0.00012になる。
検索query時のembeddingは無料。storageも無料。
検索で引いてきた文書tokenは、そのままモデルへのcontext tokenとして通常のモデル料金で課金される。
Gemini 2.5 Flashなら入力1Mトークンあたり$0.30、2.5 Proなら$1.25〜$2.50だ。
storeの容量上限はTierで変わる。
| Tier | store上限 |
|---|---|
| Free | 1 GB |
| Tier 1 | 10 GB |
| Tier 2 | 100 GB |
| Tier 3 | 1 TB |
store容量はアップロードした元データだけでなく、生成されたembeddingも含む。
Googleの説明では入力データの約3倍のサイズになるとされている。
Free tierの1GBだと、元データ換算で300MB程度が実質上限だ。
スクリーンショット数十枚と会話ログ程度のプロトタイプなら収まるが、コンセプトアートや動画キャプチャまで入れ始めると早い段階でTier 1が必要になる。
1 storeあたり20GB未満を推奨しているので、Tier 2以上でもstoreは用途別に分けたほうがいい。
gemini-embedding-2 のマルチモーダル課金をメディア種別ごとに並べる。
| メディア種別 | indexing単価 |
|---|---|
| テキスト | $0.20 / 1Mトークン |
| 画像 | $0.00012 / 枚 |
| 音声 | $0.00016 / 秒 |
| 動画 | $0.00079 / フレーム |
画像は1枚あたり約0.012セントで安い。
音声と動画にも対応しているが、ゲーム用途で使う場面はほぼテキストと画像だろう。
検索結果をLLMに渡す際のモデル料金も、選択肢によって差が大きい。
| モデル | 入力 / 1Mトークン | 出力 / 1Mトークン |
|---|---|---|
| 2.5 Flash-Lite | $0.10 | $0.40 |
| 2.5 Flash | $0.30 | $2.50 |
| 2.5 Pro（200k以下） | $1.25 | $10.00 |
| 2.5 Pro（200k超） | $2.50 | $15.00 |
Flash-Liteは入力がFlashの1/3。
検索を大量に回すプロトタイプでは、ここの差が月額に直接響く。
Proは200kトークンを超えると入力単価が倍になるので、File Searchで大きなchunkを引く構成ではこの境界にも注意がいる。
Batch APIを使うとembeddingもモデル推論も50%割引になる。
リアルタイム応答が不要な開発パイプラインでは、indexingも推論もBatchに回せば半額だ。
1キャラ分のプロトタイプで試算してみる。
会話ログ200件（約20万トークン）、スクリーンショット50枚、設定テキスト5万トークンを1つのstoreに入れる。
indexingはテキスト25万トークンで$0.05、画像50枚で$0.006、合わせて約$0.056。初回のみの課金なので誤差だ。
1回の検索でchunkが平均2,000トークン返り、NPCが200トークン応答する想定で、Flash-Liteなら1回あたり約$0.0003になる。
1日100回の検索で$0.03、月$1未満。Flashに上げても月$3程度で、個人開発なら十分に試せる水準だ。
ゲームの毎フレーム処理に入れるものではなく、会話開始時、クエスト更新時、長めのNPC応答時に呼ぶ外部検索として考えるほうが自然だ。
citationもゲーム用途では少し扱いが違う。
業務RAGなら「何ページに根拠があるか」をユーザーに見せる。
ゲームNPCではそのままページ番号を出すわけにはいかないが、開発中のデバッグUIには使える。
NPCが変なことを言ったとき、「どの台本やスクリーンショットを拾ったのか」を追えるだけで調整がかなり楽になる。
小さく試すなら会話ログとスクショだけでいい
最初から完全なNPC記憶システムを作る必要はない。
プロトタイプなら、1キャラ、1ステージ、会話ログ数十件、スクリーンショット数十枚で十分だ。
Gemini File Search storeにそれらを入れ、character_id と scene_id で絞って、NPCへの入力前に関連chunkだけ取る。
見るべき挙動は検索精度より先に、混線の少なさだ。
別キャラの記憶を拾わないか。
未来のイベントを拾わないか。
スクリーンショット由来の情報が会話に混ざっても不自然ではないか。
検索結果を毎回プロンプトへ足したとき、NPCの口調やJSON出力が崩れないか。
このあたりが通るなら、次に画像枚数を増やし、マップ、イベントCG、UI状態、クエストログへ広げる。
逆に少量で混線するなら、embeddingモデルより先にmetadata設計とstore分割を疑ったほうがいい。
ゲーム本体より開発パイプラインのほうが先にハマる
ランタイムでNPCの記憶に使う絵は楽しいが、実際に先に役立つのは開発時のほうだろう。
ゲーム開発の現場はドキュメントが散らかる。
世界設定のテキスト、キャラ設定シート、コンセプトアート、レベルデザインのスクリーンショット、シナリオ台本、プレイテストの動画キャプチャ、QAのバグ報告。
これらがConfluence、Google Drive、Slack、ローカルフォルダに分散していて、「あの赤い橋のあるマップ、どのステージだっけ」「このキャラの初登場はどの章の台本だっけ」に答えるのが毎回手作業になる。
File Searchのマルチモーダル化は、この散在をAPI経由の検索に乗せられる。
コンセプトアートとシナリオ台本を同じstoreに入れておけば、「このキャラが出てくるシーンと関連する背景アートを探して」がembeddingベースで返ってくる。
metadataに chapter や milestone を振っておけば、「M3までの素材だけ」と絞れる。
シナリオの整合性チェックにも使える。
長編RPGやADVで、別の章を書いているライターが「この伏線、もう回収済みだっけ」を確認するとき、全台本をgrepするのは辛い。
File Searchなら「〇〇が真相を知る場面」のような自然言語クエリで、該当する台本chunkとそのスクリーンショットが出てくる。
citationでページ番号まで返るので、原典に当たるコストも下がる。
開発時なら、レスポンスが数百ミリ秒遅くてもゲームループは止まらない。
API呼び出しの料金も、CI/CDのビルドコストやアセット管理ツールのライセンス料に比べれば誤差の範囲だ。
ランタイムに入れる前に、開発中のシナリオツールやQAレビューボードに検索窓として組み込むほうが、投資対効果が先に見える。