生成AI受託開発 ／ ブログ ／ チャットボットを作る前に整えるべき社内ドキュメント7つの準備
RAG社内文書ナレッジ管理

チャットボットを作る前に整えるべき社内ドキュメント7つの準備

社内向けAIチャットボットの精度は、投入する文書の状態でほぼ決まります。正典の決定、形式の統一、メタデータ付与、更新責任者の設定まで、開発前にやるべき準備を実務手順で解説します。

「社内問い合わせをAIチャットボットで減らしたい」というご相談をいただくとき、私たちが最初にお伝えするのは、ツール選定よりも先に社内ドキュメントの状態を確認してほしい、ということです。

この記事は、社内向けチャットボット（社内規程の問い合わせ対応、情報システム部のヘルプデスク、営業向けの製品仕様照会など）の導入を検討している担当者の方に向けて、開発に着手する前に何をどこまで整えておくべきかを整理したものです。ベンダーに依頼する前でも進められる作業が中心です。

なぜドキュメントの整備が先に来るのか

社内向けチャットボットは、多くの場合RAG（検索拡張生成）という仕組みで作られます。ざっくり言えば「質問に関係しそうな社内文書の一部を検索して取り出し、それを読ませて回答を作らせる」構成です。

ここで重要なのは、検索で正しい箇所が取り出せなければ、その先の生成モデルをどれだけ良いものにしても回答は改善しないという点です。取り出された文書が古ければ古い回答が返り、同じ内容の文書が3世代分入っていればどれか1つが選ばれます。文書に書かれていない例外運用は、当然回答に出てきません。

「AIが賢くなれば解決する」と期待されがちな部分ですが、実際には入力側の問題が大半を占めます。だからこそ、開発前の文書整理が投資対効果の分かれ目になります。

ステップ1：想定質問を30件書き出す

文書の整理から始めるより先に、「何を聞かれるチャットボットなのか」を確定させることをおすすめします。

有効なのは、実際に来ている問い合わせを拾うことです。情報システム部であればヘルプデスクのチケット、人事であればメールや社内チャットの質問履歴。そこから頻度の高いものを30件ほど、実際の質問文のまま書き出します。

例：

このリストは3つの役割を持ちます。第一に、どの文書を優先して整備すべきかが決まります。第二に、開発後の精度評価の基準になります。第三に、そもそもチャットボットで答えられる質問なのかを判断できます。

実際にこの作業をすると、「これは文書に書いていない」「担当者の判断次第だ」という質問が一定数出てきます。それが判明するだけでも、この段階の価値があります。

ステップ2：正典（正しい版）を1つに決める

多くの企業で最大の障害になるのが、同じ内容の文書が複数の場所に複数の版で存在している状態です。

この状態のまま全部を投入すると、チャットボットは矛盾した情報のどれかを引いてきます。しかも利用者からは「なぜその回答になったのか」が見えないため、一度誤答が出ると信頼が急速に失われます。

やるべきことは、ステップ1で挙がった質問領域ごとに**「これが正典」と言える文書を1つ決め、それ以外を検索対象から外す**ことです。過去版を削除する必要はありません。アーカイブ用のフォルダに移し、チャットボットが参照する範囲から除外できる構造にしておけば十分です。

ステップ3：形式を扱える状態にする

文書の中身が正しくても、形式によっては機械が読めません。実務でよく問題になるのは次のパターンです。

スキャンPDF（画像化されたPDF）：文字情報を持たないため、そのままではテキストを取り出せません。OCR処理が必要になり、精度も表の複雑さに左右されます。原本のWord/Excelが残っているなら、そちらを使う方が確実です。

Excelの複雑な表：セル結合が多い表、複数シートにまたがる情報、条件が縦横のマトリクスで表現されている表は、テキスト化した時点で意味が崩れます。「対象者ごとの手当額一覧」のようなマトリクス表は、可能であれば箇条書きの文章に書き直したほうが回答精度は安定します。

PowerPoint資料：図の中に文字が入っている、1枚のスライドに断片的な単語だけが並んでいる、といった資料はテキストとしての情報量が乏しく、検索でヒットしても回答の材料になりません。研修資料などをナレッジにしたい場合は、文章化された補足が必要です。

すべてを完璧にする必要はありません。ステップ1の質問リストで上位に来る領域の文書だけ、優先的に扱える形式に直す判断が現実的です。

ステップ4：1つのセクションに1つのトピック

RAGでは長い文書をそのまま渡すのではなく、一定の長さに分割して検索します。このとき、見出しで区切られ、1セクションが1つの話題で完結している文書は分割に強いという性質があります。

具体的に効果があるのは次の書き方です。

特に主語の省略と社内用語は見落とされがちです。「AS申請はSDフォームから」と書かれた文書は、書いた部署の中では通じますが、切り出された断片として読まされた生成モデルには意味が復元できません。

ステップ5：更新日と適用範囲をメタデータとして持たせる

文書ファイルに加えて、次の情報を管理できる状態にしておくと運用が安定します。

更新日があれば、複数の候補が引かれたときに新しいものを優先する、あるいは回答に「この情報は○年○月時点の規程に基づきます」と添えることができます。適用範囲があれば、「契約社員に正社員向け規程の内容を答えてしまう」という事故を減らせます。

これはシステム側の設計にも関わるため、ベンダーと相談する部分ではありますが、元の文書側に更新日と適用範囲が書かれていないケースが多く、その場合は付与作業そのものが発生します。事前に確認しておく価値があります。

ステップ6：見せてはいけない情報を切り分ける

共有フォルダをまるごと参照させる構成は、手間が少ない反面、権限の問題を抱えます。人事フォルダの中に個人の評価情報や給与データが混在していれば、それが検索対象に入ってしまいます。

開発前に確認しておくべきことは2点です。

  1. 投入予定のフォルダに、閲覧権限が限定されるべき情報が混在していないか
  2. 利用者の所属や役職によって回答を出し分ける必要があるか

2番目が「必要」になると、システムの構成は目に見えて複雑になります。全社員が同じ情報を見られる範囲に限定して第一段階を作り、権限分離は次の段階に回す、という進め方も検討に値します。

ステップ7：更新の責任者を決める

ここが最も軽視されやすく、最も影響が大きい部分です。

規程が改定されたとき、誰がチャットボットの参照文書を差し替えるのか。この担当が決まっていないと、半年後には古い情報を答えるシステムになり、利用者は使わなくなります。

決めるべきは次の3点です。

誤答報告の受け先は特に重要です。利用者が「間違っていた」と言える窓口がないと、不満だけが溜まって利用が止まります。逆に報告が集まる仕組みがあれば、それは文書の不備リストとしてそのまま使えます。

業務シーン：情報システム部のヘルプデスクで起きること

具体例として、情報システム部への問い合わせをチャットボットで受ける場合を考えます。

問い合わせ履歴を見ると、「PCの初期設定手順」「VPNがつながらない」「アカウント発行の申請先」あたりが上位を占めることが多いはずです。ここで文書側を確認すると、次のような状況がしばしば見つかります。

この状態で開発に入ると、「スクリーンショットが読めない」「答えるべき情報がない」「古い申請先を案内する」という3種類の失敗が同時に起きます。

先に、初期設定手順に文章の説明を追記し、VPNのトラブルシューティングを担当者へのヒアリングで文書化し、申請フローのPDFを現行のものに差し替える。この作業を上位10テーマに絞って行うだけで、体感できる差が出ます。逆に言えば、この作業を飛ばして開発だけ進めても投資が回収しにくい、ということです。

チャットボットに向かないケース

正直に書きますが、以下の場合は文書を整えてもチャットボットでの解決は難しいと考えています。

判断そのものが業務の中心である場合：「この案件は与信を通せるか」「この契約条項は受け入れられるか」といった問いは、文書に書かれたルールだけでは決まりません。参考情報の提示までは可能ですが、回答をそのまま使える性質のものではありません。

数値の集計や最新データの参照が必要な場合：「今月の受注件数は」といった質問は、文書検索ではなく業務システムへの照会で解くべき問題です。RAG構成のチャットボットは、この種の質問に弱いというより、そもそも役割が違います。

文書がほぼ存在しない業務：暗黙知だけで運用されている領域は、まず文書を作る作業が本体になります。それは価値のある投資ですが、チャットボット開発とは別のプロジェクトとして考えたほうが見通しが立ちます。

問い合わせ件数が少ない領域：月に数件の問い合わせのために構築・運用のコストをかける合理性は、多くの場合ありません。

最初の一歩をどう置くか

全社のドキュメントを整えてから始めようとすると、着手できないまま時間が過ぎます。私たちがおすすめしているのは、範囲を絞った検証から入る進め方です。

  1. 問い合わせ上位の1領域を選ぶ（例：経費精算）
  2. その領域の想定質問を30件書き出す
  3. 対応する正典文書を10〜20ファイルに絞って整える
  4. その範囲で試作し、30件の質問への回答を人間が採点する
  5. 誤答の原因を「文書がない」「文書が古い」「書き方の問題」「検索の問題」に分類する

5番目の分類が、次に何をすべきかを教えてくれます。文書側の問題が多ければ整備を続け、検索側の問題が多ければシステムの調整に進む。この切り分けができる状態になっていることが、拡大の前提条件です。

チャットボット導入の成否は、多くの場合ツールの選択ではなく、この地味な準備をどこまでやったかで分かれます。そして幸いなことに、ここで整えたドキュメントは、チャットボットを作らなかったとしても社内の資産として残ります。

社内文書の状態を見たうえで実現可能性を判断したい、という段階でのご相談も承っています。