講義資料　Web制作の歴史と、AI時代に置き去りにされる「セキュリティ」という論点

はじめに ― なぜ今この話をするのか

Web業界は、ある意味で「動けばいい」「見た目がきれいならいい」という価値観で30年走ってきました。

納品時に表示が崩れていなければOK、スマホで見られればOK、お客様が「いいね」と言ってくれればOK ——。

しかし、生成AIが普及した今、この30年間の「見過ごされてきた負債」が一気に表面化しています。AIは数秒で動くコードを書きます。動くコードは「正しいコード」ではありませんし、「安全なコード」でもありません。

本資料の狙いは、以下の流れを 一本の線でつなぐ ことです。

1. 歴史：1990年代の手作業時代に、制作者は何を見ていたか
2. 構造：CMS・ビルダー時代に、何が「見えなくなった」か
3. 現在地：AI時代に、どんな新しい問題が生まれているか
4. 対策：では、いま私たちは何をすべきか

💡 「技術の進化」と「責任の進化」は、必ずしも同じスピードでは進まない。むしろ後者は常に遅れる。その遅れこそがリスクの正体である。

1. 1990年代のWeb制作 ― 手作業と「配置の意識」の時代

1-1. HTML/CSSを手で書いていた時代

Webの黎明期、制作者はテキストエディタ（メモ帳、秀丸、Emacs など）でHTMLを直接書いていました。

• HTML 2.0：1995年、IETF（インターネット技術タスクフォース）が策定
• HTML 4.01：1999年、W3C（World Wide Web Consortium）が勧告
• CSS1：1996年12月、W3C勧告 → ここで「構造（HTML）と見た目（CSS）の分離」という設計思想が初めて公式化された

📝 初心者向け補足：「構造と見た目の分離」とは、文書の意味（見出し・段落・リスト）と装飾（色・余白・フォント）を別ファイルで管理する考え方です。保守性と再利用性が劇的に上がりました。

1-2. FTPアップロードと「権限・配置」を意識する運用

公開作業は FTP（File Transfer Protocol） で行われていました。

• FTP本体仕様：RFC 959（1985年）
• セキュリティ考慮事項：RFC 2577（1999年） で、FTPの認証情報が平文で流れる危険性などが明文化された

制作者は、以下のような作業を「自分の手で」やっていました。

• ファイルをサーバーへアップロード
• パーミッション（権限） の設定：chmod 644 index.html、chmod 755 cgi-bin/
• ディレクトリ構造の設計：/public_html/ の下に何を置くか
• .htaccess でのアクセス制御

📝 初心者向け補足：パーミッションとは「このファイルを誰が読めて、誰が書き換えられて、誰が実行できるか」をサーバー上で決める設定です。644 は「所有者は読み書き、他人は読みのみ」を意味します。

つまりこの時代、制作者は 「サーバーの上に何を、どんな権限で置いているか」を物理的に理解していた のです。

1-3. この時代の「良かった点」と「限界」

💡 この頃の制作者は「インフラの一部としてのWeb」を見ていた。今の多くの制作者はそれを見ていない。

これは能力の問題ではなく、ツールが見せてくれなくなった という構造の問題である。

2. CMS・ビルダー時代 ― 制作の「民主化」と「責任の希薄化」

2-1. 主要プレイヤーの登場

2000年代以降、Web制作は急速に「民主化」されました。

📝 CMSとは Content Management System の略で、「プログラムを書かなくても記事や画像を投稿・管理できる仕組み」のこと。WordPressが最も有名です。

2-2. 何が変わったか（ポジティブ面）

• 非エンジニアでもサイトが作れる → 制作の民主化
• 公開までのスピード が劇的に短縮（数週間 → 数時間）
• デザイナー単体での受託 が可能になり、市場が拡大

2-3. 何が「見えなくなった」か（構造的な負債）

ここが本資料の核心です。便利になったその裏で、以下のものが 裏側に隠れて見えなくなりました。

• サーバー設定
• データベース構造
• 権限管理
• 認証フロー
• 更新管理（コア・テーマ・プラグインのアップデート）

そして特に深刻なのが プラグイン依存 の問題です。

📊 報告例：Patchstack の年次脆弱性レポートでは、WordPress関連の脆弱性のうち 約97%がプラグイン由来 と報告されています（年度により変動あり）。

さらに、市場構造として次の問題があります。

• 「納品して終わり」が常態化 している
• フリーランス・小規模受託では 保守契約まで含めた提案が難しい
• 発注側も「作って終わり」だと思っているケースが多い
• → 責任分界が曖昧 になる

🔍 「作れるようになった」ことと「運用できるようになった」ことは 別問題 である。民主化の裏には、必ず責任の分散と希薄化が起きる。これは技術ではなく、契約と業界構造の問題 である。

3. 現代のWebデザイナー・制作者に起きやすい問題

3-1. 5つの典型パターン

現場で実際によく見るパターンです。

1. 見た目優先

• UI/UXは熱く語るが、セキュリティは「専門外」で済ませる

1. プラグイン依存

• 「○○というプラグインを入れれば解決」が思考停止になる
• プラグイン自体の脆弱性は誰も見ていない

1. 公開して終わり

• 保守契約がない、更新されない、放置される
• 1〜2年後に改ざんされて気づく

1. 外部スクリプト多用

• Google Analytics、広告タグ、チャットツール、A/Bテストツール…
• 第三者JavaScriptを 無自覚に大量に読み込んでいる

1. 管理画面軽視

• 弱いパスワード、2要素認証なし、IP制限なし
• /wp-admin がインターネット全体に開いている

3-2. なぜこうなるのか（構造分析）

これは制作者個人の怠慢ではなく、業界構造の問題 です。

• 受託単価が下がり、保守まで含めた提案がしづらい
• 発注側もセキュリティを「コスト」としか認識していない
• 「セキュリティで売上は上がらない」という誤解
• 教育課程（専門学校・スクール）でセキュリティが軽視されている

💡 「制作者が悪い」と個人を責めても何も解決しない。価格構造・契約構造・教育構造 の三つを同時に動かさないと、業界は変わらない。

4. AI時代の新しい問題 ― 「動く＝安全」という錯覚

4-1. 生成AIによるコード生成の現実

ChatGPT、Claude、GitHub Copilot などのAIは、数秒で「動くコード」を書きます。しかし重要なのは次の事実です。

「動く」ことと「安全である」ことは、まったく別の概念である。

学術研究の報告例：

• ニューヨーク大学（NYU）のCopilot評価研究では、AIが生成したコードのうち 約40% に何らかのセキュリティ上の問題が含まれていたと報告されています（研究時点・対象シナリオによる）
• スタンフォード大学の研究では、AIアシスタントを使った開発者のほうが 逆に脆弱なコードを書きやすい 傾向があると報告されています

そして実際の現場では、ユーザーは「動いたから本番に入れる」を平然とやってしまいます。

4-2. セキュリティ要件を入れないプロンプトの危険性

例えば、こんなプロンプトを考えてみてください。

「ユーザーが入力した名前を画面に表示する、カッコいいスクロールアニメーションを作って」

このプロンプトには セキュリティ要件が一切ありません。AIは親切に動くコードを書きますが、そこには高い確率で次のような実装が含まれます。

element.innerHTML = userInput;  // ← XSS脆弱性の温床

📝 XSS（クロスサイトスクリプティング）とは、攻撃者が悪意あるJavaScriptをWebページに埋め込み、訪問者のブラウザで実行させる攻撃です。Cookie盗難、なりすまし、フィッシングなどに直結します。

特に DOM-based XSS は、サーバーを経由せずブラウザ側だけで完結するため、検知が難しく見落とされやすい脆弱性です。動的UI・リッチアニメーションを多用するほど、DOM操作が増え、攻撃面（アタックサーフェス）も広がります。

4-3. 業界が示している方向性

国際的な業界団体は、すでに明確な方向性を打ち出しています。

• OpenSSF（Open Source Security Foundation）
• Secure Software Development Framework（SSDF）を公開
• 開発の最初の段階からセキュリティを組み込む
• CISA（米国サイバーセキュリティ・社会基盤安全保障庁）
• Secure by Design：設計段階からセキュリティを考慮する
• Secure by Default：初期設定の状態で安全であるべき

共通するメッセージは1つです。

「あとからセキュリティを足す」のではなく、「最初から組み込む」

💡 ラテラル視点：AIで開発者の生産性が10倍になるなら、攻撃者の生産性も10倍になる。

攻守の非対称性は変わらない。むしろ、防御側がセキュリティを後回しにすればするほど、非対称性は 攻撃側に有利に拡大 する。

5. 講義用コードスニペット

5-1. 1990年代の公開運用イメージ（FTP + 権限）

# 1990年代の典型的な公開作業

# 1. FTPでサーバーに接続
ftp ftp.example.com
# ユーザー名・パスワードを入力（※平文で流れる：RFC 2577参照）

# 2. ファイルをアップロード
put index.html
put style.css
put -r images/

# 3. パーミッションを自分で設定
chmod 644 index.html     # 所有者:読み書き / 他人:読みのみ
chmod 644 style.css
chmod 755 cgi-bin/       # ディレクトリは実行権限が必要
chmod 700 admin/         # 管理用は所有者のみアクセス可能

# ポイント：
# 「何を、どこに、どんな権限で置くか」を
# 制作者自身が一つひとつ決めていた時代

5-2. 危険な実装例：innerHTML（XSS脆弱性あり）

// ❌ 危険な例：ユーザー入力をそのままHTMLとして書き出す
const userInput = document.getElementById('name').value;
document.getElementById('greeting').innerHTML = 
  'こんにちは、' + userInput + 'さん！';

// 攻撃者が以下のように入力すると…
// <img src=x onerror="alert(document.cookie)">
// → ブラウザ上で任意のスクリプトが実行され、Cookieが盗まれる

5-3. 安全側の実装例：textContent

// ✅ 安全な例：textContent はHTMLとして解釈されない
const userInput = document.getElementById('name').value;
document.getElementById('greeting').textContent = 
  'こんにちは、' + userInput + 'さん！';

// HTMLタグが入力されても、ただの文字列として表示される
// → XSSが成立しない

// ✅ さらに安全：HTML構造が必要な場合は分離して構築
const userInput = document.getElementById('name').value;
const container = document.getElementById('greeting');

container.textContent = '';
const span = document.createElement('span');
span.className = 'user-name';
span.textContent = userInput;   // ← ここでエスケープされる

container.append('こんにちは、', span, 'さん！');

5-4. AIへのセキュリティ設計プロンプト例

AIに依頼するときは、セキュリティ要件を明示的に書き込む ことが重要です。

【依頼内容】
ユーザー名を画面に表示するスクロールアニメーションを実装してください。

【セキュリティ要件（必須）】
1. ユーザー入力は必ず textContent で扱い、innerHTML は使用しないこと
2. Content-Security-Policy (CSP) と整合する実装にすること
   - inline script、inline style、eval() は使用禁止
3. 外部スクリプトを読み込む場合は SRI (Subresource Integrity) を付与
4. 入力値はクライアント/サーバー双方でバリデーションすること
5. URLパラメータを DOM に直接反映しない（DOM-based XSS対策）
6. エラー時にスタックトレースを画面に出さないこと

【動作要件】
- スムーズなフェードイン演出
- レスポンシブ対応
- アクセシビリティ（prefers-reduced-motion 尊重）

【出力形式】
- HTML / CSS / JavaScript を分離
- 各ブロックにセキュリティ上の判断理由をコメントで記載

5-5. 最低限のセキュリティヘッダー方針例

# 最低限設定したいHTTPレスポンスヘッダー

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'
# → スクリプトやリソースの読み込み元を制限。XSSの被害を最小化

X-Content-Type-Options: nosniff
# → MIMEタイプの誤推測を防止

Strict-Transport-Security: max-age=31536000; includeSubDomains
# → HTTPS通信を強制（HSTS）

Referrer-Policy: strict-origin-when-cross-origin
# → リファラ情報の漏洩を制限

X-Frame-Options: DENY
# → クリックジャッキング対策（iframe埋め込み禁止）

Permissions-Policy: camera=(), microphone=(), geolocation=()
# → 不要なブラウザAPIを明示的に無効化

6. まとめ ― 「構造で勝つ」Web制作へ

ここまでの流れを整理します。

進化の方向性はこうです。

• 1990年代は 手作業ゆえに構造を理解 していた
• CMS・ビルダー時代に 構造が見えなくなった
• AI時代は 動くコードが大量生産される時代
• → これからの制作者に求められるのは「設計と責任の言語化」

🔖 3つのチェックリスト

公開前・契約前に、必ず確認してください。

• [ ] このサイトの「所有者・運用者・責任者」が契約書レベルで明確になっているか
• [ ] 更新・監視・インシデント対応 の体制があるか（誰が・いつ・何をするか）
• [ ] AI生成コードを「動いたから」という理由だけで本番投入していないか

💡 これからのWeb制作者の価値は、「作れること」ではなく「説明できること」に移る。

なぜこの設計にしたのか、なぜこの実装を選ばなかったのか、何をリスクとして受け入れて何を防いだのか ——

その言語化能力こそが、AI時代の差別化要因になる。

参考ソース

※ 本資料中の数値（WordPressシェア約43%、プラグイン由来脆弱性約97%、AI生成コードの約40%に脆弱性 等）は、各出典時点での 報告例・目安 として記載しています。

年度や調査条件により変動するため、断定的な数値としてではなく「傾向を示す参考値」として扱ってください。

著者注記

株式会社NKテクニカルサポート　登川晴雄　

大学ICT支援・CBT試験センター運営・生成AI活用支援の現場視点より

本資料は講義・社内勉強会での使用を想定しています。引用・転載される場合は出典の明示をお願いします。