生成AIにクライアント情報を入力してよい？契約・機密情報・ログ管理

先に要点

クライアント情報を生成AIへ入力してよいかは、便利かどうかではなく 契約・情報分類・サービス条件 で判断します。
機密情報、個人情報、認証情報、未公開資料は、原則としてそのまま入力しない方が安全です。
入力する場合は、目的、範囲、学習利用の有無、保持期間、削除、ログ、承認者を確認します。
ログ管理は「何でも全文保存」ではなく、後から追える情報と、残すと危ない情報を分けて設計します。

生成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に入れて便利か ではなく、その利用目的で、そのサービスに、その情報を渡してよいか を見ます。
マスキングできるなら、先にマスキングします。個人を識別できる形である必要がないなら、その形で入力しない方が安全です。

機密情報は「顧客名を消せばOK」ではない

クライアント資料をAIに入れるとき、「社名を消したから大丈夫」と考えがちです。
でも、機密性は固有名詞だけで決まりません。

たとえば、次のような情報は、社名を伏せても機密に近いことがあります。

未公開の新サービス計画
売上、利益率、予算、見積原価
システム構成図、脆弱性診断結果
ソースコード、DB設計、API仕様
障害報告書、インシデント報告書
契約条件、交渉中の価格、提案資料

こういう情報は、断片だけでも推測材料になります。
クライアント名を消しても、業界、地域、機能、取引先、文体、固有の課題が残れば、関係者には分かることがあります。

この考え方は、データ分類と近いです。
「公開」「社内」「機密」「個人情報」「秘匿性の高い技術情報」のように分け、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にクライアント情報を入力してよいかは、便利だから では決められません。
契約、情報分類、個人情報、サービス規約、学習利用、保持期間、ログ、承認フローを見て、入力してよい範囲を決めます。

基本は、クライアント機密、個人情報、認証情報、未公開ソースコード、障害・脆弱性情報をそのまま入力しないことです。
使うなら、公開情報や抽象化したメモから始め、必要に応じてマスキング、承認、専用環境、業務アカウント、監査ログを組み合わせます。

生成AIを仕事で使うこと自体は、もう特別な話ではありません。
だからこそ、個人の便利ツールとしてではなく、クライアント情報を扱う業務プロセスとして設計する必要があります。入力前に線引きを決めておくことが、AI活用を止めないための一番現実的な安全策です。

生成AIにクライアント情報を入力してよい？機密情報・契約・ログ管理の実務判断