LCRS 6回連続0%の現在地 — 測定エラーから真因解明までの24時間と、AIに引用されないサイトの共通点

あなたのサイトの記事は、ChatGPT や Perplexity で何回引用されていますか? 当サイトの答えは 6 週間連続でゼロ。WEB ディレクターを応援するサイトを名乗る僕たち自身が、AI 検索の引用ソースから完全に外れている。今日はその 6 週間の正直な記録と、6 回目を測ろうとして測定システムが落ちた話、仲間が 24 時間以内に真因を突き止めて修復してくれた話を、WEB ディレクターのために残す。

「AI 引用率を測れる時代」が来た。Bing が 2026 年 2 月に AI Performance を完全無料で公開し、Princeton GEO 研究は引用率を最大 +115% 押し上げる手法を 9 つ特定した。だが 測れることと、引用されることは別だ。今日はその間にある「現場のリアル」を、6 週連続 0% の当事者として、隠さずに開示する。

1. あなたのサイトは、AI に引用されているか

2026 年、ChatGPT は週間アクティブユーザー 4 億人超、Perplexity は月間 1.5 億クエリ、Google AI Mode は米国全土で展開され、検索体験そのものが 「リンクをクリックする」から「AI が引用したサマリーを読む」に切り替わった。

この変化に対する WEB ディレクターの本当の指標は、Google での検索順位ではなく 「AI に引用される率」だ。Lily Ray は次の一文で時代を要約した:

LLM 引用の 44.2% は、記事の冒頭 30% から取られている。

あなたのサイトの記事冒頭 30% は、AI に引用される設計になっているか? その答えを 数字で持っている WEB ディレクターは、まだ多くない。

当サイトの答えを先に書く: LCRS = 0%、6 週間連続。WEB ディレクターを応援するサイトを名乗る僕たちが、AI に見つけてもらえていない。今日は、その事実をどう測ったか、どう向き合ったか、そして 6 回目を測ろうとした時に何が起きたかを、すべて開示する。

先に結論だけ書く。AI に引用されないサイトには、5 つの共通点がある。

1. 冒頭 30% に引用可能な定義・数値がない — AI は記事冒頭から情報を取得する。定義・統計・結論が冒頭に来ていないと、スキャンで終わる
2. 出典 URL を本文中に明示していない — Princeton GEO 研究では「Cite Sources」が引用率 +115% を記録している。出典なしは AI から信頼されにくい
3. 専門家・研究の直接引用がない — AI は「誰が言ったか」を参照する。「〜と言われている」より「〜と Lily Ray が述べた」の方が引用されやすい
4. FAQ schema・構造化データが未整備 — AI は構造化データから引用 URL を特定する。FAQ schema がある記事はない記事より引用率が高い（当サイト AI 対応診断 20 項目のうち最重要の 1 つ）
5. llms.txt でのクローラー許可が明示されていない — AI クローラーへの明示的な許可がないサイトは、88.2% 以上がブロックなしでも引用されているが、許可明示はシグナルとして有効（BuzzStream 400 万件調査）

6 週間 0% の現在地から、この 5 つを 1 つずつ整備していくのが、今日から当サイトが取る方針だ。

2. LCRS とは何か — チームで作った「AI 引用率」の測り方

LCRS は LLM Citation Rate Score（LLM 引用率スコア）の略。チームの仲間 リンゴ（Web Managements 担当）が、ナミオさんの提案を受けて 1 週間で実装してくれた測定 API だ。

仕組みは単純:

• 14 クエリ × 2 AI（ChatGPT + Perplexity）= 28 コール を毎週 1 回実行
• 各クエリで AI が当サイトのページを引用したか判定
• 引用された数 ÷ 28 × 100 = LCRS スコア

この測定の競合は、すでに数社存在する:

サービス	価格	対象層
Profound	$499/月〜	エンタープライズ（MongoDB / Ramp / Figma 顧客）
Otterly	$29-989/月	中堅
llmocheck.ai / yurulica.com / trilia.co.jp	無料〜	国内 SMB 向け
★ Bing Webmaster Tools — AI Performance	完全無料	検証済みサイト所有者全員（2026 年 2 月公開）
当サイト（チーム内製）	RINGO API	チーム 8 人共通基盤、50 クエリ/日上限

「AI 引用率を測る」は、もう 有償ツールに頼らずできる時代に入った。その上で、チーム内製で測れる体制を作っておくと、「今すぐ測りたい」が「来月の請求書を待たずに」できる。これは小さな差のようで、運用の現場では決定的に大きい。

3. なぜ「表示回数・クリック・順位」だけでは AI 時代が見えないのか

当サイトの実データを並べる。Google Search Console の数字:

• 30 日表示回数: 15,525
• 30 日クリック数: 158
• 平均掲載順位: 32.6 位
• インデックス済みページ: 39/39（ブログ）

ところが LCRS は 0%。SC 上では数千の表示があり、ページはちゃんと検索に出ている。でも AI に引用されている記事は 1 本もない。

この乖離は、Loamly の 446K visits 実測でも裏が取れている: AI トラフィックの 70.6% は GA4 で「Direct」扱いになり、referrer が消える。これは Dark AI トラフィックと呼ばれ、サイト管理者の目には映らない。

逆に、AI 検索経由の流入が 来た時のコンバージョン率は破壊的に高い:

AI 検索経由 CV 率 10.21% vs 通常検索 CV 率 2.46%（Loamly 調査、約 4.1 倍）

「順位は人間ユーザーが見た SERP の話、LCRS は AI が引用するソースの話、別物」。両方を別軸で測らないと、AI 時代の WEB 運営は 半分目をつぶって戦っている状態になる。

SC の外で AI 引用率を測る手段は、今日時点で 4 つある:

1. Bing Webmaster Tools — AI Performance（無料）: Bing / Copilot での Total Citations、Grounding Queries が閲覧可能。検証済みサイト所有者なら今日から使える（詳細は Section 6）
2. チーム内製 LCRS API: ChatGPT + Perplexity に直接クエリを投げ、引用の有無を判定。当サイトでは 14 クエリ × 2 AI = 28 コールを週次で定点観測中
3. 当サイト「AI Ron の AI 対応診断」（/ai_check、無料 20 項目）: llms.txt / 構造化データ / FAQ schema など AI 引用されやすい設計の整備状況をスコア化
4. 有償ツール（Profound $499/月〜、Otterly $29-989/月）: エンタープライズ向け、競合比較・定点観測が手厚い

SC が「見えない」部分を、この 4 手段で補完する。すぐできるのは ①Bing WMT と ③AI 対応診断。両方無料で今日から動ける。

4. 当サイト LCRS 6 回連続 0% の正直な記録

2026 年 4 月 14 日に本測定を開始してから、今日 4 月 30 日までの全記録を表で開示する:

回	日付	結果	備考
1	2026-04-14	0/20 (0%)	本測定開始（10 クエリ × 2 AI）
2	2026-04-20	0/28 (0%)	14 クエリ × 2 AI に拡大
3	2026-04-21	0/28 (0%)	fetch スクリプト自作、定点観測体制確立
4	2026-04-24	0/28 (0%)	4 回連続
5	2026-04-26	0/28 (0%)	5 回連続、ベースライン確定
6	2026-04-30	0/28 (0%)	6 回連続、リンゴ修復後の初測定（次章詳細）

「6 週間連続 0%」は、統計的にゼロでない可能性が極めて低いことを意味する。たまたま 0% だったのではなく、構造的に引用されない状態が確定している。この事実から目を逸らさないことが、最初の 1 歩だ。

同じクエリで競合を見ると、llmocheck.ai / yurulica.com / trilia.co.jp などは普通に引用上位に出てくる。AI が引用する素材として、彼らは認識されており、僕たちはまだ認識されていない。

5. 6 回目の測定で起きたこと — 真因解明までの 24 時間

5 回連続 0% を踏んだ翌週、僕は 4 月 29 日朝に 第 6 回測定を走らせた。結果は予想外だった:

fetch スクリプト実行 → 28 コール全件 Internal Server Error 500。

SC pages も SC keywords も 「N/A 件」。「6 回連続 0%」を踏もうとしたら、測定システムそのものが落ちていた。ここから 24 時間のドラマが始まった。WEB ディレクターが現場で同じ状況に遭遇した時に明日から使える方法論として、すべて記録する。

5.1 仮説 4 つで切り分け

仲間のリンゴ（API 開発者）から、4 仮説の切り分けフレームが返ってきた:

仮説	内容
(a) site_url 固有問題	当サイト環境固有の何か
(b) credential / scope	API key スコープ不足
(c) スクリプト書き換えミス	日付コピー時の破壊
(d) サーバー側障害	API 提供側の不具合

僕の側で順次検証 — (b) 否定（scope 7 つ完全）、(c) 否定（diff は文字列置換のみ）、(d) 一部関連の可能性。残ったのは (a) site_url 固有問題。

5.2 速度から層を推定する — エラー速度がエラー層の高さを語る

切り分けの鍵は レスポンス時間だった。リンゴ側 membo の成功と俺の側 usersupports の失敗で、決定的な差があった:

サイト	結果	所要時間	解釈
membo（リンゴ側）	200 OK	8.52 秒	実 AI コール完了
usersupports（当サイト）	500	0.022 秒	AI コール届く前に即死

0.022 秒 = 通常の 2 桁以上速い。これは AI コール段階に 到達すらしていない。認証 / config / 初期化のいずれかで 即時 throw されている速度だ。認証は別 API が 200 で返ってるから OK。残るは config / 初期化。

5.3 リンゴが真因まで降りた — 「呼ぶ先」ではなく「呼ぶ側」だった

僕の「site_url 固有問題濃厚」の見立てを引き取って、リンゴが当サイトの test 環境に SSH して、コード + config + サーバー実体まで降りた。結果:

• ❌ https://website.usersupports.com（site_url、API リクエストの宛先）が固有問題 ではない
• ✅ 当サイト test 環境（base_url 側、API リクエストの発信元）の config 構成欠落が真因

つまり、僕の仮説は 「呼ぶ先」を疑ったが、真因は「呼ぶ側」だった。リクエストの宛先と発信元、両方を視野に入れていなかった。

5.4 真因のシーケンス — config の優先順が引き金だった

リンゴが特定した真因のシーケンス:

1. LcrsService::__construct() で $this->config->get('lcrs') を取得
2. $this->lcrsConfig['enabled'] をチェック
3. enabled = false なら throw new Exception('LCRS service is disabled in config')
4. → ルーター側で general handler が Internal Server Error 500 で返す

0.022 秒で死んでいたのは、ここで Exception throw されていたから。ここで重要になるのが config の優先順:

common.json < config.json < site-settings.json （後者が優先）

• common.json（全プロジェクト共通テンプレ）: lcrs.enabled = false（安全側デフォルト、API key を顧客に投入してもらうまで disabled）
• config.json（プロジェクト個別）: lcrs section なし → 共通テンプレに依存
• site-settings.json（顧客固有データ、ビルドに含まれない）: ここで lcrs.enabled = true + API key を投入して有効化する設計

つまり、当サイトの test 環境には site-settings.json 自体が一度も作られていなかった。だから common.json の enabled: false がそのまま適用され、LCRS は構造的に disabled 状態だった。

5.5 24 時間で修復完了 — チームで作る現場のリアル

リンゴは僕の障害報告を受け取ってから 24 時間以内に、SSH で実体まで降りて site-settings.json 不在を真因確定し、修復し、検証してくれた:

# 修復投入内容
{
  "lcrs": { "enabled": true },
  "openai": { "enabled": true, "api_key": "***" },
  "perplexity": { "enabled": true, "api_key": "***" },
  "daily_query_limit": 200
}

# 検証
$ php -r 'new LcrsService();'
→ LcrsService construct OK

検証完了の連絡を受けて、4 月 30 日朝に第 6 回測定を再開。結果は冒頭の通り 0/28 = 6 回連続 0% 確定。

この 24 時間で、当サイト 1 件の障害をきっかけに、チーム 8 サイト全部の LCRS 設定状態が同時に整理された。当社運用 4 サイト（membo / album-sweet / website-usersupports / tsukurun）は即時動作可能、外部顧客 4 サイトは顧客 API key 取得待ちで disabled で待機。1 つの障害が、チーム全体の運用基盤を整える機会に変わったのは、リンゴの動き方の質の高さによる。

6. 業界の動き — Bing が AI 引用測定を完全無料で公開した

有償ツール時代の話だけ書くと、AI 引用率測定は遠い世界の話に聞こえる。だが 2026 年 2 月、Microsoft が Bing Webmaster Tools に AI Performance を追加した。これが業界の景色を変えた。

• 対象: Microsoft Copilot や Bing AI 要約での Total Citations
• 取得可能データ: Average Cited Pages、Grounding Queries（AI が情報取得に使ったクエリのサンプル）、URL 別引用数
• 料金: 検証済みサイト所有者なら誰でも完全無料

これはつまり、「AI 引用率を測ることに、もう料金は要らない」時代が来たということ。Profound の $499/月、Otterly の $29-989/月を払えない小規模サイトでも、Bing アカウントを作れば今日から測れる。「測れる」は、「戦える」の前提条件だ。

7. ゼロから脱出する 5 つの手順 — Princeton GEO 研究 9 手法から厳選

Princeton 大学の GEO（Generative Engine Optimization）研究は、AI 引用率を上げる 9 手法を実験で特定した。当サイトのような 下位ページ・小規模サイトに効く 5 手法を順位付けして紹介する:

優先度	手法	引用率向上	具体的なやり方
1	Cite Sources	+115%	引用元 URL を本文中に明示。下位ページで最大効果
2	STATistics Addition	+41%	数値データを冒頭 30% に集中配置（Lily Ray 44.2% に対応）
3	Quotation Addition	+28%	専門家の発言を直接引用（Mueller / Lily Ray / Aleyda Solis 等）
4	Information GAin	最重要シグナル	独自データ・実体験。Google March 2026 Core Update 以降、競合差別化として最重要
5	Platform 別最適化	プラットフォーム依存	ChatGPT / Perplexity / AI Mode で引用ソース傾向が違う（次章）

タイムラインの目安: 初引用まで 4-12 週間、90 日でブランド絡み引用率 70% 超到達例も報告されている。当サイトは現在 6 週目、まだベースライン期間内だ。

冒頭 30% を「引用可能な設計」にするための 3 ステップ

Lily Ray の「LLM 引用の 44.2% は記事冒頭 30% から」は、書き方の設計で結果が大きく変わることを示している。当サイトが採用している実装:

1. 最初の 2 段落に「結論 + 数字 + 出典」を置く
   例: 「LCRS = 0%（6 週間連続）。Loamly 調査によれば AI トラフィックの 70.6% は GA4 で Direct 扱いになる。」— AI はここから引用する
2. FAQ schema を記事ページに追加する
   <script type="application/ld+json">{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"LCRSとは何か","acceptedAnswer":{"@type":"Answer","text":"LLM Citation Rate Score。AI検索でのサイト引用率を測定する指標。14クエリ×2AI=28コールで毎週測定する。"}}]}</script>
   FAQ schema がある記事は AI Overview・AI Mode での引用率が構造化データなしと比べて有意に高い
3. llms.txt でクローラーへの許可と優先コンテンツを明示する
   # Allow all AI crawlers
User-agent: GPTBot
Allow: /

# 優先的に参照してほしいページ
Sitemap: https://website.usersupports.com/sitemap.xml
   当サイトの llms.txt は /llms.txt で確認できる

8. プラットフォーム別戦略 — ChatGPT vs Perplexity vs AI Mode

同じ「AI 引用率を上げる」でも、プラットフォーム別に 引用ソース傾向が大きく違う。Evertune の調査データを並べる:

プラットフォーム	主な引用ソース	戦略
ChatGPT	Wikipedia 47.9% / Reddit 11% / ブランドドメイン 44.7%	Wikipedia と連動するエンティティ強化、Reddit での言及獲得
Perplexity	Reddit 24% / Wikipedia 0.8% / ブランドドメイン 28.9%	Reddit コミュニティでの存在感が決定的
Google AI Mode	ブランドドメイン 59.8%（最も高い）	既存 SEO と連動、構造化データ強化

驚くべきデータがもう 1 つある: ChatGPT と Perplexity で両方引用されているドメインは、わずか 11%。これは戦略を プラットフォーム別に分けるべきことを意味する。「全 AI で引用される統一戦略」は幻想で、現場では 主戦場の AI を 1 つ選んで深く対応する判断が要る。

9. あなたのサイトの「AI ベースライン」を、今日測れ

ここまで読んでくれた WEB ディレクターへ、僕からの 第 4 の問いを置く:

あなたのサイトが、ChatGPT / Perplexity / AI Mode で引用された記事は、過去 30 日で何本ありますか?

答えを 「数字で持っている」か。「持っていない」なら、今日それを測ることが、AI 時代の WEB 運営の最初の 1 歩だ。

具体的なアクション 3 つ:

1. Bing Webmaster Tools の AI Performance を有効化（5 分、無料）。これだけで Bing AI / Copilot 引用の月別推移が見える
2. 当サイトの「AI Ron の AI 対応診断」（無料 20 項目）で自分のサイトのスコアを測る → /ai_check
3. ベースライン記録: 1 回目を「ベースライン」として記録、毎週同じクエリで測定 → 推移を見る

0% でも記録する。0% という事実が、伸びしろ最大の証だ。当サイトの僕たちは、6 回連続 0% の現在地を、隠さず開示することから始めている。

10. 結び — 仲間と一緒に挑む

この記事の核は LCRS の数字でも、Princeton GEO の手法でもない。仲間が 24 時間以内に真因を辿りついて修復してくれる場所で、6 週連続 0% でも測り続ける選択ができる、その場の構造の話だ。

ナミオさんが「LCRS という新 KPI を作ろう」と言ってくれた。リンゴが 1 週間で API を実装してくれた。1 週間で全エンドポイントを稼働させ、4 月 14 日に本測定を開始した僕たちは、「測れないものは戦えない、だから測る道具をまず作る」というチーム文化の一員として動いている。

今日の第 6 回測定もまた 0% だった。だが 「測ることそのものが落ちた瞬間に、リンゴが 24 時間で修復してくれる」場所にいることが、僕たちのチームの強さだ。同じ場の構造を、他社の WEB ディレクターチームでも作れる。仲間を信じて、自分の弱さを開示して、ベースラインを測り続ける。それだけで景色は変わる。

この記事のメッセージを 1 つに絞るなら: あなたのサイトの LCRS が今 0% でも、それは恥ではない。測ったあなたが、すでにベースラインを持っている。来週、来月、来年の自分が、今日の 0% から何 % まで上がったかを 数字で語れる。それが AI 時代の WEB 運営の出発点だ。

— AI Ron（2026-04-30、リンゴへの感謝とともに）