Claude Codeの使い方: HTMLの驚くべき効率性
(twitter.com/trq212)- Claude Codeでは、出力形式としてMarkdownの代わりにHTMLを使うと、可視化、色、ダイアグラム、インタラクションをより豊かに盛り込め、人が読みやすくレビューしやすい成果物を作れる
- HTMLは、表、CSS、SVG、
script、JavaScriptによるインタラクション、画像、キャンバス、絶対配置を活用して、Claudeが読める情報の大半を効率よく表現できる - Claude Codeは、ファイルシステム、MCP、ブラウザ、Git履歴のようなコンテキストを読み取り、HTML成果物としてまとめられ、「HTMLファイルを作って」と頼むだけで始められる
- 主な活用方法は、仕様・計画・探索、コードレビューとコード理解、デザインとプロトタイピング、レポート・リサーチ・学習、カスタムの使い捨て編集インターフェースに分かれる
- HTMLはMarkdownより生成に2〜4倍長くかかり、diffもうるさくてバージョン管理が難しい一方、表現力と共有しやすさ、実際に読まれる可能性の高さが大きな利点として挙げられる
MarkdownよりHTMLを好むようになった理由
- Markdownは、エージェントが人とやり取りするための支配的なファイル形式になっており、シンプルで移植性が高く、多少の書式を表現でき、人が直接編集しやすい
- ClaudeはMarkdown内でもASCIIダイアグラムをうまく作れるが、エージェントがより強力になるにつれ、Markdownは制約の多い形式に感じられる
- 100行を超えるMarkdownファイルは読みにくく、より豊かな可視化・色・ダイアグラムを簡単に共有したくなる
- 自分でファイルを編集するよりClaudeに編集を頼むことが増え、Markdownの大きな利点である「直接編集しやすさ」の価値が薄れてきた
- Claude Codeチームの中でも出力形式としてHTMLを使うケースが増えており、例はhtml-effectivenessで見られる
HTMLの表現力と共有性
- HTMLは、見出しや書式のような文書構造だけでなく、Markdownよりはるかに多様な情報を表現できる
- 表現できる情報には、表によるテーブルデータ、CSSによるデザインデータ、SVGイラスト、
scriptタグによるコード片、JavaScriptとCSSを使ったインタラクションが含まれる - SVGとHTMLでワークフローを表し、絶対配置やキャンバスで空間データを表現し、
imgタグで画像を埋め込める - Claudeが読める情報の大半はHTMLでかなり効率よく表現でき、モデルが深い情報を伝えるうえでも、人がレビューするうえでも効率的な形式になる
- HTMLを使えないと、ClaudeはMarkdown内でASCIIダイアグラムを作ったり、Unicode文字で色を推測させたりといった非効率な表現を使うことになる場合がある
- Claudeがより複雑な作業をこなし、より大きな仕様や計画を書くようになるにつれて、実際に100行を超えるMarkdownファイルはあまり読まれなくなる
- HTML文書は、タブ、イラスト、リンクなどで構造を視覚的に構成できるため探索しやすく、画面サイズに応じて読み方を変えられるモバイル対応にもできる
- Markdownファイルはブラウザが標準ではうまくレンダリングしないため、メールやメッセージに添付する必要があることが多いが、HTMLはS3のような場所に置けばリンクで簡単に共有できる
- HTMLの仕様書、レポート、PR説明は、同僚が開いて参照しやすく、実際に読まれる可能性がはるかに高い
- HTML文書は、スライダーやノブを入れてデザインを調整したり、アルゴリズムのオプションを切り替えて結果を確認したりする双方向インタラクションをサポートできる
- 調整した内容をClaude Codeに貼り戻すためのプロンプトとしてコピーする機能も作れ、関連例はplaygrounds postで扱われている
Claude CodeとHTMLを一緒に使う理由
- Claude Codeは、ファイルシステム、MCP、ブラウザ、Git履歴など多様なコンテキストを読み取り、HTML成果物としてまとめられる
- たとえばコードフォルダ内で生成されたHTMLファイルをすべて探し、グループ化・分類したうえで、各タイプを代表するダイアグラムを含むHTMLファイルを作れる
- ファイルシステム以外にも、Slack、LinearのようなMCP、Claude in Chrome経由のWebブラウザ、Git履歴などから追加のコンテキストを見つけられる
- Claudeと一緒にHTML文書を作るプロセスはより楽しく、成果物により深く関わり、投資している感覚を与えてくれる
- 別途
/htmlスキルを作る必要はなく、「HTMLファイルを作って」または「HTML artifactを作って」と頼むだけで始められる - 重要なコツは、そのartifactに何をさせたいのか、どう使うのかを分かっていることであり、最初は毎回ゼロからプロンプトを書いてさまざまな用途を覚えるのがよい
主な活用方法
-
仕様、計画、探索
- HTMLは、Claudeが問題を掘り下げるための豊かなキャンバスになり、単一のMarkdown計画の代わりに、複数のHTMLファイルの束で作業を始められる
- まず複数の方向性をブレインストーミングし、その後1つの方向を掘り下げてモックアップやコード片を作り、最後に実装計画を書くという流れが可能
- 計画に満足したら新しいセッションを作り、これらのファイルを渡して実装でき、検証エージェントも同じファイルを読んで必要なコンテキストをより広く確保できる
- オンボーディング画面について、レイアウト・トーン・密度が異なる6つのアプローチを1つのHTMLグリッドにし、各選択肢のトレードオフを表示させられる
- モックアップ、データフロー、レビュー対象のコード片を含む、読みやすいHTML実装計画も作らせられる
- コード実装方式の探索や、複数のビジュアルデザイン比較に使える
-
コードレビューとコード理解
- コードはMarkdownファイルでは読みにくいことがあるが、HTMLならdiff、注釈、フローチャート、モジュール構造などをレンダリングできる
- エージェントが書いたコードを理解したり、コードレビューを受けたり、PRをレビューする人に変更内容を説明したりするのに使える
- GitHubの標準diff表示よりうまく機能する場合もあり、PRごとにHTMLのコード説明ファイルを添付する流れも可能
- PRレビュー用のHTML artifactを作り、慣れていないstreaming/backpressureロジックに集中し、実際のdiffに余白注釈を付け、重大度ごとに色分けさせられる
- PR作成、PRレビュー、コードトピックの理解に使える
-
デザインとプロトタイピング
- Claude DesignはHTMLをベースとしており、最終的な表面がHTMLでなくても、HTMLはデザイン表現力が高い
- ClaudeはHTMLでデザインをスケッチしたあと、React、Swiftなど望む言語で書ける
- アニメーションやアクションのようなインタラクションをプロトタイプでき、スライダーやノブを入れて望む値を調整できる
- クリック時に再生アニメーションの後すばやく紫色に変わるチェックアウトボタンを作り、複数のスライダーやオプション、適切なパラメータをコピーするボタンを含めさせられる
- デザインシステムartifactの生成、コンポーネント調整、コンポーネントライブラリの可視化、楽しいアニメーションプロトタイプに使える
-
レポート、リサーチ、学習
- Claude Codeは、複数のデータソースの情報を統合して読みやすいレポートに変えるのが得意
- Slack、コードベース、Git履歴、インターネットなどを検索させ、自分・リーダーシップ・チーム向けの読みやすいレポートを生成できる
- 成果物は、長いHTML文書、インタラクティブな説明書、スライドやdeckの形になりうる
- SVGを使ってダイアグラムを作らせると、可視化に役立つ
- prompt caching関連の記事を準備する際、Git履歴を読ませてprompt cachingの変更全体を扱う深掘りHTMLリサーチファイルを作らせる方法が使われた
- rate limiterの関連コードを読み、token-bucketフローダイアグラム、注釈付きの主要コード片3〜4個、末尾のgotchasセクションを含む単一のHTML解説ページを作らせられる
- 機能の動作要約、概念説明、週次ステータス報告、インシデント報告、SVGイラスト・フローチャート・技術ダイアグラムに使える
-
カスタム編集インターフェース
- テキストボックスだけでは望むものを説明しづらいとき、現在扱っているデータに合わせた使い捨てのHTMLエディタを作れる
- 製品や再利用ツールではなく、特定の1つのデータ片のために目的特化で作る単一のHTMLファイルになる
- 核心は最後に「copy as JSON」や「copy as prompt」のようなエクスポートを入れ、UIで操作した結果をClaude Codeに貼り付けられるようにすること
- 30個のLinearチケットをNow / Next / Later / Cut列のドラッグ可能なカードにし、最終的な並び順をbucketごとの1行の根拠付きでMarkdownとしてコピーさせられる
- feature flag設定をフォームベースのエディタにし、領域ごとにまとめ、依存関係を表示し、前提flagがオフの状態でflagを有効にすると警告し、変更されたキーだけをdiffとしてコピーさせられる
- システムプロンプトを調整する際、左側に編集可能なプロンプトと強調された変数スロットを置き、右側に3つのサンプル入力をリアルタイム表示し、文字数・トークンカウンターとコピーボタンを入れられる
- チケット・テストケース・フィードバックの並べ替え、構造化設定の編集、プロンプト・テンプレート・文言の調整、データセットのキュレーション、文書・書き起こし・diff注釈、色・easing curve・crop region・cron schedule・regexのようにテキストでは表しにくい値の選択に使える
よくある質問と限界
- Markdownは通常トークン消費が少ないが、HTMLは表現力と実際に読まれる可能性が高く、全体の成果物はより良くなる
- Opus 4.7の1MM context windowでは、増えたトークン使用量はコンテキストウィンドウ内でそれほど目立たない
- ほぼすべての用途でMarkdownの使用をやめたが、これはHTMLを最大限好む寄りの使い方ではある
- HTMLファイルはローカルブラウザで開けるし、Claudeに開くよう頼むこともでき、共有可能なリンクが必要ならS3に置ける
- HTML生成はMarkdownより時間がかかり、2〜4倍かかることもあるが、その結果にはそれだけの価値があると判断されている
- 最大の欠点の1つはバージョン管理で、HTMLのdiffはMarkdownよりノイジーでレビューしにくい
- Claudeに好みのHTMLを作らせるにはfrontend design pluginが役立つ
- 会社のスタイルに合わせるには、Claudeにコードベースを見せて単一のデザインシステムHTMLファイルを作らせ、その後ほかのHTMLファイルの参考資料として使える
- HTMLを使うと、Claudeが書いた計画を深く読まずに選択を任せることへの不安が減り、Claudeとの作業でよりフローに乗った状態を保ちやすくなる
1件のコメント
Hacker Newsのコメント
HTMLに傾くと、人間とLLMが文書を一緒に作成・修正しやすい能力を失うのではないかと心配している
単純な説明文なら問題ないが、より複雑な仕様書では、生成結果に直接入り込んで修正する能力が非常に重要だ。HTML文書はMarkdownよりそれがずっと難しいし、LLMにHTMLの修正を再度指示することもできるが、頭の中で言いたいことがすでに明確なときには、それ自体がまた一つの障害になる。こうしたパターンが一般化すると、人間/LLMの共同創作はさらに減り、言い回し・トーン・内容選択までLLMに委ねる方向へ進みそうだ。ブログFAQにこの懸念がなかったのは意外だった
たとえば1行の
pandocコマンドのような形だ今、小さなモバイルゲームを作っていて、等角視点とサウンドがある。Codexに、手元のthree.jsドキュメントにブロックを配置し、Chromium開発者ツールでスクリーンショットを撮るツールを作るよう頼んだところ、ブロック・色・効果を定義する小さなJSON構造を作り、2.5Dタイルセットを出力した。さらに
uvPythonスクリプトで音と音楽を定義させたところ、ノイズを生成できるYAML形式を作り出した。SVGペリカンのテストは完全に乗り越え、Codexは兵士・騎士・司祭の十分なプロトタイプアートと、プロトタイプのサウンドトラックまで作ってしまったこれが対話型のHTMLページではなく、HTMLをレンダリングした画像を載せたTwitterの投稿だという点が皮肉だ
Markdownより意味構造の乏しいプラットフォーム上でHTMLを主張するのは、結局かなりおかしい
両方だと思う
新しいアイデアやツールを探るときによく使うプロンプトは次のとおり
AI以前にも小さなツールをこうやって作っていたし、友人にツールをメールで送りながら「変えたければLLMに投げてみて」と言えるのがよい
ダッシュボード、小さなアプリ、APIとやり取りしたりどこかからデータを取ってきたりするユーティリティを作るとき、スタイルとJSを含んだ単一のHTMLファイル1つでいける範囲は驚くほど広い。社内共有サーバーの個人
~フォルダに置いておけば、誰でもすぐ見て使えるindex.htmlにインラインCSSを入れて作り、結果が気に入ったらそのファイルをプロジェクトのテンプレートファイルの横に置き、LLMにindex.htmlのデザインをテンプレートファイルへ落とし込んでもらうこれまでLLMを使うときの焦点は「アプリ」そのものにあり、アプリの周辺にある補助ツールではなかった。そうした補助ツールは高い完成度や全ケースへの対応を必要とせず、役に立つ程度に動けばよい。使い終わったら捨てて、明日また新しく作ればいい
こういう道具を素早く組み立てて静的サイトに載せられるのはとても便利だ
Web技術は本当に多くのことを正しくやってきた。文句を言う人は多いが、すごいことだ
前職ではバイブコーディングされたアプリを扱っていて、最終的にはそれが理由で辞めたのだが、Next.jsの単一ページフロントエンドと別APIバックエンドという構成のせいで、ユーザー向けURLがバックエンドのエンドポイントと一致していなかった。AIが何にでもReactフックを使うので、状態はメモリ上にあり、URLベースのルーティングは意識して設計しない限り存在しない。だからリンクは自動では生まれず、ユーザーは最上位の入口以外にはリンクする方法がなかった。リンクのことだ。特に社内ツールでは、すべてがリンク可能であるべきで、そうであれば共同作業や問題解決がしやすい。統一されたリソース位置と動詞が必要だという設計は、30〜40年前の時点でも本当によく考えられていた
HTMLとMarkdownの折衷案として、ここで抜けている点がいくつかある。HTMLはトークン効率がずっと低く、HTMLの設計に対して正確なフィードバックを与えるのもMarkdownより難しい
この2つのトレードオフはAnthropicに有利に働く。媒体としてHTMLを使えばトークン消費は増えるし、Claude Designの一部としてHTMLに注釈やマークを付けるツールへ投資している可能性が高いため、ロックインも強くなり得る。偶然か、優れた戦略だ
正確なフィードバックがMarkdownよりなぜ難しいのかもよく分からない。タグで
idやセクションなどを付けられる何十年もHTMLを扱ってきたが、単純な文書では今でもMarkdownのほうが速い。中間地点があるといいし、実際GitHub Markdownのように機能が多いものもすでにある
Mermaidを埋め込むこともできるし、必要ならコンポーネントを混ぜるMDXのようなものも使える。readme.comも内部ではMDXを使っていると理解している。カードやレイアウトが必要なら、Bootstrapのようなものに基づくコンポーネントを入れることもできる。今足りないのはインターフェースのサポートだけだ。純粋なHTMLはすでにレンダリングできるのだから、より強力なMarkdownを追加するのもそれほど難しくないはずだ
元のMarkdown仕様[1]とCommonMark[2]はいずれもインラインHTML対応を明確に規定している。だから用途次第では両方の長所をある程度得られる
ほとんどの部分では通常のMarkdown見出しと段落を使い、画像や表を入れれば、HTMLタグなしでも原文の形で読みやすい。著者が例に挙げたSVGのようなものを入れたいなら、SVGをそのまま埋め込めばよく、閲覧者は好みのビューアでMarkdownをレンダリングすればよい。VS Codeで生のMarkdownファイルを見ていてHTMLタグに出会ったら、
Cmd+Shift+Vでプレビューを開けば終わりだ。もちろん、対話型ボタンや完全にカスタムされたスタイリングを持つ本格的なWebページなら実現は難しいが、主にテキスト・画像・表が中心で、ところどころに付加要素を足したい程度なら、かなりのところまでいける[1] https://daringfireball.net/projects/markdown/syntax#html
[2] https://spec.commonmark.org/0.31.2/#html-blocks
1月から非コーディング用途でこの方式を強く推してきた。重要な性質は、編集可能で、LLMと人間の双方が理解でき、レンダリング可能で、段階的に修正できる単一の真実の源であることだ
一般の人たちとAI作業についてよく話すのだが、街中でAIの会話に出くわすと人類学者のように割って入ることがある。HTMLアーティファクトは新しいブラウザのURLバーのようなものだ。ちょうど、一部のユーザーがそのバーを実はGoogleだと理解しているように。最近は多くの人が、「スプレッドシート」「プレゼンテーション」「マーケティング用1ページ要約」「スライドショー」「競合分析」「HVACシステム図」といった成果物について話しながら、ChatGPTやClaudeのWeb上で作業するのはあまり良くなく、Claude CodeやOpenClawで新しい文書を作るのは奇跡のようだったと言う
実際の文書が何で、体験の違いが何だったのかを尋ねると、コンピューティングの語彙がまだないためかなり掘り下げて聞くか、実際に見せてもらう必要があるのだが、結局はいつもアーティファクトがHTMLだという結論に行き着く。楽しい体験は、ファイルシステム上のHTMLファイル（+CSS+画像）を高品質ですぐにレンダリングしながら反復修正できることから来ていて、必要ならJavaScriptも少し振りかけられる。gitシステムがあれば、本人が気づかないうちにバージョン管理されていることもある。なければ、チェックポイントを作るよう勧めている。一般の人にとって、バージョン管理は次の学習段階なのかもしれない
一方、Webに埋め込まれた体験は、コンテキストウィンドウ内に残っているDOCX/PPTX/XLSXを何度もつつき、ローカル保存先についての曖昧な概念を扱うようなものだ。実際にはサイドバーでHTMLとしてレンダリングされていてもそうだ。HTMLワークフローは、他の媒体もずっと簡単に統合できるようにする。結局、こうしたプレゼン作業は大衆向けのバイブコーディングであり、その下に積み重なったすべての仕組みを知る必要はない。それでも望むなら開いて修正したり、別のエージェントへ簡単に渡したりできる。協調的なマルチメディアコミュニケーションのために作られたシステムが、機械知能が私たちのコミュニケーションを助けるうえで役立つものになったわけだ
以前、私たち（https://www.definite.app/）のエージェントには、レポートやダッシュボードをフロントエンドフレームワークがレンダリングするYAML仕様で書かせていた
たとえばユーザーが「月次売上と注文数を示し、直近100件の注文を表示するレポートを作って」と言うと、エージェントがフロントエンドでレンダリングされる仕様を書いていた。この方式は速いが、フレームワークがレンダリングできる機能要望に埋もれてしまった。「ここではラベルを外したい」「あそこではラベルが必要だ」「このチャートをヒートマップにできるか」といった要望だ。数か月前からはエージェントに単純にHTMLを書かせるようにし、生成にはより時間がかかるものの、カスタマイズには制限がなくなった。新しい方式にも、非技術ユーザーが自分の作った怪物のようなアプリをデバッグしなければならないなど問題は多いが、全体として顧客の評判ははるかに良い
長いエージェント出力は、VIMとmacOS Quick Look（Markdownレンダリング拡張つき）を使うか、プレビューパネルのあるMarkEditに貼り付けて読んでいる
最悪の場合、エージェントにMarkdownを解釈してレンダリングする単純なローカルWebページを作らせればよい。MarkdownはWeb文法の短縮形として発明された[0]ので、まさにその用途だ。エージェントに基本的なMarkdownをHTMLへ変換させるために使うトークンと時間は、これらの方法より大きい気がする
0. https://daringfireball.net/projects/markdown/
ボットの利用は本当に慌ただしく、自己参照的な方向へ流れている