受託AI開発における顧客データの安全な取り扱いガイド｜マスキング3パターン・名寄せ設計・NDA AI条項・3ステップ開発アプローチ【2026年版】

顧客データを「そのまま使う」のはNGが当たり前になった

受託AI開発で顧客からデータを受領する際、「個人情報はマスキング処理し、キー項目は仮番号に変換して提供」——これが2026年のスタンダードです。AI開発にデータは不可欠ですが、生データをそのまま開発環境に入れることは、NDA違反・個人情報保護法違反のリスクを伴います。

本記事では、受託AI開発における顧客データの安全な取り扱いを、マスキング設計からNDA条項のAI対応まで実践的に解説します。

データ受領前に合意すべき5項目

項目	合意内容	具体例
マスキング方針	個人情報の処理方法	氏名→匿名ID、住所→都道府県のみ
キー項目の変換	紐付け用IDの仮番号化	医師コード→仮番号（顧客側でマッピング保持）
対象期間	分析に使うデータの範囲	2024年1月〜2026年1月の2年分
除外データ	使わないデータの明示	LINE連携ログは紐付け不完全のため除外
提供方法	データの受け渡し手段	暗号化ファイル共有サービス経由

マスキング設計の3パターン

パターン1：完全匿名化

個人を特定できる情報を全て除去します。

• 適用場面：統計分析・傾向分析など、個人の特定が不要な場合
• 方法：氏名・住所・電話番号を削除、年代・地域などの属性のみ残す
• メリット：個人情報保護法の適用外になりうる
• デメリット：個人単位のパーソナライズが不可能

パターン2：仮番号変換（推奨）

個人を特定できる情報を仮番号に変換し、マッピングテーブルは顧客側のみが保持します。

• 適用場面：個人単位の分析が必要だが、開発者が個人を特定する必要がない場合
• 方法：医師コード→仮番号、顧客ID→連番に変換。マッピングは顧客側で管理
• メリット：個人単位の分析が可能かつ、開発者は個人を特定できない
• デメリット：マッピング管理が顧客側に必要

パターン3：アクセス制御型

データ自体はマスキングせず、アクセス権限で制御します。

• 適用場面：実データでの精度検証が必要な最終段階
• 方法：顧客環境内でのみ生データにアクセス。開発環境にはコピーしない
• メリット：最も正確な検証が可能
• デメリット：開発の柔軟性が低い

複数アカウント問題の名寄せ設計

顧客データでよくある課題が「1人の人物が複数アカウントを保有している」問題です。

名寄せロジックの設計

1. キーとなるIDの特定：どのコードで人物を一意に特定するか（例：DCFコード、医師コード）
2. 統合ルールの定義：同一人物の複数レコードをどう統合するか
3. 統合不可能なケースの扱い：自動統合できないケースは手動確認の対象として分離

名寄せの精度問題

名寄せには完璧はありません。初期段階では「医師個人単位のインサイト抽出」ではなく「診療科クラスター単位での分析」に方針転換することで、名寄せ精度の影響を軽減できます。

AI開発用データセットの設計

ETL（データ整形）の標準工程

1. 文字コード・日付フォーマットの統一
2. キー項目による名寄せ（例：DCFコードで医師を特定）
3. 複数アカウントの1人への統合
4. 除外データの排除（例：紐付け不完全なLINEログ）
5. 分析軸の分類（例：診療科クラスターに分類）
6. 個人情報マスキングの最終確認

データ更新の仕組み設計

デモ段階ではCSVを直接読み込む構成でも動きますが、顧客にアプリを渡した後にデータ更新ができないという問題が発生します。

対策として、以下の仕組みを設計します。

• 顧客が新データをファイル共有に格納
• 自動スクリプトが起動し、ETLを経てDBに反映
• 手動作業不要でデータが更新される

NDA条項のAI対応

2026年のNDAには、AI固有の条項が必須になっています。

NDAに含めるべきAI条項

条項	内容
AI定義	「AI」「生成AI」を契約内で精密に定義する
学習禁止	機密データをAIモデルの学習・ファインチューニングに使用しない
第三者AIツール	第三者のAIツールに機密情報を送信する場合は事前書面承諾を要する
エンタープライズAI	セキュアなエンタープライズ版・プライベートAIツールの使用を許可
違反時の救済	第三者AIツール経由の情報漏洩に対する救済措置を明記

AIツール使用時の判断フロー

顧客データをAIに入力したい
  ├ エンタープライズ版（データ学習に使われない保証あり）→ 許可
  ├ パブリックAPI（データ学習に使われる可能性あり）→ 要確認
  └ 無料版（データ取り扱い不明）→ 禁止

3ステップ開発アプローチ

顧客データを扱うAI開発は、以下の3ステップで進めます。

1. 外部DBデモ：マスキング済みデータでプロトタイプを構築。顧客にデモを見せてフィードバック
2. 社内システム接続：顧客環境内で実データに接続。精度を検証
3. 運用設計：データ更新の自動化、アクセス権限、監査ログの整備

ステップ1では生データを一切使わず、ステップ2では顧客環境内でのみアクセスし、ステップ3で運用体制を整える——この段階的アプローチにより、データリスクを最小化しながら開発を進められます。

データ分類と保護レベル

分類	保護レベル	取り扱い
個人識別情報（PII）	最高	マスキング必須、開発環境に入れない
業務データ（売上等）	高	NDA範疇、集計値のみ開発環境に可
マスタデータ（コード体系）	中	仮番号化して開発環境に可
公開情報（業界統計等）	低	制限なし

まとめ：顧客データ取り扱いチェックリスト

フェーズ	チェック項目
受領前	マスキング方針・キー変換・除外データが合意されているか
受領前	NDAにAI条項（学習禁止・第三者ツール制限）が含まれているか
受領時	個人情報がマスキング済みであることを確認したか
ETL	名寄せ・統合・除外・分類の工程が文書化されているか
開発中	AIツールに生データを入力していないか
納品前	開発環境にマスキング前のデータが残っていないか
運用	データ更新の自動化・アクセス権限・監査ログが整備されているか

顧客データの安全な取り扱いは、受託AI開発の信頼の基盤です。マスキング設計・NDA条項・3ステップ開発の3つを徹底し、データリスクをゼロに近づけてください。

あわせて読みたい

• 5Sとは｜整理・整頓・清掃・清潔・しつけの意味・目的・進め方を解説
• AIリードスコアリング実装ガイド【2026年版】— 4要素スコアリング×テリトリー管理×ステータス倍率の本番アーキテクチャ
• AIカスタマーサポート完全ガイド【2026年版】— RAG・チャットボット・有人連携の実装パターンとツール比較

関連記事

• プロジェクト設計テンプレート
• リスクマネジメント
• 週次レポート設計
• 見積もり技術

PMOコンサルティングのご相談はrenueまで。