言葉が数字になるまでで、意味がベクトル（数字の並び）になる仕組みを見ました。この記事はその応用です。
やりたいことは、はっきりしています。
自分の分野の資料を大量に読ませて、そこに詳しいエージェントを作りたい。
社内規程に詳しいエージェント。自分が10年書きためた原稿を分かっているエージェント。取扱説明書を全部知っている問い合わせ対応。——どれも同じ形の願いです。
結論を先に言うと、これはモデルを訓練し直す話ではありません。 そしてそれは、非エンジニアにとって朗報です。
なぜ、そのままでは無理なのか
基本編に書いたとおり、LLMは訓練した後のことを知りません。そして当然ながら、あなたの会社の就業規程も、あなたのハードディスクの中身も知りません。
インターネットに公開されていない情報は、モデルの中には含まれていない。ここが出発点です。
手その1：全部そのまま貼る
いちばん単純な方法から行きましょう。資料を丸ごと指示の文面に貼り付ける。 それだけです。
ばかにできません。資料が数十ページ程度なら、これがいちばん確実で、いちばん速い。 検索の精度で悩む必要がなく、モデルは全文を見た上で答えます。
限界も明快です。
- 渡せる量に上限がある。 1万ページは収まりません
- 収まっても、高くて遅い。 毎回すべてを読み直すので、そのぶんトークンを消費します（→トークン節約のためのモデル選び）
まずこれを試して、足りなくなってから次を考える。 順番としてはこれが正解です。
手その2：追加学習させる（たいてい、これではない）
「専門特化」と聞いて多くの人が想像するのは、こちらでしょう。モデル自体を自分のデータで訓練し直す（ファインチューニング）。
ただ、目的が「知識を覚えさせること」なら、これはたいてい正解ではありません。
- 手間とコストがかかる。 個人が気軽にやる規模ではありません
- 資料を更新するたび、やり直し。 就業規程が改定されるたびに再訓練、というのは現実的ではない
- 根拠を示せない。 覚え込ませた知識は、どの資料の何ページから来たのか説明できません
- そもそも事実の記憶には向いていない。 追加学習が得意なのは、口調・出力形式・振る舞いを教えることであって、事実を正確に覚えさせることは不得意です
追加学習は「話し方」を教える道具であって、「知識」を足す道具ではない。 ここは押さえておくと、無駄な遠回りをせずに済みます。
手その3：必要なところだけ探して渡す（RAG）
実務でいちばん使われているのが、これです。RAG（Retrieval-Augmented Generation、検索で補強した生成）と呼ばれます。2020年の論文Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（Lewisら）が名前の由来です。
発想はきわめて素直です。
全部渡せないなら、質問に関係あるところだけ探して渡せばいい。
流れはこうなります。
- 資料を、ほどよい大きさに切り分ける（チャンクと呼びます）
- 切った断片を1つずつベクトルに変換して、保存しておく（ベクトルデータベース）
- 質問が来たら、質問のほうもベクトルに変換する
- ベクトルが近い断片を探す
- 見つかった断片を、質問と一緒にLLMへ渡す
- LLMはそれを読んで答える
2と3と4が、ベクトル化のいちばん実用的な出番です。 『言葉が数字になるまで』で見た「意味の近さを座標の近さで測れる」という性質が、そのまま検索エンジンになっています。
なぜ、キーワード検索ではだめなのか
ここが、ベクトルを使う理由の核心です。例で見るのが早いでしょう。
社員がこう聞きます。
「有給って何日もらえるの？」
一方、就業規程にはこう書いてあります。
「年次有給休暇の付与日数は、勤続年数に応じて…」
キーワード検索は、これを見つけられないことがあります。 「何日もらえる」と「付与日数」は、文字として一致しないからです。
ベクトル検索なら見つかります。「もらえる日数」と「付与日数」は、似た文脈で使われる言葉なので、ベクトルが近い。 文字が違っても、意味が近ければ拾える。これが決定的な差です。
同じ理屈で、日本語で質問して英語の資料を引っ張ってくることもできます。『言葉が数字になるまで』で見たとおり、ベクトルは言語をまたいで似た場所に集まるからです。
ただし、キーワード検索が勝つ場面もある
正直に書いておきます。ベクトル検索は万能ではありません。
- 型番「XR-7200B」を探したい
- 「第32条」をピンポイントで見たい
- 人名や固有名詞を、完全一致で拾いたい
こういう一字一句が命の検索は、昔ながらのキーワード検索のほうが確実です。実務では両方を併用するのが定番で、ハイブリッド検索と呼ばれます。さらに、拾ってきた候補を関連度で並べ直すリランカーという道具を挟むのも一般的です。
新しい方式が古い方式を置き換えたのではなく、得意分野が違うので併用する。 ここは誤解されやすいところです。
RAGの、いちばん大きな利点
速度でも精度でもありません。出典を示せることです。
追加学習で覚え込ませた知識は「なんとなくそう思う」しか言えません。RAGなら、「就業規程 第32条にこう書かれています」と、根拠の文書ごと提示できます。
これは実務では決定的です。LLMはもっともらしいが事実でない内容を、自信たっぷりに返してくることがあり（→ハルシネーション）、説明が上手いことと正しいことは別です。だからこそ、人間が確かめに行ける形になっているかどうかが決め手になります。
このサイトが記事中で「公式にこう書いてある」と述べるたびに必ずそのURLを貼っているのも、同じ発想です。確かめられない根拠は、根拠として弱い。
うまくいかないときは、たいてい「探す」段階
RAGを組んで期待外れだったとき、原因はだいたい決まっています。
| 症状 | 起きていること |
|---|---|
| 見当違いの答えが返る | そもそも正しい断片を見つけられていない |
| 途中で切れた変な引用をする | 資料の切り方が悪い（文の途中で切れた、表が壊れた） |
| 資料にあるのに「情報がありません」と言う | 同上。探せなければ、答えようがない |
| 見つけているのに答えを間違える | ここで初めてモデル側の問題 |
大半は「探す」段階の問題で、モデルの賢さの問題ではありません。 賢いモデルに変えても直らない、というのはよくある落とし穴です。
なお、分野に特化した埋め込みモデルも実際に提供されています。AnthropicのEmbeddingsドキュメントでは、法務向け・金融向け・コード向けといった専用モデルが紹介されています（あわせて、Anthropicは自社の埋め込みモデルを提供しておらず、外部の提供者を案内している、という点も明記されています）。「専門特化」は、ベクトルを作る段階から始められるわけです。
そして今：検索も「道具」の一つになった
ここまでは、少し前の話です。エージェントの時代になって、風景が変わりました。
従来のRAGは、手順が固定でした。質問が来たら必ず検索し、必ず結果を渡し、必ず答えさせる。1回勝負です。
エージェントなら違います。応用編で見たとおり、モデルは「道具を呼ぶ指示」を出力できます。 検索も、その道具の一つにしてしまえばいい。
すると、こんな動きができるようになります。
- 検索してみて、足りなければもう一度、言葉を変えて検索する
- そもそも検索が要らない質問なら、検索しない
- 検索ではなく、ファイルを直接開いて読む
- 見つけた資料から別の資料をたどる
手順を固定した仕組みから、その場で判断させる仕組みへ。 人間の調べものに近づいた、と言えます。
実際、エージェントに「このフォルダの資料を読んで答えて」と頼むだけで、grepやlsを駆使して自力で調べ始めます。ベクトルデータベースを用意するまでもなく、それで足りる場面はかなり多いというのが実感に近いはずです。
MCP：道具をつなぐ、共通の作法
最後にMCPです。専門特化の話は、ここに行き着きます。
問題はこうでした。エージェントに道具を持たせたい。でもエージェントごとに繋ぎ方がバラバラだと、道具を作る側は全部に個別対応しないといけません。 道具10種類 × エージェント5種類で、50通りの対応が要る。これでは広がりません。
そこで作られたのがMCP（Model Context Protocol）です。公式ドキュメントにはこう書かれています。
“MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.”
（MCPとは、AIアプリケーションを外部のシステムに接続するためのオープンソースの標準規格である）
そして、いい比喩が同じ公式ドキュメントに用意されています。
“Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.”
（MCPは、AIアプリケーションにとってのUSB-Cポートのようなものだと考えてほしい。USB-Cが電子機器をつなぐ標準的な方法を提供するように、MCPはAIアプリケーションを外部システムにつなぐ標準的な方法を提供する）
USB-Cの比喩は、よくできています。充電器を1つ持っていれば、どのメーカーの機器にも挿せる。 同じように、MCPサーバーを1つ作れば、対応している複数のエージェントから使える。
公式には、接続先の例としてローカルのファイル、データベース、検索エンジン、電卓、専用の作業手順などが挙げられています。MCPだけを掘り下げた記事にMCPとは何かを書いたので、繋ぎ方やセキュリティの注意点はそちらを参照してください。
つまり「専門特化のエージェント」とは
ここまでを繋ぐと、答えが出ます。
専門特化のエージェントを作るとは、多くの場合、モデルを訓練し直すことではありません。
- その分野の資料を用意して、
- 必要なところを取り出せるようにして、
- 道具として繋ぐ
これだけです。頭脳は汎用のまま、持たせる資料と道具で専門家に仕立てる。 医者に専門書と検査機器を渡すのに近い発想です。
そして、これが非エンジニアにとって朗報である理由がここにあります。モデルを訓練するのは無理でも、資料を整えることはできる。 そして——整えた資料を繋ぐ作業そのものを、エージェントに手伝ってもらえます。
現実的な始め方
最後に、順番の話をしておきます。いきなりベクトルデータベースを組まないでください。
- 資料をフォルダに置いて、エージェントに読ませる。 まずこれ。驚くほど、これで足ります
- 量が増えて追いつかなくなったら、資料の整理と切り分けを考える。ファイル名と見出しを整えるだけで、かなり改善します
- それでも足りなくなったら、ベクトル検索を検討する
- 繰り返し使う仕組みになってきたら、MCPサーバーとして固める
このサイトが一貫して言っていることと同じです。必要になってから、次の段に進む。 最初から立派な仕組みを組もうとすると、たいてい完成する前に力尽きます。
まとめ
- 自分の資料に詳しくさせたいなら、まずは全部貼る。数十ページならこれが最速で最確
- 追加学習は「話し方」を教える道具であって、知識を足す道具ではない
- 量が増えたらRAG——資料を切ってベクトル化し、質問に近い断片だけを探して渡す
- ベクトル検索は「有給の日数」と「年次有給休暇の付与日数」を同じ意味だと分かる。ただし型番や条番号はキーワード検索のほうが確実なので併用する
- RAGのいちばんの利点は速度ではなく、出典を示せること
- うまくいかない原因は、たいてい「探す」段階。モデルを賢くしても直らない
- エージェントの時代には、検索も道具の一つ。手順を固定せず、その場で判断させられる
- MCPは道具をつなぐ共通規格。公式いわく「AIアプリケーションにとってのUSB-C」
- 専門特化とは、頭脳を作り替えることではなく、資料と道具を用意して繋ぐこと