はじめに
「ホットワード5選」として続けてきた番外編も、今回で最後になります。これまでHarness、Loop Engineering、Context Engineering、Memoryといった、AIエージェントの設計思想そのものを扱ってきましたが、最終回のテーマはRAG（Retrieval-Augmented Generation）とローカルLLMです。
この二つは、それぞれ別の技術要素として語られることが多いのですが、実際に手を動かしていると「モデルにどんな情報をどう渡すか」という同じ問いの、二つの側面なのだと感じるようになりました。今回はその視点から整理してみます。
1. RAGとは何か
RAGを一言で説明すると、質問やタスクに関連する情報を外部から検索してきて、それをプロンプトに含めた上でLLMに渡す仕組みです。ベクトルデータベースに文書を埋め込んでおき、ユーザーの入力と意味的に近いものを検索し、その結果をコンテキストとして注入する、という流れが典型的です。
ここで大事なのは、RAGは「モデルの知識を増やす」技術ではないという点だと思います。モデル自体のパラメータは何も変わりません。やっているのは、そのタスクに必要な情報を、必要になったその瞬間に外部から取ってきて渡す、という作業です。知識を内側に溜め込むのではなく、都度、外から調達する。この設計思想の違いを意識しておくと、RAGをどこで使うべきかの判断がだいぶ楽になります。
2. Context EngineeringやMemoryとの関係
以前の記事で扱ったContext Engineeringは、AIエージェントに「何を見せるか」を設計する営みでした。RAGは、その「何を見せるか」を動的に決めるための手段の一つだと捉えると、位置づけがはっきりします。固定的に全部渡すのではなく、そのタスクにとって本当に必要な情報だけを検索して絞り込み、限られたコンテキストウィンドウの中に収める。
また、以前の記事で扱ったMemory設計とも重なる部分が多いです。エージェントが過去のやり取りや実行結果を覚えておく仕組みとしてMemoryを設計するとき、その記憶の保存先や検索方法として、結局RAGと同じ技術スタック（埋め込み、ベクトル検索、ランキング）を使うことになるケースがほとんどです。RAGとMemoryは別の概念として語られがちですが、実装レベルではかなり地続きだと感じています。
3. ファインチューニングとの使い分け
「モデルに知識を持たせたいなら、ファインチューニングすればいいのでは」という話もよく出てきます。ここは使い分けが大事なところだと思います。
ファインチューニングは、モデルの振る舞いそのもの、例えば口調や出力フォーマット、特定のタスクへの適性を変えるのには向いています。一方で、頻繁に更新される情報や、社内の特定文書、最新のログといったものを覚えさせるのには不向きです。情報が更新されるたびに再学習が必要になり、コストも時間もかかります。
RAGはその逆で、情報源を更新するだけで、モデル自体には一切手を入れずに最新の状態を反映できます。個人的には、振る舞いを変えたいのか、参照する情報を変えたいのか、を最初に切り分けておくと、どちらの手段を選ぶべきかで迷わなくなる印象があります。
4. 長いコンテキストウィンドウとの使い分け
もう一つよく比較されるのが、長いコンテキストウィンドウとの使い分けです。最近のモデルはコンテキストウィンドウがかなり広がってきているので、「全部プロンプトに詰め込めばRAGはいらないのでは」という考え方も一定の説得力を持ちます。
ただ、実際に試してみると、コンテキストが長くなるほど推論のコストとレイテンシは増えますし、関係のない情報が大量に混ざることで、モデルが本当に重要な箇所を見落とすリスクも上がるように感じます。数十件程度の文書であれば全部渡してしまう方がシンプルで速いこともありますが、数万件、数十万件の規模になってくると、検索して絞り込む工程を挟んだ方が結果的に安定するという印象を持っています。このあたりは扱うデータの量と更新頻度によって、都度判断するのが現実的だと思います。
5. ローカルLLMを使う理由
ここからはローカルLLM、つまりクラウドのAPIを介さず、自社の環境や手元のマシンでLLMを動かす選択肢について書きます。
理由としてよく挙がるのは、プライバシー、コスト、レイテンシ、オフライン要件の4つです。医療や金融、公共機関のように、機密性の高いデータを外部のAPIに送ること自体が難しい業界では、データを外に出さずに処理できることが前提条件になります。またAPI呼び出しが積み重なると従量課金のコストが無視できなくなる場面もありますし、ネットワークを経由しない分、応答が速くなるという利点もあります。工場や船舶のようにネットワークが不安定な環境では、そもそもオフラインで動くことが必須要件になることもあります。
市場調査を見ても、金融機関や病院、行政機関を中心に、データの主権性やレイテンシ制御を理由にオンプレミス型のLLM運用を選ぶ動きが一定の割合で見られるようです。すべての企業がこの選択をするわけではありませんが、業界特性によっては、クラウドAPIを使わないという選択肢が現実的な検討対象になってきていると感じます。
6. クラウドLLMとのトレードオフ
とはいえ、ローカルLLMが万能というわけではありません。クラウドの最新モデルと比べると、ローカルで動かせるモデルの性能には現時点でまだ差があることが多いですし、GPUなどのインフラを自前で用意し、運用し続けるコストと手間も発生します。モデルのアップデートも自分たちで追いかけて入れ替える必要があります。
クラウドLLMは、その手間を丸ごと引き受けてくれる代わりに、データを外部に送ることになり、従量課金というコスト構造を受け入れることになります。どちらが優れているという話ではなく、何を優先するかで選ぶものが変わる、というシンプルなトレードオフなのだと思います。
7. 検討すべき場面、しなくていい場面
実務でRAGやローカルLLMを検討すべき場面を挙げるとすれば、社内文書やナレッジベースのように継続的に更新される情報を扱う場面、機密性の高いデータを外部に出せない場面、そしてレイテンシやコストがボトルネックになっている場面あたりが典型だと思います。
逆に、扱う情報量が少なく更新頻度も低い、あるいはプロトタイプの段階でまず動くものを作りたい、という場面では、RAGもローカルLLMも無理に導入する必要はないと感じています。以前の記事で扱った企業導入のつまずきの話とも重なりますが、技術的に可能だからといって、最初から作り込みすぎると、後で軌道修正するコストの方が大きくなることがあります。まずはシンプルな構成で動かしてみて、必要になったタイミングで検索の仕組みやローカル実行を足していく、という順序の方が結果的にうまくいくケースが多いように思います。
8. まとめ
RAGは、モデルの知識を増やす技術ではなく、必要な情報をその都度外部から取ってきて渡すという設計思想です。ファインチューニングや長いコンテキストウィンドウとは競合する技術というより、扱う情報の性質によって使い分けるものだと捉えると整理しやすくなります。ローカルLLMについても同様に、プライバシーやコスト、レイテンシ、オフライン要件といった具体的な制約があるかどうかで検討すべきかが決まる、という考え方が実務では役立つのではないかと思います。
「ホットワード5選」の番外編はこれで一区切りとなります。次回については、DDD(ドメイン駆動設計)まわりのクラスターに移ろうかと考えていますが、まだ確定ではなく、2〜4週間ほど様子を見てから決めようと思っています。
関連記事
- Context Engineeringとは何か？AIエージェントに「何を見せるか」を設計する
- AIエージェントにおけるMemory設計入門 — 何を覚え、何を忘れるか
- AIエージェントの実務導入で、企業はどこでつまずくのか
- Loop Engineeringとは何か？AIエージェントを「失敗から改善するシステム」に変える方法
- AIエージェントのTool Engineering入門