守る側が遅くなる構造。個人情報保護法と小さなプロダクトのAI実装

個人情報保護法は必要で、私は守る側でいたいと思っています。それでも、注文IDをログに残すか、注文内容をAIに渡すかといった日常の判断で手が止まるたびに、小さな憤りが残ります。この記事は法律の解説ではありません。守る側にコストが集中し、守らない側が低リスクで先行しやすい構造の話です。2026年の改正を踏まえたうえで、小さなプロダクトがどこに線を引くかまで書きます。

注文IDをログに残すかで、手が止まる

この違和感を最初に強く覚えたのは、自分のプロダクトに初めてMCP（AIエージェントから外部のツールやデータを呼び出すための仕組み）の機能を作り、リーガルチェックを自分でやっていたときでした。お客様に安心して気軽に使ってもらえるように、名前、電話番号、住所のように、それ単体で個人情報になるデータはAIに返さない設計にしていました。必要なお客様だけがオプションで個人情報も返せる、という二段構えです。良い設計だと思っていました。

ところが確認を進めると、注文IDや顧客IDのような内部の識別子も、条件次第で個人情報に当たると分かりました。IDだけを見ても誰か分からなくても、自社のデータベースと突き合わせれば本人にたどり着けます。それなら「名前を返さないから安全」という整理は成り立ちません。初期設計の意図はほとんど意味をなさず、設計をやり直すことになりました。

それ以来、日常の細かい判断で手が止まるようになりました。エラー監視ツールに注文IDを含めてよいのか。分析基盤に顧客IDをそのまま送ってよいのか。サポート対応を速くするためにAIに注文内容を要約させてよいのか。どれも技術的には数分で済む話で、ビジネス上は明らかに便利です。それでも一つひとつ「これは個人情報の取扱いになるか」と考え、多くの場合は「なる」という結論になります。

守ること自体に異論はありません。問題は、この手間を引き受ける側にほとんど報酬がなく、引き受けない側が低リスクで先に進める構造にあります。この記事はその構造の話です。

容易照合性が、SaaSの前提とぶつかる

個人情報保護法の個人情報の定義には、「他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるもの」が含まれます。いわゆる容易照合性です。注文IDそのものに氏名は入っていませんが、自社の注文テーブルと結合すれば注文者が分かります。その結合が自社内で普通にできる以上、注文IDは自社にとって個人情報として扱う必要があります。

これは条文としては筋が通っています。IDに置き換えただけで規制を逃れられるなら、保護は骨抜きになるからです。ただ、SaaSの作りとは真正面から衝突します。SaaSは内部キーでデータをつなぐことを前提に設計されています。注文、顧客、請求、ログ、サポート履歴は、すべて何らかのIDで結ばれています。結ばれていなければ業務システムとして機能しません。

その結果、ログ、分析、サポート、AIへの入力のほとんどが「個人情報側」に倒れます。氏名を含まないログも、IDを含めば個人情報です。行動分析のイベントにユーザーIDを付けた瞬間、それは個人データの取扱いです。AIにサポート履歴を要約させるとき、そこに注文IDが含まれていれば、照合可能な情報を外部に処理させていることになります。

「個人情報を扱わない設計」を選ぼうとすると、IDを外す、ハッシュ化する、別の一時的な識別子に置き換える、といった対応が必要になります。しかしハッシュ化しても、元のIDとの対応表を自社が持っていれば容易照合性は消えません。本当に照合できなくするには対応表を持たない仕組みが必要で、それはつまり「後からその顧客にたどり着けない」ということです。サポートや不具合調査では、たどり着けないと困ります。守るための構成は、ここでもう複雑になります。

クラウドに預けることと、AIに読ませることは別物

「サーバもストレージも外部のクラウドなのだから、AIに渡すのも同じでは」という感覚は、現場ではよくあります。しかし、この二つは整理が違います。

クラウドのサーバやストレージに個人データを置く場合、提供元がその内容を事業として使わず、単にインフラとして預かっているだけなら、第三者への提供や委託とは扱わない、という整理が広く使われています。契約でデータに触れないことが定められ、アクセス制御も適切なら、それは「預けている」だけです。

生成AIに読ませる場合は、ここから外れやすくなります。プロンプトに注文内容や顧客メモを入れ、モデルがそれを読んで要約や分類を返すというのは、内容を処理してもらう行為です。「預ける」ではなく「加工を頼む」に近い。入力を学習に使わず、応答の生成にしか使わないことを契約で確認できれば、預けるに近い整理が可能な場合もあります。しかし、それを確認し、構成に落とし込むのは事業者側の仕事です。さらに、処理が国外で行われるか、提供元がさらに別の事業者に再委託していないか、といった論点が一気に乗ってきます。MCP経由でAIエージェントに自社データを読ませる場合も同じです。注文IDや顧客メモをプロンプトやツールの応答に載せた瞬間、照合可能な個人情報の外部処理になりえます。

守る側の構成は、ここで急に重くなります。学習に使わない契約のあるAPIを選ぶ、国外処理の扱いを整理してプライバシーポリシーに反映する、IDを外してから渡す層を作る、応答に含まれる情報を制限する。どれも正しいことですが、どれも「まず動かして試す」を遠ざけます。AIの実装は試行錯誤の速さが価値なのに、守る側は試行錯誤の前に設計を固めなければなりません。

小さなプロダクトの期待値計算

ここで、遵守と違反のコストを冷静に並べてみます。

遵守コストは確実で、即時で、固定費です。設計をやり直す時間、匿名化の層を作る工数、プライバシーポリシーと利用規約の整備、お客様への説明資料、委託先の確認。プロダクトの規模が小さくても、これらは大きく減りません。売上がゼロの段階でも同じだけかかります。

違反コストは不確実で、遅延し、規模に依存します。個人情報保護法に中小企業の適用除外はなく、個人事業でも、扱う件数が少なくても対象です。ただし執行の現実として、行政の対応は報告の求めや指導が中心で、命令や罰則に至る重い処分は、悪質だったり大規模だったりする事案に寄りがちです。法人に対する罰金の上限が1億円であることは事実ですが、それは単独では脅しになりません。「どのくらいの確率で、いつ、自分に来るか」という期待値の中で評価されます。小さなプロダクトは失うものが少なく、注目もされにくく、摘発は遠い。

そしてユーザーは、速さ、便利さ、価格でプロダクトを選びます。プライバシーポリシーの精度や、「注文IDをプロンプトから外している」といった内部の工夫は、購入理由になりません。見えないからです。B2Bの調達で確認される場合はありますが、小さなプロダクトが最初に相手にする顧客層では、そこまで問われないことが多いのが実情です。

つまり、市場の正の報酬が遵守に乗りません。遵守のインセンティブは「リスク回避」程度で、そのリスクも小さいうちは遠い。一方で、雑に運用する側は、初期の設計コストを払わず、AIに何でも渡し、便利な機能を先に出せます。「守らない方が必ず勝つ」わけではありません。漏えいが起きれば、炎上、ストアからの削除、B2Bの調達で落とされる、といった経路で一気に終わることはあります。ただ、構造として、初期は雑な側がリードしやすい。これが正確な表現だと思います。

AI推進とのねじれ

この構造は、AI推進の流れの中で見ると、もう一段ねじれます。

政策としてAIの活用は推奨されています。企業に対しても、AIを業務に組み込んで生産性を上げるよう、あらゆる方向から求められます。ところが、実際に小さなプロダクトがAIを組み込もうとすると、最初にぶつかるのが上に書いた容易照合性と外部処理の整理です。真面目に整理する側は、設計に時間をかけ、渡す情報を削り、契約を読み、結果として機能の投入が遅れます。整理を無視できる側は、そのまま先に出せます。

つまりAI推進という同じ旗の下で、遵守事業者のAI実装だけが遅くなります。これは法律が悪いという話ではなく、法律の要求と、AI実装の日常的な作業のあいだに、まだ接続部が用意されていないという話です。

2026年に成立した改正は、この方向に一定の答えを出そうとしています。統計作成やAI開発などを目的とする利用について本人同意の要件を緩める特例が入り、一方で課徴金制度が導入されました。入口を少し開けて、出口を強くする。方向としては理解できます。ただ、小さなプロダクトの日常、つまり内部IDをログに残す、分析SDKにユーザーIDを付ける、LLMのAPIにサポート履歴を渡す、といった場面のインセンティブの歪みは、これで十分に解消されるとは思えません。特例は統計や開発の場面を想定したもので、業務の中で個別の顧客データをAIに処理させる日常とは少し違います。課徴金は出口を強くしますが、小さいうちは遠いという構造は変わりません。改正を無視しているのではなく、改正後もこの記事の問題はそのまま残る、という位置づけです。

それでも法律は必要という留保

ここまで書いたうえで、はっきりさせておきたいことがあります。個人情報保護法は必要です。「守るな」とは書きませんし、思ってもいません。

容易照合性の考え方は、IDに置き換えるだけで規制を逃れる抜け道をふさぐために必要です。生成AIへの入力を「預ける」と区別することも、提供元が入力をどう扱うか分からない以上、妥当です。全方位に穴のない法律は難しく、線の引き方に不満があっても、線がないよりはるかに良い。

問題は保護そのものではなく、保護と日常のAI実装との接続部です。何が個人情報かの整理は明確でも、「では注文IDを含むサポート履歴をLLMに要約させるには、どの構成なら十分か」に対する、小さなプロダクトが実行できる標準的な答えがまだありません。答えがないから各社が自分で線を引き、真面目に引く側だけがコストを払う。ここが歪みの本体です。

憤りの正体

自分の憤りを正確に言葉にすると、こうなります。正しい行動に対して、市場も制度も十分なリターンを出していない、ということです。

私は今、お客様向けに個人情報保護法のリスクを説明する資料を作って配っています。これを書くとき、毎回同じ板挟みになります。脅すように書けば、お客様は導入をためらいます。軽く書けば、リスクが軽視され、お客様自身が危険にさらされます。売上だけを見れば、軽く書いた方が受注しやすい。それでも、お客様をリスクにさらすのは違うと思って、できるだけ正確に書いています。正確に書くたびに、「これを気にしない業者も多いだろう」という考えがよぎります。

エラー監視ツールに注文IDを気軽に送らなくなったのも、この延長です。エラーの内容をAIに読ませて原因を探る、という便利な使い方が広がっていますが、そこにIDが含まれていれば、個人情報をAIに見せていることになります。だから送らない。これは良い習慣だと思っています。ただ、気をつけるたびに、気をつけない側が先に進んでいる構造を思い出します。

この憤りは、雑な業者への個別の怒りというより、正しい選択が報われない設計への違和感です。誰かを名指しで責めたいわけではありません。同じ構造に置かれれば、多くの人が雑な側に流れるでしょう。だから個人の倫理ではなく、構造の話として書いています。

暫定解。全無視でも全完璧でもない線

構造が変わるのを待つあいだも、小さなプロダクトはどこかに線を引かなければなりません。私が今引いている線は、全無視でも全完璧でもない、次のような位置です。

取るデータを減らす

最も効くのは、そもそも取らないことです。ログに入れる項目、分析に送るイベント、サポートツールに残す情報を、業務に必要な最小限まで削ります。取っていないデータは漏れませんし、AIに渡すかどうかの判断も発生しません。

内部キーや照合可能な識別子をモデルに渡さない

注文IDや顧客IDのような内部キーは、モデルに渡す前に外します。要約や分類に必要なのは内容であって、IDではないことがほとんどです。処理結果を元のレコードに戻すための対応付けは、自社の中で完結させます。ハッシュ化は照合可能性を消さないので、匿名化の代わりにはならないと理解しておきます。

AIは学習条件、国外、再委託を見る

AIのAPIやツールを選ぶときは、機能や価格の前に、入力を学習に使わない条件になっているか、処理がどこで行われるか、提供元がさらに別の事業者へ処理を渡していないかを確認します。契約や規約で確認できないものには、照合可能なデータを渡しません。

ローカルLLMや専用経路は、速さのためではなく外に出さない選択

ローカルで動くモデルや、自社が管理する専用の推論経路を選ぶのは、性能や速さのためではありません。照合可能なデータを外に出さない、という選択のためです。性能は劣ることが多いですが、渡せるデータの範囲が広がる分、用途によっては合計で有利になります。

「今はグレー、伸びたら綺麗に」は負債として計上する

小さいうちはグレーで進め、伸びたら整える、という判断をすることはあります。それ自体を否定しませんが、技術的負債と同じように、返済が必要な負債として明示的に記録します。何をどう扱っているか、どこが未整理かを書き残し、伸びたときに「知らなかった」とならないようにします。

漏えいを隠さない

最後に、これだけは線を越えないと決めています。漏えいが起きたときに隠さない。報告し、影響を受けたお客様に伝える。これは制度の要求である以前に、隠した瞬間に、上で書いた「正しい行動が報われない構造」を自分の手で強化することになるからです。

ベストは遵守。ただし設計の問題として見る

ベストは遵守です。これは最初から最後まで変わりません。

ただ、その遵守が現場で選ばれにくいのは、個々の開発者の意識の問題ではなく、インセンティブの設計の問題です。遵守コストは確実で即時で、違反コストは不確実で遅く、市場は遵守を評価しない。AI推進の流れは、この歪みを小さなプロダクトの日常で増幅させています。2026年の改正は方向として正しくても、この日常の部分はまだ手つかずです。

だから私は、守りながら憤り、憤りながら守るのだと思います。この記事は憤りから始めましたが、着地は構造の話です。正しい行動に市場と制度がリターンを返すようになるまで、線を引き続けるしかありません。