結論先出し: 手書きJSON-LD と プラグイン はどう選ぶ？

構造化データの実装方法を「手書きか、プラグインか」で悩んでいる人は多い。結論は 両立が現実最適解だ。WordPressで運用しているなら、Yoast SEOやRank MathでArticle・FAQPage・BreadcrumbListを即日カバーしつつ、LocalBusiness・Product・HowToなど業種特化が必要なスキーマはJSON-LDを直書きして補完する。

どちらか一方に絞る必要はない。プラグインは速度と安定性を担保し、手書きは制御の深さと拡張性を提供する。両者は補完関係にある。

短い判断ルール:

  • 手書きJSON-LDを選ぶべき人: 開発者が常駐している・プラグインが対応しない独自スキーマが必要・Headless CMS / Next.js で構築しており WordPress に依存していない
  • プラグインを選ぶべき人: WordPress を使っている・技術者なしで対応したい・まず基本スキーマを週内に実装したい
  • 両方を使うべき人: WordPress 運用中だが業種特化スキーマ（LocalBusiness・Product・Event等）が必要で、プラグインの標準テンプレでは不十分な場合

それぞれの本質

手書きJSON-LD とは

JSON-LD（JavaScript Object Notation for Linked Data）は、schema.org の語彙を使って構造化データをHTMLの <script type="application/ld+json"> タグ内に記述する形式だ。Googleが推奨する実装方式であり、HTMLの本文と分離して記述できるため保守性が高い。

※ 出典: Google Search Central — 構造化データの仕組み（取得 2026-05）

強み: @type・プロパティ・ネストを完全に制御できる。プラグインが未対応の業種特化スキーマ（Event・Recipe・VideoObject・JobPosting等）も実装できる。複数スキーマの複合や@graphによる一括出力など、高度な構成も可能。プラグイン同士の競合リスクがゼロ。

弱み: 実装・検証・保守に開発者リソースが必要。ページ数が多いサイトでは一括生成の仕組みが要る。schema.orgのアップデート追従も自前で行う必要がある。WordPressなら実装にfunctions.phpやカスタムプラグインが絡み、非技術者には敷居が高い。

プラグイン とは

Yoast SEO・Rank Math・SEOPress・All in One SEOに代表されるWordPressプラグインは、構造化データの自動生成機能を内包している。設定画面からON/OFFを切り替えるだけで、Article・WebSite・BreadcrumbList・Organization等の主要スキーマを即日デプロイできる。

強み: 技術知識なしで基本スキーマを導入できる。WordPressのコアアップデートにも追従してくれる。Rank Mathは無料版でFAQPage・HowToスキーマまでサポートする。Yoast・Rank Mathはschema.orgの主要スキーマの大半をカバーしており、中小企業の標準的なリッチリザルト対応には十分。

弱み: LocalBusiness の業種細分類（DentalClinic・LawFirm等）や独自プロパティは設定が難しい。複数のSEOプラグインを同時有効化すると重複スキーマが発生する。プラグインが廃止・有料化された場合の依存リスクがある。Headless CMSや Next.js環境では使えない。

比較表 — 主要軸で並べる

比較軸手書きJSON-LDプラグイン
実装速度遅い（開発工数が必要）速い（設定のみ・即日対応可）
検証容易性要Google Rich Results Testで手動確認プラグイン内のプレビュー機能で即確認
カスタム性高（任意の@typeとプロパティを制御可）低〜中（プラグインのテンプレ範囲内）
schema.orgバージョン追従自前で管理が必要プラグインの自動アップデートで追従
プラグイン依存リスクなしあり（廃止・有料化・競合リスク）
業種特化スキーマ対応（Event・Recipe・LocalBusiness詳細等）限定的（プラグインの対応状況による）
リッチリザルト対応範囲全スキーマに対応可能Article / FAQ / BreadcrumbList 等が主体
学習コスト高（JSON構文・schema.org語彙の理解が必要）低（GUI操作のみ）
既存サイト適用のしやすさ中（PHP・テンプレート改修が必要）高（プラグインをインストールするだけ）
重複スキーマリスク低（自分で管理するため把握できる）高（複数プラグイン同時有効時に発生しやすい）

リッチリザルト対象スキーマ 10件

Google検索でリッチリザルトが表示される代表的なschema.orgスキーマを整理する。

※ 出典: Google Search Central — リッチリザルトの種類（取得 2026-05）

スキーマリッチリザルトの表示内容プラグイン対応手書き推奨度
FAQPage質問・回答の展開表示Rank Math 無料版で対応共存可
Article / BlogPosting記事のサムネイル・著者・日付Yoast / Rank Math で対応共存可
LocalBusiness営業時間・住所・電話番号設定が限定的手書き推奨
Product価格・在庫・評価WooCommerce連携で部分対応手書き補完推奨
BreadcrumbListパンくずリストの表示Yoast / Rank Math で対応共存可
Review / AggregateRating星評価の表示一部プラグインで対応手書き推奨
HowTo手順のステップ表示Rank Math 無料版で対応共存可
Recipe調理時間・カロリー・材料専用プラグインあり手書き推奨
VideoObject動画のサムネイル・再生時間限定的手書き推奨
Eventイベント日時・場所・チケット限定的手書き推奨

コピペで使えるJSON-LDテンプレ 3種

テンプレ1: FAQPage

json
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データを実装するとどのような効果がありますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Googleの検索結果でリッチリザルト（FAQ展開表示・パンくず等）が表示されるようになります。検索結果での視認性が上がります。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LDとMicrodataはどちらが推奨ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Googleはいずれも対応していますが、HTMLと分離して記述できるJSON-LDを推奨しています。"
      }
    }
  ]
}
</script>

テンプレ2: LocalBusiness（店舗・事務所向け）

json
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "店舗名・事務所名",
  "url": "https://example.co.jp",
  "telephone": "03-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "〇〇区〇〇1-2-3",
    "addressLocality": "〇〇市",
    "addressRegion": "東京都",
    "postalCode": "000-0000",
    "addressCountry": "JP"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.6895,
    "longitude": 139.6917
  }
}
</script>

テンプレ3: Article（ブログ・コラム向け）

json
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトル（110文字以内）",
  "description": "記事の要約文（160文字以内）",
  "datePublished": "2026-05-10",
  "dateModified": "2026-05-10",
  "author": {
    "@type": "Organization",
    "name": "Tufe Company",
    "url": "https://tufecompany.co.jp"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tufe Company",
    "logo": {
      "@type": "ImageObject",
      "url": "https://tufecompany.co.jp/logo.png"
    }
  },
  "image": {
    "@type": "ImageObject",
    "url": "https://example.co.jp/ogp.png",
    "width": 1200,
    "height": 630
  },
  "url": "https://example.co.jp/blog/article-slug"
}
</script>

構造化データ実装セルフチェック（10項目）

リッチリザルト獲得に向けた現状確認リスト。Google Rich Results Testで各ページを検証しながら確認する。

  • 1. 主要ページにJSON-LDが挿入されているか — ソース表示で <script type="application/ld+json"> を確認
  • 2. Article/BlogPostingスキーマにauthor・datePublished・publisherがすべて含まれているか — 不足があるとリッチリザルトが表示されない
  • 3. FAQPageスキーマがQ&Aコンテンツのあるページに設定されているか — FAQ見出しがあるだけでは不十分
  • 4. BreadcrumbListが全ページに設定されているか — 検索結果のURL表示をパンくず形式にできる
  • 5. LocalBusinessスキーマに住所・電話番号・営業時間が含まれているか — 店舗・事務所は必須
  • 6. 重複スキーマが発生していないか — 複数プラグイン同時有効化や手書きとプラグインの競合を確認
  • 7. Google Rich Results Testでエラー・警告が0件か — 公式テストツールで必ず検証
  • 8. schema.orgの必須プロパティがすべて含まれているか — 型ごとに必須・推奨プロパティが異なる
  • 9. ProductスキーマにAggregateRating（評価）が含まれているか（ECの場合） — 星評価表示に必要
  • 10. VideoObjectスキーマにthumbnailUrl・uploadDate・durationが含まれているか（動画の場合）

5項目以下: まずプラグインで基本スキーマを即日実装することを優先する。 8項目以上: 業種特化スキーマの手書き補完と、Google Search Centralの最新ガイドラインの確認フェーズ。

使い分けフローチャート

以下の順番で判断する。

code
Q1. WordPressを使っているか？
  NO  →「手書きJSON-LD」一択（Headless CMS / Next.js等の場合）
  YES → Q2へ

Q2. 開発者が常駐しているか？
  NO  →「プラグイン主体」でまず基本スキーマをカバー
       ↓
       業種特化スキーマが必要ならQ3へ
  YES → Q3へ

Q3. LocalBusiness・Product・Event・Recipeなど業種特化スキーマが必要か？
  NO  →「プラグイン」で完結（基本スキーマは充分）
  YES →「プラグイン（基本カバー）＋手書きJSON-LD（業種特化）」の両立

Q4. サイトのページ数は100以上か？
  YES → 手書きの場合は一括生成の仕組み（テンプレートエンジン・動的出力）が必要
       プラグインならページ数が多くても設定は一度で済む

ケース別: あなたはどちらを選ぶべきか

ケース1: WordPressで飲食店・クリニック・士業のサイトを運用している

→ プラグイン＋手書き補完を推奨。Yoast SEOまたはRank Mathを入れて Article・BreadcrumbList・FAQPageを即日カバーする。LocalBusiness の業種詳細型（Restaurant・MedicalBusiness・LegalService等）はプラグインが対応しきれないケースが多い。functions.php または専用ショートコードプラグインで手書きJSON-LDを追加し、営業時間・対応エリア・サービス詳細を補完する。両方使うことでリッチリザルトの取得範囲が広がる。

ケース2: Next.js / Headless CMSで新規サイトを構築している

→ 手書きJSON-LDを推奨。WordPressプラグインは使えないため、開発者がJSONオブジェクトをコードで生成し、<script type="application/ld+json"> タグとして出力する。Next.js App Routerなら app/layout.tsx でOrganization・WebSiteスキーマを一括出力し、各ページの page.tsx でArticle・FAQPageを動的生成するパターンが標準的だ。@graph を使えば複数スキーマを1つの <script> にまとめられるため、HTTP応答サイズも最適化できる。

ケース3: WordPressで運用中だが、SEOプラグインを何本も入れてしまっている

→ 整理してからプラグイン1本に絞ることを推奨。Yoast + Rank Math + All in One SEOを同時有効化している場合、同じページに同じ@typeのスキーマが複数出力される「重複スキーマ」が発生する。Googleはエラーとして警告する場合があり、リッチリザルトが無効化されるリスクもある。まずGoogle Rich Results Testで重複を確認し、SEOプラグインは1本に絞ってから、不足分を手書きJSON-LDで補完する構成に整理する。

失敗パターン 5件

失敗1: 複数SEOプラグインの同時有効化による重複スキーマ

Yoast SEO と Rank Math を同時に有効化すると、同じページに Article スキーマが二重で出力される。Google Rich Results Test で警告が出るが気づかずに放置しているケースが多い。SEOプラグインは1本に絞ること。

失敗2: 手書きJSON-LDとプラグインが同じ@typeを出力している

プラグインを入れたままカスタムJSON-LDを <head> に追加すると、同じ@typeが2つ出力されて重複スキーマになる。プラグインのスキーマ出力機能をOFFにしてから手書きに移行するか、プラグインが対応しない@typeだけを手書きで補完する。

失敗3: Article スキーマの必須プロパティ不足

author・datePublished・headlineのうち一つでも欠けると、Googleのリッチリザルトテストでエラーが出てリッチリザルトが表示されない。特にauthorを省略しているケースが多い。E-E-A-Tの観点からも著者情報は必須だ。

※ 出典: Google Search Central — Article 構造化データ（取得 2026-05）

失敗4: リッチリザルトが「落ちた」と思ったらプラグインのアップデートが原因

SEOプラグインのメジャーアップデートでスキーマの出力形式が変わり、一時的にリッチリザルトが消えることがある。アップデート後は必ずRich Results Testで確認する習慣をつける。

失敗5: LocalBusinessの@typeが汎用すぎてリッチリザルトに表示されない

"@type": "LocalBusiness" は汎用型だ。クリニックなら MedicalClinic、弁護士なら LegalService、レストランなら FoodEstablishment のように業種別サブタイプを使うと、より詳細なリッチリザルトが適用される可能性がある。

※ 出典: schema.org — LocalBusiness（取得 2026-05）

公的リソース集

併用する場合の設計

プラグイン（基本スキーマ）と手書きJSON-LD（業種特化スキーマ）を併用するときの設計原則は「同じ@typeを二重出力しない」ことだ。

推奨構成:

  1. プラグイン担当: Article・WebSite・BreadcrumbList・Organization（プラグインに任せて自動追従させる）
  2. 手書き担当: LocalBusiness（業種詳細型）・Product・Event・VideoObject・HowTo・Recipe（プラグインが弱い業種特化スキーマ）

プラグイン側の設定でデフォルトONになっているスキーマのうち、手書きで置き換えるものだけをOFFに切り替える。Yoast SEO ならサイト設定→「高度な設定」でスキーマ種別ごとにOFF可能。Rank Mathなら「Schema」タブからページタイプ別に制御できる。

WordPress以外の環境（Next.js等）では、app/layout.tsx でサイトレベルのスキーマを、generateMetadata() または各ページコンポーネント内でページレベルのスキーマを出力する構成が標準的だ。headless-cms-vs-wordpress-plugin-llmoの記事にある @graph 構成が参考になる。

よくある誤解

誤解1: 「構造化データを入れればすぐ検索順位が上がる」

構造化データは検索順位の直接的なランキングシグナルではない。リッチリザルトによって検索結果での視認性と CTR が改善されることが主な効果だ。順位そのものはコンテンツ品質・被リンク・E-E-A-Tなど別の要因で決まる。構造化データはクリックを増やすための手段であり、コンテンツが伴わなければリッチリザルトが表示されても問い合わせにはつながらない。

誤解2: 「プラグインを入れれば構造化データは完了」

プラグインが自動出力するのは汎用テンプレートだ。LocalBusinessの業種詳細プロパティ・Productのoffers情報・FAQのQ&Aテキストなどは、サイト固有の内容を入力しなければ正しく機能しない。プラグインを「入れた」後に設定を確認し、Google Rich Results Testでエラーがないかを必ず検証することが必要だ。

誤解3: 「手書きJSON-LDは上級者向けで中小企業には無理」

FAQPage・LocalBusiness・Article のテンプレートは本記事のコピペ欄から直接使えるレベルだ。<head> タグ内に <script type="application/ld+json"> を1行追加するだけで完了する。難しいのは複合スキーマや動的ページへの一括実装の場面であり、静的な店舗情報の1ページであれば非エンジニアでも10分で実装できる。

よくある質問

Q1. コストはどちらが安い？

プラグインは無料（Yoast SEO・Rank Math の基本機能は無料版で対応可能）。手書きJSON-LDは開発者の工数が発生する分コストがかかる。ただし手書きは一度実装すれば月額コストが発生しない。大量ページへの一括適用は開発工数がまとまってかかるため、初期コストの比較では「プラグイン < 手書き」が一般的だ。

Q2. 始めるならどちらが早い？

プラグインが圧倒的に速い。WordPressにYoast SEOまたはRank Mathをインストールして有効化すれば、Article・BreadcrumbList・WebSiteスキーマが即日出力される。手書きの場合はJSONを書いて <head> に挿入し、Rich Results Testで検証するまで最低数時間かかる。「まず今週中にリッチリザルト対応したい」ならプラグインから始める。

Q3. 両方使う場合の優先順位は？

  1. プラグインをインストールして基本スキーマを有効化する
  2. Rich Results Testで現状のエラー・警告を確認する
  3. プラグインが対応しきれない業種特化スキーマを特定する
  4. 該当スキーマだけを手書きJSON-LDで追加し、プラグイン側の同じ@typeをOFFにする
  5. 再度Rich Results Testで重複スキーマがないことを確認する

Q4. 将来性はどちらにあるか？

どちらもschema.orgのアップデートに継続的に追従する必要がある点は同じだ。AI検索（ChatGPT Search・Perplexity・Gemini等）が構造化データを引用ソースとして活用する方向性は強まっており、FAQPage・Article・LocalBusinessの精度向上が引き続き重要になる。プラグインは自動追従が強みだが、新スキーマへの対応には時差が生じることもある。手書きはschema.orgのリリース直後に対応できる柔軟性がある。

Tufe Companyが提供する両方のソリューション

Tufe Companyは手書きJSON-LDの実装支援とSEOプラグイン導入支援の両方を提供している。サイトの状況と目的に合わせて最適な実装方針を提案する。

Stripe 商品（即購入・即納品）:

  • Schema Markup Library — 業種別JSON-LDテンプレ集（コピペ可）。歯科・飲食・士業・EC・不動産など主要業種のLocalBusiness・Product・FAQPage等をすぐに使える形で提供。実装の手間を最小化する。
  • AI Search Integration Pack — llms.txt + 構造化データの入門パック。AI検索（Perplexity・ChatGPT Search等）への引用適性を高めるための基盤整備をパッケージ化。構造化データ未実装のサイトへの最初の一歩として設計されている。
  • LLMO Optimization Pack — AI引用最適化のフルパック。構造化データだけでなく、E-E-A-T・コンテンツ構造・llms.txt・AI検索全体の最適化を一括対応するフルメニュー。

サービスとして依頼する場合:

関連記事・比較:

グロッサリー（用語解説）:

ツール:

まとめ: 決定のためのチェックリスト

  • WordPress サイトか？ → YES なら Yoast / Rank Math でまず基本スキーマをカバーする
  • 開発者リソースがあるか？ → YES なら業種特化スキーマは手書きJSON-LDで補完する
  • LocalBusiness / Product / Event など業種特化スキーマが必要か？ → YES なら手書き必須
  • 複数SEOプラグインが同時に有効化されていないか？ → 重複スキーマの有無をRich Results Testで確認
  • Article スキーマに author・datePublished・publisher の3点が揃っているか？ → 欠けているとリッチリザルト非表示

判断に迷ったら、無料相談 で御社の状況に最適な構成をご提案します。