同じ内容でも、Markdownで出すと流し読みされ、HTMLで出すと実際に読まれる。
AIエージェントの出力を眺めていると、この差がはっきり出る。
フォーマットを変えただけで、読まれ方が変わる。
はじめは、単なる見た目の問題に見える。
だが、なぜHTMLだと読まれるのかを追っていくと、話はフォーマットを離れていく。
事実と解釈をどう分けるか、認知負荷をどう制御するか。
最後は、人間とエージェントがどう情報をやり取りするか、という一つの問いに集まっていく。
HTMLとMarkdownの使い分け
出力フォーマットとしてのHTML
出発点は、ある観察だ。
AIエージェントの出力をMarkdownではなくHTMLにすると、流し読みされる文書が、実際に読まれる文書に変わる。
探索・計画、コードレビュー、デザイン、プロトタイピング、図解、スライド、リサーチ、レポート、カスタムエディタ。
これだけの領域で、自己完結型のHTMLが機能する。
ここで一つ、区別しておきたい。
これは一貫して出力フォーマットの話であって、入力フォーマットの話ではない。
唯一の例外がカスタムエディタだ。
エージェントがUIを出力し、人間がUI上で操作し、エクスポートしてエージェントに戻す。
このループが回ると、HTMLの出力が次の入力を作りやすくする。
入力自体はテキストのままだが、間接的に入力側へ効いてくる。
トークン効率と認知コストのトレードオフ
HTMLは、Markdownより明らかに冗長だ。
トークンを食う。
それでもHTMLを選ぶ判断の裏には、暗黙の前提がある。
ボトルネックは、トークンコストではなく、人間側の認知コストのほうだ、という前提だ。
だから、線引きは単純になる。
中間的な思考や分析を出すだけなら、Markdownで十分だ。
人間が判断し、操作し、共有する最終成果物では、HTMLの認知的リターンがトークンコストを上回る。
「常にHTMLにしろ」ではない。
ブラウザというレンダリングエンジンを、もっと使えるはずだという発想の転換だ。
実用的なのは、全部を切り替えることより、使い分けの基準を一つ持つことだ。
表現力の連続スペクトラム
その基準は、表現力のスペクトラムとして描ける。
静的テーブル → ソート可能なテーブル → フィルタ付きテーブル → ドラッグで並べ替えられるボード
求める操作のリッチさが上がるほど、Markdownの天井に近づく。
その天井を超えたい場面で、HTMLに切り替える。
判断基準としては、これで十分に立つ。
もう一つ、HTMLには地味な効き目がある。
エージェントのテキスト出力は、毎回フォーマットが自由に変わる。
だから人間は「どこを見ればいいか」を毎回探す。
HTMLでテンプレート的な構造を与えれば、出力の読み方が安定する。
情報設計の本質: 事実と解釈の分離
事実は構造化、解釈はナラティブ
ここから、話がフォーマットを離れる。
エージェントの出力が読みにくくなる根っこは、事実と解釈が混ざることにある。
- 事実は、構造化されたフォーマット（テーブル、箇条書き）で「漏れなく、均質に」出す。フリーフォーマットだと、欠落や余計な情報の混入が起きる
- 解釈は、フリーテキストで「選択的に、文脈を持たせて」伝える。全項目に触れる必要はなく、重要な傾向を因果やストーリーに落とす
この二つが混ざると、出力は読みにくくなり、情報の欠落にも気づきにくくなる。
HTMLが活きるのは、事実を上のソート可能なテーブルに、解釈を下のナラティブに、と空間的に分けられるからだ。
そしてこの原則は、プロンプト設計にもそのまま効く。
「事実は表で出せ、解釈は別セクションで書け」と指示するだけで、出力の質が変わる。
認知負荷を決める3つの層
「インフォグラフィックの1枚絵が欲しい」という要求も、実はフォーマットの問題ではない。
情報設計の問題だ。
情報には、三つの層がある。
- 情報の選別。何を出すか
- 情報の構造化。どう整理するか
- 表現フォーマット。どう見せるか
元記事は、ほぼ三層目の話をしている。
だが、実際のボトルネックは、一層目と二層目にあることが多い。
どれだけリッチなHTMLで出しても、情報量そのものが多ければ、認知負荷は下がらない。
同じ階層に3つまで
実践ルールとして効くのが、「同じ階層に置くのは3つまで」だ。
セクションも、サブセクションも、箇条書きも。
マジカルナンバー（7±2）を、自分用に厳しめに締めた形だ。
項目が3つに収まらないときは、たいてい階層の切り方が甘い。
関連するものを上位にまとめ、細かいものは下位へ落とすか本文に溶かす。
「収まらない」は、情報が多すぎるサインというより、分け方を見直せというサインだ。
ツールとプロトコルの現在地
CLIの原理的な限界
出力と情報設計の話を、道具の側から見直す。
CLI（ターミナル）は、テキストストリームだ。
リッチな可視化やインタラクションとは、原理的に相性が悪い。
- CLIでもできること：事実の構造化、定型フォーマットでの出力
- CLIでは難しいこと：インタラクティブな操作、比較の横並び、視覚的なフィードバックループ
実装中のタイトなループなら、CLIで十分だ。
だが、設計判断や方針レビューのように「立ち止まって考える」フェーズでは、WebUIやHTMLへ切り替えたほうがいい。
テキストが長くなると、ターミナルのスクロールは辛い。
構造化と階層化による抽象化がないと、認知負荷が高すぎる。
A2UIに欠けている2つのピース
では、この使い分けをプロトコルが支えてくれるのか。
A2UI（Agent to UI）は、Googleが主導するエージェント向けUI生成のオープンプロトコルだ。
エージェントが宣言的なJSONでUIコンポーネントを記述し、クライアントがネイティブにレンダリングする。
できていることは、こうだ。
- エージェントがリッチなUIを生成して提示する（認知負荷の低減）
- Web、モバイル、デスクトップへのクロスプラットフォーム対応
- インクリメンタルなUI更新
一方で、まだ埋まっていないピースが二つある。
- フィードバックループの統合。A2UIはUI生成の規格であり、UI上の操作がエージェントの次の行動にどう効くかは規格の外だ。AG-UIなど別プロトコルに委ねている
- ツール実行結果の直接描画。LLMの生成内容をA2UI形式で流し込むことはできるが、ツールの生データをそのままUIにするパスが整っていない
フィードバックのUI化という未開拓領域
この二つの欠落が、次に来る場所を指している。
これからは、コーディングエージェントへのフィードバックをUI化する方向が来るはずだ。
エージェントは、フロントエンドやUIを無限に生成でき、その精度も上がっている。
「ユーザーごとにパーソナライズしたUI生成」は前から予想されてきた。
だが、より効くのは、エージェントとのフィードバックにUIが持ち込まれる流れのほうだ。
「操作して、エクスポートして、エージェントに戻す」というカスタムエディタのパターンを、プロトコルの層で標準化する段階が、まだ来ていない。
個別のシステムとしてなら、今でも作れる。
ツール実行結果をハーネス的なUIで定型化し、そこから操作して追加指示を送る。
それが標準プロトコルとして整えば、エージェントのエコシステム全体の質が一段上がる。
冒頭の、Markdownだと流し読み、HTMLだと読まれる、という小さな差に戻る。
あれは見た目の問題ではなく、出力側だけの問題でもなかった。
出力をどう受け取り、フィードバックをどう返すか。
その双方向のパスを含めて設計したとき、初めてエージェントとの協働は滑らかになる。
いま標準化を待っているのは、たぶんその「戻り道」のほうだ。
参考情報
- The Unreasonable Effectiveness of HTML — 元記事（20の自己完結型HTMLデモ集）
- A2UI（Agent to UI） — Googleが主導するエージェント向けUI生成プロトコル（v0.9）
- AG-UI — CopilotKitによるAgent-User Interactionプロトコル