ハクソク

世界を動かす技術を、日本語で。

「Claude Code」の活用: HTMLの非合理的な効果

9時間前原文(twitter.com)

概要

HTML の効果的な活用事例を紹介 シンプルなHTML が持つ強力な利点を解説 Simon Willison の記事の関連性を整理 現代Web開発における HTMLの有用性 を再評価 実用例とともに ポイント をまとめて提示

HTMLの驚くべき効果

  • HTML はシンプルでありながら、 非常に高い表現力 を持つマークアップ言語
  • CSS や JavaScript なしでも、 情報伝達 や 構造化 に十分な力を発揮
  • SEO や アクセシビリティ の観点でも、 HTMLのみ のページが優位性
  • 軽量 かつ 高速な表示 が可能で、モバイル端末でも高いパフォーマンス
  • メンテナンス性 の高さ、 学習コスト の低さが特徴

実例：HTMLの効果的な活用

  • Thariq Shihiparによる HTML活用例 の紹介
    • 純粋なHTML のみで構築されたシンプルなWebページ
    • 読みやすさ と 即時アクセス が実現
    • 余計な装飾やスクリプト がなく、 本質的な情報 に集中
  • 小規模なツール や ドキュメント、 メモ 用途での有効活用
  • GitHub Pages などの静的ホスティングとの相性の良さ

関連記事：Simon Willisonの視点

  • Simon Willisonによる HTMLの「不合理なほどの効果」 に関する考察
    • HTML単体 で多くのニーズを満たせることへの驚き
    • Webアプリケーション や データ可視化 におけるHTMLの可能性
    • JavaScriptやフレームワーク の導入前に、まず HTMLでの実現 を検討する重要性

現代Web開発への示唆

  • 過度な技術導入 を避け、 HTMLの本来の力 を再評価
  • プロトタイピング や 初期リリース 段階では、まず HTMLのみ での実装を推奨
  • アクセシビリティ や パフォーマンス を重視するプロジェクトでの有用性
  • 学習者 や 非エンジニア でも扱いやすいことから、 情報発信の民主化 に寄与

まとめ

  • HTML は シンプルながら強力 なWeb技術
  • 実用例 や 専門家の意見 からも、その有用性が明確
  • 現代Web開発 でも、 HTML中心 の設計を選択肢として検討する価値

Hackerたちの意見

ウェブ技術って本当にすごいところがたくさんあるよね。みんな文句言うけど、実際は素晴らしい。前の仕事では、バイブでコーディングされたアプリを使ってたんだけど（それが理由で辞めたんだけど）、Next.jsのSPAフロントエンドと別のAPIバックエンドがあったから、ユーザーが見るURLとバックエンドのエンドポイントが一致しなかったんだ。AIがすべてにReactフックを使うから、状態はメモリ内にあって、URLベースのルーティングはそれに合わせて設計しない限り存在しないんだよね。だからリンクが自由じゃなくて、ユーザーがトップレベルのエントリーポイント以外にリンクを貼る方法がないんだ。リンク！特に内部ツールでは、すべてがリンク可能であることが協力や問題解決にとって重要なんだ。30年か40年前に、均一なリソースの場所や動詞の必要性がすごくよく考えられてたんだよ。

└

え、じゃあ別のページやタブに移動したとき、URLは更新されないの？

「最近、Markdownの代わりにHTMLを出力フォーマットとして好むようになってきたし、Claude Codeチームの他の人たちもそう使っているのをよく見る。これが理由だ。長いエージェントの出力を読むときは、VIMとMacOSのQuicklook（レンダリング用のMarkdown拡張付き）を使ったり、MarkEdit（プレビューウィンドウ付きのエディタ）に出力を貼り付けたりしている。最悪の場合、エージェントにMarkdownを解釈してレンダリングするシンプルなローカルウェブページを作ってもらうこともできる。Markdownはウェブシンタックスのショートハンドとして発明されたんだ。それが目的なんだよ！エージェントにネイティブのMarkdownをHTMLに変換してもらうのに、これらよりも多くのトークンと時間を使っていると思うよ。」

└

もし本当にバイブを重視するなら、長い出力を要約してもらうようにボットに頼んでみたら？ボットを使うのはすごく面白いし、自己言及的だよね。

└

実際の開発者には理解できるけど、非開発者（俺みたいな）でLLMを使ってドキュメントを編集する人には、あまりストレスにならないと思う。

└

どのQuick Look拡張を使ってるの？いいのを探してるんだ。

新しいアイデアやツールを探るとき、私の定番のプロンプトは「index.htmlに依存関係なしで、スパーススタイリングで、アプリを作成する」なんだ。AIが出る前から、小さなツールを作るときはこうしてたし、友達にそのツールをメールで送って「変更したいなら、LLMに投げてね！」って言えるのが素敵なんだよね。

└

この使い方についてはあまり考えたことがなかったから、ちょっとバカみたいに感じてる。役立つのが明らかに見えるのにね。今までLLMに集中してたのはアプリの方で、アプリの周りの補助的なものはあまり考えてなかった。補助的なものは完全に仕上げる必要もないし、すべてのケースに対応する必要もない。使える程度に機能してればいいんだ。終わったら捨てて、明日また新しいのを作ればいい。

└

同じだね。新しいクライアントのデザインを繰り返すときは、インラインCSS付きのシンプルなindex.htmlを作って、結果に満足したらそのファイルをプロジェクトテンプレートファイルの横に置いて、LLMにindex.htmlからデザインを取ってテンプレートファイルに組み込むように頼むんだ。

└

これが正解だね！ダッシュボードや小さなアプリ、APIとやり取りしたりデータを取得したりできるユーティリティを作るのに、スタイルやJSを含む1つのHTMLファイルでここまでできるなんてすごいよ。共有サーバーの自分の~フォルダにポンと置くだけで、みんながすぐにチェックできるし、使えるんだ！

└

AIにTailwindCSSとAlpineを使わせるのをおすすめするよ。これで軽量でダイナミックなウェブページが作れるから。

└

うちのマネージャーがこれをやって、真顔で「これを本番に入れて」って持ってくるんだけど、5分以上かかる理由を不思議がってる。こういうツールが人の頭をめちゃくちゃにしてるのが本当に嫌だ。

ここで心配なのは、HTMLに寄ってしまうと、人間（あなた！）がLLMと一緒に文書を簡単に共著できる能力を失ってしまうこと。もしそれが自分用の説明書に過ぎないなら問題ないけど、もっと複雑なものの仕様書だったら、私が作られたものを編集できることがすごく大事なんだ。HTML文書だと、MDよりもそれがずっと難しい。もちろん、HTMLを変更するためにLLMに再プロンプトすることもできるけど、頭の中で言いたいことがはっきりしているときには、それがまた別の障害になるんだよね。このパターンがもっと一般的になると、人間とLLMの共同制作が、声やトーン、コンテンツの選択をLLMに委ねる方向にさらに減っていくと思う。ブログのFAQにこの懸念が載っていなかったのには驚いた。

└

HTMLって、MDより編集しづらいって本当にそうなの？

└

俺たちは何十年も前からHTMLを手で書いてきたけど、全然楽だよ。テキストエディタも優秀で、自動ラップや自動クローズのコマンドもあるし。読むのも書くのも簡単だしね。

└

それは、もし生のテレタイプライターエミュレーターに自分を制限するならだけど…ちゃんとしたコーディング環境なら、HTMLの編集はめっちゃ簡単だよ。リッチなモデル出力を目指すなら、埋め込みのWYSIWYGエディタも選択肢になるし。

└

そうだね、Markdownの中にHTMLを埋め込むこともできるし、Markdownでは書けないタグ（<div>、<span>、<img>など）も使えるよ。

└

うん、必要ならタグの中にJSONオブジェクトを埋め込むこともできるよ。

└

そういうことだね。Anthropicのスタッフとして、著者はエージェントがテキストドキュメントとやり取りするワークフローを促進するインセンティブがあるんだ。

└

最近、レポートにHTMLを使い始めたんだ。でも、いつもMarkdownファイルを中間として使って、LLMにMarkdownの表に基づいてグラフや画像用のSVGでより豪華なバージョンを生成するように指示してる。

└

人間的なチームがLLMをワークフローに取り入れる極端な方法が浮き彫りになってるね。私たちのほとんどは、仕事に合ったツールや出力を使って中間にいると思うよ。

└

HTMLは、特定のサブセットに従えばすごく人間に読みやすいよ。むしろもっと読みやすいかも。太字、斜体、下線、Markdownで星やティックがどれに対応するか、全然覚えられないんだよね。

└

実はこれには二つ目のレベルがあると思うんだ。確かにHTMLはどこにでも使えるけど、LLMに自分の言語を定義させるのもかなり効果的だよ。今、アイソメトリックビューと音があるちょっとしたモバイルゲームを作ってるんだけど、コーデックスに「三.jsのドキュメントにブロックを置けるツールを作って、クロミウムのデベロッパーツールでスクリーンショットを撮って」って言ったら、ブロックや色、他のエフェクトを定義する小さなJSON構造を作って、2.5Dのタイルセットを出力してくれた。さらに、「音や音楽を定義できるUVのPythonスクリプトを作って」って言ったら、音を作るためのYAMLフォーマットを作ってくれた。SVGペリカンテストを完全に超えちゃったよ。コーデックスは、兵士や騎士、僧侶の十分に良いプロトタイプアートと、プロトタイプのサウンドトラックも作り上げた。

HTMLとMDのトレードオフについて、ここで言及されていないことがいくつかあるよ：- HTMLはトークン効率がかなり悪い - HTMLの計画に対して正確なフィードバックを提供するのが難しい、MDだとずっと簡単にできる。この2つのトレードオフはAnthropicを成功に導くんだ。HTMLをメディアとして使うとトークンの使用量が増えるし、彼らがHTMLをマークアップするツールに投資していると思う（Claude Designの一部）から、ロックインを改善するのに役立つだろう。偶然か、素晴らしい戦略か。

└

効率はちょっと落ちるけど、構造的な部分やビジュアルがたくさんない限り、大きな違いはないよ。マークダウンよりも正確なフィードバックが難しいって、何があるの？タグを使えば、IDやセクションも作れるし。

俺は約9ヶ月前にMarkdownからJSONに移行して、仕様書を書いてる。HTMLではないけど、同じような利点があるよ。Claudeや他のモデルは、JSON/HTML/XMLみたいな構造化されたフォーマットだと、すごく信頼性が高い。最も重要なのは、構造化されたフォーマットに対して静的解析ができること。これは俺の仕様書にも重要なんだ。データフィールドを書いて、静的解析で分析できる。例えば、さまざまな仕様書間でデータベースフィールドが一致しているか確認するためとかね。静的解析ができるから、HTMLよりもJSON/XMLを使う理由にもなるし、カスタムスキーマも作れるし。YAMLは使わない方がいいよ、あれは信頼性が低すぎるから。（YAMLファイルを半分に切っても、まだ有効だし）

└

これはすごく面白いと思うけど、君とOPは違う問題について話してる気がする。エンドユーザーにテキストを提示することと、エージェントのためにテキストを構造化することだね。

元のMarkdown仕様[1]やCommonMark[2]は、インラインHTMLのサポートを明確に指定してるよ。これを使えば、使い方によっては両方の良いところを活かせる。ほとんどの場合、普通のMarkdownの見出しや段落を書いて、画像を埋め込んだり、表を挿入したりするだけで、HTMLタグなしでソース形式でも読みやすくなるんだ。例えば、記事の著者が一つの使い方として挙げているSVGファイルを埋め込みたい場合は、SVGを直接埋め込むだけで、みんな好きなビューアでMarkdownをレンダリングできるよ。VS Codeで生のMarkdownファイルを見ているときに、HTMLタグに出くわしたら、Cmd+Shift+Vを押してプレビューを開くだけ。それで終わり。もちろん、著者がいくつかの例で示しているような、インタラクティブなボタンや完全にカスタマイズされたスタイリングを持つ本格的なウェブページには向かないけど、テキストや画像、表が主で、ちょっとした追加をしたいだけなら、かなりのところまで行けるよ。[1] https://daringfireball.net/projects/markdown/syntax#html [2] https://spec.commonmark.org/0.31.2/#html-blocks

└

個人的には、Markdownドキュメントをプレビューする必要はないと思う。そうなったら、HTMLドキュメントを作っちゃえばいいんじゃない？

これがHTMLレンダリングの画像を使ったTwitterの投稿だっていう皮肉、全然気づいてるよ。Markdownよりもセマンティクスが貧弱なプラットフォームでHTMLを主張するのが、結局面白いよね。

└

Twitterの記事の「テンプレート」の話はやめてくれ、Markdownすらサポートしてないんだから…

地球上で最も多くの人に使われている「プログラミング」言語の異常な効果について。何十年も熱心に作り上げてきた人たちがいて、最も多くの人とコミュニケーションするために使われている言語なんだよね（そう、ほとんどの「アプリ」は、少なくともモバイルでは、さらにデスクトップでもHTMLページだし）。本当に異常に効果的なのかな？

└

こういうコメントを投稿するのはいつも心配なんだ。多くのテック系の人たちは「このクリックベイトがクリックベイトじゃない理由を論理的に説明しないと、君はトロールだ」って言ってくるから。先に言われちゃったね。ありがとう。あと、ここに投稿されてるのが「40年以上前からあるもの、/:/; Claude/chatgpt」みたいなのが10%くらいってのも好きだな。死んだインターネットの代償でこんなに広告が溢れてるのは馬鹿げてる。

└

「異常な効果」というフレーズはAIの文脈で使われてるんだ。「出力を大きく乱さずに、たくさんのマークアップ文字を文脈に入れる」ことが予想外と見なされるかもしれない。実際のパフォーマンスへの影響は測定が難しいLLMのパフォーマンスを考えると分からないし、トークンを支払う人も満足しないだろうね。HTMLの文脈で使われたこともあるけど、いくつかの論文がそのフレーズを使ったから、ちょっとした「ミーム」みたいなもんだね。「Xがあれば全て解決」っていうスノークローンみたいに。HTMLバージョンは2021年のもので（https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...）、クライアントサイドレンダリングとウェブアプリがまだピークだった頃の話。

この記事は、LLMの文脈を超えてずっと考えてきたことを提起してるね。HTMLがウェブサイトやウェブサーバー以外の情報共有のための一般的な手段としてもっと広まらなかったのは、すごく驚きだよ。WordやExcelのドキュメントみたいに、ただ回覧するものとして。

└
  1. 人々がそれが可能だと知らない 2. 単一ファイルとして機能するようには設計されていないし、私の知る限り、普遍的な方法はない 3. 多くの人にとって、WordやExcelほど簡単に編集できない 4. PDFのような代替手段がある。