The Unreasonable Effectiveness of HTMLについて追ってみる

概要

これまで LLM の出力フォーマットは Markdown が事実上のデフォルトでした。ところが Opus 4.7 で導入された100万トークンのコンテキストウィンドウ以降、Claude Code が数百行に及ぶ実装プランや技術仕様を出力するのが日常になり、Markdown の限界が顕在化してきました。

シンプルに、「読み手がモデルなら Markdown、読み手があなたなら HTML」。CLAUDE.md や SKILL.md のような設定ファイル(=モデルが読むもの)は Markdown のままで良いが、エージェントが生成するアウトプット(=人間が読むもの)は HTML の方が圧倒的に有利だ、という主張が界隈を賑わせています。

こちらについて少し追ってみたいという意図の記事です。

なぜ HTML なのか？

技術的な理由が明確で、HTML なら単一の自己完結ファイルに、スティッキーヘッダ付きの複雑なテーブル、SVG によるベクター図、script タグでの実行可能なコードスニペット、DOM に紐づく JavaScript インタラクション、絶対配置や canvas での空間レイアウト、base64 のインライン画像、文書スコープのスタイルシートをすべて詰め込める。
一方 Markdown で「色を表現しろ」と言われた Claude Code は Unicode 文字で近似しようとするという象徴的なスクリーンショットも紹介されていて、これは Markdown の構造的限界をよく表しています。

長さの問題も大きくて、PC では8つのセクションをタブで切り替え、スマホでは縦表示用に再構成される。読者は単調なテキストの壁をスクロールする必要がないという点が PR レビューや設計レビューでの認知負荷を大きく下げます。

使い方

シンプルにプロンプトの末尾に "create an HTML artifact" と付けるだけ。

Help me review this PR by creating an HTML artifact that describes it. I'm not very familiar with the streaming/backpressure logic so focus on that. Render the actual diff with inline margin annotations, color-code findings by severity and whatever else might be needed to convey the concept well.

「3回連続で同じパターンを使うようになったら、その時に Skill 化を検討すればいい。それより前にやるな」というのが Thariq のスタンスで、過剰なスキャフォールディングは逆効果という警告も明確に出されています。

使いどころ

発言元、Claude Code チームのThariq氏のギャラリーでは、PR レビュー、実装プラン、仕様の横並び比較、デザインモックアップ、ダイアグラム、レポート、カスタムエディタなどHTML アーティファクト例が出ています。
一方でターミナルベースのワークフローやプレーンテキストのコンテキストでは HTML がプレビューできないため、Markdown の実用的優位性は残る。.html ファイルとして保存してブラウザで開くか、Claude.ai の Artifacts、ブラウザベースの IDE が前提です。

まとめ

ドメインモデルレビューや実装プラン、リサーチレポート(供給網6カテゴリの構造化サマリ)あたりはまさに HTML 出力が刺さる領域で、テーブル・色分け・SVG ダイアグラム・タブ切り替えがあると、ステークホルダーに見せる時にも段違いに使いやすいものになる。

CLAUDE.md は今まで通り Markdown のままで、出力指示の方で create an HTML artifact を付ける、というハイブリッドが現実的な落としどころだと思います。

引用元