AIに書かせたコードは、動いていても安全とは限りません。 本番に出す前に、入力と出力の処理、ログインと権限、秘密情報の置き場所、データの消え方とバックアップ、使っているライブラリの5項目を確認してください。

自分で確認しきれない部分は、ソースコード診断を専門会社に、修正を開発会社に、分けて頼むのが確実です。

AIで作ったシステムは何が危ないのか?

AIで作ったシステムが危ないのは、画面どおりに動くので問題がないように見え、安全でない書き方が残ったまま本番に出やすいことです。作った本人がコードの中身を把握していないため、どこに問題があるかを自分で探せないことも重なります。

HTMLとSVGのコードが並ぶ開発画面の実写写真
開発画面の参考写真。HTMLとSVGが写っており、AI生成コードやwrenの作業画面ではありません。 写真:Florian Olivo / Unsplash(Unsplash License)。

米Veracodeが2025年7月に公表した検証では、80の課題を100以上の大規模言語モデルに解かせたところ、45%で安全でない書き方が選ばれ、セキュリティ上の欠陥を含むコードが生成されました。クロスサイト・スクリプティング(画面に悪意のあるスクリプトを埋め込まれる欠陥)への対策は86%で抜けていました(Veracode)。用意された課題での検証なので、実際のシステムで同じ割合になるとは限りませんが、AIが安全な書き方を選ぶとは限らないことは分かります。

国内では、IPAが2026年1月に公表した「情報セキュリティ10大脅威 2026」の組織編で、「AIの利用をめぐるサイバーリスク」が初めて選ばれ、3位に入りました(IPA)。

データの消え方も問題になります。2025年7月には、米国の起業家が試していたReplitのAIエージェントが、変更しないよう指示されていたにもかかわらずデータベースを消去したと報じられました。当時のReplitは、開発用と本番用で同じデータベースを使う構成でした(eWeek)。

修正を頼む側の動きも出ています。2026年3月には、受託開発者のXの投稿で、AIで書いたと思われるコードのバグ修正の依頼がココナラで増え、受託案件が倍になったという内容が2,700件以上のいいねを集めました(X、いいね数は2026年10月23日時点)。

本番に出す前に何を確認するか?

本番に出す前に確認するのは、入力と出力の処理、ログインと権限、秘密情報の置き場所、データの消え方とバックアップ、使っているライブラリの5項目です。社外の人が使う、個人情報や決済を扱う、といったシステムほど、すべて確認してから公開してください。

本番前に確認する5項目
項目確認することよくある問題
入力と出力の処理フォームやURLから受け取った値を、そのままデータベースや画面に渡していないかSQLインジェクション、クロスサイト・スクリプティング
ログインと権限URLやIDを書き換えると、他人のデータが見えないか画面では隠れているが、APIからは取得できる
秘密情報の置き場所APIキーやパスワードがコードやブラウザに出ていないか公開リポジトリやフロントエンドのコードにキーが入っている
データの消え方とバックアップ本番のデータを、開発中の操作で消せる状態になっていないか開発と本番で同じデータベースを使っている
使っているライブラリ古い版や、サポートの切れた版を使っていないかAIが学習時点の古い書き方・古い版を使う

1行目の入力と出力の処理は、IPAの「安全なウェブサイトの作り方」(改訂第7版)が扱う11種類の脆弱性と、付属のセキュリティ実装チェックリスト(Excel)で項目ごとに確認できます(IPA)。

下のIPAの図は、入力値がデータベースへの命令として扱われ、情報漏えいやデータの消去・改ざんにつながる流れを示しています。画面が正しく表示されるかだけでなく、受け取った値をプログラムがどう処理するかを確認する必要があります。

IPAのSQLインジェクション説明図。不正な入力がデータベースへの命令になり、情報漏えい・消去・改ざんを起こす流れ
引用:IPA「安全なウェブサイトの作り方」改訂第7版、1.1 SQLインジェクションの説明図。引用・転載の利用条件。 図の内容は変更していません。画像を選ぶと拡大できます。

2行目のログインと権限は、AIで作ったシステムで見落とされやすい項目です。画面にボタンが出ていなくても、裏側のAPIを直接呼べば他人のデータが取れる、という作りになっていないかを確認します。

ライブラリの更新や権限の管理を、本番に出したあとも続ける方法はWebサービス事業者のセキュリティ対策で整理しています。

ソースコード診断とWeb診断はどう使い分けるか?

AIで作ったシステムを確認するなら、ソースコード診断が向いています。Web診断は動いているサイトに外から通信を送って弱点を探す方法で、ソースコード診断はプログラムそのものを読んで危ない書き方や設定を探す方法です。

Web診断(外から試す)

  • 動いているサイトに通信を送って、反応から弱点を探す
  • ソースコードを渡さなくても受けられる
  • 画面から届かない処理は見つけにくい

ソースコード診断(中を読む)

  • プログラムと設定を読んで、危ない書き方を探す
  • ソースコードへのアクセスが必要
  • 秘密情報の置き場所や権限の作りも確認できる
Fig. 01 — 2つの診断の違い

AIで作ったシステムは、作った本人もどこに何が書かれているかを把握していないことが多く、外から試すだけでは問題の場所を特定しにくいためです。個人情報を扱うシステムなら、両方を受けておくとより確実です。

診断の費用と、診断後の修正費用が何で変わるかは脆弱性診断の費用相場で扱っています。

修正を頼むときは何を渡せばよいか?

修正を頼むときに渡すのは、ソースコードへのアクセス、動かしている環境、扱っているデータの種類、AIに出した指示の履歴、困っている症状、期限の6つです。中でも、AIに出した指示の履歴があると、どこまでが意図した動きで、どこからがAIの判断だったかを修正する側が切り分けられます。

資料をそろえる

ソースコードへのアクセス、環境(サーバーやクラウドのサービス名)、扱うデータの種類、AIへの指示の履歴

診断を受ける

専門会社にソースコード診断やWeb診断を頼み、指摘を報告書で受け取る

修正を頼む

報告書と資料を開発会社に渡し、直す範囲と期限を決める

直ったかを確かめる

修正後に再診断を受けるか、指摘箇所を再確認する

Fig. 02 — 修正を頼むときの流れ

診断と修正を同じ会社に頼む必要はありません。診断した会社が修正まで請け負わないことも多いため、報告書を受け取ったあとに修正先を探すと時間がかかります。診断を頼む前に、修正をどこに頼むかも決めておくと、公開までの期間が読めます。

修正後の保守まで外に頼む場合は、Webサイト・システム保守の費用と、保守契約で頼めることを参考にしてください。

弊社がAIでコードを書くときに決めていること

以下は導入企業の事例ではなく、弊社自身の運用です。弊社のコーポレートサイトとブログでは、変更の多くをAIエージェントが作り、人がレビューしてから本番に反映しています。AIが本番に直接反映することはありません。

AIに任せる作業は、失敗したときに取り返しがつくかどうかで「自動可・要レビュー・手動のみ」の3つに分けています。コードは要レビューで、AIは変更案(プルリクエスト)を作ったところで止まり、人が確認してから反映します。記事を追加する変更案には、内部リンク切れや必須項目の抜けを機械的に調べるチェックが自動で走り、エラーが残っていれば反映しない運用にしています。線引きの詳細は深夜2時に働くAI社員に書きました。

AIで作ったシステムの確認・修正はどこに頼めるか?

wrenは脆弱性診断の専門サービスを提供していません。第三者としての診断は専門会社に頼んでください。AIで作ったシステムのコードを読んで、本番に出す前の修正や、診断で指摘された箇所の修正を行う作業は、業務システムの受託開発として承ります。

対応範囲は、対象の技術、ソースコードにアクセスできるか、元の作成者との分担を伺ってから決めます。開発相談フォームから、システムの概要、困っている症状、希望の期限をお知らせください。APIキーなどの秘密情報は、最初の問い合わせには含めないでください。

まとめ

AIで作ったシステムは、動いていても安全とは限りません。米Veracodeの2025年の検証では、AIが生成したコードの45%にセキュリティ上の欠陥が入りました。

本番に出す前に、入力と出力の処理、ログインと権限、秘密情報の置き場所、データの消え方とバックアップ、使っているライブラリの5項目を確認してください。自分で確認しきれない部分は、ソースコード診断を専門会社に、修正を開発会社に分けて頼み、修正先は診断を頼む前に決めておきます。