社内の規程やマニュアル、過去の報告書には業務の答えが書かれていても、必要な箇所を探し出すのに時間がかかり、業務に詳しい担当者に問い合わせが集中することがあります。こうした文書をもとに、質問に回答するAIの仕組みは、RAG（Retrieval-Augmented Generation、検索拡張生成）と呼ばれます。質問を受けるたびに社内文書から関連する箇所を探し、その箇所を根拠として生成AIが回答を作成します。

ただし、RAGは文書を取り込むだけでは、業務で利用できる水準になりません。どの文書を対象とするか、誰にどの文書の閲覧を認めるか、回答の正しさをどのように評価するかを、構築にあたって定める必要があります。

RAGの導入に適する業務と適さない業務

RAGは、回答の根拠が社内文書にあり、文書の量が多く、該当箇所を探すのに時間がかかる業務で有効です。たとえば、規程や手続の問い合わせに担当部署が同じ回答を繰り返している場合や、過去の報告書や案件資料から似た事例を探す場合です。

一方で、よくある質問が数十件程度に収まる場合は、FAQのページや決まった回答を返すボットで足りることがあります。担当者の経験に基づく判断のように、答えが文書に記載されていない場合は、先に文書化が必要です。また、申請の進捗のように答えが社内システムのデータにある質問には、文書の検索ではなく、システムへの照会で回答する仕組みが適しています。

システムの構成

RAGは、文書の置き場、文書の読み取り（PDFやスキャン画像から文字と表を取り出す）、検索、回答の生成、利用者の窓口の5つの要素で構成されます。

以下では、Microsoft Azure の Azure AI Search を使って構築する場合を例に、検索と閲覧範囲の設計を説明します。Google Cloud の Agent Search（旧称 Vertex AI Search）などでも同様の構成を実現でき、クラウドを使わずに社内のサーバーで構築することもできます。構築する環境は、社内ですでに利用しているシステムと文書の置き場所、取り扱う情報の性質を踏まえて決定します。製品名と機能の提供状況は2026年10月時点のものです。

検索の設計

経験上、RAGの回答の精度は、検索で正しい箇所を取得できるかによって大きく左右されます。検索の設計では、主に次の手法を、文書と質問の性質に応じて組み合わせます。

  • ハイブリッド検索ベクトル検索だけでは、規程の条番号や製品の型番のような固有の語句を検索できないことがあるため、言葉の意味の近さで探すベクトル検索と、語句の一致で探すキーワード検索を同時に行い、結果を統合します。
  • 検索結果の並べ直し（リランキング）検索で得られた候補を、質問との関連の強さで並べ直します。Azure AI Search ではセマンティックランカーという機能です。
  • 文書の分割（チャンキング）規程は条単位、マニュアルは見出し単位というように、文書の種類ごとに分割の方法を変えます。表は行の途中で分割しないようにします。

社内規程は、分割の仕方に特に注意が必要な文書です。たとえば職務権限規程では、決裁権限の基準が条文から切り離され、別表に定められていることがよくあります。また、ある規程が別の規程の条文を参照していることも少なくありません。これらを一定の文字数で機械的に分割すると、条文と別表、規程どうしの対応が失われ、検索で正しい箇所を取得できなくなります。そのため当社では、規程の体系を先に一覧にし、各文書の位置づけを確認したうえで分割の単位を決定します。

Azure AI Search では、文書の取り込みの処理（インデクサー）に、分割とベクトル化を組み込めます（統合ベクトル化）。表やスキャン画像が多い文書は、先に Document Intelligence のレイアウト解析で処理します。なお、Microsoft Foundry の「Foundry IQ」は、Azure AI Search を基盤にした機能です。

質問を複数の検索に分解して結果をまとめる「エージェント検索（agentic retrieval）」は、2026年4月の API で、分解を伴わない検索の機能が一般提供になりました。生成AIで質問を分解する機能は、2026年10月時点でもプレビューです。複数の条件を含む質問への回答の精度が高まる一方で、応答に時間がかかり、モデルの利用料も増えます。通常の検索で十分かを評価の結果に基づいて確認してから、採用を判断します。

閲覧範囲の制御

閲覧を一部の部署に限る文書を登録する場合、回答を生成した後で隠すのでは回答の文中に情報が漏れるため、検索の段階で、質問した人が閲覧できる文書だけに絞り込む必要があります。

Azure AI Search で絞り込む代表的な方法は、次の2つです。

  • セキュリティフィルター文書ごとに閲覧できるグループのIDを索引に持たせ、検索のたびに、質問した人が属するグループで絞り込みます。一般提供の機能で、構成も単純です。文書の権限が変わったときは索引に反映し、利用者の所属は検索のたびに認証の情報から取得します。これらの処理は当社が構築します。
  • Entra ID の権限を使う絞り込み元の文書の置き場に付いている権限を索引に取り込み、利用者のトークンで自動的に絞り込む機能です。取り込める権限の単位は置き場によって異なり、Data Lake Storage Gen2 ではファイル単位、Blob Storage ではコンテナー単位、SharePoint では文書ごとの権限です。2026年10月時点ではプレビューで、本番での利用は推奨されていません。

また、チャットツールの共有チャンネルにそのまま投稿すると、閲覧権限のない参加者にも回答が見えるため、絞り込んだ結果をもとにした回答は、質問した本人だけが見られる場所に返します。

さらに、文書に生成AIへの指示を埋め込み、その文書を検索したAIの動作を操作する攻撃があります（間接的なプロンプトインジェクション）。社外から受け取った文書や、多くの従業員が編集できる文書を検索の対象に含める場合は、文書を回答の根拠となる情報としてのみ扱い、その中の文章によってAIの動作が変わるリスクを下げる対策を講じます。

利用者の窓口

従業員が質問する窓口は、日常の業務で使っているツールに合わせて選定します。Teams や Slack のようなチャットツール、社内ポータルのウェブ画面、既存の業務システムの画面への組込みが主な選択肢です。Azure で構築する場合は、例として、Microsoft 365 Agents SDK で作成したボットを Azure AI Bot Service に登録し、Teams・Slack・ウェブ画面のそれぞれに接続できます。窓口がどこでも、次の3点は共通して実装します。

  • 利用者の識別社内のシングルサインオンなどで利用者を認証し、その情報をもとに検索時の閲覧権限を判定します。チャットツール上の利用者のIDと、権限の判定に使うID（Microsoft 365 なら Entra ID）が異なる場合は、両者を対応づける処理も実装します。この対応づけがなければ、上記の閲覧範囲の絞り込みを行えません。
  • 根拠の表示利用者が回答を確認できるよう、回答の根拠となった文書の名前と該当箇所を、元の文書へのリンク付きで示します。リンク先でも、元の文書の閲覧権限がそのまま適用されるようにします。
  • 評価の受け付け回答ごとに「役に立った／立たなかった」を押せるようにします。運用後の改善の材料になります。

進め方

1. 対象業務と質問の洗い出し

最初に、想定される質問を、質問する人や業務の場面とあわせて具体的に集めます。実際に寄せられた問い合わせの記録があれば、それを材料にします。ここで集めた質問が、後の工程で精度を評価する基準になります。

2. 文書の棚卸しと構成の決定

対象の文書を、置き場所・形式・更新の頻度・閲覧できる範囲・管理の責任者の5つの項目で一覧にします。この段階では、多くの場合、次のような文書が見つかります。

  • 同じ規程の新旧の版が並んでいて、どれが現行か分からない
  • スキャンしたPDFや図表が多く、そのままでは文字として読み取れない
  • 閲覧を一部の役職や部署に限る情報が混ざっている

これらを、登録する文書・修正してから登録する文書・登録しない文書に分類します。回答の質は、この仕分けで大きく左右されます。あわせて、文書の置き場所、取り扱う情報の性質、社内ですでに利用しているシステムを踏まえて、構築する環境と、従業員が質問する窓口を決定します。

3. 評価用の質問と正解の作成

工程1で集めた質問のうち代表的なものについて、正しい回答と、その根拠となる文書の箇所を、業務の担当者の方に確認していただきます。あわせて、文書に根拠がない質問や、質問した人が見られない文書にしか答えがない質問も用意し、回答を控えられるかも評価します。こうして用意した質問と正解が、精度を評価する基準になります。基準がなければ、システムが実務での利用に耐えるかを判断できません。

4. 試作と精度の測定

小さな範囲の文書で試作し、評価用の質問に回答させて精度を評価します。評価の対象は、正しい根拠を検索できた割合、回答が根拠と整合している割合、根拠のない質問に回答を控えた割合、閲覧権限のない文書の内容が回答に含まれていないことの4点です。精度が不足する場合は、原因が文書・検索・回答の生成のどこにあるかを特定して対処します。分割の仕方、ハイブリッド検索とリランキングの有無、エージェント検索の採否は、この評価の結果に基づいて決定します。

5. 本番の構築

試作で確認した構成で本番の環境を構築し、閲覧範囲の制御、窓口への組込み、利用履歴の記録の処理を実装します。質問と回答の記録をどこまで残すか、個人情報を含む質問の取り扱いも、この段階で定めます。

6. 運用と改善

文書の新規登録や更新は、定期的な取り込みで自動的に索引へ反映します。文書の削除や閲覧権限の変更についても、元の置き場と同期する方法を設計し、古い文書や権限が索引に残らないようにします。運用開始後は、利用履歴と評価ボタンの結果から、回答できなかった質問や誤った回答を抽出し、文書や設定を修正します。

ご依頼時にご用意いただく資料

構築には、主に次のような資料を用います。すべてが揃っていない場合も、お手元の資料の状況を伺ったうえで、進め方を検討します。

  • 対象の文書（または、その置き場所へのアクセス）
  • 実際に寄せられた質問の例

構築先の環境は、すでにお使いのクラウドや社内のサーバーの状況を伺ったうえでご相談します。

成果物

ご依頼の範囲に応じて、主に次のような成果物をご提出します。システム本体に加えて、棚卸しや評価の結果も文書としてお渡しし、運用開始後にお客様が文書の更新や精度の確認を続けられるようにします。

  • 文書の棚卸し表対象の文書ごとに、そのまま登録する・修正してから登録する・登録しないの区分と、その理由をまとめたもの
  • 評価用の質問と正解の一式代表的な質問、正しい回答、根拠となる文書の箇所を対応づけたもの
  • 精度の測定結果の報告書試作と本番の構築の各段階で、評価用の質問に対する検索と回答の精度を評価した結果
  • RAGシステム文書の取り込み、検索、回答の生成を行うプログラム
  • 利用者向けの質問の画面チャットツールや社内ポータルなど、ご要望の窓口への組込み
  • 設計書と運用手順書システムの構成と閲覧範囲の設定、文書の更新の手順、不具合が発生した場合の対応手順

期間と費用の決定要因

期間と費用は、文書の量と、閲覧範囲の制御の細かさによって大きく変わるため、ご相談の際に対象の範囲を伺い、個別にお見積もりします。期間と費用を左右する主な要素は次のとおりです。

  • 文書の量と形式（スキャンしたPDFや図表の多さ）
  • 閲覧範囲の制御の細かさ
  • 窓口の数（チャットツールだけか、社内ポータルや業務システムにも組み込むか）
  • 評価用の質問の数と、担当者の方が確認に充てられる時間

対象文書と利用者を限定した簡素な構成では、最短2週間で構築した実績があります。

クラウドを使う場合、その利用料は別途お客様の契約で発生します。検索サービスの料金プランの選択と、モデルの利用料の見込みは、試作の段階でお示しします。