# 生成AI APIにクラウド例外は使えるか——個人データの技術統制

> 個人情報保護委員会Q&A(Q7-53)の判断基準を生成AI APIに当てはめ、委託先監督を前提に中小企業が実装すべき3つの技術統制を整理する。

- Canonical: https://kuucorp.com/blog/appi-cloud-exception-llm-api-technical-controls-smb/
- Date: 2026-10-15
- Last modified: 2026-10-15
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
「顧客名簿の一部をClaude APIに投げて要約させたいが、個人情報保護法上は第三者提供になるのか」。IT担当が法務に確認を求められたとき、クラウド保存の整理をそのまま流用して「問題ない」と答えてしまうケースは少なくない。

クラウド保存と生成AI APIは、事業者が個人データに触れる仕組みが違う。[エージェントガバナンス](/glossary/agent-governance/)の観点から、公式Q&Aの判断基準と、中小企業が実装できる技術統制を整理する。なお本記事は技術設計の整理であり、法的結論は顧問弁護士の確認を前提とする。

## 個人データをLLM APIに送ると第三者提供になるのか

> 個人情報保護委員会のQ&A（Q7-53）は、提供先が個人データを取り扱うかどうかで第三者提供の該当性を判断する。

Q7-53の判断基準は、保存データに個人データが含まれるかではなく、クラウド事業者が個人データを取り扱うこととなっているかどうかです。取り扱わないことになっていれば、個人データの提供に当たらず、本人同意（法27条1項）も、委託先の監督（法25条）も不要という整理になります。

「取り扱わない」の例として、Q&Aは次の2点を挙げています。いずれも例示であり、網羅的ではありません。

- 契約条項で、保存された個人データを取り扱わない旨が定められている
- 提供先で適切なアクセス制御が行われている

## 生成AI APIでクラウド例外を前提にしてよいか

> LLM APIは送信された入力そのものを処理して応答を返すため、クラウド例外を前提にせず、委託先の監督（法25条）で設計するのが安全だ。

クラウドストレージは保存が目的ですが、LLM APIはプロンプトに含まれる個人データを読み取って推論します。Q7-53の言う「取り扱わないこととなっている」状態を、契約とアクセス制御で成立させられるかは、サービスごとの契約と運用実態で判断が分かれます。ここは設計側で断定せず、法務の判断に委ねるべき箇所です。

実務では、例外が使えない場合に備えて設計します。例外が適用できなければ委託先の監督が必要になり、外国のサーバが絡む場合は個人情報保護委員会のQ12-3に沿って、外国の制度を把握したうえで安全管理措置を講じる必要があります。例外が成立する場合でも、下記の技術統制は無駄になりません。

2023年6月2日の個人情報保護委員会の注意喚起も、入力する個人情報が特定した利用目的の範囲に収まっているか、提供事業者が入力データを機械学習に利用しないかの確認を求めています。

## 中小企業が実装すべき技術統制は何か

> 技術統制は、送信前の個人データ最小化、利用目的の記録、提供先設定の固定の3点に集約できる。

1. **送信前の最小化**: プロンプトを組み立てる層で、氏名・住所・電話番号などを仮名トークンに置換します。設計は[PII除去・匿名化の設計](/blog/agent-pii-filtering-anonymization-design/)を参照してください。個人データを送らなければ、そもそも論点が小さくなります。
2. **利用目的の記録**: 呼び出しごとに、利用目的・呼び出し元システム・個人データを含むか否かのフラグをログに残します。個人情報の利用目的の範囲内かを後から説明できる状態にするためです。ログ設計は[AIエージェントの監査ログ管理](/blog/ai-agent-audit-log-management/)が参考になります。
3. **提供先設定の固定**: 利用するAPI・リージョン・データ保持設定を組織の設定で固定し、個人の判断で別サービスへ送れない構成にします。保持設定の確認観点は[Claude APIのデータ保持の確認事項](/blog/claude-api-data-retention-zdr-smb-guide/)にまとめています。

この3点はコードと設定で実装でき、委託先監督の記録としても使えます。

## 着手の順番と運用の注意点

> 着手は、個人データを含む呼び出しの洗い出し、契約条項の確認、最小化の実装の順で進めると手戻りが少ない。

まず現状の呼び出しを棚卸しし、どのシステムが個人データを送っているかを特定します。次に利用中サービスの契約・プライバシー関連文書で、入力データの学習利用と取り扱いの条項を確認します。数値や保持期間は改定されるため、必ず公式文書の最新版を参照してください。最後に、上の3点を共通ライブラリやゲートウェイに実装します。

運用面では、契約や設定の変更を定期的に見直す担当者を決めておくことが重要です。

## 参考

- [個人情報保護委員会 個人情報保護法 FAQ Q7-53（クラウドサービス提供事業者への保存と第三者提供）](https://www.ppc.go.jp/all_faq_index/faq1-q7-53/)
- [個人情報保護委員会 個人情報保護法 FAQ Q12-3（外国にあるサーバへの保存）](https://www.ppc.go.jp/all_faq_index/faq1-q12-3)
- [個人情報保護委員会 生成AIサービスの利用に関する注意喚起等](https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/)

## まとめ

クラウド例外の判断軸は「提供先が個人データを取り扱うか」です。LLM APIは入力を処理するため、例外を前提にせず、委託先の監督を含めて設計するのが安全です。技術側では送信前の最小化、利用目的の記録、提供先設定の固定を実装すれば、どちらの法的整理でも説明可能な状態を作れます。

個人データを扱う生成AI基盤の設計や運用体制づくりは、Kuu株式会社の[AI Opsサービス](https://kuucorp.com/services/ai-ops/)にご相談ください。