この1年間、私が話をした倉庫オペレーターのほぼ全員が、同じ質問をしてきました。SOPや設備マニュアル、過去の作業指示を社内のナレッジベースにまとめ、Q&Aボットを作りたい——RAGを使うべきか、それとも大規模言語モデルをファインチューニングすべきか？一見すると技術の選択に見えますが、その下には3つの帳簿があります。知識がどれだけ速く変わるのか、誤った回答のコスト、そしてチームが実際に維持できるのはどちらの方式か、です。
まず全体像から見ましょう。公開されている業界レポートやベンダーの事例研究をもとに私が確認したところ、2024年から2026年の間に実際に本番稼働した企業のナレッジベースQ&Aプロジェクトのなかで、RAG（検索拡張生成）は事実上の主流アーキテクチャになっています。この手法は2020年にMetaが発表し（Lewisら）、核心となるアイデアはシンプルです。知識をモデルのパラメータに詰め込むのではなく、まず関連文書を検索し、検索した内容に基づいて回答を生成するのです。ファインチューニングは逆の道を行きます。自社のQ&Aデータでモデルを追加学習し、知識をパラメータに「プレス」するのです。どちらの道も機能しますが、コスト構造、リスクプロファイル、適用範囲はまったく異なります——そして選択を誤った代償は、ローンチから約6か月後に現れます。
倉庫におけるRAGの実際：トレーサビリティこそ命
2025年の初め、カリフォルニア州インランド・エンパイアの3PL倉庫が自社のプロジェクトを見せてくれました。その施設は約120,000平方フィートで、40を超えるECブランドに対応し、WMSには数万件の過去の作業指示と例外記録が蓄積され、さらに数百ページのSOPがありました。彼らの方式は教科書通りのRAGでした。文書をチャンクに分割してベクトル化し、質問時には最も関連性の高い5–8パッセージを検索して、LLMがそれらのパッセージから回答を組み立てる——回答にはすべて出典が付き、SOPのセクションや特定の作業指示番号まで辿れるのです。
この「出典付き」設計がすべてです。倉庫はコンプライアンスと監査が厳しい環境です。品質検査員が「この入荷ロットのサンプリング比率は？」と聞くとき、求めているのはきれいな回答ではありません——記録に残せて、何か起きたときに遡って追跡できる回答です。RAGの回答は構造上、出自を伴います。間違いがあれば、どの文書が古くなったかを特定し、モデルではなく文書を直せばいいのです。ローンチから6か月後、この3PLの新人オンボーディング期間は約3週間から約10日に短縮されました。念のため：これは彼らの社内業務指標であり、研修プロセス自体も並行して最適化されたので、功績のすべてがRAGにあるわけではありません——でも方向性は明確です。知識が「見つけられて」「検証できる」ものになったのです。
RAGには倉庫の現場でとてつもなく重要になるもう1つの利点があります。知識の更新が「文書の差し替え」で済み、「再学習」がいらないことです。SOPが改訂されたら、チャンクを再分割して再インデックスすれば数分で反映されます。知識が絶えず変わる倉庫にとって、これはほぼ決定的です。
ファインチューニングの失敗事例：仕様を覚え、出典を失った
ファインチューニングにも採用者はいます——そして実際の失敗事例も。2025年半ば、中国東部の物流センターが設備メンテナンスマニュアルをモデルに「教え込もう」とし、数千組のQ&Aペアを集めてファインチューニングしました。テスト中、あるスタッカークレーンの定格荷重を聞いたところ、モデルは自信満々に答えました——そして数字は間違っていました。実際の定格は1.5トン、答えは2トンでした。事後検証で、旧版のマニュアルが学習データに混ざっており、モデルがその誤りを「覚えて」しまい、間違っているという自覚がなかったことがわかりました。
これがナレッジベースにおけるファインチューニングの構造的欠陥です。知識が一度パラメータに圧縮されると、追跡も部分修正もできません。誤りを見つけても、RAGのように文書を編集すれば済むわけではなく、データの再準備、再学習、再検証をすべてやり直す必要があります。さらに悪いことに、ファインチューニングされたモデルは、誤った回答も正しい回答とまったく同じ自信で述べます。倉庫では、誤った回答が人を傷つけ、貨物を壊し、コンプライアンスを損なうこともあります。この「説明不能な自信」こそ、最も危険な性質です。
公平に言えば、ファインチューニングにも正当な居場所はあります——ただ、事実の暗記ではありません。得意なのはモデルの振る舞いを変えることです。出力フォーマットの固定、トーンの統一、特定の推論パターンの学習などです。ニーズが「モデルに自社のサービスマニュアルのように話させたい」なら、ファインチューニングは良い選択です。ニーズが「モデルに3,000ページのマニュアルを覚えさせたい」なら、道具の使い方が間違っています。
RAG vs ファインチューニング：意思決定マトリクス
まとめとして、私が使っている意思決定マトリクスを紹介します。自社の状況をこの4つの次元に当てはめれば、答えは自然と見えてきます。
| 次元 | RAG寄り | ファインチューニング寄り |
|---|---|---|
| 知識の更新頻度 | 高い——週単位、時には日単位の変更（SOP、販促ルール） | 低い——知識が何年も安定（設備の原理、規制） |
| 正確性とトレーサビリティの必要性 | 高い——誤回答のコストが大きく、出典の引用が必須（品質、安全） | 中～低——事実の精度よりスタイルが重要 |
| データ量 | 文書は多いがQ&Aペアは少ない（RAGは文書を直接食べる） | 数万組の高品質Q&Aペアが学習用に利用可能 |
| コストとチーム | 軽い立ち上げ、検索ごとの課金、メンテナンスは文書の差し替えだけ | 初回＋繰り返しの再学習のGPUコストとバージョン管理のオーバーヘッド |
コストの次元は単独で計算する価値があります。パブリッククラウドの料金を参考にすると、7Bクラスのオープンモデルのフルファインチューニング1回は通常、GPUレンタルで数百～数千ドルかかります（最新の料金は各クラウドベンダーの公式サイトで確認してください）——ただし、それは1回の学習実行分だけです。本当のコストはその後に来ます。知識の更新サイクルごとに、理論上は新しいモデルバージョンの再学習、再テスト、再デプロイが必要になり、これは毎年の経常支出になります。RAGのコストカーブは逆です。検索パイプラインの構築には初期のエンジニアリング工数がかかりますが、日々の運用は「文書の差し替え」だけで、限界コストは非常に低いのです。一方は前倒し、もう一方は後倒し——比べるべきは初月の請求書ではなく、3年間の合計です。
直感に反する見解：速く変わる倉庫では、ファインチューニングは減価する資産
直感に反する判断を、はっきり述べておく価値があります。知識が頻繁に更新される倉庫にとって、ファインチューニングは「一度きりの投資」ではありません——減価する資産です。SOPの改訂や設備の変更があるたびに、前回のファインチューニング済みモデルの「記憶」の一部が陳腐化し、どの部分かが分かりません。その結果、再学習–再テスト–再デプロイのループを強制され、動く標的をモデルが永遠に追いかけながら、支出は増える一方です。RAGはまさにこのシナリオで逆の動きをします。知識が新しく、断片化し、散在しているほど、検索アーキテクチャの優位性は大きくなります。
では、トレンドの私の見立てはこうです。今後2～3年、倉庫ナレッジベースのデフォルトはハイブリッドになる——what（事実、トレーサビリティ、リアルタイム更新）にはRAG、how（フォーマット、トーン、業界の言い回し）には軽いファインチューニングです。両者は二者択一ではありません。分業なのです。
ただ、1つの問いはもっと長く観察する価値があります。どちらの道を選んでも、ナレッジベース自体の品質が天井です。曖昧なSOP、欠落フィールドのある作業指示記録、改訂が絡み合った設備マニュアル——どんなRAGパイプラインもファインチューニングの実行も、「知識ガバナンス」の問題は直せません。アーキテクチャ論争の裏側で、本当の分岐点はこれかもしれません。自社の倉庫は、AIに学ばせる価値のある知識を実際に持っているのか？これはナレッジベースを作るすべての企業が自ら答えなければならない問いです。
Dr. Chen（サプライチェーン研究者）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
