組織スキーマ

TL;DR — Organizationスキーマは、検索エンジンにあなたのビジネスが誰であるかを伝える小さなコードブロックです。名前、ロゴ、公式ウェブサイト、ソーシャルプロフィールなどです。ほとんどのスキーマとは異なり、ページ上のコンテンツではなく、会社自体を説明します。Googleがあなたのブランドを認識し、正しく識別するのに役立ち、検索結果で一部のブランドに表示される情報ボックス（「ナレッジパネル」）などの表示要素に影響を与える可能性があります。ただし、そのパネルを保証するものではなく、ランキングを上げるものでもありません。

Organizationスキーマとは

ほとんどのスキーママークアップは、ページ上の内容（商品の価格、レシピの調理時間、レビュースコア）を説明します。Organizationスキーマは異なります。サイト全体の背後にあるビジネス、つまり名前、ロゴ、公式URL、ソーシャルアカウント、場合によっては住所や連絡先の詳細を説明します。

これは共有のschema.org語彙を使用し、ページの外観を変えずに配置されるコードブロック（JSON-LD）として記述されます。Googleがそれを読むと、メッセージは基本的に次のようになります：「これが私たちです。」

追加する価値がある理由

その主な役割は、検索エンジンがあなたのブランドを識別し、似た名前の他社と区別するのを助けることです。Google自身の表現は意図的に限定されています。マークアップの追加は、 “can help Google better understand your organization’s administrative details and disambiguate your organization in search results,” (翻訳) 「Googleが組織の管理上の詳細をよりよく理解し、検索結果で組織を明確に区別するのに役立つ可能性がある」 とされ、一部のプロパティは “can influence visual elements in Search results” (翻訳) 「検索結果の視覚要素に影響を与える可能性がある」 と説明されています。対象には、表示されるロゴや、検索結果の右側または上部に一部のブランドで表示される、ロゴ、リンク、詳細を含むナレッジパネルの情報などがあります。

“役立つ可能性がある”や”影響を与える可能性がある”は保証ではありません。Googleはマークアップが存在するだけでナレッジパネルを作成するわけではありません。パネルの表示は、エンティティがウェブ全体でどれだけよく知られ、よく裏付けられているかに依存します。あなたのマークアップはGoogleが使用できる1つの入力であり、パネルをオンにするスイッチではありません。

初心者がよく間違えること

• ナレッジパネルを保証するものではありません。 正しいマークアップは役立ちますが、Googleにパネルを表示させるものではありません。
• ランキング向上にはなりません。 Organizationスキーマは検索結果での順位を上げるものではありません。その目的は識別と表示であり、ランキングではありません。
• 1か所に配置し、すべてのページに配置しないでください。 Googleはホームページまたは組織を説明する単一のページ（「About」ページなど）を推奨しており、サイトのすべてのページに必要ではないと述べています。
• ロゴには実際の最小サイズがあります： 少なくとも112x112ピクセル、かつ画像はGoogleが到達可能である（ブロックされていない）必要があります。

完全なプロパティリスト、2023年11月の拡張、sameAsの実際の動作、正確な失敗モードを知りたいですか？Advancedタブに切り替えてください。

TL;DR — Organizationスキーマ（schema.org/Organization、JSON-LD）は、サイトの背後にあるエンティティ（名前、ロゴ、URL、sameAs、および管理フィールド）を説明し、その文書化された役割は曖昧さの解消であり、一部のプロパティはナレッジパネル/帰属UIなどの視覚要素に影響を与える可能性があります—ランキングではありません。どちらも保証されていません。Googleは必須プロパティはない（関連するものを追加）と述べており、ホームページまたはAboutページに1回推奨しています。Muellerはサイト全体での重複をレビューマークアップのスパムに例えています。logoは**≥112x112pxで、クロール可能/インデックス可能**である必要があります。2023年11月の更新で、古いLogoドキュメントがOrganizationに統合され、管理フィールド（address、legalName、duns、leiCode、naics、iso6523Code、numberOfEmployees、foundingDate）が追加されました。コマース関連フィールド（hasMerchantReturnPolicy、hasMemberProgram、hasShippingService）は後で、別の2024〜2025年の更新で追加されました—2023年のバッチではありません。そして、排除すべき核心的な神話：マークアップ≠保証されたナレッジパネルであり、ランキング要因ではありません。

Organizationスキーマが実際に行うこと

Google自身の説明は正確です。ホームページへのOrganization構造化データの追加は、 “can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” (翻訳) 「Googleが組織の管理上の詳細をよりよく理解し、検索結果で組織を明確に区別するのに役立つ可能性があります。」 ここで重要なのは理解と区別です。このマークアップは、ほかのすべてのAcmeから自社の「Acme」を区別し、エンジンが自社を表現する際に使う管理上の事実（ロゴ、公式リンク、識別子）を渡す方法です。

Googleはまた、プロパティを目的別に分類しています。「一部のプロパティは、あなたの組織を他の組織から区別するために舞台裏で使用され（iso6523やnaicsなど）、その他のプロパティは検索結果の表示要素に影響を与える可能性があります（検索結果やナレッジパネルに表示されるlogoなど）。」 つまり、マークアップには2つの役割があります。静かな身元確認と、ロゴやナレッジパネルの詳細などの表示UIへの影響の可能性です。どちらもランキングの要因ではなく、保証でもありません。Google自身の動詞は「役立つ可能性がある」と「影響を与える可能性がある」であり、「表示する」や「ランク付けする」ではありません。

これは構造化データのエンティティレイヤーです。エンティティ＆アイデンティティスキーマハブと並んで位置し、その近縁であるLocalBusinessスキーマ（物理的な場所と営業時間を持つビジネス用のサブタイプ）やPersonスキーマ（個人や著者用）は、異なるエンティティタイプに対して同じアイデンティティの役割を果たします。Organizationは、会社やブランド自体に使用するものです。

必須プロパティはありません — 関連するものを追加

意外に思われる点ですが、Googleは次のように述べています。 “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.” (翻訳) 「必須プロパティはありません。代わりに、組織に関連するプロパティをできるだけ多く追加することを推奨します。」 名前、ロゴ、URL、適切なsameAs数件だけの簡潔で正確なブロックは正当であり、推測した識別子を詰め込むより多くの場合に優れています。Googleは明確な「コア」を定義していませんが、name、logo、url、sameAsは、Googleが説明する表示要素と曖昧性解消に最も結び付くため、実務上妥当な出発点です。

配置場所 — そしてなぜすべてのページではないのか

配置は好みではなく文書化されたルールです。「この情報はホームページ、または組織を説明する単一のページ（例えばアバウトページ）に配置することをお勧めします。サイトのすべてのページに含める必要はありません。」

ジョン・ミューラーもこれを直接強調しています。彼のガイダンスは、Googleがホームページや連絡先/アバウトページなど、どこか分かりやすい場所でそれを見つける必要があるだけだというもので、サイト全体に会社のマークアップを配置してどこでも拡張機能を得ようとするのは間違った考え方であり、サイト全体にレビュースターを散りばめるのと同じ間違いだと、レビューマークアップのスパムと比較して警告しました。 （Search Engine Journalが報じたミューラーのコメントから言い換えています。逐語的な引用ではなく、言い換えとして扱ってください。）

実用的な要点は変わりません。ホームページまたはアバウトページに1つのインスタンスを配置します。

完全なプロパティリスト（および2023年11月の拡張）

GoogleがサポートするOrganizationプロパティ（文書化されているもの）：

address · alternateName · contactPoint · description · duns · email · foundingDate · globalLocationNumber · hasMerchantReturnPolicy · hasMemberProgram · hasShippingService · iso6523Code · legalName · leiCode · logo · naics · name · numberOfEmployees · sameAs · taxID · telephone · url · vatID

管理バッチ（法人名、住所、連絡先情報、事業者識別子（duns、leiCode、naics、iso6523Code）、numberOfEmployees、foundingDate）は、2023年11月に、Googleが旧スタンドアロンのLogo構造化データページをOrganizationドキュメントに統合し、当初のlogo + urlの組み合わせを大幅に拡張した際に追加されました。すでにlogo + urlのマークアップを導入していたサイトは、何も変更する必要はありませんでした。(2023年11月の拡張は、Googleのブログ発表に基づく要約であり、調査中に逐語的に再取得できなかったため、詳細は言い換えとして扱ってください。)

コマース関連のオブジェクトは、その2023年のバッチの一部ではありません。それぞれが個別の、それ以降のアップデートで追加されており、Googleのライブ検索アップデート履歴で確認済みです。

• hasMerchantReturnPolicy（組織レベルの返品ポリシー）— 2024年6月11日に追加。
• hasMemberProgram（ロイヤルティプログラム）— 2025年6月10日に追加。
• hasShippingService（配送ポリシー）— 2025年11月12日に追加。

これらのそれぞれには、独自のドキュメント、利用可能条件、および製品レベルのマークアップやMerchant Center設定に対する優先順位の動作があります。有効なOrganizationマークアップがあっても、それだけではMerchant Centerでの承認や、これらのいずれかのSearchでの表示が保証されるわけではありません。

残りはおおよそ次のようにグループ化します。

• コアID: name、alternateName、legalName、url、logo。
• 連絡先 / 所在地: address、contactPoint、telephone、email。
• 事業者識別子（曖昧性解消）: duns、leiCode、naics、 iso6523Code、globalLocationNumber、taxID、vatID。
• プロフィール: sameAs。
• 組織レベルの事実: numberOfEmployees、foundingDate。
• コマース＆メンバーシップ（個別に日付が設定されている、上記参照）: hasMerchantReturnPolicy、hasShippingService、hasMemberProgram。

sameAs: その目的と、何を入れるべきか

sameAsはアイデンティティ確認のための手段です。Google自身の説明では、 “the URL of a page on another website with additional information about your organization” (翻訳) 「組織についての追加情報がある、別のウェブサイト上のページのURL」 であり、例としてソーシャルメディアやレビューサイトのプロフィールが挙げられています。schema.orgのより広い定義は少し厳密で、Wikipediaページ、Wikidata項目、公式ウェブサイトのように、 “unambiguously indicates the item’s identity,” (翻訳) 「対象のアイデンティティを明確に示す」 参照ページです。実務では、公式ソーシャルアカウント、Wikipedia、Wikidata、Crunchbase、LinkedInなど、組織を確実に表すページを指定してください。ただし、どちらの定義も全URLの所有を要求しません。運営していない検証済みWikipedia項目でも、組織を明確に識別するなら該当します。目的は曖昧性解消であり、リンク構築ではありません。

2つの注意点があります。第一に、sameAsはそれ自体がランキング要因ではなく、Knowledge Panelを保証するものではありません。これは、Googleが考慮する多くの裏付けシグナルの1つにすぎません。第二に、間違ったプロフィール（別の会社のページ、無関係なWikipediaエントリ）を指すsameAsは、エンティティのマッチングを積極的に混乱させる可能性があります。sameAsの値は、canonicalをテストするのと同じくらい注意深くテストしてください。

sameAsは、knowsAboutと混同されることもありますが、これはまったく別のプロパティです。sameAs = アイデンティティ（あなたがどのエンティティであるか）であり、knowsAbout = トピックに関する専門性（エンティティが何について知識があるか）です。これらは互換性がなく、同じ役割を果たすものではありません。

ロゴの要件とよくある失敗

ロゴには厳格な要件があります。Googleの資料では次のように定めています。 “the image must be 112x112px, at minimum. The image URL must be crawlable and indexable.” (翻訳) 「画像は最低112x112pxでなければなりません。画像URLはクロール可能かつインデックス可能でなければなりません。」 これが表面化せずに失敗するケースは次のとおりです。

• 小さすぎる — 112x112px未満の場合、JSON-LDが検証されても条件を満たしません。
• ブロックされている — 画像URLがrobots.txtで許可されていないか、Googleが解決できないリダイレクトチェーンの背後にあるため、取得できません。
• 間違った画像 — マークアップが、実際のページ上のロゴではないものを指しています。

JSON-LDブロックは完全に検証に合格しても、画像がこれらの条件を満たしていないために、希望するロゴが生成されないことがあります。

JSON-LDの例

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Co",
  "legalName": "Example Company, Inc.",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.crunchbase.com/organization/example"
  ]
}

それを一度だけ配置します（ホームページまたはアバウトページ）。address、contactPoint、および識別子は、正確な場合にのみ追加します。

グラフ全体でOrganizationノードを再利用する（任意）

サイトが複数のJSON-LDノード（WebSite、Person/著者ノード、Articleの発行者）を出力する場合、Organizationに安定した@idを付与し、完全なオブジェクトを繰り返す代わりに、他のノードから同じ@idを参照できます。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Co",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

これはGoogleの要件ではありません。Googleのドキュメントは@idや特定のグラフ構造を義務付けていません。これはグラフの衛生管理の実践です。複数のわずかに異なるコピーが同期しなくなるのではなく、他のノードが指す正規のOrganization定義を1つ持つことです。これ自体がランキングや対象資格を変更するものではありません。

Bingの対応

Bingはschema.orgマークアップ（JSON-LD、Microdata、RDFa）をサポートし、宣言された型に対して検証します。値が期待されるデータ型と一致しない場合、Bingのクローラーはその注釈を無視するため、公開前に検証してください。BingはGoogleのものに匹敵するOrganization専用のリファレンスを公開していないようです。Bingの一般的な構造化データヘルプが最も近い公式ソースです。このトピックのBing側は範囲が限られていると見なしてください。(BingのガイダンスはここではWebmaster Toolsヘルプから言い換えています。調査中に逐語的に再取得できませんでした。)

公開前に検証する

• リッチリザルトテスト — Googleが表示できるロゴ/組織要素をチェックします。
• スキーママークアップバリデータ — Organization型とそのすべてのプロパティを検証します（リッチリザルトかどうかに関係なく）。
• Google Search Console — デプロイ後の構造化データエラーを監視します。

検証によってマークアップが整形式であることが確認されます。ナレッジパネルが取得できることを確認できるわけではありません。それは、マークアップだけではなく、より広範な裏付けによって獲得されるものです。

AIまとめ

Advancedバージョンの簡潔な見解:

• 概要： schema.org/Organization（JSON-LD）は、ページ内容ではなく、名前、ロゴ、URL、sameAs、管理フィールドなどのサイト背後のエンティティを説明します。
• 機能： Googleは、“understand your organization’s administrative details and disambiguate your organization in search results.” (翻訳) 「組織の管理上の詳細を理解し、検索結果で組織を明確に区別する」 ために役立つと説明しています。一部のプロパティはナレッジパネルや帰属UIなどの視覚要素に影響する可能性がありますが、どちらも保証されません。ランキング要因ではありません。
• 必須プロパティなし： Googleは関連するものを追加するよう明記しています。実務上の推奨セットはname、logo、url、sameAsです。水増しより、簡潔で正確な方が優れます。
• 配置： ホームページまたはAboutページへ1回だけ配置し、全ページには複製しません。Muellerはサイト全体への重複をレビューマークアップのスパムになぞらえています（要約）。
• ロゴ： 112x112px以上で、クロール可能かつインデックス可能である必要があります。画像が小さい、またはブロックされていれば、JSON-LDが検証に通っても役立ちません。
• 2023年11月の拡張： 旧Logo資料をOrganizationへ統合し、address、legalName、duns、leiCode、naics、iso6523Code、numberOfEmployees、foundingDateを追加しました。コマース関連は別更新で後から追加され、hasMerchantReturnPolicyは2024年6月、hasMemberProgramは2025年6月、hasShippingServiceは2025年11月です。
• sameAs： Wikipedia、Wikidata、LinkedIn、Crunchbase、公式ソーシャルなど、組織を確実に表すページへリンクしてアイデンティティを確認します。所有ページだけには限定されません。ランキング要因でもパネルの保証でもなく、誤った対象はエンティティを混同します。knowsAbout（トピックの専門性。Googleの現在のOrganizationプロパティ表にはない）とは異なります。
• ナレッジパネル： 信頼できる情報源間の裏付けで獲得するもので、マークアップは入力の1つにすぎず、保証されたトリガーではありません。
• 関連タイプ： Entity & Identity Schema（ハブ）、LocalBusiness Schema（実店舗）、Person Schema（個人／著者）。
• 検証： Rich Results Test、schema.org Validator、Search Consoleを使います。

公式ドキュメント

検索エンジンからの一次情報ドキュメント。

Google

• Organization構造化データ — 中核となるリファレンス：定義、配置ガイダンス、「必須プロパティなし」の記述、曖昧さ回避と視覚的要素の区別、完全なプロパティリスト、112x112pxのロゴ要件。
• 構造化データの概要 — JSON-LDの推奨事項と、Googleが構造化データをエンティティ理解にどのように使用するか。
• Organizationの詳細に関するマークアップサポートの拡張（2023年11月） — LogoドキュメントをOrganizationに統合し、管理フィールドを追加した発表。
• Rich Results Test — 表示可能なorganization/logo要素をチェックします。
• Schema Markup Validator — Organizationタイプとすべてのプロパティを検証します。
• schema.org/Organization — ボキャブラリ自体。

Bing / Microsoft

• Bing Webmaster Tools — 構造化データヘルプ — schema.org / JSON-LDに対するBingの一般的なサポートと、そのタイプ検証動作。

ソースからの引用

GoogleのOrganization構造化データドキュメントからの公式声明。 これらは調査中にライブドキュメントページに対して検証されました。

Googleドキュメント — 目的

• “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.” (翻訳) 「ホームページにOrganization構造化データを追加すると、Googleが組織の管理上の詳細をよりよく理解し、検索結果で組織を明確に区別できるようになる可能性があります。」 — Google Search Central、Organization構造化データ。
• “We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don’t need to include it on every page of your site.” (翻訳) 「この情報はホームページ、または組織を説明する単一のページ（例：Aboutページ）に配置することを推奨します。サイトの全ページに含める必要はありません。」
• “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.” (翻訳) 「必須プロパティはありません。代わりに、組織に関連するプロパティをできるだけ多く追加することを推奨します。」
• “Some properties are used behind the scenes to disambiguate your organization from other organizations (like iso6523 and naics), while others can influence visual elements in Search results.” (翻訳) 「一部のプロパティは組織を他の組織から区別するために舞台裏で使われ（iso6523やnaicsなど）、ほかのプロパティは検索結果の視覚要素に影響する可能性があります。」
• “The image must be 112x112px, at minimum. The image URL must be crawlable and indexable.” (翻訳) 「画像は最低112x112pxでなければなりません。画像URLはクロール可能かつインデックス可能でなければなりません。」（logoについて）

Organizationスキーマのプロパティリファレンス

推奨コア（ID一致＋視覚的要素への影響の可能性）

その他のID／連絡先プロパティ

ビジネス識別子（曖昧性解消、2023年11月に追加／拡張）

組織レベルの事実（2023年11月に追加／拡張）

コマース＆メンバーシップ（それぞれ後で個別に追加 — 2023年11月のバッチではない）

クイックファクト

• 必須プロパティなし — 関連するものを追加。推奨コアは name、 logo、url、sameAs。
• 配置: GoogleはホームページまたはAboutページに1回を推奨 — すべてのページではない。
• ロゴ: 112x112px以上、クロール可能かつインデックス可能であること。
• 目的: 曖昧さの解消。一部のプロパティはナレッジパネルや帰属表示などの視覚要素に影響を与える可能性がある — ランキングには影響せず、保証もされない。
• パネルの保証なし: マークアップは入力の1つ。パネルは裏付けによって獲得される。
• sameAs ≠ knowsAbout: 同一性 vs トピックの専門性（knowsAboutはGoogleの現在のOrganizationプロパティテーブルにない）。
• 検証: リッチリザルトテスト + schema.orgバリデータ。

よくある間違い（実際の神話）

私が最もよく見る失敗パターン — それぞれが労力を無駄にしたり、静かにマークアップを壊す実際の方法です。

1. ナレッジパネルを保証されると期待する。 正しく完全なOrganizationスキーマでも、Googleがナレッジパネルを作成または更新することを強制しません。パネルは独立した信頼できる情報源の裏付けによって獲得されます。あなたのマークアップは1つの入力であり、トリガーではありません。マークアップを公開し、その後もエンティティの実世界での存在感を築き続けてください。

2. すべてのページに配置する。 これは最も一般的な構造上の間違いです。Googleのドキュメントでは、ホームページまたはAboutページに1回で十分とされており、Muellerはサイト全体に配置する傾向をレビューマークアップのスパムに例えています（言い換え）。どこにでも重複させても何も得られません。

3. 静かに失敗するロゴ。 JSON-LDは検証に合格しますが、ロゴが112x112px未満、robots.txtでブロックされている、壊れたリダイレクトの背後にある、または単に間違った画像です。Googleは取得できないものは使用できません — マークアップの検証は画像については何も示しません。

4. 間違ったsameAsターゲット。 sameAsはあなたの組織を確実に表すページ（Wikipedia、Wikidata、LinkedIn、Crunchbase、公式ソーシャル）を指すべきです — 自分が所有するページに厳密に限定されるものではありません。別の会社のページや無関係なエントリを指すと、あなたのエンティティが他人のものと混同される可能性があります — 省略するよりも悪いです。

5. ランキングのレバーとして扱う。 Organizationスキーマの文書化された目的は、曖昧さの解消と視覚的/表示要素であり、オーガニックランキングではありません。追加しても（またはすべてのプロパティを埋めても）順位は動きません。

6. 推測データで各プロパティを埋める。 必須プロパティはありません。疎でも正確なブロックは、発明した識別子や確信のない値で埋め尽くしたものより優れています。真実で関連性のあるものを追加し、残りは省略してください。

7. 間違ったエンティティやページをマークアップする。 Organizationは会社/ブランド自体のためのものです。営業時間のある物理的な場所にはLocalBusinessスキーマ（サブタイプ）を使用し、個人や著者にはPersonスキーマを使用します。また、ブロックは組織を表すページ（ホーム/About）に配置し、任意のコンテンツページには配置しないでください。

検証テスト

公開されたエンティティグラフをテストする

実行するテスト — Schema ValidatorでライブJSON-LDを解析します。期待される結果 — 有効なURLとサポート可能なプロパティのみを持つ、一貫性のあるOrganization ID。失敗の解釈 — プラグイン/テンプレートが重複や不正な値を生成しています。監視期間 — 即時。ロールバックトリガー — 変更が解析を壊したり、競合する組織IDを作成したりする場合は元に戻します。

ロゴとID参照をテストする

実行するテスト — 宣言されたロゴURLを取得し、urlとsameAsの宛先を確認します。期待される結果 — すべてのURLが公開され、成功し、表されている組織に属していること。失敗の解釈 — アセットが移動したか、IDリンクが古い/サポートされていない。監視期間 — 即時、およびブランド/ドメイン変更後。ロールバックトリガー — 誤解を招くID主張を残すのではなく、サポートされていない参照を削除します。

自分でテスト: Organizationスキーマ

Organizationスキーマ、Googleがそれを何に使うか、そしてそれを壊す間違いに関する5つの簡単な質問。それぞれに回答を選び、確認してください。

変更履歴