Claude Codeに『HTMLで返して』と頼むだけで世界が変わる — AnthropicエンジニアThariqが推す新しい出力フォーマット論
目次
- 1 user@sinyblog:~/article ❯ 01_tldr.md結論：「HTMLで返して」と一言足すだけで成果物の質が変わる
- 2 user@sinyblog:~/article ❯ 02_about_thariq.md記事の元ネタ — Anthropic エンジニア Thariq の発信
- 3 user@sinyblog:~/article ❯ 03_why_markdown_first.mdなぜ Markdown は AI 標準になったのか
- 4 user@sinyblog:~/article ❯ 04_role_shift.md潮目の変化：「もう自分でファイルを編集しない」
- 5 user@sinyblog:~/article ❯ 05_expressiveness.md表現力の差を可視化 — 8 種類 vs 2 種類の情報タイプ
- 6 user@sinyblog:~/article ❯ 06_ascii_limits.mdASCII 図解の限界 — Claude が unicode で色を「再現」する話
- 7 user@sinyblog:~/article ❯ 07_100_lines_wall.md100 行で止まる：仕様書を本当に読んでもらうために
- 8 user@sinyblog:~/article ❯ 08_sharing.md共有のしやすさ：URL ひとつでチーム全員が読める
- 9 user@sinyblog:~/article ❯ 09_two_way.md双方向性：触って試せる「生きた仕様書」
- 10 user@sinyblog:~/article ❯ 10_claude_code_context.mdなぜ Claude Code なのか — ファイル横断のコンテキスト取り込み
- 11 user@sinyblog:~/article ❯ 11_use_cases.mdユースケース別の具体例 — 5 つの典型シーン
- 12 user@sinyblog:~/article ❯ 12_prompts.md今日から使えるプロンプト集（コピペ可）
- 13 user@sinyblog:~/article ❯ 13_faq.mdFAQ — トークン効率・速度・バージョン管理
- 14 user@sinyblog:~/article ❯ 14_summary.mdまとめ：これは「人間がループに戻る」運動
Anthropic Engineering Notes · 2026 · Claude Code Tips
Anthropic のエンジニア Thariq Shihipar（@trq212）が公開した記事「Using Claude Code: The Unreasonable Effectiveness of HTML」[1]が、Claude Code を使う層のあいだで静かに話題になっています。主張はシンプルで、「これからは Claude Code に Markdown ではなく HTML で出力させたほうがいい」というもの。Anthropic 社内の Claude Code チームでも同じ流れが進んでいるとのことで、仕様書・調査メモ・コードレビュー・デザインモック・週次レポートまで、ありとあらゆる「AI と一緒に作る成果物」のフォーマットが Markdown から HTML へ置き換わりつつあります。本記事では、原文の主張を 14 章に再構成し、要点ごとに 図解（SVG ダイアグラム）と そのまま使えるプロンプトを添えて、明日から自分の Claude Code 運用に取り込める形にまとめました。所要時間は約 18 分です。
user@sinyblog:~/article ❯ 01_tldr.md結論：「HTMLで返して」と一言足すだけで成果物の質が変わる
本記事の結論は次のひと言に尽きます。
Claude Code に何か作ってもらうとき、出力フォーマットを Markdown ではなく HTML にしてもらうだけで、「そのファイルを実際に開いて読む確率」も「他人に共有して読まれる確率」も劇的に上がる。仕様書・調査レポート・コードレビュー・デザインモック・社内向けの解説資料——用途を選ばず効く。
Thariq Shihipar (Member of Technical Staff, Anthropic) / [1]
具体的に何が変わるのかを 9 つに圧縮すると、こうなります。
- 情報密度：表・CSS・SVG・コード・JS インタラクション・ワークフロー・空間データ・画像、ほぼ何でも 1 ファイルに同居できる。
- 視覚構造：目次・タブ・カラーリング・アイコンで「読みたくなる」ドキュメントになる。
- レスポンシブ：スマホでも開ける——通勤電車で仕様書をチェックできる。
- 共有がワンクリック：S3 や Cloud Storage に置けばリンク一発。Markdown のように「Slack に貼ったら整形が崩れた」が起こらない。
- 双方向性：スライダー・トグル・カラーピッカーを埋め込めば、デザイン値を「触りながら」調整できる。
- ASCII の卒業：Markdown の中で Claude が頑張って描いていた ASCII art（しばしば崩れる）を SVG に置き換えられる。
- 長さの呪いから解放：100 行を超えた Markdown は誰も読まない。HTML なら 5,000 行でも構造化されていれば読める。
- 編集の主体が AI に移った：そもそも私たち人間はもう Markdown を直接編集していない。「編集しやすい」というメリットが消えた。
- 生成体験が楽しい：色付きで・図入りで・触れる成果物が返ってくると、レビューする側のモチベーションが続く。
「HTML 化は単なるフォーマット変更ではなく、AI と人間の役割分担を更新するムーブメント」というのが Thariq の主張で、本記事も全章その立場で書き進めます。
あなたが今読んでいるこのページ自体、WordPress に埋め込まれた HTML + CSS + SVG で組まれています。Markdown だったら表現できなかった図表・チャート・カードレイアウトが、まさに「HTML だから当たり前にできる」ことを実感しながら読み進めてください。
user@sinyblog:~/article ❯ 02_about_thariq.md記事の元ネタ — Anthropic エンジニア Thariq の発信
本記事の出発点は、Anthropic の Member of Technical Staff（エンジニア職）Thariq Shihipar 氏が個人ブログに公開した記事「Using Claude Code: The Unreasonable Effectiveness of HTML」[1]です。Y Combinator 出身で、現在は Claude Code チームに所属。同じ Anthropic アカウント（@anthropicai）から記事リンクが拡散されたこともあり、Anthropic 社内のエンジニアが共通して感じている肌感を代弁する形になっています。
| 項目 | 内容 |
|---|---|
| 記事タイトル | Using Claude Code: The Unreasonable Effectiveness of HTML |
| 著者 | Thariq Shihipar（X: @trq212 / 旧 Twitter） |
| 所属 | Anthropic（Claude Code チーム）／前職は Y Combinator |
| 関連サイト | thariqs.github.io/html-effectiveness（実例ギャラリー） |
| 主張 | Claude Code への出力指示は Markdown より HTML が良い |
| 論拠 | 情報密度／視覚構造／共有性／双方向性／コンテキスト取り込み／生成体験 |
Thariq 氏は記事の中で「これを読んだ人が /html スキル化したくなる気持ちはわかるが、それは早すぎる」とも釘を刺しています。なぜなら HTML 化の価値は「フォーマットを切り替えること」ではなく、「その HTML で何をやらせたいかを毎回考えること」にあるからです。仕様書なら可読性、レビューなら差分注釈、デザインなら触れるノブ——用途ごとに最適な HTML 構成は変わります。スキルとして固めてしまうと、その用途依存性が消えてしまうわけです。
Thariq 氏の発信が説得力を持つのは、彼が Anthropic 社内の Claude Code 開発に直接関わるエンジニアであり、しかも個人ブログでは Anthropic 公式広報トーンを使わず、自分の試行錯誤を一次情報として書いているためです。本記事はこの一次資料を基礎に、私自身が日常の Claude Code 運用で「確かにそうだな」と感じた点を補足する形で構成します。
user@sinyblog:~/article ❯ 03_why_markdown_first.mdなぜ Markdown は AI 標準になったのか
HTML が良いという話に入る前に、なぜそもそも Markdown が AI 出力のデファクトになっているのかを整理しておきます。Markdown が選ばれてきた理由は、おおむね次の 4 点です。
- シンプル：
#**-など 10 種類弱の記号を覚えれば書ける。AI 側にとっても出力しやすい。 - 可搬性：プレーンテキストなので、どんな OS・どんなエディタでもそのまま開ける。Git diff にも乗る。
- 適度なリッチテキスト：太字・見出し・リスト・コード・表まで対応している。技術メモには十分。
- 人間が編集しやすい：書き心地が軽く、構造を保ったまま手で直せる。
4 番目の「人間が編集しやすい」が、特に決定的でした。エンジニアのワークフローでは、AI が下書きを書いて人間が手を入れる、というキャッチボールが常識だった時期が長かったからです。Markdown ならそのキャッチボールに摩擦がない——「行の先頭を - に変える」「** で太字にする」程度の編集なら、Vim や VS Code でストレスなくできる。これが HTML だと、編集中に閉じタグを忘れたり属性をミスタイプしたりして、構造が壊れやすい。
Cursor や GitHub Copilot のように「人間がコードを書き、AI がちょい足し提案する」時代は、副産物のドキュメントも当然 Markdown で良かった。AI 出力 = 補助、編集 = 人間、という分担に最適化されたフォーマットだったわけです。
しかし——この前提自体が、Claude Code（およびそれと類似する自律型エージェント）の登場で崩れ始めた、というのが Thariq の指摘です。次章で、その「崩れ方」を見ていきます。
user@sinyblog:~/article ❯ 04_role_shift.md潮目の変化：「もう自分でファイルを編集しない」
Claude Code を本気で使い込んだ人は、ある段階で気づきます——「自分はもう、AI が出した Markdown を手で直していない」。気になった部分は 「ここをもっと簡潔に」「この章を削って」と Claude にプロンプトで伝え、Claude にもう一度書かせる。直接編集しなくなると、Markdown の最大のメリット（編集しやすさ）が一気に消えます。
Thariq 氏はこの変化を、次のように要約しています。
I'm also increasingly not editing these files myself, but using them as specs, reference files, brainstorming outputs, etc. When I do make edits, I'm usually prompting Claude to edit them, which removes one of markdown's largest benefits.
Thariq Shihipar / [1]
つまり Markdown の役割は、「人間が読み書きする中間成果物」から、「Claude が読み書きする内部表現」または 「人間が一度だけ読むインプット資料」に変わってきている。だとすれば、フォーマット選定の評価軸も変わるはずです。「人間が編集しやすいか」より「人間が一度開いた瞬間に伝わるか」のほうが圧倒的に重要になる。
旧軸：書きやすさ・編集しやすさ・diff の見やすさ・ツール互換性
新軸：一目での読みやすさ・情報密度・共有のしやすさ・触れるか（インタラクション）
新軸で評価したとき、Markdown はほぼすべての項目で HTML に負けます。HTML はリッチに描けて、レイアウトを工夫でき、URL ひとつで共有でき、JavaScript で触れる。「人間が直接編集しない」前提なら、HTML を選ばない理由がなくなる——これが Thariq 氏の中核的な主張です。
正直に書くと、生成 AI が話題になり始めた頃から、私自身も「LLM に HTML を吐かせて、ローカルでブラウザで開けばすぐ動く」というワークフローを多用してきました。仕様書も、社内資料の試作も、ちょっとしたデータ可視化も——プロンプト 1 行で index.html を作らせて、ダブルクリックで開けばその場で確認できる手軽さは、Markdown には出せない強みでした。当時はまだ LLM が出す HTML は荒削りで、自分で CSS を整えながら使っていましたが、ここ 1〜2 年で生成される HTML の品質が急激に上がり、CSS / SVG / 軽い JS まで含めて十分に「魅せる」レベルに到達。今回の Thariq 氏の発信を読んだとき、「やっと時代が追い付いてきたか（笑）」というのが正直な感想でした。本記事も、そういう「先に体験して納得していた」立場から書いています。
user@sinyblog:~/article ❯ 05_expressiveness.md表現力の差を可視化 — 8 種類 vs 2 種類の情報タイプ
Markdown と HTML、ぶっちゃけどれくらい表現力が違うのか。Thariq 氏は記事の中で、HTML が表現できる情報タイプを 8 種類列挙しています。それを Markdown と比較してみたのが下の図です。
「Claude が読める情報のうち、HTML で表現できないものはほとんどない」と Thariq 氏は断言します。これが意味するのは、AI が伝えたいことの幅と、フォーマットが許す表現の幅が、HTML だとほぼ一致するということ。Markdown だと、Claude は無理やり ASCII art や記号で頑張るしかなく、しばしば「色を unicode で代用する」のような痛々しい妥協が発生します。次章でその実例を見ます。
user@sinyblog:~/article ❯ 06_ascii_limits.mdASCII 図解の限界 — Claude が unicode で色を「再現」する話
Markdown でフロー図やヒートマップを描けと言われた Claude は、何をするか。ASCII art と unicode 文字の濃淡で、それっぽく見せようと頑張ります。Thariq 氏のブログには、Claude Code が Markdown 内で「赤 → 黄 → 緑」のヒートマップを █▓▒░ の濃淡で描こうとしているスクリーンショットが載っており、思わず笑ってしまいます。
## レイテンシ ヒートマップ（Markdown では色が出せないので濃淡で代用）
時間帯 | API 応答時間
--------|----------------------------------------
00:00 | ░░░░░░░░░░ <- 軽い
04:00 | ░░░░░░░░░░░░
08:00 | ▒▒▒▒▒▒▒▒▒▒▒▒▒▒
12:00 | ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ <- ピーク
16:00 | ▓▓▓▓▓▓▓▓▓▓▓▓▓▓
20:00 | ▒▒▒▒▒▒▒▒▒▒▒▒
24:00 | ░░░░░░░░░░ <- 軽いこれを HTML でやると、そのままの色で・正確な数値で・必要なら hover で詳細表示もできます。下の図は、上と同じ意図のデータを SVG で表現したもの——色階調がそのまま意味を持ち、数字も併記できます。
Markdown 内の ASCII art は、フォントが等幅でない環境（Slack のリッチエディタ、Notion の一部ブロック、メールクライアント、SNS 投稿）ではほぼ確実に崩れます。一方、HTML/SVG はフォントに依存しません。「読み手の環境に左右されないドキュメント」を作るうえでも、HTML 出力には大きなアドバンテージがあります。
user@sinyblog:~/article ❯ 07_100_lines_wall.md100 行で止まる：仕様書を本当に読んでもらうために
Thariq 氏が記事の中でとくに強く語っているのが、「100 行を超える Markdown は誰も読まない」という肌感です。本人いわく、自分自身が 100 行を超える MD ファイルを真面目に読み切ることはほとんどない、まして組織の他のメンバーに読ませるのはほぼ無理、と。
In practice, I've found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it.
Thariq Shihipar / [1]
これに対して HTML だと、目次・タブ・折りたたみ・カード分割・サイドバーなど、「読み手の認知負荷を分散する仕掛け」を当たり前に組み込めます。スマホでも快適に読めるようにレスポンシブ対応もできる。読み手は「全体を一気に読む」のではなく、「興味のあるところから飛ぶ」ことができる。仕様書を実際に読み切ってもらえる確率が、桁違いに上がります。
user@sinyblog:~/article ❯ 08_sharing.md共有のしやすさ：URL ひとつでチーム全員が読める
意外と見落とされがちですが、Markdown ファイルは 「他人と気軽に共有しにくい」フォーマットです。理由は単純で、ブラウザがネイティブで Markdown を綺麗にレンダリングしてくれないから。Slack に貼ると整形が崩れる、メールに添付するとレンダリングは受け手のメーラーに依存する、Notion にコピペしたら見出しレベルがズレる——日常的に経験があるはずです。
HTML はこの問題が原理的に存在しません。ブラウザは HTML を表示するために生まれたソフトウェアであり、HTML ファイルを S3・Cloud Storage・GitHub Pages・Vercel のどれに置いても、URL ひとつで誰でも開けます。スマホでもタブレットでもデスクトップでも、同じ見た目で読める。さらに、開いた相手がブックマークして後から見返すこともできる。
| 共有手段 | Markdown | HTML |
|---|---|---|
| Slack に直貼り | 整形が一部だけ動く（** や -） |
URL を貼ればプレビュー付き |
| メール添付 | 受信側のレンダラ依存 | 添付してもブラウザで開ける |
| スマホで閲覧 | 専用ビューアが必要 | 標準ブラウザで完結 |
| 後でブックマーク | ファイル管理が必要 | URL を保存するだけ |
| クライアントへの説明 | 整形してから送る必要あり | そのまま送れる |
| 非エンジニア向け | そもそも開けない場合あり | 誰でも開ける |
Thariq 氏は 「共有可能性こそ、HTML を選ぶ実務的な最大理由のひとつ」と断言しています。仕様書や PR ライトアップを「実際に読んでもらえる確率」は、フォーマット選定だけで何倍も変わる。これは情報を作る側の責任の取り方の問題です。
user@sinyblog:~/article ❯ 09_two_way.md双方向性：触って試せる「生きた仕様書」
HTML が Markdown と決定的に違うもう一つの軸が、「双方向性」です。HTML は単なる表示フォーマットではなく、JavaScript で動かせるアプリ実行環境でもあります。Claude Code に「この HTML にスライダーをつけて、押すとパラメータが変わるようにして」と頼めば、それだけで 「触って試せるドキュメント」が生まれる。
Thariq 氏がブログで挙げている例の一つは、チェックアウトボタンのアニメーション設計。「クリックされると再生アイコンが出て、紫色に切り替わる」という挙動を、デザイン仕様書として Markdown で書くのはほぼ不可能。一方 HTML なら、イージング曲線・色相・継続時間のスライダーを画面に並べ、リアルタイムで挙動を確認できる仕様書を 1 ファイルで作れます。
さらに重要なのが、Thariq 氏が強調する「エクスポートボタンを必ず添える」というパターン。スライダーで好きな値に調整したあと、「Copy as JSON」や 「Copy as Prompt」ボタンをクリックすると、現在の設定値がクリップボードに入る。そのままチャットに戻して Claude にペーストすれば、Claude は人間が試行錯誤した結果をそのままコードに反映できる。「触って探索 → 結果を AI に戻す」というフィードバック ループが 1 つの HTML ファイルで完結するわけです。
同じ仕組みは、次のような場面でも使えます。
- 30 件のチケットを優先度別に並び替え：ドラッグ&ドロップで Now / Next / Later / Cut のカラムに振り分け、最後に「Copy as Markdown」で結果を出力。
- フィーチャーフラグの編集 UI：依存関係グラフ付きで、矛盾する設定をリアルタイムで警告。「Copy diff」で変更分だけ JSON に出力。
- システムプロンプトのチューニング：左にプロンプト、右に 3 件のサンプル入力で即時プレビュー。トークンカウンタも併設。
- 正規表現や cron スケジュールの組み立て：テキストボックスでは表現しづらい値を、ビジュアルに組み立てて最後にコピー。
Markdown でこれらをやろうとしても、せいぜい「設定値を表で並べる」程度にしかならない。HTML だからこそ、「読む」だけだったドキュメントが「使える道具」になる。
user@sinyblog:~/article ❯ 10_claude_code_context.mdなぜ Claude Code なのか — ファイル横断のコンテキスト取り込み
「リッチな HTML を作りたいだけなら Claude.ai や Claude Artifacts、Claude Design でもよくない？」という疑問はもっともです。Thariq 氏は記事の中で、あえて Claude Code で HTML を書かせる理由として「コンテキストの広さ」を挙げています。
Thariq 氏は記事を書くにあたり、自分のローカルフォルダ内の HTML ファイル全部を Claude Code に読ませ、種類ごとに分類して、各分類を表す代表 HTML をギャラリーページとして出力させた、と書いています。「自分が過去に作った HTML たちを Claude Code が俯瞰して、新しい HTML を生む」。これは Claude.ai 単体では難しい——ファイル横断のコンテキストが必要だからです。
同様に、Claude Code は Slack や Linear などの MCP（Model Context Protocol）サーバーや、Chrome 拡張版 Claude、git log などからもコンテキストを引っ張ってこられる。「あなたの過去のすべての作業」を踏まえた上で、HTML 出力にまとめてくれる——これは Claude.ai のチャット画面ではどうしても再現できない領域です。
user@sinyblog:~/article ❯ 11_use_cases.mdユースケース別の具体例 — 5 つの典型シーン
Thariq 氏が記事内および ギャラリーページ で挙げているユースケースを、私の現場感覚に合わせて 5 つに整理しました。それぞれのシーンで、Claude Code への依頼例も併記します。
11-1. 仕様書・計画・探索（Specs, Planning, Exploration）
新機能の検討段階で、デザインや実装方針を 「6 案並べて比較したい」といったケース。Markdown だと案ごとに見出しを切るしかないが、HTML なら 1 ファイルにグリッド表示して横並びで眺められる。
「オンボーディング画面の方向性を 6 案出して。レイアウト・トーン・情報密度をそれぞれ変えて、HTML 1 ファイルにグリッドで並べて。各案にトレードオフを書いて。」
11-2. コードレビューと理解（Code Review & Understanding）
PR レビューでありがちな「その差分が何をやっているのかわからない」を、HTML で解消する。Claude Code に「この PR を HTML アーティファクトで説明して」と頼むと、差分を色分けし、関数フローを SVG で描き、注釈を margin に並べてくれる。GitHub の標準 diff ビューより遥かに読みやすい。
「この PR のレビューを助けたい。HTML アーティファクトで、差分を margin 注釈付きで描いて、severity ごとに色分けして。streaming/backpressure ロジックは特に重点的に説明して。」
11-3. デザインとプロトタイプ（Design & Prototypes）
UI コンポーネントを実際に 「触って調整できる試作品」として渡せる。React / Swift / SwiftUI に展開する前段階の「視覚的合意形成」が劇的に速くなる。
「新しいチェックアウトボタンを試作したい。クリックすると再生アニメが出て紫に切り替わる。HTML 1 ファイルでイージング曲線・色相・継続時間のスライダーを並べて、Copy as JSON ボタンも付けて。」
11-4. レポート・調査・学習（Reports, Research, Learning）
Claude Code のもっとも光るシーン。Slack・コードベース・git log・Web を横断して情報を統合し、1 つの読み物 HTML にまとめる。週次レポートやインシデントレポート、機能解説などの「重い文書」をリッチに出力できる。
「うちのレートリミッタの仕組みがいまいちわかっていない。関連コードを読んで、HTML 1 ページの解説を作って。token-bucket のフロー図・主要 3〜4 個のコード断片への注釈・gotchas セクションを含めて。一度読みで理解できるように。」
11-5. カスタム編集 UI（Custom Editing Interfaces）
本記事の中でも特にインパクトが大きいのが、「使い捨ての専用エディタを Claude に作ってもらう」パターン。テキスト入力では表現しづらい操作（並び替え、色選択、領域指定、設定の依存関係など）を、その用途専用の UI として 1 ファイルに描いてもらう。
「Linear の 30 件のチケットを並び替えたい。HTML 1 ファイルで、各チケットをドラッグ可能なカードにして Now / Next / Later / Cut の 4 列に振り分けられるようにして。あなたのベストゲスで初期並びを作って。最後に Copy as Markdown ボタンで一行コメント付きの結果を出力して。」
user@sinyblog:~/article ❯ 12_prompts.md今日から使えるプロンプト集（コピペ可）
明日から自分の Claude Code 運用に組み込めるよう、定番テンプレートを 5 つ用意しました。そのままコピーして冒頭の {{ }} を置き換えるだけで動きます。
{{ここにやりたいことを 1〜3 文で}}
成果物は単一の HTML ファイルで。
- セクションごとに目次（クリックでアンカー遷移）
- 重要な数値・差分は表 or SVG のチャートで視覚化
- コードがある場合は <pre><code> で構造化し、説明をその下に
- スマホでも見やすいレスポンシブ
- 仕上げに、ブラウザで開いて確認できるよう open コマンドを実行{{機能名 / 改修内容}} の詳細な実装計画を HTML ファイルで作って。
含めるもの：
- 概要と動機（読者が 30 秒で把握できる density）
- 主要な画面のモックアップ（HTML/CSS で書いて。画像は不要）
- データフロー図（SVG。box and arrow）
- レビューが必要なコード断片 3〜5 個（差分形式 or 変更前後）
- 変更が触る既存ファイルの一覧表（影響範囲を色で示す）
- リスク・依存・代替案
完成後、verify セッションで読みやすいよう、目次は固定サイドバー風に。このブランチの差分を読み、PR を説明する HTML アーティファクトを作って。
- 全体の意図を 3 文で
- 主要な差分を inline annotation 付きで色分け
（critical=赤、moderate=橙、cosmetic=灰）
- {{ロジックの中で特に注目してほしい部分}} は重点的に
- 関係するファイルの依存図を SVG で
- 「ここをレビュアーに見てほしい」TOP 3 を最後にまとめる
PR の URL に貼り付けて使う想定。{{機能名 / 概念}} の仕組みを、自分が一度読みで理解できる HTML 解説ページにして。
構成：
- フロー図（SVG。実際のコードに対応した box）
- 主要 3〜4 個のコード断片に注釈
- 落とし穴・例外処理・gotchas のセクション
- 関連 PR / コミット / ドキュメントへの参照リンク
トーンは「先輩エンジニアが新人に 1 対 1 で説明する」感じで。{{操作したいデータ}} を編集する使い捨ての HTML エディタを作って。
要件：
- 単一 HTML ファイル（ライブラリは CDN から最小限）
- 直感的な UI（ドラッグ / トグル / スライダーなど用途に応じて）
- バリデーション（{{矛盾する組み合わせ}} は警告）
- Copy as {{JSON / Markdown / Prompt}} ボタンを必ず付ける
→ 結果を Claude にペーストして次の処理に渡せるように
製品にはしない。「今この一回の作業」のためだけの道具。5 つを何度か使ううちに、自分のチームでよく出る要件（カラーパレット指定、ロゴの埋め込み、社内デザイントークンなど）が見えてきます。それらを盛り込んだ「自社版テンプレート」をリポジトリに置いておくと、Claude Code がそれを参照してくれて、どんどん再現性が上がります。Thariq 氏も「1 つのデザインシステム HTML を Claude に渡せば、それ以降の HTML は全部その様式で揃う」と書いています。
user@sinyblog:~/article ❯ 13_faq.mdFAQ — トークン効率・速度・バージョン管理
Thariq 氏のブログにも FAQ コーナーが用意されており、よく聞かれる懸念点に答えています。日本のエンジニアからもよく出る疑問を補足し、現実的な落としどころを整理します。
Q1. トークン効率は悪くなるのでは？
確かに HTML のほうが Markdown よりトークンを多く消費します（タグ分の文字数があるため）。Thariq 氏の体感では、同じ内容で Markdown の 2〜4 倍程度。ただし、Opus 4.7 の 1M コンテキストウィンドウでは、現実問題としてあまり意識する必要がないレベル、とのこと。むしろ 「読まれない MD を量産する」のと「実際に成果物として機能する HTML を作る」のとを比較すれば、HTML 側の費用対効果のほうが高いという主張です。
Q2. 生成速度は？
HTML のほうが Markdown より 2〜4 倍時間がかかります（タグの分だけ書く文字数が増えるため）。ただし、Thariq 氏は「その時間に見合う価値はある」と断言。私の経験でも、初回の生成が 2 分かかっても、その後 30 分間レビュー・編集に使うことを考えれば、誤差の範囲です。
Q3. バージョン管理（Git diff）は HTML だと辛くないか？
これは Thariq 氏も「HTML の最大の弱点」と認めている項目。HTML の diff はノイズが多く、Markdown より圧倒的に読みにくい。対策は次の 2 つ。
- 「成果物」と「ソース」を分離する：HTML は「最終アーティファクト」と割り切り、その元データは別途 JSON や Markdown で持っておく。
- diff を読む人を Claude にする：そもそも HTML diff を人間が読まない前提で、レビューが必要なら Claude にレビュー HTML を出力させる。
Q4. デザインがダサい・統一感がない、どうすればいい？
Anthropic 公式の frontend design plugin（Claude Design）を使うか、もしくは 1 ファイルだけ「自社のデザインシステム HTML」を Claude Code に参照させるのが定番。後者は、自分のリポジトリの色・フォント・スペーシング・コンポーネントの典型を 1 ファイルにまとめておけば、以後の HTML 出力が全部そのスタイルに揃います。
Q5. Markdown はもう完全に捨てるのか？
Thariq 氏自身は「ほぼすべてを HTML に切り替えた」とのこと。ただ、README・CHANGELOG・コミットメッセージ・コード内コメントのような「コードと同居する文書」は、引き続き Markdown が合理的です。「人間と AI が会話するための中間成果物」＝ HTML、「コードベースの一部として永続化する文書」＝ Markdown、という棲み分けが落としどころになります。
Q6. WordPress やブログ記事もこれと同じ発想で書ける？
はい、書けます。実はこの記事自体、その発想で書かれています。WordPress のブロックエディタやリッチテキストでなく、HTML を直接 Claude に書かせる → そのまま貼り付けるワークフロー。SVG・カード・グラデーション・色付きカラム——Markdown では諦めるしかなかった表現が、コピペ 1 回で記事に乗ります。Sinyblog の他の記事（4379、4367 等）もすべて同じ思想で構築されています。
user@sinyblog:~/article ❯ 14_summary.mdまとめ：これは「人間がループに戻る」運動
Thariq 氏が記事の最後にもっとも強く書いているのが、「HTML 化は人間がループに戻るための運動」という哲学です。Claude Code が強くなるほど、人間は「中身のレビューを諦めて、AI に任せきりにする」誘惑に駆られる。そうなると、AI が間違えても誰も気づかない、悪い未来が待っている。
I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I am happy to say instead that I feel more in the loop than ever before when using HTML. I hope you do too.
Thariq Shihipar / [1]
HTML 化が効くのは、表現力が高いとか共有しやすいとか、そういう機能面の話だけではない。「読む気になる成果物」が生まれることで、人間が AI の判断を再チェックする習慣が戻ってくる。これが Thariq 氏が「Unreasonable Effectiveness（理不尽なほどの有効性）」と呼ぶゆえんです。
実務へ落とし込むときの 3 つの要点を、最後にまとめます。
- 明日から「HTML で返して」を口癖にする。新規スキルや特殊な指示は要らない。「単一 HTML ファイルで、目次付きで、必要なら SVG 図で」と一言添えるだけで十分。
- 1 つだけ自社デザインシステム HTML を用意する。色・フォント・カードスタイル・ロゴを 1 ファイルにまとめ、Claude Code に「以後はこれを参照」と渡す。これで全ての HTML 出力にブランドが揃う。
- 「双方向性」を仕様書の標準装備にする。スライダー・トグル・並び替え・Copy as {JSON/Prompt} ボタン——可能ならいつも触れるアーティファクトに。読者の認知が「読む」から「使う」に変わると、ドキュメントのライフタイムが伸びる。
Markdown は素晴らしいフォーマットでした。そして今でも README やコミットメッセージのような場面では現役です。しかし、「AI と一緒に成果物を作る場面」については、もう次の段階に進む時期。HTML というブラウザ標準フォーマットが、10 年来の蓄積（CSS、SVG、JS、Web 標準）すべてを巻き込んで、AI 時代の主役に押し上げられている——そう捉えると、今日からのワークフロー変更にも納得感が増すはずです。
本記事を読んだあと、ぜひ次の Claude Code セッションで「HTML 1 ファイルで仕上げて」を試してみてください。1 回試すと、Markdown 出力との情報密度の差が体感でわかります。気に入った形式が見えたら、自分用のテンプレートとして保存しておきましょう。
