この記事は、システムやアプリの開発を外部へ委託している中小企業の経営者と、社内に開発者がいない状態で発注を担当している方に向けたものです。AI生成コードのセキュリティを扱う記事は、その多くが開発者向けに書かれています。静的解析ツールの導入、継続的な脆弱性スキャン、シニアエンジニアによるレビュー体制。いずれも社内に開発者がいる前提です。発注側の視点で書かれたものは少数です。この記事では、技術者でなくても確認できる項目、契約に入れるべき条項、検収時の質問を並べました。どんな問題が起きるかと、それが自社に何をもたらすかまでは扱います。コードの読み方と修正方法は扱いません。
結論
AI生成コードへの対応で、発注側に技術的な検査能力は求められません。必要なのは、確認された記録を求めること、契約に条項を入れること、そして回答の明確さで判断することです。
IPA（独立行政法人情報処理推進機構）の「情報セキュリティ10大脅威 2026」では、組織向けの2位が「サプライチェーンや委託先を狙った攻撃」、3位が「AIの利用をめぐるサイバーリスク」で、後者は2026年の初選出です。委託先とAIの両方が、いま組織が向き合う上位の脅威として並んでいます。（出典: IPAの情報セキュリティ10大脅威 2026、確認日: 2026年9月5日）
「AIで作った」は品質の説明にならない
開発の見積もりや提案で「AIを活用して短期間・低コストで」という説明を受けることが増えています。開発が速くなること自体は事実です。ただしそれは品質の説明ではありません。
AIを使ったかどうかは、確認すべき項目を変えません。従来と同じことを確認する必要があります。変わるのは、確認の手間が増える点です。生成される量が多くなるため、レビューされないまま納品される割合が上がりやすくなります。つまり発注側がやることは、AI特有の高度な検査ではありません。従来から必要だったが省略されがちだった確認を、きちんと求めることです。
AI生成コードで起きやすい5つの問題
技術的な詳細は不要ですが、何が起きうるかは知っておくと質問しやすくなります。
| 起きやすい問題 | なぜ起きるか | 発注側への影響 |
| 誰が見てよいかの判定が抜ける | AIは動くコードを優先し、その利用者に見せてよいかの判定を書き落とすことがある | 会員や取引先の情報が、別の利用者や未ログインの訪問者から見える |
| 入力された文字をそのまま処理する | 利用者が入力する値を安全なものとみなした実装が生成されやすい | フォームから不正な指示を送られ、データを抜かれる、または書き換えられる |
| 存在しない部品を使っている | AIが実在しない外部部品の名前を出すことがある | 動かない、または後から差し替えが必要になる |
| 古い書き方が混ざる | 学習した情報が古い場合がある | 既知の弱点を含んだまま公開される |
| 秘密情報がコードに書き込まれている | 接続情報を直接書く例が生成されやすい | 第三者に見られる場所へ流出する |
Veracodeが2025年7月に公表した調査では、100を超えるLLMが生成したコードのうち45%がセキュリティテストに不合格となり、言語によっては72%に達しています。GitHub Copilotを対象にした2021年の研究でも、89の課題で生成された1,689本のうちおよそ40%に脆弱性が見つかりました。（出典: Veracodeの調査、Pearceらの研究、確認日: 2026年9月5日）
5番目は発注側にも実害が出やすい項目です。管理画面のパスワードや外部サービスの接続情報が、コードの中に直接書かれた状態で納品されることがあります。この状態は、コードを見られた時点で侵入されます。
2025年に公表された調査では、16のコード生成AIに57万6千件のコードを作らせたところ、実在しないパッケージを参照した割合が商用のモデルで5.2%以上、公開モデルで21.7%ありました。存在しない部品の参照が、例外ではなく一定の割合で起きることを示した数字です。（出典: Spracklenらの研究、確認日: 2026年9月5日）
いずれも「AIだから危険」ではなく、確認されなければ残る、という性質のものです。確認の仕組みがあるかどうかが分かれ目になります。
発注側が確認できること
コードを読めなくても確認できる項目があります。次の5つは、資料の有無と説明の明確さだけで判断できます。
1｜テストの有無と範囲
どの部分を、どうやって確認したか。テストの記録を求めます。「動作確認しました」だけでは範囲が分かりません。少なくとも、ログイン、権限の切り替え、データの登録と更新、エラー時の挙動について、確認した記録があるかを見ます。
2｜外部部品の一覧と更新方針
システムは外部の部品を組み合わせて作られます。その一覧と、それぞれの版が分かる資料を求めます。あわせて、部品に弱点が見つかったときに誰がいつ更新するのかを、契約の範囲として確認します。ここが決まっていないと、納品後に放置されます。この一覧はSBOM（ソフトウェア部品表）と呼ばれる資料です。見積書や発注書にこの語で書くと、開発会社に意図が伝わりやすくなります。
3｜秘密情報の管理方法
パスワードや接続情報が、コードの中に直接書かれていないかを質問します。「設定ファイルや環境変数で管理しています」という回答が得られるはずです。回答が曖昧な場合は、具体的にどこに置かれているかを説明してもらいます。
4｜誰が何を見られるかの設計
利用者の種類ごとに、見られる情報と行える操作を示した資料を求めます。管理者、一般利用者、未ログインの訪問者。この区別が資料になっていない場合、実装も曖昧である可能性が高くなります。
5｜AIの利用状況の申告
開発でAIを使ったかどうか、そして自社が渡した情報をAIへ入力したかどうかを確認します。後者が重要です。仕様書や既存のデータをAIサービスへ入力した場合、その扱いは自社の秘密保持の問題になります。
自社が生成AIへ何を入力してよいかを整理する考え方は生成AIの情報漏えいを防ぐ社内運用の作り方で扱っています。委託先へ求める基準も、自社の基準と整合させます。
契約書に入れる項目
納品後に交渉すると費用が発生するか、応じてもらえないことがあります。契約時に決めておく項目を挙げます。法務の確認は別途受けます。
経済産業省は2025年2月18日に「AIの利用・開発に関する契約チェックリスト」を公表しています。既存のAIサービスを使う利用型契約と、開発を伴う開発型契約に分けて、確認すべき契約条項が整理されました。以下の表はそのうち、技術者がいない発注側でも判断できる項目に絞ったものです。（出典: 経済産業省の公表ページ、確認日: 2026年9月5日）
| 項目 | 決めておく内容 |
| AI利用の申告 | 開発でAIを使う場合、その旨と使用範囲を報告する |
| 秘密情報の取扱い | 発注側が提供した資料やデータを、外部のAIサービスへ入力してよいか。可とする場合の条件 |
| 成果物の引き渡し | ソースコード、設計資料、外部部品の一覧、テスト記録、アカウント情報の引き渡し |
| 第三者の権利 | 成果物が第三者の権利を侵害していないことの保証と、侵害が判明した場合の対応 |
| 弱点が見つかった場合 | 納品後の一定期間、報告と修正に応じる範囲と期間 |
| 再委託 | 再委託の可否と、再委託先にも同じ条件を適用すること |
| 契約終了時 | 資料とアカウントの引き渡し、委託先側に残るデータの削除 |
2行目は従来の契約書に入っていないことが多い項目です。秘密保持契約があっても、AIサービスへの入力が第三者への開示にあたるかは解釈が分かれます。そのため契約書に明示するのが確実です。この点は法務の確認を受けたうえで文言を決めます。
3行目も見落とされます。特に外部部品の一覧とテスト記録は、引き渡しを明記しないと納品物に含まれません。将来ベンダーを変更するときに、ここがないと引き継ぎが困難になります。仕様が分からないシステムを抱えた場合の対処はブラックボックス化した基幹システムとどう向き合うかで扱っています。
検収時の質問リスト
そのまま使える質問です。技術的な知識は不要で、回答の明確さで判断できます。
この開発でAIを使いましたか。使った場合、どの範囲で使ったのかも聞きます。当社が提供した資料やデータを、外部のAIサービスへ入力しましたか。パスワードや接続情報が、コードの中に直接書かれていませんか。外部部品の一覧と、それぞれの版が分かる資料をいただけますか。外部部品に弱点が見つかった場合、誰がいつ更新しますか。どのようなテストを行い、その記録をいただけるか。管理者と一般利用者で、見られる情報と行える操作がどう違うかも説明してもらいます。ログインに失敗し続けた場合、どうなりますか。エラーが起きたとき、利用者の画面に内部の情報が出ませんか。納品後に弱点が見つかった場合、いつまで対応いただけますか。
回答が明確でない項目は、確認されていない可能性が高い箇所です。技術的に評価する必要はありません。「即答できるか」「資料があるか」で判断します。
9番目は具体的に確認する価値があります。エラー画面に内部の情報が表示される状態は、攻撃の手がかりを与えます。実際に画面を見せてもらいます。
第三者に見てもらうべきとき
質問リストで回答が曖昧だった場合や、扱う情報が重い場合は、開発を委託した先とは別の第三者に確認してもらう選択肢があります。ただし常に必要というわけではありません。判断の目安を示します。
| システムの性質 | 第三者確認の要否 |
| 社内だけで使い、外部から接続できない | 原則不要。質問リストで足りる |
| 外部に公開するが、個人情報を扱わない | 検収時の質問で回答が曖昧なら検討する |
| 個人情報を保存する | 検討する。特に問い合わせフォームや会員機能がある場合 |
| 決済や金銭のやり取りを扱う | 実施する |
| 取引先の情報を預かる | 実施する。契約上の要求がある場合も多い |
確認を依頼するときは、開発した会社とは別の会社へ依頼します。同じ会社に自社の成果物を確認させても、指摘が出にくくなります。費用の相場を示した公的な統計は見当たりません。参考として、GXO社の公表ページでは、AI生成コードの利用ルール策定を30万〜80万円、脆弱性診断とソフトウェア部品表の整備を80万〜300万円としています。これは同社のサービス価格であって市場の相場ではないため、複数社から見積もりを取り、範囲を先に決めたうえで比較します。
依頼するときは、確認してほしい範囲を先に決めます。「全部見てほしい」では費用が読めません。認証まわり、権限の分離、外部からの入力の扱い、秘密情報の保管方法。この4点に絞るだけでも、重大な問題の多くは拾えます。
社内に残す資料
納品時に受け取り、社内で保管する資料を決めておきます。担当者が交代しても引き継げる状態にすることが目的です。
ソースコードと、その置き場所。外部部品の一覧と版。テストの記録。利用者の種類ごとの権限を示した資料。外部サービスとの接続に使っているアカウントの一覧。パスワードは別管理にします。稼働している環境の情報として、サーバー、ドメイン、契約先。障害が起きたときの連絡先と、対応範囲も残します。
最後の2つは、開発とは別の運用の話です。開発の完了時にまとめて受け取っておかないと、後から集めるのは困難になります。IPA（独立行政法人情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン」第4.0版には、付録6として資産管理台帳のサンプルがあり、IPAの掲載ページから無償で入手できます。保管する様式として使えます。（出典の確認日: 2026年8月24日）
よくあるご質問
発注時にAIの利用有無を確認すべきですか
確認する意味はありますが、使っていないことを条件にする必要はありません。確認すべきなのは、生成されたコードに対して人がレビューとテストを行う工程があるかどうかです。利用の有無より、確認工程の有無が品質を左右します。
脆弱性診断はいつ受けるべきですか
外部からアクセスできる仕組みを公開する前が基本です。社内限定の仕組みでも、個人情報や決済に関わる場合は公開前に受けます。納品後にまとめて受けると、指摘が設計にさかのぼり、修正費用が大きくなります。
オープンソースのライセンス確認は必要ですか
必要です。生成されたコードが既存の実装に近い場合や、依存パッケージが自動的に追加されている場合があります。納品物に含まれる依存関係の一覧と、それぞれのライセンスを提出してもらいます。
納品後に脆弱性が見つかった場合、修正費用はどちらが持ちますか
契約に書いていなければ、多くの場合は発注側が費用を負担する有償の追加作業になります。だからこそ、報告と修正に応じる範囲と期間を契約時に決めます。経済産業省の契約チェックリストにも、責任分担を確認する項目があります。
今週着手するなら、進行中または次回の案件について、検収時の質問リストから該当する項目を選び、委託先へ送るところまでです。回答が曖昧な項目が、確認すべき箇所になります。
社内での生成AI利用のルール全体は生成AIの社内ルールに必要な項目で扱っています。
着手の順序に迷う場合は、お問い合わせからご連絡ください。
ここまでの整理を踏まえて、無料診断で現在の段階を確認できます。
無料診断をはじめる
