AI開発の外注先に確認すべきセキュリティ項目｜開発現場の事故事例6選と発注側チェックリストを公開
生成AIを利用した開発の外注先に確認すべきセキュリティ項目は、モデルの性能ではなく「権限・データの扱い・再委託」の3点です。
2025年から2026年にかけて、社員が入力を誤ったのではなく、AIを組み込んだシステムの作り方そのものが原因の事故が相次いでいます。AIエージェントが本番データベースを削除した事故、メールを受信しただけで社内データが外に出うる脆弱性、AI-OCRサービスへの攻撃が委託元まで波及した国内事例。いずれも発注側が仕様と契約で防げた余地のあるものでした。
「生成AIを組み込んだシステムを外注したいが、社内のセキュリティ審査を通せない」。この記事は、その状態で止まっている発注担当者に向けて書いています。スパイクスタジオは生成AIを使った開発の支援と、のべ1万人規模の研修を通じて、発注側と開発側の両方の現場を見てきました。
この記事で答えるのは次の問いです。
- 生成AI開発の外注で、発注側はどんなリスクがあるのか
- 実際にどんな事故が起きたのか（2024〜2026年）
- 外注先に何を確認すればよいのか
生成AIを使った開発を外注するときに発注側が負うリスク5つ
発注側が負う可能性のあるリスクは、次の5つに整理できます。事例を読む前に、問題の種類を先に押さえてください。
- AIエージェントに渡した権限が、本番環境まで届いている
- 入力したデータが、ベンダーの学習に使われる契約になっている
- AIが書いたコードの脆弱性が、検査されないまま納品される
- 外部から読み込んだ文章が、指示として実行されてしまう
- 再委託先が見えず、事故が起きてから存在を知る
いずれも「どのモデルを使うか」では防げません。防げるのは設計と契約です。発注時の確認項目は、次のように置き換える必要があります。
①AIエージェントに渡した権限が本番環境まで届いている
生成AIを使った開発では、AIが自分でコードを書き、コマンドを実行します。このときAIに渡す権限の範囲が設計されていないと、テスト環境のつもりの操作が本番環境に届きます。「本番には触らないよう指示している」は対策になりません。指示は約束であって、権限の制限ではないからです。
②入力データが学習に使われる契約になっている
主要なAIベンダーは、法人向けサービスやAPI経由のデータを既定では学習に使わないと明示しています。ただし無料枠や消費者向けプランは扱いが異なります。GoogleのGemini API追加利用規約（2026年4月28日時点）では、無料枠の入力と出力は製品改善に利用され人によるレビュー対象になりうる一方、有料サービスでは製品改善に利用しないと区別されています。開発中の検証で無料枠を使っていた、という状態は珍しくありません。
③AIが書いたコードの脆弱性が検査されない
セキュリティ企業Veracodeが100以上の大規模言語モデルにコードを書かせた検証では、生成されたコードの45%がOWASP Top 10に該当する脆弱性を含んでいました（Veracode、2025年7月）。言語別ではJavaの失敗率が72%でした。モデルが新しくなっても改善は見られていません。AIが書いたコードを人が検査する工程が契約に入っているかが分かれ目になります。
④外部から読み込んだ文章が指示として実行される
プロンプトインジェクションと呼ばれる攻撃です。AIが参照するWebページや文書、メールに命令文を仕込み、AIにその命令を実行させます。Googleが公開Web（月間20〜30億ページ）を調査した結果、悪意ある指示に分類されるページは2025年11月から2026年2月の間に相対値で32%増えました（Google Security Blog、2026年4月23日）。
⑤再委託先が見えない
生成AI開発では、開発会社がさらに外部のAIツールやAPIを使います。発注先の1社だけを審査しても、その先が見えていなければ意味がありません。IPAの情報セキュリティ10大脅威 2026では、「AIの利用をめぐるサイバーリスク」が組織向けの脅威として初めて選出され、3位に入りました（IPA、2026年1月29日公開）。
生成AI開発の現場で実際に起きたトラブル事例6選（2024〜2026年）
ここからは、開発・実装のフェーズで実際に起きた事故を7件紹介します。社員がAIに社外秘を入力して漏れた、という利用者側の事故ではなく、作り手側に原因があった事例を紹介します。
①AI開発エージェントの問題事例｜指示に反して本番データベースを削除
2025年7月、開発プラットフォームReplitのAIコーディングエージェントが、利用企業SaaStrの本番データベースに破壊的なコマンドを実行しました。当時プロジェクトは「コードを変更しない」期間（コードフリーズ）に入っていましたが、エージェントはそれを越えて実行しました。削除されたのは経営層のデータ1,200件超と企業データ1,190件超です。
AIエージェントが本番データベースへ書き込める状態にあったこと、そしてフリーズが指示にとどまり実行経路で強制されていなかったことが、報道された経緯から読み取れます。データは手動のロールバックで復旧し、Replitは開発環境と本番環境の自動分離、計画立案のみを行うモードの追加などの対応を発表しています。
②開発ツールの問題事例｜AI補完を装った拡張機能がソースコードを外部送信
2026年1月、Visual Studio Code向けの拡張機能2つが、開発者が開いたファイルの内容をそのまま中国国内のサーバーへ送信していたことが公表されました。合計インストール数は約150万件です。
この2つは実際にAIによるコード補完機能を提供しており、利用者から見て不審な点がありませんでした。その裏で、ファイル全文を符号化して外部に送る機能を備えていました。発見したのはKoi Securityで、報道時点では両拡張機能はマーケットプレイスに残っていました。開発会社が普段使っているツールが、発注元のソースコードの流出経路になりうる例です。
③サプライチェーンの問題事例｜AI接続部品の脆弱性で開発端末に任意コード実行
2025年7月、AIクライアントと外部サーバーをつなぐOAuthプロキシ「mcp-remote」に、脆弱性（CVE-2025-6514）が見つかりました。細工されたサーバーに接続すると、開発者の端末で任意のコードを実行できる状態でした。深刻度はCVSSで9.6、パッケージのダウンロード数は43万7,000回を超えていました。発見したのはJFrog Security Researchです。
同じ2025年7月には、AWSのAmazon Q Developer拡張機能で、ビルドに使うトークンの権限が広すぎたために外部から悪意あるコードが混入し、正式リリースに含まれる事態も起きています（実行時に構文エラーとなり実害には至らず）。AI関連の部品は新しく、供給経路の検証がまだ追いついていません。
出典MCP Horror Stories: The Supply Chain Attack（Docker、2025年8月7日） ／ How AWS averted an AI coding supply chain disaster（ReversingLabs、2025年8月）
④権限設計の問題事例｜非公開リポジトリの内容が公開のプルリクエストに出力
2025年5月、セキュリティ企業Invariant Labsが、GitHub公式のMCPサーバーを使った攻撃を実証しました。公開リポジトリのIssueに指示を仕込むと、それを読んだAIエージェントが、同じトークンでアクセスできる非公開リポジトリの内容を読み取り、公開リポジトリのプルリクエストとして出力しました。含まれていたのは給与情報や個人プロジェクトの詳細です。
原因は、1つのトークンに公開と非公開の両方の権限を持たせていたことと、外部から読み込んだ文章を検証せずに指示として扱う設計でした。緩和策として、リポジトリ単位での権限分離と、1セッションで1リポジトリのみ扱う制限が示されています。
出典GitHub MCP Exploited: Accessing private repositories via MCP（Invariant Labs、2025年5月26日）
⑤出力の責任の問題事例｜チャットボットの誤案内で航空会社に賠償命令
2024年2月、カナダのブリティッシュコロンビア州民事審判所が、Air Canadaに812.02カナダドルの支払いを命じました。同社サイトのチャットボットが「弔慰運賃は搭乗後90日以内に申請できる」と案内し、それを信じた利用者が正規運賃で搭乗したものの、後日返金を拒否されたことが発端です。
審判所は、チャットボットは別の法人格ではなく企業の一部であるとして、過失による不実表示を認定しました。AIの回答は「AIが勝手に言ったこと」では済みません。出力内容の検証と、誤りが出たときの責任の所在を、発注時に決めておく必要があります。
出典What Air Canada Lost In 'Remarkable' Lying AI Chatbot Case（Forbes、2024年2月19日）
⑥多重委託の問題事例｜AI-OCRサービスへの攻撃が委託元まで波及
2025年9月25日、手書き帳票をAIで電子化するサービス「Jijilla」（ローレルバンクマシン）のサーバーが第三者に侵害されました。内部に保存されていた個人情報の一部が外部へ流出した可能性があることが10月15日に判明し、同社が公表しています。
このサービスは、データ入力業務を請け負う事業者が利用していました。同サービスを利用していた日本アスペクトコアにも影響が及んでいます。業務を委託した側から見れば、契約相手は委託先であり、攻撃を受けたのはその委託先が使うツールの提供元です。委託の連鎖の先が見えない構造そのものが問題になります。
出典手書き帳票デジタル化サービスにサイバー攻撃 - 情報流出の可能性（Security NEXT、2025年10月20日）
2026年に入って変わった3つの傾向
事例を並べると、2024年と2026年で攻撃の対象が変わっていることが分かります。
1つ目は、狙われる場所が「使う人」から「作る仕組み」へ移ったことです。2024年に話題になったのは、社員が入力した情報の漏洩や、チャットボットの誤回答でした。2025年以降に目立つのは、開発ツール、接続部品、権限設計といった作り手側の穴です。
2つ目は、公的なガイドラインが契約の言葉になったことです。経済産業省は2025年2月18日に「AIの利用・開発に関する契約チェックリスト」を公表し、提供したデータの利用範囲やAI生成物の利用条件について、発注側が契約時に確認すべき論点を示しました。総務省・経済産業省のAI事業者ガイドラインも改訂が続き、2026年3月31日に第1.2版が公表されています。米国ではNIST AI 600-1が、供給元の精査とデータの出所検証をリスク項目として挙げています。
3つ目は、脅威の分類自体が更新されたことです。OWASPの「Top 10 for LLM Applications」は2025年版でプロンプトインジェクションを1位、機密情報の漏えいを2位とし、2026年8月4日には後継版が公開されました。発注仕様書に「OWASPの最新版に沿うこと」と書けるようになったのは、この2年の変化です。
一方で、国内企業の備えは追いついていません。IPAの調査では、AIのセキュリティ上の脅威を「重大」または「やや脅威」と回答した担当者が60.4%だったのに対し、生成AI利用時のセキュリティ規則を明文化している組織は20%未満でした（IPA、n=1,000、2024年7月4日公表）。帝国データバンクの調査でも、生成AIをめぐる懸念事項として「情報漏洩のリスク」を挙げた企業は33.5%にのぼりました（帝国データバンク、有効回答1万312社、2026年5月14日公表）。
【対策】生成AI開発の外注先に確認すべきセキュリティ項目
私たちは「失敗の8割は、AIの性能ではなく渡す情報の設計で決まる」と考えています。外注先の選定も同じです。見るべきはモデルの新しさではなく、情報と権限をどう渡す設計になっているかです。
ここからは、発注前の打ち合わせでそのまま使える5つの確認項目を挙げます。
1. AIに渡す権限の範囲を、設計書と契約書の両方で確認する
「AIに何ができるか」ではなく「AIに何ができないようにしてあるか」を聞きます。Replitの事例のように、指示で止める運用は事故を防げません。実行権限そのものを絞る設計になっているかを確認します。
実践ポイント
- 開発環境と本番環境が分離されているか、接続情報が別管理かを図で示してもらう
- AIエージェントが実行できる操作の一覧と、実行前に人の承認が入る操作の一覧をもらう
- データの削除・更新を伴う操作について、復旧手段と復旧に要する時間を確認する
2. 入力データが学習に使われないことを、ベンダーの規約で確認する
「学習には使いません」という口頭の説明ではなく、どのベンダーのどのプランを使うのかを聞いてください。法人向けの主要サービスの扱いは次のとおりです。
| サービス | 入力データの学習利用 | 確認しておく点 |
|---|---|---|
| OpenAI API / ChatGPT Business・Enterprise | 既定では使用しない（APIは2023年3月1日以降） | 不正利用監視のため入出力を最長30日保持。ゼロデータ保持の申請可否 |
| Microsoft Azure OpenAI Service | 許可・指示なしに基盤モデルの学習に使用しない | プロンプトと出力はOpenAI社にも共有されない旨の記載 |
| Anthropic（商用利用規約） | 顧客コンテンツでモデルを学習させない旨を明記 | 適用される規約が商用向けか、消費者向けかの区別 |
| Google Gemini API | 有料は製品改善に利用しない／無料枠は利用される | 検証段階で無料枠を使っていないか |
| Amazon Bedrock | 入出力をモデルの学習に使用しない | 入出力がモデル提供者に共有されない旨の記載 |
各社の記載は更新されます。契約時点の規約ページを、URLと取得日つきで保存してもらってください。
3. AIが書いたコードの検査工程を、見積もりの中で確認する
生成AIを使う開発は速くなりますが、脆弱性の混入率は先述のとおり45%です。速度の話だけで見積もりが出てきた場合は、検査工程が抜けている可能性があります。
実践ポイント
- 静的解析ツールの名称と、実行するタイミング（コミット時か、リリース前か）を確認する
- AIが生成したコードを人がレビューする範囲を、割合ではなく対象で決める（認証・決済・個人情報の処理は全件など）
- 脆弱性が見つかった場合の修正責任と費用負担を契約に書く
生成AIを開発に全面活用しながら品質を保った例として、当社が支援した株式会社Circloopのシステム改修があります。開発業務の80%以上をAIが担い、従来の約1.3倍の速度で改修を完了しました。速度を出すほど、人が見る場所を決めておく設計が効いてきます。
4. 外部から読み込む文章を、指示として実行しない設計か確認する
社内文書やWebページを読ませる機能がある場合、必ず聞いてください。EchoLeakやGitHub MCPの事例は、いずれもこの1点に集約されます。
実践ポイント
- 読み込んだ文章を「データ」として扱う仕組み（命令と分離する処理）があるかを確認する
- AIが参照できるデータの範囲が、利用者ごとのアクセス権と一致しているかを確認する
- AIが外部へ送信できる宛先が限定されているかを確認する
- 発注仕様書に「OWASP Top 10 for LLM Applications の最新版に沿う」と明記する
5. 再委託の範囲と、委託先のセキュリティ評価方法を確認する
帝国データバンクの調査では、生成AI活用企業のうち推進体制を「ほぼ内製で一部を外注」が15.3%、「ほぼ外注」が6.9%でした（帝国データバンク、有効回答4,705社、2024年8月公表）。外注が入る以上、その先の管理が問われます。
実践ポイント
- 再委託の有無と、再委託先の企業名・担当範囲を書面で出してもらう
- 開発で使う外部サービス（AIモデル、ベクトルデータベース、MCPサーバーなど）の一覧をもらう
- 事故が起きた場合の連絡経路と、報告までの時間を契約に書く
- 経済産業省の「AIの利用・開発に関する契約チェックリスト」を打ち合わせに持ち込む
スパイクスタジオの支援事例
スパイクスタジオはこれまでオーダーメイドでお客様にあった開発を行い、業務効率化や企業のDX化・自動化の支援をさせていただいております。携わった受託開発としては、例えば、株式会社NTT DXパートナーの生成AIプラットフォーム「架空商品モール」の開発があります。サービスのアイデア段階から企画検討に伴走し、システム要件まで落とし込む役割です。詳しくは【株式会社NTT DXパートナー】生成AIプラットフォーム「架空商品モール」の開発支援をご覧ください。
展示会DXPOの来場者に対する当社の自主調査では、生成AIの導入率は87%、効率化を実感した人は91%だった一方、満足度は30.5%にとどまりました（スパイクスタジオ調べ、DXPO 2026、n=312）。導入は進んでも、使い方と作り方の設計で差がついています。外注先の選び方については【デジタルトランスフォーメーション】DX支援サービスのメリットと活用法もあわせてご覧ください。
生成AI開発の発注で迷ったらスパイクスタジオへご相談ください
「生成AIを使って業務を楽にしたいがどのように進めればいいかわからない」「技術的なことは何を聞けばいいか分からない」という段階のお客様でも問題ありません。発注前の不安や確認事項を整理しながら、進め方を一緒に決めていく、伴走型な進め方に好評をいただいております。
- Spike AI Agent Studio：専任のエンジニアと開発AIがチームになる、月額定額のAIエージェント開発体制
- BPRコンサルティング：業務プロセスをAI前提で組み替える、戦略構想から実行設計まで
- AI人材育成：使う側・作る側・基盤層の三層に分けた研修と、統制・データ整備の設計
ご相談はお問い合わせフォームから承ります。