2026年5月8日、AnthropicのClaude CodeチームのエンジニアであるThariq Shihiparが、AI開発者コミュニティのスクロールを止める記事を公開しました。タイトルは「Using Claude Code: The Unreasonable Effectiveness of HTML」。
48時間以内に、この記事はXで75万回以上の閲覧、14,000件のいいね、30,000件のブックマーク、1,600件の引用投稿を記録しました。Simon Willisonは示唆に富むと評しました。開発者エコシステムは、これまで誰も真剣に問うたことのない質問で沸き立ちました。私たちがAIエージェントとのコミュニケーションに使ってきたMarkdownというフォーマットが、実は間違ったフォーマットだとしたら？
Thariqが記事と共に公開した20の実用HTMLアーティファクトのギャラリーに裏付けられたその答えは、開発者がエージェント出力について考える方法を再形成しつつあります。
Markdownが第1ラウンドを勝ち取った理由
この切り替えがなぜ重要なのかを理解するには、そもそもMarkdownがデフォルトになった理由を理解しなければなりません。
2022年、ChatGPTが8,192トークンのコンテキストウィンドウでリリースされた時、すべてのトークンが貴重でした。同じコンテンツに対して、HTMLはMarkdownの約3倍のトークンを消費します。HTML文書は約8,000トークンであるのに対し、同等のMarkdownは約2,800トークンです。コンテキスト予算全体が8Kトークンで、出力が入力を圧迫する場合、5,000トークンを節約することは、失われていたはずの段落単位のコンテキストを救うことを意味しました。
Markdownはコスト面でその戦いに勝ちました。当時の制約を考えれば合理的な選択でした。
AI開発者コミュニティで最も影響力のある声の一人であるSimon Willisonは、先週それを認めました。彼はGPT-4の時代からまさにその理由でLLM向けにMarkdownを書いてきました。そして彼は間違っていませんでした。当時の計算に照らせば、誰も間違っていなかったのです。
しかし、その計算が変わりました。
Claude Opus 4.7は100万トークンのコンテキストウィンドウを搭載しています。これはMarkdownをデフォルトにした8Kウィンドウの122倍です。予算が100万トークンの時、2,800と8,000の差はノイズです。Markdownのデフォルトを生み出した制約は消滅しましたが、そのデフォルト自体は約4年間、疑問視されることなく生き残りました。
HTMLが運べるがMarkdownが運べない8つのこと
Thariqの記事は、エージェント出力をMarkdownに強制したときに失うもののシンプルなカタログから始まります。全文を読む価値がありますが、以下が8つのカテゴリです。
1. 配置とセル結合が可能な本物のテーブル。 Markdownのテーブルは単純なグリッドを超えると壊れます。HTMLテーブルは列結合、行結合、配置をサポートし、重要な行を一目で強調するようにスタイリングできます。
2. CSSでスタイリングされた視覚的階層。 Markdownでは強調が太字、斜体、コードブロックに限られます。HTMLは色、サイズ、間隔、境界線、レイアウトを追加します。情報をスキャン可能にする視覚的語彙です。
3. インラインSVGダイアグラム。 これが最大の違いです。Markdownでは、ClaudeはASCIIアートに頼ります。棒グラフにはパイプ文字、カラースウォッチにはUnicodeブロック、矢印にはダッシュ。HTMLでは、本物のベクターグラフィックを描きます。スケーラブルで、正確で、実際に読めるものです。
4. JavaScriptインタラクティビティ。 折りたたみ可能なセクション、タブ付きコードサンプル、ライブフィルター、ドラッグ＆ドロップ。Markdownは静的メディアです。HTMLはランタイムです。
5. 単一ファイルに埋め込まれた画像。 Base64エンコードされた画像がHTML内に一緒に含まれます。壊れた参照リンクも、ファイルが見つからない会話もありません。
6. 空間的なキャンバスレイアウト。 並列比較、グリッドレイアウト、マージン注釈、コールアウトボックス。Markdownは上から下へ流れます。HTMLは指示した場所へ流れます。
7. クリック可能なノードを持つワークフローダイアグラム。 ボックスと矢印で描かれたデプロイパイプラインで、ステップをクリックすると実行内容、タイミング、失敗パスが表示されます。Markdownは番号付きリストしか提供しません。
8. 自己完結型で共有可能なアーティファクト。 1つの.htmlファイル。ダブルクリックするだけ。すべてのダイアグラム、スタイル、インタラクティビティがそのまま、どのブラウザでも開きます。依存関係も、ビルドステップも、設定の驚きもありません。
共通の糸：Markdownは人間が文章を書くために作られました。HTMLは豊かな情報をレンダリングするために作られました。出力が計画書、レポート、レビュー、プロトタイプである場合——READMEではない場合——豊かな情報のために作られたフォーマットが勝ちます。
ASCIIダイアグラム税
Thariqのギャラリーの一例が、どんな議論よりも要点を明確に示しています。
Claude Codeにデータセットを分析して結果をMarkdownで出力するよう依頼すると、次のようなものが生成されます。
Q1 Sales by Region
| Region | Revenue |
|---------|----------|
| North | ████████ | $2.4M
| South | ██████ | $1.8M
| East | ████████ | $2.6M
| West | ████ | $1.2M
これが、1990年代のREADMEフォーマットに強制されたときにClaudeが行うことです。即興で対処します。Unicodeブロック文字で棒グラフを偽装します。データではなく外観の近似にトークンを費やします。
同じ質問をしてClaudeにHTMLを出力するよう指示すると、適切な軸、比例した棒、ラベル、凡例を持つ本物のSVG棒グラフを描きます。同じデータ。同じエージェント。しかし2番目の出力は、同僚が実際に開き、読み、行動に移すものです。
私たち自身もテストしました。同じデータセット、同じClaude Codeセッション、2つの異なるフォーマット指示。HTML版は編集なしでブラウザでレンダリングされました。Markdown版は3回の明確化ラウンドを必要とし、最終的には棒を近似するUnicodeブロック文字に落ち着きました。フォーマットがエージェントを制約するとき、出力品質もそれに従います。
Thariqのテーゼを要約すると：エージェントに表現力のあるメディアを与えれば、エージェントはそれを使います。ASCIIに制限すれば、エージェントは補償しようとしますが、下手です。
トークンコスト論争（そしてなぜもはや重要でないか）
HTMLエージェント出力に対する最も一般的な反論は予測可能です。トークンコストがかかるというものです。
確かにその通りです。Thariqはこれについて透明です。HTML出力は同等のMarkdownの約2〜4倍のトークンを使用します。2,800トークンのMarkdown文書が8,000〜11,000トークンのHTML文書になります。
しかし、この反論はThariqや他の人々が指摘しているように、2022年には真実だったが今は時代遅れの仮定に基づいています。コンテキストウィンドウが8,192トークンの場合、5,000トークンのオーバーヘッドは壊滅的です。コンテキストウィンドウが100万トークンの場合、それは予算の0.5%です。
Claude Opus 4.7、Gemini 3、GPT-5.5——2026年半ばのフロンティアモデルはすべて数十万から数百万トークンの範囲で動作します。Markdownを必要としたトークン節約経済は、HTMLを実現可能にする豊富さの経済に取って代わられました。
さらに重要なことに、Thariqはトークンコストは間違った指標だと主張します。正しい指標は、出力が実際に使われるかどうかです。誰も読まない2,800トークンのMarkdown計画書はすべてをコストとして消費し、何も提供しません。開かれ、理解され、実行に移される8,000トークンのHTML計画書は、より多くのトークンを消費し、価値を提供します。
HTMLがMarkdownに勝つ5つの実用ユースケース
Thariqの20のHTMLアーティファクトのギャラリーは9カテゴリにわたります。以下の5つは、Claude Codeを超えてあらゆるAIエージェントワークフローに一般化できるものです。
1. 仕様書と実装計画
Markdownの仕様書とHTMLの仕様書の違いは、テキストの壁と、タイムライン、データフローダイアグラム、インラインモックアップ、色分けされた重大度のリスクテーブルを備えた文書の違いです。実装者は2番目を開きます。1番目は流し読みします。
2. AIコードレビュー
マージン注釈、重大度タグ、ジャンプリンク付きでレンダリングされたdiffは、ターミナルをスクロールするよりも根本的にスキャンしやすいです。HTML版はビフォー/アフターの並列レンダリングもサポートしており、あらゆるシーケンシャルフォーマットよりも効率的に変更を伝える空間レイアウトです。
3. デザインとプロトタイプ
HTMLはデザインシステムがデリバリーされるメディアです。トークンはスウォッチになります。コンポーネントはコンタクトシートになります。持続時間とイージングのスライダーを備えたアニメーションサンドボックスは、散文の1段落では決して伝えられないことを5秒で伝えます。実際のクリックスルー動作で結ばれた4つの画面は、読むだけでなく感じることができるプロトタイプです。
4. 調査とレポート
折りたたみ可能なセクション、タブ付きコードサンプル、マージンの用語集を備えた説明文は、同じ言葉を線形にダンプしたものとは異なる読み心地です。小さなグラフと色付きタイムラインを備えた週次ステータスレポートは、人々が流し読みするものを実際に読むものに変えます。分単位のタイムラインとログ抜粋を備えたポストモーテムは、チームが無視するのではなく参照する文書です。
5. カスタム編集インターフェース
これが最もラディカルなカテゴリです。Thariqは使い捨てのHTMLエディターをデモします。30枚のチケットをNow、Next、Later、Cutにドラッグして結果をMarkdownとしてエクスポートするチケットトリアージボード、依存関係警告とdiffコピーボタンを備えた機能フラグエディター、ライブ再レンダリング付きのプロンプトチューナー。
これらは製品ではありません。オンデマンドで生成され、一度使われ、捨てられるワンオフツールです。そのカテゴリのアーティファクトはMarkdownには存在しません。エージェントが出力プリミティブとしてHTML、CSS、JavaScriptにアクセスできる場合にのみ存在します。
本当の理由：私はMarkdownの計画を読むのをやめた
DIY Smart Codeによるビデオ分析の終盤近くに、シフト全体を説明する一文が埋もれています。
私はマークダウンの計画を読むのをやめ、Claudeにすべての選択を任せた。
これがThariqが切り替えた実際の理由であり、トークン数、SVGの忠実度、どんな機能比較よりも重要です。
エージェント出力が読めないMarkdownの壁であるとき、人間はループから外れます。計画をレビューしません。ミスを見つけません。判断を適用しません。単に良さそうだと言ってデプロイするか、さらに悪いことにファイルすら開きません。エージェントはうまく機能しました。フォーマットがその仕事を見えなくしました。これは、今日のAIエージェントが提供できるものを制限する能力ギャップの背後にあるのと同じダイナミクスです。出力は技術的には正しいが、フォーマットが必要な人間に届かないため、実質的に使えません。
HTML出力はこのダイナミクスを逆転させます。出力が視覚的で、構造化され、スキャン可能であるとき、人間がループに再び入ります。ダイアグラムを見て「そのフローは間違っている」と思います。折りたたみ可能なセクションを開いて誤った仮定を見つけます。トリアージボードでチケットをドラッグして優先順位を調整します。フォーマットが、人間が意思決定プロセスに留まるか完全に委任するかを決定します。
これが、AI支援ワークフローを構築する誰にとっても最も重要であるべき議論です。目標はトークンコストを最小化することではありません。目標は人間とエージェントのコラボレーションの質を最大化することです。そしてコラボレーションを容易にするフォーマットが、トークン数に関係なくより良い結果を生み出すフォーマットなのです。
AI生成HTMLを公開する方法
エージェントが自己完結型のHTMLファイル（SVGチャート付きの調査レポート、注釈付きdiffのあるコードレビュー、クリック可能な画面のあるプロトタイプ）を生成したら、2つ目の質問に直面します。それはどこに置くのか？
ローカルファイルシステム上の.htmlファイルはあなただけにしか役立ちません。エージェント出力の価値は、URLを持ったときに倍増します。チームと共有したり、Slackスレッドに埋め込んだり、ステークホルダーに送信したりできるときです。HTMLを書けるが公開できないAIエージェントは、草稿は書けるが印刷できない作家のようなものです。出力は存在しますが、誰にも届きません。
今日の開発者が使用する3つのアプローチを、最も手動から最も自動の順に示します。
GitHub Pages
リポジトリにプッシュし、CIビルドを待ち、URLを取得します。恒久的なドキュメントページやプロジェクトサイトに適しています。エージェントが今朝生成したワンオフレポートにはオーバーキルです。公開のたびにGitコミットが必要で、つまりエージェントにリポジトリアクセスが必要であり、すべての使い捨てアーティファクトが恒久的な履歴を作成します。
手動クラウドアップロード（S3、R2）
HTMLファイルをバケットにアップロードし、パブリックアクセスを設定し、CORSを管理し、キャッシュ無効化を処理します。これは機能しますが、インフラ作業です。あなたがやらなくて済むようにエージェントに処理してほしかった種類のことです。エージェントレポートを公開するためにバケットポリシーを設定しているなら、自動化はすでに壊れています。
エージェントネイティブ公開プラットフォーム
3番目のカテゴリは、Thariqが説明するワークフローのために目的に合わせて構築されています。エージェントが出力を生成し、公開レイヤーが人間の介入なしに他のすべてを処理します。
これらのプラットフォームはプログラムによるアクセスのために設計されています。Webダッシュボードも、手動設定も、CMSログインもありません。CLIまたはAPI経由でコンテンツを受け入れ、レンダリングし、公開URLを返します。エージェントがパイプライン全体を制御し続けます。
例えば、AnyCapのようなプラットフォームは、エージェントに完全な公開パイプラインを形成する一連の機能を提供します。これはAIによるインスタントWeb公開ガイドで取り上げたのと同じパターンです。
- クラウドストレージ（Drive）——エージェントが生成した画像、CSVエクスポート、その他のアセットを永続的なクラウドストレージにアップロードします。壊れたファイルパスも手動アップロード手順もありません。
- ページデプロイ——単一のコマンドでHTMLまたはMarkdownファイルをライブの公開Webページに変えます。
anycap page deploy report.html --title "Q2分析"が公開ステップのすべてです。 - マルチフォーマットサポート——プラットフォームはMarkdownとHTMLの両方をネイティブにレンダリングします。エージェントは速度のためにMarkdownから始め、SVGダイアグラム、スタイル付きテーブル、インタラクティブ要素が必要なときにHTMLに切り替えられます。すべて同じコマンドでデプロイされます。
- 統合CLI——ページを公開する同じツールがWeb検索、画像生成、Webクローリングも処理します。エージェントは1つのタスクを完了するために5つのサービスを切り替えません。単一のランタイムから調査し、チャートを生成し、公開します。
実際の完全なパイプラインは次のようになります。
# 1. エージェントがトピックを調査
anycap search --prompt "最新のQ2パフォーマンスデータ" --json > research.json
# 2. エージェントがヒーローチャートをSVGとして生成
anycap image generate --prompt "Q2収益棒グラフ、クリーンな企業スタイル" \
--model nano-banana-2 -o chart.png
# 3. エージェントがアセットをクラウドストレージにアップロード
anycap drive upload chart.png
# 4. エージェントが自己完結型HTMLとしてレポートを作成
# （Claude Codeがチャートを埋め込んだHTMLファイルを出力）
# 5. エージェントがページを公開——1コマンド、ライブURL
anycap page deploy q2-report.html \
--title "2026年Q2パフォーマンスレポート" \
--description "インタラクティブチャート付きAI生成の四半期分析"
人間はCMSに触れていません。ホスティングは設定されていません。エージェントが調査し、ビジュアルを作成し、公開しました。すべて単一のCLIを通じて。
どのアプローチを使うべきか？
| アプローチ | 最適な用途 | エージェントフレンドリー？ | 必要なセットアップ |
|---|---|---|---|
| GitHub Pages | 恒久ドキュメント、プロジェクトサイト | 部分的（リポジトリアクセス必要） | リポジトリ + CI設定 |
| 手動S3/R2 | 既存インフラを持つチーム | いいえ（ファイルごとに手動） | バケット + IAM + CORS |
| エージェントネイティブプラットフォーム | エージェント生成レポート、プロトタイプ、ワンオフページ | はい（CLI/APIネイティブ） | CLIインストール、認証1ステップ |
正しい選択はワークフローによって異なります。エージェントがチームと共有する必要があるレポートを週に10件出力するなら、エージェントネイティブ公開レイヤーはすぐに元が取れます。月に1ページ公開するなら、GitHub Pagesで十分です。
フォーマットのシフト（MarkdownからHTMLへ）と配信のシフト（ローカルファイルからライブURLへ）は、同じコインの裏表です。一方は出力を読む価値のあるものにします。もう一方は共有する価値のあるものにします。
エージェント出力にHTMLとMarkdownのどちらを使うべきか
HTMLへの切り替えは教条的なものではありません。一部の出力はMarkdownの方が優れています。判断フレームワークはシンプルです。
| Markdownを使うべき時... | HTMLを使うべき時... |
|---|---|
| 出力が設定ファイルの場合（CLAUDE.md、SKILL.md） | 出力が人間に読まれることを意図している場合 |
| 出力がMarkdownを期待する別のツールに入力される場合 | 出力に視覚的構造が役立つデータが含まれる場合 |
| 出力が単純なリストや段落の場合 | 出力に比較、ダイアグラム、マルチパートレイアウトが含まれる場合 |
| 出力がバージョン管理されdiffされる場合 | 出力が共有、プレゼン、参照される場合 |
| 32K未満のトークンコンテキストで操作している場合 | 200K以上のコンテキストモデルを使用している場合（おそらくそうです） |
Thariqが暗黙的に提案する経験則：人間が読むことが予想されるなら、HTMLを検討してください。純粋にマシン間なら、Markdownで十分です。
結論
MarkdownがAIエージェント出力のデフォルトフォーマットになったのは、それが最良のフォーマットだったからではなく、深刻なトークン制約の時代において最も安価なフォーマットだったからです。その時代は終わりました。
Thariq Shihiparが提唱し、20の実用アーティファクトで実証しているシフトは、実際にはHTML対Markdownの話ではありません。AIエージェントの出力を、機械が解析するものとして扱うか、人間が消費するものとして扱うかの話です。4年間、経済性が強制したために前者に最適化してきました。経済性はもはや強制しません。
エージェントは良くなっています。コンテキストウィンドウは大きくなっています。出力はより複雑になっています。フォーマットが追いつく時です。
AnyCapチーム執筆。私たちは開発者がAIエージェントで構築する方法を形作るツール、フォーマット、ワークフローを分析します。
さらに読む：