Claude CodeチームのエンジニアリングリードThariq Shihipar氏は先頃、ブログ記事を公開し（Claude Codeの活用：HTMLの驚くべき有効性）、より豊かな可視化、色彩、インタラクティブ性を備えたHTMLは、特にデフォルトMarkdown出力と比較した場合に、多くの場面で人間－エージェント間コミュニケーションの生産性を向上させると主張した。ゴールのコミュニケーション、仕様のリファインメント、出力レビューが、エージェント型ワークフローの新たなボトルネックとなりつつある。
Shihipar氏は開発者間で共通するペインポイントについて述べた:
エージェントの能力がますます高まるにつれ、Markdownはますます制約の多いフォーマットになっていると感じています。具体的には、100行を超えるMarkdownファイルを読むのが難しいと感じています。
[…] 私自身もこうしたファイルを直接編集することは少なくなり、仕様書や参照ファイルとして利用するようになってきています。
[…] 出力形式としてMarkdownではなくHTMLを好むようになり、Claude Codeチームの他のメンバーも同様の傾向を見せています。
HTML推進派の主張は、エージェントが複雑で長時間にわたるワークフローで利用される機会が増えるにつれ、その出力の複雑さと長さも増大し、人間にとって認知的なボトルネックが生じるという観察に基づいている。支持者たちはこの課題に直面した開発者がレビューせずに出力をそのまま受け入れる誘惑に負け、将来的に品質、保守性、セキュリティ上の問題を引き起こす可能性があると主張している。
この見解によれば人間による入力が不可欠であり、自動化できないワークフロー（例．ゴールと経路設定、要件の探索とリファインメント、ガイド付きの修正）、または人間による妥当性確認と検証が必須となるワークフローでは、エージェントの出力形式は提示された情報の要点と詳細の両方を素早く把握でき、ユーザーにより設定したゴールをサポートできるものであるべきだ。
Shihipar氏はその時々のゴールに合わせてカスタマイズされた視覚的かつインタラクティブなワークスペースを作成するため、Markdownより単一ファイルのHTMLアーティファクトを好んでいる。つまり、仕様策定、プランニング、探索；コードレビューと理解；インターフェース設計とプロトタイピング；データ探索、分析、可視化；一般に目的に合わせて設計されたユーザーインターフェイスが役立つあらゆる問題において、HTMLのベネフィットを得られるとShihipar氏は考えている。
このブログ記事の関連記事で、Shihipar氏はチケットのトリアージを迅速化するために作成された使い捨てのカスタムHTML出力例を紹介している：
/filters:no_upscale()/news/2026/06/anthropic-html-markdown-agent/en/resources/1claude%20html-1782325841515.png)
もう一つの例はPRレビュープロセスを迅速化することを目的としている。このHTML出力はターミナルをスクロールするよりも一目で把握しやすいようになっている：
/filters:no_upscale()/news/2026/06/anthropic-html-markdown-agent/en/resources/1PR-1782325841515.png)
Shihipar氏の主張はHacker News、Reddit、Mediumで広範な議論を巻き起こし、開発者たちはHTMLの視覚的な情報密度を歓迎する派と、Markdownのプレーンテキストのシンプルさを手放すことに警鐘を鳴らす側に分かれた。
Shihipar氏の初期フレームワークに対し、Simon Willison氏は現在のコンテキストウィンドウのサイズと、より高速かつ低コストになったモデルを考慮すると、Markdownをデフォルトの出力形式にすることはもはや最善の戦略ではない可能性があると指摘した：
私はGPT-4の時代から、ほとんどのものをMarkdownで出力するよう要求することをデフォルトにしてきました。当時は8,192トークンという上限があり、HTMLよりMarkdownのトークン効率の高さには極めて大きな価値があったからです。
Thariqのこの記事を読んで、特に出力に関してはその考えを見直すことになりました。ClaudeにHTML形式での説明を依頼すれば、SVG図やインタラクティブなウィジェット、ページ内ナビゲーションなど、情報をより快適に閲覧するためのさまざまな優れた仕組みを組み込めます。
一方で前述のようなユースケースであっても、MarkdownをHTMLに置き換えることは後退であると考える人々もいる。彼らはソースコードの可読性が失われること、安全でない可能性のあるHTMLに伴うセキュリティおよびインフラストラクチャ・リスク、Markdownと比較したHTMLのトークン税、Gitとの連携が最適ではないこと（例．差分表示）を強調している。
それにも関わらず、一部の開発者はカスタムツールを作成している(例．html-artifactsはGreg Dogum氏が開発したオープンソースのClaudeスキルであり、タスクに応じてHTML出力へ切り替える認識ヒューリスティックを備えている）。
結局のところ、Shihipar氏の主張はその作業に適したツールを使うというケースに当てはまるのかもしれない：
以上を踏まえると私がMarkdownではなくHTMLを使用する本当の理由は、Claudeのループに自分がより深く関与していると感じられるからです。Claudeがより多くの作業を担うようになるにつれ自分がプランを以前ほど注意深く読まなくなっていることに気づき、Claudeの選択を単に任せきりにするのではなく、その選択に関与し続けるための方法が欲しいと考えました。HTMLはまさにそのための方法だったのです。
AIエージェントプラットフォームでは標準的なテキストベースの仕組みに、よりインタラクティブなインターフェースを追加することなどを通じて、人間とエージェント間のインターフェースを改善する取り組みが積極的に進められている。特に生成UIにより、エージェントは人間の要求に合わせてカスタマイズしたUIをその場で作成可能になる。