AIや検索エンジンに、自分について正しく知ってもらうにはどうすればいいのか。この問いを考えたとき、最初は「AIに覚えさせる方法」や「検索結果を変える方法」を探していました。でも実際には、こちらからAIの内部知識を書き換えることも、検索結果を直接決めることもできません。
できるのは、その手前です。検索エンジンやAIが調べたときに、正しい一次情報へたどり着けるようにする。どのページが中心なのかを分かりやすくする。人間だけでなく機械にも意味が伝わる形で情報を置く。そして、外部でどう認識されたのかを確認し、ズレがあれば情報環境の側を直す。
そこでTarCoon☆CarToonでは、こうした一連の処理を担う仕組みとして「ロビイスト」を作りました。
技術的には、独自の検索エンジンを作ったわけでも、新しいAIモデルを学習したわけでもありません。WordPress、構造化データ、検索エンジン向けの基本的な仕組み、外部認識の記録を組み合わせています。
この記事では、AIや検索エンジンから正しい一次情報を見つけてもらうために、どんな構造を考え、WordPress上に何を実装したのかを整理します。
本記事は、筆者が行った設定・調整作業を振り返るための備忘録として記録しています。環境によって挙動が異なる場合があり、内容の正確性・再現性・動作を保証するものではありません。実施は自己責任でお願いします。万一トラブルが発生しても、筆者は責任を負いかねますのでご了承ください。
まず「AIに覚えさせる」と「AIから見つけてもらう」を分けた
最初に考えていたのは、「ChatGPTなどのAIにTarCoon☆CarToonを覚えてもらいたい」ということでした。ただ、ここは整理が必要でした。
生成AIの内部知識そのものを、こちらから自由に書き換えることはできません。ChatGPT、Claude、Grokなど、それぞれのAIの基盤モデルへ「TarCoon☆CarToonとはこういうものです」と直接登録する仕組みがあるわけではありません。
一方で、Web検索を使えるAIなら話が変わります。AIが質問を受けたときにWebを検索し、TarCoon☆CarToonの公式サイトへたどり着き、その内容を参照できれば、少なくとも知らないAIでも調べれば分かる状態にはできます。
そこで最初の目標を、**「AIそのものに覚えさせる」ではなく、「AIが検索すれば正しい一次情報へ行けるようにする」**に置き換えました。ここがロビイストの技術設計の出発点です。
Google Driveは正本、Webサイトは外部への窓口
共同観測所では、情報源や409記録などをGoogle Drive側で管理しています。ここで重要なのは、Google Driveと公開Webサイトの役割を分けることでした。
Google Drive
＝正本・内部記憶
WordPress
＝外部へ公開する窓口
検索エンジン・AI
＝外部から参照する側内部で管理している情報を、そのまますべてWebへ公開するわけではありません。正本には、未整理の記録、内部用資料、未解決問題、409文書なども含まれます。これをそのまま検索エンジンへ渡すと、何が現在の説明で何が過去の検討なのか分からなくなります。
そこで、外部へ公開する情報だけを抽出した公開用の記憶層を用意することにしました。内部ではこれを「Public Memory」と呼んでいます。
Public Memoryを作る
Public Memoryは、TarCoon☆CarToonについて外部から参照してほしい情報だけをまとめる層です。
たとえば、
name
TarCoon☆CarToon
type
concept
canonical_url
公式の参照先
description_short
短い説明
description_long
詳しい説明
aliases
表記揺れ・別称
related_entities
共同観測所・409機関など
official_links
公式Web・SNS等
status
current
updated
更新日といった情報を持たせます。
ここで大事なのは、Public Memoryを「TarCoon☆CarToonのすべて」にしないことです。これはあくまで、外部がTarCoon☆CarToonを参照するための案内板です。
内部の記憶と、外部へ見せる情報を分けることで、検索エンジン向けに情報を整理しながら、共同観測所の複雑な記録をそのまま単純化せずに残せます。
Entity Homeという「ここを見ればいい」を作る
次に必要になったのが、TarCoon☆CarToonについて説明する中心ページです。内部ではこれをEntity Homeと呼んでいます。
考え方は単純で、**「TarCoon☆CarToonについて調べるなら、まずここを見ればいい」**というURLを一つ決めるということです。
Web上には、ブログ記事、過去のプロフィール、SNS、イベント情報など、TarCoon☆CarToonに関する情報がいろいろあります。しかし検索エンジンから見ると、それらが同じ対象について書かれているのか、どのページが現在の中心的な説明なのかは必ずしも明確ではありません。
そこで、Entity Homeを一つ決め、そのページから共同観測所、409機関、ロビイスト、公式記事、SNS、関連活動などへつなげていきます。人間にとってのプロフィールページであると同時に、検索エンジンやAIに対する参照点として使います。
canonicalで「中心のURL」を伝える
同じ内容や近い内容が複数URLに存在すると、検索エンジン側から見て「どれが本体なのか」が分かりにくくなります。そこで使うのがcanonicalです。
<link rel="canonical" href="https://example.com/entity-home/">のように、中心となるURLを明示します。
これだけで検索結果が思い通りになるわけではありませんが、「この情報の代表URLはここです」と伝える基本的な手段になります。ロビイストでは、この参照先を曖昧にしないことをかなり重視しています。
検索エンジンだけでなく、機械が読める説明も置く
Webページは基本的には人間向けに書かれています。でも検索エンジンやAIにとっては、「この文章に出てくるTarCoon☆CarToonが何なのか」を機械的に判断できる情報もある方が扱いやすくなります。
そこで使うのが構造化データです。今回のロビイストでは、Schema.orgのJSON-LDを使います。
たとえば概念としてのTarCoon☆CarToonなら、
{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"name": "TarCoon☆CarToon",
"description": "...",
"url": "..."
}のような形です。
ここで重要なのは、Person や Organization にしなかったことです。TarCoon☆CarToonを一人の人物として機械へ伝えてしまうと、共同観測所で扱ってきた「人物ではなく概念」という前提と矛盾します。そのため、最初の実装ではDefinedTermを採用しました。
構造化データは検索順位を上げる魔法ではありません。ただ、人間向けの文章とは別に、機械へ「これは何についてのページなのか」を伝える補助線になります。
WordPressに「ロビイスト」を実装した
これらを毎回手作業で管理するのは面倒です。そこで、TarCoon☆CarToonのWordPressサイトに、独自の「ロビイスト」機能を実装しました。
現在の最初のバージョンでは、WordPressの管理画面から、Entity Name、Entity Home、canonical URL、短い説明、詳細説明、aliases、外部参照先、IndexNow関連設定などを管理できるようにしています。さらに、Entity HomeではJSON-LDによる構造化データを出力します。
つまり、思想として語っていた「ロビイスト」を、まずはWordPressプラグインという形で実体化したことになります。
REST APIでPublic Memoryを外から読めるようにする
Public Memoryは、WordPressの画面だけで使うのではなく、外部システムから取得できるようにもしています。そのために、REST APIを用意しました。
考え方としては、
WordPress
↓
Public Memory API
↓
AI・外部ツール・将来の検索システムという形です。
今後、共同観測所の外部記憶や別のAIと接続するときも、WordPressから公開情報だけを取得できます。重要なのは、ここでも内部記憶すべてを公開しないことです。外部へ出していい情報だけをPublic Memoryとして切り出し、その情報だけAPIから返します。
sitemapで「ページがあります」と知らせる
検索エンジンにページを見つけてもらうためには、Webサイト内部でページが存在するだけでは不十分なことがあります。そこで使う基本的な仕組みがXML Sitemapです。
WordPressには標準で、
/wp-sitemap.xmlがあります。
ロビイストでは、これを検索エンジンから参照できる状態にしておくことを確認します。サイトマップは、「このサイトにはこういうページがあります」というページ一覧です。検索エンジンに対する索引のような役割を持ちます。
IndexNowで更新を通知する
ページを更新したとき、その変更を検索エンジンがいつ見つけるかは分かりません。そこで、一部の検索エンジンへ更新を通知する仕組みとしてIndexNowを使います。
WordPressの記事や固定ページを公開したとき、
ページ公開・更新
↓
ロビイスト
↓
IndexNow
↓
対応する検索エンジンへ通知という動きをします。
ただし、IndexNowへ送信したからといって、必ず検索結果へ反映されるわけではありません。あくまで、**「このURLが更新されました」**と知らせる仕組みです。検索結果への採用や評価は検索エンジン側にあります。
この「こちらができるのは通知まで」という距離感も、ロビイストの思想とよく合っています。
Googleには別の経路を使う
ここは少し注意が必要です。IndexNowはすべての検索エンジンへ共通して使える仕組みではありません。
Googleについては、Search Consoleやサイトマップを使って、サイトやURLの状態を確認していきます。また、GoogleのIndexing APIは通常のブログ記事や一般的なWebページを自由に登録するためのAPIではありません。
そのため、
Google
→ Search Console / Sitemap
IndexNow対応検索エンジン
→ IndexNowという形で経路を分けています。
「APIを叩けばGoogleに登録される」という単純な仕組みではない点は、作ってみて重要だと感じたところです。
robots.txtやnoindexも確認する
どれだけ情報を整理しても、検索エンジンのクローラーを拒否していたら意味がありません。
そのため、ロビイストでは、
robots.txt
meta robots
X-Robots-Tag
canonical
sitemap
HTTP statusなども確認対象にしています。
特にWordPressには、「検索エンジンがサイトをインデックスしないようにする」という設定があります。制作中に有効にしたまま公開してしまうと、ページを作っても検索されません。ロビイストでは、こうした入口が閉じていないかも確認します。
AI検索に見つけてもらうには、Webから読める必要がある
検索エンジンだけでなく、ChatGPTなどWeb検索を行うAIから見つけてもらいたい場合も、基本的な考え方は同じです。
まず、公開ページとして存在する。クローラーがアクセスできる。ページの意味が分かる。関連するページ同士がつながっている。どこが中心的な情報なのかが分かる。
こうした普通のWebの整備が先にあります。
「AI専用の特殊な裏技」を探すよりも、Web上の一次情報をきちんと作ることの方が先でした。ロビイストを作りながら、ここはかなり重要だと感じています。
外へ出したら、それで終わりではない
ロビイストのもう一つの仕事は、外部認識を観測することです。
たとえば、
TarCoon☆CarToonとは？
TarCoon☆CarToonは誰？
TarCoon☆CarToonは何をしている？
共同観測所とは？
TarCoon☆CarToonと共同観測所の関係は？といった質問を検索エンジンや生成AIへ投げて、どんな回答が返るかを確認します。そして、その結果を記録します。内部ではこれを外部認識記録として扱っています。
外部認識を分類する
AIや検索結果から返ってきた説明を、単純に「正しい／間違い」の二択にはしません。
たとえば、
aligned
かなり一致している
acceptable
大きな問題はない
partial
一部しか認識されていない
outdated
古い情報
misrecognized
明確な誤認
unsupported
根拠が確認できない
interesting
誤りとは言えないが興味深い解釈のように分けます。
ここでも409機関と同じように、「違う＝即座に削除対象」にはしません。明確な事実誤認なら修正を試みる。古い情報なら更新する。情報不足なら一次情報を追加する。でも、単なる異なる解釈なら観測として残す。
思想編で書いた、事実には働きかける。解釈は支配しない。 を、運用へ落とすための仕組みです。
外部認識がズレていたら、出力ではなく入力側を直す
ここがロビイストの設計で特に重要なところです。
たとえば生成AIが、「TarCoon☆CarToonは○○という人物です」と答えたとします。AIの回答を直接修正することはできません。
そこで、
外部認識を観測
↓
ズレを発見
↓
なぜそう見えたか調べる
↓
公式Web側の情報を修正
↓
再クロール・再観測という順番で考えます。
つまり、回答を直接操作するのではなく、回答を作るための情報環境を改善する。ロビイストの考え方を一番短く表すなら、この循環になります。
ロビイストの処理を単純化すると
かなり簡略化すると、現在の仕組みはこうなります。
Google Drive
↓
正本
Public Memory
↓
外部公開用情報
Entity Home / WordPress
↓
HTML + JSON-LD + canonical
Sitemap / IndexNow / Search Console
↓
検索エンジン
検索エンジン・生成AI
↓
外部認識
外部認識記録
↓
ズレを観測
必要なら
↓
正本・公開情報を修正
↓
再び外部へロビイストは、一方向に情報を発信する仕組みではありません。正本 → 公開 → 発見 → 認識 → 観測 → 修正 → 再公開というフィードバックループです。
今のロビイストで、まだやっていないこと
現在のロビイストは、まだ最初のバージョンです。
現時点では、WordPress上のPublic Memory管理、Entity Home向けの構造化データ、外部認識記録、IndexNow、REST APIなどを中心に実装しています。一方で、まだ自動化していないものもあります。
Google Search Consoleとの本格的なAPI連携、URL Inspectionの定期取得、複数の生成AIに対する自動認識監査、Google Drive上の外部記憶とPublic Memoryの自動同期、409機関への自動送致などです。
ここは今後、必要性を見ながら追加していく予定です。最初から全部自動化するのではなく、まずは人間が何を確認し、何を直しているのかを理解できる状態で動かすことを優先しています。
特別なSEOより「参照できる一次情報」を作る
ロビイストを作り始めたときは、もっと特殊なSEO技術やAI向けの対策が必要だと思っていました。でも実際に整理していくと、中心にあるのはかなり基本的なことでした。
公式の参照先を作る。情報を整理する。機械にも意味が分かるようにする。検索エンジンがアクセスできるようにする。更新を知らせる。外部からどう認識されたかを見る。間違っていたら一次情報側を直す。
結局、必要だったのは「検索結果を操作する技術」ではなく、検索結果が正しい一次情報を参照できる状態を作ることでした。
AI時代のWebサイトは「人に読ませるだけ」ではなくなる
今回ロビイストを作っていて、一番大きく感じたのはここです。
これまでWebサイトは、基本的に人間が読むものとして作っていました。でも生成AIが検索結果やWebページを読み、それを別の人へ説明するようになると、Webサイトにはもう一人の読者が増えます。
AIです。
人間に伝わる文章を書く。検索エンジンがページを発見できるようにする。機械が何について書かれたページなのか理解できるようにする。そして、その情報をAIがどう解釈したのかまで観測する。
これからのWebサイトには、この循環が必要になるのかもしれません。ロビイストは、その実験でもあります。
検索結果を直接書き換えることはできません。AIの認識を直接支配することもできません。でも、何を参照できる状態にしておくかは選べます。
そこへ働きかける。そして、その結果をもう一度見る。
それが、ロビイストの技術的な仕事です。
改訂履歴 ダウンロード
この項目の表示は制限されます。この部分を閲覧できるのは、TarCoon☆NetWorkのメンバーに限られます。
コメントを残す