こんにちは、㈱MMOLにて、AI & ロボティクス インプリメンターをしています三木です。
「Created to Create」への投稿は4回目、こちらの「つかう、つくる」マガジンへの投稿は3回目となります。
ChatGPT、Claude、Geminiをはじめとする汎用LLMは、様々なアプリとの連携機能が拡大して利便性が増しています。
汎用LLMを、例えばGoogleドライブのようなクラウドストレージを連携すると。
日々変化する広範な社内ナレッジを常に最新の状態で、動的にRAGの検索対象にすることができます。
日常的なライトな利用には、大変有効だと思います。
多くの場合、むしろこれだけでも、かなり助かると思います。
一方で、検索対象（情報ドメイン）が広い分、回答生成までに時間を要すケースがあったり、APIベースの連携に留まるゆえ、回答内容が表層的になりがちだったりします。
タスクの要求機能として、それで十分であれば、全く問題ないです。
本記事では、実際に回答品質として、どのような違いがあるのか、以下に会話の実験結果をご紹介します。
（１）汎用LLMとドライブ接続
実際の挙動から判断すると、RAGの検索技術としては、キーワード検索／全文検索を基盤とした仕組みである可能性が高いと考えられます。
🔸質問例：
「docsを参照して、Genome Layer（ゲノムレイヤー）のナビゲーション項目を教えて。」
※ 「docs」は、Googleドライブ内のフォルダ名（例）です。
🔸回答結果：
①ChatGPT 5.2 + Googleドライブ接続
→
応答は早い。
参照内容と回答内容は、正しい。
しかし、内容は表層的であり、キーワード検索、全文検索の挙動に近い。
他の関連するコンテキスト（文脈）までを包括した回答ではない。
②Claude Sonnet 4.5 + コネクタ（Googleドライブ検索）
→
応答は遅い。参照ソースの特定にかなり時間を要していた。
参照内容と回答内容は、正しい。
しかし、内容は表層的であり、キーワード検索、全文検索の挙動に近い。
他の関連するコンテキスト（文脈）までを包括した回答ではない。
③Gemini 3 Pro（デフォルトでGoogleドライブ接続）
→
応答は早い。
参照内容と回答内容は、正しい。
しかし、内容は表層的であり、キーワード検索、全文検索の挙動に近い。
他の関連するコンテキスト（文脈）までを包括した回答ではない。
（２）汎用LLMのカスタマイズ版
GPTs、Claude Project、Gemのような汎用LLMのカスタマイズ版として、参照ソース（情報ドメイン）を明示的に与えた場合、同様の質問を投げかけてみました。
具体的には、Googleドライブのdocsフォルダ内のドキュメントをソースとして登録したGPTsを使用しました。
RAGの検索技術としては、ベクトル検索単体でも、キーワード検索 / 全文検索単体でもなく、両者を組み合わせたハイブリッド検索と考えられます。
ハイブリッド検索（Hybrid Retrieval）
= ベクトル検索 × キーワード／全文検索 × 再ランキング
パイプラインとしては、下記の通りです。
① クエリ理解
├ 意味検索用クエリ（embedding）
└ キーワード／フレーズ抽出
② 並列リトリーバル
├ ベクトル検索（Top-k_semantic）
└ 全文検索（BM25など）（Top-k_lexical）
③ 結果統合
├ スコア正規化
├ 重複排除
└ 候補集合の生成
④ 再ランキング
└ Cross-Encoder or LLMで「質問との適合度」を再評価
⑤ LLMへのコンテキスト投入
各技術により、下記の回答品質を実現しています。
・全文検索（キーワード検索を内包する上位概念）：確実性
・ベクトル検索：柔軟性
・再ランキング：最終品質保証
これらは、ユーザーがどのような形式でソース（情報ドメイン）を登録したとしても、ユーザーがどのような文言で質問をしたとしても、回答品質を担保するために、組み合わせられているものです。
字面一致も意味一致も、どちらも必要という考え方ですね。
🔸質問例：
「Genome Layer（ゲノムレイヤー）のナビゲーション項目を教えて。」
🔸回答結果：
→
応答は早い。
参照内容と回答内容は、正しい。
内容は、キーワード検索、全文検索のような正確性と、他の関連するコンテキスト（文脈）までの意味的な包括性を備えた回答になっている。
まとめ
以上より、（１）と（２）で、コアとする参照ソースは同一であったとしても、回答品質には明確に有意差があることを確認できました。
理想的には「1体の万能AIを作ろう・1体で完結させよう」としたくなる気持ちも出やすいところです。しかし、クライアント様の環境への実装（社会実装）という意味では、現時点では、1体で完結は、現実的ではないことを再認識しました。
当面の間は、ユースケース、特に扱いたい情報ドメインに応じて、AIを分けて用意して、マルチエージェントシステムと言われるように、複数AIのオーケストレーションで実装することが大切なのだろうと思います。
今回は実験事例に挙げていませんが、エージェントプラットフォーム（miiboやチャネルトークなど）やNotebokLMも、検索技術の公式ドキュメントでの明文化の有無によらず、ベクトル検索を含むハイブリッド検索が搭載されていると考えられます。
よって、ユースケースや目的に応じて、「汎用LLM」、「汎用LLMのカスタム版」、「プラットフォームで作成するAIエージェント」を適宜、使い分ける・組み合わせることが大切になります。
最後までお読みくださり、ありがとうございます。
今後もAI、ロボットといった技術領域を中心に、今回のようなふと気になり試してみたことなども発信していければと思っています。
引き続きよろしくお願いいたします！
弊社では、クライアントさまの「今」の業務に携わりながら、「人を採用すべき領域」と「効率化すべき業務」を見極めるところから伴走・支援するサービスをご提供しています。
「人は足りないが採用費は高い」
「特定の人に業務が集中している」
など、お悩みがございましたら、どんな小さなご相談からでも構いません。
ぜひお気軽にお問い合わせください。
▶︎ 弊社サービスページ
▶︎ 資料請求・お問い合わせ
