Organization構造化データは、正しく書いても「合格」の通知が来ない ── ナレッジパネルに伝える情報を確認する13項目（2026年9月時点）

01 何が起きたか — Organization構造化データは、検索結果の「見出し」を変えない

FAQやレシピの構造化データとは、そもそも役割が違う

構造化データというと、検索結果に星評価やアコーディオン表示を出す「リッチリザルト」を思い浮かべる人が多い。Organization（組織）の構造化データは、その系統とは別物だ。Googleの公式ガイド「Organization (Organization) structured data」は、この構造化データを設置する目的をこう説明している。

"Adding organization structured data to your home page can help Google better understand your organization's administrative details and disambiguate your organization in search results."

（訳: ホームページに組織の構造化データを追加すると、Googleが組織の管理情報をより正確に理解し、検索結果で組織を正しく識別する助けになる。）

公式ガイドが挙げる影響先は、ナレッジパネル・マーチャントナレッジパネル・ブランドプロフィールの3つである。検索結果の一覧に星や画像カルーセルを追加するタイプの構造化データとは、表示される場所も目的も違う。

必須プロパティはゼロ。公式は「関係するものをできるだけ多く」と勧めている

公式ガイドは必須プロパティについて、はっきりと述べている。

"There are no required properties."

（訳: 必須プロパティは存在しない。）

一方で推奨プロパティは、住所・連絡先・法人名・設立日・従業員数・税務ID・sameAsなど25種類以上にのぼる。実は、上で引用した「必須プロパティは存在しない」という一文は、その先にこう続いている。

"There are no required properties; instead, we recommend adding as many properties that are relevant to your organization."

（訳: 必須プロパティは存在しない。その代わり、組織に関係するプロパティをできるだけ多く追加することを推奨する。）

公式は、組織に関係するプロパティをできるだけ多く足すことを勧めている。そのうえで、入れる値が実態と一致しているかが要になる。存在しない従業員数を書いたり、使っていないSNSアカウントをsameAsに残したままにしたりすれば、数は増えても「組織を正しく識別する」という目的からは外れる。

ロゴだけは、単独の要件が細かく決まっている

推奨プロパティの中でも、logoは他のプロパティと違って画像に関する具体的な条件が公式ガイドに明記されている。まずサイズについて、公式ガイドはこう述べている。

"The image must be 112x112px, at minimum."

（訳: 画像は最小でも112×112ピクセルでなければならない。）

これに加えて、画像のURLがクロール可能かつインデックス可能であること、Google画像検索がサポートする形式であること、そして純粋な白背景の上に表示したときに、意図したとおりに見えることが条件として挙げられている。透過PNGを想定して作った画像を、背景色が付いた状態のまま使っていると、この最後の条件を満たさない可能性がある。かつてはロゴ専用の解説ページが別に存在していたが、本記事執筆時点ではOrganizationのページへ301リダイレクトで統合されており、経緯は08章で改めて扱う。

02 なぜ・背景 — 「拡張機能レポート」に出てこない構造化データ

ナレッジパネルを「持つ」ことと、構造化データを「書く」ことは別の話

Organizationの構造化データを実装すると、自動的にナレッジパネルの管理者になれると誤解されることがある。Googleのナレッジパネルヘルプは、パネルの情報源として「ウェブ全体の様々な情報源」「特定分野のデータパートナー」「パネルが指す組織自身からの編集提案」「ユーザーからのフィードバック」を挙げているが、この一覧に構造化データという言葉そのものは登場しない。パネルを管理者として確認（claim）する手続きは、Googleアカウントで自社の公式サイトやSNSにサインインする形で行われ、これは構造化データの実装とは別の作業である。

Search Consoleの拡張機能レポートに、Organizationという項目は無い

FAQやレシピの構造化データを実装した経験がある担当者ほど、Search Consoleの「拡張機能」セクションでOrganizationの検証結果を探してしまう。だが公式ヘルプが一覧する拡張機能レポートの対象は、パンくず・データセット・イベント・求人情報・レシピ・レビュースニペットなど19種類であり、この中にOrganizationは含まれていない。公式ヘルプは、レポートが表示される条件をこう説明している。

"A rich result report for a type will appear only if: Google finds valid markup in your property, and the markup is a supported rich result type."

（訳: あるタイプのリッチリザルトレポートが表示されるのは、有効なマークアップが見つかり、かつそのマークアップがサポート対象のリッチリザルトタイプである場合に限られる。）

Organizationはナレッジパネル等に使われる有効な構造化データだが、Search Consoleが追跡する「サポート対象のリッチリザルトタイプ」の一覧には入っていない。レポートに出てこないのは実装ミスではなく、そもそも対象外だということを、先に知っておく必要がある。

Rich Results Testが見ているのは「構文」であって「内容の妥当性」ではない

では検証はどこで行うのか。公式ガイドが案内するのはRich Results Testだが、このツールにも限界がある。トラブルシューティングの項目にはこう書かれている。

"The problem can be caused by either spammy content or spammy markup usage. However, the issue may not be a syntax issue, and so the Rich Results Test won't be able to identify these issues."

（訳: 問題はスパム的なコンテンツやスパム的なマークアップの使用が原因のことがある。ただしそれは構文の問題ではないことが多く、Rich Results Testではこうした問題を検出できない。）

Rich Results Testが「合格」を返しても、それは構文が正しいことの確認でしかない。マークアップした内容が実際のページと一致しているか、実体を偽っていないかは、ツールではなく人が判断する領域である。

03 この記事で出てくる用語

「型」は具体的なほど良いとされている

構造化データ全般ガイドラインは、Schema.orgで定義された最も具体的な型とプロパティ名を使うことを求めている。単なるOrganizationより、実態に合っていればOnlineStoreやLocalBusinessのような、より具体的なサブタイプを選ぶことが推奨される。06章で、代表的なサブタイプの使い分けを一覧にした。

JSON-LD・Microdata・RDFaの3形式 — Googleが推しているのは1つ

構造化データはJSON-LD・Microdata・RDFaの3形式のいずれでも記述できる。Microdata・RDFaは、ページ本文のHTMLタグに直接属性を埋め込んでいく方式で、表示用のマークアップと構造化データの記述が同じ場所に混在する。一方でJSON-LDは、<script>タグの中に独立した1つのブロックとして記述するため、表示用のHTMLを変更せずに追加・修正できる。公式の入門ガイドは、この実装・保守のしやすさと、JavaScriptで動的に挿入する構成とも相性が良い点を理由に、JSON-LDを推奨している。以降のチェックリストも、JSON-LDを前提に書いている。

ナレッジパネルとブランドプロフィールは、表示される場面が違う

Organization構造化データの影響先として挙げられている3つの表示のうち、ナレッジパネルは検索結果の横または上部に出る情報ボックス、マーチャントナレッジパネルは商品を扱う事業者向けの拡張版、ブランドプロフィールはさらに別の表示形式である。どれも「検索結果の一覧に星を付ける」タイプの表示とは異なり、組織そのものの実在性と属性をGoogleに伝えるという共通点を持つ。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どんな組織で優先度が高いか

この構造化データが特に効いてくるのは、社名や店名が一般名詞に近く検索結果で同名の別組織と混同されやすい組織・複数のブランド名やサービス名を運営している組織・ECサイトや店舗を持ちマーチャントナレッジパネルの対象になりうる組織である。設立から日が浅く、まだ検索結果上で組織としての実在性が十分に認識されていないサイトでも、優先度は高くなりやすい。個人名に近い小規模なサイトで、既に検索結果が正しく組織を識別できている場合は、優先度はそれほど高くない。

🅱 この記事が測っていないこと・分からないこと

公式ドキュメントを確認しても、明確にされていない点がある。第一に、Organization構造化データの有無や充実度が、検索順位そのものに影響するかどうかは、公式ガイドのどこにも明記されていない。第二に、sameAsに複数の候補URLがある場合、GoogleがどのURLを優先して採用するのかという判定ロジックも示されていない。第三に、推奨プロパティを何個満たせばナレッジパネルの表示精度が上がるのかという、定量的な基準も公開されていない。第四に、ナレッジパネルがそもそも表示されるかどうかの判定基準（対象となる組織の規模や知名度の目安）についても、公式ガイドは具体的な数字を示していない。分からないことを、分かるふりで埋めていない。

🅲 手順 — 実装から検証までの3段階

実際の作業は、次の3段階で進める。まず設置するページを1つに決め、次に組織の実態に合った推奨プロパティを過不足なく書き、最後にRich Results Testで構文を検証する。検証が通ったら終わりではなく、内容がページの実態と一致しているかを自分の目でも確認する。

05 明日、自分のサイトで確認できることチェックリスト

以下は、今日からブラウザとRich Results Testだけで確認できる項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。

• ホームページまたは組織概要ページのソースを開き、Organization構造化データがあるか確認する
• JSON-LD形式（<script type="application/ld+json">）で書かれているか確認する
• nameプロパティが、実際の組織名・サイト名と一致しているか確認する
• logoプロパティがある場合、画像が112×112px以上あるか確認する
• logo画像のURLに直接アクセスし、実際に表示され、クロールをブロックされていないか確認する
• sameAsに列挙されているURLを1つずつ開き、すべて自組織の公式アカウントを指しているか確認する
• addressを記載している場合、addressCountry・addressLocalityなど必要なサブプロパティが揃っているか確認する
• 同じOrganization情報を複数ページに重複して書いていないか確認する
• Rich Results Testに対象ページのURLを入力し、構文エラーが無いか確認する
• Rich Results Testの結果で、Organizationとして正しく認識されているか確認する
• マークアップした内容が、そのページ上で読者にも見える情報と一致しているか確認する
• Search Consoleの拡張機能レポートにOrganizationの項目が無いことを、実装漏れと誤解していないか確認する
• ナレッジパネルの「claim」が必要な場合、構造化データとは別に検証手続きが要ることを確認する

すべてに目を通す時間の目安は1サイトあたり40分程度である。sameAsのURLを1つずつ開く作業は件数が多いほど時間がかかるため、公式アカウントの一覧を別途まとめておくと次回以降が早い。addressやtelephoneのように、そもそも設置していないプロパティが多い場合は、点検よりも先に、01章の表を見ながらどのプロパティを追加するかを決める作業の方が優先度は高くなる。

06 代替・他の選択肢（表で）

「Organization」のままでよいか、より具体的な型があるか

03章で触れたとおり、公式ガイドラインは最も具体的な型を使うことを求めている。組織の実態に応じて、以下のようなサブタイプが用意されている。

迷ったら「Organization」から始めてよい

サブタイプの選択に時間をかけすぎるより、まずは基準となるOrganizationで必要な推奨プロパティを揃え、実態がより具体的なサブタイプに当てはまると分かった時点で切り替える、という順序でも問題はない。@typeの値を後から書き換えても、他の推奨プロパティの記述はそのまま流用できることが多く、切り替えの手間自体は大きくない。型を迷って着手が遅れるより、汎用の型で早く始めて推奨プロパティを一つずつ増やしていく方が、01章で見た「できるだけ多く追加する」という公式の方針には合っている。

07 自社サイトで確認したこと — 11個のプロパティから、公開当日にlogoとaddressを足した

ホームページのJSON-LDには、11個のプロパティが入っていた

当サイトのホームページのソースを実際に開いて確認したところ、Organizationの構造化データには、name・legalName・alternateName・url・email・description・foundingDate・areaServed・knowsAbout・founder・sameAsの11個のプロパティが入っていた。legalNameには正式な法人名を、nameにはサイトとして名乗っている通称を、それぞれ別のプロパティとして分けて記載している点は、01章で見た「組織を正しく識別する」という目的に沿った書き方だと言える。founderにはPerson型がネストされ、代表者の名前や役職、外部プロフィールへのsameAsも別途記載されていた。組織自体のsameAsとは別に、founderという個人の実在性も併せて示す構成になっている。

logo・address・telephoneは、まだ入っていない

一方で、01章で見た推奨プロパティのうち、logo・address・telephoneは現時点で設置していないことも同じ確認で分かった。当サイトはEC機能を持たないため、hasMerchantReturnPolicyのような通販向けのプロパティは対象外だが、logoは検索結果でのブランド識別に関わる項目であり、05章のチェックリストに沿って優先度を判断する対象として記録しておく。エンティティSEOの取り組みとしてWikidataの登録やsameAsの実装を進めてきた経緯は、別の記事で詳しく記録している（archives/66）。

記事を公開した日のうちに、logoとaddressを足した

この記事を公開した2026年9月11日のうちに、当サイトのOrganizationへlogoとaddressを追加した。

logoには、サイトのアイコンとして使っている512×512ピクセルの画像を指定した。05章の4番目と5番目の項目どおり、画像のURLを直接開いて表示されること、112×112ピクセル以上あることを確かめている。一方、ページの上部に出している横長のロゴ画像は高さが58ピクセルしかなく、公式ガイドの最小サイズに届かないため使わなかった。見た目として馴染みのある画像でも、条件を満たしているとは限らない。

addressには、運営会社（株式会社ツクルン）の公式サイトに掲載しているのと同じ住所を、同じ項目の分け方（streetAddress・addressLocality・addressRegion・postalCode・addressCountry）で入れた。組織の情報を複数のサイトで出しているなら、表記と項目の分け方を揃えておく方が、同じ組織の情報として扱われやすい。

telephoneは入れていない。運営会社の公式サイトにも電話番号は掲載しておらず、問い合わせはフォームとメールアドレスで案内しているためだ。01章で見たとおり、推奨プロパティは数を増やすことより、実態と一致させることが要になる。構造化データのためだけに、実態に無い情報を用意することはしない。

08 このテーマの、これまで

2011年、3社が共同で仕様を立ち上げた

Schema.orgは2011年6月2日、Bing・Google・Yahoo!の3社が共同で発表した構造化データの仕様である。同年11月にはYandexも加わった。robots.txtが1994年に1人の提案として始まったのとは対照的に、schema.orgは最初から複数の検索エンジンが足並みを揃える形で始まっている。

2012年、ナレッジグラフが「モノ」を理解する仕組みとして発表された

翌2012年5月16日、Googleは検索の仕組みを「文字列ではなくモノ」として理解するナレッジグラフを発表した。当時のエンジニアリング担当上級副社長Amit Singhalによる発表記事のタイトルが、そのまま「things, not strings」だった。発表当初のナレッジグラフは5億以上のオブジェクトと、その間の35億以上の関係情報を含んでいたとされる。Organization構造化データがナレッジパネルに使われているのは、この2012年の発表を土台にした流れの延長線上にある。

2026年、ロゴ専用ページがOrganizationページに統合された

本記事執筆時点で確認すると、以前はロゴの構造化データを個別に解説していたページが、301リダイレクトでOrganizationのページへ統合されていた。ロゴの要件は今、Organizationページの推奨プロパティの1つとして記載されている。ドキュメントの構成が変わっても、112×112px以上という数字自体は変わっていない。当サイトが以前、出力の値そのものに見つけた小さな穴を記録した回（archives/128）と同じく、ドキュメントの置き場所が変わった時ほど、内容を読み直す価値がある。

チェックリストの観点そのものが漏れていたことがある

当サイトでは以前、本文や見出しを新しい形式にすべて書き直しても、確認項目の一覧に「タイトルが素材のままではないか」という観点そのものが入っておらず、見落としに気づけなかった事例があった（archives/142）。05章のチェックリストも、今回書いた13項目がすべてではない可能性がある。ロゴの実装やsameAsの追加を進めるたびに、確認項目自体を見直す運用にしたい。