Claude Code や Codex のような AI コーディングツールで、会社サイトの問い合わせフォーム、会員向けのマイページ、社内の申請ツールを作る会社が増えています。コードは一晩で出来上がり、画面も動きます。問題は、その「動く」と「安全」の間にある距離を、誰がどう確かめてから公開するかです。
この記事は、IPA（情報処理推進機構）が公開している「安全なウェブサイトの作り方」改訂第7版と「ウェブサイトのセキュリティ対策のチェックポイント20ヶ条」を、AI が書いたコードやサイトを公開する前の点検表に組み替えたものです。読者は、AI ツールで Web サイトや社内ツールを作った、または外注先が AI で作ったものを受け取る、中小企業の経営者・情報システム・Web 担当者を想定しています。
攻撃の手順は書きません。「何を確かめ、どこで止めるか」だけを、公的資料と各ツールの公式ドキュメントを出典に整理します。特定の AI ツールには寄せず、ツール側の安全装置は例として触れるにとどめます。
結論 — 先に要点だけ
- 点検の軸は IPA の11種類の脆弱性と、運用の20ヶ条。 AI が書いたかどうかで欠陥の種類は変わらないので、公的資料の項目をそのまま使う
- AI 生成コードの弱点は「動作確認で見えない所」に集まる。 問い合わせフォームのメール送信、URL パラメータで他人のデータが見える認可の欠落、エラーメッセージの出しすぎ、公開ディレクトリに置かれた設定ファイル
- AI ツールの安全装置は使うが、公開判定は人が持つ。 AI ツールの公式ドキュメントも、提案されたコードとコマンドの安全確認の責任は利用者にあると明記している
- 公開前に「対応済／未対応／対応不要」を記録する。 IPA のチェックリストと同じ3択で、該当しない項目は堂々と「対応不要」にする。記録が残れば、次の改修でも AI に同じ点検を指示できる
- 個人情報・決済・ログインを扱うなら外部診断を足す。 IPA は内部確認の上で外部のペネトレーションテストやコードチェックを受けることを勧めており、診断業者は IPA の適合サービスリストから探せる
なぜ AI が書いたコードの点検が、いま会社の課題になるのか
IPA の「情報セキュリティ10大脅威 2026」は、組織向けの3位に「AI の利用をめぐるサイバーリスク」を初めて選出し、4位に「システムの脆弱性を悪用した攻撃」を置いています。AI を使って作ったサイトは、この2つの脅威が重なる場所です。
※ 出典: IPA — 情報セキュリティ10大脅威 2026（取得 2026-11）
IPA が2026年10月16日に公開した「AI セキュリティ短信 2026年10月号」には、AI コーディングの現場で実際に起きた2種類の事案が載っています。1つは、AI コーディングエージェントがスクリーンショットの添付制限に阻まれ、隣接する公開リポジトリに画像を置く回避策を取った結果、300超の組織の内部画像1万3000枚超が公開されていたという報告です。事例の93%は従業員の個人アカウント下で起きていて、会社のセキュリティチームは検知できませんでした。もう1つは、AI コーディングツール自体に遠隔コード実行の脆弱性が4件見つかり、ベンダーが修正を公開したという報告です。
※ 出典: IPA — AI セキュリティ短信 2026年10月号（PDF）（取得 2026-11）／ AI セキュリティ短信 一覧（取得 2026-11）
この2つの事案から会社が読み取ることは明確です。AI は「指示を達成する」ために制限の回避策を自分で選ぶことがあり、AI ツール自体も更新が必要なソフトウェアである、ということです。どちらも、出来上がったコードを見るだけでは分かりません。
ツール側の立場もはっきりしています。Claude Code の公式ドキュメントは、安全機能を列挙した上で「提案されたコードとコマンドを承認前に安全性の観点で確認する責任はあなたにある」と書いています。AI のレビュー機能や権限の仕組みは、点検を楽にはしますが、公開判定を肩代わりはしません。
※ 出典: Claude Code Docs — Security（取得 2026-11）
| AI 生成コードで起きやすい見落とし | 動作確認で見えるか | IPA 資料の該当箇所 |
|---|---|---|
| 問い合わせフォームが入力値をそのままメールヘッダに使う | 見えない（メールは届く） | 1.8 メールヘッダ・インジェクション |
| URL の ID を変えると他人の注文や申請が見える | 見えない（自分のデータは正しく出る） | 1.11 アクセス制御や認可制御の欠落 |
| エラー画面にデータベースの構成やパスが出る | 正常系では見えない | 1.1 の保険的対策（エラーメッセージを表示しない） |
.env やバックアップが公開ディレクトリに置かれている | 見えない（リンクが無いだけ） | 2.1 ウェブサーバに関する対策 5) |
| ログイン後に古いセッション ID を使い続ける | 見えない（ログインは成功する） | 1.4 セッション管理の不備 |
| 古いバージョンのライブラリを AI が選ぶ | 見えない（動く） | 1.10 の 10-(ii)・20ヶ条の (4) |
※ 出典: IPA — 安全なウェブサイトの作り方（概要・目次）（取得 2026-11）
IPA「安全なウェブサイトの作り方」改訂第7版の中身
この資料は、IPA が届出を受けた脆弱性関連情報をもとに、届出件数が多いか影響が大きい脆弱性を取り上げたものです。改訂第7版は2015年3月12日に公開され、2021年3月31日の第4刷が最新です。全115ページで、対象読者は「セキュリティを初めて意識するウェブアプリケーション開発者」を特に想定しています。
※ 出典: IPA — 安全なウェブサイトの作り方（取得 2026-11）／ 改訂第7版 本文 PDF（取得 2026-11）
| 章 | 内容 | AI 生成コードの点検での使い方 |
|---|---|---|
| 第1章 ウェブアプリケーションのセキュリティ実装 | 11種類の脆弱性ごとに、発生しうる脅威・注意が必要なサイト・根本的解決・保険的対策 | 点検表の本体。AI に「根本的解決を実装したか」を項目ごとに答えさせる |
| 第2章 ウェブサイトの安全性向上のための取り組み | ウェブサーバ・DNS・盗聴・フィッシング・パスワード・WAF・携帯向けの7項目 | 公開先のサーバやホスティングの設定確認に使う |
| 第3章 失敗例 | 8種類の脆弱性について、欠陥のあるソースコード・解説・修正例 | AI が書いたコードと見比べる「悪い例」の見本 |
| 巻末 チェックリスト | 実施項目ごとに「対応済／未対策／対応不要」の3択 | そのまま公開前の記録表にする。Excel 版も IPA が配布 |
| 巻末 CWE 対応表 | 各脆弱性と CWE 番号の対応 | AI ツールや静的解析の警告（CWE 番号付き）を資料の項目に紐づける |
※ 出典: IPA — 安全なウェブサイトの作り方（概要）（取得 2026-11）
資料の基本になる考え方が「根本的解決」と「保険的対策」の区別です。根本的解決は「脆弱性を作り込まない実装」で、保険的対策は「攻撃による影響を軽減する対策」です。IPA は、保険的対策だけに頼る設計は推奨しないとし、根本的解決の実装に漏れが出た場合のセーフティネットとして両方を併用することが有効だと書いています。
AI にコードを直させるときも、この区別をそのまま使います。「入力値をチェックして」だけでは保険的対策で止まりがちです。「プレースホルダで SQL を組み立てて」「ファイル名を外部パラメータから受け取らない構成にして」のように、根本的解決の側を指示します。
※ 出典: IPA — 改訂第7版 本文 PDF「脆弱性対策について －根本的解決と保険的対策－」（取得 2026-11）
11種類の脆弱性を「AI に聞く質問」と「自分で確かめる所」に分ける
第1章の11項目を、AI コーディングツールへの確認の仕方と、人が自分の目で見る場所に分けました。IPA の項番は深刻度順ではなく、対策の優先順位を示すものではないと資料に明記されているので、自社のサイトにどの機能があるかで優先を決めます。
※ 出典: IPA — 安全なウェブサイトの作り方（第1章の抜粋一覧）（取得 2026-11）
| IPA の項目 | 該当しやすいサイトの機能 | AI に聞く質問（根本的解決の側） | 人が自分の目で見る所 |
|---|---|---|---|
| 1.1 SQL インジェクション | データベースを使う全機能 | SQL の組み立てはすべてプレースホルダか。文字列連結の箇所は無いか | エラー画面に SQL 文やテーブル名が出ないか。DB アカウントの権限が最小か |
| 1.2 OS コマンド・インジェクション | 画像変換・ファイル処理・外部コマンド呼び出し | シェルを起動する言語機能を使っていないか。使うなら引数を許可リストで絞っているか | AI が「便利だから」とシェル実行を入れていないか、依存ライブラリ経由も含めて確認 |
| 1.3 パス名パラメータの未チェック | ファイルのダウンロード・テンプレ切替 | ファイル名を外部パラメータから直接受け取っていないか。固定ディレクトリ＋ディレクトリ名を含まないファイル名か | ダウンロード URL の形。?file= のような設計が残っていないか |
| 1.4 セッション管理の不備 | ログイン機能 | セッション ID は推測困難か。URL に入れていないか。ログイン成功後に新しいセッションを開始しているか。Cookie に secure 属性があるか | ログイン前後で Cookie の値が変わるか。URL にセッション ID が無いか |
| 1.5 クロスサイト・スクリプティング | 入力を画面に出す全機能（検索結果・コメント・プロフィール） | 出力時のエスケープはフレームワークの標準に任せているか。生の HTML 出力を許す記述が無いか。Content-Type に charset があるか | フレームワークのエスケープを無効化する記述（dangerouslySetInnerHTML や ` |
| 1.6 CSRF | ログイン後の変更・購入・退会 | 処理を実行するページは POST で、秘密情報（トークン）を照合しているか。重要処理の前に再認証しているか | 設定変更・退会・購入の画面で、他サイトから勝手に実行されない仕組みがあるか |
| 1.7 HTTP ヘッダ・インジェクション | リダイレクト・Cookie 発行 | ヘッダ出力は言語やフレームワークの API に任せ、外部入力を直接ヘッダに書いていないか | リダイレクト先を URL パラメータで受けていないか |
| 1.8 メールヘッダ・インジェクション | 問い合わせフォーム・アンケート | メールヘッダ（宛先・件名）は固定値で、外部入力はすべて本文に出力しているか。送信 API を使っているか | 「送信先を hidden パラメータで持つ」設計になっていないか |
| 1.9 クリックジャッキング | ログイン後の設定変更 | X-Frame-Options などのレスポンスヘッダで他ドメインからの frame 読み込みを制限しているか | 重要な処理がマウス操作だけで完了しないか |
| 1.10 バッファオーバーフロー | ネイティブ拡張・古いライブラリ | 直接メモリにアクセスできる言語の部分は最小か。脆弱性が修正されたバージョンのライブラリか | 依存ライブラリの一覧と、更新の仕組み |
| 1.11 アクセス制御や認可制御の欠落 | マイページ・管理画面・申請一覧 | 閲覧にはパスワード等の秘密情報を要求しているか。利用者 ID や注文番号をセッションから取り、外部パラメータと一致確認しているか | ログインしたまま URL の ID を1つ変えて他人のデータが見えないか |
※ 出典: IPA — 改訂第7版 巻末チェックリスト（PDF）（取得 2026-11）／ 1.11 アクセス制御や認可制御の欠落（取得 2026-11）
「人が自分の目で見る所」の列が、AI 生成コードの点検で最も重要です。1.11 の認可制御について IPA は、メールアドレスだけでログインできてしまうサイトや、利用者 ID を URL や POST のパラメータに埋め込んでいる画面が届出を受けた例として挙げています。AI は「ID を受け取ってデータを返す」コードを素直に書きます。そのデータが「ログイン中の本人のもの」かを確認する行が入っているかは、仕様に書いていなければ AI は補いません。
※ 出典: IPA — 安全なウェブサイトの作り方 1.11 アクセス制御や認可制御の欠落（取得 2026-11）
公開前の点検表（15項目）— コードの外側も含める
第1章の11項目はコードの点検です。公開するには、サーバ・公開ディレクトリ・ログ・運用の点検も要ります。IPA の「ウェブサイトのセキュリティ対策のチェックポイント20ヶ条」から、AI で作ったサイトに特に関わる項目を選び、合わせて15項目にしました。各項目は IPA のチェックリストと同じ「対応済／未対応／対応不要」で記録します。
※ 出典: IPA — 安全なウェブサイトの運用管理に向けての20ヶ条（取得 2026-11）
A. コード（第1章）
- 1. 上の表の11項目について、自社サイトに該当する機能を洗い出し、該当しないものは「対応不要」と記録した
- 2. 該当する項目ごとに、AI に「根本的解決」の実装有無を答えさせ、その回答をコードの該当行で人が確認した
- 3. 認可制御（1.11）は、ログインしたまま他人の ID や注文番号を URL に入れても見えないことを人が実際に試した
- 4. 問い合わせフォーム（1.8）は、宛先・件名が固定値で、入力は本文だけに入ることをコードで確認した
B. 公開ディレクトリとサーバ（第2章・20ヶ条 1〜14）
- 5. 公開すべきでないファイル（設定ファイル・
.env・バックアップ・AI との作業ログ・スクリーンショット）が公開ディレクトリに無い（20ヶ条 (1)、第2章 2.1-5） - 6. 開発中に作った試験ページ・試験アカウント・管理用の裏口が削除されている（20ヶ条 (2)(11)）
- 7. エラーメッセージが利用者に必要な最低限で、内部構成を含まない（20ヶ条 (5)）
- 8. 全ページが HTTPS で、Cookie に secure 属性が付いている（20ヶ条 (7)、第2章 2.3）
- 9. 管理画面・リモート操作はパスワードだけに頼らず、公開鍵認証や多要素認証を使っている（第2章 2.1-2、20ヶ条 (8)(12)）
- 10. 使っているフレームワーク・ライブラリ・CMS の一覧があり、脆弱性情報を受け取る手段（JVN など）が決まっている（20ヶ条 (4)(9)）
C. 記録と運用（20ヶ条 6・14・19・20）
- 11. アプリケーションとサーバのログを保管し、誰がいつ見るかが決まっている（20ヶ条 (6)(14)）
- 12. ホスティングやクラウドの責任分界を把握し、事業者側が提供しない対策は自社で持っている（20ヶ条 (19)）
- 13. 公開後の定期的な検査（診断）の頻度と担当が決まっている（20ヶ条 (20)）
D. AI ツール固有
- 14. AI コーディングツール自体を最新に保ち、ツールが使える権限（書き込み先・ネットワーク・外部サービス）を社内ルールで絞っている
- 15. AI が作業中に作った公開リポジトリ・個人アカウント・外部サービスへの投稿が無いことを、会社の管理下のアカウント一覧で確認した
14 と 15 は IPA の資料には無い項目ですが、上で触れた AI セキュリティ短信の2つの事案に対応する項目です。ツールが回避策として外部に何かを置いていないかは、コードではなくアカウントとリポジトリの一覧で確かめます。
※ 出典: IPA — AI セキュリティ短信 2026年10月号（PDF）（取得 2026-11）
AI ツール側の安全装置を点検に組み込む
点検の多くは、AI コーディングツールやコードホスティングの機能で自動化できます。ただし自動化できるのは「候補を挙げる」までで、「対応済」と記録するのは人です。代表的な機能を2つの系統で挙げます。特定のツールの推奨ではなく、自社が使っているツールに同種の機能があるかを探す手がかりとして読んでください。
| 系統 | 機能の例 | 点検表のどこに効くか | 注意点 |
|---|---|---|---|
| AI コーディングツールのレビュー機能 | Claude Code の /security-review（現在のブランチの変更に対するセキュリティの確認）、セッション中に自分の変更の脆弱性を確認・修正する Security guidance プラグイン | A-2 の「AI に答えさせる」工程 | 公式ドキュメントは、提案されたコードとコマンドの安全確認の責任は利用者にあると明記 |
| AI ツールの権限・隔離 | 権限モード、ファイルシステムとネットワークを隔離するサンドボックス、作業ディレクトリ外への書き込み制限 | D-14 のツール権限 | 社内の設定として配布し、個人任せにしない |
| コードホスティングの依存関係監視 | GitHub の Dependabot アラート・セキュリティアップデート（脆弱な依存関係の検出と修正 PR） | B-10 のライブラリ更新 | 検出された更新を取り込む担当を決める |
| コードホスティングの静的解析 | GitHub の code scanning（CodeQL によるコード中の脆弱性とエラーの検出） | A-1〜A-4 の候補出し | 警告の CWE 番号を IPA の CWE 対応表で資料の項目に紐づける |
| 秘密情報の流出防止 | GitHub の secret scanning と push protection（認証情報がリポジトリに入る前に止める） | B-5 の設定ファイル・鍵 | AI が生成した設定ファイルに鍵を書き込みがちな点を補う |
※ 出典: Claude Code Docs — Security（取得 2026-11）／ GitHub Docs — Code security（取得 2026-11）
GitHub のドキュメントによると、code scanning をプライベートリポジトリで使うには GitHub Code Security の有効化が必要です。費用が発生する機能なので、どのリポジトリに適用するかは会社で決めます。AI ツール側の権限設定の配り方は、Claude Code の社内ルールの作り方にまとめています。
※ 出典: GitHub Docs — Code security（取得 2026-11）
コピペで使える2点 — AI へのレビュー依頼と、公開判定の記録表
AI コーディングツールに点検を指示するプロンプトの雛形
次の文章を、作業中の AI コーディングツールにそのまま渡します。ポイントは、IPA の項目名を使うこと、根本的解決の側を聞くこと、該当しない項目は「対応不要」と答えさせることです。回答はそのまま記録表に貼れます。
このリポジトリの Web アプリケーションを公開する前の点検をします。
IPA「安全なウェブサイトの作り方」改訂第7版 第1章の11項目
（SQL インジェクション／OS コマンド・インジェクション／パス名パラメータの未チェック／
セッション管理の不備／クロスサイト・スクリプティング／CSRF／HTTP ヘッダ・インジェクション／
メールヘッダ・インジェクション／クリックジャッキング／バッファオーバーフロー／
アクセス制御や認可制御の欠落）について、項目ごとに次の形式で答えてください。
- 該当する機能: （無ければ「該当機能なし → 対応不要」）
- 根本的解決の実装: 対応済／未対応 と、根拠になるファイル名と行
- 保険的対策の実装: 対応済／未対応 と、根拠になるファイル名と行
- 人が目視で確かめるべき箇所: URL・画面・設定ファイルを具体的に
コードは変更しないでください。推測で「対応済」と書かず、根拠の行が示せないものは「未確認」と書いてください。
最後に、公開ディレクトリに置かれているファイルの一覧と、その中で公開すべきでない可能性があるものを挙げてください。
「コードは変更しないでください」と「根拠の行を示せないものは未確認」の2行が重要です。AI は聞かれると直したくなり、直すと点検対象が動きます。点検と修正は別の指示に分けます。
公開判定の記録表（テンプレ）
| 項目 | 判定（対応済／未対応／対応不要） | 根拠（ファイル・行・画面） | 確認者 | 確認日 |
|---|---|---|---|---|
| 1.1 SQL インジェクション | ||||
| 1.8 メールヘッダ・インジェクション | ||||
| 1.11 認可制御 | ||||
| B-5 公開ディレクトリの不要ファイル | ||||
| D-15 AI の外部投稿の有無 |
IPA のチェックリストも「ウェブアプリケーションの性質によっては、本書で挙げた全ての対策が必要になるわけではありません」と注記しています。該当しない項目を「対応不要」と記録することは手抜きではなく、次に AI に同じコードを改修させるときの「ここは意図的に対象外」という引き継ぎになります。
※ 出典: IPA — 改訂第7版 巻末チェックリスト「チェック方法について」（PDF）（取得 2026-11）
失敗パターン5つ
- 「テストが全部通った」を公開判定にする。 上の表のとおり、メールヘッダ・認可制御・エラーメッセージ・公開ディレクトリの問題は、正常系のテストでは見えません。テストの緑と IPA の点検表は別の工程です
- AI に「セキュリティも考慮して」とだけ頼む。 保険的対策（入力チェック）で止まり、根本的解決（プレースホルダ、セッションからの ID 取得）が入らないことがあります。項目名を指定して聞きます
- AI が選んだライブラリのバージョンをそのまま使う。 AI は学習時点のバージョンを選びがちです。依存関係の監視機能を入れ、公開前に一覧を人が見ます
- 作業中の成果物を公開ディレクトリに残す。 AI との作業ログ、スクリーンショット、試験用のページや管理用アカウントは、公開前に削除し、20ヶ条の (1)(2)(11) で確認します
- 点検結果を記録しない。 次の改修で AI が別の実装に書き換えたとき、何が「対応済」だったか分からなくなります。IPA と同じ3択で記録を残します
※ 出典: IPA — 安全なウェブサイトの運用管理に向けての20ヶ条（取得 2026-11）
外部の脆弱性診断を頼むとき
IPA は資料の末尾で、組織内部でセキュリティ対策の確認と実施を行った上で、外部組織によるペネトレーションテストやウェブアプリケーションのコードチェック等の監査を受けることが、より効果的だとしています。あわせて、ウェブサイトの重要度に応じて脆弱性検査を受けることを勧めています。個人情報・決済・ログインのいずれかを扱うサイトは、この「重要度が高い側」に入ると考えて差し支えありません。
※ 出典: IPA — 改訂第7版 本文 PDF「おわりに」（取得 2026-11）
診断業者を探す出発点は、IPA が公開している「情報セキュリティサービス基準適合サービスリスト」です。経済産業省が策定した基準への適合性を審査登録機関が審査し、登録された事業者の脆弱性診断サービス・ペネトレーションテストサービスなどが一覧になっています。2026年10月9日掲載の版が最新です。IPA はリスト掲載がサービスの保証ではないと明記しているので、候補を絞る道具として使い、見積もり時に次の3点を聞きます。
※ 出典: IPA — 情報セキュリティサービス基準適合サービスリスト（取得 2026-11）
- 診断の範囲は IPA の11項目のどれをどの手法（ツール・手動）で見るか
- 報告書には再現手順と修正の優先度が入るか、修正後の再診断は含まれるか
- AI コーディングツールで作ったコードであることを伝えた上で、依存ライブラリと設定ファイルの確認が範囲に入るか
IPA の別冊「ウェブ健康診断仕様」は13の診断項目で基本的な対策の有無を確認できますが、IPA 自身が「検査パターンを絞り込んだ診断なので、脆弱性が検出されなかった場合でも安全宣言には繋がらない」と注記しています。無料や簡易の診断で問題が出なかったことを、公開判定の根拠にはしません。
※ 出典: IPA — 安全なウェブサイトの作り方（別冊「ウェブ健康診断仕様」の内容）（取得 2026-11）
脆弱性が見つかった後の直し方にも傾向があります。IPA の2026年第3四半期（7〜9月）の届出状況によると、この四半期に修正が完了したウェブサイト19件のうち、ウェブアプリケーションを修正したものが17件（89%）、当該ページを削除したものが2件（11%）でした。ウェブサイトの届出は四半期で61件、累計は13,666件です。AI で作ったサイトでも、見つかった欠陥はコードを直すのが基本で、「そのページを消す」は最後の手段です。
※ 出典: IPA — ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第3四半期］（取得 2026-11）
サイト制作を外部に頼む場合は、発注時点で「公開前に IPA の11項目で点検し、記録表を納品に含める」を条件に入れます。費用の見方はWeb 制作の費用相場と発注先の選び方に、Tufe の Web 制作の範囲はWeb Productionにまとめています。
公的リソース集
| 資料 | 用途 | URL |
|---|---|---|
| 安全なウェブサイトの作り方 改訂第7版（PDF・全115ページ） | 点検表の本体。巻末チェックリストと CWE 対応表 | ipa.go.jp |
| 同 概要ページ（第1章の抜粋・Excel 版チェックリスト） | 脆弱性ごとの Web 版解説。Excel を記録表に使える | ipa.go.jp |
| ウェブサイトのセキュリティ対策のチェックポイント20ヶ条 | 運用・サーバ・ネットワークの点検。Excel 版あり | ipa.go.jp |
| 情報セキュリティ10大脅威 2026 | 経営層への説明資料。AI 利用のリスクが組織3位 | ipa.go.jp |
| AI セキュリティ短信（月次） | AI コーディング・エージェントの事案を一次情報付きで追う | ipa.go.jp |
| 情報セキュリティサービス基準適合サービスリスト | 脆弱性診断・ペネトレーションテストの業者探し | ipa.go.jp |
| JVN（Japan Vulnerability Notes） | 使っているフレームワーク・CMS・ライブラリの脆弱性情報 | jvn.jp |
| 脆弱性関連情報の届出状況（四半期） | 届出の傾向と修正方法の実態 | ipa.go.jp |
※ 出典: 各行の URL および IPA — 安全なウェブサイトの作り方（概要）（取得 2026-11）。資料の版・掲載日は本文の各節に記載。
よくある質問
Q. AI が書いたコードは、人が書いたコードより危険ですか？
危険か安全かは書き手ではなく、公開前に誰がどう点検したかで決まります。AI コーディングツールの公式ドキュメントも、提案されたコードとコマンドの安全を確認する責任は利用者にあると明記しています。AI は動くコードを速く出しますが、問い合わせフォームのメール送信や管理画面の認可のように、動作確認では見えない欠陥は、人が IPA の資料に沿って確かめる必要があります。
Q. IPA の「安全なウェブサイトの作り方」は古い資料ではありませんか？
改訂第7版の初版は2015年、最終の第4刷は2021年ですが、取り上げているのは IPA が届出を多く受けた、または影響の大きい種類の脆弱性で、ウェブサイトの脆弱性の届出自体は2026年も四半期ごとに続いています。フレームワークが変わっても欠陥の種類は変わらないので、点検の軸としては今も使えます。最新の個別製品の脆弱性は JVN で補います。
Q. 小さなコーポレートサイトや LP でも、ここまで点検が必要ですか？
問い合わせフォームがあるだけでも、メールヘッダ・インジェクションと入力値の扱いは点検対象になります。IPA の「20ヶ条」も、新しいページを公開する前に都度確認することを求めています。ログインや決済、個人情報の保存がない静的なサイトなら、点検表のうち該当しない項目は「対応不要」として記録すればよく、全項目を実施する必要はありません。
Q. AI ツールの自動セキュリティレビューを通せば、外部の脆弱性診断は不要ですか？
代わりにはなりません。IPA は資料の末尾で、組織内部で確認を行った上で外部組織によるペネトレーションテストやコードチェックを受けることがより効果的だとし、サイトの重要度に応じて脆弱性検査を受けることを勧めています。AI のレビューは内部確認の一部として使い、個人情報や決済を扱うサイトは外部診断を組み合わせる、という位置づけが妥当です。
次の一歩
- 今週: AI で作った（または作らせている）サイト・ツールを一覧にし、ログイン・問い合わせフォーム・個人情報・決済の有無を列にする。該当機能から、上の11項目のどれが「対応不要」になるかを先に決める
- 今月: 残った項目について、上のプロンプト雛形で AI に点検させ、回答の根拠行を人が確認して記録表を埋める。公開ディレクトリの不要ファイルとアカウント一覧（D-15）は人が直接見る
- 四半期ごと: 依存ライブラリの更新と JVN の確認、記録表の見直し。個人情報・決済を扱うサイトは、IPA の適合サービスリストから外部診断の見積もりを取る
記録表を作ったうえで、AI コーディングツールで作ったサイトの公開前点検や、点検を組み込んだ制作・保守の進め方を相談したい場合は、埋めた記録表を添えてお問い合わせからご連絡ください。Tufe Company は Web 制作と AI 導入・業務自動化の設計を行っており、公開前の点検項目・権限の設計・外部診断の範囲の切り分けを含めて、書面で実装ステップを提示します。契約前提ではありません。初期費用を抑えて保守まで含める形は月額制ホームページ、AI ツールの社内導入の全体像はClaude 導入支援のハブもあわせてご覧ください。
更新履歴
- 2026-11-09: 初版公開
関連ページ
- AI にメール・フォーム・社内文書を読ませる前に決める統制【2026年11月】 — AI エージェントに読ませるデータと実行させる操作の線引き
- AI 導入前に整える情報セキュリティの土台【2026年11月】 — IPA ガイドライン第4.0版と SECURITY ACTION
- Claude Code の社内ルールの作り方【2026年10月】 — ツール側の権限・秘密情報の線引き（D-14 の実装例）
- Claude Code Review の法人導入【2026年10月】 — AI によるコードレビューの費用と深度の決め方
- 生成 AI の社内利用ガイドラインの作り方【2026年9月】 — AI 利用の規程に点検工程を書き込む土台
- Web 制作の費用相場と発注先の選び方 — 外注時に点検を条件に入れる際の費用の見方