【ITニュース解説】How I Review AI-Generated HTML Before Publishing It

AIが数秒でWebページを生成できるようになった今、その速度は非常に便利だが、見た目が完成しているページでも、公開する前にいくつかの重要な確認が必要である。AIが生成したHTMLコードには、構造的な問題やセキュリティ上のリスク、アクセシビリティの欠陥が含まれている可能性があるため、必ずレビューを行う必要がある。コードのすべてを疑うのではなく、最小限の確認作業を習慣化することが目的となる。

具体例として、一見問題なさそうなHTMLコードには、以下のような見落としやすい問題が含まれていることがある。まず、段落を示す<p>タグの閉じタグが間違って別の開始タグ<p>になっている場合がある。正しくは</p>で閉じる必要がある。次に、画像を示す<img>タグにalt属性（代替テキスト）が設定されていない場合がある。これは、画像が表示されない環境や視覚に障がいのあるユーザーがスクリーンリーダーを使う際に、画像の内容が伝わらない問題を引き起こす。また、リンクを示す<a>タグのhref属性に、通常のWebページへのURLではなく、JavaScriptコードが直接記述されている場合がある。このようなリンクは、クリックすると意図しないJavaScriptを実行する可能性があり、セキュリティ上のリスクや予期せぬ動作につながる。

これらの問題を未然に防ぎ、AI生成HTMLを安全かつ適切に公開するためには、以下の7つのステップに従ったレビューが有効である。

まず第一に、最初のプレビューを隔離することが重要だ。見慣れないHTMLコードを直接本番環境や重要な開発環境に貼り付けるのは避けるべきである。サンドボックスと呼ばれる隔離された環境でプレビューすることで、コードが周辺のアプリケーションに与える影響を限定できる。サンドボックスは完全な安全を保証するものではないため、もしコードが第三者のスクリプトやフォーム、ログイン情報、プライベートデータに依存している場合は、それらの部分を慎重に確認してから有効にするべきだ。パスワードやAPIキー、顧客情報などを、完全にレビューしていないコードに決して貼り付けてはならない。

次に、スタイリングの前にドキュメント構造を確認するステップに進む。HTMLの基本的な構成要素、つまり<!doctype html>宣言、<html>タグ、<head>タグ、<body>タグといった必須要素がすべて含まれているかを確認する。そして、すべての開始タグに対応する閉じタグが正しく配置されているかを丁寧にチェックする。コードのインデント（字下げ）は、要素の階層構造を視覚的に分かりやすくし、閉じタグの誤りを見つけるのに役立つ。コード整形ツールを使うことも有効だが、ツールがコードの意味まで修正してくれるわけではないため、最終的な意味の確認は人間の目で行う必要がある。

第三のステップは、すべてのURLと実行可能セクションを検査することである。<script>、javascript:、onclick=、onerror=、iframe、form、fetch(、localStorageといった文字列を検索する。これらの要素が自動的に悪意のあるものとは限らないが、それぞれがどのような目的で使われているのか、その説明を求めるべきである。スクリプト、画像、フォーム、iframeがどのドメインと通信するのか、クリックすると表示されているラベルと異なるコードが実行されるのか、ページが情報を読み書きするのか、サードパーティコードがなくても機能するか、といった点を問いかける。例えば、JavaScriptを実行するリンクは、ユーザーを特定のWebページにナビゲートする実際のURLに置き換えるべきである。予約ページがまだ存在しない場合は、JavaScriptで明確なアクションを提供するボタンを使用し、ナビゲートするように見せかけるリンクは避ける。

第四に、キーボードと意味のチェックを行う。AIが生成するページは、見た目の美しさを優先しがちで、アクセシビリティや意味論（セマンティクス）が考慮されていない場合がある。色や配置を評価する前に、以下の項目を確認する。通常、ページにはメインとなる<h1>見出しが一つであるべきだ。見出しレベル（<h2>, <h3>など）は、単に大きなテキストを作成するためではなく、ページのセクション構造を明確にするために使用する。対話可能なアクション（例えばクリック可能な要素）には、意味的に適切なリンク<a>またはボタン<button>を使用し、<div>要素など他のタグを誤って使わない。フォームコントロールには、利用者が内容を理解できるような目に見えるラベルが必要だ。意味を伝える画像には、その内容を説明するaltテキストを設定する。装飾的な画像にはalt=""`を設定し、スクリーンリーダーが読み飛ばせるようにする。Tabキーでページ内を移動したときに、常にフォーカス（現在選択されている要素を示す枠線など）が可視化されていることも重要である。

第五のステップは、狭い画面、不足しているアセット、長いコンテンツをテストすることだ。完成されたデスクトッププレビューだけでは不十分である。少なくとも、スマートフォンの狭い幅、タブレットの幅、ワイドなデスクトップの幅で表示を確認する。ブラウザのズーム機能を200%に設定した場合の表示もチェックする。意図的に長い見出しやコンテンツを挿入してみて、レイアウトが崩れないか確認する。存在しない画像ファイルや、読み込みに時間がかかる、あるいはブロックされた外部リソースがある場合のページの挙動も確認する。横スクロールが発生したり、ボタンがクリッピングされたり、テキストが重なったり、コントロールが小さすぎてタップできないなどの問題がないか確認する。ブラウザの開発者ツールにあるコンソールを見ると、表示されていないだけで実際には読み込みエラーになっている画像やスクリプトなどの問題を発見できる場合がある。

第六に、見た目だけでなく動作を検証する。すべてのリンクをクリックして遷移先を確認する。フォームがある場合は、有効な入力と無効な入力の両方で送信を試みる。データがまだ存在しない「空の状態」の表示もトリガーして確認する。ページをリロードした場合の挙動もテストする。もし機能がデータを保存する場合は、データがどこに保存されるのかを理解し、ストレージが利用できない場合の動作もテストする。生成されたJavaScriptコードがある場合は、ボタンを押す前に実行されるコードパスを読んでおくべきである。「レポートを生成」といった分かりやすいラベルが付いていても、そのコードがファイルをダウンロードするのか、サービスにデータを送信するのか、あるいはその両方を行うのかは、コードを読まなければわからない。

最後のステップは、一度に一つの修正を行うことだ。AIによる大規模な書き換えは、一つの問題を解決しながら別の問題を引き起こす可能性があるため、小さなループで修正を進めるのが望ましい。まず、明確な一つの問題を特定する。次に、その問題に関連する最小限のセクションだけを変更する。変更後、再度プレビューを行い、キーボード操作やモバイル表示、エラーチェックなど、必要なテストを繰り返す。次の変更を加える前に、動作するバージョンを保存しておくことで、問題が発生した場合に容易に元の状態に戻せる。

これらのレビュープロセスは、AIが生成したHTMLを公開する前に不可欠なチェックリストとなる。すべての外部URLとスクリプトの意図を理解しているか。文書には適切なドキュメントタイプ、言語、文字セット、ビューポート設定、そして有用なタイトルが設定されているか。開始タグと閉じタグは正しく対応しているか。見出しの順序はページの構造を正しく伝えているか。画像には適切な代替テキストが設定されているか。リンクとボタンはそれぞれの動作を明確に説明しているか。キーボードでのフォーカス移動はすべての対話型コントロールに到達し、視認できるか。スマートフォン、タブレット、デスクトップ、ズーム表示でレイアウトが崩れないか。空の状態、無効な入力、欠落したアセットの状態が適切に処理されているか。ソースコードに秘密情報やプライベートデータが埋め込まれていないか。そして、最終変更後に最終バージョンをテストしたか。これらを確認することが重要である。

ただし、ブラウザプレビューや構文チェックだけでは、ページのセキュリティ、アクセシビリティ、正確性を完全に保証できるわけではない。サーバー側のコード、依存関係、認証プロセス、決済フロー、データ処理、そして組織固有のポリシーについては、それぞれ専門的なレビューが別途必要となる。また、自動化されたアクセシビリティツールでは見つけられない問題も多く、実際にユーザーがタスクを完了する視点での人によるテストが不可欠である。このチェックリストは、強力な最初のレビューとして活用し、適切なセキュリティ専門知識、アクセシビリティ知識、ドメイン専門知識の代替とはしないことが肝要だ。