HTML is the New Markdown——AIが作る資料のフォーマット、どう選ぶか

「長くて読めない」「どこを見ればいいか分からない」——資料を配ったのに、そう言われた経験はないだろうか。精度の高い実装計画を Claude Code で生成したとき、私も同じ壁にぶつかった。600行に及ぶ Markdown ファイルをチームに共有した翌朝、Slack に飛んできたのは「ちょっと読みきれなかったんだけど」という一言だった。

「HTML 化が良いと聞いたが、自分のチームに当てはめていいのかわからない」という感覚も、おそらく多くの人が持っている。実際、この判断は単純ではない。何でも HTML にすればよいわけではなく、Markdown が依然として優位な場面が明確に存在する。

Anthropic Claude Code のエンジニアリングリード Thariq Shihipar が 2026年11月に発表した「HTML is the New Markdown」論は、この問いへの一つの答えだ。作成者・利用者それぞれのメリット、トークンコストの現実、そして「自分の資料はどちらか」を判断するための基準を、この記事でまとめた。

発端: Thariq の一言が 4.4M views を集めた理由

2026年11月8日、Anthropic Claude Code エンジニアリングリードの Thariq Shihipar が個人サイトに「HTML is the New Markdown」と題した記事を公開した。X（旧 Twitter）で 16時間のうちに 4.4M views、8,200 likes、15,700 bookmarks を集め、Hacker News でも 1,000 points 超のスレッドが立った。

これほどの反響が起きた理由は、Thariq の主張が「あー、それ困ってた」という体感に刺さったからだと思う。彼の核心は次の一文に集約される。

> Markdown is a report. HTML is an interface.

レポートは読んで捨てる。インターフェースは作業を続けられる。

この区別は、Claude や類似のエージェントが「数百行に及ぶ実装計画や技術仕様」を当たり前に生成するようになった 2026年の文脈と重なる。Anthropic が Opus 4.7 で 1M token context window を導入したことで、AI の出力はさらに長大になった。フラットな Markdown では、その情報量を読者が消化しきれなくなってきた。

Thariq は HTML を使うべき場面として、探索・計画、コードレビュー、デザインプロトタイピング、図解・イラスト、プレゼン・研究、レポートの6カテゴリを整理している。「読むだけでなく操作したい」「長文で構造ナビが要る」「視覚的な情報がある」という条件がカテゴリをまたいで共通する。

作成者が HTML に切り替えるとき何が変わるか

配布が一行で終わる

Markdown ファイルを共有するとき、受け取った相手には IDE・GitHub・専用エディタのどれかが必要になる。HTML はブラウザリンクで完結する。「URL を Slack に貼る」だけで、相手が何を使っていても開ける。PDF も配布できるが、検索性が低く、クリッカブルな要素も持てない。

長い資料が「読まれる」に変わる

実装計画が600行になったとき、Markdown のフラット構造では読者はスクロールしながら「今どこにいるか」を見失う。HTML なら collapsible sections で章ごとに折りたたみ、sticky TOC でどこからでも全体を把握できる。読者が必要な部分だけ展開できる設計にすることで、「長い = 読まれない」という制約が崩れる。

インタラクティブ要素を単一ファイルに収める

Thariq が示した例では、コードレビュー結果に severity フィルタ、リスク表に重要度ソート、設計案にコピーボタン付きスニペットを埋め込んでいる。Markdown だと Notion や Figma など別ツールで作っていたインタラクションが、単一 HTML ファイルに収まる。

HTML 生成のコストは LLM がほぼゼロにした

「HTML は手間がかかる」という感覚は、人間が手で書いていた時代の話だ。Claude への指示に「single-file HTML レポートで」と一行追えば、tabs・collapsible・inline SVG まで一発で出る。LLM が HTML 生成コストを実質ゼロにしたことで、この判断の非対称が生まれた。

受け取る側の体験が変わる

作成者のメリットだけに目が向きがちだが、受け取る側の体験もかなり変わる。

PR レビュー結果が HTML で届いたとする。severity フィルタで critical だけ抽出できる。ファイルパスで並び替えられる。各 issue を collapsible で展開・収納できる。「対応済み」状態を local state で保持できる。これらを Markdown のフラットリストでやろうとすると、別ツールへの転記が必要だった。

モバイルでの読みやすさも変わる。HTML のレスポンシブレイアウトが効くので、スマートフォンで開いても可読性が保たれる。EM が移動中にメンバーから「これ確認してほしい」とリンクを受け取る場面で、HTML レポートであれば電車の中でそのまま確認できる。

「情報の正しさ」だけでなく「情報の見え方」を含めて成果物が完結する。これは、相手を動かすというドキュメントの目的に直結する話だ。Thariq が "joy factor"（喜びの係数）と呼んでいるのは、こういう感覚のことだと思う。

トークンコスト 2〜5倍の現実

ただし、HTML をコンテキストに含めるコストは無視できない。Thariq が PR レビュー1件で示した数値はこうなる。

1M context の 0.55% は許容範囲に見えるが、複数の HTML を同時にコンテキストに積み上げると話が変わる。Sonnet 4.6 の入力コスト（$3/1M tokens 想定）で換算すると、Plain Markdown は $0.0034/PR、Full HTML は $0.0164/PR。1日100件のコードレビューを HTML 化すると、月30日で約 $39 の差になる（入力分のみ。出力トークンを含めるとさらに広がる）。規模次第では効いてくる数字だ。

複数の解説記事では、Markdown は HTML よりトークンが 10〜20% 少ない傾向があると報告されている。表データの抽出精度については、GPT 評価による特定ベンチマークで Markdown 60.7% に対し HTML 53.6% という結果も報告されている。「LLM が読む」用途では Markdown の方が効率が良い場面があるという認識は持っておきたい。

Thariq 本人が明示した「Markdown のままで良い場面」

HTML の話が広まると「何でも HTML 化すれば良い」という単純化が起きる。だが、Thariq 本人が「Markdown を使い続けるべき」と明示している場面がある。

Thariq の言葉を借りれば「HTML when the document has a third-party reader who will not modify it, Markdown when collaborative, indexed, or for automatic pipelines」。第三者が読むだけなら HTML、共同編集・インデックス・自動パイプラインが絡むなら Markdown。この区別が判断の基点になる。

Thariq の発表に対し、Hacker News のスレッドにも批判的な声はあった。HTML は共同編集が難しい、という指摘はその筆頭だ。