AI活用データ比較：Markdown・YAML・HTML
fukayayuji
はじめに
AITCセンター長の深谷です。
これまで、以下のように、AI Ready Dataの観点から、MarkdownとYAMLを紹介してきました。
Markdownは、文章の構造を人にもAIにも分かりやすく表現する形式です。業務知識を蓄積し、RAG（Retrieval-Augmented Generation）などの検索や要約、再利用につなげる「AI Ready Data」の土台として、とても有効です。
一方、YAMLは設定値やルール、条件、処理の関係を構造化して記述する形式です。人が読めるだけでなく、AIやプログラムがそのまま扱いやすい点に強みがあります。
では、HTMLはどうでしょうか？
HTMLと聞くと、「Webページを作るための言語」という印象を持つ方が多いと思います。しかし、生成AI時代のHTMLは、少し違う位置付けで捉えると、その価値が見えてきます。
本記事の結論を先にお伝えします。
「AIに渡す文章や知識を整えるならMarkdown、設定やルールを構造化するならYAML、AIから受け取った結果を「見て理解し、比較し、操作する成果物」にするならHTMLが有効」
今回はHTMLの文法を順番に学ぶのではなく、AIエージェントが生成する成果物としてHTMLをどう使うか、という観点で説明します。
Anthropicのエンジニアが、MarkdownよりHTMLを使い始めた理由
2026年5月、AnthropicのClaude Codeチームに所属するThariq Shihipar氏が、以下のような記事を公開しました。
記事では、AIエージェントと人間の間で使われるファイル形式としてMarkdownが広く普及したことを評価しつつ、AIエージェントがより複雑で長い仕事を担うようになると、Markdownだけでは表現しにくい場面が増えると説明されています。この発信はAnthropicの製品方針ではなく、Claude Codeチームに所属するエンジニアの実践と個人的な見解として公開されています。しかし、AIエージェント時代の成果物を考えるうえで、非常に示唆的な記事だと思います。
人が、AIの生成物を直接編集しなくなってきた
Markdownの大きな利点は、人がテキストエディターで簡単に読み書きできることです。
しかし、AIエージェントがファイルを作り、修正もAIに指示する働き方では、人がソースを直接編集する機会は減ります。人が行うのは、タグや記号の修正ではなく、「この内容をもう少し詳しく説明して」「この条件を変えて再比較して」とAIに依頼することです。
そうなると、手で編集しやすいこと以上に、生成された内容を人が短時間で理解し、判断できることが重要になります。
AIが作る計画書や調査結果が、長く複雑になった
AIエージェントは、社内文書、Web情報、コード、MCP経由の業務データなどを横断し、以前よりはるかに大きな成果物を作れるようになっています。
ただし、AIが長時間働けるようになっても、人間が長いMarkdownを上から順番に読む時間まで増えるわけではありません。AIの生産量が増えるほど、今度は人間側の確認作業がボトルネックになります。
HTMLなら、重要な結論を先頭に置き、詳細をタブや折りたたみに格納し、関係を図で示し、リスクを色分けできます。同じ情報量でも、「読む順番」を画面側で設計できるのです。
AIの判断に、人が関与し続ける必要がある
AIに仕事を任せることと、AIの判断を見なくなることは同じではありません。HTMLは、AIが考えた複数案、前提、根拠、リスクを人が把握し、必要な部分を操作して、次の指示へつなげる画面になります。
AI時代のHTMLは、「人が書くWebページ」から「AIが作る業務成果物」へ
従来、HTMLで見やすい画面を作るには、HTML、CSS、JavaScriptなどの知識が必要でした。そのため、業務担当者が一度だけ使う比較画面や確認画面を作りたくても、労力に見合わず、ExcelやPowerPointで代用することが多かったと思います。
生成AIは、この前提を変えました。
人間がHTMLのタグを一つずつ書かなくても、「誰が、何を判断するための画面か」を伝えれば、AIがHTML、CSS、SVG、必要に応じてJavaScriptまで生成できます。
HTMLは、一つのファイルの中に次の要素を組み合わせられます。
- 見出し、文章、表などの文書構造
- 色、余白、カード、グリッドなどの視覚表現
- フロー図、構成図、タイムラインなどのSVG図
- タブ、検索、絞り込み、折りたたみなどのナビゲーション
- スライダー、チェックボックス、ドラッグ＆ドロップなどの操作
- JSON、YAML、Markdown、プロンプトなどへのエクスポート
つまり、HTMLは単なる文書形式ではなく、文書、図、ダッシュボード、プロトタイプ、簡易ツールを一つにまとめられる「ブラウザで動く成果物」になります。
ここで重要なのは、立派なWebシステムを毎回開発することではありません。特定の調査、レビュー、比較、意思決定のためだけに、AIが目的別のHTMLを作るという使い方です。
HTMLが有効な3つの事例 「見て理解する」「並べて比較する」「触って操作する」
以下、HTMLが有効な3つの事例を紹介します。
1．見て理解する
文章だけでは、情報同士の関係を頭の中で組み立てなければなりません。
たとえば、システム障害の報告書に、発生時刻、影響範囲、原因候補、ログ、対応履歴、再発防止策が記載されていたとします。Markdownでも正確に書けますが、情報量が多くなるほど全体像をつかみにくくなります。
HTMLなら、次のような見せ方ができます。
- 画面上部に、影響範囲と現在の状態を要約する
- 障害発生から復旧までをタイムラインで示す
- システム構成と障害の伝播経路を図示する
- 事実、推定、未確認事項を色やラベルで分ける
- 生ログや詳細な調査記録は折りたたむ
- 根拠となる資料やチケットへリンクする
情報を減らすのではなく、概要から詳細へと段階的に読めるようにすることで、人は短時間で全体像を理解できます。
2．並べて比較する
生成AIは複数案の作成を得意とします。しかし、案を一つずつ文章で提示されると、読み手は前の案を覚えながら次の案を読まなければなりません。
HTMLでは、複数案をカードやグリッドで横に並べ、同じ評価軸を同じ位置に表示できます。
たとえば、新設備の導入案A・B・Cについて、次の項目を一画面で比較できます。
- 初期投資
- 生産能力
- 品質への影響
- 立ち上げ期間
- 保守性
- 技術的リスク
- 前提条件
- AIの推奨理由
さらに、差が大きい項目を強調し、リスクの高い項目を色分けし、評価の根拠をその場で展開できれば、「三つの長い提案書を読む」作業が「一つの比較画面で違いを確認する」作業に変わります。
人が違いを認識しやすい形で並べるところまでを、AIの仕事として設計することが重要です。
3．触って操作する
HTMLの価値は、表示だけではありません。JavaScriptを必要最小限に使えば、その場で条件を変更し、結果を確かめることができます。
たとえば、次のような操作が可能です。
- コスト、品質、納期の重みをスライダーで変え、案の順位を再計算する
- 不具合候補を「即対応」「次回対応」「監視」「対象外」へドラッグする
- 表示する部門、製品、期間を絞り込む
- 設計パラメーターを変更し、見た目や挙動を確認する
- プロンプトの変数を編集し、完成形をライブプレビューする
- 確定した条件だけをJSONやYAMLとして出力する
これは、従来の「AIとチャットする」方法とも異なります。
文章で「品質をもう少し重視して」「案Bを除外して」と何度も伝える代わりに、画面を直接操作できます。そして、操作結果を「JSONとしてコピー」「YAMLとして出力」「次のプロンプトとしてコピー」できれば、その結果をAIエージェントの次の処理へ戻せます。
HTMLは、AIの回答を表示する終点ではなく、人の判断を取り込み、AIの次の行動へつなぐ接点にもなりえます。
HTMLは、AIエージェント時代のHuman-in-the-loop画面になる
AIエージェントが長時間・複数工程の仕事を担うようになると、人間の役割は、すべての作業を自分で行うことから、目標、制約、判断基準を与え、途中結果を確認し、重要な意思決定を行うことへ移ります。
そのとき、チャットに長文の報告を返すだけでは、人間が確認しきれません。
HTMLを使うと、AIエージェントと人間の協働を、次のようなループとして設計できます。
1. AIエージェントが、文書、データ、コード、業務システムから情報を収集する
2. AIエージェントが、結論、選択肢、根拠、リスクをHTMLに整理する
3. 人がHTMLを見て、比較し、必要な項目を操作する
4. 人の選択をJSON、YAML、Markdown、プロンプトなどの機械可読形式で出力する
5. AIエージェントが、その結果を受けて次の処理を進める
この構成なら、「AIに任せる範囲」と「人が判断する地点」を明確にできます。
特に、大企業の業務では、AIが技術的に実行できることと、AIだけで実行してよいことは同じではありません。承認、優先順位付け、例外判断、リスク受容など、人が責任を持つべき地点があります。
その地点に、業務内容に合わせてAIが生成したHTMLを置く。これは、AIエージェントの業務利用を考えるうえで有効な設計です。
こんな業務にもHTML成果物で
HTML成果物は、次のような業務で活用できます。
| 業務 | HTML成果物の例 | HTMLが効く理由 |
|---|---|---|
| 経営・事業報告 | KPI、重要トピック、リスク、打ち手をまとめた意思決定レポート | 概要から根拠となる詳細へ段階的に確認できる |
| 調査・市場分析 | 複数企業・技術・製品の比較ページ | 同じ評価軸で横並びにし、共通点や差異を把握できる |
| 製造・品質 | 不具合の傾向、工程との関係、原因候補、対策案をまとめた分析レポート | 写真、表、時系列、因果関係を一つの画面で確認できる |
| 設計レビュー | 複数案、要求、制約、影響範囲、リスクの比較画面 | 案ごとの差とトレードオフを把握しやすい |
| システム開発 | コード差分、構成図、処理フロー、指摘事項をまとめたレビュー画面 | コード、説明、図、AIの指摘根拠を一体的に確認できる |
| インシデント対応 | タイムライン、影響範囲、原因候補、対応状況を示すレポート | 現在地、確認済みの事実、推定、未解決事項を区別できる |
| 課題分析・優先順位判断 | 複数の課題を影響度、緊急度、対応コストなどで整理したレビュー画面 | AIによる分類や評価の根拠を確認しながら、対応の優先順位を判断できる |
| データ品質確認 | 欠損、重複、表記揺れ、異常値、修正候補をまとめた品質確認レポート | 問題箇所とAIの修正候補を一覧し、採用・却下などの判断結果を次工程へ渡せる |
ここで想定しているHTMLは、業務システムに代わってデータを継続的に編集・管理する画面ではありません。生成AIが、その時点の情報を基に都度生成する「閲覧・比較・判断のための成果物」です。
HTML上の操作も、表示条件の変更、評価軸の調整、候補の選択、採用・却下の判断などに限定します。元データを更新する必要がある場合は、判断結果をYAMLやJSONとして出力し、業務システムやAIエージェントの次の処理へ引き渡します。
実務で使えるプロンプト例
まずは、特別な仕組みを作らず、生成AIに「一つのHTMLファイルとして作成してください」と依頼するところから始められます。
たとえば、新設備導入案を比較する場合は、次のように依頼できます。
以下に提示する"新設備導入案"を比較する自己完結型のHTMLファイルを作成してください。対象読者：工場長、製造部門、品質保証部門目的：次回の投資審議で、検証を継続する案を1つ選ぶ以下を含めてください。- 最初の画面に、各案の結論と最大の違いを表示する- 初期投資、生産能力、品質、立ち上げ期間、保守性、リスクを横並びで比較する- 確認済みの事実、AIによる推定、未確認事項を明確に分ける- 各判断の根拠資料と該当ページを表示する- コスト、品質、納期の重みをスライダーで変更できるようにする- 重みを変えた場合は、総合順位と理由を再表示する- 最後に、選択した案、評価値、コメントをJSONとしてコピーできるようにする外部のフォント、画像、APIは使用せず、外部通信を行わないでください。JavaScriptは上記の操作に必要な最小限にしてください。資料に存在しない値は作らず、「情報なし」と表示してください。## 新設備導入案＜新設備導入案をそれぞれ記載＞
誰が、何を判断するのか。何を並べ、何を操作し、最後にどの形式で結果を取り出すのか。そのように指定すると、HTMLは装飾されたレポートではなく、業務の判断画面になります。
Markdown、YAML、HTMLを比較
以前私が書いたMarkdownの記事と、この記事をここまで読んでいただくと、「これまでMarkdownを推奨していたのに、今度はHTMLなのか？」と思われるかもしれません。
しかし、MarkdownとHTMLは、どちらか一方を選ぶ関係ではありません。
以下、Markdown、YAML、HTMLを比較します。
| 観点 | Markdown | YAML | HTML |
|---|---|---|---|
| 主な役割 | 文章・知識を記述し蓄積する | 設定・ルール・構造化データを表す | 人が確認・比較・操作する成果物を表す |
| 主な利用者 | 人とAI | 人、AI、プログラム | 主に人。生成と更新はAIも担当 |
| AIへの入力 | とても向く | 構造が合えば向く | タグや装飾が増えるため、入力の正本には用途を選ぶ |
| RAGのデータソース | とても向く | 項目が明確なら向く | 本文抽出や前処理をした方が扱いやすい |
| 人による直接編集 | しやすい | 慣れが必要 | ソースの直接編集はしにくい |
| 視覚的な理解 | 基本的な表現 | ほぼ対象外 | とても向く |
| 複数案の比較 | 表までは可能 | 対象外 | レイアウト、色、図を使って比較できる |
| 操作・シミュレーション | 基本的に不可 | 不可 | JavaScriptと組み合わせて可能 |
| Gitでの差分確認 | しやすい | しやすい | 装飾や生成コードが多いと確認しにくい |
| 得意な位置 | 入力・知識・正本 | 設定・制約・交換 | 出力・レビュー・意思決定 |
実務では、次のように組み合わせると分かりやすいと思います。
- 業務知識や調査結果の正本はMarkdownで管理する
- 評価基準やしきい値、実行条件はYAMLで管理する
- AIが両方を読み、レビュー用のHTMLを生成する
- 人がHTML上で確認・比較・選択する
- 確定結果をJSON、YAML、Markdownへ戻して保存する
MarkdownとYAMLはAIが仕事をするためのデータ、HTMLはAIの仕事を人が理解し、判断するための画面と整理すると、役割の違いが明確になります。
HTMLを業務で使う際の注意点
HTMLを「正本」にしない
AIが生成したHTMLには、内容と表示用コードが混在します。長期保存、差分確認、RAGへの再利用を考えると、正本はMarkdown、YAML、JSON、データベースなどで持ち、HTMLはそこから生成する方が管理しやすくなります。
意思決定の結果も、HTMLで残すのは推奨しません。選択結果を構造化データとして出力し、正式な記録や業務システムへ戻すところまで設計します。
見栄えと事実性を分ける
色や図が付くと、内容が正しいように見えやすくなります。しかし、HTMLの表現力と、AIの回答の正確さは別問題です。
出典、更新日時、前提条件、未確認事項、AIによる推定を画面上で明示し、根拠を追跡できるようにします。評価点や推奨順位についても、計算方法や判断基準を確認できるようにすることが重要です。
生成AIコストと保守性を考える
Markdownに比べて、HTMLはタグ、CSS、JavaScriptの分だけ生成AIのトークン量が増えます。トークン量が増えるということは、コストが増加することに繋がります。
すべての回答をHTMLにする必要はありません。短い回答、ナレッジ、手順、AIへの指示はMarkdownの方が合理的です。視覚化、比較、操作によって人の確認時間を大きく減らせる場面に絞ることが重要です。
アクセシビリティと共有方法を確認する
色だけで状態を区別しない、図にも説明を付ける、キーボードでも操作できる、印刷やPDF化でも情報が欠けない、といった配慮が必要です。
また、HTMLファイルをメール添付で配るのか、社内Web環境へ配置するのか、AIの成果物ビューアーで表示するのかによって、セキュリティ、権限、更新方法が変わります。最初に利用環境を決めておきましょう。
まずは、「読むだけのHTMLレポート」から始める
いろいろ書きましたが、HTML活用を始めるために、難しいことも、大きな仕組みを用意する必要はありません。
まずは、現在MarkdownやPowerPointで作っている報告書、調査結果、比較表などのうち、一つを選びます。そして、同じ情報を、次の条件でAIにHTML化させてみてください。
1. 一つのHTMLファイルで完結させる
2. 結論、根拠、詳細の順で読めるようにする
3. 複数案や複数期間は、同じ評価軸で並べる
4. 出典、前提、未確認事項を明示する
5. 最初は外部通信なし、JavaScriptなしの読み取り専用にする
Markdown版とHTML版を実際に利用者へ見せ、「理解にかかった時間」「比較のしやすさ」「確認漏れ」を比べます。
効果が確認できたら、折りたたみ、フィルター、スライダー、選択結果のエクスポートなどを少しずつ追加します。同じ形式を繰り返し使うようになった段階で、テンプレートやAIエージェントのスキルとして標準化していけば良いです。
まとめ
生成AI活用では、これまで「AIに何を、どの形式で読ませるか」が重視されてきました。Markdown、YAMLなどは、まさにそのための重要な考え方です。
しかし、AIエージェントが扱う情報量と仕事の範囲が拡大すると、もう一つの問いが重要になります。
人はAIの結果をどう理解し、どう判断し、どう次の処理へ戻すのか？
- 文章として読み、知識として残すならMarkdown。
- 人にもAIにも読みやすい形で項目や階層、ルールを構造化できるYAML。
- 見て理解し、複数案を比較し、条件を操作して意思決定するならHTML。
HTMLの本質は、装飾の豊富さだけではありません。AIエージェントの複雑な仕事を人が把握し、人の判断を構造化してAIへ戻す、Human-in-the-loopの接点を作れることにあります。
今後、業務ナレッジ、Web情報、MCP経由の業務システムなどを横断するAIエージェントが増えるほど、成果物の設計は重要になります。AIに長文を生成させるだけで終わらせず、利用者が「見て分かる」「違いが分かる」「その場で決められる」ところまでを、AI活用として設計していきましょう。
電通総研AITCでは、AI Ready Dataの整備、RAG、AIエージェント、業務システムとの接続、Human-in-the-loopを含む業務設計まで、企業の生成AI活用を支援しています。自社業務に合うAI成果物やAIエージェントの設計を検討されている方は、ぜひご相談ください。
筆者
AITC センター長
深谷 勇次
