ハクソク

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

ウェブサイト仕様書

4時間前原文(specification.website)

概要

このドキュメントは、 優れたウェブサイト が備えるべき 技術的機能 のプラットフォーム非依存仕様をまとめたものです。 10分野 に分類し、各項目は国際的な標準に準拠しています。 人間とエージェント の両方を対象とした内容設計。 各トピックは 公式標準 へのリンク付きで、実装ヒントも提供。 オープン開発 ・PR歓迎・GitHub編集リンク・全仕様はMCPサーバー経由で提供。

優れたウェブサイトの技術仕様

  • HTML・head・ドキュメント基本要素 の網羅
    • title要素、基本的なHTML構造、メタデータなどの基礎仕様
  • SEO（検索エンジン最適化）対応
    • robots.txt、sitemaps、canonical、構造化データなど検索可視性向上策
  • アクセシビリティ（WCAG準拠）
    • 色コントラスト、キーボード操作、代替テキストなど全ユーザー対応
  • セキュリティ
    • HTTPヘッダー、HTTPS強制、CSPなど安全性確保策
  • Well-Known URI
    • /.well-known/配下の標準パス（security.txt等）の設置
  • エージェント対応
    • AIエージェントやクローラーに読解可能な構造・llms.txt対応
  • パフォーマンス最適化
    • Core Web Vitals、キャッシュ制御、画像・フォント最適化
  • プライバシー尊重
    • 同意管理、プライバシーシグナル対応、ユーザー選択の尊重
  • レジリエンス（耐障害性）
    • エラーページ、オフライン対応、リダイレクト設計
  • 国際化
    • 言語・ロケール・テキスト方向・翻訳コンテンツ対応

標準と実装方針

  • 各項目 はWHATWG、W3C、IETF RFCs、WCAG、MDNなどの 公式標準 に準拠
  • プラットフォーム非依存 （WordPress、Drupal、Next.js、Hugo、Django、静的HTML等すべて対象）
  • 仕様が最優先、実装ヒントは仕様に従属
  • オープン開発体制、全ページに「Edit on GitHub」リンク設置
  • 情報源明記、各ページにソースクレジット
  • エージェント対応 ：全仕様はMCPサーバー経由で公開、/llms.txtやAccept: text/markdownでMarkdown取得可能

サイトの利用方法

  • 監査
    • チェックリスト形式で「実装済みか否か」を確認
  • 学習
    • 各項目をクリックし、内容・重要性・実装方法を詳細解説
  • 改善
    • 不足・誤り・追加要望はPRで提案（ソース必須）

MCPサーバー・エージェント連携

  • 仕様全体 はMCPサーバー（https://mcp.specification.website/mcp）で公開
  • Agent Skill としても提供、互換エージェントが利用可能
  • ページごとにMarkdown取得 （/llms.txtまたはAccept: text/markdownヘッダー）

まとめ

  • 広範な標準準拠チェックリスト による品質保証
  • 人間とAIエージェント 双方の利用を想定した設計
  • オープンかつ透明性重視 の運用方針

Hackerたちの意見

.well-known/securityは有名な例として挙げられてるけど、実際には有名なカテゴリには入ってないんだよね。

└

便利な参考資料だね、https://securitytxt.org/。ただ、いくつかのサイトは/.well-known/security.txtの代わりにルートの/security.txtに置いてることもあるから注意してね。招待状はバウンティやスパムを引き寄せるから。

└

「セキュリティ」カテゴリに入ってるよ。彼らが使ってるカテゴライズの仕組みでは、アイテムごとに複数のカテゴリを割り当てることができないみたいだね。

うーん、これらの中でどれくらい一般的なのか気になるな… /.well-known/change-passwordがあったらいいのに。でも、https://news.ycombinator.com/.well-known/change-passwordやgoogle.com/.well-known/change-passwordは実装されてないみたい？

└

security.txtは、存在する場合、サイトのこのフォルダの下に常に置かれてるよ。これは、letsencryptが証明書や更新失敗のためにも使うんだ。

└

SafariとChromeでは動くみたいだね: https://web.dev/articles/change-password-url でも、実際に使われてるのは聞いたことないな。GoogleのURLは https://accounts.google.com/.well-known/change-password にあるけど、メインのドメインにはないよ。

「エージェントの準備状況」は「Web 4.0 ブロックチェーン統合」と同じように時代遅れになるだろうね。（はっきり言うけど、エージェントが関係なくなるわけじゃないと思うけど、特別な許可をサイトから求めることが全体の目的を損なうと思うんだ。結局、悪用するやつらがエージェントが見るものと人間が見るものをずらして使うだけだから、意図的に無視されることになるだろうね。）

└

そうだね、エージェント向けに提案された「基準」の全体像は、今のエージェントの限界やコストをなんとかごまかそうとしてる一時的な策に見えるよ。彼らはAnthropicやGoogle、OpenAIなんかが新しいモデルを出すたびにすぐに回転していくんだろうね。

└

今のウェブサイトは広告だらけで膨れ上がってるから、純粋なテキスト版があったらいいなと思うよ。人間はそれを使って、エージェントには私たちのために必要なものを処理させればいいんじゃないかな。でも、そうなるとは思えないんだよね。悪質な行為については、昔からできてたことだし。例えば、検索エンジンのクローラーには違うコンテンツを見せるとか。確か、Googleはそういうサイトをペナルティした時期もあったよね。

└

神に誓うわ。2000年代に戻りたい。あの頃は、基本的にプレーンなHTMLとちょっとしたCSSだけで、デフォルトでレスポンシブデザインがあって、読みやすいテキストと超ユーザーフレンドリーなGUIがブラウザのデフォルトスタイルシートから提供されてた。今はどのウェブサイトを開いても、全部がクソなコンポーネントだよ。有限リストのシンプルなドロップダウン？ 自分専用のローダーがあって、意味もなく10回もフェッチリクエストをする。誇張じゃない、ウェブのInstagramやFacebookを見てみて。クソみたいな仕様はどうでもいいから、俺にお前らのクソみたいな新しいJSフレームワークに隠されてない生のHTMLをくれよ（お前のことを見てるぞ、React）。

└

キーワードメタタグを再び素晴らしいものにしよう！

これはスラップファクトリーから出てきたスラップみたいだ。「SEO」と「エージェント準備」。まさに良いウェブサイトがやらないことだね（ホームページを言い換えると）。ああ、これはWordpressの「SEO」専門家とプライベート投資家がClaude LLMを使って作ったものなんだ。驚きだね。広告のスラップで私たちが愛したインターネットを壊して富を築いた男が、今残っているものをLLMのスラップで壊そうとしてるんだから。

└

これ、私にもスロップフラグが立つわ。1 - 小さな色タグ：必須、オプション、推奨。2 - 誰も読まないような膨大なコンテンツ。3 - アイデアの弱い前提が、痛いほど詳細に展開されてる。

└

概要ページから（https://specification.website/about/）：> フレームワークではない。ガイドでもない。仕様だ — 必要なこと、推奨されること、避けるべきこと。サイトのどれくらいがLLMのスロップなのかはわからないけど、確かに一部のコピーはそうだね。

└

どうやら純粋なAIのゴミらしいよ、 https://tropes.fyi/vetter 使ってる。

└

エムダッシュや「XじゃなくてY」みたいな言い回し、重複した内容を見ると、これがAIによるものだって確信できる。 「安定したURL」を「エージェントの準備」としてフラグ付けしてるのを見ると、これを書いた人は人よりもAIのことを重視してるんだなって思う。このドメインはブラックリストに入れるつもり。これがウェブ開発に関する情報を探すのをどれだけ悪化させるか、もう見えてるよ。

└

単一ページの完全な仕様は、今のAIによる雑なウェブ開発のポスターボーイみたいだね。 https://specification.website/llms-full.txt

すごく良いリソースだね。30年間ウェブサイトを作ってきた者として、基本的なことをまだ学べるのは驚きだよ。ただ、正直言うと、当時はこれらの多くは存在しなかったけどね。この情報を使って、自分のページにいくつかのタグを追加しようと思ってる。必要とされる機能の中には、実際に仕様で必要なもの（例えば、タイトルタグ）や、意見で必要とされるもの（例えば、https）があるから、実用的なベストプラクティスが推奨されてる要素があるんだ。ブラウザに色のヒントを設定することが推奨されてるのは興味深いね。私はブラウザをできるだけシンプルにして、自分のページが話すようにしてるから。^意図したダジャレじゃないけど、見逃さないようにね。

└

このウェブサイトから何を学んだ？

これの中には結構いい内容もあるけど、128項目のチェックリストに標準化することで、ウェブサイト作成をためらう人が出ないことを願ってるよ。

https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification... このウェブサイトの目的がよくわからない。仕様として避けられてるけど、何のための仕様なの？すべてが別の「真実のソース」に基づいてる。

└

LinkedInでこれが投稿されてるのを見たよ[1]。著者はこう書いてた：> 6つの異なるソースを指摘するのに疲れた。HTMLはWHATWG、アクセシビリティはWCAG、ヘッダーはIETF、構造化データはschema.org、その他はMDN、web.dev、Google Search Central。> 「現代のウェブサイトは実際に何をする必要があるのか？」という意見が一つにまとまった、プラットフォームに依存しない仕様がなかった。> だから、私はそれを書いた。 [1] https://www.linkedin.com/posts/jdevalk_the-website-specifica...

└

これはベストプラクティスのまとめで、一つの場所でチェックリストとして使えるのは価値があるよ。

ログインフォームに関するベストプラクティスを知りたいな、例えば：

  • パスワードマネージャーが認識する標準の入力フィールド名を使う
  • ログインフィールドではオートコンプリートとオートキャピタリゼーションを無効にする
  • メールアドレスの場合は正しいHTML5入力タイプを使う
  • ログイン用のメールアドレスだけのフォームを作って、パスワードを入力するためにクリックを強制しない
  • NIST SP 800-53に従う、例えばSMSの2FAはなし、任意のパスワードローテーションや構成ルールもなし それに、入力が一つだけのフォームで自動的にフォーカスが当たらないサイトも多いよね。
└

Evil Martiansがログインフォームについていい記事を書いてるよ： https://evilmartians.com/chronicles/html-best-practices-for-...

└

アダム・シルバーのブログでフォームのベストプラクティスについて読むのが楽しかったよ。 https://adamsilver.io/blog/form-design-from-zero-to-hero-all... 彼はそれ以来、たくさんの新しいことを投稿してる。ウェブ上でのUXリソースの中では多分一番いいやつ。

└

ログイン用のメールアドレスだけのフォームを作って、パスワードを入力するためにクリックを強制しない こういうログインフォームが増えてるのに気づいた、特に「ビッグテック」のサイトで。（個人的には、これもウザいと思う）サイトがこのパターンに切り替わる理由があると思ってたけど、例えばボット保護が良くなるとか。これについて詳しい人いる？

└

入力が一つだけのフォームを持つサイトが、自動的にその入力にフォーカスしないことがどれだけあるか。これは「ウェブスタック」が、すべてのウェブサイトにネイティブUIツールキットで標準だったことを手動で実装させる多くの例の一つだよね。もちろん、ほとんどのウェブサイトはそれを優先事項と考えなかったり、そもそも考慮すべきことだと気づかなかったりして、こんな状況になっちゃうんだ。

マックブックでサイトを開いたら、CPU使用率が50%を超えた。ウェブサイトの仕様についてのはずなのに、ちょっと皮肉だね。

└

え？ここでは同じことは観察できないよ。君の方で何が起こってるのか調べた方がいいかも！

いいリソースで、整理もされてるね。いくつか新しいことを試す機会を得たよ。