AI時代のリッチテキスト形式（RTF）

Anthropic で Claude Code チームにいる Thariq Shihipar が、 2026年5月8日に「Using Claude Code: The Unreasonable Effectiveness of HTML」という記事を X に公開しました。 「HTML is the new Markdown」という宣言から始まる、AI の出力フォーマットとして Markdown ではなく HTML を活用するメリットを論じた内容です。

本記事では、この主張を起点に、Markdown と HTML の役割が AI 時代にどう分かれていくのかを考察します。 Markdown が消えるのではなく、役割が分かれていく、というのが筆者の見立てです。

要約：

• AI が生成するドキュメントには「閲覧が主目的のパブリッシュ先」と「編集・転送で次のコンテキストへ運ばれる中間素材」という異なる側面がある
• パブリッシュ先には HTML が、中間素材には Markdown が向く
• AI が HTML を選ぶのは Markdown と対立しているからではなく、仕様がオープンで生成しやすく既存資産が豊富だから

「HTML is the new Markdown」

Thariq は、AI に何かを生成させるとき、これまで Markdown を要求してきたが、 最近はほぼ HTML に切り替えている、と書いています。 HTML のほうが SVG・インタラクティブ要素・ページ内ナビゲーションを自然に組み込めるからです。 実際にThariq のチームは、20以上の HTML 出力例を thariqs.github.io/html-effectiveness で公開しています。

ここで重要なのは、AI 出力が Markdown に移り変わった背景です。 過去のモデル世代ではコンテキストウィンドウや出力最適化に制約があり、 Markdown のトークン効率の優位性が決定的だったため、Markdown が広く使われてきた、という事情があります（Simon Willison がブログ記事で整理しています）。

今はその制約がほぼ消え、HTML の生成も実用的な時間に収まるようになりました。加えて、エージェントハーネス側（Claude Code などの実行ループ）でも入出力の最適化が進んでいます。

つまり Thariq の主張は、HTML と Markdown の優劣を論じているというより、 Markdown を既定にしてきた理由が変わったので、選択肢を見直す時期だ、というメッセージとして読めます。

出力フォーマットを「パブリッシュ先」と「中間素材」で見る

「Markdown vs HTML」の議論は、ファイルがどの場面で使われるかを混ぜて語られていることが多い、と筆者は感じています。 こう整理すると見通しがよくなります。

パブリッシュ先は、閲覧が主目的の到達点です。 読まれて意図が伝わったら、それでファイルの役目はひとまず終わります。 このタイプのファイルにもフィードバック→再生成のループは存在しますが（後述）、 ファイル自体を別ツールへ持ち運んで再加工することは想定されていない、という意味で「終点」です。

中間素材は、編集や転送で次のコンテキストへ運ばれることを前提にしたファイルです。 原稿として書き換えられたり、別ツールへコピペされたり、コーディングエージェントがタスク過程で読み込んだりします。

なのでThariq の議論はパブリッシュ先に限定していて、中間素材としての議論は別途必要だと筆者は考えています。

プレビューからインライン編集へ

Claude の Artifacts や ChatGPT の Canvas は、一つのプレビューに対してチャットで変更を繰り返し依頼する形式の機能です。 プレビュー側のリッチ表現とチャット側の対話が紐づいた状態を保つので、 ユーザーは見えている成果物に対して直接フィードバックできます。 こうした UI が成立する以上、プレビューとチャットの間に内部表現があってしかるべきです。

その内部表現の上に、レビュー画面に直接フィードバックを返して AI に局所的に書き換えさせる UX が、ツールごとに形を変えながら実装されてきました。 Claude Artifacts（2024年6月ローンチ）と ChatGPT Canvas（2024年10月ローンチ）が、生成された成果物を別ペインに表示し、チャットで継続編集できる UX を提供しはじめました。 Canvas はコードや文章の範囲を選択して書き換えを指示する機能を備えています。

Antigravity（2025年11月）はブラウザのスクリーンショットを画像アーティファクトとして残し、それに Google Docs スタイルのコメントでフィードバックを返せます。 Claude Design（2026年4月）はビジュアルキャンバス上にインラインコメント・直接編集・調整スライダーを統合しています。 Cursor の Visual Editor（2025年12月、Cursor 2.2 から）や Windsurf の Browser Previews の Send element も、レンダリング結果の要素を選択して AI に指示する形を備えています。

これらは大きく分けて、コードの編集ポイント（CanvasやCursor の Cmd+K、Windsurf の Cmd+I含め）から、プレビューの編集ポイント（Antigravity、Claude Design、Cursor の Visual Editor、Windsurf の Send element）へと UX が広がってきた流れです。 後者は要するに、DOM ツリーをユーザーが選択して指示を送ると、AI がソースに反映する仕組みです。

この UX が成立するには、HTML の DOM のように、ノード単位で識別・参照できる構造が前提になります。 フラットな Markdown では、画面上の選択を内部で安定して指し示すことが本質的に難しい。 これも、AI 生成のパブリッシュ先で HTML が選ばれている構造的な理由のひとつだと筆者は推測しています。

共通しているのは「パブリッシュ先としての成果物を、人間が見ながらフィードバックし、AI が再生成する」というループです。

中間素材としての Markdown

ここまでパブリッシュ先としての HTML の話を見てきました。 一方、Markdown が中間素材として強みを発揮する場面は、次の3つに整理できます。

(1) AI が開発時に読み込む素材。 ADR（Architectural Decision Record）、仕様書、CLAUDE.mdまで。 コーディングエージェントが繰り返し参照する素材で、 構造化された自然言語として AI にとっても扱いやすく、Markdown が定着しています。

(2) テキスト編集での AI と人間の編集サイクル。 プレーンなテキスト情報としての原稿を書き、AI に直してもらい、また自分で直す、という往復のサイクルです。 Markdown は行・段落単位での編集ハンドルを持ち、生成コストも軽い。 HTML では差分が大きすぎて、テキストレベルでの編集サイクルが効率よく回りません。 ただし、前述のような 範囲を選択して AI に書き換えを指示するサイクルは HTML でも成立します。 Markdown が優れているのは、人間が直接テキストを書き換えるサイクルが発生する場面です。

(3) ツール間のポータビリティ。 Notion や Google Docs、各種ブログサービス、Slack、Obsidian など、 ナレッジワーカーが日常的に使うツールの多くが Markdown を共通語として受け入れます。 HTML は結果の共有を手軽にしてくれますが、ツール間の持ち運びでは余計なタグがノイズになりがちです。

そもそも Markdown は、人間が HTML を効率的に書くためのショートハンド（簡易記法）として John Gruber が作った記法です。 原稿テキストと印刷物プレビュー（PDF など）の関係に近く、プレビューに書き手や編集者が赤入れすることはあっても、それはパブリッシュ先を改善するためのフィードバックであり、プレビュー自体が中間素材になるわけではありません。 HTML と Markdown の関係も似た形だと筆者は捉えています。

パブリッシュ先としての HTML

HTML がパブリッシュ先として活きるのは、AI が生成して人間が読む成果物の用途です。 PR レビュー、教材、分析レポート、ダッシュボードなど、一度ブラウザで開けばそのまま動き、SVG・インタラクティブ要素・ページ内ナビゲーションを一つのファイルに収められます。

Thariq が紹介していた具体的なプロンプト例は、こういうものです。

Help me review this PR by creating an HTML artifact that describes it. ... Render the actual diff with inline margin annotations, color-code findings by severity ...
このプルリクエスト（PR）の内容をまとめたHTMLアーティファクトを作成して、レビューを手伝ってください。その際、実際の差分（diff）を表示し、マージンにインラインで注釈を入れ、指摘事項は重要度に応じて色分けしてください。

似た用例として、Simon Willison は同じ記事の中で、Linux のセキュリティ脆弱性「copy.fail 」の PoC として配布されていた難読化済み Python コードを解読・解説する HTML を AI に生成させる例を紹介しています。 コードの展開・色分け・要点の見出し付けが、まとまった一画面に収まって出てくる。これも「人間がそのまま読む」ためのパブリッシュ先としての HTML の使い方です。

実践的には、これまで Markdown で指示していた内容に「どういう視覚表現で出してほしいか」という要件を足すかたちになります。 diff を描画して、margin に注釈を置いて、深刻度で色分けして、というように、視覚要件まで指示文に書き込む。 HTML だからこそ、注釈付きの diff、色分けされた指摘、レイアウトされた要約が一発で出てきます。

このように指示を出すには、コードを直接書く必要はない代わりに、ある程度のデザイン知識（コンポーネント、レイアウト、色階層など）が必要になります。 プログラミング自体は AI に任せるかたちですが、Markdown のときは「見出しと本文を整える」だけで済んでいた指示出しが、HTML では視覚デザインまで含む指示に広がる、というのもちょっと面白いところです。

パブリッシュ先／中間素材で使い分ける

整理すると、こう分かれます。

予測されるのは、「AI 生成優位で、人間がそのまま読む」用途は HTML へ移行していく、というあたりです。 PR の概要、diff の提示、コードレビューの出力、プランニングドキュメントなどが代表例で、 Cursor、Windsurf、Kiro、Antigravity、Devin といった AI 開発ツールの GUI が年を追ってリッチ化していることが、その流れを後押ししています。 逆に AI が読み込む側のドキュメントと、ツール間を運ばれる中間素材は、Markdown のまま残るだろうと考えています。

なぜHTMLなのか

これは推測の話ですが、リッチな視覚表現を出すとき、AI が HTML（および Web 標準）を選びがちなのには、いくつかの条件が重なっていそうです。

1. 仕様がオープンで、特定企業のライセンスや実装に縛られない
2. プレーンテキストとして書ける（バイナリの Office 文書のように専用ライブラリを介する必要がない）
3. 既存資産が豊富（学習データに大量の Web 文書があり、AI にとって書き慣れた形式）
4. 生成コストが効率化しやすい（バイナリ操作やツール呼び出しを介すよりトークン効率がよい）

実例としては、Artifacts/Canvas 系の AI ツール（Claude Artifacts / Canvas / Antigravity / Claude Design）はもちろん、 プログラマブルな動画生成の Remotion、 AI がプロンプトから生成するスライドツール（Marp や Slidev、reveal.js ベースのMarkdownを介したもの）など、 リッチな視覚表現を扱う AI 系ツールはおおむねHTML / Web 標準の上に作られています。

従来 Office 文書が担っていた用途の一部が HTML に移っているのは、これらの条件が重なった結果として起きていることだと筆者は捉えています。

派生として注目しているのは、Claude Design でデザインした HTML をそのまま Claude Code に渡して実装に進める、というように、HTML が AI ツール間で受け渡される素材としても使われ始めている点です。 本記事ではパブリッシュ先と中間素材の二項に分けて整理してきましたが、HTML がその両方を兼ねる場面が今後増えていくかもしれない、という感触はあります。

終わりに

タイムラインを並べてみると、テキスト形式の系譜は .txt → RTF → RTFD → HTML → Markdown → AI Artifacts という流れになっています。

今 AI 出力で起きている「Markdown では足りない、HTML 的な表現がほしい」という動きは、 かつての .txt → RTF の流れ（プレーンテキストにスタイルや画像を足したくなった）を、別の文脈でなぞっているようにも見えます。 ただし AI 時代の特徴は、ただ「リッチ寄りに一周した」ことではなく、役割の分業に移行していることだと筆者は考えています。 Markdown も HTML も、それぞれの強みが活きる場面に向かって、徐々に整理されつつある、と言ったほうが近いかもしれません。

そう考えてくると、「HTML is the new Markdown」という言い方は、対立構図として読むとどうしても違和感が残ります。 HTML は Markdown の新版ではありませんし、 両者は別の役割を担うようになった、というのが本記事の結論と発見です。

関連記事リンク

AntigravityはどういうAIエディタなのか

GoogleがGemini 3と同時にAntigravityという新たなAI コーディングエディタを発表しました。 Google AntigravityGoogle Antigravity - Build the new wayGoogle Antigravity 内部技術としては、Google製のChromiumとV8エンジンを内蔵したエディタをGitHubが作った過程で生まれたElectronというフレームワークでマイクロソフトのWebエディタMonacoをデスクトップ化したVisual Studio CodeのOSS版ディストリであるCode-OSSをフォークしたWindsurfの取得時点のライセンスを使い再構築された[1]Googleの独自エディタアプリです（1周した！）。 [1]: 内部には Windsurf/Cascade 由来と思われるコード痕跡が見られる しサードパーティライセンス記述がある し開発チームにはKevin Houがいる ただし、表層の実装は魔改造Windsurf寄りでありつつも、プロダクト設計はKiroに近い方向へ振れており、AIエージェントを中心

laisolaiso