こんにちは！DX開発事業部の髙﨑です。

7月30日, 31日の両日に渡り、Google Cloud Next Tokyo 26に参加してきました。
今回はDAY2に参加したセッション「BigQueryとGeminiバッチ推論で作るパーソナライズAI実践アークテクチャ」の概要とセッションを聴いて感じたこと・学んだことをまとめようと思います！！

このセッションでは、AIチューターの事例をもとに、BigQueryとGeminiバッチ推論を活用して学習者一人ひとりの理解度や「つまずき」に合わせた指導を実現する、パーソナライズAIの実践的な開発・運用アーキテクチャについて述べられていました。

また、Geminiを用いた推論のコスト最適化に関する学びがありましたので、紹介できればと思います！！

AIチューター実現における最大の課題

まず、チューターとは個人指導の教師・学習や進路の相談に乗る担当者などを指します。つまり、今回のテーマはチューターをAIに任せたいということですね。しかし、学習者の学力・思考・つまずき方は当然バラバラで、100人いれば100通りの対応が必要になります。

この課題はAIチューターを実現する上で最も重要であり、最も難しい課題と言えると思います。また、この課題があるからこそAIチューターをパーソナライズするという方針が必然であることが分かります。

課題：AIチューターにおけるパーソナライズの必要性

  • 単に問いに答えるだけのAIでは不十分であり、学習者ごとに異なる「つまずき」のレベルに応じた指導が必要である。
  • 一人ひとりに最適な指導を提供するには、学習ログからユーザーの状態を正確に読み解く必要がある。

課題解決のためのアプローチ

この課題を解決するために、「学習ログ→学習者コンテキスト→LLMの振る舞い」とう流れが重要であると述べられていました。つまり、この事例においては「パーソナライズ」＝「学習者コンテキストによって、LLMの振る舞いを変える」ということであり、そのために細かい学習ログを収集する必要があります。


例えば、学習ログから計算ミスが多いことが特定できた場合、その生徒の指導では、途中式を確認しながら進められる説明を返したい、といった具合です。

では、この流れを踏襲することで、実際にどの程度効果が得られるのでしょうか。セッションでは3つの学習者ケースを例として挙げていました。

一番左の「計算ミスが多い」ケースでは、

  • 符号ミスが多いので、移項時の符号確認を促す。
  • 答えを急がず、1ステップずつ確認する。
  • 必要に応じて、途中式や検算を必ず行わせる。

というような学習者コンテキストを生成することで、LLMが途中の確認を促す振る舞いを行うようになっています。

システム構成とコスト削減

ここまでの話を聞いて、「確かに効果はありそうだけど、生徒一人ひとりの学習ログを毎回AIに読み込ませて分析していたらコストが高くつくのでは…？」と思った方も多いのではないでしょうか。

実際に、この「100人100通りのパーソナライズ」を数十万人規模で愚直にリアルタイム実装してしまうと、大きなトークン費用とレート制限の壁に当たってしまうそうです。


そこで、セッションではアーキテクチャの工夫によって劇的なコスト削減と安定運用を実現する方法を紹介していました。個人的には、ここがセッション全体を通して一番学びになったと感じた部分でした！！

コスト削減のポイントは大きく分けて以下の3点です。

1. Gemini Batch推論の活用で推論単価を半額に

ユーザーの質問に対する即時回答など「今すぐ」必要な処理はリアルタイムで行い、学習ログの解釈やコンテキストの更新といった「後でよい」処理は非同期に処理を行う Gemini Batch に回す。

スライドのシミュレーション（30万人規模・月120万回実行時）によると、月間で約86.4万円（年間で約1,000万円以上！）ものコスト削減効果がある計算であることが分かります。
参考：Agent Platform での AI モデルの構築とデプロイの費用

2. 「今すぐ」と「後で」の切り分け

ユーザーがAIとやり取りする「その瞬間」に毎回過去の全ログをAIに解釈させるのではなく、

  • リアルタイム（オンデマンド）：ユーザーの質問への即時回答、直接のヒント提示
  • 非同期（Batch推論）：学習ログの集約・解釈、学習者コンテキストの更新

と役割を明確に分けることで、ピーク時の負荷や無駄なリアルタイム推論コストを最小限に抑える。

3. 「ロジック」と「推論」の明確な役割分担

すべてのデータをAIの推論に任せるのではなく、

  • ロジックで出せるもの：正誤率などの習熟度、学習頻度、最終学習日など
  • 推論が必要なもの：つまずき傾向の定性的な分析、説明の好みの解釈など

を徹底的に切り分ける。


ロジックで処理できる事前データをDB側で整形してからLLMに渡すことで、プロンプトに含めるトークン数自体を大幅に絞り込み、入力費用を削減しています。

感じたこと・学んだこと

今回のセッションで最も大きな学びとなったのは、「すべてをLLM（推論）に頼らない」という設計上の割り切りです。

AI機能を開発するとなると、つい「何でもLLMに読み込ませて解釈・処理させたい」と考えてしまいそうですが、正誤率や学習頻度といったルールや集計で計算できるものはロジックに逃がし、AIには「定性的な解釈や文脈の言語化」という得意領域だけに集中させることが重要です。このロジックと推論の明確な役割分担こそが生成AIサービスの精度向上とコスト削減を両立させる最大の鍵なのだと痛感しました！

理想のユーザー体験を追い求めつつも、現実的なコストや速度の課題をアーキテクチャの力で解決していく姿勢を忘れずに持ち続けたいと思います！！

今回のブログは以上になります！
最後まで読んでいただきありがとうございました🙇‍♂️