AI出力の新標準はHTMLか？Anthropicエンジニアが提案する合理性と課題
Markdownは現在、すべての大規模言語モデル（LLM）が生成するコンテンツのデフォルトフォーマットです。これが当然のことすぎて、多くの人はなぜかを考えたことがないかもしれません。実は理由は単純です：LLMの正式名称はLarge Language Modelで、テキストを生成します（マルチモーダルの場合は別ですが）。Markdownはプレーンテキストだけで見出し、リスト、太字、コードブロックなどの基本的なフォーマットをレンダリングできます。コストが低く、互換性が高く、ツールチェーンが成熟しており、ほぼ自然な最適選択です。
しかし、AnthropicのClaude Codeチームのエンジニア、Thariqは最近、異なる見解を提唱しました。2026年5月8日、彼は「Using Claude Code: The Unreasonable Effectiveness of HTML」というタイトルの記事を公開し、核心となる主張は「Markdownでは不十分で、HTMLこそがLLM出力の新標準であるべきだ」というものでした。この記事は公開当日に100万回以上の閲覧、約9000の「いいね」、11000以上のブックマークを獲得しました。多くの人が賛同を示し、例えばDjango共同創設者で有名開発ブロガーのSimon Willisonは、3年間のMarkdownデフォルト使用習慣を再考していると公言しました。Hacker Newsの関連議論もすぐにホットトピックになりました。もちろん、疑問を呈する声も多く見られました。
しかし、いずれにせよ、これは冗談のような主張ではありません。Thariqは完全な論拠を提供しており、真剣に検討する価値があります。
Thariqの論理：ドキュメント作成者が人間でなくなった今、人間設計のフォーマットを使う理由は？
Thariqの出発点は理解しやすいものです。Markdownというフォーマットは2004年にJohn Gruberによって設計され、当時の目標は一つだけでした：人間がプレーンテキストで迅速にHTML構造を作成できるようにすること。换句话说、Markdown本質的にはHTMLの簡略版であり、人間の書きやすさのために表現能力を大幅に犠牲にしました。並列レイアウト、インタラクション、SVG埋め込みグラフ、色分け、アニメーションなどがありません。
この犠牲は人間がドキュメントを作成する時代には完全に合理的でした。しかし、Thariqの疑問は、ドキュメント作成の主体がAIになった今、「人間が速く書く」という設計仮定はまだ成立するかということです。AIには迅速な入力は不要で、毎秒数千トークンを出力できます。必要なのは意図を完全に表現できるフォーマットであり、ブラウザのネイティブ言語であるHTMLは、Markdownではできないことを自然にサポートしています。
これを証明するため、Thariqは記事だけでなく、専用のデモサイト（thariqs.github.io/html-effectiveness）を構築しました。そこでは、AIが生成した単一ファイルHTMLが20個公開されており、9つの作業シナリオをカバーしています：探索と計画、コードレビュー、設計システム、プロトタイプインタラクション、チャート図解、スライド、研究学習、レポート、およびカスタム編集インターフェースです。開発者や技術チームが日常的に遭遇するドキュメントタイプをほぼ網羅しています。
20の例から見るHTMLの優位性：3つの理由に集約される
この20個の例を個別に見ると、HTMLが勝利するシナリオの理由は3つのカテゴリに帰着できます。20個の具体的な例を覚えるよりも、この3つのカテゴリを理解する方がはるかに役立ちます。日常の作業シナリオがどのカテゴリに属するかを直接判断できるからです。
第一のカテゴリ：情報が本質的に二次元であるにもかかわらず、Markdownが一次元に圧縮することで情報を喪失する。 Thariqが示すコード案の並列比較、diff注釈、モジュール関係図、デザインパレット、週次レポートやインシデントタイムラインなどがこのカテゴリに属します。これらのコンテンツの共通の特徴は、横向きの比較や全体的な俯瞰が必要なことです。Markdownは上から下への直列配置しかできず、案Aを見てから案Bを対照するには、頭の中で空間を再構築する必要があります。HTMLでは直接2列や3列にレンダリングでき、一目で比較が可能です。
diffやコールグラフはさらに典型的な例です。これらの情報は本質的に空間構造を持っており、線形テキストに圧縮するのはフォーマットの好みの問題ではなく、情報次元の喪失です。
第二のカテゴリ：コンテンツはインタラクションを通じて初めて理解可能であり、静的なテキスト記述はどれほど優れても一桁違う伝達効率になる。 このカテゴリの例には、アニメーションサンドボックス（スライダーでイージング曲線を調整可能）、クリック可能なマルチスクリーンプロトタイプフロー、一貫性ハッシュリングのリアルタイムノード追加デモンストレーション、左側でプロンプトテンプレートを編集し右側でリアルタイムプレビューするデバッガーなどがあります。これらのシナリオでは、Markdownが「少し劣る」のではなく、根本的にこの機能を実現できません。動的に調整可能なビジュアライゼーションと、それを記述したテキストでは、伝達効率に数量級の差があります。
インタラクティブ性の必要性に関しては、HTMLとMarkdownの間にトレードオフの余地はなく、「できるかできないか」の問題です。これがThariqの主張の中で最も説得力のある部分です。
第三のカテゴリ：HTML自体がコンテンツのネイティブ言語であり、MarkdownでHTMLを記述するのは回り道である。 設計システムのパレットレンダリング、コンポーネントの異なる状態の表示、いくつかのHTMLタグで構築されたページ可能スライドショーなど、これらのシナリオではHTMLは「より良いフォーマット」ではなく、コンテンツ自体がHTMLで生きています。デザイントークンをカラーブロックとしてレンダリングする方が、16進コードのリストを並べるより直感的です。コンポーネントの状態を直接表示する方が、「ホバー時に色が深くなる」とテキストで記述するより効果的です。Markdownで次元を下げ、読者に頭で再構築させるのは、不必要な回り道です。
また、Thariqが提示するカスタム編集インターフェース（タスクカンバン、Feature Flagエディター）にも注目すべきです。それらには興味深い設計パターンがあります：ユーザーがHTMLインターフェースでドラッグ操作を行い、「Export」ボタンで結果をMarkdownやJSONなど、エージェントが利用可能なフォーマットに変換します。HTMLはここでインタラクション層であり、終点ではありません。このアイデアは後で「最終解」を議論する際に再び取り上げます。
しかし、Thariqの主張はやはり絶対的すぎる
まず一つ明確にしておくことがあります：Thariqが議論しているのは比較的狭いシナリオです——「AIが生成し、人間が読む最終成果物」、例えばPR説明、技術レポート、概念説明、設計レビュードキュメントなどです。エージェント間で中間結果を渡すのにHTMLを使うべきだとは言っていませんし、バージョン管理のドキュメントにHTMLを使うべきだとも言っていません。これらのシナリオでは、Markdownやプレーンテキストが依然として合理的な選択です。なぜなら、マシンには豊かなレンダリングは不要で、パース可能性と軽量さが求められるからです。
この境界を理解した上で、彼の主張をより正確に評価できます。彼が定義したシナリオ内では、HTMLの表現能力は確かに構造的優位性を持っています。しかし、「HTML is the new markdown」という実際の操作提案としては、現時点では2つの乗り越えられない問題があります。
第一はコストです。 完全なリッチフォーマットHTMLファイル（インラインCSS、JavaScript、SVGを含む）のトークン量は、同等のMarkdownの5倍から10倍になる可能性があります。現在のAPI価格設定では、特に高頻度呼び出しシナリオでは無視できない差異です。
第二は速度です。 より多くのトークンは、より長い生成時間を意味します。即時フィードバックが必要なインタラクティブシナリオでは、AIがCSSやJSを含むHTMLファイル全体を出力するのを待つと、Markdownとの体験の差は肉眼で明らかなものです。
Thariq自身はこの問題に対処するエンジニアリング実践を持っています——以前にprompt cachingに関する記事を書きました。Claude Codeの実行フレームワークは高いキャッシュヒット率に基づいており、HTMLファイル中の不変のCSSやJS部分はキャッシュでき、モデルは変化するコンテンツのみを生成します。これにより、実際のトークンコストは直感よりかなり低くなります。しかし、これは実行フレームワークの精密な設計に依存しており、一般ユーザーまたは開発者が箱から出してすぐに得られる効果ではありません。
もちろん、これらの制約には重要な特徴があります：それらは時間的なものであり、構造的なものではありません。トークンコストと生成速度の低下傾向は非常に明確で、半年ごとに数量級の変化があります。「HTMLは高くて遅い」という反論は今日成立しますが、1年後には成立しないかもしれません。
有用的な類推：ExcelはなぜGoogle Sheetsに置き換えられなかったか？
ここで思考を助ける類推を導入しましょう。Excelは「ウェブ時代」に生き残りました。それは機能がGoogle Sheetsより強いからではなく、制約された环境下でより安定しているからです：ローカル計算はネットワークに依存せず、大量データセットの処理遅延が低く、VBAマクロエコシステムが完全で、ローカルファイルシステムとシームレスに統合されます。Google Sheetsはコラボレーションと配布に優れていますが、パフォーマンス敏感なシナリオではネイティブアプリに勝てません。
マッピングすると、MarkdownはExcelに似ています——機能は限られていますが効率的で、軽量で、オフライン可能で、バージョン管理に友好的で、ツールチェーンが成熟しています。HTMLはGoogle Sheetsに似ています——表現能力はより強いですが、パフォーマンスオーバーヘッドと環境依存があります。
この類推には2つの意味があります。第一の意味は：ExcelはGoogle Sheetsの出現で消滅せず、異なるシナリオで共存しています。MarkdownとHTMLもおそらく同じです——置き換えではなく、シナリオの分化です。
第二の意味はより注目に値します：Excelが生き残れたのは、コアの優位性であるパフォーマンスに依存しており、パフォーマンス優位性の源はハードウェアとネットワークの制約です。これらの制約がなくなれば、ウェブアプリが徐々にその領地を侵食します（事实上、これはすでに起きています）。同様に、Markdownのコア優位性はトークン効率と生成速度です。これらの制約が急速に解消され続けるなら、「Markdownがより効率的」という論拠も弱まります。
では、LLM生成結果の最終解とは？HTMLでもMarkdownでもない可能性
Thariqは正しい方向を指摘していますが、HTML自体も终点ではないかもしれません。毕竟、HTMLは「人間のブラウザのために設計された」フォーマットであり、仕様には30年の歴史的負荷——クロスブラウザ互換性、後方互換性、複雑なレンダリングモデル——が詰まっています。AI生成ドキュメントにはこれらは一切不要です。
より合理的な予想は：最終的には「AIネイティブ」の出力フォーマットが登場し、HTMLレベルの表現豊かさと、Markdownに近い生成効率を備えるということです。すでにいくつかの方向がこの方向に収束しつつあります。
第一のアプローチは構造化データとフロントエンドレンダリングの分離です。 モデルはセマンティック構造のみを出力し（例えばJSON）、レンダリングロジックはクライアントテンプレートに固定します。モデルが実際に生成するコンテンツ量は非常に少なくなりますが、最終的な表示効果は完全なHTMLと同じくらい豊かになります。Claude ArtifactsやChatGPT Canvasは本質的にこのアプローチを取っています——モデルはドキュメントオブジェクトを状態維持し、毎回全量のHTMLをゼロから生成しません。このアーキテクチャのトークン効率は、HTMLを直接生成するよりはるかに高いです。
第二はテンプレート填充パターンです。 AIは定義済みのHTMLテンプレート内の変数スロットを埋めるだけで、空白から完全なファイルを生成しません。コスト構造はMarkdownに近く、出力品質は手書きHTMLに近いです。現行のコスト制約下では、これが最も現実的な中間パスかもしれません。
第三の可能性はさらに遠い：新たなセマンティックフォーマット標準です。 XMLがかつて試みて成し遂げなかったことに似ています——セマンティック構造とレンダリング指令を備えつつ、HTMLよりはるかに軽量です。エージェント間のコラボレーション規模が拡大し続けるなら、このフォーマットへの需要が強まり、誰かが作り出すでしょう。
前に言及した「HTMLをインタラクション層として使用し、Exportボタンでマシン可読フォーマットに戻す」という設計パターンは、すでにこの方向を示唆しています：入出力には軽量フォーマット、表示層にはリッチフォーマットを使用し、明確な変換インターフェースで接続します。未来の「最終解」はおそらく、このパターンを標準化したものになるでしょう。
まとめ
Thariqのコア観察は正しいです：Markdownの設計仮定は「人間が迅速に書く必要がある」というものから来ており、AI生成ドキュメントのシナリオではこの仮定は成立しなくなり、HTMLは表現能力で構造的優位性を持っています。彼は20の実例でこれを証明し、開発者の日常的なドキュメントシナリオの大半をカバーしており、論拠は堅実です。
しかし、「HTML is the new markdown」という現時点で実行可能な提案としては、トークンコストと生成速度の制約が完全に解消されるまでは、やはり絶対的すぎます。より正確な言い方かもしれません：HTMLはAIドキュメント出力が進むべき方向を示していますが、現在の最適実践はシナリオに応じて選択することです——インタラクションとビジュアルの豊かさが必要な最終成果物にはHTMLを、軽量さとパース可能性が必要な中間フォーマットには引き続きMarkdownを使用します。二者は分業関係であり、置き換え関係ではありません。
さらに遠くを見ると、MarkdownとHTMLはどちらも终点ではないかもしれません。真の「最終解」は、AIドキュメントの第一原理から導かれるべきです——最適化の目標は「人間が速く書く」ことでも「ブラウザがよくレンダリングする」ことでもなく、「AIが効率的に生成し、表示が豊かで、人間が直接読みやすい」ことです。このフォーマットは今日まだ存在しませんが、Claude Artifacts、ChatGPT Canvasなどの製品の進化方向から、その輪郭はすでに見え始めています。
関連記事
読み込み中...