AIの回答をHTMLで表示しても大丈夫？XSSを防ぐ設計と保存時の注意点

公開日2026.10.15

更新日2026.10.17

約8分で読めます

※本ページのリンクにはプロモーションが含まれています。

AIが書いた回答を読みやすくするために、見出しやリンクを付けてWeb画面へ表示する。自然な改善に見えますが、その文章をブラウザーがHTMLとして解釈する瞬間、生成内容は見た目以上の意味を持ちます。文章の正しさと、表示処理の安全性は別の課題です。

情報確認日：2026年10月15日。本記事はOWASPのLLM05:2025とXSS対策資料、WordPress公式資料に基づく設計解説です。特定サービスでの新しい攻撃被害を報告するものではありません。以下の画面構成や確認手順は、本サイトからの提案です。

AIの出力も、アプリの外から届くデータとして扱う

OWASPのImproper Output Handlingは、モデル出力を十分に検証せず後続処理へ渡す問題を整理しています。AIが社内で動いていること、信頼する提供元のモデルを使っていることだけで、生成されたHTMLや操作指示を安全とみなすことはできません。根拠資料：OWASP：LLM05:2025 Improper Output Handling。

生成結果には、利用者の入力、参照したWebページ、取得文書の一部が混ざる場合があります。モデルに悪意がなくても、危険な要素を引用したり、想定外の形式を出したりする余地があります。「安全なHTMLだけ返す」というプロンプトを、表示側の検査の代わりにしないでください。

XSSは、攻撃者が用意した内容などがWebページ内で実行される問題です。影響は画面や権限、他の防御によって変わりますが、閲覧者としての操作や表示の改変につながり得ます。AIが返したという経路が加わっても、ブラウザーで実行される仕組みは無関係にはなりません。

文字として表示するなら、HTMLを解釈させない

回答を文字として見せるだけなら、通常の要素のtextContentなど、文字列をHTMLとして解析しない方法が検討できます。OWASPのXSS資料も、危険なinnerHTMLのような使い方を減らし、適切な文字表示先へ置き換えることを説明しています。根拠資料：OWASP：Cross Site Scripting Prevention Cheat Sheet。

ただし、どんな要素でもtextContentならよい、という意味ではありません。scriptやstyleのように特別な意味を持つ場所は別に扱います。要素名や属性名もAIに自由に選ばせず、アプリが決めた表示部品へ、検証したデータを渡す構成にします。

説明用のチャットUIなら、回答本文は段落の文字列、出典は別のリンク配列として受け取る方法があります。書式と内容を分けることで、どの値を文字として表示し、どの値をURLとして検証するかを明確にできます。JSONという形式自体が安全を保証するわけではありません。

Markdown変換の後に何ができあがるかを見る

MarkdownはHTMLより簡単な記法ですが、変換器の設定によっては埋め込みHTMLを通したり、リンクや画像を生成したりします。Markdownだから安全という一括判断を避け、利用するライブラリの仕様と設定を確認してください。

本サイトでは、不要なら生HTMLを無効にし、変換後の結果へ必要最小限の要素と属性だけを許す設計を提案します。サニタイズとは、許可した構造を残し、不要な構造を取り除く処理です。単純な文字列置換で特定のタグだけを削る方法と同じではありません。

処理順にも注意が必要です。検査済みの文字列を、その後のプラグインが再変換すれば、検査時と表示時の構造が違う可能性があります。OWASPも、サニタイズ後の変更で防御が崩れる点を説明しています。最終的にブラウザーへ届く内容まで、経路を追ってください。

リンクは表示文字列と移動先を分けて確認する

「公式資料」という表示があっても、そのリンク先が公式サイトであるとは限りません。URLは、文字としてエスケープするだけでなく、許可するスキームや用途を確認します。AIが作ったリンクを、そのままイベント処理や任意の埋め込みへ渡さないようにします。

外部リンクを別タブで開く場合は、用途に応じてnoopenerなどの属性も設定します。ただし、これらはリンク先の内容を保証する機能ではありません。フィッシング先の正当性確認や、AIが出典を実際に参照したかの確認は、別に必要です。

画像も単なる飾りではありません。外部画像を自動表示すると、閲覧時に外部へ通信が発生します。読み込み先、追跡の可能性、サイズ、許可する形式を検討してください。HTMLの実行を止めても、外部通信による情報の流れまで自動で消えるわけではありません。

WordPressでは、保存経路と表示経路の両方を点検する

WordPress公式は、出力の場所に応じてesc_html、esc_attr、esc_urlなどを使い分けることを説明しています。HTMLを許したい本文では、wp_ksesやwp_kses_postで許可する構造を制限する方法があります。関数名だけを覚えるより、文字とHTMLのどちらが必要かを先に決めます。根拠資料：WordPress Developer Resources：Escaping Data。

wp_kses_postは投稿本文向けに許可されたHTMLを残しますが、その許可範囲が独自のAIチャットに必要な最小範囲と一致するとは限りません。短い回答欄なら、より狭いタグと属性で足りる場合があります。既存の投稿機能を流用する場合も、実際の用途で判断します。

管理者での取り込み、独自REST API、テーマの表示、一覧の抜粋、管理画面のプレビューで、適用される処理が同じとは限りません。ブロックエディター用の形式で保存しても、カスタムHTMLや動的なブロックの出力まで無条件に安全になるわけではありません。

自動公開前のプレビューも、攻撃面になる

公開前の下書きだから危険はない、と考えると、確認する編集者の画面を見落とします。AI出力を管理画面のプレビューへ直接入れる実装では、その時点でHTMLが解釈される場合があります。保存前の確認、下書き表示、公開後の表示を同じ観点で点検しましょう。

本サイトでは、記事を表示する環境と管理操作の環境を可能な範囲で分け、AIが作ったHTMLを管理画面へ直接差し込まない構成を提案します。確認用画面であっても、不要なスクリプトの実行や、管理者としての操作につながる部品を持たせません。

見直し担当者が文章を読んだことも、技術的な検査の代わりにはなりません。大量の出力から、見えない属性や変換後の挙動を目視だけで検出するのは難しいためです。機械的な構造の制限と、内容を評価する編集作業を分けて実施します。

CSPは補助策として設計し、表示の安全性を先に直す

Content Security Policyは、許可するスクリプトや通信先を制限するために役立ちます。ただし、CSPを付けたから危険なHTMLを無条件に受け入れてよい、とはなりません。OWASPも、出力の扱いと併せた対策として位置付けています。

既存サイトでは、解析タグや外部部品との互換性が関係するため、いきなり広い設定変更をせず、影響を確認して導入します。動かなくなったから許可範囲をすべて広げるのではなく、必要な機能と発生した違反を照合します。

また、サニタイズのライブラリや表示フレームワークも更新対象です。導入時だけ安全性を確認し、そのまま固定してよいものではありません。変換器の変更時には、保存済みの古いAI回答を再表示する経路も含めて確認します。

ストリーミング表示では、途中の断片も確認する

回答を少しずつ表示するUIでは、生成中と生成完了後で処理が分かれる場合があります。完了した本文だけを検査しても、その前に断片をHTMLとして挿入していれば、検査より先にブラウザーが解釈する経路が残ります。本サイトでは、生成中は通常の文字として表示し、書式付き表示へ切り替える段階を明確にする方法を提案します。

一部分だけMarkdownを変換する実装では、後から届く記号によって構造の解釈が変わる場合もあります。断片、結合後、保存後の表示で、同じ安全条件が維持されるかを確認します。表示の滑らかさを優先する変更でも、危険な挿入方法へ戻っていないかをレビュー対象にしてください。

表示形式を変更するとき、古い回答も対象になる

保存済みの回答を、新しいMarkdown変換器で再表示する場合、過去には文字だったものが、新しい設定ではHTMLや埋め込みとして扱われることがあります。公開後のプレビューだけでなく、履歴の閲覧、管理者の検索結果、印刷用の表示なども点検します。

本サイトでは、回答がどの形式のデータかを保存時に明確にし、表示するコードが勝手に形式を推測しない構成を提案します。文字列の中にタグがあったらHTMLとみなす、といった曖昧な規則を避けます。既存データの移行が必要なら、許可する書式と失われる書式を確認し、検証用のコピーで見え方と安全性を確かめてから進めます。