AI・院内文書検索 / 公開 2026-07-17 / 更新 2026-07-17 / 約15分
病院の院内規程・マニュアル検索をAIで速くするには？RAGの仕組みと安全な始め方
必要な手順は院内にある。それでも、保存場所が分からない、検索語が合わない、最新版か判断できないため、結局は詳しい職員へ聞く。RAG型のマニュアルAI検索は、この「探す仕事」を軽くする方法の一つです。ただし、AIに文書を入れるだけでは安全にも正確にもなりません。根拠へ戻れる検索、版管理、権限、人の確認までを一つの業務として設計します。
マニュアルがあることと、必要なときに見つかることは別です
「停電時は、どこへ連絡するのか」「入職時のアカウント申請は、どの様式を使うのか」「この研修は誰が対象なのか」。答えは院内規程や手順書に書かれていても、保存先と文書名を知らなければ、探し始めることができません。
共有フォルダを何階層も開き、PDFを数本見比べ、それでも分からず担当者へ電話する。詳しい職員は同じ質問へ何度も答え、新しく入った職員は「誰に聞けばよいか」を覚えるところから始めます。検索で古い版が先に出れば、見つかったのに使えないこともあります。
RAGを使ったマニュアルAI検索は、職員が普段の言葉で質問すると、登録された院内文書から関連箇所を探し、回答候補と出典を示す仕組みです。目指すのは、AIだけで判断を終える状態ではありません。
質問する、関連箇所を見つける、根拠の原文を開く、必要なら責任者へ確認する。この一連の時間を短くするのが、院内マニュアル検索の役割です。
RAGは、承認済み文書を探してから回答を作る仕組みです
RAGはRetrieval-Augmented Generationの略で、日本語では検索拡張生成と呼ばれます。生成AIが内部に持つ知識だけで答えるのではなく、質問に関係する外部文書を検索し、その内容を材料に回答を作ります。
RAGの原著論文では、生成モデルが持つ知識と、外部の検索可能な記憶を組み合わせる考え方が示されました。院内マニュアル検索では、外部の記憶に当たるのが、病院が利用対象として承認した規程、手順書、FAQなどです。
一般的な処理は次の順番です。
- 院内文書から文字と文書情報を取り出す
- 長い文書を、検索に使える小さな単位へ分ける
- 分けた文章を検索できる形で登録する
- 職員の質問と意味が近い箇所を探す
- 見つけた箇所だけを材料としてLLMが回答候補を作る
- 文書名、版、ページなどの根拠を一緒に表示する
- 職員が原文を開き、必要な確認を行う
これは、院内文書を材料にAIを一から再学習することとは異なります。文書を差し替えて検索対象を更新しやすい一方、登録や削除の反映方法、古い版の除外、アクセス権の引き継ぎは別途設計が必要です。
Chunkとベクトル化が、検索の見つけやすさを左右します
RAGの画面では質問と回答しか見えませんが、裏側では文書の分け方と探し方が結果を大きく左右します。
Chunkは、長い文書を検索できる単位に分けたものです
数十ページある規程を一つの塊として登録すると、「どの条文が質問に答えているか」を細かく探しにくくなります。そこで、文書を章、節、段落などの単位へ分けます。この一つひとつがChunkです。
小さく分けすぎると、主語や条件、例外が前後へ切れて意味が欠けます。大きすぎると、関係のない文章まで検索結果へ混ざります。Microsoftの公式技術文書でも、固定長、可変長、重なりを持たせる方法などが説明されており、用途に合う調整が必要とされています。
院内文書では、文字数だけで機械的に切る前に、次の構造を残せるかを確認します。
- 規程名、章、条、別表の関係
- 「原則」と、その直後にある例外
- 申請手順と承認者
- 表の列名と各項目
- 改定日、施行日、文書番号
- 本文から参照される別紙や様式
ベクトル化は、文章の意味を検索へ使える数値に変える処理です
文書Chunkと質問を、埋め込みモデルによって数値の並びへ変換します。この数値表現を使うと、文字が完全に一致しなくても、意味が近い文章を候補にできます。
たとえば質問が「新しい職員のパソコンを用意したい」で、規程には「入職者端末の利用申請」と書かれている場合、単純な文字列検索では一致しないことがあります。ベクトル検索は、表現の違いを越えて近い箇所を探すために使われます。Microsoftが示すRAGの構成例でも、質問と文書Chunkをベクトル化し、類似する箇所を取得して生成モデルへ渡す流れが説明されています。
ただし、意味が近いことと、院内ルールとして正しいことは同じではありません。「端末申請」と「アカウント申請」を取り違える可能性もあります。そのため実装によっては、ベクトル検索だけでなく、文書名や用語による検索、部署・文書種別・有効期間による絞り込みを組み合わせます。
高性能なLLMを選ぶだけでは、正しい検索になりません
回答が不十分なとき、LLMを大きなモデルへ交換すれば直るとは限りません。検索段階で正しい箇所を取得できていなければ、回答を作る材料そのものが欠けているからです。
| つまずく場所 | 起きること | 先に確認すること |
|---|---|---|
| 文書 | 古い版や重複文書が候補になる | 正本、改定日、廃止状態 |
| 文字抽出 | スキャンPDFや表が崩れる | OCR結果、表、注記、別紙 |
| Chunk | 条件と例外が別々になる | 見出し構造、前後の重なり |
| 検索 | 院内略称で目的文書が出ない | 同義語、正式名称、キーワード |
| 絞り込み | 他部署だけの規程が混ざる | 部署、職種、権限、施行日 |
| 回答生成 | 根拠にない説明を補う | 回答指示、引用、回答保留 |
| 画面 | 回答だけ読まれて原文を見ない | 出典表示、原文への導線 |
精度評価も、「それらしい文章になったか」だけでは足りません。実際に院内で繰り返される質問を集め、正しい文書が上位に出るか、根拠ページが合っているか、答えるべきでない質問を保留できるかを分けて確認します。
病院では、患者別情報を使わない文書から始められます
最初から診療情報や電子カルテと接続しなくても、探す時間を減らせる候補はあります。
| 最初の候補にしやすい | 条件を確認して扱う | 別案件として設計する |
|---|---|---|
| 公開済み規程、施設案内 | 院内限定の運用手順 | 患者別の診療情報 |
| 総務・人事の申請手順 | 職員名を含む文書 | 診断・治療判断 |
| 研修、委員会の運営規程 | セキュリティ構成資料 | 電子カルテへの自動記録 |
| 情報システムの申請窓口 | 契約・取引先情報 | レセプトの自動確定 |
| 設備トラブルの連絡手順 | 医療安全・感染対策手順 | 患者ごとの対応指示 |
「患者情報を使わない」は出発点です。職員情報、取引先情報、認証情報、院内限定情報にも管理が必要です。情報の分け方は、患者情報を使わずに始める、病院事務のAI・自動化でも詳しく説明しています。
国内では、東京北部病院の発表として「RAGモデルを用いた医療業務マニュアルAIチャット」の検討例があります。これは一施設の研究報告であり、すべての病院で同じ結果になることを示すものではありませんが、院内マニュアルへのアクセス改善が実際の検討対象になっていることは分かります。
安全性は、サーバーの置き場所だけでは決まりません
「クラウドを使わず、院内だけで動かせば安全」とは言い切れません。外部送信を減らせても、端末、アカウント、閲覧権限、ログ、更新、バックアップ、持ち出し、障害対応の管理は残ります。反対に、クラウドという理由だけで一律に可否を決めるのではなく、扱う情報、契約、保存、送信先、役割分担を確認します。
厚生労働省の医療情報システム安全管理ガイドライン第7.0版は、経営管理、企画管理、システム運用、委託先との役割分担を含む資料で構成されています。患者や職員に関する個人情報を扱う場合は、個人情報保護委員会・厚生労働省の医療・介護ガイダンスも含め、案件の範囲に応じて確認します。
少なくとも、次の境界を導入前に決めます。
- AI・検索が行うこと: 文書候補の検索、該当箇所の提示、回答候補の作成
- 人が行うこと: 原文確認、例外判断、院内ルールの解釈、最終案内
- 責任者が行うこと: 対象文書の承認、版の更新、権限付与、利用停止の判断
- 対象外にすること: 診断、治療方針、患者別の判断、根拠がない回答の確定
回答画面には、文書名だけでなく、版、改定日、該当ページ、原文を開くリンクを表示します。権限のない文書は検索候補にも回答材料にも入れません。見つからない場合や文書同士が矛盾する場合は、無理に一つの答えへまとめず、担当部署へ戻します。
小さなPilotでは、検索画面より先に正解を用意します
いきなり全院の共有フォルダを取り込むと、重複、旧版、個人情報、権限の整理が一度に必要になります。最初は一部署・一種類の文書へ絞ります。
1. 探す時間が発生している質問を集める
「どこへ申請するか」「どの様式か」「誰の承認が必要か」など、実際に繰り返されている質問を集めます。質問ごとに、正しい文書と該当箇所を人が確認しておきます。
2. 利用する文書と対象外を決める
正本、版、改定日、所有部署、閲覧できる職種を一覧にします。廃止文書、下書き、個人情報を含む資料は混ぜず、判断できないものはいったん外します。
3. 文字抽出とChunkを確認する
PDFやWordから本文、見出し、表、ページを取り出し、条件と例外が切れていないかを確認します。スキャン文書はOCR後の誤字も見ます。
4. 検索と回答を別々に評価する
正しいChunkが見つからないのか、見つかった後の要約が誤っているのかを分けます。原因を分けなければ、どこを直すべきか判断できません。
5. 現場で原文確認まで試す
普段の質問を入力し、回答を読むだけでなく、根拠文書を開いて確認します。質問の言い換え、略称、例外、複数文書にまたがる質問も含めます。
6. 続ける条件と止める条件を決める
検索時間、担当者への問い合わせ、正しい根拠を提示できた割合、回答を保留できたか、文書更新の負担を確認します。誤案内の影響が大きい、更新責任を持てない、権限を再現できない場合は対象を狭めるか、導入を止めます。
効果は、AIへの質問回数ではなく仕事の変化で測ります
利用回数が多くても、回答を毎回直し、結局担当者へ聞いているなら仕事は軽くなっていません。改善前後で、同じ種類の質問を使って比べます。
| 測る項目 | 確認すること |
|---|---|
| 探索時間 | 質問してから根拠文書を開くまで何分か |
| 問い合わせ | 詳しい職員や担当部署へ聞く件数が変わったか |
| 取得精度 | 正しい文書と該当箇所が候補に入ったか |
| 根拠確認 | 回答から原文へ移動し、確認できたか |
| 回答保留 | 根拠がない質問に無理に答えなかったか |
| 更新負担 | 改定、廃止、権限変更を継続して反映できるか |
短縮時間だけでなく、古い版の参照、問い合わせの集中、新入職員の迷い、文書管理の負担も見ます。検索しやすくなっても、古い文書が放置されていれば、問題を速く再現するだけになりかねません。
RAGは、文書管理を代わりに完成させてくれるものではありません
院内マニュアル検索を作ると、「正本がどれか」「誰が更新するか」「同じ手順が複数に書かれていないか」という既存の問題が見えてきます。RAGはその問題を隠すのではなく、整理が必要な場所を表面化させます。
Eighgentでは、ローカルLLMやRAGを使った社内マニュアル検索を検証プロジェクトとして試作しています。これは病院への導入実績ではなくLAB段階ですが、病院の院内SEとして約10年、電子カルテの運用、データ連携、院内業務アプリの開発に関わった経験を基に、検索画面だけでなく権限、更新、障害時の戻り方まで含めて考えます。
導入方法を決める前に、小さな業務診断で、現在どの文書を、誰が、どのように探しているかを整理すると、RAGを使うべきか、文書整理や既存検索の改善で足りるかを分けられます。
よくある質問
ChatGPTへPDFをアップロードするだけでは駄目ですか
少量の公開資料を一時的に読む用途なら役立つ場合があります。ただし院内運用では、誰が使えるか、入力内容がどこへ送られるか、保存や学習利用はどうなるか、最新版だけを参照できるか、ログを残せるかを確認します。個人の判断で院内文書を外部サービスへ入力しません。
スキャンした紙のマニュアルも検索できますか
OCRで文字を取り出せば候補になりますが、かすれ、縦書き、表、手書き、ページ順で誤認識が起きます。登録前に文字抽出結果を確認し、重要な表や注記は原本への導線を残します。
SharePointやGoogle Driveの文書を使えますか
利用する製品や構成によって連携方法は異なります。接続できるかだけでなく、元のフォルダや文書の閲覧権限を検索結果へ反映できるか、更新と削除がいつ反映されるかを確認します。
ベクトル化すると元の文章へ戻せなくなりますか
検索用の数値表現だけで運用するのではなく、元文書、Chunk、文書名、版、ページを対応づけて管理します。回答から原文へ戻れることが重要です。ベクトルデータ自体の取扱いも、元文書の機密性に応じて管理します。
出典が表示されれば、回答は正しいですか
いいえ。関係の薄い箇所を取得したり、正しい出典から誤った要約を作ったりする可能性があります。出典の表示は確認を助けますが、正しさの保証ではありません。重要な手続きや例外は原文と責任者の確認を残します。
患者情報を含むマニュアルも登録できますか
文書内に患者を識別できる情報や事例が含まれる場合は、利用目的、必要性、閲覧権限、委託・契約、保存、ログなどを個別に確認します。最初のPilotでは、患者別情報を含まない文書から始める方が影響を限定できます。
最初の相談では、院内文書そのものを送る必要はありません
「どの部署で」「どんな質問が繰り返され」「今はどこを探し」「最後に誰が確認しているか」が分かれば、文書整理、既存検索の改善、RAG試作のどれが合うかを切り分けられます。
契約前に機密文書や患者情報を送る必要はありません。文書名を伏せた一覧と、探し方の流れだけでも構いません。相談から診断、Pilotまでの進め方に沿って、一部署・一種類の文書から確認します。