HTMLはAIエージェントが求める形式

2026年5月8日、AnthropicでClaude Codeに携わるエンジニアのThariq Shihiparは、9カテゴリの知的作業にまたがってエージェントが生成した20個のHTML成果物を集めた個人サイトを公開しました。主張はひとつです。答えが空間構造、インタラクション、視覚的な証拠を含むなら、HTMLはMarkdownに勝ります。¹²

エージェント出力では、HTMLがMarkdownに勝ります。空間構造、インタラクション、視覚的な証拠は、文章にすると平板化される情報を運ぶからです。エージェントが出力する形式は、人間が検査する操作面そのものであり、その外側の包装ではありません。

この投稿は、5月14日のarXiv論文が「エージェント検索の品質は検索器ではなく実行環境に宿る」と示す6日前に公開されました。³ 同じ型が見えます。形式と実行環境は、包装ではなく基盤です。コンポーネントが意味を持つのは、その周囲の操作面がモデル出力を人間の検証可能なものへ変えた後なのです。

TL;DR

Thariq Shihiparは、コードレビュー、デザインシステム、プロトタイピング、探索、図解、調査、レポート、エディター画面にまたがる20個のHTML例を載せた関連サイトを公開しました。¹ 主張は、Markdownが本来は空間的に届く情報を直線化してしまう、というものです。差分、コールグラフ、横並びの比較、インタラクティブなプロトタイプには、文章にすると失われる意味があります。8KトークンのGPT-4ローンチ期には、トークン効率の高い既定形式としてMarkdownが広まりました。しかし現在のClaudeのコンテキストウィンドウ文書には、200Kトークンや1Mトークンのモデルが掲載されており、多くの成果物サイズで前提が変わっています。⁴⁵ FastAPIとHTMXのようなサーバーレンダリング型のノービルドWebスタックにとって、この投稿はエージェント側からの論拠になります。HTMLはモデルが生成したがる形式であり、ブラウザがすでに描画できる形式です。Markdownを経由すると、両端で忠実度を落とす変換手順が増えます。⁶

重要なポイント

エージェントを作る人へ： - 答えが比較、差分、フローチャート、移動可能な構造であるとき、エージェント出力をMarkdown既定にするのはやめましょう。HTMLを求め、エージェントに空間レイアウトまで引き受けさせるべきです。¹ - モデルの出力形式をツールの操作面の一部として扱いましょう。流れていく会話ログより、単一の描画済み成果物のほうが検査しやすいものです。⁷

インターフェースデザイナーへ： - HTMLは、デザインシステムがすでに出荷している媒体です。Markdownを経由すると忠実度を失う変換手順が入り、描画時にもう一度変換が発生します。¹ - 操作面とは、エージェントが生成するものそのものです。人間がエージェントの見たものを見られないなら、その操作面は壊れています。⁷

サーバーレンダリング型ノービルドスタックを運用するチームへ： - ビルドパイプラインではなくHTMLに賭ける判断には、いまやエージェント側の裏づけがあります。モデルが生成したがる形式と、ブラウザがすでに描画する形式が同じだからです。⁶ - サーバーレンダリング型サイトは、変換層を2回取り除きます。1回目はビルド手順で、2回目はエージェント出力でです。この2つの削減は重なって効いてきます。

Thariqが実際に主張したこと

ShihiparはAnthropicでClaude Codeに携わっています。ただし、この投稿はAnthropicの公式ブログではなく、本人の個人サイトに掲載されています。² 関連ギャラリーには、エージェントが生成した自己完結型のHTMLファイルが20個あり、HTMLが構造的にMarkdownを上回る9カテゴリの作業に分類されています。¹

中心にある主張は次のとおりです。

Web基盤を作る人にとって、2つ目の主張がいちばん重要です。デザインシステムがHTMLで出荷されるなら、エージェントもHTMLを生成すべきです。それ以外は、情報を落とす往復変換を持ち込みます。

20個の例そのものが論証です

Shihiparのギャラリーにあるカテゴリは、多くの人がいまコーディングエージェントに任せている作業を網羅しています。¹

• コードレビュー： 重大度ごとに色分けされたインライン注釈付き差分、強調された呼び出し経路を持つモジュールマップ。
• 探索： 横並びのコード方針、順番に読むのではなく選べるよう配置されたビジュアルデザイン案。
• デザイン： 生きたデザインシステムページ、実際にバリアントを描画するコンポーネント一覧。
• プロトタイピング： 実際のイージングカーブを持つアニメーション環境、クリックに反応するインタラクティブな流れ。
• 図解： インラインSVG図、注釈付きフローチャート、箱と矢印によるアーキテクチャスケッチ。
• 調査： 折りたたみ可能なセクション、ライブデモを含むインタラクティブな概念解説。
• レポート： 構造そのものが意味を運ぶ、整形済みのタイムラインとチャート。
• エディター： 成果物の中にエクスポート機能を埋め込んだカスタムインターフェース。

どれも、モデルが一度で生成したHTMLページです。共通する型があります。答えが空間的またはインタラクティブであり、描画された成果物が、Markdownなら文章で説明せざるを得ないものを保っているのです。

なぜ既定はMarkdownだったのか

Markdownがエージェント出力の既定になった理由は2つあります。どちらも、もはや以前ほど当てはまりません。

第1に、チャット出力の慣習が固まった時期、GPT-3.5とGPT-4世代は4Kから8K程度のコンテキストウィンドウにぶつかっていました。⁴ Markdownの簡潔さは、本当に強い制約でした。<div class="...">に使う1トークンは、分析に使えない1トークンだったからです。現在のClaudeのコンテキストウィンドウ文書には、多くのモデルで200Kトークン、Opus 4.1とSonnet 4.6で1Mトークンのコンテキストが掲載されています。⁵ 多くの検査用成果物では、トークン効率の議論は弱くなっています。

第2に、ターミナルレンダラーやチャットウィンドウはMarkdownを簡単に描画できますが、HTMLにはWebビューやブラウザタブが必要です。表面上の手軽さが、トークン面の議論が弱まった後もMarkdownを最も抵抗の少ない道にしていました。

Shihiparの投稿に重みがあるのは、著者がAnthropicでClaude Codeに携わっているからです。20個の例は抽象論ではなく、具体的な成果物です。² 同日に公開されたSimon Willisonの記事も同じ型を再現しています。Linuxのセキュリティ悪用手法の解説を、Markdownの説明文ではなく、インタラクティブなHTMLページとして描画した例です。⁸

HTMLが保ち、Markdownが落とすもの

議論を支える性質は4つあります。

それぞれの性質は、出力を文章へ平板化すると難しくなるエージェント作業の種類に対応します。差分は空間的な比較です。フローチャートはグラフです。デザインシステムレビューは視覚的な判断です。Markdownへ押し込めると、レンダラーが表示できたはずのものを読者に再構築させることになります。

実行環境とのつながり

エージェント検索の品質は検索器ではなく実行環境に宿ります。 この投稿では、検索手法そのものより、その周囲のローカル実行基盤が重要だと論じました。プロンプトの形、ツールの操作面、会話ログの整形、結果の届け方、再試行の振る舞いです。³

HTMLの議論は、同じ枠組みを出力へ広げます。モデルはどんな形式でも正しい答えを生成できます。けれど、どの形式を求めるかは実行環境上の契約の一部です。形式が違えば、検証可能な操作面も変わります。

• Markdownで届ける場合：ユーザーは上から下へ読み、何が重要かを判断し、構造を頭の中で再構築します。
• HTMLで届ける場合：モデルが構造にコミットし、レンダラーがその構造を走査しやすくし、ユーザーは読むというより検査します。

同じデータでも、操作面が違います。エージェント型デザインとは操作面のデザインです。 エージェントが出力する形式は、その操作面の一部であり、外側の包装ではありません。⁷

ノービルドスタックにとっての意味

このサイトのFastAPIとHTMXのガイドでは、JavaScriptのビルドパイプラインではなく、サーバーレンダリング型のHTMLを使う理由を説明しています。⁶ Shihiparの投稿は、そこにエージェント側の論拠を与えます。

• モデルはHTMLを生成したがります。
• ブラウザはHTMLを描画したがります。
• その間にMarkdownやJSXを挟むと、情報を落とす変換手順が2つ増えます。

ノービルドのサーバーレンダリング型サイトは、ビルド時の変換を取り除きます。エージェントから直接HTMLを生成すれば、出力時の変換も取り除けます。効き目は重なります。モデルからルートを通ってブラウザへ届くまで、同じ形式が中間形式なしで流れるからです。

これは、ReactやMarkdownがどこでも間違いだと言っているわけではありません。言いたいのは、変換手順のコストが両端から見えるようになったということです。両端を避けるスタックは、その分だけシンプルになります。

形式が重要です。実行環境も重要です。どちらも基盤です。

エージェント検索の論文とHTMLの投稿は8日違いで公開され、同じ形のことを主張しています。¹³

• 検索器はコンポーネントです。実行環境が基盤です。
• モデルはコンポーネントです。出力形式が基盤です。

コンポーネント思考は、局所的な改善を提案し続けます。検索器を替える、メモリを足す、モデルを差し替える、プロンプトを磨く。基盤思考は、ユーザーが見る操作面と、エージェントが生成する操作面を変えます。今週の2つの発見は、どちらも作業を後者の枠組みへ押し出しています。

実務上の動きは明快です。エージェントの答えが空間情報を含むなら、HTMLを求めましょう。エージェントがローカル実行基盤の中で動くなら、モデルより先にその基盤を計測しましょう。どちらも積み重なる改善です。ただし、単独で万能薬になるわけではありません。

FAQ

Anthropicがこの投稿を公開したのですか？

いいえ。Thariq Shihiparが自身の個人サイト、thariqs.github.io/html-effectiveness/で公開しました。¹ 彼はAnthropicでClaude Codeに携わっているため、権威性のシグナルは強いです。ただし、この投稿はAnthropicの公開物ではありません。²

この議論はすべてのエージェント作業に当てはまりますか？

いいえ。この投稿が明確に対象としているのは、空間構造、インタラクション、視覚的な証拠が意味を運ぶ作業です。短い事実回答やターミナルに閉じた出力では、Markdownはいまでもよい既定形式です。¹

トークンコストはどう考えればよいですか？

Markdownのコスト面の利点は、小さなコンテキストウィンドウと結びついていました。現在のClaudeのコンテキストウィンドウ文書には、200Kトークンと1Mトークンのモデルが掲載されています。そのため、この投稿で示されている成果物サイズでは、HTMLの冗長さに関するトレードオフが変わります。⁵

これはClaude Codeの既存のMarkdown既定を壊しますか？

いいえ。この議論は、検査のためにその場でモデルへ生成させる出力についてのものです。会話ログやターミナル出力の話ではありません。単一のプロンプトでHTMLを求めれば、自己完結した成果物を返してもらえます。¹

これはエージェント検索の実行環境に関する論文とどうつながりますか？

どちらの議論も、モデルそのものではなく、モデルの周囲にある基盤を指しています。検索品質はローカル実行基盤に依存し、出力品質は形式に依存します。コンポーネントは必要です。しかし、コンポーネントを信頼できるものにするのは基盤です。³

FastAPIとHTMXのチームは何をすべきですか？

出荷するAI機能では、HTMLを第一級の出力先として扱いましょう。同じ形式がモデルからルートを通ってブラウザまで流れ、ノービルドスタックはすでにその経路に最適化されています。⁶

参考文献