先に要点
生成AIを使うと、議事録の要約、メールの下書き、契約書の論点整理、コードレビュー、問い合わせ文面の分類などがかなり楽になります。
ただ、クライアント案件で使うときに迷うのが、クライアント情報をAIに入れてよいのか という問題です。
結論から言うと、クライアント情報は、許可・契約・入力範囲が確認できない限り、そのまま生成AIへ入れないのが基本です。
AIだから特別に危険というより、外部サービスへ情報を渡すこと、ログや学習利用の可能性があること、第三者提供や委託の整理が絡むことが問題になります。
この記事では、2026年4月19日時点で、個人情報保護委員会の生成AI注意喚起、総務省・経済産業省の AI事業者ガイドライン第1.2版、経済産業省の AI契約チェックリスト、IPAの AIセキュリティ情報を確認しながら、受託開発・制作・コンサル・運用支援で使いやすい判断基準を整理します。
法律判断は契約や業種で変わるため、実際の契約条項は弁護士やクライアントの法務・情シスと確認してください。
まず結論: そのまま入力してよい情報はかなり少ない
生成AIに入力してもよい情報は、思ったより狭いです。
特に、クライアントから預かった資料は、自社の情報よりも慎重に扱う必要があります。
| 情報の種類 | 例 | 生成AIへの入力判断 |
|---|---|---|
| 公開情報 | 公開済みWebページ、プレスリリース、公開ドキュメント | 比較的扱いやすい。ただし誤引用や著作権には注意 |
| 社内情報 | 社内手順、社内FAQ、業務メモ | 組織のAI利用ルールとサービス条件を確認する |
| クライアント機密 | 未公開仕様、見積、契約、事業計画、ソースコード | 原則そのまま入力しない。契約と許可が必要 |
| 個人情報・PII | 氏名、メールアドレス、問い合わせ履歴、顧客データ | 利用目的、本人同意、第三者提供・委託の整理を確認 |
| 認証情報 | APIキー、パスワード、秘密鍵、アクセストークン | 入力しない。漏えい時は即時ローテーション対象 |
「要約だけだから」「一瞬貼るだけだから」「有名なAIだから」という理由では足りません。
入力した内容がどこへ送られ、どの目的で処理され、どのくらい保持され、学習に使われるのかを確認する必要があります。
判断の順番
実務では、いきなり利用規約を読み始めるより、次の順番で見ると判断しやすいです。
- 入力したい情報の種類を分ける
- クライアントとの契約で外部サービス利用が許されているか確認する
- 使うAIサービスの契約プラン、学習利用、保持期間、削除、管理者設定を見る
- そのまま入力せずに、マスキングや要約で目的を達成できないか考える
- 誰が承認し、どのログを残し、問題が起きたとき誰に報告するか決める
この5つを通らない場合は、入力しない方が安全です。
クライアント案件では、少し面倒でも「入力してよい情報」「入力してはいけない情報」「承認すれば入力できる情報」を分ける方が、あとで説明できます。
契約で最初に見るポイント
クライアント情報を生成AIに入れる前に、まず見るべきはAIの機能ではなく契約です。
確認したいのは、主に次の項目です。
| 確認項目 | 見る理由 | 危ない例 |
|---|---|---|
| 秘密保持契約 | 第三者サービスへの入力が秘密情報の開示に当たらないかを見る | NDAで再委託や外部提供が制限されているのにAIへ貼る |
| 業務委託契約 | 作業方法、再委託、外部サービス利用の制限を見る | 外部委託禁止なのに個人契約のAIサービスを使う |
| 個人情報の取扱い | 個人データを渡す場合に委託か第三者提供かを整理する | 問い合わせCSVをそのまま無料AIサービスへ入力する |
| 成果物・入力データの権利 | プロンプト、入力データ、出力結果の利用条件を見る | クライアント資料をAI提供者の改善目的に使われる |
| ログ・監査 | 誰が何を入力したか後から追えるかを見る | 個人アカウント利用で入力履歴を組織が確認できない |
経済産業省の「AIの利用・開発に関する契約チェックリスト」では、AI関連サービスへ提供する情報について、インプットの特定、提供、使用・利用、外部提供、権利帰属、保持期間・消去、管理・セキュリティなどを確認する考え方が示されています。
ここでいうインプットには、プロンプトや学習用データなどが含まれます。
つまり、AIに入力する文章は、単なる作業メモではなく、契約上の「提供情報」になる可能性があります。
クライアントから預かった情報を使うなら、まずその情報が契約でどう扱われているかを見ます。
個人情報が入る場合はさらに慎重に見る
個人情報保護委員会は、生成AIサービスに個人情報を含むプロンプトを入力する場合、特定された利用目的を達成するために必要な範囲内か確認する必要があると注意喚起しています。
また、個人データを含むプロンプトが応答出力以外の目的で取り扱われる場合、個人情報保護法に違反する可能性があるため、AIサービス提供者が機械学習に利用しないこと等を十分確認するよう示しています。
実務では、次のような情報はPIIや個人データに該当する可能性があるため注意します。
- 顧客の氏名、メールアドレス、電話番号
- 問い合わせ履歴、チャットログ、通話メモ
- 採用応募者の職務経歴書、面接メモ
- 医療、金融、購買、相談内容などのセンシティブな情報
- ログに含まれるIPアドレスやユーザーID
個人情報を扱うときは、AIに入れて便利か ではなく、その利用目的で、そのサービスに、その情報を渡してよいか を見ます。
マスキングできるなら、先にマスキングします。個人を識別できる形である必要がないなら、その形で入力しない方が安全です。
自社が保有する顧客情報を AI に読ませる場合の線引きや、要約・分類・問い合わせ対応補助のような用途ごとの判断を見たい場合は、顧客情報をAIに読み取らせていいのか？ もあわせてどうぞ。
機密情報は「顧客名を消せばOK」ではない
クライアント資料をAIに入れるとき、「社名を消したから大丈夫」と考えがちです。
でも、機密性は固有名詞だけで決まりません。
たとえば、次のような情報は、社名を伏せても機密に近いことがあります。
こういう情報は、断片だけでも推測材料になります。
クライアント名を消しても、業界、地域、機能、取引先、文体、固有の課題が残れば、関係者には分かることがあります。
この考え方は、データ分類と近いです。
「公開」「社内」「機密」「個人情報」「秘匿性の高い技術情報」のように分け、AIに入力できる範囲を分類ごとに決めます。
新規サービスのアイデア出しで使うAIモデルの選び方は、サービスアイデア出しに強いAIモデルはどれか：OpenAI・Claude・Gemini・Grok・Mistralを中立比較でも整理しています。
入力前の確認チェックリスト
実際にAIへ入力する前に、最低限このくらいは確認したいです。
| 確認 | 見るポイント |
|---|---|
| 目的 | 要約、分類、翻訳、コードレビューなど、入力目的が明確か |
| 必要最小限 | 全文ではなく、必要な箇所だけで目的を達成できないか |
| マスキング | 氏名、社名、金額、ID、URL、認証情報を伏せられるか |
| サービス条件 | 学習利用、保持期間、削除、第三者提供、管理者制御を確認したか |
| 契約許可 | クライアント契約、NDA、再委託条項、個人情報条項に反しないか |
| 承認 | 担当者判断でよいのか、クライアントや社内責任者の承認が必要か |
| ログ | 誰が、いつ、何の目的で使ったかを後から追えるか |
迷ったら入力しない、では業務が止まることもあります。
なので実務では、禁止だけでなく「どうすれば使えるか」も決めておくのが大事です。
マスキングして使うときの考え方
生成AIを完全に禁止するより、マスキングして使う方が現実的な場面もあります。
ただし、マスキングは「置換すれば安全」ではありません。
良いマスキングは、目的を保ちながら、識別性と機密性を下げることです。
悪い例:
株式会社サンプル商事の山田太郎様から、月額120万円の保守契約についてクレームがありました。
改善例:
ある法人顧客の担当者から、月額保守契約の対応範囲についてクレームがありました。
論点を「契約範囲」「対応履歴」「次回説明事項」に分けて整理してください。
この例では、社名、氏名、具体金額を落としつつ、AIにやってほしい整理の目的は残しています。
さらに安全にするなら、実際の契約文や問い合わせ全文は入れず、自分で抽象化したメモだけを入力します。
一方で、脆弱性診断結果、未公開のソースコード、障害原因、顧客リストのように、マスキングしてもリスクが高い情報はあります。
その場合は、クライアント契約の範囲内で使える専用環境、社内承認済みのAI、またはローカル・閉域の仕組みを検討します。
ログ管理で残すべきもの、残すと危ないもの
ログ管理は重要ですが、プロンプト全文を全部保存すれば安心 ではありません。
全文ログには、機密情報や個人情報がそのまま残る可能性があります。
生成AIの利用ログでは、次のように分けて考えると扱いやすいです。
| ログ項目 | 残す目的 | 注意点 |
|---|---|---|
| 利用者 | 誰が使ったかを追う | 個人アカウントではなく業務アカウントに寄せる |
| 日時 | インシデント時の時系列確認 | タイムゾーンと保存期間を揃える |
| 利用目的 | 要約、翻訳、分類などの用途を追う | 細かすぎる本文を残さず分類で足りる場合がある |
| 情報分類 | 公開情報、社内情報、機密、個人情報などを追う | 利用者の自己申告だけに頼りすぎない |
| プロンプト全文 | 品質確認や事故調査 | 残す場合はアクセス制御、保存期間、マスキングが必要 |
| 出力結果 | 成果物への反映確認 | 誤情報や機密の再出力が含まれる場合がある |
ログは、あとから説明するための証跡です。
ただし、ログ自体が情報漏えいの原因になることもあります。
そのため、監査ログとして残す情報と、本文ログとして残す情報を分けます。
多くのケースでは、まずは「誰が、いつ、どの案件で、何の目的で、どの分類の情報を使ったか」を残し、プロンプト全文は高リスク用途だけ限定的に保存する方が現実的です。
DLPと承認フローを組み合わせる
人の注意だけで運用すると、忙しいときに崩れます。
可能ならDLPや入力チェックを使い、危ない情報を検知したら警告やブロックを出します。
たとえば、次のようなルールです。
- メールアドレスや電話番号が含まれる場合は警告する
- APIキーらしい文字列が含まれる場合はブロックする
契約書障害報告脆弱性などの語がある場合は承認を求める- クライアント名や案件コードが含まれる場合は入力前に分類を選ばせる
- 個人アカウントからの利用を禁止し、SSO配下の業務アカウントに寄せる
ここで大事なのは、DLPを入れたから完璧、ではないことです。
DLPは漏れを減らす仕組みであって、契約判断や情報分類の代わりにはなりません。ルール、教育、承認、ログをセットで設計します。
個人アカウント利用が危ない理由
クライアント案件で特に避けたいのが、個人契約の生成AIアカウントへクライアント情報を入力することです。
個人アカウントでは、次の問題が起きやすいです。
- 組織の管理者が利用状況を確認できない
- 退職・契約終了後も履歴が個人側に残る
- プランや設定によって学習利用・保持条件が違う
- クライアントから見て、誰が情報を管理しているか分からない
- インシデント時にログ提出や削除確認が難しい
IPAの「情報セキュリティ10大脅威2026」でも、業務で生成AIへデータをコピー＆ペーストする利用や、組織に管理されていないアカウント利用による情報漏えいリスクが取り上げられています。
また、IPA/AISIの「AI利用者のためのセキュリティ豆知識」でも、クラウドAIに営業秘密を教えないことが対策項目として示されています。
実務では、個人アカウントで便利に使うより、業務アカウント、管理者設定、ログ、保存期間、学習利用の制御を確認できる環境へ寄せる方が安全です。
これはシャドーAI対策でもあります。
クライアントへ確認するときの文面例
クライアント情報を使って生成AIを利用したい場合は、曖昧に「AIを使ってもいいですか」と聞くより、用途と範囲を分けて確認した方が通りやすいです。
本案件の作業効率化のため、生成AIを補助的に利用したいと考えています。
利用目的は、公開情報の整理、文章のたたき台作成、一般的な技術調査に限定します。
貴社の未公開資料、個人情報、認証情報、契約条件、ソースコード、障害・脆弱性情報は、
事前承認なく外部AIサービスへ入力しません。
機密情報を含む資料をAIで処理する必要が生じた場合は、
利用するサービス名、入力する情報の範囲、学習利用の有無、保持期間、ログ管理、削除方法を明示し、
事前に承認をいただいてから実施します。
この文面のポイントは、利用範囲を狭く始めることです。
いきなり「AI利用を包括的に許可してください」ではなく、公開情報や一般的な調査から始め、機密情報は別承認にします。
AIツール利用料や費用負担も一緒に整理したい場合は、AIツール利用料はクライアントに請求できる？経費計上と見積書の考え方 もつながります。
入力してよい例、避けるべき例
最後に、実務で迷いやすい例を分けます。
| 場面 | 比較的安全に寄せやすい使い方 | 避けるべき使い方 |
|---|---|---|
| 議事録整理 | 固有名詞や金額を落とした要点メモを整理させる | 録音文字起こし全文を個人向けAIへ貼る |
| 問い合わせ対応 | 個人情報を除いた相談パターンを分類させる | 顧客名、連絡先、相談履歴をそのまま入力する |
| コードレビュー | 公開可能なサンプルコードや抽象化したエラーを相談する | 未公開リポジトリ、APIキー、DB接続情報を貼る |
| 契約書確認 | 一般的な条項の意味を、伏字化した短い抜粋で確認する | 契約書全文や交渉中の条件をそのまま入力する |
| 障害対応 | エラー種別や一般化した構成をもとに切り分け案を出す | 本番ログ、IP、ユーザーID、脆弱性情報を丸ごと貼る |
生成AIは、抽象化した情報でもかなり役に立ちます。 むしろ、機密情報をそのまま貼らずに済むよう、質問の作り方を工夫する力が大事になります。
生成AIへのクライアントデータ入力に関するよくある質問
Q. 個人情報を生成AIに入力するのは違法ですか？
A. 個人情報保護法では、第三者提供 に該当する可能性があります。本人の同意なしに ChatGPT などへ氏名・住所・連絡先を貼り付けると違反のリスクがあります。Enterprise プランで 外部送信契約 を結んでも、入力前の同意取得が必要なケースは多くあります。
Q. Enterprise プランなら何を入力しても安全ですか？
A. 違います。学習に使われない、保存期間が決まっている、SOC2 認証あり、などの保証はありますが、契約上の禁止事項 や 業界別の規制(医療、金融、政府案件) は別途確認が必要です。
Q. クライアント契約に AI 利用条項がない場合は？
A. 黙示で禁止と解釈される可能性があります。新規プロジェクト前に AI 利用ポリシーを契約書に明示する、または 事前に書面で AI 利用許可を得る のが安全です。
Q. ローカル LLM(Ollama、LM Studio など)なら問題ないですか？
A. データが外部に出ない点で安全性は高いですが、社内ネットワーク内でのデータ取扱い、ログ管理、退職時のアクセス遮断などのルールは別途必要です。オフライン = 完全安全 ではありません。
Q. 抽象化したデータならどんなものを入れて良いですか？
A. 特定不能な汎用例(架空の名前、ダミーの数字、業界名のみ)、エラーメッセージから固有情報を除いたもの、構造のみのテーブルスキーマ、コード片(機密文字列を除く)、などです。誰が見ても具体的な誰か特定できない がボーダーラインです。
Q. AI 利用ログはどれくらい残すべきですか？
A. 業務利用なら最低6か月〜1年、医療・金融など規制業界では3〜7年が一般的です。誰がいつ何を入力したか の証跡を残せる Enterprise プランや、社内プロキシ経由の利用が望ましいです。
Q. AI に書かせたコードを納品しても良いですか？
A. 多くの場合可能ですが、契約条件によります。AI を使った成果物の権利、ライセンス互換性、著作権の帰属 を契約で明示するのが安全です。OSS と混ぜる場合は特に確認が必要です。
まとめ
生成AIにクライアント情報を入力してよいかは、便利だから では決められません。
契約、情報分類、個人情報、サービス規約、学習利用、保持期間、ログ、承認フローを見て、入力してよい範囲を決めます。
基本は、クライアント機密、個人情報、認証情報、未公開ソースコード、障害・脆弱性情報をそのまま入力しないことです。
使うなら、公開情報や抽象化したメモから始め、必要に応じてマスキング、承認、専用環境、業務アカウント、監査ログを組み合わせます。
生成AIを仕事で使うこと自体は、もう特別な話ではありません。
だからこそ、個人の便利ツールとしてではなく、クライアント情報を扱う業務プロセスとして設計する必要があります。入力前に線引きを決めておくことが、AI活用を止めないための一番現実的な安全策です。
参考リンク
- 個人情報保護委員会: 生成AIサービスの利用に関する注意喚起等
- 個人情報保護委員会: 生成AIサービスの利用に関する注意喚起
- 経済産業省・総務省: AI事業者ガイドライン（第1.2版）
- 経済産業省: AIの利用・開発に関する契約チェックリスト
- IPA/AISI: AI利用者のためのセキュリティ豆知識
- IPA: 情報セキュリティ10大脅威2026 組織編