Html vs Markdown:AI出力をインターフェースとして再定義する
AIエージェントが200行の計画書を作成。しかし20行目以降は誰も読みません。問題はコンテンツではなくフォーマットです。AI出力を「読む終点」から「操作の起点」に変える設計思想を探ります。
AIエージェントが完璧な200行の計画書を作成しました。しかし、20行目以降を読んだ人は誰もいません。問題はコンテンツの品質ではなく、出力フォーマットにあります。
誰も読まなかった計画書
いま、あらゆるチームで同じ光景が繰り返されています。AIエージェントが200行の実装計画書を生成しました。ロジックは明確、技術的にも正確、Markdownのフォーマットも整っています。その計画書がチームのSlackチャンネルに投稿されました。3日後の週次ミーティングで、PMはこう言いました。「ざっと目を通しました。」
これはAIの能力不足ではありません。計画書の内容そのものは優れていました。問題はもっと根本的なところにあります。AIの文章生成能力は向上し続けています。しかし、人間の読解処理能力は追いついていません。
2026年5月、AnthropicのClaude Codeエンジニアリングリード Thariq Shihipar氏が「The Unreasonable Effectiveness of HTML」という記事を公開しました。16時間で440万ビュー、15,700ブックマークを記録し、大きな議論を呼びました。主張はシンプルかつ逆説的です。AI業界全体がデフォルトとしてきたMarkdownというフォーマットが、エージェント出力の消費効率を低下させている。同氏はほぼすべての場面でMarkdownの使用をやめ、HTMLに切り替えたとのことです。
この記事が提起したのは、単なるフォーマット論争ではありません。すべてのAIワークスペースが答えるべき本質的な問いが浮き彫りになりました。エージェントが複雑な成果物を生成するとき、それをどのような形で人間に届けるべきなのか。
Markdownがデフォルトになった経緯
現在の議論を理解するには、2022年に遡る必要があります。GPT-4のコンテキストウィンドウはわずか8,192トークンでした。同じコンテンツをHTMLで表現すると約8,000トークン、Markdownなら約2,800トークンで済みます。68%の削減です。トークン予算が8Kしかなく、出力が入力を圧迫する環境では、1トークンの節約が段落ひとつの生存を意味しました。Markdownは純粋なコスト効率で勝ったのです。
次に設定ファイルの普及がありました。CLAUDE.md、AGENTS.md、SKILL.md——エージェントエコシステム全体の土台がMarkdownで構築されました。コンテキスト内のあらゆる場所でMarkdownを目にしたエージェントは、当然のようにMarkdownで出力するようになりました。「エージェントの成果物はMarkdownで」と誰かが意思決定したわけではありません。トークンが希少だった時代の名残として、ただそうなっていたのです。
2026年の現在、コンテキストウィンドウは100万トークンまで拡張されています。Markdownが合理的だった制約はすでに解消されています。しかし、慣性は残り続けています。AI開発者コミュニティで高い信頼を得ているSimon Willison氏も認めています。GPT-4時代からMarkdownをデフォルトにしてきたが、Thariq氏の記事がその前提を見直すきっかけになったと。
測定されてこなかった認知コスト
2026年3月、BCGヘンダーソン研究所が1,488名のフルタイム労働者を対象に実施した調査がHarvard Business Reviewに掲載されました。従業員たちが「AIブレインフライ」と呼び始めた現象に、初めて定量的なエビデンスが示されました。
- AIの監視負荷が高い労働者は、情報過負荷が19%増加
- 監視負荷が低い労働者と比較して、意思決定疲労が33%増加
- 業務における重大エラーが39%増加
- 離職意向が39%増加
最も重要な知見は、AIブレインフライの原因がAIの使用ではなく、AIの監視にあるという点です。エージェントの出力を継続的に確認・評価・修正する認知負荷が問題の本質です。ここでフォーマットの問題が浮上します。Markdownにはこの監視負担を軽減する仕組みがありません。200行のMarkdownファイルは、均質なテキストの壁です。見出しと太字以外に視覚的な階層はなく、ナビゲーション機能もなく、不要な部分を折りたたむこともできず、コンテンツと対話的にやり取りする手段もありません。
神経科学のデータもこれを裏付けています。人間の大脳皮質の約30%は視覚処理に割り当てられています。聴覚はわずか3%、触覚は8%です。視覚はAndrej Karpathy氏の表現を借りれば「脳への10車線情報ハイウェイ」です。しかしMarkdownは、このハイウェイをほとんど活用していません。太字、見出し、箇条書きが視覚ツールのすべてです。
HBRの調査が記録した19%の情報過負荷増加は、Markdownの質を上げても解決しません。人間の脳が効率的に処理できるフォーマットで情報を届けることが必要です。
核心の転換：出力はドキュメントではなく、インターフェースである
ここで本記事の核心的な主張に至ります。AIエージェントの出力フォーマットは、組版の好みではなく、インターフェース設計の意思決定です。
2つのモデルを比較します。
Markdownの出力 = 読む終点。 コンテンツは線形に流れ、人間はスクロールし、受動的に読みます。すべてを吸収するか、途中で離脱するか（多くの場合、40行目あたりで離脱します）。ドキュメントが終わったところで消費も終わります。
HTMLの出力 = 操作の起点。 コンテンツはタブ、折りたたみセクション、ソート可能なテーブル、色分けされた重要度マーカー、インラインナビゲーションで構造化されます。人間はクリック、フィルタリング、注釈、アクションを実行します。出力はエージェントの仕事の終わりではなく、人間の仕事の始まりです。
2026年のAIエージェントが実際に何を生成しているかを見れば、このパラダイムシフトの意味が明確になります。短い回答の生成はもはやエージェントの主な仕事ではありません。実装計画、コードレビューレポート、競合分析、デザインの方向性検討、データサマリーなど、複雑な成果物を生成しています。これらはすべて、人間による確認・判断・アクションが必要な成果物です。
成果物がこの複雑さに達すると、フォーマットはもはや見た目の問題ではありません。人間が効果的に監督できるかどうかの問題です。Thariq氏はこう述べています。「HTMLを使うようになってから、これまで以上に作業の全体像を把握できるようになりました。」リッチな出力フォーマットは見栄えを良くするためのものではなく、AIの仕事に対する人間の主体性（agency）を回復させるものです。
Epsilla社のエンジニアリングブログはこの論点を端的に表現しています。「Markdownは受動性を促し、デフォルトの信頼と主体性の漸進的な喪失につながります。HTMLはAIの推論プロセスを透明かつインタラクティブにし、厳密なレビューを可能にします。」
HTMLが実現すること：5つのシナリオ比較
Thariq氏は20の実例HTMLファイルを掲載したコンパニオンサイトを公開しました。特に差が顕著な5つのシナリオを紹介します。
実装計画。 Markdown：200行の線形スクロール。HTML：ワークストリーム別のタブナビゲーション、折りたたみ可能なフェーズ詳細、埋め込みタイムライン、色分けされたリスクマトリクス。同じ情報でも、一方はしっかり読まれ、もう一方は流し読みされます。
コードレビュー。 Markdown：プレーンテキストのdiffとインラインコメント。HTML：シンタックスハイライト付きの実際のdiffレンダリング、重要度別に色分けされたマージン注釈（赤/黄/緑）、各発見事項へのジャンプリンク、全体評価を一覧できるサマリーパネル。
選択肢の比較。 Markdown：各選択肢を順番に段落で記述。HTML：サイドバイサイドの2カラムレイアウト、色分けされた差分表示、下部の結論ボックスとインタラクティブなスコアリングマトリクス。
デザイン検討。 Markdown：4つのデザイン方向をテキストで説明。HTML：4つの完全なビジュアルモックアップ。フルスクリーンプレビューで、クリックして操作できる実際のインターフェースとして確認できます。
データレポート。 Markdown：モバイルでレイアウトが崩れるASCIIテーブル。HTML：ソート・フィルタリング可能なテーブル、インラインSVGチャート、画面サイズに適応するレスポンシブレイアウト、ホバーでコンテキスト情報を表示。
いずれのシナリオでも、HTMLが優位な理由は見た目の良さではありません。人間の脳が処理可能なフォーマットで、より高い情報密度を提供しているからです。そして、出力を「読むもの」から「操作するもの」に変えているからです。
フォーマットレイヤー原則：各レイヤーに最適なフォーマット
この分析の結論は「Markdownは終わった」ではありません。より正確には、AIワークフローの各レイヤーに異なるフォーマットが必要であり、業界はこの明確なパターンに収斂しつつあります。
入力レイヤー（人間 → AI）： Markdownが依然として最適です。システムプロンプト、設定ファイル、RAGパイプラインはすべて、Markdownのトークン効率と構造的な明瞭さの恩恵を受けます。研究によると、RAGシステムは生のHTMLよりMarkdownを取り込んだ場合、精度が最大35%向上します。
推論レイヤー（AI → AI）： 構造化データフォーマット（JSON、YAML）が最も効率的です。エージェント間の通信には色やレイアウトは不要で、パース可能な型付きデータが求められます。
デリバリーレイヤー（AI → 人間）： HTMLが優位です。主な読み手が複雑な出力を確認・理解・アクションする必要のある人間である場合、視覚的階層、ナビゲーション、インタラクティブ性は贅沢品ではなく必需品です。
判断基準をシンプルにまとめると、出力の主な読み手が別のLLMであればMarkdown、確認とアクションが必要な人間であればHTMLです。
もう一つの側面：リッチフォーマットのコストとリスク
公正な議論のために、トレードオフも正直に検討します。
トークンコスト。 クリーンなHTMLはMarkdownの約3倍のトークンを消費します。CSSやJavaScriptを含むHTMLは8〜10倍に膨れることもあります。1時間に数百のファイルを生成する高スループットパイプラインでは、このコストは無視できません。
セキュリティ。 AI生成のHTMLにはJavaScriptが含まれる可能性があり、クロスサイトスクリプティングやインジェクション攻撃のリスクがあります。Googleが策定したAgent-to-UI（A2UI）プロトコルは、エンタープライズのセキュリティチームがエージェント生成の任意HTMLを本番環境で実行することを許容できないために生まれました。サンドボックス化されたレンダリングが必須です。
アクセシビリティ。 AI生成のHTMLは通常、ARIA属性、説明的なalt テキスト、一貫したtab順序が不足しています。標準のMarkdownコンバーターはセマンティックな見出しと画像altをデフォルトで生成します。HTMLではWCAG 2.2 AA準拠のためにプロンプトで明示的な制約を追加する必要があります。
バージョン管理。 HTMLのdiffはノイズが多く、閉じタグや属性の変更が実際のコンテンツ変更を覆い隠します。Gitベースのレビューワークフローに依存するチームにとって、これは実際の摩擦となります。
いずれも解決不可能な問題ではありません。サンドボックスiframeがセキュリティに対応し、アクセシビリティ制約はプロンプトに組み込めます。トークンコストもコンテキストウィンドウの拡大とともに低下傾向にあります。しかし、リッチフォーマットの出力をプロダクションレベルにするために必要なエンジニアリングを明確にするために、これらの課題を認識しておくことは重要です。
AIワークスペースプロダクトへの示唆
AIワークスペースプロダクトを構築するチームにとって、フォーマットの問題はプロダクト設計に直結します。
レンダリングレイヤーは競争優位の接点です。 ユーザーがプロンプトに「HTMLで出力して」と書かなくても、エージェントの推論結果を自動的に人間が消費しやすいリッチフォーマットに変換するワークスペースは、体験品質で明確な差を生みます。フォーマット変換はプラットフォームレイヤーで実行されるべきであり、ユーザーのプロンプトに依存すべきではありません。
セキュリティは後付けではなく、組み込みで実現する必要があります。 ワークスペース環境内でのサンドボックス化されたHTMLレンダリング、CSPヘッダーとスクリプト隔離を組み合わせることで、生のHTMLのセキュリティリスクなしにリッチな出力を実現できます。
出力はワークフローの起点であるべきです。 テーブルはソート可能に。計画書は注釈可能に。コードは実行可能に。提案にはワンクリックのアクションボタンを。エージェント出力が静的なドキュメントからインタラクティブなアーティファクトに変わることで、ワークスペースは「AI結果を読む場所」から「AI結果に基づいて行動する場所」へと進化します。
誰が「ハンドル」を握っているのか
MarkdownとHTMLの議論は、ファイルフォーマットよりも大きなテーマに関わっています。2026年における人間とAIエージェントの関係そのものです。
エージェントの能力が向上し続ける中——数時間にわたる連続稼働、数千行のコンテンツ生成、複数ステップのワークフロー調整——人間の役割は、作業の実行から作業の指揮・レビューへとシフトしています。しかし、効果的なレビューには効果的なインターフェースが必要です。200行のMarkdownテキストの壁はレビューではありません。それはレビューの幻想です。
BCGの調査は、AI監視の認知負荷が過大になると、従業員が批判的レビューを行わずにデフォルトで出力を信頼してしまうことを示しました。これは最悪の結果です。人間が名目上はループに入っていながら、実質的には処理していないエージェントの成果物を承認しているだけの状態です。
リッチな出力フォーマットがすべての問題を解決するわけではありません。しかし重要な課題に対処します。「ヒューマン・イン・ザ・ループ」が本来発揮すべき判断力を、人間が実際に行使するための視覚的・インタラクティブなツールを提供すること。 AI出力のフォーマットが、誰が本当に「ハンドル」を握っているのかを決定します——仕事をレビューする人間か、仕事を生成したエージェントか。
AIエージェントが誰も読まない計画書を生成しているなら、問題はエージェントにあるのではないかもしれません。エージェントが仕事を届ける方法にあるのかもしれません。
本記事は、AI ネイティブワークスペースの設計原則を探るwukong.aiブログシリーズの一部です。人間とAIの協働に関する最新の知見をお届けします。