・AnthropicのClaude CodeチームThariq氏が2026年5月8日にHTMLをエージェント出力の第一選択にすべき理由を公開した。
・Markdownは100行超で読まれず、図・色・SVG・インタラクションを表現できないため、情報密度の限界がある。
・HTMLは表・CSS・SVG・JavaScriptを統合でき、ブラウザでそのまま共有できる「軽量アプリ」として機能する。
・スペック・PRレビュー・調査レポート・カスタムエディタなど9ユースケース20デモが公開された。
・Simon Willison氏も追従し『コンテキスト長の制約が消えた今、出力フォーマットを再考すべき』と評価した。
AIエージェントの出力フォーマットは長らくMarkdownが標準だった。シンプルで、ポータブルで、人間が手で編集できる。だがClaude Codeのように100行を超えるスペックや調査レポートを生成するエージェントが普及した現在、その制約が逆に枷になり始めている。
この記事ではAnthropic Claude CodeチームのThariq Shihipar氏が2026年5月8日に公開した記事「Using Claude Code: The Unreasonable Effectiveness of HTML」を起点に、なぜHTMLがエージェント出力の第一選択になりつつあるかを9つのユースケースで分解する。Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。
1. Markdownが「天井」に達した理由
Thariq氏は記事の冒頭で、Markdownを長らく愛用してきた立場から語り始めている。シンプルでポータブル、軽量なリッチテキスト機能を持ち、人間が直接編集しやすい。さらにClaudeはMarkdown内でASCIIアート図を作るスキルすら身につけてしまった。
しかしエージェントが強力になるにつれ、Markdownは制約として感じられるようになったという。100行を超えるMarkdownファイルは読む気力が湧かず、組織の他メンバーに共有しても誰も読まない。色・図・インタラクションを欲する場面で、Markdownでは表現が足りない。
もうひとつの転換点は「自分で編集しなくなった」ことだ。スペックやリファレンスやブレストの出力を、Thariq氏は手で書き換えず、Claudeにプロンプトで指示して書き換えさせている。となるとMarkdownの最大の強み「人間が手で編集しやすい」が消滅する。
・編集者は人間か、エージェントか。
・読者は1人か、組織やチームか。
・出力は「読み返すドキュメント」か「使い捨ての作業空間」か。
この3つの問いに対する答えが「エージェント／組織／作業空間」に傾いた瞬間、Markdownの優位性は崩れる。残るのは「ポータブルで軽量」だけだが、HTMLも単一ファイルでブラウザで開けるという意味では十分にポータブルだ。
2. HTMLが持つ8軸の情報密度
Thariq氏が論拠として挙げるのは、HTMLが持つ表現力の広さだ。Markdownが扱える情報の種類が「文字とリンクと表」に限られるのに対し、HTMLは8軸の情報を1ファイルに統合できる。
・表データ（table要素）。
・デザインデータ（CSS）。
・イラストレーション（SVG）。
・コードスニペット（script要素）。
・インタラクション（HTML+JS+CSS）。
・ワークフロー（SVG+HTML）。
・空間データ（absolute positioning, canvas）。
・画像（img要素）。
Thariq氏の言葉を借りれば「Claudeが読める情報のうち、HTMLで効率よく表現できないものはほとんどない」。これは誇張ではなく、Markdownでは妥協してASCIIアート図やUnicodeで色を近似していた問題が、HTMLでは素直に解ける。
実際にThariq氏はClaude CodeがMarkdown内でUnicodeを使って色を再現しようとしたスクリーンショットを記事に貼っている。これはエージェントが情報密度の壁を破ろうと苦肉の策で出した結果であり、HTMLを出力先に許せばそうした「歪み」が消える。
情報密度が上がると何が嬉しいか。エージェントが書きたい情報を圧縮せずに渡せるため、内容の正確さが上がる。読み手も同じ情報量を、視覚的構造化のおかげで短時間で把握できる。これは生産性の問題というより、エージェントと人間のコミュニケーション効率の問題だ。
3. 視覚的明瞭さと「実際に読まれるか」
100行超のMarkdownは読まれない、という現実問題は重い。Thariq氏は『個人として100行を超えるMarkdownは読まないし、組織のメンバーに読ませるのはまず無理だ』と書いている。これはエージェントが大規模成果物を出すほど深刻になる。
HTMLならタブ・図・リンク・サイドナビなど、ナビゲーション設計でこの問題を解ける。さらにレスポンシブにすればモバイルでも読める。共有の側面でも、Markdownはブラウザがネイティブにレンダリングしないため、メールやSlackで添付ファイルとして送る必要がある。
一方HTMLはS3など共有可能な場所にアップロードすればURLひとつで誰でも開ける。これは『スペック・レポート・PRライトアップが実際に読まれる確率』に直結する。Thariq氏は「読まれる確率がはるかに高くなる」と強調している。
読まれない成果物は存在しないのと同じという観点に立つと、HTMLのこの優位性は表現力以上に重要だ。組織の中でエージェント成果物を流通させたいなら、フォーマットの選択が普及速度を左右する。
4. 9ユースケース：HTMLが効く具体例
Thariq氏は記事の後半でコンパニオンサイトを公開し、20個の自己完結型HTMLファイルをカテゴリ別に並べている。9つのユースケースを以下に整理する。
| # | ユースケース | 主なデモ | Markdownが苦手な要素 |
|---|---|---|---|
| 1 | 探索＆プランニング | コード方針3案比較／ビジュアル探索／実装計画 | 横並び比較・モックアップ |
| 2 | コードレビュー | 注釈付きPR差分／PRライトアップ／コード理解 | 色付き差分・モジュール図 |
| 3 | デザイン | 配色案／コンポーネント案 | カラーパレット・実物 |
| 4 | プロトタイピング | ボタンアニメ／インタラクション | 動き・操作感 |
| 5 | 図解 | 技術ダイアグラム／フローチャート | SVG・色 |
| 6 | スライドデッキ | プレゼン用1枚物 | レイアウト・余白 |
| 7 | リサーチ | 調査レポート／概念解説 | 情報量・回遊性 |
| 8 | レポート | 週次ステータス／インシデント報告 | グラフ・タイムライン |
| 9 | カスタムエディタ | チケット並べ替え／フラグ設定UI | ドラッグ操作・出力ボタン |
注目すべきは「9. カスタムエディタ」のカテゴリだ。これは『製品にも再利用ツールにもしない、その作業1回限りのために作るUI』という発想で、Markdownでは到達できない領域に入っている。
例として「Linearの30チケットをNow/Next/Later/Cutの4列にドラッグ可能なカードとして並べ、最後にMarkdownでエクスポートするボタンを付ける」というプロンプトが紹介されている。これはClaude Codeが文書ではなく『使い捨ての小さなアプリ』を生成する世界だ。
5. 双方向インタラクションという新しい使い方
HTMLが単なる『見るためのドキュメント』を超える瞬間が、双方向インタラクションだ。Thariq氏は『デザインのスライダーを足して』『アルゴリズムのパラメータを調整できるノブを付けて』と指示できると書いている。
決め手は最後に『Copy as JSON』『Copy as Prompt』ボタンを置くことだ。HTMLで操作した結果をテキスト化し、それをClaude Codeにペーストして次のターンに渡せる。これでHTMLは『出力フォーマット』から『エージェントとの対話インタフェース』に格上げされる。
・最後にコピー用ボタンを必ず付ける。
・出力はClaudeが解釈しやすいJSON/Markdown形式に統一する。
・UI操作の意図を文章化する欄を1個設ける。
・これがないとUIで操作した内容が次のセッションに渡らず、HTMLが袋小路になる。
このパターンは「色・イージング曲線・正規表現・cronスケジュール」のように、テキストでの表現が苦痛な値を扱う場面で特に効果を発揮する。マウス操作で決めた値を、最終的にエージェントの世界に戻すブリッジとしてHTMLが機能する。
6. データ取り込み：Claude Codeを使う必然性
『なぜClaude.aiやClaude DesignではなくClaude CodeでHTMLを作るのか』という問いにThariq氏は明確に答えている。Claude Codeはローカルファイルシステム・MCP・ブラウザ・git履歴など、コンテキストの取り込み量が桁違いだ。
実例として、この記事自体を書く際にThariq氏はClaude Codeに『自分のcodeフォルダ内のHTMLファイルを全部読んで分類し、各タイプを表すダイアグラムだけを集めたHTMLを作って』と指示している。記事中の図はその出力結果だ。
Slack・Linear] B --> E[ブラウザ
Claude in Chrome] B --> F[git履歴] C --> G[コンテキスト統合] D --> G E --> G F --> G G --> H[HTMLアーティファクト生成] H --> I[ブラウザで閲覧] H --> J[S3経由で共有] H --> K[操作してエクスポート] K --> A
このコンテキスト統合能力があるからこそ、HTMLという『重い』フォーマットを意味あるものにできる。Claude.aiでアップロードできる文脈量だけでは、ここまでリッチなHTMLは作れない。
Claude Codeの拡張機能やMCPの全体像については Claude Codeベストプラクティスガイド2026 で体系的に解説しているので、コンテキスト統合の設計を深掘りしたい人はそちらも参照されたい。
7. HTMLとMarkdownの使い分け判断軸
すべてをHTMLにすべきという主張ではない。判断軸を整理すると、編集者と読者と寿命の3要素で分かれる。
| 判断軸 | Markdownが向く | HTMLが向く |
|---|---|---|
| 編集者 | 人間が頻繁に手で書き換える | エージェントが生成・更新する |
| 読者 | 開発者個人 | チーム・経営層・組織横断 |
| 寿命 | 長期保守する正本 | 1回読まれて捨てるレポート |
| 内容 | テキストとコード中心 | 図・色・操作・空間データを含む |
| 配布 | リポジトリ内・README | URL共有・S3・社内ポータル |
| 双方向性 | 不要 | UIで操作してエクスポート |
この表の左側に該当する文書はMarkdownのままでよい。CLAUDE.md・README.md・ADRなど『人間が長期に手入れする正本』は依然としてMarkdownが最適だ。
逆に右側に該当する文書はHTMLに切り替えると効果が出る。とくに『1回しか読まれないが情報密度が高い』成果物（調査レポート・PRライトアップ・実装計画）はHTML化のROIが大きい。
8. プロンプトパターンと導入手順
導入は驚くほど簡単だ。Thariq氏は『「HTMLファイルで作って」「HTMLアーティファクトで」と書くだけで十分』と書いている。スキル化を急ぐ必要はなく、まずプロンプトの感覚を掴むのが先だという。
ユースケース別のプロンプトテンプレートを4つ抜粋する。Thariq氏の記事から引用した実例だ。
オンボーディング画面の方向性が決められていない。
6つの異なるアプローチを生成してほしい。レイアウト・トーン・密度を変えて、
1つのHTMLファイルにグリッド配置で並べて比較できるようにして。
各案にトレードオフのラベルを付けて。
このPRのレビューを手伝ってほしい。HTMLアーティファクトを作って、
ストリーミング/バックプレッシャーのロジックに焦点を当てて説明して。
実際の差分にインラインで注釈を付け、重要度別に色分けして。
チェックアウトボタンを試作したい。クリックでアニメーションし
紫色に変わる動作を、複数のスライダーとオプションで調整できる
HTMLファイルにして。良い設定をコピーするボタンも付けて。
このシステムプロンプトをチューニングしている。
左に編集可能なプロンプト、右にサンプル入力3つを並べた
サイドバイサイドエディタを作って。文字/トークンカウンタと
コピーボタンも配置して。
特徴は『最後に何をエクスポートするか』を必ず指定している点だ。HTMLを単なる閲覧物にせず、操作結果をClaude Codeに戻すループを最初から設計している。これがHTMLを生産的に使うコツだ。
・まずPRレビュー1件をHTMLに置き換える。差分・注釈・サマリを1ファイルに。
・次に調査レポート1件をHTMLに置き換える。図とリンクを増やす。
・最後にカスタムエディタを1つ作る。チケット並べ替えやフラグ設定が候補。
慣れてきたら自分専用の /html-spec /html-review /html-research のようなスキル化を検討すればよい。ただし最初からスキル化すると『どんな粒度でHTMLが効くか』の感覚が育たないため、Thariq氏は段階的な導入を推奨している。
9. Simon Willison氏ら識者の追従反応
この記事は公開24時間以内にHacker News・X・各国のテックメディアで広く議論された。とくに重要なのが、長年Markdown派だったSimon Willison氏が立場を変えたことだ。
Willison氏は自分のブログで『私が長らくMarkdownを好んでいた理由は、初期GPT-4の8,192トークン制限下でMarkdownのトークン効率が極めて重要だったからだ』と書いている。コンテキスト長制約が大幅に緩和された2026年現在、その理由は弱まった。
さらにWillison氏は実例として、ある脆弱性CVEの解説をClaudeに『リッチでインタラクティブで、できるだけクリアに』と指示してHTMLで生成させ、SVG図と安全コールアウトとコード分解が一体化した成果物を見せている。
『出力フォーマットを再考する時期が来た、特に出力に関しては』というWillison氏のコメントは、HTMLへの転換がコミュニティに広がっていることを示している。GitHubには早くも html-artifacts という非公式スキルが登場した。
韓国・中国・日本のテックコミュニティでも翻訳記事や考察が出始めている。エージェントの成果物フォーマットを巡る議論は、過去5年Markdownが独占してきた領域に久しぶりに再考の波が立っている状況だ。
10. 注意点と限界
熱心に推奨される一方、HTMLには明確な限界もある。Thariq氏自身も認めているように、HTMLは人間が手で編集する文書としては読みにくい。CLAUDE.mdやADRをHTMLにする必要はない。
セキュリティ面でも、HTMLは任意のJavaScriptを実行できるため、信頼できないエージェントが生成したHTMLを社内で配るのはリスクがある。S3にアップロードする際はサンドボックス化されたサブドメインに分離する運用が安全だ。
・git diffが視覚的に役に立たない（バイナリ並みに変更が散らばる）。
・人間の手書き編集が困難で、Claude経由の修正が前提になる。
・JavaScript実行を含むため社内配布時のセキュリティ設計が必要。
・重い装飾を入れすぎるとファイルサイズが肥大化する。
・検索性はMarkdownより劣る（grep困難）。
これらの限界を踏まえると、HTMLとMarkdownはどちらが優れているかという二者択一ではない。『正本はMarkdown、生成物・共有物・操作物はHTML』という棲み分けが現実解となる。
最後に1つ、Thariq氏の記事の締めくくりは印象的だ。『HTMLドキュメントをClaudeと作るのは単純に楽しい。創作に深く関わっている感覚がある。それだけで十分な理由だ』。エージェントとの協働における『楽しさ』が成果物のフォーマットに依存するという観察は、見過ごされがちな本質を突いている。
まとめ
・Claude Codeチームの公式見解として、HTMLが情報密度・視覚明瞭さ・共有性で優れる。
・9ユースケース20デモが公開され、コミュニティに転換の波が広がっている。
・PRレビュー・調査レポート・カスタムエディタの3点から始めるのが現実的。
・正本はMarkdown、生成物・共有物・操作物はHTMLという棲み分けが現実解。
・最後にエクスポートボタンを設計するとHTMLが対話インタフェースに格上げされる。
スキルとしてのClaude Codeの体系的な活用法は Claude Skills徹底解説：使い方・実装パターン でも触れているので、HTMLパターンをスキル化する段階に進む際の参考にされたい。エージェント成果物のフォーマットは静かな転換期にあり、PRライトアップ1件をHTMLに切り替えるところから始めるのが最小コストの第一歩だ。
参照ソース
・Using Claude Code: The Unreasonable Effectiveness of HTML — Thariq Shihipar (2026-05-08) ・The unreasonable effectiveness of HTML — examples (companion site) ・Using Claude Code: The Unreasonable Effectiveness of HTML — Simon Willison (2026-05-08) ・Hacker News discussion #48071940
