markdownは古いのか：Thariq「HTMLの不合理な有効性」とAI性能の壁

AnthropicのThariq氏（@trq212）がXで公開した記事「Using Claude Code: The Unreasonable Effectiveness of HTML」が、わずか半日で300万を超える閲覧を集めて話題になっています。趣旨は「AIに長尺ドキュメントを書かせるなら、もうmarkdownではなくHTMLにすべきだ」というもの。

ただし、これは「markdownは古い」という単純な話ではありません。Thariq氏自身も「自分はHTML maximalist寄りだ」と但し書きを入れていますし、HTML出力という戦略がそもそも有効に働くかどうかは、使うAIの性能に大きく依存します。本当に重要なのは、AIエージェント時代に文書形式の役割が分化してきたという構造の話です。本記事では、Thariq氏の主張を整理した上で、ワークフローの種類とAIの性能という二つの軸で出力形式の使い分けを考えてみます。

1. Thariqが言っていること：HTMLの不合理な有効性

Thariq氏が指摘するmarkdownの限界はシンプルです。第一に、100行を超えるとほとんど誰も読まない。第二に、表現力が足りず、ASCII図やUnicode文字で色を表現するような苦肉の策に陥る。第三に、ファイルとして共有しづらく、ブラウザで素直にレンダリングできない。

一方のHTMLは、Claudeが生成する多くの文書要素や図解、インタラクションを、1つの成果物として表現しやすい形式です。情報密度が高いだけでなく、視覚的な構造化、モバイル対応、リンク共有、双方向のインタラクション（スライダーやボタンで挙動を試せる）まで実現できる。Thariq氏自身は、spec作成、コードレビュー、設計プロトタイプ、レポート、カスタムエディタなど、ほぼすべての成果物をHTMLに移行したと述べています。

2. Ejimaの整理：中間言語と化粧コンパイル

この記事への日本語圏の反応で印象的だったのが、Kenn Ejima氏（@kenn）のXポストです。Ejima氏は「人間がコンパイル結果のバイナリを触らないという縛りが可能になると、こういうパラダイムシフトが起きる」と整理しています。

つまり、markdownは「AIを駆動する新世代のプログラミング言語であり、プログラマーが読み書きする中間言語」。一方、一般ユーザーに渡すドキュメントは、それをHTMLに「化粧コンパイル」したartifactである、というアナロジーです。

ソースコードとバイナリの関係に重ねると、確かに腑に落ちます。markdownはAIと人間（プロンプトを書く側）が触れる中間表現で、HTMLはエンドユーザーに届ける最終成果物。Thariq記事の本質を一段抽象化した整理だと言えます。

3. ワークフロー別の使い分け：3つのパターン

ここからが本題です。Ejima氏の整理を踏まえつつ、用途を三つのパターンに分けてみます。

(1) 流れる情報：チャット応答、エージェント間の短い受け渡し、CLAUDE.mdのような構成ファイル。トークン効率が重要で編集も発生する場面では、markdownが圧倒的に強い。チャットUIがそのままレンダリングしてくれる利便性も大きく、ここをHTMLで置き換える理由はほぼありません。

(2) 共同編集する情報：specを二人三脚でこねる、プロンプトを推敲する、要件をまとめながら何度も書き換える。人間とAIの双方が編集を繰り返す文書は、git diffに優しく、エディタで素直に開けるmarkdownが向いています。HTMLはdiffがノイジーで編集の往復に向かない（Thariq氏自身もこの欠点を認めています）。

(3) 結晶化した情報：レポート、設計書、技術解説、ピッチ資料、PRの説明文。一度作ったら基本的に「読まれる」だけで、繰り返し参照される文書。ここでHTMLの情報密度と視覚的な明瞭さが効いてきます。Thariq記事が射程に入れているのは、ほぼこの領域です。

4. 第4のパターン：HTMLをそのまま次のAIに食わせる

ここで、Thariq氏の議論をさらに自分のワークフロー寄りに引き寄せた使い方を一つ挙げておきます。「HTMLにまとめた成果物を、そのまま次のAIセッションのコンテキストとして渡す」というワークフローです。

自分は別のチャットでやり取りした内容をHTMLにまとめてもらい、それを次のセッションへの引き継ぎ素材として渡す、ということをよくやっています。あるいは、数字をちょっと書き換えるくらいの軽微な修正ならエディタやメモ帳でも触れるので、HTMLを少し手直ししてから別のAIに渡す、という使い方もできる。HTMLの中に図表や構造が整理されていれば、次のAIも、少なくとも構造化された引き継ぎ資料として読み取りやすくなる可能性があります。「人間が読むため」と「次のAIが読むため」の両方を兼ねる成果物として、HTMLは意外なほど機能します。

ただし、これは常にHTMLがAI向けの中間表現として優れている、という意味ではありません。HTMLを次のAIに渡す価値が出るのは、図表、配置、視覚的な強調、インタラクションといった、HTML固有の構造そのものが意味を持っているケースです。単純な議事録や要件整理であれば、依然としてmarkdownのほうが軽くて扱いやすい。

つまり、結晶化した情報としてのHTMLは、人間にも次のエージェントにも効く二重の意味を持つ成果物になりうる。中間言語と成果物の二層モデルが少しねじれる場面で、Thariq記事の射程を一歩超えるところだと考えています。

5. もう一つの軸：AIの性能

ここまではワークフロー軸の話でした。しかし、忘れてはいけないもう一つの軸があります。AIの性能です。

「HTMLにすればいい」という戦略が成立するのは、AI側に十分な表現力とコンテキスト窓があってこそです。具体的には、Claude Opus 4.7やChatGPTの最新モデルといったフロンティア級のLLMが念頭にあります。これらのモデルなら、CSSの設計を含めた一貫性のあるHTMLを書けるし、SVGで意味のある図を生成でき、長尺の文書でも構造を維持できる。

一方、手元で動かすローカルLLM、たとえば話題のGPT-OSS 20Bあたりだと、HTML出力は荷が重いのではと感じます。厳密に検証したわけではなく、あくまで体感ベースの話ですが、コンテキスト窓もローカルマシンのスペックに依存するため、長尺HTMLを安定して生成する条件は厳しくなりがちです。Thariq氏自身も認めているとおり、HTML生成はmarkdownの2〜4倍の時間がかかります。これは出力量や表現の複雑さに伴うコストでもあり、推論速度が遅いローカルモデルでは無視できないペナルティになる。実際のところどこまで通用するかは、きちんと比較検証してみたいテーマでもあります。

つまり、HTML戦略はフロンティアモデルの能力があってこそ本領を発揮する。ローカルモデルや軽量モデルを使う場面では、品質・速度・実効コンテキストの制約を見ながら、markdownを基本にしつつ必要な部分だけHTML化するほうが現実的な場合も多いでしょう。AI性能の階層によって、最適な出力形式も変わってくる、ということです。

まとめ

Thariq氏の記事は、「やっている人は前からやっていた」内容を、ついに正面から言語化したものです。だからこそ広く読まれた、と見るのが正確だと思います。

要点を整理するとこうなります。markdownが古くなったわけではなく、文書形式の役割が用途ごとに分化してきた。どの形式を使うかは、ワークフローの種類とAIの性能、この二次元で決まる。流れる情報や編集する情報はmarkdown、結晶化した成果物はHTML、そしてフロンティアモデルが手元にあるか否か。

盲目的にmarkdownを使い続けるのも、盲目的にHTML maximalistになるのも、どちらも筋がよくない。手元のAIが何で、これから書くものが「読まれる」のか「編集される」のか、そこを意識して選び分ける。Thariq記事のいちばんの価値は、その判断軸を可視化してくれたところにあるのだと思います。