HTMLはAI出力の新たな標準になるか？Anthropicエンジニアが提唱する「脱Markdown」論
現在、ほぼすべてのLLM（大規模言語モデル）が生成するコンテンツのデフォルト形式はMarkdownです。これは至極当然のことと思われてきました。なぜなら、LLMは本質的にテキストを生成するものであり、Markdownは純粋なテキストのみで、見出し、リスト、太字、コードブロックなどの基本フォーマットをレンダリングできるためです。低コストで互換性が高く、ツールチェーンが成熟しているMarkdownは、天然の最適解と言えるでしょう。
しかし、AnthropicのClaude Codeチームに所属するエンジニアのThariq氏は、異なる視点を提示しました。彼は2026年5月8日に公開した記事『Using Claude Code: The Unreasonable Effectiveness of HTML』の中で、**「Markdownでは不十分であり、HTMLこそがAI出力の新たな標準になるべきだ」**という挑発的な主張を展開しました。
この記事は公開直後に100万回以上の閲覧数を記録し、Djangoの共同創設者であるSimon Willison氏などの著名な開発者が「ここ3年間のMarkdownデフォルトの習慣を再考している」と賛同を示すなど、大きな議論を巻き起こしています。
「人間が書くのではないなら、なぜ人間に最適化した形式を使うのか？」
Thariq氏の論理はシンプルです。Markdownは2004年にJohn Gruber氏によって設計されましたが、その目的は「人間が純粋なテキストを用いて、迅速にHTML構造を記述すること」でした。つまり、Markdownは本質的にHTMLの簡略版であり、「書きやすさ」のために表現力を大幅に犠牲にしています。横並びのレイアウト、インタラクティブな要素、内蔵SVGチャート、色の指定、アニメーションなどは不可能です。
人間が文書を作成する時代において、この妥協は合理的でした。しかし、作成主体がAIに代わった今、「書きやすさ」という設計思想に意味はあるのでしょうか？ AIは人間のように入力速度に制限されておらず、秒間数千トークンを出力できます。AIに必要なのは「速く書けること」ではなく、「意図を完全に表現できるフォーマット」です。そして、ブラウザのネイティブ言語であるHTMLは、Markdownが不可能なあらゆる表現を天然にサポートしています。
Thariq氏は、自身のデモサイト（thariqs.github.io/html-effectiveness）で、AIが生成した単一ファイルのHTML事例を20個提示しました。そこにはコードレビュー、デザインシステム、プロトタイプ、スライド、レポートなど、開発者が日常的に接するほぼすべてのシーンが含まれています。
HTMLが圧倒的な優位性を持つ3つの理由
これらの事例を分析すると、HTMLが優れている理由は以下の3点に集約されます。
-
情報の「次元」を維持できる コードの左右比較（diff）、モジュール関係図、デザインパレットなどは、本来「二次元的」な情報です。Markdownでこれらを表現しようとすると、情報を一次元の直線的に並べるしかなく、ユーザーは脳内で空間的な再構成を行う必要があります。HTMLなら、2列・3列に直接レンダリングし、視覚的に瞬時に比較させることが可能です。
-
インタラクティブな理解を可能にする アニメーションの調整スライダー、クリック可能なプロトタイプ、リアルタイムでノードを増減させるハッシュリングのデモなどです。これらは静的なテキストでは、どれだけ詳細に記述しても伝わりません。HTMLによる動的な視覚化は、Markdownとは伝達効率において桁違いの差があります。
-
HTMLこそがコンテンツの「ネイティブ言語」である デザインシステムのカラーパレットやコンポーネントの状態表示など、そもそもHTMLで表現されるべき内容をMarkdownで記述することは、遠回りをしているのと同じです。16進数のコードを列挙するより、色の塗りつぶしとして直接表示する方が遥かに直感的です。
依然として残る「現実的な制約」
とはいえ、Thariq氏の主張には議論すべき点があります。彼が想定しているのはあくまで「AIが生成し、人間が読む最終成果物」という限定的なシーンです。Agent間のデータ受け渡しや、バージョン管理が必要な文書においては、依然として軽量で解析しやすいMarkdown（または純粋なテキスト）が正解でしょう。
また、現実的な課題として以下の2点が挙げられます。
- コスト： インラインCSSやJSを含むリッチなHTMLファイルは、同等のMarkdownに比べてトークン量が5〜10倍に膨らみます。これはAPIコストに直結します。
- 速度： トークン量が増えれば生成時間は長くなります。即時性が求められるシーンでは、HTMLの生成待ち時間はユーザー体験を損ないます。
Thariq氏は、プロンプトキャッシュ（Prompt Caching）を利用して固定的なCSS/JS部分をキャッシュさせることでコストを抑える手法を提案していますが、これは高度なエンジニアリングが必要であり、一般ユーザーがすぐに享受できるメリットではありません。
結論：最終的な「正解」はHTMLでもMarkdownでもない？
Markdownは「Excel」のように、機能は限定的だが効率的で安定したツールです。一方、HTMLは「Google Sheets」のように、表現力は高いが環境依存し、パフォーマンスコストが伴います。おそらく、この二つは代替関係ではなく、用途に応じて共存し続けるでしょう。
しかし、さらに先を見据えると、HTMLすらも終着点ではないかもしれません。HTMLは30年の歴史的負債を抱えたブラウザ向けフォーマットであり、AI生成に最適とは言えません。
真の解決策は、**「AI-nativeな出力フォーマット」**の登場でしょう。それは、HTMLレベルの表現力を持ちながら、Markdownに近い生成効率を実現するものです。既にその片鱗は見えています。
- 構造化データとレンダリングの分離： モデルはJSON等の意味構造だけを出力し、レンダリングはクライアント側のテンプレートで行う。Claude ArtifactsやChatGPT Canvasがこのアプローチに近いと言えます。
- テンプレート充填方式： predefinedなHTMLテンプレートの変数部分だけをAIが埋める形式。
結局のところ、Thariq氏の洞察は正しいと言えます。「人間が速く書くための制約」から解き放たれたAIにとって、表現力の制限は不自然なものです。短期的には「用途に応じた使い分け」が正解ですが、長期的には「AIによる効率的な生成」と「人間にとってのリッチな提示」を両立させた、全く新しい標準フォーマットへ移行していくことになるでしょう。
関連記事
読み込み中...