YMYL対応の士業メディア｜SWELL×Claude Codeで信頼性を3階層に設計する

税務・FP・投資・医療など、読者の人生や財産に直接影響を与えるテーマは、Googleが「YMYL（Your Money or Your Life）」と呼んで検索品質を厳しく見ているジャンルです。E-E-A-T（経験・専門性・権威性・信頼性）が評価軸に組み込まれ、AdSenseやインデックス判定でも「監修者の実在性」「運営主体の透明性」「構造化データの整合性」がそろっていないと評価が伸びにくいのが現状です。

僕はこの課題に対し、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のカスタムフィールド＋投稿メタを連動させる

僕は記事冒頭直下に「監修者プロフィールバー」を固定配置しています。SWELLの場合、テーマ既定の「投稿者情報」を直接編集するより、カスタムフィールドで別管理するほうが運用が安定します。理由は、記事ごとに監修者を切り替えたい（税務記事＝税理士、FP記事＝CFP・FP1級など）需要があるからです。

具体的には、カスタムフィールドに reviewer_name / reviewer_qualification / reviewer_link / review_date の4項目を持たせ、テーマの functions.php から PHP テンプレートで読み込み、 the_content の直前にバーを挿入します。バー内には資格名・氏名・最終レビュー日・運営者ページへの内部リンクを並べ、見出しに itemprop="reviewedBy" を付けて構造化データと連携させるのがポイントです。

監修者バーに最低限入れるべき項目

僕は「誰が書いたか」と「誰が最終確認したか」を分けて表記することを勧めています。監修する士業と編集する主体が同一でない構造は、近年のYMYLメディアで増えており、Google品質評価ガイドライン上も矛盾しません。むしろ役割分担が明確なほうが信頼性は上がる傾向にあります。

階層②：運営者ページのYMYL記載項目

3資格者帯と編集体制の見せ方

運営者ページ（about / company）は、Googleが「サイト全体の権威性」を判定する際の起点になるページです。僕は「税理士・FP1級・公認会計士」の3資格者帯を冒頭に置き、各メンバーの登録番号・所属事務所・主たる業務領域を明記しています。資格番号まで載せる必要はありませんが、「実在性が確認できる粒度」が求められる点は意識しておきたいところです。

運営者ページ必須項目チェックリスト

「アフィリエイト方針」を運営者ページから1クリックで辿れる場所に置いておくことも、YMYL対応では効果が大きい要素です。僕は別途「アフィリエイトポリシー」固定ページを用意し、運営者ページ・記事内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で自動付与する設計パターン

僕は構造化データの差し替えを Claude Code が WP REST API 経由で実行しています。記事公開直後にカスタムフィールドの reviewer 情報を読み取り、JSON-LD を再生成して <head> 直前に注入する流れです。スクリプトのトリガーは「投稿ステータスが publish に変化したとき」の単一イベントに絞ることで、副作用を最小化しています。

Claude Code に任せる範囲を「テンプレート生成」と「投稿API呼び出し」に限定し、reviewer の選定や記事内容の判断は人間（編集部・監修者）が握る運用にしているのも、YMYL対応では重要な切り分けです。AIに任せる粒度を間違えると、構造化データと実体に齟齬が生まれ、かえって信頼性を毀損するリスクがあります。

3階層を運用に乗せるためのルーティン

記事公開フローの4ステップ

3階層を一度設計しても、運用で形骸化すれば意味がありません。僕は記事公開を次の4ステップに固定しています。① 編集部が初稿を作成、② 監修者が事実確認とコメント、③ カスタムフィールド（reviewer情報・最終レビュー日）を更新、④ 公開後にClaude Codeが構造化データを差し替え。④だけが自動化されており、①〜③は必ず人間が通す設計です。

運用上の落とし穴として、「監修者バーは更新したが、構造化データのreviewedByは前の人のまま」といった齟齬が起きやすい点があります。僕はカスタムフィールド更新時に構造化データを再生成するフックを入れることで、表示と構造化データを必ず同期させています。

まとめ

YMYL領域の士業メディアにおいて、信頼性は「監修者バー（記事内）」「運営者ページ」「構造化データ」の3階層が連動して初めて評価につながります。SWELLのカスタマイズ機能を中心に、Claude Codeで反復作業を自動化することで、士業の本業と並行しても運営可能な体制に落とし込めるのが、FinLaboで採用している考え方です。

ここまで読んでくれて、ありがとうございます。ふだん何を考えているかは、note に書いています。

よこまる

公認会計士・税理士。IPO準備企業で、経営に近い場所にいます。仕事は数字を扱うことですが、いちばん興味があるのは「人がどう働いて、どう暮らすか」。お金・税務・AI・キャリア、そして日々のことを、一般論として、自分の頭で考えた分だけ書いています。ここに書いているのは、個人としての見解です。