AIに渡してよいデータの線引き

生成AIを業務で使い始めると、最初に起きる問題はほぼ決まっています。誰かが顧客からもらった資料をそのまま貼り付けて要約させる、という場面です。悪意はありません。速く仕事を終わらせたかっただけです。

この問題を「情報漏洩に気をつけましょう」という呼びかけで防ごうとしても、まず続きません。気をつけるべき対象が人によって違うからです。必要なのは、データを区分し、区分ごとに扱いを決めておくことです。

区分で線を引く

危険度で考えると判断が属人的になります。「これは大丈夫そう」という感覚は人によってずれるためです。データがどこから来たかで区分すると、現場の判断が揃います。

この表は、そのまま社内に配れる粒度で作るのが要点です。「機密情報」とだけ書かれた規程は読まれません。自社で実際に扱っている資料の名前が書かれていれば、その場で判断できます。

想定例として、業務委託でデザイナーに入ってもらっているチームを考えます。その人が受け取る資料には、取引先から預かったものが混ざっています。区分表があれば「この資料は取引先由来だから貼らない」と本人が判断できますが、なければ社内資料と区別がつきません。区分は社員だけでなく、業務委託や副業のメンバーに渡すことを前提に書いてください。

「渡してよい」を先に決める

禁止事項だけを並べたルールは、抜け道を探されます。読んだ人が最初に知りたいのは「では何なら使えるのか」だからです。

具体的に書けるものから並べます。

• 公開しているサービス説明文の書き直し、誤字の確認
• 自分で書いた会議メモの整形と要約
• 一般的な技術的質問（特定の顧客名や社内固有の構成を含まないもの）
• ダミーデータに置き換えた状態での不具合の相談
• 社外に出す文章のトーンの調整

この一覧が具体的であるほど、「載っていないものは確認する」という運用が成立します。逆に「業務効率化の範囲で利用可」といった抽象的な許可の書き方をすると、何でも入るように読めてしまい、線引きとして機能しません。

匿名化は手順まで決める

「匿名化して渡す」と決めても、手順がなければ実行されません。具体的には次のような作業になります。

氏名・住所・電話番号・メールアドレスといった直接の識別子を削除するのは出発点です。問題はその先で、所属と役職と日付の組み合わせ、社内でしか使わない管理番号、自由記述欄に書かれた固有名詞などが残ります。不具合の調査でログを貼るときは、ユーザーIDやセッションIDが本番の値のまま含まれていないかを確認します。

現実的なのは、ダミーデータへの置き換えを標準にすることです。構造だけ同じで中身が架空のデータを用意しておけば、開発や検証の相談は毎回そのデータで行えます。置き換えの手間を最初に一度払うほうが、毎回判断するより結果的に軽くなります。

学習利用の設定は組織側で押さえる

入力した内容がモデルの改善に使われるかどうかは、サービスと契約形態によって異なります。ここで確認すべきことは三つです。

第一に、組織アカウント（法人向けプラン）で契約し、管理画面で設定を一括適用することです。個人が各自の設定画面で無効化する運用は、新しく入った人の設定漏れで崩れます。

第二に、無料プランや個人契約での業務利用を把握することです。会社として法人契約を結んでいても、手元の無料アカウントで作業されていれば意味がありません。経費精算やアカウント一覧から実態を確認します。

第三に、API経由での利用と、ブラウザ上のチャット画面での利用で条件が異なる場合があることです。自社サービスに組み込む場合は前者、社内で使う場合は後者になることが多く、それぞれ確認が必要です。規約の具体的な読み方は別記事で整理しています。

プロダクトに組み込むときの線引き

社内利用と、自社サービスの機能としてAIを組み込む場合とでは、判断の前提が変わります。後者では、入力されるデータの持ち主は自社ではなく利用者だからです。

このとき決めることは次の点です。利用者のどのデータをAIサービスに送るのか。送ることを利用規約とプライバシーポリシーに書いてあるか。送らない選択肢を利用者に用意するか。送ったデータが外部サービス側にどれだけ残るか。

設計上は、送る前に絞り込むのが基本です。会話の全文ではなく必要な範囲だけを送る、自由記述欄はそのまま送らず必要な項目を抽出してから送る、といった処理を挟むと、扱うリスクそのものが小さくなります。機能の要件より先にこの検討をしておくと、後から作り直す事態を避けられます。

私たちは既製のAIサービスを業務システムに組み込む立場で開発をしていますが、この検討で「その機能はAIを使わないほうがよい」という結論になることも珍しくありません。キーワード検索や単純な条件分岐で足りるなら、そのほうがデータを外に出さずに済み、費用も安定します。

線引きを保つために見直すこと

ルールは作った日から古くなります。半年に一度、次の点を確認してください。使っているAIサービスが増えていないか。規約や設定の既定値が変わっていないか。区分表に載っていない種類のデータを扱い始めていないか。判断に迷って相談が来た事例を、区分表に追記できないか。

とくに相談事例の追記は効果が大きい作業です。誰かが一度迷った論点は、他の人も迷います。迷った事実を記録して区分表に戻すことで、ルールが現場の実態に近づいていきます。

データの線引きは、技術ではなく運用の問題です。区分を決め、渡してよいものを具体的に示し、設定を組織側で押さえ、迷った事例を戻す。この四つが回っていれば、細かい手順が多少不揃いでも実務は守られます。AI活用開発やWebシステム開発で、データの扱いを含めた設計から相談したい方はお問い合わせください。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。