コンテンツにスキップ

Public Experiment Log #2: 外部ベースラインパネル

Public Experiment Log の第1回は、私たちが所有する 6 サイトをスコアリングした。6 つとも 90 以上だった。これは何かの証明として機能するには too clean だと正直に書いた。今回の第2回は、第1回が提供できなかったキャリブレーションそのもの: 私たちが所有していないハイトラフィックの技術系サイト 39 本を、同じツールで、同日に測ったパネル。

見出しの発見は地味で、見出しの発見は uncomfortable でもある。地味なほう: 中央値は 61、標準偏差 19.5 — 「良い」よりかなり下にセンターがある、見た目通常の分布。uncomfortable なほう: モダンな web で最も訪問されているドキュメントポータルのうち 3 つ — rust-lang.orgtailwindcss.comdjangoproject.com — が 40 を下回っている。

40 URL のパネルを 3 カテゴリにまたがるように選んだ: 開発者向けドキュメント (20)、製品マーケティングサイト (12)、エンジニアブログ (6)。さらに別枠の「AI プロバイダーのドキュメント」サニティチェックペアとして 2 つ (docs.anthropic.complatform.openai.com/docs/) を加えた。選定は測定実行の前に確定し、スコアに基づいて URL を追加・削除することはしていない。

40 URL を llmo-checker@0.1.0 で 1 バッチ実行、リクエスト間 1 秒の delay つきで測定した。1 URL (platform.openai.com/docs/) はパースエラーを返したのでドロップし、n = 39 となった。

すべてのリクエストで同じ User-Agent (llmo-checker/0.1.0) を使った。これは、私たちの推奨に従う AI クローラーが実際に送るものと一致する。どのサイトも再試行はしていない。最初の測定をそのまま採用する。

StatisticValue
n39
Mean58.8
Median61
Stdev19.5
Q1 / Q345 / 69
Min / Max23 / 94
20-29 ███ 3
30-39 ████ 4
40-49 █████████ 9
50-59 ██ 2
60-69 ████████████ 12
70-79 █ 1
80-89 █████ 5
90-99 ███ 3

分布はおおむね bimodal だ: 1 つは 40〜49 のクラスタ (machine-readability の弱い early-to-mid-tier サイト)、もう 1 つはより大きな 60〜69 のクラスタ (大半は埋まっているが jsonldllms.txt が欠けている mid-tier サイト)。

#SiteScore
1supabase.com94
2redis.io93
2www.cloudflare.com93
4stripe.com89
5docs.docker.com84
#SiteScore
39www.rust-lang.org23
38tailwindcss.com25
37www.djangoproject.com26
36www.postgresql.org32
35golang.org37
CategorynMedianMeanRange
Product marketing1268.574.858–94
Dev blog665.065.344–80
Documentation2045.548.023–93
CheckMedianMeanRange
llms-txt9054.90–100
robots-ai8078.760–100
canonical9067.90–100
jsonld026.10–94
meta8078.50–100

ドキュメントサイトが最弱カテゴリだった。 事前に予想を問われていたら、私たちはこの予測を外していた。デフォルトの想定は — データが届く前の私たち自身も含めて — docs ポータルこそが 最強 カテゴリのはずだった。人間にも検索エンジンにも長年キュレーションされた authoritative source であり続けてきたからだ。データはその逆を言う: ドキュメントの中央値スコア (45.5) は、製品マーケティングの中央値 (68.5) より 20 点以上下にある。ドキュメントポータルは広く愛され、成熟し、人間向けに作り込まれているが、同じチームが平均としては machine-readable な表層に投資してこなかった。

schema.org のフロアは非常に低い。 パネルの jsonld 中央値は 0。これらの有名な技術サイトのうち半数以上が、認識可能な JSON-LD @type を 1 つも出していない。平均は、ごく一部のよく計装されたサイト (大半は製品マーケティング) によって 26 まで引き上げられている。jsonld スコアが 0 だからといってサイトが壊れているわけではない — AI クローラーが引用の根拠 (entity-graph) を置く表層がないということだ。

llms.txt は段階的ではなく bimodal。 中央値は 90、平均は 54.9。サイトは spec 準拠の /llms.txt に投資しているか (きれいな 90 台と 100)、ファイル自体がないか (0) のどちらかで、真ん中に座っているサイトはほとんどない。これは、llms-txt で 0 → 90+ に上げるコストが 1 ファイルのコミットであって、多段階移行ではないということ。

最下位 3 つは誰でも知っているブランド。 rust-lang.org (23)、tailwindcss.com (25)、djangoproject.com (26) はパネル全体で最も低いスコアの URL だ。同時に、どんな常識的なトラフィック推定でも web 上で最も訪問されている開発者向け URL のグループに入る。スコアはトラフィックでもブランド認知でもコンテンツ品質でもない、AI クローラーがそのページのメタデータに引用の根拠を置けるかどうかを測っている — そしてその 1 軸だけで見れば、この 3 つが底にいる。

Cloudflare 系列は 3 URL で 93 / 64 / 44 とばらつく。 www.cloudflare.com (93) はトップの製品ページ、www.cloudflare.com/blog/ (64) はブログインデックス、blog.cloudflare.com (44) はブログのサブドメインフロントエンド。同じエンジニアリング組織、3 つの異なる表層、50 点のスプレッド。マルチサイト組織はだいたいこのくらい不均等で、私たち自身のポートフォリオもそれを確認している (v1.5.1 の Experiment Log で私たち自身の 90–99 vs 96 vs 94 のスプレッドを既に記録した)。

私たち所有のサイトはどこに位置するか

Section titled “私たち所有のサイトはどこに位置するか”

第1回 Experiment Log では私たち所有の 6 サイトを 93〜99 でスコアリングした。単独で見るとこれは uncomfortable に高く見えた。今は context がある:

SiteScorePanel percentile (approx.)
llmoframework.com99> 99th
kenimoto.dev99> 99th
kaoriq.com96> 95th
propel-lab.co.jp96> 95th
mypcrig.com93> 90th (supabase.com および redis.io と同点)
legacydram.com(今回は再測定していない)

これにより、私たち所有のサイトは 39 サイトのハイトラフィック技術系パネルの最上位に位置する。これは私たちのコンテンツが rust-lang.orgstripe.com より優れていることを意味しない。スコアがターゲットとしている同じ 5 つの機械的なチェックを、私たちが測定し続け修正し続けてきたということだ — 自作ツールが楽にすべき作業そのもの。

これが第1回ログに欠けていたキャリブレーションだ。私たちが座っている 90+ クラスタは普通ではない。machine-readable な表層を狙って最適化することを決めたサイトたちのクラスタで、このパネル上ではその決定が、最上位の小さなグループと 40〜69 帯の long tail とを分けている。

それでもまだ証明できていないこと

Section titled “それでもまだ証明できていないこと”

スコアは内部整合している (Experiment Log #1 の Update で、修正が spec の予測する delta を生むことを確認済み)。スコアは今や外部パネルとの比較対象も持っている。しかしこの 2 つの事実は、スコアが高いほど AI 引用率が高くなる 原因 であることを証明したものとは別物だ。

そこは依然として Experiment Log #3 (引用相関パイロット) の仕事になる。スコア帯全域にまたがる 50 URL — 今回パネルの bottom 5 と top 5 の一部を含む — について、LLMO Score と実際の AI 引用率 (Perplexity API + ChatGPT search + Claude web tool) を比較する。スコアが本物なら、いずれが信頼できるソースになり得るクエリで、このパネルの bottom 5 は top 5 より顕著に少なくしか引用されないはずだ。

この Update を honest に書くとこうなる: スコアは、測定ツールが通らなければならない 3 つのテストのうち 2 つを今や通過した。内部整合性 (v1.5.2 Update)、そして信頼できる外部パネルに対して非フラットな分布を生むこと (このログ)。3 つ目のテスト — スコアが主張している outcome を実際に予測するか — が、プロジェクトを続ける価値があるかを決める。

パネルは小さく (n = 39)、英語サイトだけだ。日本語・中国語・ドイツ語・フランス語のサイトは入っていない — 第1回パネルをフォーカスさせるための意図的な選択だが、クロス言語キャリブレーションには実際の制約だ。

カテゴリ分割は不均等: docs 20、製品マーケティング 12、開発ブログ 6。これによりカテゴリ別中央値は方向性を示すには十分だが、統計的にタイトとは言えない (特に n = 6 の Dev blogs)。

選定は私たちが測定実行前に行った。「弱いサイトを cherry-pick した」という反論を最小化するため、有名でハイトラフィックの技術系 URL を優先したつもりだが、selection bias を排除はできない。raw な URL リストはこの post と並んでコミットしている (experiments/external-baseline-2026-05/urls.txt) ので、パネルは再現も拡張も可能。

platform.openai.com/docs/ は、checker がパース可能な JSON を返さなかったためドロップした。これは 1 件の survivorship bias であり、AI プロバイダー docs の比較は 2 点揃っていた方が 1 点 (docs.anthropic.com は 64) だけより interesting だった。

Terminal window
git clone https://github.com/open-llmo/llmo-checker
cd llmo-checker
npm install && npm run build
# URL リストと実行スクリプトを取得
cd experiments/external-baseline-2026-05
cat urls.txt # 40 URLs
bash run-measurements.sh # results/*.json を生成
python3 analyze.py # 上記サマリを出力

raw な results/*.json ファイルもコミット済み。同じ URL に対して llmo-checker@0.1.0 で走らせれば、この post のスコアの ±1 以内には収まるはず (サイトは実行間で変わる; 新しい <meta> タグ 1 つで meta は 10 動き得る)。

ロードマップは Experiment Log #1 の締めから変わらない:

  • Experiment Log #3 — 引用相関パイロット。 スコア帯にまたがる約 50 URL について、Perplexity / ChatGPT / Claude に同じクエリセットでプローブをかけ、LLMO Score と引用率の相関を計算する。これが本当の検証だ: スコアは自分が主張する outcome を予測するか?
  • v0.2 のスコア重み。 引用相関データが期待通りに着地したら、観測された相関を最大化するように per-check 重みを再チューニングする。期待通りに来なかった場合は、spec はもっと面白いフォローアップ post を持つことになる。

全ロードマップは Experimental Projects を参照。v0.1 スコアの重み定義は Score v0.1 Draft Specification にある。