この記事で分かること
- 学習用・参照用・評価用データの違いと、開発方式ごとの必要資料
- 既存のExcelや文書から始めるデータ棚卸しと品質確認の方法
- 予測の答えが紛れ込む問題や、評価の偏りを避ける考え方
- AIの正しさと現場の作業負担を分けて測る評価設計
必要なデータは「AIに任せる仕事」から決める
最初に決めたいのはファイル形式ではなく、AIが受け取る入力と、返すべき結果です。「営業を効率化する」だけでは、商談を分類するのか、訪問記録を要約するのか、次の提案を考えるのかが定まりません。例えば「問い合わせの本文から担当部署の候補を出し、人が確定する」と書けば、入力本文、部署の定義、過去の振り分け結果、担当者が迷う境界事例が必要だと分かります。
既存システムから情報を取り出す方法や、AIの結果をどこへ戻すかも、この段階で確認します。ファイルが毎回手作業で作られるなら、検証に使えても継続運用には負担が残るためです。AI受託開発・生成AIシステム開発を検討する際も、期待する回答例と実際の入力例を並べておくと、データ整理とシステム連携の相談を具体化できます。
学習用・参照用・評価用を混同しない
学習用データは、予測や分類の傾向をモデルに学ばせる材料です。参照用データは、回答を作る際に検索・照会する根拠です。評価用データは、作った仕組みが期待どおりに働くかを確かめる問題集に当たります。この区別を付けずに「AIへ渡す資料」として一括管理すると、何を増やせば改善するのか判断しにくくなります。
| 対象の仕事 | 主な入力・材料 | 別に用意する評価材料 |
|---|---|---|
| 需要や作業時間の予測 | 予測時点までの実績、条件、確定した結果 | 後の期間の実績と、従来の予測方法による結果 |
| 問い合わせの分類 | 問い合わせ本文、分類定義、確認済みの分類ラベル | 学習から分離した問い合わせと正解・許容分類 |
| 社内文書を検索するRAG | 承認済みの規程、手順書、版・適用日・閲覧権限 | 実務の質問、根拠箇所、回答に必要な条件 |
| 帳票や議事録の要約・抽出 | 対象文書、出力項目の定義、望ましい出力例 | 転記すべき値、欠落させてはいけない事項 |
既存の生成AIを利用する開発では、自社で基盤モデルを一から学習させることが前提とは限りません。RAGは必要な情報を検索して回答の材料にする構成なので、まず問われるのは資料を正しく取り出せるかです。一方で、参照資料がそろっていても評価用の質問がなければ、検索や回答の改善を判断できません。
データ棚卸しは件数よりも意味と責任者を確認する
データの所在を調べる際は、全社のファイルを一度に集めるより、対象業務が完了するまでに通る情報を追います。受注の予測なら、見積、受注、変更、取消、出荷のどこを扱うかを区切ります。同じ「売上」でも受注額と計上額が混在すれば、きれいな表へ変換しても目的に合うデータにはなりません。
棚卸し表には、データ名、管理部署、取得方法、対象期間、更新間隔、識別子、利用範囲、品質上の懸念を書きます。ファイルの所有者と内容の正しさを判断する人が違う場合は、両方を記録してください。システム担当者だけでは、空欄が未入力なのか「該当なし」なのかを確定できないことがあります。
一件の単位と結合キーをそろえる
一行が「顧客一人」なのか「注文一件」なのか「注文明細一行」なのかを定義します。注文表と明細表を結合すると、注文金額が明細の数だけ重複することがあります。この状態で集計した数値をAIに渡せば、AIの前段階ですでに判断材料が誤っています。結合前後で行数、識別子の重複、金額の合計を比較する確認手順を持ちましょう。
顧客名や商品名の文字列だけで結合する運用も点検対象です。略称や社名変更に備えて、可能なら業務上の識別子を使い、対応できないレコードは無理に結び付けず一覧へ出します。「不明なものを残さない」より「何が未確定か追跡できる」状態の方が、後から修正しやすくなります。
欠損・重複・古い情報を別々に処理する
欠損値を一律にゼロへ置き換えると、未測定と実際のゼロが区別できなくなります。処理を決める前に、発生理由、対象部署、期間を調べます。重複についても、二重登録と同じ内容の正当な再注文は別です。削除対象を識別する条件と、削除前の原本を残す場所を定めておくと、処理結果を説明できます。
文書の古さは更新日だけでは判定できません。移管作業で保存日だけ新しくなった旧規程もあり得ます。承認状態、適用開始日、失効日、後継文書を確認し、通常の検索対象と履歴参照用を分ける設計が有効です。過去時点について質問する業務なら、単純に旧版を捨てず、いつのルールを答えるのかを指定できるようにします。
複数のExcelや既存データベースで項目の意味が食い違う場合は、AIの設定変更だけでは解決しません。開発前診断・ロードマップで扱うような既存システムの現状整理を先に行い、データを直す範囲と接続方法を決めることが、開発の手戻りを減らす準備になります。
正解を定義し、現場を代表するデータを選ぶ
教師ありの分類では、正解ラベルの意味が安定していることが欠かせません。過去の担当部署をそのまま正解にすると、組織変更前の割当や誤転送が混ざる場合があります。実績として残っていることと、今後も採用したい判断であることを分けて確認します。
ラベル付けの手順書には、分類名だけでなく、判断条件、例外、迷ったときの確認先を書きます。複数担当者が同じ例を判定して結果を突き合わせれば、定義の曖昧な箇所を発見できます。合意できない問い合わせは無理に単一の正解へ押し込めず、「複数候補を提示」「情報を追加確認」といった許容動作を設計する余地があります。
件数の目標を先に固定しない
必要件数は、仕事の難しさ、データのばらつき、失敗時の影響、使う方式によって変わります。一律の件数を満たしたから実用化できるとは判断できません。まず対象業務の種類を洗い出し、通常の処理、繁忙期、特殊な顧客条件、入力不備などが含まれているかを確認します。
例えば、通常の請求書ばかりを集めても、取消伝票や複数税率の帳票の扱いは分かりません。代表例を広くそろえた試験で弱点を見つけ、改善に必要な種類を追加していく方が、同じ形式の正常データだけを増やすより判断につながります。少数しかない例外は、平均点に埋め込まず、個別の確認項目として管理します。
対象外も明記します。日本語の定型帳票を検証した結果を、外国語や手書きの帳票まで含む性能として扱わないためです。データ一覧に「今回確認した範囲」と「未確認の範囲」を残すことで、本番開始後に利用部署が増えたときの追加検証を計画できます。
学習と評価を分けて、実力の見誤りを防ぐ
判断時点では存在しない情報を入れない
予測時には分からない情報を開発時に使ってしまうと、試験の点数が良くても実務で再現できません。これをデータリークと呼びます。納期遅延の予測に出荷後の確定日数を入れる、問い合わせの受付時分類に対応完了後の社内メモを含める、といった混入が典型的な確認対象です。
項目ごとに「いつ取得できるか」を記録し、AIを動かす時点で存在するものだけを入力候補にします。履歴データを現在の状態で上書きしているシステムでは、過去時点の情報を再現できない場合があります。その場合は欠けた履歴を推測で補わず、記録方法の変更や将来分の収集から検証計画を組み直します。
同じ案件の派生データをまたがせない
学習用はモデルが傾向を覚えるため、検証用は設定を選ぶため、最終テスト用は調整後の確認のために使い分けます。行単位で無作為に分割するだけでは、同じ案件のメールや同じ文書の改訂版が双方に入り、未知の案件への対応力を測れないことがあります。案件、顧客、文書系列など、独立させたい単位で分けます。
将来の需要予測のように時間が意味を持つ仕事では、過去で学習して後の期間で評価する構成を検討します。欠損補完の平均や数値の尺度調整に使う統計量も、学習データから求め、評価データへ同じ変換を適用します。分割前の全データから値を計算すると、評価対象の情報が準備段階で混ざるためです。
最終テストを何度も見ながら設定を直すと、その問題集に合わせた調整になります。失敗分析に使うデータと、変更後の受入判定に使うデータの役割を分け、版と実施日を記録してください。開発会社への依頼では、この分割方法と評価結果の提出形式も合意事項に含めます。
RAGでは文書の読み取り・検索・回答を分けて調べる
社内文書を参照するRAGで誤答が出たとき、原因が生成AIそのものとは限りません。元のPDFを正しく読めていない、関連する節を検索できない、取得した根拠を回答へ反映できないという段階を分けて調べます。それぞれで修正対象が異なるため、質問と最終回答だけを保存する評価では原因を追い切れません。
文書を分割しても条件と根拠を失わないようにする
長い文書は検索しやすい単位へ分割して扱うことがあります。このとき、金額表から適用条件の見出しが離れたり、例外を示す脚注が別の断片になったりすると、部分的には正しくても誤解を招く回答につながります。分割した本文に、文書名、見出し、版、元ページなどを結び付け、根拠へ戻れるようにします。
読み取りの検査では、画面上のPDFと抽出された文字を比べます。特に結合セル、縦書き、複数段組、画像だけのページはサンプルを用意して確認します。検索方式の調整より先に、対象の規程や数値が取り込まれているかを確かめると、欠落した材料を探し続ける無駄を避けられます。
答えのない質問と権限の異なる質問も用意する
評価用の質問には、根拠がある質問だけでなく、資料に答えがないもの、前提が不足するもの、旧制度について聞くものを含めます。望ましい振る舞いは常に回答することではありません。根拠が不足するときは回答を保留し、確認先や追加で必要な情報を示すことも合格条件になります。
閲覧権限は生成された文章の見せ方だけでなく、検索で取得する文書にも適用します。一般社員と管理者など、権限の異なる利用者で同じ質問を試し、許可されない資料が検索結果や回答の根拠に含まれないかを検査します。検索用の複製データへ権限や削除を反映する仕組みも、元ファイルの管理とは別に確認してください。
整備の着手点を絞りたい場合は、まず一つの業務について正本の文書と質問例をそろえます。既存の保存先や更新手順に課題がある段階では、文書管理を含む改善範囲を決めてから進める方が見積もりの前提をそろえやすくなります。
評価は正答率と業務への影響を別々に測る
判定表に「許されない失敗」を書く
正答率の平均だけでは、失敗の重さを判断できません。部署の候補を一つ取り違える場合と、存在しない契約条件を案内する場合では、業務への影響が違います。評価表には「問題なく採用」「軽微な修正で採用」「再作成」「重大な誤り」などの判定区分を設け、実例を添えて担当者間で基準を合わせます。
| 評価の視点 | 確認する内容 | 記録する材料 |
|---|---|---|
| 出力の品質 | 値や分類が合うか、必要な項目が欠けていないか | 入力、期待結果、実際の結果、判定理由 |
| 根拠の整合 | 回答が参照資料で裏付けられるか | 検索された箇所、版、回答との対応 |
| 例外時の動作 | 不明・入力不備・権限不足で適切に止まるか | 保留理由、利用者への案内、引継ぎ先 |
| 業務の負担 | 確認や修正を含めて作業が減るか | 従来手順とAI利用時の所要時間、手戻り |
不良品検出や特定カテゴリの分類では、全体の正解率に加え、見逃しと誤検出を区別します。対象が少ない場合は、すべて対象外と答えても全体の正解率が高く見えるためです。分類ごとの件数と失敗内容を示し、どの失敗なら人による確認で補えるかを現場と判断します。
試験件数が少ない区分では、成功率だけでなく分母と失敗数を記録します。今回失敗がなかったことを、今後も失敗しない保証として扱わないためです。業務側が許容条件を決められない場合は、自動実行へ進める前に、人が承認する範囲を設定した検証から始めます。
従来手順との比較に確認時間を含める
回答の生成が速くても、誤りを探す時間が長ければ業務改善になりません。入力準備、回答待ち、根拠確認、修正、承認までを同じ範囲で測ります。評価の途中で確認工程を省いたり、簡単な案件だけAI側へ割り当てたりすると、比較条件が変わってしまいます。
測定の目的はAIを高く評価することではなく、使う条件と使わない条件を決めることです。検証全体の進め方は、AIシステム開発で費用対効果を出すためのPoC検証チェックリストと合わせて整理すると、精度評価を本番移行の判断につなげやすくなります。
データの引渡しと本番更新まで設計する
開発会社へ渡す際は、ファイルだけでなく、項目定義、作成条件、除外したデータ、既知の問題、正解の作り方を添えます。データの利用範囲、保管場所、アクセスできる担当者、保存期間、削除方法も合意します。実データを外部サービスへ送る構成では、そのサービスの契約・設定と社内の利用基準を確認し、氏名などが不要なら受渡し前に除去する方針を検討します。
開発中は、原本、整形処理、整形後のデータ、評価結果の対応を追えるようにします。単に「最新版」というファイル名を使うのではなく、取得日や版を識別できる形にし、どのデータで出した結果かを残してください。担当者が交代しても同じ処理を再実行できることが、改善を続ける土台になります。
本番では、入力項目の追加、商品構成の変化、規程改訂などが起きます。更新担当者と反映期限を決め、取り込み失敗、未反映の文書、分類別の修正増加を確認する運用を用意します。評価に使った質問や帳票の一部を再確認用に残せば、変更で以前の機能が崩れていないかを調べられます。
予算を考えるときは、初回のデータ整備だけでなく、追加収集、ラベル確認、文書改訂への追従、人による採点も作業に含めます。担当者の時間を確保しないまま開発だけを発注すると、判断待ちで作業が止まる原因になります。依頼前に準備する項目は、AI受託開発のRFPに入れるべき項目にもつながる論点です。
よくある質問
Excelしかありませんが、AIシステム開発を始められますか？
形式だけで可否は決まりません。一行の単位、項目の意味、必要な履歴、識別子が確認できれば検証材料になり得ます。結合セルや手入力の注記に大切な情報がある場合は、それを失わずに取り出す方法と、今後の入力方法を先に検討します。
社内文書を全部登録すれば、回答は正確になりますか？
資料が増えるだけでは保証できません。旧版の混在や根拠の分断があると、適切な情報を取り出しにくくなります。対象業務の正本を決め、代表的な質問で検索結果と回答を確認してから、登録範囲を広げます。
評価用の正解は誰が作るべきですか？
業務上の正しさを判断できる担当者が中心となり、開発側と判定可能な形へ整理します。自由記述の回答では文章の完全一致を求めるのではなく、必須事項、許容表現、禁止する断定、根拠の条件を決める方法があります。
実データをまだ渡せない場合、何を用意すると相談が進みますか？
項目一覧、入力と出力の見本、想定件数、更新頻度、対象外の条件をまとめます。架空の見本は構造の説明には使えますが、実データでの精度を示すものではありません。実データで確認する時期と、共有できる範囲を別途決めます。
まず一つの業務で、材料と合格条件をそろえる
データ準備の着地点は、ファイルを大量に集めることではなく、対象業務を再現し、結果の良し悪しを説明できる状態です。最初の打ち合わせには、実際の入力例、期待する出力例、迷う例外、データの管理者と更新方法を持ち寄りましょう。これらがそろえば、不足しているのがデータなのか、業務の定義なのか、既存システムの仕組みなのかを切り分けられます。
対象を絞った検証で、品質、確認負担、更新の手間を確かめてから利用範囲を広げます。AIの設定だけに改善を任せず、データを直す責任と、採用を判断する責任を決めることが、継続して使える仕組みへの出発点になります。
