営業部門から「この見積書をAIに要約させたい」と相談を受けたら、どう答えるでしょうか。取引先名、担当者の電話番号、単価の交渉履歴。エクセルの見積書1枚にも、社外に出してはいけない情報が詰まっています。この記事は、業務システムを保守しながら生成AIの導入要望に応えるエンジニア・PMの方に向けて、契約書やExcel台帳をAIアシスタントに渡す際の「仮名化」という技術的アプローチを整理します。
AIアシスタントの導入が進む現場では、数週間のうちに似た依頼が繰り返し出てきます。「この契約書を要約して」「この台帳を地域別に集計して」「このメールスレッドへの返信案を作って」。いずれも顧客名、メールアドレス、電話番号、IBAN（国際銀行口座番号）、給与、交渉済みの価格といった、社外の第三者に渡してはいけないデータを含んでいます。請求書1枚で数十人分の個人情報と自社の価格体系が同時に露出することも珍しくありません。
GDPR（EU一般データ保護規則）の観点では、こうした文書を外部のAI APIに送る行為は「第三者による個人データの処理」に当たり、EU域外への移転を伴うケースもあります。営業秘密の保護という観点でも、取引条件を自社の管理外のインフラに渡すことになります。かといって「AIを使うな」という結論は、生産性の差が大きすぎて現実的ではありません。禁止すれば、従業員はチャット画面に文書をそのまま貼り付けてしまうだけです。管理されていない利用のほうが、管理された利用よりもリスクは大きくなります。
なぜ単純な墨消しでは業務に使えないのか
最初に思いつく対策は「個人名や金額を黒塗り（redaction）にする」ことです。しかしこれは業務用途では機能しません。名前をすべて████に置き換えると、AIは契約の当事者が誰と誰なのか区別できなくなります。金額を[REDACTED]にすると、「地域別に合計を出して」という依頼自体が意味を失います。
ここで必要になるのが仮名化（pseudonymization）という技術です。マスキングや墨消しと違い、値を消すのではなく「同じ形式の別の値」に置き換えます。たとえば「山田太郎」という名前は別の人名っぽい文字列に、社内メールアドレスは別の正しい形式のメールアドレスに、IBANは桁数と検査文字が正しい別のIBANに変換されます。日付は一定のオフセット（ずらし幅）だけシフトされます。
重要なのは、この対応関係が全体で一貫していることです。同じ「山田太郎」は文書のどこに出てきても同じ仮名に置き換わります。だからこそAIは「同じ人物が3つのシートに登場している」という関係性を追跡できます。この対応表（マッピングファイル）は手元の環境から一切外に出さず、AIからの回答が返ってきた時点で逆変換して実名に戻します。長い一致を優先して置換することで、「山田太郎」のエントリが「山田太郎子」を中途半端に巻き込んでしまうような誤爆も防げます。
検出の仕組みは3段階で組み立てる
業務文書から「守るべき値」をどう見つけるかは、1つの手法では取りこぼしが出ます。実務では3段階の検出を重ねる設計になっています。
1段目は、構造が決まっているパターンの検出です。メールアドレス、電話番号、IBAN、クレジットカード番号、日付などは正規表現やフォーマット検証で機械的に見つけられます。ここで見落としやすいのが、市販の検出ライブラリの多くがメールドメインを「パブリックサフィックスリスト」（.comや.jpなど正式なドメイン末尾の一覧）と照合する仕様になっている点です。その結果、[email protected] や [email protected] のような社内ドメインのアドレスを「無効」と判定して見逃してしまいます。しかし社内ドメインのアドレスこそ、自社のインフラ構成を推測されかねない情報です。対策として、ローカル部とドメインの形だけを検証してパブリックサフィックスの照合は行わない、緩めの検出ルールに調整する必要があります。
2段目は、構造を持たない値の検出です。人名、組織名、地名などは正規表現では捉えられないため、NER（固有表現抽出。文章中から人名や組織名などを機械学習で識別する技術）を使います。実装では、外部クラウドに何も送らないローカル環境で、PresidioとspaCyというオープンソースのライブラリを組み合わせるアプローチが取られています。表計算ファイルの断片に対してNERをかけると、「電話番号」という列見出し1語がなぜか人名として誤検出されるようなノイズも出ます。誤検出を除外するリストを後付けの微調整ではなく、最初から設計に組み込んでおく必要があります。
3段目は、検出後の全文スイープです。検出済みの値をすべてのテキスト断片に対して単語境界で再検索し、1段目・2段目で漏れた出現箇所を拾います。表計算ファイルのタイトルプロパティに埋め込まれた組織名や、セルのコメント欄に紛れ込んだ人名などが対象です。大文字小文字の表記ゆれにも対応し、「Acme Industries」を検出すれば見出しの「ACME INDUSTRIES」も同じ対応関係で処理されます。
数値の扱いは列によって意味が変わるため、専用のルールが用意されます。順序や比率を保ったまま値をぼかす「乗算スケーリング」（最大の顧客がどれかはAIにも分かる状態を保つ）など、業務での使い方に応じた変換方式を選べる設計です。
既存の対策との違いと業務システムでの位置づけ
これまで社内文書の秘匿化といえば、DLP（データ損失防止ツール）による送信ブロックや、権限管理による閲覧制限が中心でした。これらは「渡さない」ための仕組みです。仮名化はアプローチが異なり、「AIには渡すが、AIには実名を見せない」という第三の道になります。
既存のマスキング機能付きRPA（業務自動化ツール）やETL（データ変換基盤）の匿名化機能と比べると、仮名化は可逆性（元に戻せること）と一貫性（同一人物は常に同じ仮名になること）を両立させている点が異なります。単純なマスキングは不可逆で、AIの回答から実名に戻す工程を想定していません。この違いが、「AIに要約や集計をさせて、結果は実名入りで受け取りたい」という業務要求に応えられるかどうかの分かれ目になります。
日本の現場でも、個人情報保護法上の第三者提供や委託の整理、金融・医療業界の業界ガイドラインでのマスキング要件と照らし合わせる際に、この「可逆的な仮名化」という考え方は参考になります。特にオンプレミスのAI基盤や、社内ネットワークに閉じたLLM（大規模言語モデル）ゲートウェイを検討している組織では、仮名化処理をゲートウェイの前段に挟む構成が現実的な選択肢になります。
今日、自社の環境で確認できること
実際に導入を検討する前に、次の点を社内で確認しておくと判断がしやすくなります。
- 現在AIアシスタントに渡している文書の種類を棚卸しする（契約書、見積書、人事メール、顧客台帳など）
- 各文書に含まれる識別子の種類を洗い出す（氏名、メール、電話番号、IBAN、社内コードネームなど）
- 使っているAI連携基盤（社内チャットボット、RPA、LLM APIゲートウェイなど）が、送信前にテキスト変換を挟めるアーキテクチャになっているか確認する
- 社内ドメインのメールアドレスやオンプレミス用語が、検出ルールの対象から漏れていないか確認する
- 復元処理（仮名から実名への逆変換）が必要な業務フローかどうかを整理する。要約だけで十分なら仮名のままでよく、契約書の差し戻しのように実名復元が必須なフローもある
既存のマスキングツールやDLP製品の設定画面を開いて、可逆マッピングをローカルに保持できるか、NERベースの検出に対応しているかを確認するところから始めるのが現実的な一歩です。多くの製品はクラウド型のマスキングAPIを前提にしているため、「マッピングファイルが自社の管理下から一切出ない」構成になっているかは、契約前に必ず確認する価値があります。
まとめ
業務文書をAIに渡す際の課題は、禁止でも野放しでも解決しません。仮名化という「同じ形式の別の値に置き換え、必要なときだけ正確に戻す」仕組みを理解しておくことが、既存システムへの組み込みを検討する第一歩になります。
社内で確認すべきは、文書の棚卸し、識別子の種類の洗い出し、AI連携基盤が送信前処理を挟める構成かどうかの3点です。仮名化ツールを評価する際は、マッピングファイルの保管場所と、社内ドメインのような非標準データへの対応状況を必ず確認してください。ここまで整理できれば、AI導入の可否を「禁止するか放置するか」の二択ではなく、具体的な設計判断として進められる状態になります。