AI API連携で個人情報を扱う前に確認すべきこと
「問い合わせ内容をAIで自動要約したい」「顧客データをAIに読ませてレコメンドを出したい」——既存プロダクトにAI機能を足す相談で、必ず一度は「個人情報を外部のAI APIに投げていいのか」という不安が出てきます。法務に聞いても明確な答えが返ってこず、かといって開発を止めるのも惜しい。この記事では、その不安を「怖いから触らない」ではなく「確認すべき点を確認して進める」に変えるための具体的なチェックポイントを整理します。
まず切り分ける、「送信していいデータ」と「送信してはいけないデータ」
最初にやるべきは、機能全体を止めることではなく、AI APIに渡すデータの範囲を機能単位で洗い出すことです。
- その機能の目的を達成するのに、氏名・メールアドレス・電話番号・住所そのものが本当に必要か。多くの要約・分類・レコメンド系の機能は、識別子を伏せても成立する
- 個人情報の中でも要配慮個人情報（病歴、犯罪歴、信条など）が含まれる項目は特に慎重に扱う。これが混ざる設計は原則避ける
- 「今回のリリースで使う項目」と「将来使うかもしれない項目」を混同しない。使わないカラムまで一括でAPIに渡す実装は、後で必ず監査コストになる
ここを機能ごとにテーブル化するだけで、「全部危ない」という漠然とした不安が「この3項目だけ要注意」という具体的なタスクに変わります。
API提供者側の学習利用・データ保持ポリシーを確認する
OpenAIとAnthropic（Claude）はいずれも、Business/Enterprise向けAPI（Platform API）のデータは既定でモデル学習に使用しない契約になっています。これはConsumer向けのチャットアプリ（ChatGPT・Claude.ai の無料/Pro版で学習利用をオプトアウトしていない場合）とは別の話なので、混同しないことが重要です。
確認すべき項目は以下の通りです。
- 学習利用の有無: APIのデータが既定でopt-outか。契約書（Terms of Service / Business Terms）の該当条項を実際に読む。営業資料の要約だけで判断しない
- データ保持期間: OpenAI APIは既定で30日間の不正利用モニタリング用ログを保持し（Zero Data Retention申請で短縮可能な用途もある）、Anthropic APIも同様に一定期間の保持ポリシーがある。「保持ゼロ」ではないことが多いので、保持期間そのものが要件に抵触しないか確認する
- ログ・モニタリングの扱い: 不正利用検知のためにAPI提供者側の担当者や自動システムがログを閲覧しうる範囲を把握する
- サブプロセッサ: API提供者がさらにどのクラウドインフラ（AWS/GCP/Azure等）を使っているか。提供者のセキュリティページやDPAに記載がある
ポリシーは更新されるため、契約時点のスナップショット（PDFやスクリーンショット）を社内に残しておくと、後で「あの時点ではこうだった」を証明できます。
DPA(データ処理契約)と国内保存要件
toB向けプロダクトで顧客企業の個人情報を扱う場合、多くのケースでDPA(Data Processing Agreement)の締結が論点になります。
- OpenAI・AnthropicともにDPAをオンラインで提供しており、企業向けアカウントで締結できる。これを結ばずにAPIを本番投入すると、顧客との契約（特に個人情報保護に関する条項）に違反するリスクがある
- 「データを日本国内に置かなければならない」という要件がある場合（官公庁案件、一部の金融・医療系顧客）は、AI APIのリクエストが海外リージョンを経由する時点で要件を満たせない可能性がある。この場合はAzure OpenAI Serviceの日本リージョンなど、データレジデンシーを選べる選択肢を検討する
- 個人情報保護法上、外国にある第三者（API提供者）への提供にあたる場合は、本人同意または法定の例外要件を満たす必要がある。ここは法務判断が必要な領域なので、エンジニアだけで完結させず、契約前に法務・顧問弁護士に確認するプロセスを組み込む
「DPAを結んでいるかどうか」は開発着手前の1メールで確認できるのに、後回しにされがちな項目です。見積もり段階で確認事項リストに入れておきます。
マスキング・匿名化の設計パターン
「個人情報を送らない」を実装で担保する具体的な方法は、主に3つです。
- 除外: そもそも個人情報カラムをAPIに渡すペイロードに含めない。最もシンプルで確実。要約・分類・レコメンドの多くはこれで足りる
- 仮名化(トークン化): 氏名や連絡先を
[顧客A]のようなプレースホルダーに置き換えてから送信し、AI応答を受け取った後にアプリ側で元の値に復元する。会話文脈の中で人名が必要な要約機能などで使う - マスキング(部分的な伏せ字): 電話番号の下4桁だけ残す、メールアドレスのドメイン部分だけ残すなど、識別性を落として渡す。統計・傾向分析用途で使う
どれを選ぶかは機能要件次第ですが、共通して重要なのはマスキング処理をAPI呼び出しの直前に集約し、テストでカバーすることです。「送信前にマスキングする関数」がコードベースに散らばっていると、新しい呼び出し箇所を追加したときにマスキングを忘れる事故が起きます。既存プロダクトでは、AI連携用のサービスクラス（例: AiClient や SummarizeService）を1箇所に集約し、そこを通らない限りAPIを呼べない構造にするのが実務上もっとも事故が少ない設計です。
社内規定とログの扱い
技術的な対策と並行して、社内ルールとして固めておくべき点があります。
- 利用範囲の明文化: 「どの業務で」「どのデータを」「どのAI APIに」送っていいかを1ページのルールにする。エンジニアが個人の判断でAPIキーを発行し、規定外のデータを送ってしまう事故を防ぐ
- APIキーの管理: キーは環境変数・シークレットマネージャで管理し、ソースコードに直書きしない。既存プロダクトの改善では、まずここが守られているかを最初に確認する
- ログへの個人情報混入: アプリケーションログやエラートラッキング（Sentry等）に、AI APIへのリクエスト/レスポンス全文がそのまま出力されていないか確認する。デバッグ目的で入れたログが個人情報の保管場所になっているケースは非常に多い
- 監査可能性: 「いつ・どの機能が・どのデータをAI APIに送ったか」を後から追跡できるログを別途残しておく。インシデント発生時に影響範囲を特定するために必須
ユーザー同意の設計
BtoBプロダクトで、エンドユーザー（顧客企業の担当者やその先の消費者）のデータをAI機能に使う場合、利用規約・プライバシーポリシーの更新も必要になることが多いです。
- 既存のプライバシーポリシーに「AIによる自動処理」の記載がなければ追記が必要か、法務に確認する
- 新規に同意を取得する必要があるか、既存の利用規約の包括同意で足りるかは、扱うデータの性質（要配慮個人情報を含むか等）によって変わる
- BtoB SaaSの場合、エンドユーザーへの説明責任は顧客企業側にあることが多いが、機能を提供する側として「AIにどう使われるか」を顧客企業が自社のユーザーに説明できる資料（データフロー図など）を用意しておくと、営業・カスタマーサクセスの負担が減る
外注する場合の進め方
これらを自社だけで判断しきれない場合、外部の開発チームに依頼する際は次の順で進めると手戻りが少なくなります。
- 診断フェーズを先に切る: いきなり実装に入らず、扱うデータの棚卸し・マスキング設計・DPA確認事項の洗い出しを短期の診断として発注する。実装費用を確定させる前に、法務確認が必要な項目を先に潰しておける
- マスキング処理はコードレビュー対象にする: 発注先に「マスキングしてください」とだけ伝えるのではなく、除外・仮名化・マスキングのどれを採用するかを機能ごとに合意し、実装後にコードレビューで確認する
- 契約書とDPAは並行して進める: 技術実装を待たずに、AI API提供者とのDPA締結・自社プライバシーポリシーの見直しは法務チーム側で並行して進める。実装が終わってからDPA未締結に気づくと、リリースが数週間止まる
個人情報を理由にAI機能の検討自体を止めてしまうケースをよく見ますが、実際にはほとんどの機能が「送るデータを絞る」「マスキングする」で問題なく実現できます。過剰に恐れるより、確認すべき項目を順番に潰していくほうが、結果的に早くリリースにたどり着きます。
既存プロダクトへのAI機能追加の進め方は既存プロダクトの改善、外部チームが最初に見る観点でも扱っています。個人情報以外のデータ取り扱い全般の観点は個人情報の取り扱い、既存プロダクトの点検ポイントをあわせてご覧ください。
まとめ
- AI APIに送るデータは機能単位で洗い出し、「除外・仮名化・マスキング」のどれで対応するかを設計段階で決める
- API提供者の学習利用ポリシー・データ保持期間・DPAは契約書の原文で確認し、国内保存要件がある場合はリージョン選択も検討する
- 社内規定（利用範囲・キー管理・ログ・監査ログ）とユーザー同意の設計を、技術実装と並行して法務と詰める
torcheeesでは、既存プロダクトへのAI API連携を、データ棚卸しから実装・運用設計まで支援しています。まずは扱うデータの整理から始めたい方は、AI開発・API連携支援のページをご覧いただくか、お問い合わせからご相談ください。