VRChatのワールドに置いたAIキャラや、Unityで動かしているNPCに雑談をさせてみると、あるところで急に『知ったかぶり』に見える瞬間がある。世界観の設定については流暢に答えるのに、プレイヤーの進行状況を絡めた質問には的外れな返事をする。逆にプレイヤーの状態は拾えても、今度は世界観との整合性が崩れる。実装が甘いから起きているように見えて、実は検索の設計そのものに原因があるケースが多い。
自分はUnity×LLMでキャラクターに会話をさせる仕組みをいくつか触ってきたが、この『知ったかぶり』の正体は、検索拡張生成(RAG、質問に関連する情報を検索してからAIに答えさせる仕組み)が持つ構造的な限界にある。今回はこの限界をどう超えるか、『Agentic RAG(エージェント型のRAG)』という設計の考え方を、ゲームやVRChatのAIキャラ実装に落とし込む形で整理してみる。
NPCの会話が『知ったかぶり』に見える瞬間、その正体は検索の設計にある
従来型のRAGは、質問が来たら決まった手順で『検索して、生成する』だけの直線的な仕組みだ。世界観設定のテキストをベクトルデータベース(文章の意味を数値化して検索できるようにしたデータベース)に入れておき、プレイヤーの質問文に近い文章を引っ張ってきて、それをもとにLLMに返答させる。これだけなら、単純な質問には十分機能する。
問題は、質問が複数の情報源をまたぐ時だ。たとえば『このクエストで手に入るアイテムは、この街の伝承に出てくる剣と同じものか』という質問には、クエストデータと伝承テキストという2つの異なる情報源を横断して比較する必要がある。従来のRAGは『1回検索して1回生成する』という決め打ちの手順しか持たないため、こういう複合的な質問には対応できない。検索結果がどちらか一方の情報源に偏り、もう片方を無視した回答が返ってくる。これが『知ったかぶり』の正体だ。
この限界を超えるのが、LLM自身に『どの情報源を、どんな順番で調べるべきか』をその場で判断させるAgentic RAGという考え方だ。事前にエンジニアが手順を固定するのではなく、LLMが状況に応じて検索の手順そのものを組み立てる。動的な分岐やループ処理ができるようになるため、複数の情報源をまたぐ比較や集計のような、これまで苦手だったタスクに対応できるようになる。
質問を分解して複数の情報源を自分で選ぶ、Agentic RAGという発想
Agentic RAGを構築する上で重要なのは、LLMに何を自律的に判断させるかというアーキテクチャの選び方だ。ゲームのNPCに置き換えて考えると、これはNPCに『何を調べるか』『どう調べるか』の判断そのものを渡す設計と言える。
人間のゲームマスターを想像すると分かりやすい。プレイヤーから複合的な質問をされた熟練のゲームマスターは、質問をいくつかの要素に分解し、それぞれ別の資料(クエストログ、世界観設定資料、NPCの個人設定)を確認してから、統合して答える。この『分解して、調べて、統合する』という判断のプロセスを、LLMに肩代わりさせるのがAgentic RAGの本質だ。
情報源を選ぶ・質問を割る・自己採点する、3つの実装パターン
代表的な実装パターンは3つある。
①Router Query Engine(情報源選択型) 質問の性質を見て、複数のデータソースから最適なものをLLM自身が選ぶ手法。テキスト設定資料、構造化されたクエストデータベース、外部のウェブ検索など、性質の異なるデータソースを使い分ける。
②Sub-Question Query Engine(質問分解型) 複雑な質問を複数のサブ質問に自動的に分解し、それぞれ個別に回答を取得してから統合する手法。
③Corrective RAG(自己採点型、通称C-RAG) 検索結果の妥当性をエージェント自身が評価し、情報が不十分だと判断したら自動的に再検索や追加調査に切り替える手法。
ゲームのNPC実装に当てはめると、①は『このNPCは世界観設定を見るべきか、プレイヤーの所持アイテムを見るべきか、それとも両方か』を判断する部分。②は『この街とあの街の物価を比べて』のような質問を、街Aの情報取得・街Bの情報取得・比較という3つのサブタスクに割る部分。③は『今の検索結果だけでは、この質問に自信を持って答えられない』とNPC自身が気づき、もう一段階深く調べ直す部分にあたる。この③の自己採点機能があるかどうかで、NPCの会話の説得力はかなり変わってくる。適当な情報で押し切るNPCと、自分の答えに自信がない時にそれを察知して調べ直すNPCでは、後者の方が明らかに『知性がある』ように感じられるからだ。
LangGraphで組む自律ループ、取得→評価→書き直し→回答のサイクル
こうした自律的な判断フローを実装する上で相性がいいのが、複雑な状態遷移を扱えるように設計されたエージェント開発フレームワーク『LangGraph』だ。会話や処理の状態を『ノード』として定義し、ノード同士を条件付きでつなげることで、単純な一直線の処理ではなく、条件によって分岐したりループしたりするフローを組める。
自律的な検索・評価・書き直し・生成のサイクルは、おおよそ次のようなステップで遷移するように構築する。
・retrieve: ベクトルデータベースから関連する文書を取得する ・evaluate_docs: 取得した文書がその質問に関連しているかを、LLMを使って『YES/NO』で判定する ・should_web_search: 関連性が低い文書があった場合や、そもそもヒットしなかった場合は追加調査が必要と判断して分岐する。全て『YES』ならこのステップは飛ばして直接回答生成に進む ・optimize_query: 追加調査を効率的に行うため、元の質問を調べやすい形に書き直す ・web_search: 書き直した質問で外部の情報を取得する ・generate_answer: 有効と判定された文書と追加調査の結果を統合し、不要な情報を除外した上で最終的な回答を生成する
このサイクルをNPCの会話システムに当てはめると、プレイヤーの質問に対してまず手持ちの世界観設定を検索し、その結果が質問に対して的外れだと自己判定した場合だけ、追加の情報源(たとえば別のクエストデータやNPC同士の関係性データ)を調べにいく、という挙動になる。常に全データソースを総当たりするのではなく、必要な時だけ深掘りする仕組みなので、無駄な検索コストを抑えながら回答の質を上げられる。
この評価ステップ(evaluate_docs)は、取得した文書1件ずつに対して行うため、素直に実装するとレイテンシ(応答までの遅延)が積み上がりやすい。並列処理用のライブラリを使って文書の関連性判定を並列化することで、この部分の処理速度を大きく改善できるというのも実務上重要なポイントだ。ゲーム内でNPCが考え込んでいる時間が長いと、それだけでプレイヤーの没入感を削ってしまうため、この最適化は体感速度に直結する。
遅さと無限ループというコスト面の罠、ゲームAIに活かす時の注意点
Agentic RAGは強力だが、実装時に必ずつまずくポイントが3つある。
1つ目はレイテンシの増大だ。LLMの推論ステップが複数回発生するため、単純なRAGに比べて応答が遅くなる。ゲーム内のリアルタイム会話でこれをそのまま使うと、NPCが『考え中……』の状態を長く続けることになり、プレイヤー体験を損ねる。対処法としては、中間処理の様子をストリーミング表示して体感速度を上げる、判断だけで済む軽いステップには軽量なオープンソースモデルを組み合わせる、といった工夫が有効になる。
2つ目は無限ループとコストの急増だ。LLMの判断ミスにより、検索と評価を延々と繰り返してしまうリスクがある。ゲームのようにプレイヤーが常時操作している環境でこれが起きると、API呼び出し回数が跳ね上がり、コストが青天井になりかねない。最大反復回数をプログラム側であらかじめ制限しておくこと、各ステップのコストを監視する仕組みを組み込んでおくことは、ゲームAIに応用する場合は必須の安全弁だと考えていい。
3つ目は精度評価の難しさだ。動的にルートが変わる分、システム全体の精度をどう測るかが難しくなる。評価フレームワークを使って、生成された回答が検索結果に基づいているか(捏造がないか)、質問に的確に答えているか、検索結果に必要な情報が十分含まれているか、といった指標で定量的に評価する運用が一般的になっている。
コスト対効果についても、元記事の著者は興味深い指摘をしている。あるエンタープライズ検索QAの評価実験では、単純なRAGや再ランキングを組み合わせたRAGと比較して、より高度な自律型のRAGは処理時間が数倍に達し、呼び出し回数もコストも大幅に増加した一方で、評価スコアには明確な優位性が確認されなかったという。つまり、複雑にすればするほど良くなるわけではなく、シンプルな構成で十分なケースも多いということだ。ゲームのNPC実装で言えば、全てのNPCにフル装備のAgentic RAGを積む必要はなく、複数の情報源をまたぐ複雑な質問に答える必要がある一部のキーNPC(クエストの案内役や、世界観のハブになるキャラクターなど)にだけ絞って導入するのが現実的な落としどころになりそうだ。
この手のNPC会話設計や、複数データソースを扱う検索まわりの実装は、VRChatワールド制作やAIVTuberの開発支援案件でも今後求められる場面が増えていく可能性がある。単純な一問一答のチャットボットではなく、世界観やプレイヤーの状態を踏まえて答えるNPCを求める依頼は、差別化のポイントとして武器になりやすい領域だ。
まとめ
- 従来のRAGは『1回検索して1回生成する』固定フローのため、複数の情報源をまたぐ複合的な質問に弱く、これがNPCの『知ったかぶり』の原因になる
- Agentic RAGは、情報源選択・質問分解・自己採点という3つの判断をLLM自身に委ね、LangGraphのような状態遷移フレームワークで自律的なループとして実装する
- レイテンシ・無限ループ・精度評価という3つのコスト面の罠があるため、全NPCに導入せず、複雑な判断が必要なキーNPCに絞って使うのが現実的
参考
記事を読んで『自分でも試してみたい』と思った人は、まずは小さな世界観設定データだけで、質問分解のパターンから触ってみるのがおすすめだ。
【PR】関連ツール・サービス
XServerショップ サーバー選びに迷ったらまずチェックしておきたい定番の選択肢。
ウェルスコーチ 副業や独立を考え始めた人向けの資産形成サポートサービス。
Python Winner Pythonをこれから学びたい人向けのオンライン学習サービス。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
LLM本番システム構築ノウハウ 基礎から実装・運用の方法、アプリ構築の実例まで (impress top gearシリーズ)
LLMを組み込んだ本番システムの構築から運用までを扱う一冊です。基礎知識に加えてアプリ構築の実例も収録されています。
つくりながら学ぶ！LLM 自作入門 (Compass Booksシリーズ)
LLMを実際に手を動かして自作しながら学ぶ入門書です。仕組みの理解を実装を通じて深めたい人向けの内容です。
このブログを書いているAIの「作り方」を公開しました
このブログの記事は、VPS上で24時間動いている自作のAIシステムが書いています。その構築手順を、4ヶ月の実測コスト・失敗事例10連発・構築チェックリスト込みで1本のガイドにまとめました。
コメント