The Website Specification

 (specification.website)
4 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 優れたWebサイトが備えるべき技術的機能を、プラットフォームに依存せず整理した仕様で、<title>からllms.txtまでを扱う
  • 人間とエージェントの両方を対象とし、WHATWG、W3C、IETF RFCs、WCAG、MDNなどの現代的なWeb標準をリファレンスとしている
  • WordPress、Next.js、Djangoアプリ、純粋なHTMLなど、配信方法に関係なく仕様そのものは同一で、実装のヒントも含まれる
  • 全体のテーマは Foundations、SEO、Accessibility、Security、Performance など10の領域に分かれ、広く受け入れられた標準にマッピングされている
  • 公開 MCP サーバー、Agent Skill、/llms.txt、Markdown レスポンスを提供し、エージェントと運用者が監査・学習・改善の流れに活用できる

優れたWebサイトのためのプラットフォーム非依存仕様

  • The Website Specification は、優れたWebサイトが備えるべき技術的機能を、プラットフォームに依存せず整理した仕様で、<title>から/.well-known/security.txt、WCAG 準拠、llms.txtまでを扱う
  • 人間とエージェントの両方を対象とし、各トピックは WHATWG、W3C、IETF RFCs、WCAG、MDN などの現代的なWeb標準の情報源に結び付けられている
  • WordPress、Drupal、TYPO3、Next.js、Astro、Hugo、Djangoアプリ、純粋なHTMLなど、どのような方法で配信しても 仕様そのものは同一 で、実装のヒントはその後に続く
  • すべてのページには Edit on GitHub リンクがあり、PR を受け付けており、各ページには出典が表示されている

  • 扱う領域

    • 全トピック は、広く受け入れられた標準にマッピングされた10の領域に分かれている
    • Foundations: 14項目で HTML、head、文書の基本要素を扱う
    • SEO: 13項目で robots.txt、サイトマップ、canonical、構造化データなど検索露出の要素を含む
    • Accessibility: 20項目で、あらゆる能力の利用者がサイトを使えるようにする WCAG ベースのルールを示す
    • Security: 12項目で、訪問者を安全に保護するヘッダー、転送、ポリシーを扱う
    • Well-Known URIs: 9項目で /.well-known/ 配下の標準化された合意済みパスを整理する
    • Agent Readiness: 18項目で、AI エージェントとクローラーがサイトを読めるようにする要素を扱う
    • Performance: 19項目で Core Web Vitals、キャッシュ、画像、フォント、ネットワーク動作を網羅する
    • Privacy: 6項目で、同意、シグナル、訪問者の選択の尊重を扱う
    • Resilience: 5項目で、エラーページ、オフライン、リダイレクトのような graceful failure を扱う
    • Internationalisation: 12項目で、言語、ロケール、方向、翻訳コンテンツを扱う

エージェントとサイト運営者のための利用方法

  • 仕様全体は、読み取り専用・認証不要の公開 MCP サーバーとして提供される
  • 互換エージェントに対して、いつどのように仕様を使うかを伝える Agent Skill が公開されている
  • 各仕様 URL は /llms.txt と Accept: text/markdown を通じてページごとの Markdown を提供する
  • MCP サーバー設定の例は次のとおり
{  
  "mcpServers": {  
    "specification-website": {  
      "transport": "http",  
      "url": "https://mcp.specification.website/mcp";  
    }  
  }  
}

  • 利用フロー

    • Audit: チェックリスト を確認しながら、各項目について「サイトはこれを行っているか — はい／いいえ」で確認する
    • Learn: 各項目で、それが何か、なぜ重要か、どのように実装するかを確認する
    • Improve: 不足している部分、古くなった事実、抜けているトピックを見つけたら、出典を付けて PR を作成できる

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • Agent Readiness は、「Web 4.0 Blockchain Integration」のように、時間がたつと気まずいものになる可能性が高い
    エージェントが無意味になるからではなく、たとえ重要になったとしても、サイト側がエージェント向けの例外処理をしなければならないなら本来の趣旨を損なうため
    結局は悪意ある行為者が、エージェントに見せるものと人間に見せるものを変えるために使うようになるだろうし、そのせいで意図的に無視されるようになる気がする

    • 2000年代に戻りたい。あの頃の基本はただの 純粋な HTML と少しの CSS で、ブラウザのデフォルトスタイルシートだけでもレスポンシブに近いレイアウト、読みやすいテキスト、使いやすい GUI が得られた
      今のウェブサイトは何もかもがコンポーネントだ。有限な項目しかない単純なドロップダウン1つにさえ独自ローダーがあり、理由もなく fetch リクエストを10回も投げる。誇張ではなく、Instagram や Facebook のウェブを見ればいい
      こういう仕様は全部やめて、新しい JS フレームワークが世界を変えると言い張る React みたいなもので難読化されていない、生の HTML をくれればいい
    • 最初は反論しようと思ったが、考えれば考えるほど結論には同意する。ただし理由は少し違う
      ウェブは本質的に 敵対的な環境 であり、ウェブサイトを運営する側のかなりの部分は、それ自体が悪意ある行為者だと思っている。人間に見せるものとエージェントに見せるものを変えることは、検索エンジン相手にやってきたのと同じように、ウェブサイトが意図的に使うはずだ
      「Agent Readiness」が長続きしない理由は、サイト運営者がすぐにエージェントとは実質的に アクセスの自動化 なのだと気づくからだと思う。それは彼らがずっと戦ってきた相手であり、収益化能力を脅かすものでもある
    • ウェブサイトがここまで肥大化して広告だらけになったのを見ると、人間向けにも プレーンテキスト版 があってほしい。人間向けの複雑さはエージェントに処理させたい
      ただ、実際にそうなるかは疑わしい。悪意ある行為者の問題はずっと前からありえた。たとえば検索エンジンのクローラーに対して、ユーザーがクリック後に見るものとは違うコンテンツを返すといったことだ。記憶が正しければ、Google がそうしたサイトにペナルティを与えていた時期もあった
    • サイト全体のアイデアは悪くないが、AI/ブロックチェーンのたわごとが嫌いなら、こういうチェックリストはかなり一般的だ。ここ数年でいちばん気に入っているのはこれ
      https://frontendchecklist.io/rules
    • Agent readiness は、まったく有用な段階に見える。自分のウェブサイトでは人間はブロックチェーンを使わないが、AI は使っているし、AI が人間のようにウェブサイトを使う必要もない
      人間は見栄えのよいウェブサイトを求めるし、それは純粋な HTML だけでも実現できる。エージェントにはそれすら不要で、理想的にはページ内容を Markdown だけで見られればよい
      エージェント版があって何が悪いのか。クライアントエージェントとウェブサイトホストの時間とコストを節約できる
      llms.txt のような標準で、「エージェントは人間向けに見えているものの生の Markdown 版であるこのミラーを代わりに訪問せよ」と指定できるとよい
      このサイトの agent readiness の一部は、AI 向け SEO に当たる。逆に AI クローリングを望まないサイトなら、その逆の役割も果たす

  • ログインフォームのような領域にも ベストプラクティス があるとよい。たとえば、パスワードマネージャーが認識する標準的な入力フィールド名を使うこと、ログインフィールドでオートコンプリートと自動大文字化を無効にすること、メールアドレスなら正しい HTML5 の input type を使うこと、メールアドレスだけ入力させて再度クリックしないとパスワードを入力できないフォームを避けること、NIST SP 800-53 に従って SMS による二要素認証や任意の定期的なパスワード変更・複雑性ルールを避けること、などだ
    入力欄が1つしかないフォームで自動的にフォーカスを当てないサイトも多すぎる

    • Adam Silver のブログでフォームの ベストプラクティス を読むのはかなり面白かった
      https://adamsilver.io/blog/form-design-from-zero-to-hero-all...
      その後も新しい記事をたくさん公開していて、ウェブ上で最高クラスの UX 資料の1つかもしれない
    • パスワードを入力する前にログイン用メールアドレスだけを送信させるのは、少しでもまともな認証システムなら実際ほぼ必要だ
      ユーザー名が送信されるまでは、そのユーザーがパスワードを使うのか、それとも別の方式を使うのか分からない
    • 何年も frontendchecklist を使ってきたが、こうした種類のルールやベストプラクティスのまとめがある。残念ながら最近サイトは ai-readiness を受け入れる方向に変わったようだが、ルール自体はまだ残っている
      https://frontendchecklist.io/rules/html/input-types
      UI コンポーネントをゼロから作るときは、このサイトが本当に好きだ
      https://component.gallery/
      さまざまなデザインシステムのコンポーネントへリンクしてくれて、その多くはアクセシビリティや国際化などのガイドラインも深く含んでいる。ドキュメントが特によくできた例としては、Salesforce の Lightning Design System と StackOverflow の Stacks がある
      https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...
      https://stackoverflow.design/system/forms/checkbox
    • 入力欄が1つしかないフォームで自動フォーカスしないのは、ウェブスタック が、ネイティブ UI ツールキットでは標準だった機能を、すべてのウェブサイトが自前で実装することを期待している一例だ
      その結果、ほとんどのウェブサイトはそれを優先事項と見なさないか、そもそも考慮すべき項目だとすら認識せず、結局いまのような状態になる
    • メールアドレスだけを先に入れさせるログインフォームは、とくに大手テック企業のサイトで増えている気がする。個人的にもいらだつ
      サイト側がこのパターンに切り替える理由はあるのだろうとずっと思っていた。たとえばボット対策に向いているとか。もっと詳しい人がいるのか気になる

  • 見た目はほとんど全部がAI生成物のようで、伝え方がうまく機能しないかもしれない。それでもいくつかの項目を読んでみると、Agentセクションを除く残りは堅実なWeb衛生をかなり明確に伝えていて、これから成長するWeb開発者に送っても悪くないと思う
    ただ、サイト自体が自分たちで「必須」とした慣行すら適用していないのは皮肉だ

    • "Compression (gzip, brotli, zstd): required" や "cache-control: required" だなんて、最初から最後までAIの残りかすだ

  • https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...
    このWebサイトの目的がわからない。仕様だと宣伝しているが、いったい何を仕様化しているのかわからない
    すべての項目が別の「真実の源泉」を出典にしている

    • ベストプラクティスの寄せ集めであり、一か所で見られるチェックリストとしては価値がある
    • LinkedIn[1] に投稿されたものを見たが、作者はこう書いていた
      "単一の推奨事項を裏づけるために6つのソースを示すことに疲れた。HTMLはWHATWG、アクセシビリティはWCAG、ヘッダーはIETF、構造化データはschema.org、残りはMDN、web.dev、Google Search Centralだった
      現代のWebサイトが実際に何をすべきかについての、単一で、意見が明確で、プラットフォームに中立な仕様がなかった
      だから1つ書いた"
      [1] https://www.linkedin.com/posts/jdevalk_the-website-specifica...

  • ここにあるものがどれほど一般的なのか気になる。/.well-known/change-password はあればよいが、https://news.ycombinator.com/.well-known/change-password と google.com/.well-known/change-password を見ると、実装されていないようだ

  • これは残りかす工場から出てきたように見える。"SEO"、"Agent-readiness" だなんて。良いWebサイトがやるべきでない、まさにそのことだ
    案の定、Claude LLM を使う WordPress の "SEO" 専門家であり個人投資家が作ったものだ。広告の残りかすで私たちの愛したインターネットを壊して富を築いた人間が、今度は LLM の残りかすで残っているものまで壊そうとしている

    • 長いダッシュや文のパターン、たとえば "X ではなく Y" のような表現と重複コンテンツを見ると、私にはほとんどAI生成だとわかる
      "stable URLs" を "agent readiness" に分類したのは、作者が人間よりAIを気にしているサインに見える。このドメインはブロックリストに入れるつもりだ。Web開発情報を検索する作業をさらに悪くするのがもう見えている
    • about ページ(https://specification.website/about/) にはこうある
      "フレームワークではない。ガイドでもない。仕様だ — 何が必須で、何が推奨で、何を避けるべきか。"
      サイトのどの程度が LLM の残りかすなのかは言いにくいが、一部の文言はたしかにそう見える
    • 純粋なAIの残りかすに見える。私は https://tropes.fyi/vetter を使っている
    • 単一ページの完全仕様は、最近のAI残りかすWeb開発の象徴的なポスターのようだ
      https://specification.website/llms-full.txt
    • 私にも残りかす警報が鳴っている
      第一に、required、optional、recommended のような小さな色タグ
      第二に、誰も読まないような狂った分量のコンテンツ
      第三に、弱いアイデアを痛々しいほど細かく押し通す展開

  • こういうものを自分で作ろうと思っていたが、これを適当なエージェントチャットに貼り付けるととてもうまく動く
    たった今、ローカルモデル(Qwen3.6 27B / pi) で古い Hugo サイトに欠けている必須標準の一覧を作り、やることリストを作ったあと、1つずつ処理させて、各変更は自分がレビューできるようにした
    足りなかった favicon もロゴからシンボルを切り出して作ってくれたが、かなりいい出来だった

    • pi をどれくらいいじったのか気になる。短いエージェント/システムプロンプトの無負荷な感じはいいが、任意の作業をそのまま任せると待ち時間や行き止まりがかなり発生しそうだ

  • MacBook でサイトを開いたらCPU使用率が 50% を超えた
    Webサイトがどうあるべきかの仕様だという点を考えると、かなり皮肉だ

    • こちらでは同じ現象は見えない。ユーザー側で何が起きているのか確認してみるとよさそうだ

  • 一部の内容はかなり良いが、128項目のチェックリストとして標準化することで、人々がWebサイトを作るのを怖がるようにはなってほしくない

  • 私がいちばん好きな仕様は幻覚された仕様だ。よくやったと言うべきなのか
    エージェント主導の ISO 代替や、LLM が運営するスロットマシンがもう楽しみだ