
この記事のポイント
- 整理するデータは、AIで改善したい業務に必要な範囲に絞って始める。
- 最新版の確定と機密度の区分は、開発を始める前に済ませておきたい作業。
- ファイルの整理後は実際の質問で照合し、更新・削除が検索結果へ反映されることまで確認する。
社内の資料を参照して回答するAIアプリや、社内のデータをもとに書類の下書きを作るAIアプリでは、使うデータの状態が出力の質に大きく関わります。古い資料や内容の重なる資料がそのまま使われれば、AIの回答も古くなったり、食い違ったりするためです。
一方で、社内のすべてのデータをきれいに整えてから開発を始めようとすると、いつまでも着手できません。AIで改善したい業務に必要なデータを見極め、その範囲で整理を進めるのが現実的です。
この記事では、AIアプリの開発を始める前に整理しておきたい社内データについて、確認する項目と進め方を説明します。
対象の 業務に 必要な データを 洗い出す
最初に、AIアプリで改善したい業務を一つ決め、その業務で使っているデータを書き出してみましょう。担当者が普段どの資料を見て、どのシステムから情報を取り出しているかを聞き取ると、必要なデータが見えてきます。
社内のデータは、主に次のような種類に分けられます。種類ごとに確認したい点も異なるため、表に整理しました。
| 種類 | 例 | 確認したい点 |
|---|---|---|
| 文書 | 規程、マニュアル、提案書 | 最新版はどれか、ファイル形式 |
| 表 | 価格表、商品一覧 | 表の構造、更新の頻度 |
| システム内のデータ | 販売管理、顧客管理 | 取り出す方法、閲覧権限 |
| やり取りの記録 | 問い合わせの履歴、メール | 個人情報の有無、使ってよい範囲 |
この段階では、すべてのデータを集める必要はありません。業務で実際によく使われているものから順に、置き場所と管理している人を一覧にしておきましょう。
最新版と 重複を 整理する
共有フォルダには、同じ文書の古い版と新しい版が並んでいることがよくあります。「最新」「修正版」「確定」のような言葉がファイル名に付いた文書が複数あり、どれが正しいか分からないという状況も珍しくありません。

AIアプリが古い版を参照すると、すでに変わった規程や価格をもとに回答を作ってしまいます。開発を始める前に、文書ごとに最新版を一つに決め、古い版は検索の対象から外すか、別の場所に移しておくことをおすすめします。
内容の重なる文書も確認しておきたい点です。同じ手順が複数のマニュアルに少しずつ違う形で書かれている場合、AIの回答が文書によって食い違うおそれがあります。どちらを正とするかを担当部署で決めておけば、こうした食い違いを減らせるでしょう。
ファイルの 形式と 中身を 確認する
AIが資料を読み取るには、文字のデータとして取り出せる形式であることが前提になります。紙をスキャンしたPDFや写真のように、画像として保存された資料は、そのままでは文字として扱えない場合があります。
その場合は、文字を読み取る処理を加えるか、元の電子データを探すことを検討してください。手書きの書類や、図が中心の資料は、読み取りの精度も確かめる必要があります。
表計算ファイルも注意が必要です。セルの結合が多い表や、一つのシートに複数の表が並んでいるファイルは、AIが内容を正しく読み取れないことがあります。必要に応じて、一行に一件のデータが並ぶ形に整えておくと扱いやすくなるはずです。
機密度と 閲覧 権限を 区分する
社内のデータには、全社員が見てよいものと、一部の人しか見てはいけないものがあります。人事や給与に関する資料、顧客の個人情報、取引先との契約内容などは、閲覧できる人を限るべきデータです。
AIアプリでは、こうしたデータを区別せずに登録すると、回答を通じて権限のない人に内容が伝わるおそれがあります。データごとに機密度を区分し、誰が閲覧できるかを整理しておくことが欠かせません。
外部のAIサービスにデータを送ってよいかどうかも、社内の決まりに照らして確認しておきましょう。送信したデータの扱いはサービスや契約によって異なり、条件が変わることもあるため、公式情報を確認する必要があります。個人情報の扱いについては、最新の情報を公的機関や専門家に確認してください。
更新の 担当と ルールを 決める
AIアプリを公開した後も、規程の改定や価格の変更は続きます。データを最新の状態に保つためには、誰が、どのタイミングで、どのデータを更新するのかを決めておくことが大切です。
たとえば、規程は総務の担当者が改定のたびに差し替える、価格表は月に一度更新する、といったルールが考えられます。更新の担当者が専門知識なしで作業できるように、管理画面の要否も開発会社と相談しておくとよいでしょう。更新した日付と内容を記録しておけば、AIの回答が変わった理由を後から確かめるときにも役立ちます。
評価に 使う 質問と 答えの 例も 集める
データの整理とあわせて、AIアプリの出来を確かめるための例も集めておきます。実際に社内で寄せられた質問と、それに対する正しい答え、答えの根拠となる資料の組です。
この例があれば、開発中にAIの回答が正しいかを確かめられ、公開後に設定を変えたときの確認にも使えます。答えの根拠となる資料が見つからない質問があれば、整理すべきデータが不足しているという手がかりにもなるでしょう。
要件定義でほかに決める項目については、AIアプリ開発の要件定義で決めることで説明しています。
商品 問い合わせの 資料を 整理する例
架空の販売会社で、商品仕様の質問に答えるAIを準備するとします。共有フォルダには現行の仕様書、旧版のカタログ、営業担当者が作った説明メモ、顧客向けの見積書があります。これらを一括で登録する前に、回答の根拠として使えるかを分けます。
| 資料 | 最初の判断 | 整理する理由 |
|---|---|---|
| 承認済みの現行仕様書 | 対象にする | 商品の仕様を確認する根拠になる |
| 廃番商品の旧カタログ | 現行商品と区別して保留 | 新旧の条件が混ざるのを防ぐ |
| 個人作成の説明メモ | 商品責任者が確認する | 独自の解釈が含まれる場合がある |
| 顧客別の見積書 | 最初の対象から外す | 個別の価格や取引条件が含まれる |
整理表には、資料名だけでなく、元の保存場所、責任者、適用開始日、閲覧できる人、差し替え方法を記入します。適用開始日とファイル更新日は別の情報です。翌月から有効になる仕様書を今日登録した場合に、今日から新仕様として回答しないよう区別します。
一つの 資料を 質問と 照合する
準備ができたら、資料を開いて答えられる質問を作ります。「型番Bに付属するケーブルの長さは何メートルか」という質問なら、表の型番と長さが対応して取り出せているかを見ます。文字が読めていても、列の関係が崩れていると違う商品の値を答えることがあります。
資料を少量登録し、取り出した文章と元のページを並べて確認します。図や脚注に条件があるなら、その条件も残っているかを確認してください。「標準仕様の場合に限る」といった注記が消えると、数値自体が正しくても誤った案内になります。
登録前の 確認を 三段階に 分ける
第一段階は、業務の担当者が内容の正しさを確認する作業です。最新版か、適用対象は何か、矛盾する資料はないかを見ます。ここで分からない資料は、登録後にAIが判断してくれるものとして扱わず、保留にします。

第二段階は、管理者が利用範囲を確認する作業です。社員全員に見せてよい資料か、部署限定かを整理します。資料に必要な範囲を超える情報がある場合は、承認された抜粋版を作る案もあります。その場合も、元資料との対応と更新担当を残します。
第三段階は、開発担当者が取込み後の状態を確認する作業です。見出し、表、脚注、ページ番号がどう扱われるかを見て、質問から正しい箇所を探せるかを試します。三段階のうち、技術的な取込みだけが成功しても、業務で利用できるとは限りません。
資料を 消した 後も 回答に 残る 問題への 備え
元の共有フォルダから資料を消しても、AIアプリ側へ作成したコピーや検索用データが残る構成があります。更新の手順には追加だけでなく、差し替え、廃止、閲覧範囲の変更も含めます。
たとえば商品説明を廃止したら、元資料を移動する担当者と、検索対象から外れたことを確かめる担当者を決めます。確認には、その資料だけに答えが載っていた質問を使います。廃止後に同じ内容を返すなら、コピーや一時保存されたデータを調べます。
資料整理の完了条件は、フォルダがきれいになったことだけではありません。担当者が根拠をたどれ、変更後の内容を確認できる状態までを含めます。運用の担当分担はAIアプリ公開後の保守運用と合わせて決めておくと引き継ぎやすくなります。
まとめ
AIアプリの出力の質は、使うデータの状態に大きく左右されます。開発を始める前に、対象の業務に必要なデータを洗い出し、最新版の確定、ファイル形式の確認、機密度と閲覧権限の区分、更新ルールの決定を進めておけば、開発の途中で手戻りが起きにくくなるはずです。すべてを完璧に整える必要はないので、一つの業務に必要な範囲から始めてみてください。
e-Grantsでは、RAGやLLMを使ったAIアプリケーションについて、課題の整理から設計・開発、公開後の保守運用まで対応しています。どのデータを整理すればよいかの段階から相談したい方は、AIアプリケーション受託開発のページをご覧ください。


