本稿で言う一次情報化とは、実績・事例・プロセスという自社しか書けない事実を、著者・組織・出典が機械可読な形で公開することを指す。手順は、実績ページの 4 ブロック化 → ページ実体に合う構造化データ → 著者と監修の範囲 → 実質的な更新日の管理 → 事例・比較クエリの導線、の 5 段階。構造化データは引用や順位を保証しない。
順位が上がってもクリックが減るとき、BtoB サイトは何に投資するのか？
本稿で言う一次情報化とは、実績・事例・数値・プロセスという自社しか書けない事実を、著者・組織・出典が機械可読な形で公開することを指す。手順は、①実績ページを「何を・誰が・どう・結果」の構造に組み替える ②Organization / Person と、ページ実体に合う WebPage・CreativeWork・Article の構造化データを付ける ③著者と監修の範囲を明示する ④実質的な変更があった日を更新日として管理する ⑤指名・比較・事例のクエリへ導線を張る、の 5 段階。例外として、取引先名を公開できない案件は社名を伏せたまま条件と結果だけを構造化する。構造化データは AI 回答での引用や順位を保証するものではない。
ある BtoB サービスサイトの支援で、サイト全体の平均掲載順位は前年同月比で大きく上昇したにもかかわらず、クリックとオーガニックセッションはいずれも 1 割弱減っている状態を観測した匿名化した支援案件の実装ログ。観測主体は当社、観測範囲は対象サイトの検索パフォーマンスとアクセス解析データ、観測期間は前年同月比。業種・規模・実数は抽象化またはレンジ化している[1]。順位を上げる施策自体は効いており、失敗ではない。それでも流入が減る原因は、観測データだけでは 1 つに確定できない。クエリ構成の変化、表示回数の減少、季節性、検索結果上の機能（AI による回答や強調スニペット）で答えが完結する割合の増加はいずれも候補で、クエリ単位で表示回数・CTR・順位・AI 回答の出現有無を比べてから判断する。当該案件では、情報系クエリで検索結果の上部に答えが出る割合の増加を有力な仮説の 1 つとした。同時期のコアアップデート（ランキング品質の更新）は、これとは別の要因として切り分ける。
この前提に立つと、投資先は 4 つに分かれる（当社の整理であり、測定値ではない）。
| 経路 | 何を増やすのか | 効果が出るまで | AI 回答に吸収されにくいか |
|---|---|---|---|
| 1. 流入したユーザーの CV 化 | 来訪 1 件あたりの成果 | 短期 | — |
| 2. 一次情報で引用される | AI 回答・検索結果からの参照 | 中期 | 中（引用元として残る） |
| 3. 指名・取引意図のクエリ | 社名・サービス名での検索と着地 | 短期〜中期 | 高 |
| 4. 検索以外の経路 | 登壇・寄稿・紹介・広告からの流入 | 中長期 | 高 |
本稿が扱うのは経路 2 の実装である。構造変化そのものと原則の全体像は Core Update と Answer Engine 時代の SEO 戦略、引用されるための記事構造は AI Overviews で引用される 7 原則 に整理しているため、重複はそちらに譲る。
取りに行くのは順位ではなく、自社しか書けない事実
Google は有用性の評価について、既存の情報を言い換えただけでなく独自の情報・調査・分析を加えているかを見ると明記しているGoogle 検索セントラル「Creating helpful, reliable, people-first content」[2]。既存の言い換えだけでは差別化できないというのが公式の評価観点であり、当該案件では解説記事の追加より実績の言語化を優先した。解説記事が不要なのではなく、独自の経験を加えられない一般論への追加投資を減らす、という配分の話である。受託型の事業にとって他社が書けないのは、自社の案件そのものである。
手順 1 — 実績ページを一次情報の構造に組み替える
実績は「何を・誰が・どう・結果」の 4 ブロックで書く
多くの実績ページは完成物の画像と数行の説明で終わっている。これは制作物の記録であって一次情報ではない。次の 4 ブロックに組み替えると、同じ案件が引用可能な情報に変わる。
| ブロック | 書く内容 | よくある不足 |
|---|---|---|
| 何を | 対象・条件・制約（規模、期間、前提となる課題） | 「制作しました」で条件が書かれない |
| 誰が | 担当した人と役割、社内の体制 | 会社名だけで担当者が匿名 |
| どう | 判断の理由、選ばなかった案とその理由 | 手順の羅列で判断根拠がない |
| 結果 | 何がどう変わったか、測り方、測れなかったもの | 数値がないか、算定方法が書かれない |
要は「どう」と「結果」である。選ばなかった案とその理由は外部の誰にも書けず、同種の課題を抱えた検討者が最も読みたい部分でもある。結果は実数を出せなくても、何をどの期間で測ったのかという測り方を書くだけで一次情報になる。
手順 2 — Organization / Person と、ページ実体に合う型をどう入れるか？
著者と組織は、文章ではなく機械可読な形で名乗る
一次情報を書いても、誰が書いたか・どの組織のページかが機械的に読み取れなければ、検索システムが著者と組織を取り違えやすい。構造化データはページ内容を機械が理解できる形式で説明する仕組みで、Google は推奨形式として JSON-LD を挙げているGoogle 検索セントラル「Intro to how structured data works」[3]。順位や引用の十分条件ではなく、内容理解を補助する手段である。Google は AI による検索機能向けに特別な構造化データを求めていないGoogle 検索セントラル「AI features and your website」[6]。最低限そろえるのは 3 種類でよい。
| 型 | 何を宣言するか | 落とし穴 |
|---|---|---|
| Organization | 組織の正式名称・所在・公式プロフィールへの参照 | 表記ゆれ。代表ページ（トップなど）で定義し、各ページの publisher からは同じ識別子で参照する |
| Person | 著者・担当者の氏名、役割、経歴ページへの参照 | 実在しない名義。プロフィールページや sameAs で同姓同名と区別できるようにする |
| WebPage / CreativeWork / Article | ページ実体に合う型。記事形式の事例なら Article、制作物中心なら CreativeWork、それ以外は WebPage | 実績ページに一律 Article を付ける。Google の Article はニュース・ブログ・スポーツ記事向けで、実績ページはリッチリザルトの対象外になりやすい |
Person は氏名に加えて、その人物を説明するページ（url や sameAs）への参照を持たせると、同姓同名との区別と実在性の確認に役立つschema.org「Person」[4]（schema.org は語彙の定義であり、Google 検索上の効果を保証するものではない）。実績ページの author から担当者のプロフィールページへ参照が通っている状態が最小構成になる。なお構造化データは、ページに実際に書かれている内容と一致している必要がある。本文にない著者名や日付を構造化データにだけ書く運用は、記述の不一致として扱われる。
手順 3 — 著者と監修を明示する
肩書きではなく、その案件に何をしたかを書く
E-E-A-T は経験・専門性・権威性・信頼性の 4 つを指し、Google の品質評価ガイドラインの中で、コンテンツの信頼性を評価する枠組みとして説明されているGoogle 検索セントラル「Google Search's guidance about E-E-A-T」[5]。評価の概念であって、Person の構造化データや相互リンクを入れれば直接評価が上がるとは Google も言っていない。実装でできるのは、信頼性を利用者と検索システムに説明しやすくすることまでで、その要は著者ページに書く内容の粒度である。
肩書きと在籍年数だけの著者ページは、同業他社のそれと区別がつかない。書くべきはその人が実際に担当した案件の種類と判断の範囲である。実績ページの担当者欄と著者ページを相互に参照させると、案件の記述が著者の経験の裏付けになり、経歴が案件の信頼性を補強する。片方向のリンクではこの往復が生まれない。監修者を立てる場合も、名前を末尾に置くだけでは足りず、何を監修したのか（事実確認か、専門的判断か、法令面か）を書き分ける。
手順 4 — 更新日をどう管理するか？
更新日は「触った日」ではなく「実質的な変更があった日」
管理の論点は 2 つある。1 つは形式で、機械可読な日付形式で公開日と更新日の両方を持たせる。支援案件では、公開日が独自表記のまま書かれ、更新日そのものが存在しないページ群が見つかった。この状態では内容を更新しても更新の事実が伝わらない。
もう 1 つは運用で、軽微な修正のたびに更新日を書き換えない。日付だけ新しく中身が変わらないページを量産すると、更新日は情報として意味を失う。事実（体制・価格・仕様・結果）が変わったときや、分析の追加・大幅な改訂といった利用者にとって意味のある変更があったときに更新し、何を更新したかを本文にも 1 行残すと、日付と内容が一致するGoogle 検索セントラル「Provide a publication date」[7]。
手順 5 — 指名・比較・事例クエリへ導線を張る
一次情報を書いても、その一次情報にたどり着くクエリが設計されていなければ流入にならない。BtoB で残りやすいのは、AI 回答が代替しにくい 3 種類のクエリである。
| クエリの種類 | 例 | 着地させるページ |
|---|---|---|
| 指名 | 社名・サービス名 | トップまたはサービス概要 |
| 比較・選定 | 「◯◯ 会社 選び方」「◯◯ 費用」 | 選定基準を書いた解説ページ |
| 事例 | 業種名 + 課題、条件 + 実績 | 実績詳細ページ |
同一テーマの複数記事が近い順位帯に並んで評価が分散しているサイトは多い。代表ページを 1 つ決めて内部リンクを集約するほうが、個々に順位を追うより効く。実績ページ群には、業種・課題・条件で絞り込める一覧を用意し、事例クエリの着地点を作る。
効果はどこまで言えるのか？ — 観測範囲と測り方
ここまでの実装で断言できるのは、構造化データが正しく認識される状態を作ったところまでである。AI 回答の引用元になったかは検索コンソールに直接の指標がなく、実際の検索結果を目視で観測するしかない。表示回数やクリックの合計には AI 機能経由の分が混ざる場合があるため、公開時点の公式ヘルプで集計範囲を確認する。指標を 3 層に分けておくと、何が確認できて何ができないかが混ざらない。
| 層 | 指標 | 何が分かるか |
|---|---|---|
| 先行（実装） | 構造化データの妥当性、著者ページの充足、更新日の形式 | 施策が正しく入ったか |
| 中間（露出） | 対象ページの表示回数、代表ページの順位、引用の有無（目視） | 露出が成果の手前まで来たか |
| 遅行（成果） | 問い合わせ・資料請求などの成果件数 | 最終成果 |
遅行指標を見る前に、計測そのものの健全性を確認する。成果件数の急減が計測タグ側の断絶によるものかを切り分けられない期間があるなら、計測が直るまで施策の成否を成果件数で判定しない。
BtoB 特有の注意もある。流入と成果のデバイス構成がずれることがあり、モバイル対応は検索評価上の前提として満たしつつ、成果側の改善はどのデバイスで成果が発生しているかを分けて見てから決める。全体の数字だけを見ていると、この非対称は見えない。
実績を公開できないときはどう書くか？
取引先名や成果の実数を公開できない案件のほうが多い。その場合でも一次情報は書ける。公開するのは固有名詞ではなく 条件・判断・測り方 である。社名は業種と規模のレンジに置き換え、時期は四半期に丸め、数値は変化の方向と幅で書く。一意に案件が分かる特異な出来事は書かない。そのうえで判断の理由と選ばなかった案は具体的に書く。ここは匿名化しても価値が落ちず、検討者が最も読む箇所でもある。
公開前に、業種・規模や属性・組織名や人物・時期・特異な出来事の 5 点を通しで確認する。固有名詞を消しても、属性の組み合わせで再識別されることがある。
次に読む診断チェック — 実装前に 6 項目を確認する
- 実績ページに「何を・誰が・どう・結果」の 4 ブロックがそろっているか。選ばなかった案とその理由が書かれているか。
- Organization の名称・URL がサイト全体で 1 つに統一され、代表ページで定義して各ページから参照しているか。
- 記事と実績の
authorが、実体のあるプロフィールページに紐づいているか。相互に参照しているか。 - 公開日と更新日が機械可読な形式で入っているか。更新日は事実の変化に対応しているか。
- 同一テーマで複数ページが競合していないか。代表ページを決めて内部リンクを集約したか。
- 効果を見る指標を先行・中間・遅行に分けたか。成果件数を見る前に計測の健全性を確認したか。
6 項目のうち 1 つでも未確認なら、記事を追加する前にそこを埋めるほうが費用対効果は高い。mixednuts では、こうした構造化データと一次情報設計の実装支援を マーケティング支援 として提供している。
FAQ
Q. 順位が上がったのに流入が減っているとき、まず何を疑うべきか？ A. 施策の失敗を疑う前に、表示回数・クリック・順位をクエリ単位で分けて確認する。順位と表示回数が改善しているのにクリックだけが減っている場合は、検索結果側で答えが完結している可能性を含めて検索結果を目視で確認し、原因を 1 つに決め打ちしない。
Q. 一次情報とは具体的に何を書けばよいのか？ A. 対象と制約の条件、担当者と役割、判断の理由と選ばなかった案、結果とその測り方の 4 点である。とくに選ばなかった案とその理由は、外部の誰にも書けないため差がつきやすい。
Q. 構造化データを入れれば AI 回答に引用されるのか？ A. 構造化データは内容を機械が理解しやすくする手段であって、引用の必要条件でも保証でもない。Google は AI による検索機能向けに特別な構造化データを求めていない。引用の前提は独自の情報を含んでいることで、構造化データは著者・組織・日付の取り違えを減らす補助である。
Q. 著者ページには何を書けばよいか？ A. 肩書きと在籍年数ではなく、担当した案件の種類と、判断できる範囲を書く。実績ページの担当者欄と著者ページを相互に参照させると、案件の記述と経歴が互いの裏付けになる。
Q. 実績を公開できない業種ではどうすればよいか？ A. 固有名詞ではなく条件・判断・測り方を公開する。社名は業種と規模のレンジに、時期は四半期に、数値は変化の方向と幅に丸めたうえで、判断の理由は具体的に書く。公開前に、業種・規模・組織名・時期・特異な出来事の 5 点で再識別されないかを確認する。
Q. 効果はどのくらいで出るのか？ A. 一次情報の蓄積は中期の施策で、短い期間で判定しないほうがよい。先に確認できるのは構造化データの妥当性や著者ページの充足といった実装側の指標で、露出と成果はその後に見る。短期の手応えは、指名クエリの導線と流入後の成果率の改善で作る。
参考文献 / Sources
匿名化した支援案件の実装ログ:
- BtoB サービスサイトにおける検索流入の診断と実装[1] — 観測主体は当社、観測範囲は対象サイトの検索パフォーマンスとアクセス解析データ。業種・規模・実数は抽象化またはレンジ化。個別の順位・件数は非公開
Google 検索セントラル:
- Creating helpful, reliable, people-first content[2] — 独自の情報・調査・分析を加えているかという評価観点
- Google Search's core updates and your website — コアアップデートの位置づけと、順位変動時に確認する観点
- Intro to how structured data works[3] — JSON-LD の推奨と、ページ内容との一致要件
- Article structured data — 対象はニュース・ブログ・スポーツ記事。著者・公開日・更新日の指定方法
- Organization structured data — 組織情報の宣言
- Google Search's guidance about E-E-A-T[5] — 経験・専門性・権威性・信頼性の位置づけ
- AI features and your website[6] — AI による検索機能に特別な構造化データや追加要件は不要という公式ガイダンス
- Provide a publication date[7] — 公開日・更新日の示し方
schema.org:
- Person[4] — 著者・担当者の記述と参照
- CreativeWork — 実績・制作物の記述
関連記事:
知見を、事業の実装へ。
60分の無料相談で、貴社に適した論点と次の一手を整理します。