社内のメモ、問い合わせ、議事録を生成AIへ渡すとき、多くの人は「この文章を貼り付けて大丈夫か」と最後に確認します。
しかし、確認がコピー・貼り付けの直前に1回あるだけでは、忙しい日ほど抜けます。名前や電話番号を見落とすこともあれば、個人を特定できる複数の情報を残したまま、要約や分類を依頼してしまうこともあります。
必要なのは、AIの性能比較より先に、入力する文章を整える手順です。この記事では、情報クリーニングを「注意喚起」ではなく、検出・置換・意味確認・受入判定まで含む小さな業務フローとして設計します。
1. リスクはAIの回答より前に始まっている
生成AIの回答が正しいかを確認しても、入力した文章に不要な情報が含まれていれば、確認の出発点から危うくなります。
たとえば、問い合わせの要約を作るだけでも、本文には次のような情報が混ざる可能性があります。
- 顧客や担当者の氏名、メールアドレス、電話番号
- 注文番号、会員番号、契約番号など、個人や取引を追跡できる識別子
- 会社名、案件名、施設名、担当部署など、組み合わせると対象を絞れる情報
- 未公開の価格、契約条件、トラブルの経緯、社内の評価や判断
大切なのは、これらをすべて危険と決めつけることではありません。業務上その情報が必要なのか、AIへ渡す必要があるのか、入力先の環境へ渡してよいのかを分けることです。
2. 入力データを3つの扱いに分ける
まず、文章を次の3層に分けます。
そのまま扱える情報
公開済みの説明、一般化された手順、架空データ、すでに匿名化されたサンプルなどです。ただし、公開済みかどうかを担当者が迷わないよう、社内の正本を決めておきます。
置き換えて使う情報
実際の問い合わせや議事録のように、業務上の文脈は必要だが、固有名詞や直接の識別子までは不要な情報です。氏名を役割名へ、会社名を取引先Aへ、具体的な番号を識別子Xへ置き換えます。
そのまま入力しない情報
本人確認、認証情報、秘密鍵、未公開の契約原本、詳細な健康情報、採用判断の原資料など、入力の必要性や扱いの承認が明確でない情報です。匿名化が難しいなら、AIへの入力対象から外し、人が別の方法で処理します。
この分類の目的は、担当者に毎回難しい判断をさせることではありません。よくある業務ごとに、どの情報をどの層に置くかを先に決めることです。
3. 匿名化は名前の置換だけでは足りない
名前を削っても、文章の中に対象を推測できる手がかりが残る場合があります。
「先週、駅前の店舗で、特定の商品を、特定の担当者が扱った」というように、場所、時期、商品、役割が組み合わさると、社内の人には誰の話か分かるかもしれません。
そこで、検出対象を次の3段階で見ます。
- 直接識別子: 氏名、メール、電話番号、住所、番号類
- 業務識別子: 案件名、顧客名、施設名、担当者名、固有のURLやファイル名
- 組み合わせ情報: 日付、地域、金額、商品、役割、出来事の順序など、重なると対象を絞れる情報
すべてを無差別に削ると、AIが処理すべき意味まで消えます。残すべき業務情報と、消すべき識別情報を分けて扱うことがポイントです。
4. 6段階の入力前クリーニング
最初から全社の文書を対象にせず、1つの業務の入力前処理を次の順番で作ります。
- 対象を決める: 問い合わせ要約、議事録整理など、AIへ渡す文章の種類を1つに限定する
- 検出する: 氏名、連絡先、番号、固有名詞、未公開情報などの候補に印を付ける
- 置換する: 役割名、取引先A、案件B、日付の範囲など、意味を残せる表現へ変える
- 対応表を分ける: 元の値と置換後の値を結びつける情報が必要なら、AIへ渡す文章とは別に管理する
- 意味を確認する: 登場人物の関係、時系列、条件、数量など、依頼に必要な情報が壊れていないかを見る
- 受入判定をする: 直接識別子が残っていないか、入力先の環境が許可されているか、確認者が明確かを記録する
この工程を、単なるチェックリストではなく、貼り付ける文章を通過させる前処理として扱います。検出だけを自動化しても、置換漏れや意味の欠落を人が確認しなければ、業務では使いにくいからです。
5. 意味を残す匿名化にする
匿名化の失敗には、情報を残しすぎる失敗と、消しすぎる失敗があります。
たとえば「担当者Aが顧客Bへ返金条件を説明した」という文章から、人物と顧客をすべて削ると、誰が誰へ何をしたか分からなくなります。一方で、実名や連絡先を残す必要はありません。
置き換え後も、次の構造は残します。
- 誰が、どの役割で関わったか
- 何が起きたか、どの順番で起きたか
- 判断や回答に必要な条件は何か
- 数値を正確に残す必要があるか、範囲で足りるか
AIに求める処理が「事実の抽出」なら関係性と時系列を優先し、「文章の分類」ならカテゴリと判断条件を優先します。匿名化の方法は、AIへ依頼する仕事に合わせて決めます。
6. ローカル処理を選ぶときの確認点
入力前の置換を端末内で行う設計は、外部へ送る前の段階を分けたい場合の選択肢になります。ただし、「ローカルで動く」と書かれているだけで安全性が確定するわけではありません。
少なくとも次を確認します。
- クリーニング処理の前後で、どの通信が発生するか
- 元の文章、置換後の文章、対応表、一時ファイルがどこに保存されるか
- クリップボードへコピーした内容が残る期間と、他のアプリから読める範囲
- 実行ファイルや拡張機能を更新できる人、設定を変更できる人
- 検出・置換の結果を誰が確認し、失敗時にどの手順へ戻るか
機能の名前ではなく、データがどこを通り、どこに残り、誰が操作できるかを確認するのが実務上の要点です。
7. 最初の試行は「1業務・1種類の文章」にする
匿名化のルールをいきなり全社へ適用すると、例外が増えて運用が止まります。最初は、問い合わせ要約や議事録のように、入力形式と出力の良し悪しを確認しやすい業務を1つ選びます。
試行前に、次の項目を1枚へ書きます。
- AIへ渡す前の入力例と、渡した後の匿名化例
- 必ず残す情報と、必ず削る情報
- 置換後も保つ関係性・時系列・条件
- 受入判定をする担当者
- 失敗したときにAIへ渡さず、人の作業へ戻す方法
試行後は、検出漏れ、削りすぎ、置換の揺れ、確認にかかった時間を記録します。精度や削減率を最初から約束するのではなく、次のルールを直す材料として使います。
8. 「入力前に止められる」ことを受入条件にする
情報クリーニングの成果は、AIが文章をうまく要約したことだけでは測れません。入力前に問題を見つけ、必要なら処理を止められたかが重要です。
最低限、次の受入条件を置きます。
- 直接識別子や認証情報が残っていない
- 置換後もAIが処理するための意味が残っている
- 入力してよい環境と、入力してはいけない環境が区別されている
- 元データと置換後データの保存先・保持期間・閲覧者が決まっている
- 検出に迷ったとき、人へ戻す手順がある
この条件を満たさない文章は、AIの回答が良さそうでも業務へ進めません。自動化を止める条件を先に定めると、担当者が「便利だからそのまま使う」流れを抑えやすくなります。
Optiensの見方
AI導入の相談では、使いたいモデルやツールから話が始まりがちです。実務では、その前に「何を入力するのか」「誰が確認するのか」「問題があればどこへ戻るのか」を決める必要があります。
Optiensでは、AI活用診断（無料）で、フォーム入力をもとにAI活用を検討する業務候補と確認事項の入口を整理します。無料診断は個別の専門確認や構築作業を含みません。構築へ進む場合は、導入前スコープ整理で対象業務と範囲を固めます。
まとめ
生成AIへ渡す文章を安全に扱うには、最後に注意するだけでは不十分です。
- 入力データを、そのまま使う・置き換える・入力しないに分ける
- 名前だけでなく、組み合わせで対象を推測できる情報も確認する
- 検出、置換、意味確認、受入判定を一つの業務フローにする
- ローカル処理を選ぶ場合も、通信・保存・権限・更新を確認する
- 最初は1業務で試し、迷ったら人へ戻す
AIに何をさせるかを考える前に、AIへ何を渡してよいかを設計する。その順番が、便利さを業務へ定着させる土台になります。
関連: