エンティティSEOは、自社を一意にする設計

エンティティとは、名前がついた実体のこと

エンティティとは、名前で呼ぶことができ、他のものと区別がつく物事のことです。人物、組織、場所、製品などが当てはまります。

この記事では、そのうち自社に関わるものに絞ります。会社、そこで働く人、提供しているサービス。「パソコン」や「駅」のような広い言葉も機械の側では整理されていますが、特定の1社や1人を指さない言葉は、自社が何者かを伝える役には立ちません。

ここで大事なのは「一意であること」です。ある名前が、どの実体を指しているかが確定している状態を言います。

たとえば「田中製作所」という社名の会社は、全国に複数あります。文字列としてはまったく同じですが、静岡の金属加工会社と、大阪の樹脂成形会社は、別の実体です。人間なら文脈から読み分けますが、機械は文脈が足りなければ読み分けられません。同じ名前が複数の実体を指しうるとき、そのままでは実体は確定しないということになります。

中小企業の社名は、地名や創業者の姓を含むことが多く、この状態に置かれやすくなります。珍しい名前ほど取り違えられにくく、ありふれた名前ほど、所在地や事業内容といった手がかりを添える必要が出てきます。

キーワードとエンティティは、別のレイヤーにある

キーワードは、検索する人が入力する文字列そのものです。エンティティは、その文字列が指し示す実体です。この2つは、別のレイヤーにあります。文字列は入り口で、実体はその先にあるものです。

同じ会社を探している人でも、入力する文字列は毎回違います。「田中製作所」と打つ人もいれば、「田中製作所 静岡」「株式会社田中製作所」と打つ人もいます。文字列は3通りですが、探している実体はひとつです。

検索エンジンが文字列の一致だけで結果を組んでいた時代は、この3通りが別々の検索として扱われていました。文字列が指す実体をとらえるようになってから、3通りの入り口が同じ実体に結びつけられて解釈されるようになっています。

実体が確定していないと、そこに結びつくものを、その会社の情報としてまとめられません。 同じ社名の会社が2社あって、機械がその区別をつけられていない場合、自社サイトのページも外部サイトでの言及も、どちらの会社のものか確定しません。2社ぶんの情報が混ざるか、どちらにも結びつかないまま残ります。

検索エンジンとAIが、実体を見にいく理由

Googleがこの考え方を公にしたのは2012年5月16日の発表です。ナレッジグラフの導入を告げたその記事は、「things, not strings（文字列ではなく物事）」という言葉をタイトルに掲げています。当時のGoogleは、5億を超える事物と、それらについての事実や、それらのあいだの関係を35億件以上保持していると書いていました。

発表の中では、[taj mahal] というキーワードが例に使われています。この2語は、世界的な建築物を指すこともあれば、グラミー賞を受賞した音楽家を指すこともあり、ニュージャージーのカジノを指すこともあります。文字列としては同じでも、指している実体が違うという説明です。

※出典：Google 公式ブログ「Introducing the Knowledge Graph: things, not strings」（2012年5月16日公開・2026年9月24日参照）

Googleがエンティティを持つ目的は、もともと検索意図を正しく読むことにありました。順位を決めるためではなく、質問の意味を取り違えないための仕組みとして始まっています。

検索意図を読むという目的とは別に、評価の側でも実体が前提になります。E-E-A-T（経験・専門性・権威性・信頼性）は、Googleが検索品質評価ガイドラインで示している考え方で、「誰が書いたか」を含めて品質を見るものです。そして「誰が」を評価するには、その誰かが実体として認識されている必要があります。認識されていなければ、そこにあるのは名前の文字列だけで、書いたものや実績を、その人に結びつけられません。

AI検索でも同じことが起きます。AIが回答を作るとき、どの情報源を参照するかを判断します。その判断には、発信しているのが何者なのかという情報が要ります。実体が定まっていない発信者は、判断材料そのものが薄い状態に置かれます。

「エンティティSEO」は、2つの別のことを指している

エンティティSEOという言葉は、2つの別のことを指して使われています。

	コンテンツ側の話	実体側の話
何をするか	記事に関連する語を盛り込む	自社・自分を識別できる状態にする
対象の範囲	1本の記事	サイト全体と、その外側
伝えたいこと	このページは何の話か	この会社・この人は何者か
効く先	そのページの評価	サイトと発信者の評価

コンテンツ側の話は、テーマを十分に説明すれば、自然に満たされます。人工知能について書けば機械学習という語が出てきますし、ハンバーグのレシピを書けば挽肉が出てきます。書き手が意識して埋め込むまでもなく、必要な語はそこに現れます。だからこれを「施策」として構えることには、あまり意味がありません。 テーマを十分に説明すること自体が要らない、という意味ではありません。

実体側の話は、性質が逆です。普通に書いても満たされません。何も設計しなければ、自社は名前の文字列のまま置かれます。会社概要ページに社名が書いてあっても、それが他のどの情報と同じものを指しているかは、機械の側では確定していません。

この2つを分けておかないと、関連語を足しただけで、エンティティSEOに手を付けたつもりになります。 実体側は、手を付けない限りそのまま残ります。外部から提案を受けたときも、どちらの話かを確かめると、何をしてもらうのかが見えてきます。以降で扱うのは、実体側だけです。

記事の中身そのものをどう作るかは、コンテンツSEOの記事で扱っています。

関連記事コンテンツSEOは、正しくやるほど差が消える

自分で決められる範囲と、決められない範囲を分ける

実体として認識されるうえで、信頼できる外部サイトからの言及は手がかりのひとつになります。ただ、それを目標に置くと、中小企業には打つ手がなくなります。大手メディアに載ることも、Wikipediaに項目ができることも、自分では決められないためです。検索結果に会社の情報がまとまって表示されること（ナレッジパネル）も、申請して出せるものではありません。これらはすべて、結果として起きることです。

一方で、自分の判断で今日から決められることがあります。自社サイトで社名を正式名称のまま書くこと。社名・住所・電話番号の書き方を、自社で直せるWeb上の場所で揃えること。会社概要ページを、自社に関する情報が一箇所に集まる場所として整えること。記事ごとに、書いた人が誰なのかを名前と肩書きで示すこと。事業所や店舗があるなら、Googleビジネスプロフィールに登録して情報を最新にしておくこと。

この2つを分けたうえで、順序を決めます。

自分で決められる側から手を付ける理由があります。表記が揺れたままだと、外部での言及が起きても、自社に結びつかないためです。

社名が「株式会社田中製作所」「田中製作所」「（株）田中製作所」と場所によって違い、住所の書き方も揃っていない状態で、外部のサイトが自社に言及したとします。その言及が、どの実体に対するものなのかを機械が確定できません。せっかくの言及が、実体に結びつかないまま残ります。

このうち、いちばん手を付けやすいのは自社サイトの中の書き方です。会社概要やフッターのように、自社を名乗る場所では「弊社」「当社」ではなく正式名称で書き、社名の書き方をひとつに決めます。自分たちのサイトの中で自分たちが何者かを名乗っていないと、その先の話が始まりません。

進める順は、まず社名・住所・電話番号の書き方を1つに決め、自社サイトの会社概要とフッターを直し、Googleビジネスプロフィールをそろえ、最後に業界のポータルや求人媒体など、自分で編集できる掲載先を直していきます。

Googleビジネスプロフィールの登録の手順や、Googleマップの順位の決まり方は、MEO対策の記事で解説しています。

関連記事MEO対策とは？Googleマップで差がつくのは口コミ

会社概要やトップページに何を載せるか、会社の公式サイト（コーポレートサイト）全体をどう作るかは、コーポレートサイトを解説した記事で扱っています。

関連記事コーポレートサイトとは？目的と載せるページ、Googleに会社を伝える役割まで

型を書くことと、一意になることは別

自社の情報を機械に伝える手段として、構造化データ（JSON-LD）があります。schema.orgという共通の語彙を使い、会社ならOrganization、人ならPerson、記事ならArticleという型で情報を書きます。

型の一覧を見ながら書いていくと、書き終えた時点で完了に見えます。ただ、型を書いたことと、その実体が一意に識別されたことは、別のできごとです。

会社概要ページにOrganizationを書き、記事ページにもOrganizationを書いたとします。人間が見れば同じ会社の話だと分かります。機械から見ると、同じ名前を持つ2つの記述があるだけで、それが同じ実体を指しているという保証はありません。第1章で見たとおり、名前が一致していることは、同じ実体である証明にはなりません。その原理は、自分のサイトの中でも同じように働きます。

これを解くための仕組みが、JSON-LDには最初から用意されています。識別子（@id）です。ひとつの実体にひとつの識別子を決めておき、他の場所からはその識別子を参照します。そうすると、別々の場所に書かれた記述が、同じ実体を指していると宣言できます。

つながっているかどうかで、何が変わるのか。記事を100本書いたとして、それぞれの著者情報が別々の記述になっていれば、100人ぶんの薄い記述が並ぶ形に近づきます。同じ識別子で結ばれていれば、100本すべてが1人の書き手の仕事としてまとまります。同じ作業をしていても、機械から見える形は変わります。記事を書かない会社でも、製品や事例のページごとに会社の情報を別々に書いていれば、同じ違いが出ます。

このサイトの記事も、図3の形で書いています。別の記事のページを開いても、書いた人と会社の識別子は同じです。

外部との接続を示す書き方もあります。SNSのプロフィールや、Wikipediaのように第三者が管理している参照ページなど、自社や自分を指す別の場所のURLを列挙しておく（sameAs）ことで、「これらは同じものです」と自分の側から申告できます。第5章で「決められない」に置いたWikipediaの項目も、できたあとであれば、自分の側から指し示すことはできます。申告できるのは把握している範囲に限られますが、自社を指す場所を宣言しておくと、外部にある情報と照合するための手がかりが増えます。

ひとつ、正直に書いておきます。構造化データがAI検索の回答に直接参照されているかどうかを、サイトの側から確かめる手段は、いまのところありません。 私も「入れれば引用される」とは考えていません。確かに言えるのは、機械が読み取れる形で書いておけば、誤って解釈される余地が減る、というところまでです。

Googleは、検索のAI機能のために特別な構造化データを足す必要はないとしたうえで、構造化データをページに表示している内容と一致させることを勧めています。Googleの検索に限れば、AIに備えるために特別なものを足す必要はない、ということです。Googleのどの資料に何が書かれているかは、AEO対策の記事で整理しています。

関連記事AEO対策の施策は、Googleの公式資料で「要件・不要・書いていない」に仕分ける

入れて終わりにすると、ずれていく

構造化データには、見出しや本文を直す作業と決定的に違う点があります。画面に出ないということです。

見出しの文字が消えていれば誰でも気づきます。構造化データは、ページを見ても目に入りません。壊れていても、内容とずれていても、見た目には現れません。気づく機会がないまま放置されます。

この性質があるため、次のような状態が起きやすくなります。

• リニューアルのときには入ったが、その後に追加したページには入っていない
• ページの内容を書き換えたのに、構造化データは古いままになっている
• 値が用意できなかった項目に、仮の文字列が入ったまま公開されている

3つ目は少し補足が要ります。値がないときに空の文字列や仮の値を出すと、機械の側にはそれが値として渡ります。分からないという状態は伝わりません。値がないなら、その項目ごと出さないほうが正確です。

見るべきなのは「入っているかどうか」ではなく、「いまのページの内容と合っているかどうか」です。確かめる手立てはいくつかあります。

見たいこと	手立て
実際に何が出力されているか	Googleのリッチリザルトテスト、schema.orgの検証ツール
サイト全体でエラーが出ていないか	Search Consoleの拡張レポート（リッチリザルト対象の型に限られる）
自社・自分が実体として認識されているか	Googleトレンドに名前を入れ、「トピック」候補が出るかを見る

表の3行目は簡単に試せます。Googleトレンドの検索窓に社名や個人名を入れたとき、通常は「検索キーワード」としての候補が出ます。「トピック」という候補が現れていれば、実体として認識されている手がかりになります。出ていなければ、まだ文字列として扱われている可能性があります。ただ、検索される回数が少ないだけで出ないこともあるので、それだけで認識されていないとは言えません。

こうした確認は、ページを増やすたび、内容を変えるたびに繰り返します。構造化データは、一度書いて置いておく飾りではなく、内容と一緒に動き続ける必要があります。

ARROWSのAI検索対策

社名・住所・電話番号の書き方を決めたら、自社サイトから外の掲載先へと直していく。その順を、ARROWSのAI検索対策でも踏みます。お客さまのサイトの中の表記は私たちが直し、外部のサイトは、直す箇所と推奨する表記を一覧にしてお渡しします。会社概要のページは、会社の公式の情報をまとめる場所として、とくに丁寧に整えます。

識別子で同じ実体を結ぶ作業も、このサービスに入ります。記事は書いた人を、書いた人は会社を同じ識別子で指す、図3のような形にします。どのページの記述をどの実体に結ぶかは、私たちが確かめてから入れます。

リニューアルのときには入ったのに、あとから足したページには入っていない。第7章で挙げたこの状態に向けて、ページのタイトル・更新日・画像などをもとに構造化データを自動で作る仕組みを入れます。ページを足したり直したりしても、構造化データが追いつくようにするためです。この仕組みを、私たちはEverSchemaと呼んでいます。

いまのサイトのまま、他社が制作したサイトでも頼めます。第6章で書いたとおり、AIの回答に引用されることまでは、お約束できません。

まとめ

エンティティSEOという言葉は、2つの別のことを指しています。記事に関連語を盛り込むコンテンツ側の話と、自社という実体を一意にする実体側の話です。前者は、テーマを十分に説明すれば自然に満たされます。後者は設計しない限り満たされません。

実体側を進めるときは、次の順で考えます。

1. 自分で決められる範囲と、決められない範囲を分ける
2. 決められる範囲（正式名称で書く・表記を揃える・書いた人を明示するなど）を先に固める
3. 型を書くだけで終わらせず、同じ実体が同じ識別子で結ばれているかを確かめる
4. 画面に出ないものなので、内容を変えるたびに出力を見にいく

自社が何者かを、自分の言葉で、機械にも読める形で、揺れずに言い続ける。エンティティSEOと呼ばれているものの中身は、突き詰めればそれだけです。派手な施策ではありませんが、ここが定まっていないと、検索エンジンもAIも、自社の情報をほかの会社と混ぜたまま扱いかねません。