評価基準
評価基準
Tooru の AI エージェント互換性診断が、何を・どう測り・何点を付けるかを全て公開しています。スコアは各ページの HTML・robots.txt・構造化データ・エージェント向けファイルを機械的に解析した結果で、人の主観は入りません。
基本原則
本診断は 3 つの原則に基づいて設計されています。
- 客観性
- すべての評価項目は、公開された技術規格または各社の公式ドキュメントから導いています。結果は配信されたままのページを機械的に読み取ったもので、主観的な判断は含みません。
- 再現性
- 同一の URL を同一の条件で測定すれば、同一のスコアになります。Tooru は結果をキャッシュしません。実行ごとにページを取得し直すので、サイト側の変更は次の実行に反映され、Before/After 比較のための履歴として残ります。
- 透明性
- 配点のある 39 項目の評価基準・配点・判定方法・準拠規格と、配点なしで記録する参考項目 16 つを、本ページで公開しています。
スコア体系
総合スコアは 4 つの問い（見つけてもらえる 19・読み取れる 29・伝わる 38・使われる 14）の合計で 100 点満点です。採点はページ（URL）単位で行い、robots.txt・sitemap.xml・llms.txt・/.well-known/ などドメイン単位のリソースはオリジンごとに 1 回取得します。そのページに当てはまらない項目は「対象外」として計算から外し、問いごとの点は「満点 × 獲得点 ÷ 当てはまる項目の満点の合計」を四捨五入して出します。当てはまる項目が 1 つも無い問いは、ほかの問いの達成率で埋めます。項目によっては問うページの種類が決まっています。ページの種類は、トップ（サイトのルートか /en/ のような言語のルート）・FAQ（FAQPage の構造化データ、/faq のようなパス、または FAQ の見出し）・記事（公開日付きの Article 系の構造化データ、または日付か記事の本文があるニュース・ブログのようなパス）・その他の 4 つです。
1. AI に見つけてもらえる？19 点 · 11 項目2. AI がページを読み取れる？29 点 · 10 項目3. 会社のことが AI に伝わる？38 点 · 12 項目4. AI が答えに使ってくれる？14 点 · 6 項目
合計100 点 · 39 項目
上記 39 項目に加え、参考項目 16 つ（方針・参考のボット、これからの対応の宣言、クローラーの取得の経過、指摘のみの判定）を配点なしで記録します。参考項目がスコアを動かすことはありません。
ランク定義
総合スコアに基づき、ページごとに 5 段階のランクを付与します。
| ランク | スコア | 判定 |
|---|---|---|
| S | 90〜100 | 規格への準拠度が非常に高く、主要な AI エージェントが支障なく読み取り・到達できる状態。 |
| A | 75〜89 | 主な条件が揃っており、4 つの問いのうち 1〜2 段を直すとさらに上がる状態。 |
| B | 60〜74 | 基本的な対応はあるが、AI エージェントが情報を正確に取得できない項目が残っている状態。 |
| C | 40〜59 | 4 つの問いのうち複数の段で点が低く、AI が情報を読み取る・使うのに支障がある状態。 |
| D | 0〜39 | 準拠が不十分で、主要な AI エージェントが正確な情報を取得できない状態。 |
サイトの総合ランクは、そのサイトで診断した各 URL の最新スコアの平均（小数第 1 位まで）を、同じ閾値に当てて決めます。
問いごとの評価項目
1. AI に見つけてもらえる？ (19 満点)
検索型の AI クローラーがサイトに来られ、案内を見つけられるか。sitemap・canonical URL・/.well-known/ での MCP サーバーの宣言・フィード・llms.txt・Content-Signal の方針を測ります。見つけてもらえないページは、中身がどれだけ良くても届きません。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| 1-1 | MCP サーバーの宣言（/.well-known/） | 3 | 取得＋接続（initialize） | MCP のサーバーカードを /.well-known/mcp/server-card.json・/.well-known/mcp.json・/.well-known/mcp で探し、MCP のカードとして読める最初のものを使います（MCP に固有の鍵が無い JSON、たとえば JSON のエラーページはカードと見なしません）。カードがあれば、そこに書かれた MCP サーバーへ実際に JSON-RPC の initialize を送ります。MCP の応答が返る=3。401/403 が返り、OAuth の発見（RFC 9728 の保護リソースのメタデータ → RFC 8414 の認可サーバーのメタデータ）がたどれる=3、たどれない=0。カードにサーバーの URL が無い・旧方式（HTTP+SSE）だけ・エラーの応答・応答なし・MCP の応答ではない=0。カードが無い=対象外（減点なし）で、レポートの「これからの対応」で MCP サーバーの用意を提案します。 |
| 1-2 | sitemap.xml | 2 | 取得・検証 | robots.txt の Sitemap: 行（同じサイトのもの・サブドメインを含む・先頭の 3 本まで）を先に試し、次に /sitemap.xml・/sitemap_index.xml・/wp-sitemap.xml・/sitemap-index.xml の順に 1 本ずつ試して、sitemap として読めた最初のものを使います。gzip で圧縮したものも読みます。urlset または sitemapindex 要素と loc を含む=2。要素はあるが loc が無い=1。それ以外、または見つからない（HTML が返る場合も無しと扱う）=0。 |
| 1-3 | canonical URL | 2 | link[rel=canonical] | link[rel="canonical"] がこのページ自身を指す（末尾の /・index.html・クエリ・# の違いは同じとみなす）=2。http/https か www の有無だけ違う=1、トップ以外のページがトップを指す=1（テンプレートでよくある誤設定）、別のページを指す=1（意図した統合のこともある）、http(s) の URL でない=1。無し=0。 |
| 1-4 | OAI-SearchBot の許可 (検索型) | 2 | robots.txt 解析 | OpenAI の検索用クローラー（ChatGPT 検索）が Disallow されていないこと。ブロックすると ChatGPT の検索結果から消えます。許可またはルール無し=2、拒否=0。robots.txt が無ければ許可と同じ。サーバーの不調で robots.txt が読めない場合は対象外。 |
| 1-5 | PerplexityBot の許可 (検索型) | 2 | robots.txt 解析 | Perplexity の検索用クローラーが Disallow されていないこと。許可またはルール無し=2、拒否=0。robots.txt が無ければ許可と同じ。サーバーの不調で robots.txt が読めない場合は対象外。 |
| 1-6 | Claude-SearchBot の許可 (検索型) | 1 | robots.txt 解析 | Anthropic の検索用クローラーが Disallow されていないこと。ブロックすると Claude の検索引用から消えます。許可またはルール無し=1、拒否=0。robots.txt が無ければ許可と同じ。サーバーの不調で robots.txt が読めない場合は対象外。 |
| 1-7 | RSS / Atom フィード | 2 | フィードリンク検出 | トップページだけで問います（ほかのページは対象外）。rel="alternate" で type が application/rss+xml・application/atom+xml・application/feed+json の link 要素がある=2、無し=0。WordPress の oEmbed（text/xml+oembed など）はフィードに数えません。 |
| 1-8 | /llms.txt の存在 | 2 | ファイル取得 | /llms.txt をテキストとして取得できること（HTML が返る場合は無しと扱う）。存在=2、存在するが 10 文字未満=1、無し=0。 |
| 1-9 | llms.txt の仕様準拠度 | 1 | フォーマット検証 | llmstxt.org の形と突き合わせます。① 最初の行が「# 」のタイトルで、それが 1 つだけ ② タイトルの後・最初のセクションの前に「> 」の要約がある ③ 「## 」のセクションが 1 つ以上ある ④ セクションの中に Markdown のリンクの箇条書き（「- [名前](URL)」。後ろに「: 説明」可）がある ⑤ セクションの中の箇条書きがすべてその形で、URL として読める。タイトルを含めて 4 つ以上=1、それ以外=0（2〜3 つは警告）。llms.txt が無い場合は対象外。 |
| 1-10 | /llms-full.txt の存在 | 1 | ファイル取得 | 存在=1、存在するが 100 文字未満=0（警告）、無し=0。 |
| 1-11 | Content-Signal | 1 | robots.txt 解析 | robots.txt の Content-Signal 行で search・ai-input・ai-train のいずれかに yes / no を指定している（例: 「search=yes, ai-train=no」）=1。行が無い=0、その形の指定が無い=0（警告）、robots.txt が無い=0。サーバーの不調で robots.txt が読めない場合は対象外。 |
参考項目（配点なし）
レポートに表示するために記録しますが、配点は 0 です。参考ボットは配点のあるボットと同じ規則で許可/拒否を判定します。エージェント層の宣言は「妥当」「形だけ（存在するが使えない）」「未公開」の三状態で判定します。 配点なしで記録する参考ボット: ChatGPT-User, Googlebot, bingbot, Perplexity-User, Google-Agent, Applebot。ユーザー起点フェッチ（ChatGPT-User・Perplexity-User・Google-Agent）は人の要求でのみ動作し robots.txt の制御外です。Googlebot・bingbot・Applebot は検索エンジン本体で、ブロックするとその検索結果から消えるため、採点せず状態を記録します。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| — | GPTBot の許可 (学習型) | 参考 | robots.txt 解析 | OpenAI の学習用クローラー。許可（ルール無しを含む）か拒否かを記録しますが、配点はありません（AI の学習に使わせるかは方針の選択）。 |
| — | ClaudeBot の許可 (学習型) | 参考 | robots.txt 解析 | Anthropic の学習用クローラー。許可か拒否かを記録しますが、配点はありません（方針の選択）。 |
| — | Google-Extended の許可 (学習型) | 参考 | robots.txt 解析 | Gemini の学習用トークン。ブロックしても Google 検索には影響しません。許可か拒否かを記録しますが、配点はありません（方針の選択）。 |
| — | Applebot-Extended の許可 (学習型) | 参考 | robots.txt 解析 | Apple Intelligence の学習用トークン。許可か拒否かを記録しますが、配点はありません（方針の選択）。 |
| — | その他の AI クローラー | 参考 | robots.txt 解析 | Meta-ExternalAgent, Amazonbot, Bytespider, CCBot, cohere-ai, Google-CloudVertexBot, DeepSeekBot のいずれも Disallow されていない=問題なし、1 つでも拒否=警告。配点なし — 個別のブロックは不備ではなく方針の選択なので、グループで判定します。 |
| — | Googlebot (検索型) | 参考 | robots.txt 解析 | Google 検索本体。ブロックすると Google 検索から完全に除外されるため、採点せず状態を記録します。 |
| — | bingbot (検索型) | 参考 | robots.txt 解析 | Bing 検索と Microsoft Copilot が同じクローラーを使い、分離できません。参考として記録します。 |
| — | Applebot (検索型) | 参考 | robots.txt 解析 | Apple の検索用クローラー（Siri・Spotlight・Safari）。参考として記録します。学習用途は Applebot-Extended で別に制御します。 |
準拠規格: RFC 9309: Robots Exclusion Protocol · sitemaps.org · Content Signals · llmstxt.org · Model Context Protocol · RFC 9728: OAuth 2.0 Protected Resource Metadata · RFC 9727: api-catalog · OpenAI: Overview of OpenAI crawlers · Anthropic: Does Anthropic crawl data from the web · Google: Overview of Google crawlers and fetchers
2. AI がページを読み取れる？ (29 満点)
人の代わりに来た AI が入れて、ページを読めるか。robots.txt、利用者起点のフェッチャー、そして**サーバーが返す HTML に内容が入っているか**（エージェントは JavaScript を実行しません）。あわせて見出し構造・ランドマーク・画像の代替テキスト・文書の言語・Markdown のコンテントネゴシエーション・公開している API の記述・応答時間を測ります。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| 2-1 | JavaScript 依存度 | 6 | 初期 HTML 解析 | スクリプト実行前にサーバーが返す HTML に本文が入っているか。見える本文（script・style・noscript を除く）が 200 以上（全角 1 字を 2 と数える。日本語で約 100 字）で、外部 script が 10 本未満=6、20 本未満=5、20 本以上=4。本文がそれに届かないとき: 読める文章の noscript の代わりがある=2（タグマネージャーの iframe・画像・「JavaScript を有効にしてください」の定型文は数えない）、本文が少しある（同じ数え方で 40 超）=1、それ以下=0。 |
| 2-2 | 見出し階層 | 5 | HTML 解析 | h1 が無い=0。h1 がちょうど 1 つ=2（複数=1）、h2 がある=+1、h2 に加えて h3 もある=+1、本文の見出しで階層の飛び（h2→h4 など）が無い=+1。ヘッダー・フッター・ナビゲーションの見出しは飛びの判定に入れません。 |
| 2-3 | ランドマーク要素 | 4 | HTML 解析 | main・nav・header・footer（対応する ARIA の role も可）の各存在で 0.8 点、article または section（role="article"・"region" も可）があれば +0.8。合計を整数に四捨五入（上限 4）。 |
| 2-4 | alt 属性の充足率 | 3 | HTML 解析 | img 要素のうち alt 属性を持つものの割合。空の alt="" も正しいと数えます（飾りの画像の正しい書き方）。role="presentation"・"none"、aria-hidden="true"、1×1 の計測用画像は数えません。90% 以上=3、70% 以上=2、50% 以上=1、未満=0。数える画像が無いページは対象外。 |
| 2-5 | robots.txt | 2 | 取得・解析（RFC 9309） | 取得でき 5 文字以上=2、存在するがそれ未満=1。robots.txt が無い（4xx・代わりに HTML のページが返る）=1 — クローラーは全部を取ってよいが、サイトの方針を宣言できない。サーバーの不調（5xx・429・時間切れ・到達不能）=0 — クローラーはサイト全体を取ってはいけないものとして扱う（段 ② が止まる）。この場合は、クローラーごとの項目と Content-Signal を「分からない」として採点から外します。 |
| 2-6 | 言語属性 | 2 | HTML 解析 | html 要素に空でない lang 属性がある=2、無い=0。 |
| 2-7 | Markdown のコンテントネゴシエーション | 2 | Accept ヘッダ検証 | ページの URL を Accept: text/markdown で取得し（サイトのファイルと一緒にサイトごとに 1 回、最初に診断したページで確かめ、ほかのページにもその結果を使います）、text/markdown（または text/x-markdown）が返る=2、HTML などそれ以外・エラー・応答なし=0。 |
| 2-8 | 公開 API の参照 | 2 | 取得＋中身検証 | 機械が読める API の記述が実際に取れるか。候補は <link rel="service-desc"> と、記述らしいパス（openapi.json・swagger.yaml・/v3/api-docs など）か Swagger UI / Redoc のページへのリンクで、2 本まで取得します。Swagger UI / Redoc のページからは、そこに書かれた記述の URL を 1 回だけ追います。OpenAPI 3.x か Swagger 2.0 の記述（JSON か YAML。info 付き）が取れた、または /.well-known/api-catalog（RFC 9727）の linkset に href 付きのリンクが 1 つ以上ある=2。記述らしいリンクが取れない・OpenAPI ではない、または API Catalog がその形でない=0（警告）。どちらも無い場合は対象外（減点なし）。「API」という語や /api へのリンクだけでは数えません。 |
| 2-9 | サーバー応答時間 | 2 | HTTP 計測 | Tooru のクローラーから見た、サーバーが応答し始めるまでの時間（TTFB。転送（リダイレクト）の時間を含む）。本文を受け取る時間は数えないので、遠いサーバーがページの大きさの分だけ損をしません。0.8 秒以内=2、2.5 秒以内=1、超=0。 |
| 2-10 | Claude-User の許可 (エージェント型) | 1 | robots.txt 解析 | Anthropic のユーザー起点フェッチ（利用者の指示で Claude がページを訪れる）が Disallow されていないこと。許可またはルール無し=1、拒否=0。robots.txt が無ければ許可と同じ。サーバーの不調で robots.txt が読めない場合は対象外。 |
参考項目（配点なし）
レポートに表示するために記録しますが、配点は 0 です。参考ボットは配点のあるボットと同じ規則で許可/拒否を判定します。エージェント層の宣言は「妥当」「形だけ（存在するが使えない）」「未公開」の三状態で判定します。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| — | ChatGPT-User (エージェント型) | 参考 | robots.txt 解析 | OpenAI のユーザー起点フェッチ。利用者の明示的な要求でのみ動作し robots.txt に従わないため、許可/拒否の状態を記録しますが、改善アクションは取れません。 |
| — | Perplexity-User (エージェント型) | 参考 | robots.txt 解析 | Perplexity のユーザー起点フェッチ。利用者の明示的な要求でのみ動作し、robots.txt では制御できません。参考として記録します。 |
| — | Google-Agent (エージェント型) | 参考 | robots.txt 解析 | Gemini Agent などが利用者の指示でサイトを訪れる際の User-Agent（2026 年 3 月に Google の公式クローラー一覧へ追加）。robots.txt では制御できません。参考として記録します。 |
| — | WebMCP Declarative API | 参考 | HTML 解析 | toolname と tooldescription の両属性を持つ form 要素（W3C WebML Community Group Draft・Chrome 149+ origin trial）。両属性が空でない form が 1 つ以上=妥当、片方だけ=形だけ（ツールとして登録されない）、無し=未公開。命令的な JavaScript API はクローラーがスクリプトを実行しないため判定しません。 |
| — | A2A Agent Card | 参考 | 取得＋中身検証 | /.well-known/agent-card.json（A2A Protocol 1.0）。空でない name と、url または空でない interfaces 配列を持つ JSON オブジェクト=妥当。取得できるがそれを満たさない=形だけ。未公開=未公開。 |
| — | UCP プロファイル | 参考 | 取得＋中身検証 | /.well-known/ucp（Universal Commerce Protocol・2026-08-25 版）。YYYY-MM-DD 形式の version と services・payment_handlers を持つ ucp オブジェクト=妥当。取得できるがそれを満たさない=形だけ。未公開=未公開。keys 配列は現段階では要求しません。 |
| — | クローラーへの配信 | 参考 | HTTP 取得（2 つの User-Agent） | Tooru のクローラー（User-Agent「TooruBot」）にページが配信されるか。401/403/406/429 かボット対策のチャレンジが返ったときだけ、所有確認済みのドメインに限り、同じ URL をブラウザの User-Agent でもう一度取得します。ブラウザにだけ配信=クローラーを User-Agent で拒否している（段 ② が止まる）。両方拒否、または所有確認していないドメインで拒否=診断できず、実行結果に理由を出します。配点なし。 サーバーの TLS の設定に不備があり（中間証明書を送らない・安全な再交渉に対応しない・弱い鍵交換を選ぶ）、ブラウザと同じ水準で補って読めたときは、点に入れない注意として伝えます（一部の AI クローラーは読めない可能性があるため）。 |
準拠規格: HTML Living Standard (WHATWG) · RFC 9309: Robots Exclusion Protocol · Anthropic: Does Anthropic crawl data from the web · WebMCP (W3C WebML CG Draft) · A2A Protocol · Universal Commerce Protocol
3. 会社のことが AI に伝わる？ (38 満点)
AI が「何の会社か」を掴めるか。ページの冒頭で「何を・誰に・どこで」が分かること、組織を同定できる構造化データ（所在地・連絡先・外部参照）、Schema.org のタイプ・プロパティ値・Open Graph メタデータを測ります。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| 3-1 | JSON-LD の存在 | 5 | HTML 解析 | パースできる script[type="application/ld+json"] が 1 つ以上=5。壊れたものが混じる=3（注意。壊れた分は AI に渡りません）。あるが全部壊れている=0（「壊れている」と表示）。FAQPage / QAPage だけ=0（注意。FAQ だけでは誰の何のページかが伝わりません）。無し=0。最上位の配列・@graph・入れ子の実体も読み、コメントや CDATA で包んだものも読みます。パースできる JSON-LD が無いときは、Schema.org タイプ・エンティティの相互接続・必須プロパティ・値の形式を対象外にし、JSON-LD が無い損を 1 回だけにします。 |
| 3-2 | Schema.org タイプ | 5 | JSON-LD 解析 | タイプは Schema.org の階層で認識し（Corporation や Dentist は Organization、NewsArticle は Article として数える）、ページの種類ごとに見ます。トップ: Organization 系=3、WebSite=2（どちらも無くほかの型だけ=1）。記事: Article 系=3、その author と publisher が Person / Organization の実体ならそれぞれ +1（@id の参照も解決）。Article 系が無ければ「その他」の基準で最大 2。FAQ: FAQPage / QAPage の質問がすべて name と答えの text を持ち、少なくとも 1 つが見える本文にある=5、そうでなければ「その他」の基準。その他: ページの中身を表す型（Product・Service・Event・AboutPage・Article など）=5、サイト共通の型（Organization 系・WebSite）だけ=3、汎用の型（WebPage・BreadcrumbList・ImageObject など）だけ=1。FAQPage / QAPage は中身の型に数えません。パースできる JSON-LD が無い場合と、FAQ の型だけの場合は対象外。 |
| 3-3 | プロパティ値の形式妥当性 | 3 | JSON-LD 値検証 | 最上位の実体（と publisher の logo）にある値の形式を検証します。datePublished・dateModified・startDate・endDate・uploadDate は実在する日付の ISO 8601（秒と時差のコロンは省略可）、url は絶対 URL、image・logo は絶対 URL か、絶対 URL の url / contentUrl を持つ ImageObject、inLanguage は BCP 47 タグ（大文字小文字は問わない。en-us・zh-Hant-TW・es-419 など）、headline は空でないこと、author は空でない名前か、name 付きの Person / Organization。@id の参照はページの中で解決し、解決できないものは数えません。妥当率 95% 以上=3、80% 以上=2、50% 以上=1、未満=0。検証する値が無い場合と、パースできる JSON-LD が無い場合は対象外。 |
| 3-4 | エンティティの相互接続 | 3 | JSON-LD 解析 | @graph の使用=+1。参照（{"@id": …}。入れ子や配列の中も含む）がページ内の別の実体の @id を指している=+2、@id はあるがそうした参照が無い=+1。パースできる JSON-LD が無い場合と、FAQ の型だけの場合は対象外。 |
| 3-5 | 組織の同定 | 3 | JSON-LD 検証 | Organization 系の実体（Corporation・LocalBusiness とその下位型・NGO など。入れ子や参照も含む）に、所在地（addressLocality または addressRegion。文字列の住所も可）・電話または contactPoint・外部プロフィールへの sameAs があるかで各 1 点。トップページで Organization 系の実体が 1 つも無い=0（不合格。サイトの入口で「誰のサイトか」を宣言していないこと自体が問題です）。トップ以外のページは対象外です（組織の宣言はトップページで問います）。必須プロパティの項目とは役割が違います — あちらは「型ごとの必須が埋まっているか」、ここは「同名の別会社と区別できるか」です。 |
| 3-6 | 必須プロパティの充足度 | 2 | JSON-LD 解析 | タイプ別の必須プロパティの充足率。最上位の実体だけを見て、Schema.org の階層で最も近い型の定義を使います。Article・BlogPosting（と下位型）は headline・image・datePublished・author、FAQPage・QAPage は mainEntity と、すべての質問に name と答えの text があるか（2 件として数える）、BreadcrumbList は itemListElement、WebPage は name、WebSite は name と url、LocalBusiness は name と address、Organization は name と url、Product・Person は name。入れ子の実体（publisher など）には求めません。90% 以上=2、50% 以上=1、未満=0。これらの型が最上位に無い場合と、パースできる JSON-LD が無い場合は対象外（減点なし）。 |
| 3-7 | Open Graph メタデータ | 2 | メタタグ解析 | og:title・og:description・og:image・og:url の 4 つ全て=2、2 つ以上（または 1 つ＋twitter:card）=1、それ以下=0。 |
| 3-8 | 事業の明示 | 3 | タイトル・説明文・h1・本文の冒頭 | トップページだけで問います（ほかのページは対象外）。タイトル・メタ説明文・本文の h1・本文の冒頭（表示幅 600。日本語で約 300 字。ナビゲーション・ヘッダー・フッターは除く）に「何を」「誰に」「どこで」が書かれているかで各 1 点。日本語のページは日本語の語彙で、ほかのページは英語の語彙（単語の区切りで照合）で見ます。場所が書かれておらず、オンラインで完結する事業と読める語（クラウド・SaaS・アプリ など）がある場合は、「何を」「誰に」の 2 つで満点にします。AI はページの冒頭から読むので、ここで事業が分からないと構造化データでは補えません。 |
| 3-9 | タイトル | 3 | メタタグ解析 | head の title 要素がある=1（SVG アイコンの title は読まない）、表示幅 20〜120（全角 1 字を 2 と数える。日本語で約 10〜60 字、英語で 20〜120 字）=+1、汎用語だけ（home・index・top・welcome・untitled・document・page・ホーム・トップ など）でない=+1。無し=0。 |
| 3-10 | メタディスクリプション | 3 | メタタグ解析 | meta[name="description"]（大文字小文字は問わない）がある=1、表示幅 50〜99 か 321〜480=2、100〜320（日本語で約 50〜160 字、英語で 100〜320 字）=3。無し=0。 |
| 3-11 | 情報構造の明確性 | 3 | コンテンツ構造解析 | h2/h3 見出しのうち、中身が続くものの割合。見出しから同じか上の階層の次の見出しまでの文字（h4〜h6 の下の文字も含む）が、日本語のページで 40・ほかのページで 60 以上（全角 1 字を 2 と数える。日本語で約 20 字、英語で約 60 字）なら中身ありとします。ナビゲーション・サイトのヘッダー・フッター・サイドバー・パンくずの見出しは数えません。70% 以上=3、40% 以上=2、それ未満は見出しが 2 つ以上なら 1・1 つなら 0、h2/h3 が無い=0。 |
| 3-12 | 内部リンク | 3 | リンク解析 | 同じサイトのページへのリンクの数。転送後の URL を基準に解決し、登録ドメインで比べます（www やほかのサブドメインも同じサイト）。#・javascript:・mailto:・tel: のリンクは数えません。10 件以上=3、5 件以上=2、1 件以上=1、無し=0。 |
参考項目（配点なし）
レポートに表示するために記録しますが、配点は 0 です。参考ボットは配点のあるボットと同じ規則で許可/拒否を判定します。エージェント層の宣言は「妥当」「形だけ（存在するが使えない）」「未公開」の三状態で判定します。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| — | 構造化データと本文の整合 | 参考 | JSON-LD × 本文 | 構造化データの値が本文にも書かれているかを突き合わせます。社名（Organization の name・legalName・alternateName のどれか 1 つが本文にあれば一致。株式会社・(株)・Inc. などの法人格と空白は無視）、電話番号（telephone。括弧・ハイフン・全角・+81 を吸収）、住所（PostalAddress の postalCode・addressLocality・streetAddress。〒・丁目・番地の表記を吸収）、営業時間（openingHours / openingHoursSpecification。「10:00〜18:00」と「10時から18時」を同じ時間帯として比較）、価格（Offer の price・lowPrice・highPrice。¥・円・カンマ・税込表記を無視）。社名は常に比べます。それ以外は、本文に同じ種類の値が 1 つも無いページではその種類を比べません（全ページ共通の Organization を、住所の無いページで「欠け」とは言いません）。逆方向は、本文にある電話番号・郵便番号・価格が構造化データに無い場合と、FAQPage / QAPage の質問が見える本文に無い場合を指摘します。現在は指摘のみで配点なし。採点への組み込みは engine の版を次に上げるときに判断します。 |
準拠規格: Schema.org · Google Search Central: Structured data · The Open Graph protocol · Google Search Central
4. AI が答えに使ってくれる？ (14 満点)
AI が答えに使う根拠がページにあるか。単位付きの具体的な数字、出典と引用、答えの形（問い・定義・手順・比較）、著者と日付、更新の新しさを測ります。生成エンジンの研究（Aggarwal et al., KDD 2024）で、引用される頻度を上げると確認されたのがこれらです。出典・著者と日付は記事のページで、Q&A と答えの形は記事と FAQ のページで問います。
| # | チェック項目 | 配点 | 判定方法 | 判定基準 |
|---|---|---|---|---|
| 4-1 | 具体性 | 3 | 本文解析 | トップページと記事のページだけで問います（ほかのページは対象外。あいさつ・理念・一覧・問い合わせなどは数字を書く性質ではないため）。本文（ナビゲーション・ヘッダー・フッター・パンくずを除く）にある単位付きの数字の件数。先に日付と時刻を取り除くので、「2026年10月11日」などは数えません。通貨記号（$・€・£・¥）と % はどのページでも数え、英語の単位（years・customers・million・kg など）は単語の区切りで照合し、日本語の単位（円・年間・ヶ月・件・社・名・人・倍 など）は日本語のページだけで数えます。10 件以上=3、5 件以上=2、1 件以上=1、無し=0。固有名詞は数えません。生成エンジンの研究（Aggarwal ら「GEO」KDD 2024）では、統計を加えるなどの手法で、AI の回答の中での見え方が最大 40% 上がったと報告されています。 |
| 4-2 | FAQ / Q&A コンテンツ | 3 | 目に見える Q&A の解析 | FAQ と記事のページだけで問います（ほかのページは対象外）。目に見える問いと答えの組を数えます。問いの形の dt とその後の dd、summary が問いの形の details、問いの形の見出しとその下の文章のいずれかです。記事のページでは、問いの形の見出しは FAQ の区画（「よくあるご質問」などの見出しの下）の中だけを数えます（記事の本文の問いの形の見出しは「答えの形」で見ます）。関連記事の一覧のタイトル（全部がリンクの文字）は数えません。答えは 20 以上（全角 1 字を 2 と数える）が必要です。問いの形とは、「？」で終わる、Q・Q1・Ｑ や疑問詞で始まる、「ですか」「ますか」などで終わる文です。ナビゲーションやフッターの中は数えません。組が 2 つ以上=2、5 つ以上か、2 つ以上でページに FAQ の見出し（FAQ・よくあるご質問・Q&A など）がある=3、組が 1 つ、または FAQ の見出しはあるが組が読めない=1、無し=0。FAQPage の構造化データだけではここの点になりません（正しさと本文との一致は構造化データの項目で見ます）。 |
| 4-3 | 著者情報・日付 | 3 | メタデータ・本文解析 | 記事のページだけで問います（ほかのページは対象外）。著者（meta author・JSON-LD の author・rel="author"）=+1、公開日（datePublished・datetime 付き time 要素・article:published_time）=+1、更新日（dateModified・article:modified_time）=+1。 |
| 4-4 | 答えの形 | 2 | HTML 構造解析 | FAQ と記事のページだけで問います（ほかのページは対象外）。問いの形の h2〜h4 見出しが 2 つ以上（「？」で終わるもの。日本語のページでは「とは」「の違い」「比較」「手順」「選び方」「メリット」など、英語のページでは how to・what is・vs・comparison など）で 1 点、2 項目以上の定義リスト・3 項目以上の番号付きリスト・見出しセル（th）があり 2 列以上の表のいずれかで 1 点。ナビゲーション・ヘッダー・フッター・サイドバー・パンくずの中は数えません。これらの塊は、そのまま回答に取り出しやすい形です。 |
| 4-5 | 根拠と出典 | 2 | リンク・マークアップ解析 | 記事のページだけで問います（ほかのページは対象外）。ほかのサイト（登録ドメインで比べる）へのリンクのうち、リンクテキストか前後の文で出典を示している（出典・参考文献・引用元・source・according to など。「open source」「source code」は除く）もので 1 点、blockquote・cite・q 要素で 1 点。ナビゲーション・ヘッダー・フッター・サイドバーの中は数えません。出典を示すと、読み手も AI も主張の出どころを確かめられます。 |
| 4-6 | 更新の新しさ | 1 | 日付の抽出 | 構造化データの dateModified・datetime 付きの time 要素・article:modified_time・meta last-modified のうち、ISO 形式で読める最新の日付（イベントの開催日のような未来の日付は除く）。診断時点から 12 か月以内=1、それより古い=0。日付が読み取れない場合は対象外 — 著者情報・日付の項目が既に欠落を測っているので、二重に引きません。 |
準拠規格: GEO: Generative Engine Optimization (Aggarwal et al., KDD 2024) · Google Search Central · Schema.org
AI エージェント対応サマリー
レポートの冒頭には「AI エージェントはこのページに来られるか、案内を見つけられるか」に答えるサマリーを置いています。上の項目から導出するもので、点を足したり変えたりはしません。
- 総合判定
- 来られない — エージェント型または検索型のボットが robots.txt で拒否されている、またはサーバーの不調で robots.txt が読めない（robots.txt が無いだけなら来られます）。エージェントが入れるようになるまで、他は意味を持ちません。
- 一部 — 来られるが、見つけてもらう層に欠けがある（llms.txt が無い、使える MCP サーバーの宣言が無い、Markdown のコンテントネゴシエーションが無い）。
- 対応済み — 来られて、案内もある。
- 最初に直す場所
- サマリーは詰まる場所を 1 つだけ示します。確かめる順番は、先にエージェントが来られなくなるもの（ボットの拒否・robots.txt の破損）、次に案内の欠けで、エージェント型ボットの拒否 → robots.txt の破損 → 検索型ボットの拒否 → llms.txt 無し → 使える MCP サーバーの宣言無し → Markdown ネゴシエーション無し、です。
- ボット種別ごとの到達
- 到達はボットの分類（検索型・学習型・エージェント型）ごとに、個別のボット項目から示します。robots.txt に従わないボットには印を付け、設定では制御できないことが分かるようにしています。
準拠規格一覧
評価項目の根拠とした規格と公式ドキュメントです。
- 1. AI に見つけてもらえる？
- 2. AI がページを読み取れる？
- 3. 会社のことが AI に伝わる？
測定の技術的制約
本診断で見えるもの・見えないものです。
- 測定対象
- 公開 HTTPS で到達できるページだけを測定します。Basic 認証・IP 制限・ログインの先にあるページは診断できません。
- クローラーはサーバーが返す HTML を読み、JavaScript を実行しません。スクリプトだけで描画されるコンテンツは見えません。これは多くの AI クローラーが見ている姿と同じです。
- 各項目は Tooru のクローラー（User-Agent「TooruBot」）に配信されたページで判定します。クライアントごとに異なる内容を返すページは、人が見る姿と点数が異なることがあります。クローラーが拒否されたとき（401/403/406/429 かボット対策のチャレンジ）は、「クローラーを User-Agent で拒否している」と「非ブラウザ全般を拒否している」を切り分けるために、同じ URL をブラウザの User-Agent で 1 回だけ取り直します。
- 測定精度
- robots.txt は RFC 9309 準拠のパーサーで解釈します。示せるのはファイルの宣言内容で、サーバーや CDN が実際に何を通しているかではありません。
- エッジ側のボット管理（CDN が AI エージェントにチャレンジや遮断を行う設定など）は robots.txt には現れません。robots.txt で許可していても、エッジで遮断されていることがあります。Tooru が検出できるのは、自分のクローラーの取得そのものが拒否・チャレンジされた場合だけで、通した上で応答を変える設定は見えません。
- 構造化データの「適切性」は Schema.org の型定義に対する機械的な判定で、ビジネス上の最適性を評価するものではありません。
- コンテンツ品質の一部項目（情報構造・FAQ 検出・著者と日付）はパターンマッチによる判定で、慣習から外れたマークアップを取りこぼすことがあります。
- 測定のタイミング
- 結果はキャッシュしません。実行ごとにジョブの時点でページを取得し直し、ページ単位でクレジットを消費します。
- サーバー応答時間は測定時点のネットワーク状況に依存し、実行ごとに変動することがあります。
- 大きなジョブは分割して処理するため、同じジョブ内のページでも測定時刻が数分ずれることがあります。
- スコアの位置づけ
- スコアは公開された技術規格への準拠度を測る指標で、ビジネス上の成果を保証するものではありません。
- 各 AI プラットフォームがコンテンツをどう取得・順位付け・引用するかは各社が決めており、本評価基準とは独立しています。
- 参考項目はスコアに影響しません。広く普及する前の新しい規格をレポートで示すために記録しています。
バージョン履歴
| バージョン | 日付 | 変更内容 |
|---|---|---|
| v3.0 | 2026-10-11 | 約 6,400 社のサイトの観測をもとに判定を見直しました。そのページに当てはまらない項目（確かめる構造化データが無い・記事ではない など）は、減点として数えず、段ごとに当てはまる項目だけで採点します。FAQ・答えの形・出典・著者と日付は記事と FAQ のページで、組織の宣言・事業の明示・フィードはトップページで問います。FAQ は FAQPage の宣言だけでなく、目に見える問いと答えの中身で評価します。本文の比率の項目はやめ、その 3 点を JavaScript に頼らない読みやすさ（+2）と見出しの構造（+1）に移しました。robots.txt が無いことを「壊れている」と判定していた誤り（無いのは全部許可の意味）、robots.txt で宣言したサイトマップを見落としていた誤り、Google タグマネージャーの noscript を本文と数えていた誤り、語彙が日本語だけで英語のページが低く出ていた偏りなどを直しました。MCP の宣言は、宣言にあるサーバーに実際につないで確かめます。エンジンの版は 3.0.0。 |
| v2.0 | 2026-10-09 | 18 項目の判定の説明を、エンジンの実際の動きに合わせて訂正しました（llms.txt の配点、内部リンク、本文の構造、構造化データの値、ブラウザの User-Agent で取り直す条件など）。項目・しきい値・配点は変えていません。 |
| v2.0 | 2026-09-08 | 採点の単位を、5 カテゴリ × 各 20 点から、AI が答えに使うまでにページが満たす 4 つの条件（見つけてもらえる 19・読み取れる 29・伝わる 38・使われる 14）に組み直しました。配点を根拠に合わせ、llms.txt の項目を小さくし、AI の学習用ボットを許可するかは配点しない「方針」にしました。事業の明示・組織の同定・具体性・根拠と出典・答えの形・鮮度の 6 項目を追加。エンジンの版は 2.0.0。 |
| v1.0 | 2026-09-05 | Tooru 初版。untype.jp の AI 診断（V1）の評価基準 v2.3（2026-06-05）の 39 項目と配点をそのまま継承し、エージェント層の参考項目 3 つ（WebMCP Declarative API・A2A Agent Card・UCP プロファイル）と、AI エージェント対応サマリーの判定規則を追加。V1 の評価基準は凍結し、以後の変更は本ページで行います。 |
評価基準は AI エージェント関連の規格の進展に応じて改訂します。変更は本ページで告知し、バージョン番号を更新します。配点のある項目と配点は、過去の点と比べられるよう、Tooru の診断をバージョンアップするときにまとめて変えます。
フィードバック
技術的な誤りの指摘、新しい規格への対応要望、配点バランスへのご意見は support@tooru.ai までお寄せください。件名に「評価基準」と書いていただけると助かります。