AI開発委託が増加する中、セキュリティリスクが変わった
生成AIや機械学習モデルの開発を外部委託する企業が急増しています。コスト効率や専門人材の確保を理由に、開発のコア部分まで外部に委ねるケースは、もはや珍しくありません。
しかし、AI開発委託には従来のシステム開発委託とは異なる固有のセキュリティリスクが存在します。多くの企業が既存のチェックシートをそのまま流用しており、AI特有のリスクが実務上まったく確認されていないケースが散見されます。
本記事では、AI開発委託において実務担当者が必ず押さえるべきチェックポイントと、現場で繰り返されている失敗パターンを解説します。現在進めているAI開発プロジェクトでも、同様のリスクは例外ではありません。
なぜ従来のチェックシートでは不十分なのか
従来のITシステム開発委託では、「アクセス管理」「NDA締結」「納品物の権利帰属」が主なチェック対象でした。しかしAI開発には、これらに加えて確認しなければならない領域が3つ追加されます。
| AI開発委託で新たに必要なチェック領域 |
|---|
| ① データの「使われ方」リスク → 学習データが外部AIに再利用されないか |
| ② モデルの「外部送信」リスク → 入力データが委託先・APIベンダーに送信されないか |
| ③ 成果物の「権利」リスク → AIが生成したコードやモデルの知的財産権は誰のものか |
IPAが実施した「ITサプライチェーンにおける情報セキュリティの責任範囲に関する調査」によれば、新たな脅威が顕在化した際の対応を契約書等に明記していない企業は約8割に達します。インシデント対応の記載がない企業も6割強にのぼり、「何かあってから初めてルールを決める」状態が常態化しています。
AIは開発段階から大量のデータを扱い、外部APIと常時連携します。このため、「契約時に責任範囲を明確にしない」ことのリスクは、従来のシステム開発より格段に高くなっています。
AI開発委託で必ず確認すべき5つのリスク
① データの再学習リスク
多くの外部AIサービスでは、無償・低価格プランを利用する場合、入力データがモデルの再学習に使用される設定がデフォルトになっています。担当者が意識しないまま機密情報や個人情報を含むデータを送り続けている、というケースは珍しくありません。すでに自社の委託環境で同様の構造になっている可能性があります。
- APIベンダーのデータ保持期間と再学習利用の有無を確認していますか？
- 再学習に利用されない設定（オプトアウト）が有効になっているか
- 契約書にデータ利用禁止条項が明記されているか
② 外部サービスへの入力データ送信リスク
生成AIや外部APIを利用する開発では、入力データが開発者も把握していない経路で海外サーバーに送信されているケースがあります。個人情報保護法やGDPRの観点から、データの越境移転には事前確認が必要ですが、APIの仕様変更で送信先が変わることもあります。
- 入力データの送信先（国・サーバー）を把握していますか？
- 海外へのデータ移転がある場合、法令上の要件を満たしているか
③ 学習データの権利・出所リスク
AIモデルの学習に使用するデータの出所が不明確な場合、著作権侵害や個人情報の無断利用につながります。特にウェブスクレイピングで収集したデータや第三者提供のデータセットは、ライセンス上の問題が後から発覚するリスクがあります。
- 学習データの出所と利用許諾が明確か
- 個人情報を含む場合、適切な同意が取得されているか
④ 成果物の知的財産権リスク
AIが生成したコード、モデルの重みパラメータ、学習済みモデルなど、成果物の権利帰属は契約で明確にしなければなりません。契約が曖昧なまま開発が進んだ結果、委託先が同等のモデルを競合他社に提供していたという事例が実際に報告されています。
- AIが生成した成果物の知的財産権の帰属が契約で明確か
- 学習済みモデルの独占使用権の範囲が定義されているか
⑤ 再委託先（2次・3次）の管理リスク
委託先が業務の一部を再委託するケースは少なくありません。委託元が把握していない2次・3次委託先からの情報漏洩は、インシデント発生後に初めて発覚するという構造的な問題があります。
- 再委託の有無と委託先が契約で明確にされているか
- 再委託先も同等のセキュリティ基準を満たしているか
実務で使えるチェック項目：AI特有の確認事項
以下は、AI開発委託において従来のチェックに「追加すべき」重要項目の一部です。特にリスクの高い項目を優先度順に抜粋しています。
| No. | 確認項目（実務での質問形式） | なぜ重要か |
|---|---|---|
| 1 | APIベンダーのデータ保持期間と再学習利用の有無を確認していますか？ | 意図しない学習利用・漏洩防止 |
| 2 | 入力データがどの国・サーバーに送信されるか把握していますか？ | 越境移転・法令遵守リスク |
| 3 | データが再学習に利用されないオプトアウト設定を有効にしていますか？ | 機密情報の外部流出防止 |
| 4 | 学習データの出所と利用許諾が明確か | 著作権・個人情報リスク |
| 5 | AIが生成した成果物の知的財産権の帰属が明確か | 権利トラブルの予防 |
| 6 | 再委託の管理がされているか（2次・3次含む） | サプライチェーン全体のリスク管理 |
| 7 | OSSモデル利用時にライセンスを確認しているか | 商用利用不可モデルの誤利用防止 |
| 8 | データの削除ポリシーと削除証明の取得ができるか | プロジェクト終了後のリスク管理 |
よくある失敗パターン
AI開発委託の現場では、以下のような失敗が繰り返されています。
失敗①：NDAだけ締結して安心してしまう
NDAは秘密情報の漏洩を防ぐための契約ですが、「データの利用範囲」「再学習への使用禁止」「再委託先への適用」は別途定めが必要です。NDAを締結していても、データが委託先のAIサービス改善に使われたという事例は実際に発生しています。
失敗②：データの利用範囲を定義しないまま委託する
「開発に必要なデータを渡す」という口頭合意だけでは、委託先がそのデータをどの範囲で使用できるかが不明確です。開発完了後のデータ削除義務や削除証明の要求も、事前に契約で定めておく必要があります。
失敗③：既存のチェックシートをそのまま流用する
従来の「システム開発委託」用のチェックシートには、AI特有のリスク（再学習・外部送信・OSSライセンス）が含まれていません。担当者が「チェックした」という安心感だけが残り、実質的なリスクが見落とされます。
失敗④：チェック結果が担当者の個人管理になる
ExcelとメールでチェックシートをやりとりするEC運用では、「誰がいつ確認したか」「最新版はどこにあるか」という情報が担当者の手元にしか存在しない状態になります。担当者が異動・退職した際に、チェックの経緯が失われます。
ExcelとメールによるCheckシート管理の限界
多くの企業でセキュリティチェックの運用実態は、ExcelシートをメールやチャットでやりとりするExcel管理に留まっています。この方式が抱える構造的な問題は3点あります。従来のチェックやExcel管理では、AI開発委託特有のこのレベルのリスクまではカバーできません。
| Excel管理の3つの構造的問題 |
|---|
| ① 属人化：担当者の手元にのみ最新版が存在し、異動・退職で引き継ぎが困難になる |
| ② 分散：メール・チャット・ファイルサーバーに情報が散在し、最新状態が把握できない |
| ③ 形骸化：「送ればよい」「返ってくればよい」という形式的な運用になりやすく、リスク分析が行われない |
特にAI開発委託では、複数の委託先・再委託先・外部APIサービスとのやりとりが同時並行で発生します。Excel管理では、どの委託先のチェックがどのステータスにあるかを一元的に把握することが、構造的に困難です。
解決策：チェックを「標準化」し「可視化」する
AI開発委託のセキュリティチェックを機能させるには、以下の3点が必要です。
- AI特有のリスク項目を網羅したチェックシートを使う（従来の流用ではなく専用設計）
- チェックの送付・回収・進捗を一元管理し、担当者依存をなくす
- チェック結果を記録として蓄積し、継続的なモニタリングを可能にする
まとめ
AI開発委託のセキュリティチェックは、従来のIT委託管理とは異なる専門的な視点が必要です。
- データの再学習・外部送信・権利帰属はAI固有のリスクであり、従来のチェックでは見落とされやすい
- NDAだけでなく、データ利用範囲・削除義務・再委託管理を契約で明確にする
- ExcelとメールによるExcel管理は構造的に属人化を招き、形骸化しやすい
- チェックの標準化・可視化・継続的モニタリングが、実効性のあるセキュリティ管理の基盤となる
「チェックシートを送ること」が目的化してしまうと、本来のリスク低減にはつながりません。AI開発委託のリスクを実務として管理するための第一歩として、チェック体制の見直しをご検討ください。
【出典】
IPA独立行政法人情報処理推進機構「ITサプライチェーンにおける情報セキュリティの責任範囲に関する調査」（2018年度）