業務AIエージェントのナレッジベース・RAG環境の作り方｜設計と構築の基本

AIに任せたいのに、結局“社内ではどうするか”を毎回人が補足しています

これは、製造業のDX推進部で業務実行AIエージェントの検証を進めていた佐伯さん(仮名)の言葉です。半年前、同社では営業、情シス、法務、現場部門がそれぞれ別のフォルダやSlackに情報を持ち、AIは一般的な回答こそできるものの、社内ルール、顧客別の例外、過去の判断履歴までは踏まえられませんでした。見積作成や問い合わせ対応を任せようとしても、「その判断はA社向けには違う」「最新版の規程を見ていない」と差し戻される状態だったのです。

現在は、直近3か月で整備した約1,200件の業務ドキュメントに、文書種別、更新日、管理部門、アクセス権限などのメタデータを付与し、RAG環境からAIエージェントが必要な社内ナレッジを検索できる状態に近づいています。KanataのようにAIチャットや学習データライブラリをプロジェクト単位で扱える基盤を使えば、部門や用途ごとに参照先を分けながら、段階的に運用を試せます。

この記事では、業務実行AIエージェント RAGを整備したい企業に向けて、ナレッジベース AIの作り方、ベクター検索の設計、鮮度管理、評価指標までを共通パートとして整理します。目指すのは、AIが一般論ではなく、自社固有の前提を確認しながら業務を補助できる状態です。ただし、RAG 設計だけで全ての判断が自動化できるわけではありません。ドキュメント整備、権限設計、人によるレビューを含めて、自社の現場に合わせて参考にしてみてください。

業務実行AIエージェントにRAG環境が必要になる理由

業務実行AIエージェントは、単に質問へ回答するAIチャットとは役割が異なります。

問い合わせに回答する、見積条件を整理する、社内申請の内容を確認する、顧客対応の次アクションを提案する。こうした業務をAIに補助させる場合、AIは一般的な知識だけでなく、その会社のルール、過去の判断、業務フロー、例外条件を踏まえる必要があります。

たとえば、次のような質問があったとします。

• この顧客には、標準契約のどの条項を適用すべきですか
• この問い合わせは、一次回答で処理してよいですか。それとも法務確認が必要ですか
• この申請内容は、社内規程上、承認して問題ありませんか

これらは、一般的な生成AIだけでは正確に判断しにくい問いです。答えはインターネット上の一般論ではなく、自社の契約テンプレート、社内規程、過去の判断履歴、部門ごとの運用ルールの中にあるからです。

そこで必要になるのが、業務実行AIエージェント RAGです。

RAGとは、Retrieval-Augmented Generationの略で、日本語では「検索拡張生成」と呼ばれます。AIが回答を生成する前に、外部のナレッジベースから関連情報を検索し、その内容を参照して回答する仕組みです。RAGの一般的な説明は、Google CloudのRAG解説などでも確認できます。

社内ナレッジ検索、ベクター検索、メタデータ検索を組み合わせることで、AIが「一般的にはどうか」だけでなく、「この会社ではどう判断しているか」に近い回答を作りやすくなります。

RAG環境は「AIに社内常識を丸ごと覚えさせる仕組み」ではない

RAG環境を作れば、AIが自動的に社内のすべてを理解するわけではありません。

RAGは、AIに知識を丸ごと覚えさせる仕組みではなく、必要なタイミングで、必要な社内ナレッジを検索し、回答の根拠として使わせる仕組みです。そのため、RAG環境の品質は、主に次の4つに左右されます。

1. 登録されているドキュメントの品質です。古い資料、重複した資料、見出しのないPDF、作成者不明のメモが大量に入っている状態では、AIも必要な根拠を見つけにくくなります。
2. 検索設計です。単純なキーワード検索だけでは、表現が少し変わった質問に対応しづらくなります。一方で、ベクター検索だけに頼ると、文書名、規程番号、契約条項などの厳密な一致が弱くなる場合があります。
3. アクセス権限です。AIが本来見てはいけない資料を参照してしまうと、業務効率化以前に情報管理上の問題が起きます。LLMアプリケーションにおける権限不備やデータ漏えいリスクは、OWASP Top 10 for LLM Applications 2025でも重要論点として整理されています。
4. 運用です。ナレッジベース AIは、作って終わりではありません。新しい資料を追加し、古い資料を差し替え、使われなかった検索結果や誤回答を見直す必要があります。

つまりRAG 設計とは、AIに知識を与えるだけの作業ではありません。社内ナレッジを「AIが安全に扱える状態」に整える業務設計です。

ナレッジベースに入れるべき情報を整理する

最初に行うべきことは、社内の情報をすべて集めることではありません。業務実行AIエージェントに補助させたい業務を決め、その業務に必要なナレッジだけを整理することです。

社内問い合わせ対応を対象にするなら、就業規則、経費規程、出張規程、FAQ、過去の問い合わせ履歴が候補になります。

営業支援を対象にするなら、提案書、商談メモ、顧客別の契約条件、導入事例、競合比較表、営業プレイブックが候補になります。

マーケティング支援を対象にするなら、過去記事、ホワイトペーパー、広告文、ペルソナ資料、ブランドトーン、禁止表現リストなどが候補になります。

ここで重要なのは、ナレッジを「資料の種類」だけで見ないことです。業務実行AIエージェントが必要とするのは、資料そのものではなく、判断に使える情報です。

たとえば、営業資料の中には、顧客への説明に使える情報もあれば、社内向けの暫定メモもあります。経費規程の中にも、社員にそのまま案内してよい文言と、人事・経理側で解釈が必要な文言があります。

ナレッジベース AIを作るときは、次のように分類しておくと扱いやすくなります。

この分類が曖昧なまま資料を登録すると、AIは「公式ルール」と「参考メモ」を同じ重さで扱ってしまう可能性があります。それが、RAG環境の失敗事例につながります。

ドキュメント整備はRAG設計の前提になる

RAG環境というと、ベクター検索や埋め込みモデルなどの技術に目が向きがちです。しかし、実務上の成否を分けるのは、ドキュメント整備です。

よくある失敗は、既存のファイルサーバーや社内WikiをそのままAIに読ませようとすることです。

次のような状態では、AIが正しい情報を見つけにくくなります。

• 「最新版」「最終版」「最終版_v2」のようなファイルが並んでいる
• PDFの中に画像化された文字が多く、本文として読み取れない
• 1つの議事録に複数テーマが混ざっている
• 社内用語の略称が説明なしに使われている
• 更新日や作成者が分からない
• 既に廃止されたルールが残っている

人間なら、文脈や経験で「おそらくこちらが新しい」と判断できるかもしれません。しかしAIエージェントに業務を補助させる場合、その曖昧さは誤判断の原因になります。

最低限、次の項目は整えておきたいところです。

Kanataのように、プロジェクトごとにアプリや学習データライブラリを分けられる仕組みを使う場合も、この整理は重要です。Kanataでは、プロジェクト単位でメンバー、データ、アプリを整理し、プロジェクトライブラリにAI設定・プロンプト・学習データを置く考え方が示されています。

メタデータはAIの検索精度を支える

ナレッジベース AIでは、本文だけでなくメタデータが重要です。

メタデータとは、文書そのものに付与する補助情報です。たとえば、部署、業務カテゴリ、対象顧客、文書種別、作成日、更新日、権限区分などが該当します。

人間が資料を探すときは、「営業部のフォルダにある、A社向けの、昨年更新された提案資料」のように探します。AIにも同じように、検索の手がかりが必要です。

RAG環境では、メタデータを使うことで、次のような制御がしやすくなります。

• 2025年4月以降に更新された規程だけを参照する
• 営業部の資料のうち、製造業向けの提案書だけを検索する
• このユーザーがアクセスできるプロジェクトの文書だけを参照する
• 参考資料ではなく、公式ルールだけを回答根拠にする

特に、業務実行AIエージェントでは、検索結果の関連性だけでなく、参照してよいかどうかが重要になります。どれほど関連性の高い資料でも、権限のない資料をAIが使ってはいけません。

そのため、メタデータ設計では、少なくとも次の項目を検討します。

メタデータは細かくしすぎると運用が続きません。一方で、粗すぎると検索精度と権限制御が弱くなります。初期段階では、部署、業務カテゴリ、文書種別、更新日、機密区分の5つから始めると、現場でも運用しやすくなります。

ベクター検索とキーワード検索を使い分ける

社内ナレッジ 検索では、ベクター検索がよく話題になります。

ベクター検索とは、文章を数値の並びであるベクトルに変換し、意味的な近さをもとに関連文書を探す方法です。ベクター検索やRAG向けデータベースの考え方は、IBMのRAG向けベクターデータベース解説でも紹介されています。たとえば「出張費の精算期限を知りたい」と質問したときに、文書内に「出張費」という言葉がなくても、「旅費申請」「立替経費」「精算期日」といった関連表現を探しやすくなります。

これは、RAG環境において有効な技術です。ユーザーの質問文と社内文書の表現は一致しないことが多いからです。

一方で、ベクター検索だけでは不十分な場面もあります。

規程番号、契約条項、製品コード、顧客名、案件番号などは、意味の近さよりも完全一致が重要です。「第12条」と「第21条」を意味的に近いからといって混同してはいけません。

そのため、実務では次のような使い分けが必要です。

業務実行AIエージェント RAGでは、ハイブリッド検索を前提に考えるのが現実的です。

たとえば、社員が「海外出張のホテル代はいくらまで認められますか」と質問した場合、ベクター検索で関連する旅費規程を探し、メタデータで最新版かつ全社規程に絞り込み、キーワード検索で「宿泊費」「海外出張」「上限額」を確認する、という流れが考えられます。

チャンク設計で回答の品質が変わる

RAG環境では、ドキュメントをそのまま丸ごと検索対象にするのではなく、一定の単位に分割して扱います。この分割単位をチャンクと呼びます。

チャンクが大きすぎると、検索結果に余計な情報が混ざります。AIが必要な箇所を見つけにくくなり、回答がぼやける可能性があります。

逆に、チャンクが小さすぎると、前後の文脈が失われます。規程の条件文や例外規定が切り離され、誤った解釈につながることがあります。

たとえば、次のような文書があったとします。

国内出張の宿泊費上限は1泊12,000円とする。ただし、役員同行、災害対応、顧客指定施設への宿泊など、業務上やむを得ない理由がある場合は、上長承認により例外を認める

この文を「国内出張の宿泊費上限は1泊12,000円とする」だけで切り出すと、例外条件が消えます。逆に、旅費規程全体を1つのチャンクにすると、必要な情報に対して周辺情報が多すぎる場合があります。

チャンク設計では、次の考え方が役立ちます。

• 1つのチャンクに1つの論点を入れる
• 条件と例外を分断しない
• 見出し情報をチャンクに含める
• 表や箇条書きは意味が崩れない単位で扱う
• 規程や契約書は条項単位を基本にする
• FAQは質問と回答をセットで扱う
• 議事録はテーマ単位で分ける

チャンク設計は、技術担当だけで決めると失敗しやすい領域です。業務部門が「どこまでが1つの判断単位か」を確認しながら設計する必要があります。

アクセス権限はRAG環境の中核である

業務実行AIエージェントに社内ナレッジを参照させるとき、避けて通れないのがアクセス権限です。

AIが便利になるほど、参照できる情報の範囲は広がります。しかし、誰にでも全社の情報を見せてよいわけではありません。

営業部の顧客別提案書、人事部の評価資料、法務部の契約交渉メモ、経営会議の議事録などは、それぞれ参照できる人が限られます。AIエージェントがこれらを横断的に検索する場合、ユーザー本人の権限に応じて検索対象を制御しなければなりません。

起きやすい失敗は、ナレッジベース側には権限があるものの、RAG検索時には権限が考慮されていない状態です。

人間がファイルサーバーで見られない資料でも、AIの回答にその内容が混ざってしまえば、実質的な情報漏えいにつながります。

そのため、RAG 設計では次の原則を置くべきです。

• ユーザーが見られない文書は、AIも参照できない
• プロジェクトや部門ごとにナレッジベースを分ける
• 文書単位、可能であればチャンク単位で権限を持たせる
• 機密区分をメタデータとして管理する
• 回答には参照元を表示し、確認できるようにする
• 退職者・異動者の権限変更を反映する

Kanataのベストプラクティスでは、プロジェクトは「関係者が同じ情報を見てよいか」で切る考え方が示されています。営業部とエンジニア部の情報を同居させてよい関係か、そうでなければ分けるべきかを判断する視点は、RAG環境にも当てはまります。

鮮度管理をしないRAGは古い判断を再生産する

RAG環境では、古い情報を参照してしまうリスクがあります。

これは、業務実行AIエージェントにとって重大な問題です。AIの回答が自然であるほど、ユーザーはそれを正しいと受け取りやすいからです。

たとえば、就業規則が改定された後も古い規程が残っていれば、AIは古い申請条件を案内するかもしれません。価格表が更新された後も旧価格の提案資料が残っていれば、営業AIエージェントが誤った金額で提案を作るかもしれません。

そのため、ナレッジベースには鮮度管理の仕組みが必要です。

具体的には、次のような運用を決めます。

特に注意すべきなのは、長く使われる資料ほど古くなりやすいという点です。

社内FAQ、営業資料、導入事例、規程集などは、作成時には正しくても、半年後には条件が変わっていることがあります。RAG環境では、古い資料を「消す」ことも品質向上の一部です。

「分からない」と答えられるAIにする

業務実行AIエージェントにとって重要なのは、正しい答えを出すことだけではありません。分からないときに、分からないと答えられることも同じくらい重要です。

ナレッジベースに根拠がないのに、AIが一般論で補ってしまうと、業務上の事故につながります。

たとえば、社員が「このケースは経費精算できますか」と質問したとき、規程に明記されていないにもかかわらず、AIが「一般的には認められる可能性があります」と回答してしまうと危険です。

この場合に望ましい回答は、次のようなものです。

登録されている経費規程には、このケースを明示した記載は見つかりませんでした。経理担当に確認してください。関連しそうな規程は第3章の出張費精算です

このような回答をさせるには、プロンプトと評価設計が必要です。

Kanataのベストプラクティスでも、規程・FAQヘルプデスク用途では、AIに「分からないと言わせる」プロンプトが重要であり、無理に答えさせると誤った規程解釈につながるとされています。

RAG環境では、次のようなルールをプロンプトに組み込みます。

• 根拠資料が見つからない場合は、推測で答えない
• 回答には参照元の文書名、章、ページ、条項を示す
• 古い資料と新しい資料が矛盾する場合は、両方を提示し、人に確認を促す
• 判断に必要な情報が不足している場合は、追加質問をする
• 業務上の最終判断が必要な場合は、担当部門への確認を案内する

「答えられるAI」よりも、「根拠がある範囲で答え、範囲外では止まれるAI」のほうが、業務実行には向いています。

評価指標を決めなければ改善できない

RAG環境は、一度作って終わりではありません。検索結果、回答内容、ユーザーの修正、業務成果を見ながら改善していく必要があります。

そのためには、評価指標を決めておく必要があります。

代表的な評価指標には、次のようなものがあります。

ここで大切なのは、AIの回答そのものだけを評価しないことです。

業務実行AIエージェントの目的は、きれいな文章を出すことではなく、業務を安全かつ再現性のある形で進めることです。そのため、評価指標には業務側の指標も含める必要があります。

問い合わせ対応であれば、初回回答時間、一次解決率、差し戻し率、担当部門へのエスカレーション率を見ます。

営業支援であれば、提案書作成時間、商談準備時間、CRM入力の抜け漏れ、ナレッジ再利用率を見ます。

社内申請であれば、申請不備率、承認までの時間、確認依頼の件数を見ます。

AIの精度だけを追うのではなく、業務のどこが改善したかを見ることが重要です。

小さく始めるRAG環境構築ステップ

RAG環境は、全社一斉に始めると複雑になります。最初は、1業務、1部門、1ナレッジ群に絞って始めるのが現実的です。

ここでは、30日程度の検証を想定した進め方を紹介します。実際の期間は、対象業務の複雑さ、文書量、権限設計の難易度によって変わります。

よくある失敗事例

RAG環境の構築では、いくつかの失敗パターンがあります。

Kanataで考えるナレッジベース運用の一例

RAG環境は、単独の検索システムとして構築する方法もあれば、既存の業務支援プラットフォームやAI活用基盤と組み合わせて運用する方法もあります。

たとえばKanataを使う場合、営業部向けのプロジェクトを作り、その中に営業支援用AIチャット、提案書要約用AI要約、営業研修用eラーニングを置く設計が考えられます。さらに、プロジェクトライブラリに提案書テンプレート、競合比較資料、過去商談メモ、営業トーク例を登録すれば、用途ごとに参照先を整理しやすくなります。

Kanataでは、プロジェクトの中にAIチャット、AI要約、eラーニングなどのアプリを追加でき、プロジェクトライブラリからAI設定・プロンプト・学習データを管理する構成が説明されています。

この構成にすると、業務ごとに参照するナレッジを分けやすくなります。

人事総務向けプロジェクトでは、就業規則、経費規程、FAQを参照する問い合わせBotを作る。営業向けプロジェクトでは、提案書や顧客事例を参照する商談準備AIを作る。マーケティング向けプロジェクトでは、過去記事、ブランドトーン、禁止表現リストを参照するコンテンツ制作AIを作る。

このように、プロジェクト単位でナレッジとアプリを分けることで、アクセス権限、利用目的、評価指標を整理しやすくなります。ただし、Kanataに限らず、同様の設計は他のAI基盤、社内検索基盤、文書管理システムでも実現できます。重要なのは、ツール名ではなく、業務単位でナレッジ、権限、評価指標をそろえることです。

RAG環境は3つの視点で設計する

共通パートとして押さえたいのは、RAG環境には3つの視点があるということです。

同じRAG環境でも、見る立場によって重視する論点は変わります。だからこそ、最初に共通の設計思想をそろえたうえで、自社の組織構造や業務特性に合わせて設計することが重要です。

まとめ

業務実行AIエージェントに自社の業務を補助させるには、一般的なAI回答だけでは足りません。

必要なのは、社内ナレッジを検索し、権限を守り、最新版を参照し、根拠を示しながら回答できるRAG環境です。

ただし、RAG環境は技術だけで完成するものではありません。ドキュメント整備、メタデータ設計、アクセス権限、鮮度管理、評価指標、人によるレビューがそろって初めて、業務で使える基盤になります。

最初から全社展開を狙う必要はありません。まずは1業務、1部門、1ナレッジ群から始め、検索結果と回答を検証しながら、AIエージェントが参照できる社内ナレッジを育てていくことが現実的です。

社内の暗黙知や散らばった資料を、AIが扱えるナレッジベースに変える。その積み重ねが、業務実行AIエージェントを一般論の回答者から、自社の前提を踏まえて動ける実務パートナーへ近づけていきます。

Q&A