医療とAIの、これまでとこれから。

RAGとは何か — 院内マニュアル検索を例に

院内のルールをAIに「覚えさせる」のではなく「探させる」のが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が答えること」ではない。答えの根拠を人が確かめられることである。 ここを設計に入れていない導入は、結局使われなくなる。

Anthropic の引用(Citations)機能は、この部分を仕組みとして扱っている。同社のドキュメントは、引用が各主張を裏付ける正確な箇所を返すため回答を検証しユーザーにソースを提示できると説明し、APIが引用を解析して該当箇所を直接抽出するため、引用には提供されたドキュメントへの有効なポインタが含まれることが保証されると述べている。

もうひとつ、設計上の判断が要る点として「チャンク化」がある。同ドキュメントは、文書の内容がチャンク化されることで引用の最小粒度が決まると説明している。プレーンテキストは文単位に分割され、複数の連続する文をつないで段落として引用することもできる。一方、箇条書きや書式が特殊な文書でより細かい粒度を制御したい場合は、分割を自動に任せずコンテンツブロックを自分で指定する方式が用意されている。

院内マニュアルは箇条書きと表が多い。 自動分割に任せると、条件と手順が別々のチャンクに割れて「条件だけが引用される」事故が起きうる。粒度をどう切るかは、資料の書式を見てから決める設計事項である。

なお、本サイトを運営しているシステムでも同じ構成のベクトルインデックスを用意している(768次元・コサイン類似度)。この記事は仕組みの説明であって稼働中の院内検索の事例報告ではない、という区別だけ明示しておく。

実際に詰まるのは資料の状態

ここからが、導入検討で最も見落とされる部分である。

筆者は前職が看護師である。現場から見ると、院内マニュアルは「1つの正しい文書」であるとは限らない。同じ手順について、詰所に貼ってある紙・電子的に配布されている版・部署で運用されているローカルな決めごとが並存し、内容が食い違うことがある。 どれが最新かは、担当者の記憶で補われる。

この状態のままRAGを入れると、何が起きるか。検索は正しく動く。そして食い違ったまま両方を引いてくる。 精度の問題ではない。資料が矛盾しているのだから、忠実な検索ほど矛盾を露わにする。

したがって導入の実務は、モデルの選定ではなく次の順で進む。

  1. どの文書を正本とするかを決める(版と施行日を持つのはどれか)
  2. 正本になっていない紙・ローカル運用を洗い出し、廃止するか正本に統合する
  3. 正本の書式を、引用の粒度が割れない形に整える
  4. そのうえで検索と生成をつなぐ

1と2は情報システムの作業ではなく、文書管理の意思決定である。 ここを飛ばした導入は、精度不足として評価されて止まる。逆に言えば、1と2は導入するかどうかに関わらず価値が残る作業でもある。

FAQ

Q. RAGを入れれば間違った回答はなくなりますか。 なくなりません。根拠となる箇所を示させ、人が確認できる状態にすることが目的です。

Q. 院内マニュアルをそのまま入れれば動きますか。 動きますが、正本が定まっていない状態では矛盾した回答が返ります。先に正本を決めてください。

Q. 患者情報は入れられますか。 本記事は院内規程・マニュアルなど診療情報を含まない文書を前提にしています。診療情報を扱う場合の可否は、施設の規程と各サービスの契約条件で判断してください。

Q. 小規模なクリニックでも意味がありますか。 文書の量より、担当者の記憶に依存している度合いで決まります。「あの人しか知らない」が多いほど効きます。

Q. どのくらいの資料量から効果が出ますか。 量よりも、探す頻度と探す人の多さです。同じ質問が繰り返し発生している文書から始めるのが確実です。


院内の文書を正本化するところから、検索して根拠つきで答えさせる仕組みの構築まで、設計のご相談を承っています。

出典

  1. Cloudflare Docs(公式ドキュメントのソース)— Vectorize(ベクトルデータベース / embeddings)(参照 2026-08-09)
  2. Anthropic — 引用(Citations)(参照 2026-08-09)
  3. Cloudflare Docs(公式ドキュメントのソース)— Workers AI(参照 2026-08-09)