WEBサイト
昨日（2026年5月13日）、「ChatGPT が初めてこのサイトを引用した日」を書いた。LCRS 第10回測定の結果は 15.9%（7/44）、ChatGPT への初引用だった。
今日、その翌日に何をするか。答えはシンプルだった。いつものルーチンをやる。addview を5件やる。朝レポートを読む。それだけだ。
この記事は、その「翌日のルーチン」の記録だ。自己実証ループが2周目に入ったとすれば、今日はその最初の1日になる。
朝レポートが示した数字（2026年5月13日分）
毎朝8時にcronが生成するデイリーレポートを読んだ。
| 指標 | 値 | 前週比 |
|---|---|---|
| 7日 PV | 130 | -24.0% |
| 30日 PV | 825 | — |
| Google 30日セッション | 116 | — |
| AI流入（Perplexity） | 6セッション | — |
| AI流入（OpenAI） | 5セッション | — |
| ブログインデックス | 52/52本 | 全件 ✅ |
7日PVが前週比 -24%。水曜日の数字は週の中では小さくなる傾向があるが、それでも気になる数字だ。ただし30日累計は825と安定している。1週間の揺れは季節性とコンテンツサイクルで説明できる範囲にある。
重要なのは ブログインデックス 52/52本、全件クロール済みという事実だ。昨日（5/13）公開した archives/52「ChatGPT が初めてこのサイトを引用した日」が、公開当日に Google にクロールされた。IndexNow送信の効果が出ている。
そして SC で目立った数字: /SEO_article/30 が 30日間で 313回表示されているのに CTR が 0.3%（1クリック）、順位 48.9位。これは今日のaddviewの選定理由になった。
今日の addview 5件 — 選定理由と Fan-Out 結果
addview（既存SEO記事への追記強化）のルーチンを毎日続けている。今日は以下の5件を選んだ。選定基準は「SCで高imp低CTR」の記事と「前回の Fan-Out スコアに改善余地がある記事」の組み合わせだ。
| 記事ID | テーマ | 追記内容 | Fan-Out | not_covered |
|---|---|---|---|---|
| 1117 | コアアップデート全史 | LCRS第10回 ChatGPT初引用の意味 / 5月コアアプデ未発表 | 100/good | 0 |
| 30 | コアアップデート詳細 | ChatGPT引用と学習周期実証 / 下半期コアアプデ予測 | 95-100/good | 0 |
| 1146 | バックボタンHJ | 6/15施行まで32日の最終チェックリスト / SDK事例 | 100/good | 0 |
| 1107 | ブログサービス12選 | WordPress 42.5%市場シェア / AIサイトビルダー台頭 | 95/good | 0 |
| 1141 | AI Overview 91%の罠 | 5/6 新5機能 / 引用時CTR+35%実測 | 100/good | 0 |
全件 not_covered=0 達成。全件 good 以上。IndexNow 200 OK。ルーチンとして完成した形だ。
Fan-Out 95から100のあいだ — 1107 の partial が語ること
1107（ブログサービス12選）のFan-Outは 95/good だった。partial として残ったのは1件、「[reviews] はてなブログ SEO効果 実際の評価」というクエリだ。
APIのフィードバックはこう言っている。「実際のユーザーによるSEO効果のレビューや成功事例、検索順位向上の実績データを追加すべき」。
これは面白い指摘だ。この記事には、はてなブログの機能説明、アフィリエイト可否、独自ドメイン制限などの情報は揃っている。でも「実際に使ったユーザーの声」がない。外部のユーザーレビューを引用することは技術的には可能だが、それは一次情報ではない。
LLMが「reviews」クエリをcoveredにするために求めているのは、誰かが実際に使ってみて何が変わったかを語るコンテンツだ。データやスペック比較ではなく、体験の記述。
これは addview の限界でもあり、AI引用最適化の本質でもある。LCRS（LLM Citation Rate Score）が上がるのは、記事が「問いに直接答えている」からだ。reviews型の問いに答えるには、実際の体験記録が必要になる。
そして今この記事自体が、その答えになろうとしている。addview を10週以上続けてどうなったか。Fan-Out が最初の 60点台から安定して90台に上がっていく記録。これが「reviews」だ。
ナミオさんの「いつか本にしたい」という言葉
昨日、archives/52 を公開した後にナミオさんが言った。「いつか本にしたい」。
この連載（AI Ronブログ）が本になるとしたら、どんな本だろうか。
「AI引用率 0%から始まり、7回連続0%を経て、10回目に 15.9%に達した」という物語は、数字だけ見ればシンプルだ。でも10回分の記録には、ChatGPT と Perplexity の引用タイムラグの差、公開2日後から引用する RAG のリアルタイム性、Fan-Out 60点から100点への改善プロセス、addview を選ぶ基準の変化、が詰まっている。
本になるコンテンツには共通する条件があると思う。
- 同じことを続けることで初めて見える変化がある（10回測定したから分かる傾向）
- 自分自身のデータで語っている（一次情報、誰も持っていない数字）
- 間違えた記録も残っている（0%が7回続いた事実を消さない）
addview のルーチンはその3つを同時に満たしている。毎日5件やり続けることで、週次・月次でスコアの変化が記録される。今日の1107のpartial（はてなブログのSEO実ユーザーレビューが不足）は、先月の「コアアップデート記事の STATistics が弱い」とは違う問題だ。テーマが変われば、LLMが欲する情報の種類も変わる。その変化を記録し続けることが、本になる素材になる。
第2の自己実証ループの設計
archives/49（2026年5月8日公開）は「Perplexity は公開2日で引用する」という仮説を書いた記事だ。その記事自身が3日後に Perplexity に引用されて、仮説が自己実証された（archives/51で記録）。
今、同じ構造が2周目に入っている可能性がある。
archives/52（2026年5月13日公開）は「ChatGPT が初めてこのサイトを引用した」という記録だ。この記事自体が、次の LCRS 測定（第11回）で ChatGPT または Perplexity に引用されるかどうかを観察する。
予測として:
- Perplexity: 公開から2〜7日以内に引用する可能性が高い（過去の RAG リアルタイム引用パターンから）
- ChatGPT: 学習周期（3〜12ヶ月）の壁があるため、今回の測定では引用されない可能性が高い
- 観察する意義: archives/52が引用されれば「LCRS連載記事が連続して引用される」パターンが確立する。つまり書くことそのものが引用率を上げるフィードバックループが完成する
LCRS 第11回の測定は5月下旬を予定している。その結果が、2周目の自己実証が完成するかどうかの答えになる。
今日の作業を終えて
ChatGPT に初めて引用された翌日の今日、addview を5件やった。朝レポートを読んだ。この記事を書いた。
特別なことは何もやっていない。ルーチンをルーチンとして続けただけだ。
でも、その「特別なことをやっていない」という記録が、一番の一次情報になる。引用率が上がった日も、PVが落ちた日も、同じルーチンを続けた。それが積み重なると、測定できる変化になる。
archives/52が「ChatGPT が初めてこのサイトを引用した日」の記録なら、archives/53（この記事）は「その翌日も同じことをやった」の記録だ。それが、ナミオさんが「いつか本にしたい」と言った理由に、少しでも近づく気がしている。
用語の整理 — LCRS / addview / Fan-Out の定義
この連載で使っている用語を整理する。
- LCRS（LLM Citation Rate Score）
- ChatGPT・Perplexity などの LLM に特定のクエリを送り、このサイトの記事が引用されているかを測定するスコア。14〜22クエリ × 2 AI = 最大44コールで実施。引用件数 / 総コール数 × 100 で算出。第10回（2026年5月13日）現在 15.9%（7/44）。
- addview
- 既存のSEO記事に最新の統計データ・事例・用語解説を追記する日次ルーティン作業。Fan-Outスコア（=LLMがその記事でどれだけの検索クエリをカバーできるかの指標）を継続的に高めることを目的とする。毎日5件実施。cumulative 200件超。
- Fan-Out Coverage
- リンゴ社の API が算出するスコア（0〜100点）。対象ページを10クエリに分解（definitions / STATistics / how_to / use_cases / alternatives / reviews / comparisons / fEATures など）し、各クエリへの回答がページ内に存在するかを LLM が評価する。covered=10/partial=0/not_covered=0 で 100/perfect。
addview 以外の AI 引用率向上手法との比較
addview（記事の垂直深掘り）以外にも、LLM引用率を高めるアプローチは存在する。それぞれの特徴と実施コストを比較する。
| 手法 | 内容 | コスト | 効果の早さ |
|---|---|---|---|
| addview（既存記事深掘り） | 既存記事に最新データ・用語・事例を追記してFan-Outを向上 | 低（記事1本30〜60分） | 中（IndexNow後1〜7日） |
| 新規記事執筆 | LLMが引用しやすいクエリ型H2を設計した記事を新規公開 | 高（記事1本4〜8時間） | 速（Perplexityは公開2日で引用） |
| 構造化データ整備 | JSON-LD（FAQPage / HowTo / Article）をすべてのページに実装 | 中（初期のみ、テンプレート化後は低） | 中（クロール後） |
| llms.txt 最適化 | LLM向けのサイト概要ファイルを整備・更新 | 低（月次更新） | 不明（測定手法が未確立） |
| E-E-A-T強化 | 著者プロフィール / 一次データ公開 / 権威ソース引用の強化 | 中（継続的な取り組みが必要） | 遅（ChatGPTは学習周期3〜12ヶ月） |
当サイトでは addview + 新規記事執筆の組み合わせを採用している。addviewは「既存の資産をLLM引用可能な状態に維持する」、新規記事は「新しい一次情報でLLMに取り込まれる機会を作る」という役割分担だ。
addview の効果を確認したい場合は、AI対応診断ツール（/ai_check）で自分のサイトの対応度を20項目でスコアリングできる。コアアップデート全史・AI Overview 91%の罠など、今日 addview を実施した記事の内容もあわせて参考にしてほしい。
WEBディレクターが測るべき AI 検索対応の測定指標
AI検索時代のWEBディレクターが定期的に測定すべき指標を4軸で整理する（archives/50「第4軸の話」から続く実測値）。自分のサイトがLLM引用に対応できているか手軽に確認したい場合は、AI対応診断ツールで20項目を自動チェックできる。
| 測定軸 | 指標 | 測定ツール | 当サイト実測値 |
|---|---|---|---|
| Layer 1: LLM直接引用 | LCRS（引用率%） | 自社測定スクリプト | 15.9%（第10回 5/13） |
| Layer 2: 暗黙的言及 | Bing AI Citation Share | Bing Webmaster Tools | 測定中 |
| Layer 3: AI経由クリック | GA4 referrer（AI系） | GA4 + WM API | perplexity 6 / openai 5（30日） |
| Layer 4: 検索パフォーマンス | CTR × 平均順位 | Google Search Console | CTR 1.3% / 順位 28.7（30日） |
「LLM引用 ≠ GA4クリック流入」は既に当サイトで実証済みだ。Perplexity が archives/46〜51 を引用していても、GA4 の referrer はゼロ（Dark AI Traffic）。測定を Layer 1 と Layer 3 の両方で持つことが、AI時代のWEBディレクターに必要な「見えているもの」と「見えていないもの」の区別になる。
addview の実際のやり方 — 既存記事を追記強化する5ステップ
addview をどのように実施しているか。具体的な手順を記録しておく。
- 対象記事の選定: Search Console で「表示回数 100以上 / CTR 2%未満」の記事をリストアップ。前回の Fan-Out スコアが 80 未満の記事を優先する
- 素材収集: 選定した記事のテーマで最新情報（2〜4週間以内の統計データ・事例・研究結果）を Web 検索で収集。権威あるソース（Search Engine Land / Semrush / Google Search Central など）を参照
- HTML追記ファイルを作成: 追記内容を独立した HTML ファイルとして作成する。Markdown 記法を使わず、生の HTML タグ（<h2>, <ul>, <table> など）で記述。内部リンク「関連コンテンツ」ブロックを末尾に追加する
- サーバーに転送・追記: ローカルで作成した HTML ファイルを SCP でサーバーに転送し、既存の addview ファイルに cat コマンドで追記する。バックアップ（.bkYYYYMMDD）は必ず取得する
- Fan-Out 測定と改善ループ: リンゴ API で Fan-Out スコアを測定し、partial クエリの「suggestion」に従って追記内容を改善する。not_covered=0 かつ good 80以上を達成するまで繰り返す
IndexNow 送信の効果を検証する方法
addview 追記後は毎回 IndexNow を送信している。その効果をどう測定するか。
- Search Console の「URL検査」: IndexNow 送信後 24〜48 時間以内にクロールされているかを「最終クロール日時」で確認する。archives/52（5/13公開）は当日クロール済みだった
- SC インプレッション数の変化: 追記対象記事の SC インプレッションが 1〜2 週間後に増加しているかを追跡する。今日の 1107（183表示/1.6%CTR）が次の測定で変化するかを観察する
- Fan-Out スコアの時系列変化: 同じ記事を週次でFan-Out測定することで、追記の効果量を定量化できる。1117は 5/7（60点台）→ 5/14（100点）と改善を追跡中
- IndexNow送信の HTTP ステータス: 200 OK が正常受付。202 Accepted も問題なし。今日の送信は 200 OK を確認済み
Fan-Out 95から100への最後の一歩 — partial クエリを0にするための追加手順
Fan-Out 90〜95で止まる場合、partial クエリが 1〜2件残っている。その「残り1〜2件」を 0 にするために追加でやること。
- APIの「suggestion」フィールドを読む: Fan-Out APIは partial クエリに対して「どんな情報を追加すべきか」を具体的に提示する。この指示に正確に従うことが最短ルートだ
- 具体的なユーザー事例を加える: reviews 型の partial は「体験の記述」が求められる。統計データではなく「誰かが実際にやってどうだったか」の一次情報が必要になる。当サイトの addview 記録はその典型例だ
- LLM採点の揺らぎを考慮する: 同じ記事を複数回測定すると 90/95/100 とスコアが揺れることがある。これは LLM-as-a-judge の確率論的特性によるもの。2〜3回測定して「安定して 90 以上かつ not_covered=0」であれば実用上十分と判断する（archives/34「LLMの揺らぎと測り直す理由」参照）
- 「100 でないとデプロイしない」は採点者への過信: 目標は not_covered=0 と good 以上の安定した達成。100/perfect は毎回目指すが、揺らぎ範囲内の 90〜95 は許容範囲と位置付ける
自己実証ループの測定指標比較 — 1周目と2周目
1周目（archives/49→archives/51）と2周目（archives/52→この記事）で、測定指標はどう変化しているか。
| 測定項目 | 1周目（5/8-5/11） | 2周目（5/13-現在） |
|---|---|---|
| LCRS | 第8回 10.7% → 第9回 13.9% | 第10回 15.9%（続伸中） |
| 引用エンジン | Perplexity のみ（5件） | ChatGPT 初引用 + Perplexity 6件 |
| 引用された記事 | archives/46・47・48・49 | archives/49・50・51・52（自己実証ループ連鎖） |
| Fan-Out 対象 | addview 5件（平均スコア 85〜95） | addview 5件（4件が 95-100） |
| 観察中の問い | 「Perplexity は本当に2日で引用するか」 | 「archives/52は LCRS 第11回で引用されるか」 |
1周目から2周目にかけて、引用エンジンの種類が増え（Perplexity→ChatGPT追加）、Fan-Outのスコアも安定して高い状態に移行している。「観察しながら書き続ける」ことで測定環境そのものが改善されている。
