税務・FP・投資・医療など、読者の人生や財産に直接影響を与えるテーマは、Googleが「YMYL（Your Money or Your Life）」と呼んで検索品質を厳しく見ているジャンルです。E-E-A-T（経験・専門性・権威性・信頼性）が評価軸に組み込まれ、AdSenseやインデックス判定でも「監修者の実在性」「運営主体の透明性」「構造化データの整合性」がそろっていないと評価が伸びにくいのが現状です。
ひより
FinLaboではこの課題に対し、WordPressテーマ「SWELL」と運用エージェント「Claude Code」を組み合わせ、信頼性を3つの階層に分けて設計しています。①投稿内の監修者プロフィールバー、②運営者ページの3資格者帯、③構造化データ（JSON-LD）の author / reviewedBy。本記事では、その判断と実装をまとめます。
なぜYMYL領域は「信頼性の3階層」設計が必要なのか
E-E-A-Tは記事単体ではなくメディア全体で評価される
Googleが2025年末以降に強調しているのは、「個別ページの信頼性は、メディア全体の信頼性に支えられる」という考え方です。1記事だけ立派な監修クレジットが付いていても、運営者ページが薄かったり、構造化データに author が含まれていなかったりすると、検索評価は伸びにくくなります。逆に運営者ページが厚くても、各記事に監修者の所在が示されていなければ、ユーザー側の信頼が積み上がらないという問題があります。
単一の監修バナーでは届かない理由
多くの士業サイトが採用している「記事末尾に小さく監修者プロフィールを置く」方式には限界があります。クローラーは記事構造の中で監修情報の位置・量・関連性を見ているため、画像ベースのバナーだけでは E-E-A-T シグナルとして十分に拾われないからです。ユーザー側の体験でも、上部に監修者の専門性が出ていない記事は、読み始めの段階で信頼を得にくい構造になっています。
葵
階層①：投稿内の監修者プロフィールバー（SWELLでの実装）
SWELLのカスタムフィールド＋投稿メタを連動させる
FinLaboでは記事冒頭直下に「監修者プロフィールバー」を固定配置しています。SWELLの場合、テーマ既定の「投稿者情報」を直接編集するより、カスタムフィールドで別管理するほうが運用が安定します。理由は、記事ごとに監修者を切り替えたい（税務記事＝税理士、FP記事＝CFP・FP1級など）需要があるからです。
具体的には、カスタムフィールドに reviewer_name / reviewer_qualification / reviewer_link / review_date の4項目を持たせ、テーマの functions.php から PHP テンプレートで読み込み、 the_content の直前にバーを挿入します。バー内には資格名・氏名・最終レビュー日・運営者ページへの内部リンクを並べ、見出しに itemprop="reviewedBy" を付けて構造化データと連携させるのがポイントです。
監修者バーに最低限入れるべき項目
監修者バー・必須項目チェックリスト
- 監修者の氏名（フルネーム・読み仮名）
- 資格名（税理士・公認会計士・FP1級など正式名称）
- 監修者プロフィールページへの内部リンク
- 最終レビュー日（記事更新ごとに更新）
- 「監修者と運営主体は別法人」である旨の一言注記（該当時）
FinLaboでは「監修：FinLabo公認会計士・税理士事務所／編集：FinLabo編集部」のように、監修側と編集側を分けて表記しています。士業事務所と編集メディアが同一法人ではない構造は、近年のYMYLメディアで増えており、Google品質評価ガイドライン上も矛盾しません。むしろ役割分担が明確なほうが信頼性は上がる傾向にあります。
AIで運用する前提でWordPressテーマを選ぶなら、SWELLは扱いやすい筆頭です。
✅ YMYL対応の士業メディアを自分で運用したい人 → SWELL
独自記法が少なくHTMLが素直で、監修者バーや構造化データなどのカスタマイズをClaude Codeで自動化しやすいのが選定理由です。
WordPressテーマ「SWELL」を見る※リンク先は公式サイト（PR）
階層②：運営者ページのYMYL記載項目
3資格者帯と編集体制の見せ方
運営者ページ（about / company）は、Googleが「サイト全体の権威性」を判定する際の起点になるページです。FinLaboでは「税理士・FP1級・公認会計士」の3資格者帯を冒頭に置き、各メンバーの登録番号・所属事務所・主たる業務領域を明記しています。資格番号まで載せる必要はありませんが、「実在性が確認できる粒度」が求められる点は意識しておきたいところです。
運営者ページ必須項目チェックリスト
| セクション | 必須記載項目 | YMYL観点での意味 |
|---|---|---|
| 運営主体 | 法人名／屋号・所在地・代表者名 | 責任主体の明確化 |
| 監修体制 | 監修者名・資格・連携事務所 | 専門性と権威性の担保 |
| 編集方針 | 取り扱いテーマ・更新頻度・出典ルール | 記事品質の一貫性 |
| 連絡手段 | 問い合わせフォーム・メールアドレス | 説明責任の担保 |
| 免責・利益相反 | アフィリエイト方針・投資勧誘有無 | 透明性の担保 |
| 更新履歴 | 主要改訂日と内容 | 鮮度と継続運営の証跡 |
「アフィリエイト方針」を運営者ページから1クリックで辿れる場所に置いておくことも、YMYL対応では効果が大きい要素です。FinLaboは別途「アフィリエイトポリシー」固定ページを用意し、運営者ページ・記事内CTA・フッターの3か所からリンクしています。
階層③：構造化データ（JSON-LD）の author / reviewedBy
schema.org/Article のFinLabo採用フォーマット
SWELL自体は schema.org に沿った構造化データを出力しますが、YMYLメディアとしては標準出力に加えて author / reviewedBy / publisher を明示するのが望ましい状態です。FinLaboで採用しているJSON-LDのフォーマットを抜粋すると次のとおりです。
ポイントは2つ。① author を Organization（編集部）にすることで、執筆主体が個人ではなくメディア全体であることを示す。② reviewedBy を Person（実在する有資格者）にすることで、ページ単位の専門性を担保する。この2分割は、士業監修メディアの標準形として近年定着しつつあります。
Claude Codeで自動付与する設計パターン
FinLaboでは構造化データの差し替えを Claude Code が WP REST API 経由で実行しています。記事公開直後にカスタムフィールドの reviewer 情報を読み取り、JSON-LD を再生成して <head> 直前に注入する流れです。スクリプトのトリガーは「投稿ステータスが publish に変化したとき」の単一イベントに絞ることで、副作用を最小化しています。
Claude Code に任せる範囲を「テンプレート生成」と「投稿API呼び出し」に限定し、reviewer の選定や記事内容の判断は人間（編集部・監修者）が握る運用にしているのも、YMYL対応では重要な切り分けです。AIに任せる粒度を間違えると、構造化データと実体に齟齬が生まれ、かえって信頼性を毀損するリスクがあります。
3階層を運用に乗せるためのルーティン
記事公開フローの4ステップ
3階層を一度設計しても、運用で形骸化すれば意味がありません。FinLaboでは記事公開を次の4ステップに固定しています。① 編集部が初稿を作成、② 監修者が事実確認とコメント、③ カスタムフィールド（reviewer情報・最終レビュー日）を更新、④ 公開後にClaude Codeが構造化データを差し替え。④だけが自動化されており、①〜③は必ず人間が通す設計です。
運用上の落とし穴として、「監修者バーは更新したが、構造化データのreviewedByは前の人のまま」といった齟齬が起きやすい点があります。FinLaboではカスタムフィールド更新時に構造化データを再生成するフックを入れることで、表示と構造化データを必ず同期させています。
まとめ
YMYL領域の士業メディアにおいて、信頼性は「監修者バー（記事内）」「運営者ページ」「構造化データ」の3階層が連動して初めて評価につながります。SWELLのカスタマイズ機能を中心に、Claude Codeで反復作業を自動化することで、士業の本業と並行しても運営可能な体制に落とし込めるのが、FinLaboで採用している考え方です。
ひより
最新の税務・FP・投資情報はSNSでも発信しています。
X：@FinLabo_jp（毎日の小ネタ）
Instagram：@finlabo_jp（図解で3分・平日2本）
※ 本記事は2026年6月時点の情報をもとに作成しています。Googleの検索品質評価ガイドライン・schema.orgの仕様は更新される可能性があります。実装の最終判断は読者自身の運用状況に応じて行ってください。
コメント