生成AIで日報と問い合わせを読み、現場の異常を早く拾う仕組み

日報やお問い合わせフォームに書かれた文章には、集計表には出てこない異常の兆候が埋もれています。「いつもと違う」「念のため確認したい」といった一文を、担当者が読み切れずに見落とすことも起こります。生成AIにこれらの文章を読ませ、異常の可能性がある記述を拾い出す仕組みを作ると、見落としを減らせます。ただし個人情報の扱い、誤検知の前提、最終判断を人が行う設計の3点を先に決めておく必要があります。

日報とお問い合わせに埋もれている異常

配車の日報、出荷の日報、お問い合わせフォームの自由記述欄には、数値では表れない情報が書かれています。「荷物の破損が多かった気がする」「同じ商品について問い合わせが続いている」といった記述は、件数が少ないうちは誰かの気づきに依存していて、忙しい時期ほど読み飛ばされます。

生成AIに読ませると何が変わるか

生成AIに日報やお問い合わせの文章を読ませると、人が全件を目視する代わりに、あらかじめ決めた観点（破損、遅延、同一内容の繰り返しなど）に該当しそうな記述を拾い出せます。拾い出した結果を担当者に通知する仕組みにすれば、全件を読む時間を、拾われた記述を確認する時間に置き換えられます。

個人情報・社外秘を読ませる前の対策

日報やお問い合わせには、取引先名、担当者名、電話番号などが含まれます。個人情報保護委員会は2023年6月2日の生成AIサービスの利用に関する注意喚起等で、事業者に2点を求めています。個人情報を含むプロンプトを入力する場合は、特定した利用目的の達成に必要な範囲内かを十分に確認すること。本人の同意なく個人データを入力し、それが応答の出力以外の目的で扱われると個人情報保護法違反になる可能性があるため、提供事業者が機械学習に利用しないこと等を十分に確認すること。PTはこの2点を、次の対策に落として組み込みます。

対策	具体的にやること	防ぐもの
送る前に置き換える	氏名、電話番号、住所、メールアドレスをプログラムで記号に置き換えてから送る。取引先名は社内の取引先コードに変換する	個人データと取引先情報の外部送信
学習に使われない契約で使う	法人向けプランまたはAPIの規約で、入力が学習に使われないことと保持期間を確認し、確認日と該当条項を社内に記録する	応答以外の目的での利用
利用目的を照合する	問い合わせ対応・品質改善が、公表済みのプライバシーポリシーの利用目的に入っているかを確認し、無ければ改定してから始める	目的外利用
委託先として監督する	提供事業者が入力データを取り扱う契約であれば、個人情報の取扱いの委託として契約内容を確認し、監督する（個人情報保護法第25条）	委託先管理の不備
処理する国を把握する	データが外国のサーバーで処理される場合は、その国を把握し、社内の安全管理措置に反映する	外的環境の把握漏れ
権限とログを残す	通知を見られる人を限定し、いつ、どの日報を何件送ったかをログに残す	社内からの漏えいと説明不能

最も効く対策は、1行目の置き換えです。異常を拾うのに、氏名や電話番号は必要ありません。送る前に消してしまえば、残りの対策は「念のため」の位置づけになります。

社外秘も同じ考え方で扱います。取引先から秘密保持契約のもとで受け取った取引条件や出荷数量は、契約の開示制限・目的外使用の条項を確認し、範囲外であれば置き換えの対象に加えます。自社のノウハウを不正競争防止法の営業秘密として守るには、秘密として管理されていることが要件です。学習に使われる無料版に入力する運用は、この管理を自ら崩すことになるため、社内ルールで禁止します。

社内ルールに書く項目は、使ってよい生成AIサービスの名前、入力してはいけない情報の一覧、置き換え処理を通さない送信の禁止、例外を承認する担当者の4つです。

誤検知は前提にする

生成AIが「異常かもしれない」と拾う記述には、実際には異常ではないものも混ざります。これは仕組みの欠陥ではなく、最初から人が確認する前提で設計するものです。

仮に日報1,000件のうち、実際に対応が必要な異常が10件だとします。生成AIが「異常の可能性あり」として拾った件数が40件だった場合、残り30件は確認した結果問題なしと判断されるものです。この仮の例のように、拾う件数は実際の異常件数より多くなるよう設計するのが基本です。少なく拾うように調整すると、本当の異常を見落とすリスクが上がります。

観点ごとに拾う記述の例

生成AIに読ませる観点をどう設定するかのイメージとして、一般的な例を示します。実際の記述ではなく、観点の設計を示すための例文です。

観点	日報に書かれる例	お問い合わせに書かれる例
破損	荷物に傷があったと報告された	届いた商品が破損していたという連絡
遅延	配送が予定より遅れたと記載	届く予定日を過ぎても届かないという連絡
同一内容の繰り返し	同じ商品の不具合報告が複数件	同じ注文番号への問い合わせが複数回届いている

観点は最初から多く設定せず、1〜2個から始めて、拾われた記述の精度を見ながら増やしていく進め方をPTは勧めます。

導入後に精度を確認する進め方

仕組みを作った直後は、拾う基準が自社の業務に合っているかどうかが分かりません。最初の数週間は、生成AIが拾った記述と、拾わなかった記述の両方を担当者が目視で確認する期間を設けます。拾われなかった記述の中に対応が必要なものが混ざっていないか、拾われた記述のうち実際に対応が必要だったものはどれくらいかを記録し、拾う基準（観点やキーワードの設定）を調整します。

この確認期間を設けずに本運用に入ると、基準が合っていないまま通知が流れ続け、担当者が通知を確認しなくなる状態につながります。基準を調整したあとも、月に一度は拾った件数と対応が必要だった件数を振り返り、基準が業務の変化に合っているかを確認します。

通知を受け取る担当者を決めておく

拾い出した記述を誰に通知するかを、仕組みを作る前に決めておきます。複数の部署に関わる内容であれば、一次確認をする担当者と、対応が必要と判断された場合に引き継ぐ先を分けておくと、通知が宛先不明のまま放置される状況を避けられます。担当者が不在のときの代理確認者も、あらかじめ決めておきます。

拾う観点を増やすときの進め方

最初に設定した観点で運用が安定したら、次の観点を追加するかどうかを検討します。観点を一度に複数追加すると、どの観点が誤検知を増やしているのかが分かりにくくなります。追加するときは1つずつ増やし、数週間の確認期間を経て精度を見てから、次の観点を検討する順番を守ります。

観点を追加するたびに、担当者が確認する記述の量も増えます。確認の負担が担当者の通常業務を圧迫しないよう、観点を増やす前に、現在の確認作業にかかっている時間を把握しておくことも必要です。

人が最終判断する設計にする理由

生成AIの役割は「読む量を減らす」ことで、「判断する」ことではありません。拾い出した記述が本当に対応が必要かどうかは、現場を知っている担当者が確認します。この順番を逆にして、生成AIの判断だけで対応の有無を決めてしまうと、誤検知による対応漏れや過剰対応が、確認されずに進んでしまいます。

通知を受け取った担当者が「対応する」「対応不要」を記録に残す運用にしておくと、後から仕組みの精度を見直す材料にもなります。

生成AIの出力を確認するときのチェック項目

生成AIが拾った記述を担当者が確認するときは、毎回同じ観点で見られるよう、確認項目を決めておきます。

確認項目	確認する内容
拾われた理由	どの観点（破損・遅延・繰り返しなど）に該当したか
元の記述	日報・問い合わせの該当部分の原文
対応の必要性	対応が必要か、確認のみで終わるか
対応結果	対応した内容と完了日

この項目を記録に残しておくと、後から拾う基準を見直すときの材料になるほか、同じ担当者が交代した場合の引き継ぎ資料としても使えます。

小さく始めるときの範囲の決め方

最初から全部署の日報とお問い合わせを対象にすると、マスキングの設計も確認の負担も大きくなります。1つの部署、1つの観点（例えば配送の破損報告だけ）に絞って動く形を作り、確認の負担と拾える件数のバランスを見てから対象を広げる進め方をPTは勧めます。範囲を絞って始めると、個人情報のマスキング設計も対象が少ない分だけ検証しやすくなります。

あわせて読みたい記事として、「在庫差異の原因をAIに探らせる前に、現場でそろえておくべきデータ項目」と「冷凍・冷蔵の温度ログを自動記録し、監査資料まで出す方法」も参考にしてください。

PT に相談するなら

どの観点から読ませるか、どこをマスキングするかを含めて設計する場合は、PT WORKS（30万円〜、税込33万円〜）で1テーマを約5時間で簡易実装まで進められます。複数の観点や既存システムとの連携を含む本開発は、PT BUILDで個別見積になります。まずは自社の日報やお問い合わせの量と種類を整理したい場合は、概算見積から合うプランを確認してください。

料金は参加人数、テーマ数、事前調査の量、開発範囲で変わります。出張を伴う場合の交通費・宿泊費は実費です。