2026.08.26 コラム
【テックコラム】Memory Bank のメモリ生成 1 回で、Gemini は最大 4 回呼ばれる
DataCurrent の金子です。今回は、Agent Platform の Memory Bank でメモリを生成したとき、裏側で Gemini が何回呼ばれるのかを調べました。
Memory Bank は、ユーザーとエージェントの会話から、今後のやり取りに役立つ情報を長期メモリとして生成する機能です。今回扱うメモリには、情報を文章で保持する「自然言語メモリ」と、あらかじめ決めた Schema の項目ごとに保持する「Profile」があります。
本検証では、自然言語メモリのみ、Profile のみ、両方を有効にした 3 条件を比較します。
※ この記事は、2026 年 8 月時点の Google Cloud の仕様と検証結果に基づいています。同じ呼び出し回数になることを保証するものではありません。
先に結論
タイトルにあるように、Memory Bank の GenerateMemories API を 10 回実行したところ、Gemini は自然言語メモリのみで 20 回、Profile のみで 20 回、両方を有効にすると 40 回呼ばれました。
Memory Bank のメモリ生成 1 回が、Gemini の呼び出し 1 回に対応するわけではありませんでした。料金を確認するときは、GenerateMemories の実行回数ではなく、内部の Gemini 呼び出しで消費された入力・出力トークン数を確認する必要があります。
「メモリ生成 1 回」の定義
この記事では、10 イベントを渡した GenerateMemories API の 1 リクエストを「メモリ生成 1 回」と数えます。
ユーザーとモデルの 50 往復、合計 100 イベントを用意し、10 イベントずつに分けて GenerateMemories を 10 回実行しました。
100 イベント
└─ 10 イベント × 10 リクエスト
└─ Gemini の呼び出し回数を Cloud Monitoring で確認
検証条件
| 項目 | 設定 |
|---|---|
| Memory Bank の Location | asia-northeast1 |
| Generation model | gemini-3.5-flash（asia-northeast1） |
| Embedding model | gemini-embedding-2（global） |
| 会話イベント | 100 件（user と model の 50 往復）、合計 1,115 トークン |
検証開始前に、自然言語メモリを使う条件には、1 件あたり 42 トークンの自然言語メモリを 1,000 件（合計 42,000 トークン）登録しました。Profile を使う条件には、合計 77 トークンの既存 Profile を登録しました。
検証結果
Gemini の呼び出し回数
| 条件 | メモリ生成 | Gemini の呼び出し | メモリ生成 1 回あたり |
|---|---|---|---|
| 自然言語メモリのみ | 10 回 | 20 回 | 2 回 |
| Profile のみ | 10 回 | 20 回 | 2 回 |
| 自然言語メモリと Profile | 10 回 | 40 回 | 4 回 |
入出力トークン数
Gemini が処理したトークン数は次のとおりです。
| 条件 | 入力トークン数 | 出力トークン数 | メモリ生成 1 回あたりの平均入力 |
|---|---|---|---|
| 自然言語メモリのみ | 61,316 | 36,991 | 約 6,132 |
| Profile のみ | 67,818 | 27,330 | 約 6,782 |
| 自然言語メモリと Profile | 129,198 | 68,207 | 約 12,920 |
これらは、Cloud Monitoring の Publisher Model メトリクスで確認した値です。このメトリクスには、Vertex AI 上で Gemini が実際に処理した呼び出しとトークンが記録されます。
補足：Memory Bank 内部の Gemini の動きを推測する
自然言語メモリ 1,000 件の合計は 42,000 トークンです。一方、自然言語メモリのみの条件では、Gemini への入力は合計 61,316 トークンで、メモリ生成 1 回あたりの平均は約 6,132 トークンでした。
この結果と、メモリ生成 1 回につき Gemini が 2 回呼ばれていることを考慮すると、1 回目で会話に関連する既存メモリを検索で絞り込み、2 回目で候補を会話と比較して生成・統合する処理が内部で行われているのかもしれません。
仮にこの 2 段階の処理だとすると、2 回目のプロンプトに入力された既存メモリは 100 件程度だったとみられます。これは、メモリ生成 1 回あたり約 6,132 トークン、既存メモリ 1 件あたり 42 トークンという実測値からの概算です。正確な件数は分かりません。
Embedding の観測範囲
今回、Cloud Monitoring で確認できたのは、生成モデルである Gemini 3.5 Flash の呼び出し回数とトークン数です。gemini-embedding-2 も Memory Bank に設定しましたが、Cloud Monitoring には利用状況を示す時系列データが記録されず、Cloud Billing にも Embedding の SKU と料金は表示されませんでした。そのため、本記事では実測できた生成モデルの処理を対象に結果を整理しています。
まとめ
今回の検証では、メモリ生成 1 回につき、自然言語メモリのみと Profile のみでは Gemini が 2 回、両方を有効にすると 4 回呼ばれました。自然言語メモリに加えて Profile も有効にした場合、自然言語メモリのみと比べて、Gemini の呼び出し回数と入出力トークン数はどちらも約 2 倍になりました。
Memory Bank の料金を見積もるときは、API の実行回数をそのまま Gemini の呼び出し回数として扱うのではなく、次のように計算するのがよさそうです。
想定料金 = メモリ生成回数 ×（1 回あたりの入力トークン数 × 入力単価
＋ 1 回あたりの出力トークン数 × 出力単価）
今回の条件では、メモリ生成 1 回あたりの入力は、自然言語メモリのみと Profile のみで約 6,000～7,000 トークン、両方を有効にすると約 13,000 トークンでした。実際のトークン数は会話や既存メモリによって変わるため、本番に近い条件で少量のメモリを生成し、Cloud Monitoring の実測値から見積もるのが確実です。
参考
最後に
自社に専門人材がいない、リソースが足りないなどの課題をお持ちの方に、エンジニア領域の支援サービス（Data Engineer Hub）をご提供しています。お困りごとがございましたら、ぜひお気軽にご相談ください。
本件に関するお問い合わせは下記にて承ります。
株式会社DataCurrent
info@datacurrent.co.jp