「著者エンティティを実装した」と書いた私が、自分の239ページを監査したら配線が途中で切れていた話
少し前に、私は「AIに著者として認識させるには Person エンティティと sameAs を実装しろ」という記事を書きました。author に名前を文字列で書くだけでは住所のない表札だ、@id 参照と sameAs で実在の人物に配線を通せ、と。書いているときの私は、自分のサイトではもう配線が通っているつもりでいました。
その記事を出した数日後、ふと自分のサイトの構造化データを実際に取得して確かめてみました。ブラウザの想像ではなく、本当に配信されているHTMLの中身です。そこで見たものは、自分で書いた記事の主張を、自分のサイトが守っていない光景でした。表札に配線を通せと説いた本人が、肝心のページで配線を途中までしか引いていなかったのです。
この記事は、その自己監査でわかったことと、239ページぶんの配線を通し直して、効果を測るための前後比較を始めるまでの話です。人に配線図を渡す前に、自分の家の配電盤を開けたほうがいい、という当たり前の教訓も込みで書きます。
取得して確かめたら、参照先が記事ページに無かった
私が実際に取得した、自分の記事ページのJSON-LDはこうでした。
{
"@type": "BlogPosting",
"author": {
"@type": "Person",
"@id": "https://kenimoto.dev/#person",
"name": "井本 賢",
"url": "https://kenimoto.dev/"
},
"publisher": { "@id": "https://kenimoto.dev/#organization" }
}一見、前の記事で説いたとおりに見えます。author は文字列ではなく @id 参照になっている。ちゃんと宿題をやった顔をしています。問題は、その @id が指す先です。#person という実体、つまり sameAs を持った Person ノードは、このページのどこにもありませんでした。同じく #organization の実体もありません。実体はすべて、トップページにだけ置いてあったのです。
前の記事で私はこう書きました。@id 参照にすれば全記事が1つのPersonに集約される、と。それ自体は正しい。けれど私は、その集約先のPersonを記事ページに同梱するのを忘れていました。記事ページにあったのは「#person という住所」だけで、その住所に建っているはずの「sameAsで身元を証明する建物」はトップにしか無かった。住所は書いたが、建物は別の町にあったわけです。
なぜこれが効かないか。AI検索は、引用しようとする記事のURLを直接取りに来ます。トップページを経由してから記事に来るわけではありません。その記事ページだけを見たAIにとって、author: { "@id": "#person" } は、同じページのどこにも定義のない参照、つまり宙に伸びた矢印でした。Googleはサイト全体を統合して解決してくれることもありますが、単一ページをfetchするAIにそれを期待するのは甘えです。私は前の記事で「住所のない表札」を批判して、自分は「建物のない住所」を203記事ぶん配っていました。どちらも、訪ねた人が本人にたどり着けない点では同じです。
sameAs の数が、言語ごとにバラバラだった
もう一つ、開けてみて気づいたことがあります。トップページに置いてあった唯一の Person 実体ですら、言語ごとに別物でした。
英語版には10個のプロフィールが sameAs に並んでいて、日本語版には11個、ポルトガル語版には5個、スペイン語版には4個。同じ一人の人間なのに、ページによって「私は何者か」の証明書の枚数が違っていたのです。
sameAs は本来、その人物が同一であることを示す配列です。人物の同一性は言語に依存しません。私がGitHubにいることも、Zennにいることも、何語のページから見ても同じ事実です。それなのに、スペイン語のページを見たAIは私の身元を4本の糸でしか確かめられず、日本語のページでは11本で確かめられる。証明の強さがページの言語で変わるのは、設計のほころびでした。
配線を全ページに通し直す
直し方は、説いていたことを今度こそ全ページで実行するだけです。各ページのJSON-LDを @graph という入れ物に変えて、その中に 記事本体・著者の Person 実体（sameAs 付き）・発行者の Organization 実体・サイトの WebSite 実体 をまとめて同梱しました。これで、どの記事ページを単独でfetchしても、その場で著者の身元まで解決できます。住所と建物が、同じ町にある状態です。
sameAs は、全プロフィールの和集合をとって11個に統一しました。これで何語のページから見ても、私の身元は同じ11本の糸で証明されます。実装の重複を避けるため、sameAsの一覧は一箇所のソースファイルに集約して、トップページも記事ページもそこを参照する形にしました。今後プロフィールが増えても、書き換えるのは一箇所です。
ついでに、もっと恥ずかしい dangling も見つかりました。書籍ページの isPartOf、つまり「このページはこのサイトの一部です」という参照が、全言語で英語版サイトの @id を指していたのです。日本語の書籍ページが、日本語サイトではなく、存在しない参照先を指していた。これも言語ごとの正しい WebSite に繋ぎ直しました。
直したあと、全ページを機械的に検査しました。203記事と36書籍、あわせて239ページ。その中にある内部参照を全部たどって、参照先がそのページに存在するかを数えました。
- 239ページすべてが、sameAs付き Person・Organization・WebSite を自己完結で保持
- ページ内の
@id参照 1,455本のうち、宙に浮いた参照は 0本 - トップページの出力は変更前と一字一句同じ（リグレッションなし）
最後の項目は地味ですが大事です。共通化のためにトップページのコードも書き換えたので、表示される構造化データが前と変わっていないことを、生成後のHTMLを突き合わせて確認しました。リファクタで「ついでに壊す」のが一番こわいので、ここは機械に数えさせました。
前と後を、正直に測る
ここからが本題かもしれません。前の記事で私は「引用の帰属が記事URLから著者へ一部移った」と書きました。あれは嘘ではありません。author を @id 参照にした効果は、たしかに観測しました。けれど今回わかったのは、その配線が記事ページでは途中までしか繋がっていなかったという事実です。だとすれば、これから全ページに実体を通したことで、帰属がさらに動くかどうかは、改めて測り直す価値があります。
そこで、デプロイ前の今のうちに「before」を記録しました。実装前のAI検索が、私の記事をどう引用しているか。著者名が添えられているか、URLだけか。これを対照として残しておかないと、あとで「変わった」と言っても、それが配線のおかげなのか、ただの時間経過なのか区別がつきません。検証メディアを名乗る以上、対照のない before/after は出したくありません。
観測のスパンは、前の記事で引いた業界分析にならって3〜6ヶ月にとります。1ヶ月後に早期シグナルを見て、3ヶ月後に本評価。測る対象は、著者エンティティそのものを扱ったこの記事を含む数本と、あえて別トピックの記事を1本混ぜます。別トピックを混ぜるのは、「WebRTCに詳しい著者」のように、記事単位ではなくエンティティ単位で私が拾われ始めるかを見たいからです。結果は出てから、数字とスクリーンショットを添えてまた書きます。
念のため釘を刺しておくと、これで一夜にして引用が何倍にもなるとは思っていません。今回やったのは、前の記事で配り損ねていた建物を、ようやく全部の住所に建てた、というだけの話です。即効薬ではなく、ただの伏線の回収です。伏線は、回収して初めて意味が出ます。
まとめ
- 人に渡す配線図は、自分の家の配電盤を開けてから渡したほうがいい。私は「
@id参照と sameAs を実装しろ」と書いた直後、自分の記事ページに参照先の実体が無いことに気づきました。 @id参照は、参照先の実体が同じページに無いと、単一URLをfetchするAIには宙に浮いた矢印に見えます。実体はトップだけでなく、AIが実際に取りに来る記事ページに同梱する必要があります。- sameAs は人物の同一性なので、言語によって本数が変わるのは設計のほころびです。全プロフィールの和集合に統一し、一箇所のソースから参照させると、証明の強さがページ間で揃います。
- 239ページの内部参照1,455本を機械的に検査して、宙に浮いた参照が0であることを確認しました。リファクタで既存の出力を壊していないことも、生成後のHTMLで突き合わせました。
- 効果は、対照を取って3〜6ヶ月で測ります。before を残さない before/after は出しません。結果は数字とスクリーンショットで改めて報告します。
配線図を配る人ほど、自分の配電盤は後回しになりがちです。たまには自分のHTMLを生で取得して、説いたとおりに繋がっているか確かめてみてください。たぶん、一箇所くらいは矢印が宙に浮いています。面白くいきましょう。
AI検索に「拾われる側」になるための構造化データ・llms.txt・引用率設計を体系的に扱った本があります。著者エンティティやE-E-A-Tの実装、今回のような自己監査の観点も含めて、より深く知りたい方はこちらをどうぞ。
この記事は役に立ちましたか？