前回の最後に、一つだけ宙に残した問いがある。構造化データが、検索順位を上げる魔法でも、AIに引用される保証でもないとしたら——相関は見えても因果は確かめられない、という現在地に立つのだとしたら——私たちは何を頼りに、この手間をかけるのか。
六回かけて、知る・読む・埋める、と歩いてきた。その足場の上で、最後にこの問いへ降りる。結論を先に言えば、頼るべきは「AIに見つけてもらう」という外からの見返りではない。もっと手前の、自分の手で確定できる何かだ。そしてそれは、構造化という技術の話を一周して、「伝える」という、ずっと古い仕事に戻っていく。
ここまでの道のり — 知る、読む、埋める
第1回で、私たちは「構造化データ」という一語をほどいた。考え方・語彙・記法・セマンティックHTML。地図を持たずに歩けば迷うだけだから、まず言葉を交通整理した。そして気づいたのは、その語彙も記法も、もともとすべて検索エンジンに読ませる前提で設計されていた、という事実だった。
第2回で、その前提が動いていることを、時間をさかのぼって確かめた。schema.org は2011年、検索結果をリッチに見せるために生まれた。だが2026年5月7日、FAQリッチリザルトの表示が完全に終わった。表示は消えたのに、マークアップは死んでいない——Google はページ理解に使い続け、AIクローラーは読み続けている。同じ数行のコードの「目的」だけが、検索エンジン向けからAI向けへ引っ越した。FAQPage は、その引っ越しを日付つきで記録した生き証人だった。
第3回と第4回は、抽象論を現物に着地させる回だった。自社サイト untype.jp の <head> を開き、Organization から FAQPage まで一つずつ読んだ。土台は、よく整っていた。だが読めるようになると、そこに「無いもの」が見えた。サービスが——看板商品の互換性診断ですら——構造として書かれていない。AI可読性を売る会社の自社サイトで、肝心の売り物が機械に読めない。紺屋の白袴だ。第4回では、その空白を4つの層（情報設計・文書構造・マークアップ・能力）の地図に置き、それぞれが三つの職種の仕事であることを確かめた。地図を持つと、やらないことが決まる。
第5回で、その空白を実際に埋めた。サービスを Service に、価格は性質に応じて出し分け（受託は出さず、診断は出し、累進は単価で）、増えたノードはすべて @id で一つの会社ノードへ束ねた。連載のために作った架空の例ではなく、本当に自社のリポジトリで手を動かし、本番に出した記録だ。そして第6回では、その前向きな話を一度脇に置き、技術の効かない範囲を直視した。相関≠因果。構造化データ「だけ」では引用されない。嘘をつけてしまう危うさ、保守の負担、JavaScript で挿入すると多くのAIに届かないという罠。道具を正しく使うには、道具の効かない範囲を知らねばならない。
ここまでが、足場だ。そしてその足場の縁に、最初の問いが立っている。これだけの手間を、何のためにかけるのか。
外部報酬は、他人の頻繁に変わる選択に乗ること
いちばん素直な答えは、「AIに見つけてもらうため」だ。構造化すれば、ChatGPT や AI Overviews に引用され、そこから人が、あるいはエージェントがやってくる。その露出を見返りとして、手間をかける。これを外部報酬と呼ぶことにする。外から与えられる、見つけてもらうことの報酬だ。
問題は、この報酬が、驚くほど不安定なことだ。
AIがある問いに答えるとき、どのサイトを引用するかは、月どころか週の単位で入れ替わる。SEO分析企業 SISTRIX が3つのプラットフォーム・6か国・82,619件の問いを17週間追った調査では、引用されるドメインが Google のAI Modeで毎週およそ56%、ChatGPT では74%も入れ替わっていた。ChatGPT にいたっては、17週間を通じて一度も欠けずに引用され続けたドメインが一つもない、という問いが半数以上を占めた。検索順位の変動とは、時間の桁が違う。検索なら、上位の同じURLが何か月も同じ問いを占め続けることが多い。引用は、そうではない。先週引用されていたページが、今週は跡形もなく消えうる。
なぜか。引用するかどうかを決めているのは、私たちのサイトではなく、AIの側の——生成のたびに計算し直される——選び方だからだ。第6回で見たとおり、その選び方の機構は公開されていない。先の調査でも、この入れ替わりは一時的な乱れではなく、三つのプラットフォームすべてに共通して現れる性質だった。つまり外部報酬とは、自分では中身を見られない他人の選択に、見返りを丸ごと預けることにほかならない。
これを認めると、構造化データを「引用されるため」にやる、という動機づけは、足元が砂になる。第6回で見た Ahrefs の対照実験が示したように、引用されるページにスキーマが多い傾向はあっても、後から足して引用が有意に増えることはなかった——相関はあっても、後付けの因果は確かめられなかったのだ。仮に増えたとしても、その見返りは早ければ来週には引っ込みうる。外部報酬を当てにした投資は、相手の気まぐれに賭ける投資になりやすい。
ただし、誤解を避けたい。外部報酬を狙うのが愚かだ、という話ではない。引用も検索流入も、得られればありがたい。言いたいのは順番のことだ。不安定なものを土台に据えてはいけない。砂の上に、家の重心を置いてはいけない。
内部報酬は、自分の手で確定できる
では、何を土台に据えるか。外部報酬の対極にあるもの——内部報酬だ。
第5回の改修を思い出してほしい。私たちは「診断スコアが上がる」「引用が増える」とは約束しなかった。約束できたのは、ただ一つ、「機械が読める構造になった」という構造的事実だけだった。バリデータがその構文の正しさを裏づけ、自社の提供物が、推測の余地なく、正しい単位で存在するようになった。これは外部の反応を一切待たずに、その日のうちに手元で確定できた価値だ。
この「手元で確定できる」性質が効く場所が、すでに一つある。自社のRAGだ。第2回で触れたとおり、構造化データの引っ越し先は、検索エンジンでもAIサービスでもなく、自分たち自身の業務にもあった。整えられた構造は、自社のドキュメントをAIに読ませて答えさせるとき、推測を減らし、取り出しの精度を上げる。ここに、外部の選び方は介在しない。来月になっても引っ込まない。整えた構造は、整えた瞬間から、自分の手元で使える。
外部報酬と内部報酬の違いを、一言で言えばこうなる。外部報酬は「見つけてもらえたか」を他人が採点する。内部報酬は「正しく整っているか」を自分が確かめられる。前者の採点基準は毎週書き換わるが、後者は——本文と一致しているか、語彙は正しいか、参照は解決しているか——自分の側で完結する。第6回で「バリデータの緑は出発点であってゴールではない」と書いた。その緑が証明するのは構文の正しさだけだが、少なくともそれは、他人の気分では消えない確かさだ。
だから、この連載が最後に勧める動機づけは、こうだ。AIに見つけてもらうために構造化するのではない。いま、自分たちが正しく整っているために構造化する。見つけてもらえたら、それは果報として受け取ればいい。だが手間をかける理由は、もっと手前の、確定できる側に置く。砂ではなく、地面に。
構造化とは、結局「伝える」という仕事だった
ここで、視点をもう一段引きたい。
内部報酬のために「正しく整える」とは、突き詰めると何をしていることなのか。社名を確定値で渡し、サービスを独立した提供物として書き、価格を偽らず、本文とマークアップを一致させる——これらはすべて、「自分たちが何者で、何を、誰に提供しているのか」を、曖昧さなく差し出す作業だ。相手が推測しなくて済むように。取り違えなくて済むように。
それは、「伝える」という仕事の、別の名前ではないか。
「書く」と「伝える」は、似ているようで違う。書くは、書き手の側で完結する。書き終えた時点で仕事は終わる。伝えるは、相手に届いた時点で初めて完結する。視点が、内側からではなく、受け手の側に立つ。構造化データがやっているのは、明らかに後者だ。機械という受け手が、推測なしに受け取れる形まで面倒を見る——それは表現ではなく、到達への配慮である。
私の会社が「Web制作会社」という看板を下ろし、「コミュニケーションデザイン会社」を名乗り直したのは、ここに関わっている。コミュニケーションは、書き手の独白では成立しない。受け手との往復で初めて成り立つ。デザインとは、受け手の体験までを設計することだ。構造化データは、その受け手に「機械」が加わった時代の、伝えるための配慮の一つの形にすぎない。新しい技術の話に見えて、やっていることはずっと古い。
そして、ウェブが見えなくなるほど、この「伝える」の中身が剥き出しになる。AIが間に立ち、ページを要約して人に渡すようになると、多くの場合、装飾は要約で削られる。デザインの巧みさも、コピーの語感も、サイトの印象も、要約のなかではほとんど残らない。残るのは「何を伝えたか」、言葉の内容そのものだけだ。これは、表面で取り繕う余地が減るということであり、同時に、ちゃんと伝えた言葉はこれまで以上に正確に届く、ということでもある。構造化とは、その剥き出しになった中身を、機械にも誤読されない形で差し出す技術だ。
〈伝える側の仕事に戻る〉
私はこの連載と並行して、一つの問いを保留にしていた。AI時代のウェブで、本当に必要なことは何か、という問いだ。構造化データを入れよう、schema.org に対応しよう、GEOだ、LLMOだと、新しい用語が次々に湧く。経営者にとっては、何から手をつけていいか分かりにくい状況だと思う。
六回を経たいま、その答えを書ける。自分たちが何をやっている会社で、誰に何を届けているのかを、誠実に、ぼやかさず、ちゃんと伝わる形に整える。 これからのウェブで必要なことの大半は、それで済む。
派手な施策は要らない。難しい技術用語を追いかけ続ける必要もない。構造化データも、RAGの構築も、能力層への対応も、根っこにあるのは「自分たちのことを、世界に正しく伝わるように整える」という、ただ一つの仕事だ。整えれば、人間の顧客に届く。AIにも届く。社内のメンバーやRAGにも届く。これから登場する未知のエージェントにも届く。一本の柱から、すべてが派生している。
ここで順番が、もう一度効く。結果を先に追うと、テクニックに走る。流行りのキーワード、もっともらしい体裁、AIに媚びる書き方。これらは短期で効くこともあるが、長くは続かない。AIも検索エンジンも、年々「中身」を見るようになっているからだ。伝わる形に整えることを先に置けば、見つけてもらえるかどうかは、あとから付いてくる——あるいは、付いてこなくてもいい。整えたこと自体が、すでに内部報酬として手元に残っているのだから。
ウェブの仕事は、長いあいだ「書く」「見せる」の側に寄りがちだった。コピーを書く、デザインを見せる、施策を打つ。だがAIが受け手として加わり、装飾が要約で削られていく時代に、その重心は「伝える側」の地道な作業へと戻っていく。一周回って、ウェブがまだ装飾も検索もアプリもなかった頃の、伝えるための場所だった本質に、戻ってきている。
技術の話をしてきたつもりが、最後は伝えることの話になった。構造化データという連載の終わりが、ここに着地するのは、私には腑に落ちる。
余韻 — 意味は、また引っ越すだろう
最後に、一筆だけ。
この連載の背骨は、「意味の引っ越し」だった。検索エンジンのために生まれた構造化データが、AIのための技術として読み直された。同じコードの、目的だけが移った。だがおそらく、引っ越すのは構造化データの意味だけではない。
いまAI向けに整えている構造も、数年後には、別の何かのための土台として読み直されているかもしれない。能力層のように、いまは標準すら固まっていない層が、主役になっているかもしれない。「伝える」という仕事の本質は変わらないとしても、その仕事を載せる技術の意味は、また静かに引っ越していくのだろう。構造化データは、その「意味は時代とともに引っ越す」という現象の、たまたま私たちが居合わせた一例にすぎないのかもしれない。
結び — 急いで結論を出さない
七回を通じて、私は何度も「ただし」と書いてきた。スキーマを足せば引用される、とは書かなかった。診断スコアが上がる、とも約束しなかった。言えたのは、機械が読める構造になった、という構造的事実と、それが自分の手元で確かめられる、という確かさだけだった。
これは、結論を出し惜しんでいるのではない。いまの時点で誠実に言えることが、そこまでだ、というだけのことだ。相関は見える。因果は、まだ確かめられていない。外部報酬は不安定で、内部報酬は確かだ。そして「伝える」という古い仕事が、いっそう効くようになっている。ここまでは、自社の現物で確かめた。その先——構造化が長期にどんな見返りを生むのか、意味が次にどこへ引っ越すのか——は、急いで答えを出すより、手を動かしながら観察を続けたい。
untype.jp の <head> は、これからも書き換わっていく。私たちはそれを、定点として読み続ける。意味が、次にどこへ引っ越すのかを見届けるために。
参照情報
AI Citation drift: How stable are sources in AI search results?（SISTRIX） — 3プラットフォーム・6か国・82,619プロンプトを17週間追跡。引用ソースの週次入れ替わりが Google で約56%、ChatGPT で約74%にのぼると報告。
We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.（Ahrefs, 2026-05-11） — JSON-LDを追加した1,885ページを4,000の対照ページと比較（差分の差分法）。Google AI Mode +2.4%・ChatGPT +2.2%（いずれも誤差範囲）、AI Overviews −4.6%。後付けのスキーマでは引用は有意に増えないと結論。
FAQリッチリザルト廃止（2026年5月7日）の一次ソースは Google 検索セントラル「FAQ（FAQPage, Question, Answer）structured data」（連載第2回・第3回と同じ出典）。
その他の技術面の一次ソース（schema.org 公式、Google 検索セントラル、Vercel・MERJ の検証、validator.schema.org など）は、本連載 第1回〜第6回の各「参照情報」を参照。
この記事をシェアする
