RAGとは何か — 院内マニュアル検索を例に
悠 Yu NiiboriAIエンジニア運営者について
院内のルールをAIに「覚えさせる」のではなく「探させる」のがRAGである。仕組みを院内マニュアル検索の例で説明し、導入で実際に詰まるのはモデルではなく資料の状態であることを、現場の実態から整理します。
「院内のルールをAIに覚えさせる」方式を選ぶと、マニュアルが改訂されるたびにやり直しが要ります。改訂が前提の文書では、そこが最初の分かれ道になります。
この記事でわかること
- RAGはモデルを作り変えず、質問のたびに手元の資料を検索して答えさせる仕組みである
- 改訂が前提の文書(院内規程・マニュアル・手順書)を扱うなら、ファインチューニングではなくRAGを選ぶ
- 導入で実際に詰まるのは精度ではなく、どれが正本かが決まっていないという文書管理の問題である
RAGとは
RAGとは、質問のたびに手元の資料を検索し、見つかった文章を根拠にしてAIに答えさせる仕組みです。
要点は、モデル自体を作り変えないことにあります。院内マニュアルが改訂されたら差し替えるのは資料のほうだけで済みます。「院内のルールを覚えさせる」のではなく「探させる」と言い換えると、運用の性質がはっきりします。
仕組みを分解する
RAGは、質問が来てから答えが返るまでに3つの段階を踏みます。
| 段階 | 何をしているか |
|---|---|
| 1. 検索 | 質問に意味の近い文章を、資料の中から取り出す |
| 2. 提示 | 取り出した文章を、質問と一緒にAIに渡す |
| 3. 生成 | 渡された文章だけを根拠に、AIが文章で答える |
段階1を支えるのがベクトル検索です。Cloudflare の公式ドキュメントは embeddings をこう定義しています。「テキスト、画像、音声などの値やオブジェクトの表現で、機械学習モデルと意味論的検索アルゴリズムによって処理されるよう設計されたもの」。そして Vectorize を、そのベクトルを保存して検索・類似性判定・分類などを自前のデータ上で構築できるグローバル分散のベクトルデータベースとして説明しています。
実務的な意味はひとつです。言い回しが違っても意味が近ければ拾えます。 「褥瘡」の手順書を「床ずれ」で探せる、という違いになります。キーワード一致の検索では取りこぼす部分がここで埋まります。
ベクトルに変換する処理そのものは、モデルを動かすサービス側で行います。Cloudflare の場合は Workers AI がその役割を担います。公式ドキュメントはこれを、サーバーレスGPU上でモデルを実行するサービスとして説明しています。Vectorize や Workers と組み合わせて開発プラットフォームを構成する、とも述べています。
ファインチューニングとの違い
導入検討で最も多い分岐がここです。
| RAG | ファインチューニング | |
|---|---|---|
| 変えるもの | 渡す資料 | モデルそのもの |
| 改訂への追随 | 資料を差し替えるだけ | 原則としてやり直し |
| 根拠の提示 | 引用元を示せる | 示せない |
| 向く用途 | 院内規程・マニュアル・手順書 | 文体や出力形式の癖づけ |
改訂のたびにやり直しが要る仕組みは、医療機関の文書運用と噛み合いません。 院内規程・マニュアル・手順書のように改訂が前提の文書を扱うなら、選ぶのはRAGです。
答えの根拠を検証可能にする
RAGを入れる目的は「AIが答えること」ではありません。答えの根拠を人が確かめられることです。 ここを設計に入れていない導入は、結局使われなくなる。
なお、本サイトを運営しているシステムでも同じ構成のベクトルインデックスを用意している(768次元・コサイン類似度)。この記事は仕組みの説明であって稼働中の院内検索の事例報告ではない、という区別だけ明示しておきます。
引用は「どこに書いてあったか」を返す
Anthropic の引用(Citations)機能は、この部分を仕組みとして扱っています。同社のドキュメントは、引用が各主張を裏付ける正確な箇所を返すため、回答を検証しユーザーにソースを提示できると説明しています。さらに、APIが引用を解析して該当箇所を直接抽出するため、引用には提供されたドキュメントへの有効なポインタが含まれることが保証されるとも述べています。
引用の粒度は「チャンク化」で決まる
もうひとつ、設計上の判断が要る点として「チャンク化」があります。同ドキュメントは、文書の内容がチャンク化されることで引用の最小粒度が決まると説明しています。プレーンテキストは文単位に分割され、複数の連続する文をつないで段落として引用することもできます。一方、箇条書きや書式が特殊な文書でより細かい粒度を制御したい場合は、分割を自動に任せずコンテンツブロックを自分で指定する方式が用意されています。
院内マニュアルは箇条書きと表が多く含まれます。 自動分割に任せると、条件と手順が別々のチャンクに割れて「条件だけが引用される」事故が起こり得ます。粒度をどう切るかは、資料の書式を見てから決める設計事項です。
実際に詰まるのは資料の状態
ここからが、導入検討で最も見落とされる部分です。
現場から見ると、院内マニュアルは「1つの正しい文書」であるとは限りません。同じ手順について、詰所に貼ってある紙・電子的に配布されている版・部署で運用されているローカルな決めごとが並存し、内容が食い違うことがあります。 どれが最新かは、担当者の記憶で補われています。
この状態のままRAGを入れると、何が起きるか。検索は正しく動きます。そして食い違ったまま両方を引いてきます。 精度の問題ではありません。資料が矛盾しているのだから、忠実な検索ほど矛盾を露わにします。
したがって導入の実務は、モデルの選定ではなく次の順で進みます。
- どの文書を正本とするかを決める(版と施行日を持つのはどれか)
- 正本になっていない紙・ローカル運用を洗い出し、廃止するか正本に統合する
- 正本の書式を、引用の粒度が割れない形に整える
- そのうえで検索と生成をつなぐ
1と2は情報システムの作業ではなく、文書管理の意思決定です。 ここを飛ばした導入は、精度不足として評価されて止まります。逆に言えば、1と2は導入するかどうかに関わらず価値が残る作業でもあります。
FAQ
Q. RAGを入れれば間違った回答はなくなりますか。 なくなりません。根拠となる箇所を示させ、人が確認できる状態にすることが目的です。
Q. 院内マニュアルをそのまま入れれば動きますか。 動きますが、正本が定まっていない状態では矛盾した回答が返ります。先に正本を決めてください。
Q. 患者情報は入れられますか。 本記事は院内規程・マニュアルなど診療情報を含まない文書を前提にしています。診療情報を扱う場合の可否は、施設の規程と各サービスの契約条件で判断してください。
Q. 小規模なクリニックでも意味がありますか。 文書の量より、担当者の記憶に依存している度合いで決まります。「あの人しか知らない」が多いほど効きます。
Q. どのくらいの資料量から効果が出ますか。 量よりも、探す頻度と探す人の多さです。同じ質問が繰り返し発生している文書から始めるのが確実です。
院内の文書を正本化するところから、検索して根拠つきで答えさせる仕組みの構築まで、設計のご相談を承っています。
出典
- Cloudflare Docs(公式ドキュメントのソース)— Vectorize(ベクトルデータベース / embeddings)(参照 2026-08-09)
- Anthropic — 引用(Citations)(参照 2026-08-09)
- Cloudflare Docs(公式ドキュメントのソース)— Workers AI(参照 2026-08-09)