Wikidata Q コードで AI に正しく認識される

Wikidata は、Wikipedia の姉妹プロジェクトとして運営される、誰でも編集できる構造化データベースです。掲載されるすべての項目には、Q に整数が続く一意の永続識別子が付きます。これが QID、通称「Q コード」です。

たとえば「東京都」にも「ウェブデザイン」にも、それぞれ固有の Q コードがあります。重要なのは、この番号が言語に依存しないことです。日本語ページでも英語ページでも、同じ実体なら Q コードは 1 つ。名前の表記ゆれに左右されません。

Google の Knowledge Panel（検索結果の右側に出る情報枠）に表示される情報の多くは、この Wikidata 由来です。つまり Q コードは、機械が世界の事物を整理するための「背番号」のような役割を果たしています。

名前は曖昧です。「沼津」は地名ですが、人名や商品名にもなりえます。「ハートン」という屋号も、同名の別事業者が世界のどこかに存在するかもしれません。人間は文脈でこれを解きほぐせますが、機械には難しい。

AI 検索エンジンは、回答の根拠を組み立てるとき「これとあれは同じ事業者か、別物か」を判断する必要があります。名前だけが手がかりだと、別の事業者の情報を混ぜてしまうリスクが残ります。

Q コードはこの曖昧さを断ち切ります。事業者の業種やサービス分野を Q コードで明示すれば、機械は「この事業者は、世界共通で定義されたこの概念に属する」と確定できます。これがエンティティの明確化であり、Q コードの本質的な価値です。

実装の入口は Schema.org の additionalType プロパティです。Schema.org の型は数百ありますが、業種によっては「ぴったりの型」が存在しません。そんなとき、おおまかな型に Q コードで具体性を足します。

たとえば WEB 制作業に専用の Schema.org 型はありません。そこで LocalBusiness という大枠の型を使い、additionalType に Wikidata の Q コード URL を https://www.wikidata.org/entity/Q... の形式で配列指定します。これで「LocalBusiness の一種で、具体的にはこの業種」と機械に伝わります。

事業者が詳しい分野は knowsAbout、サービス対象地域は areaServed にも Q コードを使えます。名前の文字列ではなく Q コードで指定すると、機械の解釈の精度が一段上がります。

ここで誇張を 1 つ正しておきます。「Wikidata に紐づければ検索順位が上がる」「AI 引用が増える」といった主張には、確実な裏付けがありません。

Wikidata の Q コードは直接のランキング要因ではありません。効果はあくまで間接的で、AI と検索エンジンがエンティティを明確に特定できるようになることです。Knowledge Panel の情報が Wikidata 由来であるように、機械が事物を整理する土台に貢献する、という性質のものです。

とはいえ無意味ではありません。2025 年 10 月には Wikidata Embedding Project が公開され、MCP（Model Context Protocol）標準への対応で AI からの参照性が公式に強化されました。Q コードは「順位を押し上げる魔法」ではなく、機械に取り違えられないための識別子。土台として地味に効きます。

Q コードの調べ方はシンプルです。wikidata.org の検索窓に業種名や地名を日本語で入力すると候補が出ます。目的の項目を開けば、URL の末尾と見出し横に Q から始まる番号が表示されます。それが QID です。

選ぶときの注意点は 2 つ。1 つ目は概念の粒度。自社の業態に最も近い項目を選び、広すぎず狭すぎない概念にします。2 つ目は項目の確認 — 開いた項目の説明文を読み、本当に意図した概念かを人間の目で確かめます。同名で別概念の項目が存在することがあるためです。

設定後は、Schema.org の Markup Validator や Google のリッチリザルトテストで JSON-LD の構文を検証します。構文エラーはツールが見つけますが、Q コードが業種に合っているかは人間が確認します。ここは JSON-LD 実装ガイドの検証手順と同じ流れです。