差し戻された稟議書を見せてもらう機会が、この半年で何度かありました。ある医療機器メーカーの一枚もそうで、情報システム部門が書いた差し戻し理由は「データがどこまで社外に出るのか不明」の一行だけ。添付された調査メモには AI 個人情報保護法 / AI 業務自動化 データ 取扱い / AIエージェント 個人情報 と論点が几帳面に並び、条文の引き写しも正確でした。空欄だったのは、自社のどの業務のどの操作がその条文に当たるのか、という欄です。

止める対象は条文ではありません。データが社外に出る地点です。AI業務自動化でその地点は五つに分かれます。プロンプトへの入力、機械学習への利用、サービス側のログと保存、エージェントによる外部API呼び出し、そして再委託の連鎖。

AI業務自動化で個人データが社外に出る地点はどこか？

社外に出る地点は五つで、そのうち担当者の目に見えるのは最初の一つだけです。残りの四つは契約書の別紙か、管理画面の設定か、相手方のさらに相手方の側にあります。稟議が止まるのは、この非対称に誰かが気づいたときです。

地点	データが出る操作	見落とされやすい理由
入力	担当者がプロンプトに顧客情報を貼り付ける	画面上の操作なので、渡した項目の記録が残らない
学習	入力内容がモデルの学習に回される	契約条項と設定の話で、業務画面からは見えない
ログ・保存	サービス側が入力と応答を一定期間保持する	保持期間と保存先が仕様書の付録に書かれている
外部API呼び出し	エージェントが別のサービスを呼び出す	呼び出し先はフロー定義次第で運用中に増える
再委託	サービス提供者がさらに別の事業者を使う	相手の相手なので、契約書の視界に入らない

五つを並べると、対策の順番も決まります。目に見える入力から手をつけるのは自然ですが、事故の後始末が重いのは後ろの四つです。

社内のセキュリティ審査で議論が入力の一点に集中しがちなのも、同じ非対称から来ています。入力は禁止事項として書き下せるので、規程に落としやすい。残る四つは相手方の仕様と契約に依存するため、社内規程では表現できず、審査項目から静かに落ちます。

落ちた項目は、稟議の差し戻し理由として後から戻ってきます。

なお、以下は制度の枠組みを設計の観点から整理したものです。個別の取扱いが適法かどうかの最終判断には、自社の法務部門や専門家への確認が要ります。

プロンプト入力は法律上どう扱われるのか？

個人情報保護委員会は2023年6月2日の注意喚起で、事業者向けに二点を挙げています。個人情報を含むプロンプトを入力する場合は「特定された当該個人情報の利用目的を達成するために必要な範囲内であることを十分に確認すること」。そして本人の同意なく個人データを含むプロンプトを入力し、それが応答結果の出力以外の目的で取り扱われる場合、法の規定に違反することとなる可能性がある、という指摘です。

後段には条件が続きます。だからこそ「当該生成AIサービスを提供する事業者が、当該個人データを機械学習に利用しないこと等を十分に確認すること」。確認の相手はサービス提供者であって、社内の運用ルールではありません。

入力先の事業者が入力データを自社の目的で扱わない前提で契約が組まれていれば、法第27条第5項第1号の「委託」として整理される場合もあります。委託であれば第三者提供に当たらず、本人の同意は不要です。ただし委託先は委託された業務以外にそのデータを取り扱えず、委託元には法第25条の監督責任が課されます。

前段の「利用目的を達成するために必要な範囲内」という条件も、実務では引っかかりどころになります。数年前に公表した利用目的の記載が、AIによる処理まで読み込める書き方になっているか。ここを既存の記載の範囲内と読むか、追記が要ると読むかで、着手前にやるべき作業が変わります。

判断を先送りにすると、検証が進んだあとで公表文の改定と本人への周知が発生します。

順番が逆になるわけです。

設計に落とすと、問いは「入力してよいか」から「どの項目を渡すか」に変わります。氏名と住所を渡さなくても処理が成立する業務は、実際にかなりあります。

「学習に使われない」をどこまで確認すれば足りるのか？

委員会の文言は「十分に確認すること」で、確認の方法までは定めていません。実務では三つの層に分けて見ると漏れが減ります。契約条項、管理画面の設定、そして変更の通知経路です。

契約条項は、データ処理に関する付属文書まで読む必要があります。本体の秘密保持条項だけでは、学習利用の可否は決まりません。管理画面の設定は、既定値がどちらに倒れているかを実機で確かめるのが確実です。無償プランと有償プランで既定値が違うサービスも珍しくありません。

この既定値の差は、検証の進め方そのものを歪めます。無償枠でPoCを回し、結果が良かったので有償プランで本番へ、という流れはよくある形です。ところが検証中の設定と本番契約後の設定は別物で、確認したはずの条件が引き継がれていない。移行の作業項目に「設定の再確認」が入っていないと、この段差は静かに通過します。

見落とされるのが三つ目です。契約書を一度読んで確認したという事実は、その時点の確認であって、継続の確認ではありません。規約とプランの仕様は改定されます。

だから確認は行事にします。四半期に一度、担当を決めて設定画面と規約の更新履歴を見る。この程度の頻度なら運用は持ちますし、改定の見落としもだいたい防げます。

ログと保存先が見落とされるのはなぜか？

学習に使わないことと、保存しないことは別の話だからです。不正利用の監視や障害調査のために入力と応答を一定期間保持する設計は一般的で、そこに個人データが含まれていれば、保存先の国と保持期間が論点になります。

ガイドライン通則編の別添は「外的環境の把握」として、外国において個人データを取り扱う場合は当該外国の個人情報の保護に関する制度等を把握した上で、安全管理のために必要かつ適切な措置を講じなければならないと定めています。海外リージョンを選んだ時点で、この確認が発生します。

外国にある第三者への提供となれば、法第28条第1項により原則として本人の同意が要ります。例外は三つ。委員会規則で定める国（EUおよび英国）にある場合、相当措置を継続的に講ずる体制の基準に適合している場合、そして法第27条第1項各号に該当する場合です。委託であっても同じ扱いになる、と委員会はよくある質問で明示しています。

分岐点は別のところにもあります。委員会は、外国の事業者のサーバーを利用する場合でも、契約により当該事業者がデータを取り扱わない旨が定められ、適切にアクセス制御されているときは外国にある第三者への提供に該当しないとしています。取り扱わせないという設計が、そのまま法の適用範囲を変えるわけです。

同意で解く道を選ぶなら、規則第17条第2項が求める情報提供の準備が必要になります。外国の名称、その外国の制度に関する情報、第三者が講ずる保護措置の三点です。

三点を本人に示せる形にするのは、既存顧客が数万人いる業務では相応の負担になります。だから多くの現場では、同意を取りに行くより先に、保存先を国内リージョンに固定できるかを確認する順序になります。

固定できれば論点そのものが立ちません。

エージェントが外部APIを呼ぶ瞬間に何が起きるか？

出口の数が、設定によって変わります。ChatGPTは答えます。WindyFloは働きます。この違いは機能の優劣ではなく、データが出る地点の数の違いとして現れます。

答えるだけの道具なら、社外に出るのは入力した内容だけです。実行する道具は、業務を進めるために別のシステムを呼びます。在庫を確認する、伝票を起こす、通知を送る。呼び出しのたびに送信先と送信項目が決まり、その組み合わせはフロー定義の中にあります。

厄介なのは、フローが運用中に編集されることです。最初は社内システムだけを呼んでいたフローに、三か月後には外部の与信サービスが足されている。追加した担当者に悪意はなく、業務上は正しい判断です。ただ出口は一つ増えました。

出た先での扱いも計算に入れます。呼び出したサービスの側にも、リクエストの内容はログとして残る。自社が保持期間を短く設定していても、送信先の保持期間は送信先の仕様に従います。出口が一つ増えるとは、自社の管理外にある保管場所が一つ増えるということです。

置く制御点は二つ。送信項目のホワイトリストと、送信前の承認ゲートです。前者はフロー定義の側で項目を固定し、後者は誰がいつ何を承認したかを残します。

誤った内容が業務に届くのを止める仕組みは、AIの誤りを業務の手前で止める確認ゲートと記録の設計として別に組みます。止める対象が違えば、記録すべき項目も違うためです。

再委託の連鎖はどこで断ち切るのか？

断ち切るというより、見えるようにして固定します。AIサービスの背後にはモデル提供者があり、その下に基盤クラウドがあり、監視や解析の事業者が並ぶこともある。階層は珍しくありませんが、契約書の別紙に一覧がなければ、こちらからは存在しない構造です。

ガイドラインは、委託先が再委託を行おうとする場合、委託元は再委託する相手方・業務内容・個人データの取扱方法等について事前報告を受けるか承認を行うこと、定期的な監査を実施すること等が望ましいとしています。さらに注意書きが付きます。委託元が必要かつ適切な監督を行っていない場合で、再委託先が不適切な取扱いを行ったときは、元の委託元による法違反と判断され得る。

責任が自社に戻ってくる以上、契約交渉で確かめる項目は具体的になります。サブプロセッサの一覧が開示されるか。追加・変更のときに事前通知が来るか。通知後に異議を述べる猶予期間があるか。

三つとも「否」なら、そのサービスは監督義務を果たせる構成になっていません。価格や機能の比較より前に効く分岐です。

規模の大きい海外サービスほど、個別交渉に応じず標準約款のままで、という回答が返ってきます。そこで選択肢は二つに絞られます。標準約款が開示している範囲で監督の記録を組み立てられるか検討するか、扱う業務の側から個人データを外して適用対象そのものを狭めるか。

前者を選ぶなら、公開されているサブプロセッサ一覧のページを定期的に取得して差分を残す運用が最低線になります。

相手が通知してくれないなら、こちらが見に行く。

制御点を業務フローのどこに置くか

五つの地点には、置くものと決めるものが一組ずつ対応します。決めるものの側が実は難所で、ここを空欄のまま導入すると、設定は入っているのに誰も運用できない状態になります。

地点	置く制御点	判断が要る点
入力	項目単位のマスキングと送信項目の固定	どの項目を業務上「必要な範囲」とみなすか
学習	契約条項と管理画面設定の二重確認・定期再確認	再確認の頻度と担当者
ログ・保存	保持期間の指定とリージョンの固定	保持を短くすると障害調査が難しくなる
外部API	送信前の承認ゲートと送信先ホワイトリスト	承認を要する条件（金額・件数・項目）の閾値
再委託	サブプロセッサ一覧の開示と変更通知	通知後に拒否できる猶予期間の長さ

設計の原則は一つです。制御点は業務が実際に止まる場所に置きます。全件を承認対象にすると担当者の処理待ちが積み上がり、三か月で承認は形骸化するか、設定ごとオフにされます。閾値で分け、越えたものだけを人に回す構成が現実的です。

初期値は発明しないのが早道です。既存の業務で人が二重チェックしている条件を、そのまま閾値に写す。承認の基準を新しく発明すると根拠を説明できず、監査でも運用でも揉めますが、既存の内部統制と同じ線なら説明が済んでいます。

誰がその閾値を決め、誰が例外を処理するのか。役割の置き方は非エンジニアの業務チームがAI運用を持つときの役割分担で扱った通りで、権限の所在が曖昧なままだと制御点は機能しません。

WindyFloが採っている設計も同じ線上のものです。実行のレイヤーを業務画面から分離し、送信項目と実行権限をフロー定義の側に持たせる。個別の保存場所や暗号化の仕様は要件によって変わるため、技術相談で条件を突き合わせて確認する範囲としています。

何が出たかを後から辿れる記録をどう残すか？

監査ログの価値は、事故が起きた日にまとめて表れます。法第26条第1項の報告対象事態にあたる場合、事業者は事態を知った後、速やかに委員会へ報告しなければなりません。ガイドラインは「速やか」の目安を、事態を知った時点から概ね3〜5日以内と示しています。

確報の期限はさらに具体的です。知った日から30日以内、規則第7条第3号に定める不正の目的による行為の事態では60日以内。この期限内に、漏えいのおそれがある個人データの項目と、それに係る本人の数を報告する必要が出てきます。

ここで記録の設計が効きます。項目と件数を出せるかどうかは、事故の後に調べて分かることではなく、平常時にどの粒度でログを残していたかで決まるからです。誰が、いつ、どのフローで、どの項目を、どの送信先に渡したか。この五つが揃っていれば、報告書の該当欄はデータから埋まります。

記録の設計には逆説が一つあります。追跡のために送信内容をそのまま保存すると、監査ログ自体が個人データの新しい保管場所になる。実務では、送信した項目名と件数、送信先、実行者、時刻までを残し、値そのものは残さない形が扱いやすくなります。値が必要になる調査は限られており、そのときだけ元の業務システム側から突き合わせれば足りるからです。

委託関係にある場合、報告対象事態に該当すれば原則として委託元と委託先の双方が報告義務を負い、委託先が委託元へ通知したときは委託先の義務が免除されます。ガイドラインはもう一点、高度な暗号化その他の個人の権利利益を保護するために必要な措置が講じられている場合については報告を要しない、とも述べています。暗号化の設計判断が、事故時の負担に直接つながる箇所です。

小さく始める範囲はどう切るのか

最初の範囲から外すものを先に決めます。要配慮個人情報は法第20条第2項により、例外に該当する場合を除き、あらかじめ本人の同意を得ないで取得してはならないと定められています。信仰・病歴・犯罪歴などが該当し、人事や健康管理の業務は最初の一本には向きません。越境が絡む業務も、確認事項が増えるぶん検証の焦点がぼやけます。

残った候補から一業務・一出口で始め、五つの地点のうち自社で実際に発生するのはどれかを実測する。机上で五つ全部に備えるより、二つしか発生しなかったという事実を掴むほうが、次の判断は速くなります。導入がつまずく典型的な形はAI導入が失敗する原因と、着手前に打てる対策に整理しました。

実測の対象は、地点の有無だけではありません。各地点で一日に何件の判断が発生するかも同時に数えます。件数が分かって初めて、承認ゲートの閾値が運用可能な水準に収まっているかを検証できるからです。

制度の側も動いています。個人情報の保護に関する法律等の一部を改正する法律は2026年7月10日に成立し、7月17日に公布されました。施行は原則として公布の日から起算して2年を超えない範囲内で政令で定める日とされ、本稿の時点では日付が決まっていません。

改正には、委託を受けた事業者の義務の見直し、課徴金納付命令の制度、統計情報等の作成にのみ利用される場合の本人同意の例外といった項目が含まれます。三つ目には、統計作成等と整理できるAI開発等が含まれるとされています。具体的な対象範囲は委員会規則等で定められる想定で、委員会は2026年8月26日に「政令・規則等で定める事項の全体像について」を決定しました。

現時点で確定しているのは公布の事実であり、条文の適用が始まる日と細目はこれからです。改正を先取りした運用設計は、まだ組めません。

改正の内容が固まるのを待つ理由は、設計の側にはありません。データが出る地点を特定して制御点を置く作業は、いまの枠組みで完結しますし、制度が変わっても地点の数は変わらないからです。自社の五地点を書き出すところから、WindyFloのサービス概要とあわせて条件を突き合わせてみてください。

よくある質問

出典

• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日公表） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ — 本文のプロンプト入力に関する事業者向け注意点（利用目的の範囲内の確認、機械学習に利用しないこと等の確認）の根拠。
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」平成28年11月（令和8年4月一部改正） https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ — 委託先の監督（法第25条）、再委託に関する記述、漏えい等の報告（法第26条）の速報・確報の期限、要配慮個人情報の取得（法第20条第2項）、講ずべき安全管理措置の内容（技術的安全管理措置・外的環境の把握）の根拠。
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」平成28年11月（令和5年12月一部改正） https://www.ppc.go.jp/personalinfo/legal/guidelines_offshore/ — 法第28条第1項の例外三類型、規則で定める国（EUおよび英国）、規則第17条第2項の情報提供事項の根拠。
• 個人情報保護委員会「よくある質問」Q12-1 https://www.ppc.go.jp/all_faq_index/faq1-q12-1/ ・Q12-3 https://www.ppc.go.jp/all_faq_index/faq1-q12-3/ — 外国にある第三者への委託にも法第28条第1項が適用される点、および外国事業者のサーバー利用時に「取り扱わない」ことが担保されている場合の扱いの根拠。
• 個人情報保護委員会「「個人情報の保護に関する法律等の一部を改正する法律」の公布について」（令和8年7月17日） https://www.ppc.go.jp/news/press/2026/260717/ — 成立日・公布日の根拠。
• 個人情報保護委員会事務局「個人情報保護法等の一部を改正する法律について」（令和8年7月） https://www.ppc.go.jp/files/pdf/260717_kaiseihounitsuite.pdf — 改正内容（委託を受けた事業者の義務の見直し、課徴金、統計情報等の作成に係る本人同意の例外）および施行期日の根拠。
• 個人情報保護委員会「令和8年改正個人情報保護法について」 https://www.ppc.go.jp/personalinfo/legal/r8kaiseihogohou/ — 「政令・規則等で定める事項の全体像について」（令和8年8月26日決定）の公表状況の根拠。
• 本文中の稟議・PoC・ベンダー選定に関する観察は、筆者（ハマダラボCTO）による導入支援の実務経験にもとづく。