AIに渡す情報を絞るとき、何を確かめたか。

個人情報保護法を守る。それはプロダクトを運営する前提です。それでも、注文IDをログに残すか、注文内容をAIに渡すかといった日常の判断で手が止まるたびに、小さな憤りが残ります。確認や設計の負担は目の前にあるのに、その工夫は機能や価格ほど外から見えません。

この記事では、自分のプロダクトでMCPを実装した経験から、遵守に必要な作業が小さな開発体制にどう響くかを考えます。制度について確認できることと、運営者として感じていることを分けながら書きます。

名前を返さない設計だけでは、足りなかった

この違和感を最初に強く覚えたのは、自分のプロダクトに初めてMCP（AIエージェントから外部のツールやデータを呼び出すための仕組み）の機能を作り、法的な扱いを自分で確認していたときでした。お客様に安心して使ってもらえるように、氏名、電話番号、住所などの情報は標準ではAIに返さず、必要なお客様だけがオプションで返せる設計にしていました。

ところが、注文IDや顧客IDのような内部の識別子も、条件次第で個人情報に当たると分かりました。IDだけを見ても誰か分からなくても、自社のデータベースと容易に突き合わせて本人にたどり着けるなら、氏名を外しただけでは「個人情報を返していない」と言えません。

名前や住所を返さない設計が無意味になったわけではありません。外に出る情報を減らす価値はあります。ただ、それだけで法的な扱いの確認が済むわけではなかった。ここを分けて考え、設計を見直すことになりました。

エラー監視ツールに注文IDを含める。分析基盤に顧客IDを送る。AIにサポート履歴を要約させる。実装そのものは短時間で済みそうでも、何のために、誰に、どの条件で情報を渡すのかを整理する必要があります。私が負担を感じたのは、この実装の手軽さと確認作業の重さの差でした。

IDがつながる便利さと、照合性の確認

個人情報の定義には、他の情報と容易に照合することで特定の個人を識別できる情報も含まれます。氏名がないことだけで判断せず、通常の業務で何と照合できるかを見る必要があります。また、「個人情報」と、個人情報データベース等を構成する「個人データ」は区別されます。個人情報保護委員会の通則編ガイドラインで、それぞれの定義を確認できます。

SaaSでは、注文、顧客、請求、サポート履歴を内部キーでつなぎます。自然人である注文者を容易に特定できるIDなら、自社での取扱いを個人情報として整理する必要があります。一方、どんなIDでも、誰が持っていても同じ扱いになると一括りにはできません。情報の組み合わせと、それを扱う主体を確認することになります。

ここで、個人情報に該当することと、利用や外部への提供が禁止されることは別です。該当性を確認したうえで、利用目的、委託や第三者提供に当たるか、安全管理などを整理する。私が目指すべきだったのは、何でも「個人情報ではない」形にすることではなく、必要な情報を適切な条件で扱う設計でした。

IDの削除やハッシュ化も、確認を不要にする万能な方法ではありません。対応表などから容易に本人へたどり着けるなら、その照合性は残ります。対応表をなくしても、本文や他の項目の組み合わせから本人が分かる場合があります。渡す項目を減らすことと、個人情報に該当しなくなることは分けて考える必要があります。

クラウドもAIも、契約と実際の扱いを見る

「クラウドには置けるのに、AIには渡せない」という単純な線引きではありません。

個人情報保護委員会のクラウドサービスに関するQ&Aは、提供事業者が個人データを取り扱うことになっているかどうかを判断基準にしています。契約で取り扱わない旨が定められ、適切なアクセス制御がある場合などには、個人データの提供に当たらないという整理です。「クラウドだから対象外」ではなく、その条件を確認する必要があります。

生成AIについては、公式の注意喚起が、利用目的の達成に必要な範囲内の入力であることや、個人データが応答結果の出力以外の目的で扱われないかを確認するよう求めています。学習に使わない条件は重要ですが、それだけですべての確認が済むわけではありません。

自分の用途で、提供先がどのようにデータを扱うのか。委託として整理できるのか、本人同意等が必要な提供なのか。国外の事業者への提供や再委託はどうなっているのか。サービスの名称や「モデルが読む」という比喩ではなく、契約と実際の処理に沿って判断することになります。MCPも接続の仕組みであって、これらの確認を省略できるものではありません。

この確認を、自分の構成に落とし込むところに時間がかかります。実データを使う前に確認する必要はありますが、架空データで機能を試すことまで止める必要はありません。試作と実データを扱う運用を分けることも、進め方の一つです。

先に払う工数と、見えにくい価値

私が感じる負担は、設計の見直し、サービスの規約確認、利用規約やプライバシーポリシーの整備、お客様への説明に使う時間です。扱うデータや用途によって作業量は変わりますが、利用者が少なくても必要になる確認はあります。小さな開発体制では、その時間が機能を作る時間と直接競合します。

一方、その工夫は画面だけでは伝わりません。注文IDをAIへ渡さないことや、提供先の取扱条件を調べたことは、新機能のようには見せにくい。調達時の確認や継続利用の信頼につながる価値はあっても、初期の売上や開発速度にすぐ返ってくるとは限らないと感じています。

確認を省けば、その時点で使う工数は減ります。そこから「守らない側が先に進めるのではないか」という憤りが生まれます。ただ、これは私の感じているインセンティブの問題で、違反する事業者が市場で有利だと実証した話ではありません。摘発の確率を比較したわけでもなく、小規模なら事故や信用失墜の影響が小さいとも言えません。

確実に発生する目先の作業と、後になって初めて見えるかもしれない信頼やリスク回避の価値。その時間差が、遵守のための作業を重く感じさせるのだと思います。

私は今、お客様向けに個人情報保護法のリスクを説明する資料を作って配っています。脅すように書けば導入をためらわせてしまう。軽く書けば、お客様が判断に必要な情報を得られない。お客様をリスクにさらさないために、できるだけ正確に書いています。こうした説明の工夫も、プロダクトの価値として伝わってほしいと思います。

2026年改正と、実装に落とすまでの距離

個人情報保護委員会の改正法に関するページによると、2026年の改正法は7月10日に成立し、7月17日に公布されました。この記事の執筆時点である9月11日には、施行に向けた政令・規則・ガイドライン等の整備が進められています。成立・公布と、各規定を実際の業務に適用できる時期は分けて確認する必要があります。

改正の効果を、今の段階で「日常の問題は何も変わらない」と決めつけることはできません。私が引き続き知りたいのは、注文IDを含むサポート履歴の要約や、MCP経由のデータ参照といった場面で、何を確認してどの構成を選べばよいかです。

AIの活用が進むほど、小さな事業者にもその判断が必要になります。データの種類、提供先の取扱条件、利用目的を組み合わせた具体例が増えれば、各社が同じ論点を一から整理する負担を減らせるはずです。保護の水準を下げずに、遵守を実装へ落とし込む道筋がもっと分かりやすくなってほしいと思っています。

遵守を前提に、渡す情報を絞る

今の私の方針は、必要な確認を済ませたうえで、業務に不要な情報を外に出さないことです。取扱いを曖昧にしたまま進め、成長してから整えるという運用はしていません。

必要な項目と、戻し先の管理を分ける

ログ、分析、AIへの入力を、それぞれの目的に必要な範囲へ絞ります。注文IDや顧客IDが要約や分類に不要なら、モデルへ渡す前に外し、結果を元のレコードへ戻す対応付けは自社内で行います。ただし、IDを外しただけで本文が個人情報ではなくなるとは考えません。

たとえば、問い合わせを分類する場合を考えます。次は設計上の考え方を示す架空の例で、実際のMCPの応答仕様ではありません。

• 元の記録：「注文ID ORD-001、顧客名 山田太郎、問い合わせ 配送日の変更を希望」
• モデルへ渡す内容：「問い合わせ 配送日の変更を希望」
• モデルから受け取る結果：「分類 配送日変更」
• 自社側で行うこと：呼び出し元が保持している対象レコードへ分類結果を保存する

この例では、分類に注文IDや顧客名を使わずに済みます。ただし、実際の自由記述には住所、連絡先、本人を特定できる事情が含まれることがあります。本文の確認や削減も必要です。また、自社内で対応付けできる処理を、法的に匿名化できたと説明するものではありません。情報を減らす設計と、提供先の取扱条件の確認は両方行います。

AIの取扱条件を確認する

入力の学習利用だけでなく、利用目的、保存や削除の条件、提供先や再委託先の扱いを確認します。国外での処理についても、サーバの場所だけで判断せず、誰が取り扱うのかを整理します。契約や規約で確認できないものには、照合可能なデータを渡しません。

外部送信を避けたい用途では、ローカルで動くモデルも選択肢になります。ただし、専用環境という名称だけで外部への提供がなくなるわけではありません。管理主体やログの送信先も含めて確認する必要があります。

説明と、問題が起きたときの対応まで含める

お客様が、どの情報をどこへ渡すのか理解したうえで判断できるように説明します。漏えい等が起きたときも隠さず、状況を確認し、必要な報告・通知を行います。見えにくい内部の工夫を、説明と運用までつなげて初めて、安心して使えるサービスになると思っています。

守るための工夫が、続けやすくなるように

個人情報保護法を遵守することと、そのために必要な負担を問題にすることは両立します。私が求めているのは、確認を省く余地ではなく、小さなプロダクトでも適切な判断へたどり着きやすくなることです。

守るために使った時間が、機能の遅れとしてだけ見えるのはもどかしい。それでも、お客様へ説明できる設計を選び続けます。その過程で迷った点や、情報を減らす工夫を共有することが、次に同じ判断をする人の負担を少しでも軽くできればと思います。