中小企業の構造化データ入門 JSON-LDの組み立て方から確認・監視まで【2026年10月版】

「構造化データを入れると、検索で目立つらしい」。

Webサイトの担当を兼務している方から、こうした相談をよくいただきます。

構造化データは、ページの中身を検索エンジンに正しく伝える仕組みです。一方でGoogleは、ここ数年で、よくある質問（FAQ）や手順（HowTo）などの特別な表示を次々に縮小・終了しました。

古い解説をそのまま真似ると、手間に見合わないことがあります。

この記事では、2026年10月17日に確かめたGoogleの公式ドキュメントと公式ブログをもとに、中小企業のサイトで「何を、どこに、どう入れて、どう確かめるか」を整理します。

コードそのものは掲載しません。書く項目と値を表にまとめ、実際のコード例はGoogleの公式ドキュメントのものを使う形にしています。

公式の内容は更新されます。実際に入れる前に、最新のドキュメントも合わせて確認してください。

先に結論 入れる型は絞り、確認と監視まで一続きで考える

最初に、この記事の結論を表にまとめます。

決めること	結論	理由
書き方の形式	JSON-LDを使う	公式の入門ページが、実装と管理が最も容易な形式として勧めている
最初に検討する型	Organization、LocalBusiness、BreadcrumbList、Article	必須の項目が少なく、会社のサイトに当てはまりやすい
商品とイベント	条件を確かめてから決める	対象になるページと地域に、公式の決まりがある
終了した表示	新しい作業をしない	FAQやHowToなどは、検索結果に出なくなっている
確認の道具	リッチリザルトテストとSchema Markup Validator	目的が違う2つの道具を、公式が案内している
公開後	Search Consoleのレポートを月1回見る	問題の件数が増えていないかを追える

どれも、特別な技術は要りません。順番に進めれば、現状の点検から始められます。

全体の流れ

作業は、調べる、選ぶ、入れる、確かめる、見直すの順に進めます。

最初の1手

いきなり新しいコードを書く前に、今のサイトが何を出力しているかを調べます。

WordPressのテーマやプラグインが、すでに出力している場合があるからです。

この記事で扱わないこと

専用のソフトの使い方や、ECサイトの商品データの大規模な運用は扱いません。

扱うのは、会社の公式サイトとブログで、手作業でも管理できる範囲です。

構造化データとは何か

構造化データは、ページに書かれている情報に、機械が読めるラベルを付けたものです。

ページの内容に付ける「ラベル」

人が読めば「これは会社の住所だ」と分かる文字列も、プログラムには、ただの文字の並びです。

そこで「この文字列は住所」「これは開始日時」とラベルを付けて伝えます。

ラベルの語彙として広く使われているのが、schema.orgです。Googleの検索も、この語彙を使った構造化データを読み取ります。

リッチリザルトとの関係

Googleは、構造化データを手がかりに、検索結果に特別な表示をすることがあります。これをリッチリザルトと呼びます。

代表例は、商品の価格や評価、イベントの日程、パンくず（サイト内の階層）です。

ただし、公式の一般ガイドラインには、構造化データが検索結果に表示されるとは限らないと書かれています。リッチリザルトテストに沿って正しくマークアップしても、表示されない場合があります。

表示されない主な理由

公式ガイドラインが挙げる理由を、表にまとめます。

理由	内容
ページの主要な内容を表していない	構造化データがページの中身と合っていない、または誤解を与えている
検出できない誤りがある	リッチリザルトテストでは見つからない誤りがある
見えない内容を参照している	構造化データが指す内容が、利用者に表示されていない
ガイドラインに従っていない	一般のガイドライン、機能ごとのガイドライン、検索の基本事項、コンテンツポリシーのいずれかに反している
検索ごとの判断	検索履歴、位置情報、端末の種類などに応じて、Googleのしくみが表示を調整する

つまり、構造化データは「表示の条件を整える作業」であり、表示を約束するものではありません。

JSON-LDを使う理由と組み立て方

Google検索で使える形式は、JSON-LD、microdata、RDFaの3つです。

3つの形式の違い

公式の入門ページは、一般的に、実装と管理が最も容易な形式を推奨するとして、多くの場合はJSON-LDを挙げています。

形式	書く場所	特徴
JSON-LD	ページ内のscriptタグの中	本文のHTMLを触らずに追加でき、入れ子の項目も書きやすい
microdata	本文のHTMLの属性	本文の要素に属性を足して名前を付ける
RDFa	本文のHTMLの属性	microdataと同様に、HTMLの属性で書く

公式は、マークアップが有効で、機能のドキュメントに沿って実装されていれば、3つの形式のどれも有効だと説明しています。

すでにmicrodataで入れているサイトを、急いで書き換える必要はありません。

JSON-LDの組み立て方

JSON-LDは、<script type="application/ld+json"> というタグの中に、まとめて書きます。

タグは、ページのheadの中にもbodyの中にも置けます。公式の入門ページは、CMSのスクリプトや埋め込みウィジェットで動的に挿入されたJSON-LDも、Googleが読み取れると説明しています。

中身は、次の部品の組み合わせです。

部品	役割	書き方のポイント
@context	語彙の指定	schema.orgを指すURLを書く
@type	何についての情報か	OrganizationやArticleなどの型名を書く
各項目	型ごとの情報	nameやurlなど、型のドキュメントにある項目を書く
入れ子	項目の中の項目	住所のように、まとまりのある情報は、中に型を持たせる

書く前に決めること

書く前に、次の3つを決めておきます。

• どのページに、どの型を入れるか
• 値の元になる情報を、どこで管理するか
• 情報が変わったときの、更新の担当者

値は、ページに書いてある内容と必ず一致させます。

中小企業が検討しやすい型と、その役割

Googleが対応している型は多くあります。一般的な中小企業や、法人向けの商売をするサイトで検討しやすい型を、表にまとめます。

型（@type）	主に置くページ	伝える内容	公式の必須項目
Organization	トップページ、会社概要	会社名、ロゴ、URL、連絡先、住所、SNSなど	なし
LocalBusiness	店舗や事務所のページ	所在地、営業時間、電話番号	name、address
BreadcrumbList	下層のページ	サイト内の階層	itemListElement（2つ以上のListItem）
Article	ブログ、お知らせ	見出し、著者、公開日、更新日、画像	なし
Product	商品のページ	商品名、価格、評価	機能によって違う
Event	告知のページ	イベント名、日時、会場	name、startDate、location

必須項目が「なし」の型でも、何も書かなくてよいという意味ではありません。公式は、ページに当てはまる推奨項目を、できるだけ多く指定するよう案内しています。

Organization 会社そのものの情報

Organizationは、会社や団体についての情報です。

公式のドキュメントには、必須の項目はなく、当てはまる項目を追加するよう書かれています。認識される項目には、name、legalName、url、logo、address、telephone、email、sameAs、foundingDateなどがあります。

sameAsは、自社について書かれた、ほかのページを指す項目です。自社のSNSのページなどが当てはまります。

LocalBusiness 店舗や事務所がある会社向け

来店や訪問を受け付ける拠点があるなら、LocalBusinessが候補です。

公式のOrganizationのページは、実店舗などのローカルビジネスには、LocalBusinessの下位の型のうち、最も当てはまるものを使うよう案内しています。

LocalBusinessの必須項目は、nameとaddressです。営業時間はopeningHoursSpecificationで書けます。

営業時間の書き方で気をつけること

公式のドキュメントには、休業日と期間限定の休みの書き方が示されています。

場面	公式の示す書き方
終日の休業	opensとclosesの両方を「00:00」にする
24時間の営業	opensを「00:00」、closesを「23:59」にする
年末年始の休み	validFromとvalidThroughの両方で期間を指定する

営業時間は、変わるたびに、本文と構造化データの両方を直す必要があります。

BreadcrumbList サイト内の階層

パンくずリストの構造化データです。

公式は、少なくとも2つのListItemを含むBreadcrumbListを定義するよう案内しています。各ListItemには、position、name、itemを書きます。

最後の項目（そのページ自身）は、itemを省略できます。省略すると、Googleはそのページ自身のURLを使います。

モバイルでパンくずが出なくなった件

2025年1月、Googleはモバイルの検索結果でパンくずを表示しない変更をしました。公式のドキュメントには、この機能がパソコン版の検索に対応したものだと書かれています。

スマートフォンでパンくずが出なくても、マークアップが壊れているとは限りません。

Article ブログやお知らせの記事

記事のページには、Article、NewsArticle、BlogPostingのいずれかの型を使います。

必須項目はなく、author、dateModified、datePublishedなどが推奨項目です。日付はISO 8601の形式で、タイムゾーンも付けて書くよう案内されています。

著者を書くときは、author.nameに名前を、author.urlに著者を識別できるページを指定します。自社内のプロフィールページを指す場合は、そのページにも構造化データを付けることが勧められています。

Product 商品のページ

商品に関する機能は、大きく2つに分かれます。

機能	対象のページ	公式の条件
商品スニペット	商品の紹介や、レビューのページ	review、aggregateRating、offersのいずれか1つが必須
販売者リスティング	買い物客が商品を購入できるページ	0より大きな値の価格が必要

法人向けで、価格を公開せず見積もりで対応する商品は、販売者リスティングの条件を満たしません。

価格がないのに、架空の価格を入れることは避けてください。

Event イベントの告知

セミナーや展示会の告知に使いたくなる型ですが、公式の条件を先に確認します。

条件	公式ガイドラインの内容
公開の範囲	誰でも予約できること。会員登録や招待が必要なイベントは対象外
開催の場所	現実の場所で開催されること。完全なオンラインのイベントは対象外
ページの構成	イベントごとに固有のURLを持つ、1つのイベントのページ
提供地域	公式の一覧に、日本は含まれていない（2026年10月17日時点）

このため、日本の中小企業が自社のセミナー告知に付けても、イベントの検索表示は期待しにくいのが実情です。

必須項目は、name、startDate、locationです。それでも付ける場合は、本文の内容と一致させます。

ページの種類ごとの対応表

ここまでを、ページの種類別にまとめます。

ページの種類	候補の型	進め方
トップページ	Organization	会社の基本情報を、本文と同じ内容で書く
会社概要	Organization	住所、電話、設立年などが本文にある場合に書く
拠点のページ	LocalBusiness	所在地と営業時間を、本文と一致させる
サービスの下層ページ	BreadcrumbList	パンくずの表示がある場合に、同じ階層を書く
ブログ、お知らせ	Article	公開日、更新日、著者を、本文と一致させる
商品のページ	Product	購入できるか、価格を公開しているかで選ぶ
セミナーの告知	付けなくてよい	提供地域と公開の条件を満たさない場合は見送る

ここでの進め方は、公式の条件をもとに、弊社が整理した目安です。自社のサイトに当てはまるかは、各型のドキュメントで確かめてください。

2026年10月時点で終了・縮小した表示

「FAQを入れて、検索結果を広く取ろう」という数年前の助言は、現在は当てはまりません。

Googleの公式ブログとドキュメントの更新履歴で確かめられた、主な変化を時系列で並べます。

時期	内容
2023年8月	FAQのリッチリザルトは、よく知られた権威ある政府・健康関連のサイトにだけ表示。HowToはパソコンだけに
2023年9月	HowToはパソコンでも表示されなくなり、廃止。HowToの構造化データのドキュメントも削除
2024年11月	サイトリンク検索ボックスの表示を、11月21日から終了
2025年1月	モバイルの検索結果でのパンくず表示を終了。パソコンでは継続
2025年6月	Course Info、ClaimReview、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing、Book Actionsを段階的に終了すると発表
2025年11月	Practice Problem、Datasetの段階的な終了を案内。2026年1月から、Search Consoleでの扱いも終了
2026年5月	FAQリッチリザルトの廃止を告知。2026年5月7日から検索結果に表示されない
2026年6月	FAQリッチリザルトのドキュメントを削除

2025年6月の発表に含まれていたBook Actionsは、2025年11月に、廃止予定の表示が外されています。Google検索で、このマークアップを使う機能がまだあるためです。

2025年6月の発表について、公式ブログは、この変更がページの順位に影響しないと説明しています。

すでに入れているFAQやHowToはどうするか

2023年の公式ブログは、FAQの構造化データを、あえて急いで削除する必要はないと説明していました。使われていない構造化データは、検索に問題を起こさない一方で、見た目にも影響しません。

サイトリンク検索ボックスの終了のときも、マークアップの削除は不要と説明されています。

実務では、次のように考えるのが現実的です。

• 既存のマークアップは、サイトの改修のついでに整理する
• 新しいFAQやHowToのマークアップを増やす作業には、工数をかけない
• 終了した機能のためだけに、新しい測定や報告の作業をしない

ページ上の「よくある質問」は残してよい

構造化データと本文は、別の話です。

読者の役に立つ「よくある質問」の文章は、構造化データがなくても、残す価値があります。

守るべき一般ガイドライン

構造化データは、Googleの一般ガイドラインに沿っている必要があります。

中小企業のサイトに関わりそうな点を挙げます。

見えない内容を入れない

ガイドラインは、ページの読者に表示されない内容をマークアップしないよう求めています。

公式の例では、JSON-LDで出演者を書いたなら、HTMLの本文にも同じ出演者が書かれている必要があります。

本文に書いていないのに、検索エンジン向けに営業時間だけ入れる、という使い方は避けます。

無関係な内容や誤解を招く内容を入れない

ページの主題と関係のない内容や、虚偽のレビューのような誤解を招く内容も、マークアップしてはいけません。

構造化データを使って、利用者を欺いたり、誤解させたりすることも禁じられています。他人や組織へのなりすましも、同じです。

必須項目は全部、推奨項目は多く

公式は、機能ごとのドキュメントに書かれた必須項目を、すべて指定するよう求めています。必須項目が欠けているアイテムは、リッチリザルトに表示されません。

推奨項目は、指定するほど、表示される検索結果の質が高くなると説明されています。ただし、ページに無い情報を、埋めるために作ってはいけません。

自社のレビューに星を付けたい場合

ここは誤解の多いところです。

LocalBusinessやOrganizationの構造化データで、評価の対象になる事業者が、自社へのレビューを管理している場合、そのページは星のレビュー表示の対象になりません。

ケース	公式の扱い
自社サイトに、自社へのお客様の声の評価を書く	星の表示の対象外
第三者のウィジェットで、Googleビジネスプロフィールなどの口コミを埋め込む	同じく対象外
ほかの事業者のレビューを集めるサイト	対象になりうる

2019年の公式ブログは、すでに入れているマークアップを削除する必要はなく、このことだけで手動による対策を受けることもないと説明しています。

2026年7月に加わった新しいガイドライン

2026年7月24日に、レビュースニペットのドキュメントへ、新しいガイドラインが加わりました。

偽のレビューや、見返りを明確に開示していないレビューを、ページや構造化データに含めないという内容です。

例として、実際の利用体験に基づかないレビューと、金銭や割引などの見返りで書かれたのに、それを目立つ形で開示していないレビューが挙げられています。

ガイドラインに違反するとどうなるか

構造化データの問題があるページは、手動による対策の対象になることがあります。

手動による対策を受けると、そのページはリッチリザルトとして表示されなくなります。ただし、公式は、ウェブ検索での掲載順位には影響しないと説明しています。

対策を受けたかどうかは、Search Consoleの手動による対策のレポートで確認できます。

WordPressでの入れ方の考え方

公式の入門ページは、WixやWordPressなどのCMSを使っている場合、HTMLを直接編集できないことがあると説明しています。

その場合は、CMSの検索エンジン向けの設定ページや、構造化データを指定できるプラグインを使う方法が案内されています。

実務では、次の順で考えると混乱しにくくなります。ここからは、弊社の進め方の目安です。

手順1 今あるものを調べる

テーマやプラグインが、すでに構造化データを出力している場合があります。

まず、後述のテストの道具で、自社のページから何が読み取れるかを確かめます。

手順2 重複を避ける

プラグインが出力している型を、手書きでもう1つ足すと、内容が食い違う原因になります。

足りない項目は、可能ならプラグインの設定で補います。

手順3 足りない型だけを追加する

拠点のページのLocalBusinessなど、ページ単位で足したい場合は、ページごとにJSON-LDを追加できる仕組みを使います。

カスタムHTMLのブロックや、テーマの機能などが候補です。

手順4 更新の担当を決める

営業時間、住所、日付が変わったとき、本文と構造化データの両方を直す担当と手順を決めます。

本文だけ直して、構造化データが古いままになるのが、起きやすい失敗です。

テーマやプラグインを更新したあとは、出力を確かめ直します。

公開前後の確認 2つのテストの道具

Googleは、目的の異なる2つの道具を案内しています。

道具	提供元	分かること
リッチリザルトテスト（Rich Results Test）	Google	そのページの構造化データから、どのリッチリザルトが生成されうるか。誤りと提案
Schema Markup Validator	schema.org（Googleが提供するサービス）	Google固有の判定を除いて、schema.orgの書き方として正しいか

公式は、まずリッチリザルトテストで、Googleのリッチリザルトが生成されるかを確かめ、汎用的な文法の確認にはSchema Markup Validatorを使うよう案内しています。

リッチリザルトテストの使い方

リッチリザルトテストは、JSON-LD、RDFa、microdataに対応しています。

ページのURLを入れる方法と、コードを貼り付ける方法があります。コードの貼り付けは、公開前の確認に向いています。

確認の観点	公式ヘルプの内容
端末の種類	初期設定はスマートフォン。パソコンも選べる
取得できない場合	robots.txtやnoindexでクロールが止められているページは、テストできない
ページの資源	パスワードの内側にあるなど、匿名では見られない資源は、テストでも使えない
コメント	JSON-LDの中のコメントは、ツールは無視するが、標準では想定されていないので公開前に消す

Schema Markup Validatorの使い方

Schema Markup Validatorは、Googleが以前提供していた構造化データテストツールを元にした、schema.orgのツールです。

公式のページによると、JSON-LD、RDFa、microdataを取り出し、書き方の誤りを見つけます。JavaScriptで挿入されたデータも取り出せます。

Googleのリッチリザルト向けの判定は含まれていません。

確認の手順

公開の前後で、次の順に確認します。

順番	確認すること	方法
1	公開前のコードの書き方	コードを貼り付けて、リッチリザルトテストで確かめる
2	公開後の実ページ	URLを入れて、読み取れているかを確かめる
3	誤りの修正	誤りは必ず直し、足りない推奨項目はページにある情報なら足す
4	値と見た目の一致	会社名、住所、日時が、ページの見た目と合っているかを目で確かめる

テストを通っても、表示は約束されない

テストに通っても、リッチリザルトが表示されるとは限りません。

前述のとおり、品質に関するガイドラインは、自動の道具では簡単に確かめられません。最後は、人の目で確認します。

公開後の監視 Search Consoleのレポート

公開した後は、Search Consoleで状態を追います。

レポートの見方

Search Consoleには、リッチリザルトの種類ごとのレポートがあります。

公式のヘルプでは、これらのレポートは、ナビゲーションのEnhancements（拡張）の下にあります。商品スニペットと販売者リスティングは、Shoppingの下にあります。

項目	内容
表示される条件	Googleが有効なマークアップを見つけ、サポート対象のリッチリザルトの種類であるとき
数字の単位	検出された項目の数（ページ数は表さない）
一覧の性質	検出された項目の一部（サンプル）
一覧にないURL	URL検査ツールで、構造化データが検出されているかを確かめる

問題が出たときの直し方

公式ヘルプは、問題の修正と検証の流れを、次のように案内しています。

• レポートで問題をクリックし、影響を受けているページを見る
• 1つの問題を、関係するすべてのURLで先に直す
• テンプレートの誤りなら、テンプレートを直すと、関連するページがまとめて直る
• URL検査ツールのライブテストで、直ったことを確かめる
• 問題の詳細ページで、修正の検証（Validate fix）を始める

Googleは、まずサンプルのページを確かめ、通れば残りのページも確かめます。

月1回の点検表

月に1回、次の点検を行います。

確認すること	見るところ
無効な項目	各レポートで、無効な項目が増えていないか
修正の検証	問題を直したあと、修正の検証を始めたか
項目数	サイトの改修やプラグインの更新のあとに、急に減っていないか
手動による対策	レポートに、何も表示されていないか
情報の更新	営業時間、住所、日程の変更を、構造化データにも反映したか
終了した表示	FAQやHowToのために、新しい作業をしていないか

「入れれば順位が上がる」とは言えない

最後に、期待の置き方を整理します。

公式の一般ガイドラインが説明しているのは、リッチリザルトとして表示されるための条件と、手動による対策の影響の範囲です。手動による対策は、ページのリッチリザルトの表示に関わり、ウェブ検索の掲載順位には影響しないと説明されています。

この記事は、構造化データを入れれば順位が上がる、とは約束しません。

本文が先、構造化データは補助

構造化データは、ページの内容を正確に伝えるための補助です。

会社の情報、所在地、営業時間、日付が、本文に分かりやすく書かれていることが前提になります。

売れるサイトはみな謙虚 入れる型も足さずに引く

ここまで、入れる型と確認の手順を整理してきました。この考え方に、名前を付けて紹介します。

「売れるサイトはみな謙虚」という考え方です。大きく見せる言葉や機能を足していくより、訪れた人が迷う要素を引いていくほうが、次の一歩を踏み出してもらえるという見方です。

構造化データにも、そのまま当てはまります。

引くもの

引くもの	引いたあとの状態
終了した表示のためのマークアップの追加	工数が、本文や問い合わせの導線に回る
ページに見えない内容	本文と構造化データが一致し、食い違いが起きない
表示の条件を満たさない型	管理する項目が減り、更新の漏れが減る
同じ内容を出す重複した出力	食い違いの原因が減る

残すもの

引いても、残すものがあります。

会社の基本情報、拠点の情報、記事の日付と著者、パンくず。この4つが、まず整える対象です。

本文に書いてあることだけを、正確に、少なく伝える。それが、構造化データの謙虚な使い方です。

よくある質問

Q1. 構造化データを入れないと、検索に出ませんか

入れなくても、ページは検索結果に表示されます。

構造化データは、検索結果の見え方を整える補助です。ページを検索に載せるための手続きではありません。

Q2. すでに入れているFAQやHowToは、削除したほうがよいですか

急いで削除する必要はありません。

2023年の公式ブログは、FAQのマークアップを、あえて取り除く必要はないと説明しています。サイトの改修のついでに整理すれば足ります。

Q3. 自社サイトのお客様の声に、星を付けたいです

自社が管理しているレビューは、LocalBusinessやOrganizationのページで、星の表示の対象になりません。

第三者のウィジェットで口コミを埋め込んだ場合も、同じ扱いです。2026年7月には、偽のレビューや、見返りを開示していないレビューを含めないというガイドラインも加わりました。

Q4. 構造化データは、プラグインに任せてよいですか

任せてよい部分と、確認が必要な部分があります。

プラグインが出力した内容は、テストの道具で必ず確かめます。会社の情報が最新かどうかは、人が見る必要があります。

Q5. 自社のセミナーに、Eventを付けるべきですか

公式の条件では、誰でも予約できる、現実の場所で開催される、1つのイベントを扱うページが対象です。

提供地域の一覧に、日本は含まれていません。会員向けや、オンラインだけのセミナーは、対象外です。

今日できる点検

今日の作業時間が10分あれば、次の点検表で現状を確かめられます。

区分	確認する項目	状態
現状	トップページをリッチリザルトテストにかけて、読み取れる型を確かめた	□
重複	プラグインとテーマで、同じ型が二重に出ていない	□
一致	会社名、住所、電話が、本文と構造化データで同じである	□
営業時間	変更があれば、本文と構造化データの両方を直す担当を決めた	□
終了した表示	FAQやHowToのために、新しい作業をしていない	□
レビュー	自社のお客様の声に、星の構造化データを付けていない	□
監視	Search Consoleのレポートを見る日を、月に1回決めた	□
手動対策	手動による対策のレポートに、表示がない	□

全部にチェックが入らなくても、問題ではありません。チェックの入らない行が、次にやることです。

まとめ

構造化データは、入れる型を絞り、確認と監視まで続けて考えます。

項目	要点
形式	JSON-LDが、実装と管理の面で勧められている
まず検討する型	Organization、LocalBusiness、BreadcrumbList、Article
商品とイベント	公式の条件を確かめてから決める。Eventの提供地域に日本は含まれない
終了した表示	FAQ、HowToなどのために、新しい作業をしない。既存のマークアップは急いで消さなくてよい
ガイドライン	見えない内容は入れない。自社へのレビューは星の対象外
WordPress	出力を調べ、重複を避け、足りない型だけ足し、更新の担当を決める
確認と監視	リッチリザルトテストとSchema Markup Validator、Search Consoleのレポート
期待	表示の条件を整える作業であり、順位の約束はない

最初の1回は、トップページの現状を、リッチリザルトテストで確かめるところから始められます。

構造化データや、その先のサイトの導線の見直しに迷うときは、初回60分のオンライン相談でお話しできます。

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。