AIコーディング支援でWebページを作ると、最初の形は驚くほど速く出ます。問題はそのあとです。「動いているように見えるもの」を公開してよいかは、別の判断です。この記事では、小規模なWebページを対象に、AIへ任せる範囲と人が持ち続ける責任を5段階に分けて整理します。
対象は、AIコーディング支援を使ってページを作る担当者、その内容を確認する編集者、公開を承認する立場の方です。特定フレームワークのチュートリアル、脆弱性診断の代行、デザイン品質や売上向上の保証は扱いません。
AIコーディング支援が得意なことと、所有しない責任
まず、何が速くなるのかを正確に押さえます。AIコーディング支援が得意なのは、既知のパターンを素早く形にすることです。よくあるレイアウト、定型的なマークアップ、設定ファイル、テストの雛形といった作業では、下書きを作る時間が大幅に縮みます。
一方で、生成されたものが正しいとは限りません。GitHub は Copilot のエージェント機能について、「有効に見えるが、実際には意味的または構文的に正しくないコードを生成することがある」、また「開発者の意図を正確に反映しないことがある」と明記しています。同社は「要件を満たし、誤りやセキュリティ上の懸念がないことを、マージ前に必ずレビューしテストすべきである」とも述べています。
ここから読み取るべきは、レビューが省略可能な工程ではなく、提供者自身が前提として置いている工程だということです。「AIが作ったから確認は軽くてよい」ではなく、「AIが作ったからこそ確認の手順が要る」という向きになります。
Stage 1：目的、対象、禁止変更、受入条件を固定する
実装を始める前に、5行でよいので次を書き出します。書かずに始めると、出てきたものを見てから条件を考えることになり、判断が生成物に引きずられます。
| 項目 | 書くこと |
|---|---|
| 目的 | このページで読者に何をしてほしいか |
| 対象 | 変更してよいファイル・領域。ここに書かれていないものは触らない |
| 禁止変更 | 共通CSS、既存ページ、設定ファイルなど、触られると影響が広がるもの |
| 受入条件 | 何が満たされたら完成とみなすか。表示・動作・非退行の観点で書く |
| rollback | 問題があったとき、どう元に戻すか。誰が判断するか |
| 承認者 | 公開を決める人。作った人と同一にしない |
特に効くのが禁止変更です。AIコーディング支援は、目的を達成するために周辺のファイルへ手を伸ばすことがあります。共通CSSを1行変えれば当該ページは直りますが、他のページが崩れます。禁止領域を先に書いておくと、この種の副作用を工程で防げます。
受入条件は「確かめられる形」で書く
受入条件でよくある失敗は、「見やすいこと」「スマホで崩れないこと」のように確かめ方が決まらない書き方をすることです。誰が見ても同じ判定になる形にします。
| 曖昧な書き方 | 確かめられる書き方 |
|---|---|
| スマホで崩れないこと | 375pxと768pxで、横スクロールが発生せず、文字の切れ・重なりがないこと |
| リンクが正しいこと | 各リンクが仕様どおりの目的地へ到達し、破損していないこと。新規タブで開くのは必要な場合に限り、その場合は視覚表示と支援技術の双方へ事前に伝え、rel="noopener" 等の指定を確認すること |
| SEOに配慮すること | title・description・canonical・OGPが指定値と一致すること |
| 既存に影響しないこと | 対象ページ以外の生成物に差分が出ないこと |
右列は、どれも実行して確かめられます。受入条件は、完成の定義であると同時に検証手順の一覧でもあると考えると書きやすくなります。
Stage 2：小さな差分として実装させる
1回の指示で完成品を出させないでください。差分の大きさは、レビューできる量に制限するのが原則です。
- 1回1目的：レイアウト、文言、リンク、metadataを同時に変えさせない
- 変更点を説明させる：何をなぜ変えたかを、コードとは別に短く書かせる
- 読めない差分は差し戻す：理解できないまま通した差分は、レビュー済みではない
- 既存の書き方に合わせる：周辺コードと異なる流儀が混ざると、後の保守が難しくなる
差分を小さく保つ利点は、レビューの負荷だけではありません。問題が起きたときに原因を切り分けられることが大きい。10箇所を一度に変えて表示が崩れると、どの変更が原因かを特定する作業が発生します。1箇所ずつなら、そもそも切り分けが要りません。
Stage 3：build・test・diffで機械確認する
機械で確認できることは、機械で確認します。人が見るべきものに集中するためです。
- build が通るか：構文エラー、参照切れ、型の不整合を検出する
- test が通るか：既存の自動テストが壊れていないかを見る
- 差分が想定どおりか：変更されたファイルの一覧が、Stage 1 の対象と一致するか
- 禁止領域に触れていないか：差分の中に禁止変更のファイルが含まれていないか
ここで強調しておきたいのは、build成功は品質保証ではないことです。buildが通るのは「機械が処理できる形になっている」ことの確認であって、内容が正しいこと、表示が意図どおりであること、安全であることは何も示しません。
セキュアな開発の考え方を体系立てたものとして、NIST は SP 800-218『Secure Software Development Framework (SSDF) Version 1.1』を公開しています。SSDF は実践を4つのグループ ── 組織の準備（PO）、ソフトウェアの保護（PS）、十分に保護されたソフトウェアの作成（PW）、脆弱性への対応（RV） ── に整理しています。開発の一工程だけでなく、準備から対応までを含めて設計するという枠組みは、AI支援の有無にかかわらず変わりません。
Stage 4：実画面を複数幅、keyboard、consoleで確認する
機械確認を通ったら、実際の画面を見ます。自動検査だけでは、視覚的な品質もアクセシビリティも証明できません。
| 観点 | 確認すること |
|---|---|
| 複数の画面幅 | スマートフォン幅・タブレット幅・デスクトップ幅で、切れ・重なり・横スクロールがないか |
| キーボード操作 | Tabで到達できるか、順序が視覚順と一致するか、フォーカスが見えるか |
| console | ブラウザのコンソールにエラーが出ていないか |
| リンクと画像 | リンク先が存在するか、画像に意味のある代替テキストがあるか |
| metadata | title、description、canonical、OGPが意図した値になっているか |
| 非退行 | 触っていないページの表示が変わっていないか |
アクセシビリティは「確認観点」として扱う
アクセシビリティの国際的な基準として、W3C は WCAG（Web Content Accessibility Guidelines）を公開しています。現行版はWCAG 2.2で、2023年10月5日に W3C 勧告として公開されました。WCAG は知覚可能・操作可能・理解可能・堅牢の4原則で構成され、適合レベルは A、AA、AAA の3段階が定義されています。
「WCAG 準拠」と書く前に
適合を主張するには、対象範囲、適合レベル、試験方法が揃っている必要があります。自動チェッカーを1回通しただけでは適合の証明になりません。本稿では WCAG を確認の観点として参照しており、適合の宣言や達成の保証を意図するものではありません。
Stage 5：セキュリティ、権利、表現、公開を人が判断する
最後の段階は、機械にも AI にも委ねられない判断です。
- セキュリティ：入力の扱い、外部からの読み込み、公開してよい情報かどうか
- 権利：画像・フォント・文章の出所とライセンス。第三者のロゴや素材を含んでいないか
- 表現：断定的な効果の約束、誤認を招く比較、業界規制に触れる表現がないか
- 公開操作：いつ、誰が、どの手順で公開するか。戻す手順が用意されているか
Webアプリケーションのセキュリティリスクを整理した資料として、OWASP は Top 10 を公開しています。これは「開発者とWebアプリケーションセキュリティのための標準的な啓発文書」と位置づけられており、最新版は OWASP Top Ten 2025 です。啓発文書であって認証基準ではないため、「Top 10 を見たから安全」とは言えません。何を確認したかを記録する枠組みとして使います。
ここで最も重要な原則を1つ挙げるなら、AIの自己申告を証拠にしないことです。「確認しました」「問題ありません」という応答は、確認が行われた証拠ではありません。証拠になるのは、実行したコマンドの出力、実際の画面、取得したファイルの中身です。
よくある失敗 — 大差分、自己検証、scope creep、未確認依存
| 失敗 | 何が起きるか | 対処 |
|---|---|---|
| 大差分 | レビューが形式的になり、問題が通過する | 1回1目的に分ける。読めない差分は差し戻す |
| 自己検証 | 「確認した」という応答を証拠として受け取ってしまう | 出力・画面・ファイルの実体で確かめる |
| scope creep | 頼んでいない改善が入り、影響範囲が読めなくなる | 禁止変更を先に固定し、差分一覧と照合する |
| 未確認依存 | 外部ライブラリやフォントが勝手に追加される | 追加された依存を一覧で確認し、出所とライセンスを見る |
| 成功表示の追認 | コマンドが成功と表示したことを、結果の確認だと取り違える | 生成物のファイルと実画面を自分で開いて確かめる |
実務チェックリスト
- 目的・対象・禁止変更・受入条件・rollback・承認者を、実装前に書いたか
- 1回の指示を1目的に絞り、差分を読める大きさに保ったか
- build と test が通り、差分一覧が対象範囲と一致しているか
- 禁止変更のファイルが差分に含まれていないか
- 複数の画面幅・キーボード操作・console を実画面で確認したか
- 画像の代替テキストとリンク先の存在を確認したか
- 触っていないページが変わっていないことを確認したか
- 追加された依存の出所とライセンスを確認したか
- 公開の承認者が、作成者とは別に決まっているか
- AIの「確認しました」ではなく、実体で確かめたか
まとめ
AIコーディング支援は、実装案を出す速度を大きく変えます。しかし、要件を決めること、影響範囲を限ること、実画面で確かめること、公開してよいと判断することは、いずれも人に残ります。この5段階は、その残る部分を工程として見えるようにするためのものです。
次に1ページ作るとき、まず受入条件と禁止変更を5行だけ先に書いてみてください。書けないなら、それは要件がまだ決まっていないということです。その状態でAIに実装させると、決まっていない要件を生成物が代わりに決めてしまいます。
引用元・参考文献
公式ドキュメント・標準
- GitHub Docs『Application card: GitHub Copilot Agents』（確認日：2026年8月9日）：https://docs.github.com/en/copilot/responsible-use-of-github-copilot-features/responsible-use-of-copilot-coding-agent-on-githubcom
- NIST『Secure Software Development Framework (SSDF)』プロジェクトページ（SP 800-218 Version 1.1／確認日：2026年8月9日）：https://csrc.nist.gov/Projects/ssdf
- W3C Web Accessibility Initiative『WCAG 2 Overview』（WCAG 2.2 は2023年10月5日に W3C 勧告として公開／確認日：2026年8月9日）：https://www.w3.org/WAI/standards-guidelines/wcag/
- OWASP『OWASP Top 10』プロジェクトページ（最新版：OWASP Top Ten 2025／確認日：2026年8月9日）：https://owasp.org/www-project-top-ten/
※ GitHub Docs の記述は同社の Copilot エージェント機能についてのものであり、すべてのAIコーディング支援へそのまま一般化できるものではありません。本稿ではレビュー責任の考え方を示す根拠として参照しています。WCAG は本稿では確認の観点として参照しており、適合の宣言や達成の保証を意図するものではありません。OWASP Top 10 は啓発文書であり、認証基準ではありません。本稿で述べた5段階は、これらの資料が示す考え方を踏まえた一般的な整理であり、特定の資料に工程そのものが規定されているものではありません。