士業サイトのAI検索対策: Claude CodeでFAQ・著者情報・相談CTAを直す

士業サイトの相談ページで問い合わせが増えないとき、原因は「AI検索に弱いから」だけではありません。相続、労務、会社設立、契約書レビューのページを見た読者は、料金、対応範囲、誰が見ているのか、初回相談で何を持っていくのかを先に知りたい。そこが薄いままFAQだけを増やすと、Google検索でもAIの回答でも、ページの強みがぼやけます。

この記事では、税理士、社労士、司法書士、行政書士、弁護士などの士業サイトを想定し、Claude CodeでFAQ、著者情報、根拠リンク、相談CTAを見直す手順を書きます。参考にした一次情報は、Google Search CentralのAI機能向けの最適化ガイド、有用で信頼できるユーザー第一のコンテンツ、構造化データの基本、FAQPage構造化データです。

先に大事な線引きをします。AI検索対策という名前で、AIに拾われるためだけの薄いFAQを量産する話ではありません。GoogleはAI機能でも基本のSearch方針を土台にしており、ページの本文、根拠、著者、更新日、クロール可能性がまず見られます。Claude Codeには、相談ページを読者の不安ごとに分解し、足りない事実と公開前の確認項目を表にさせます。料金、法令判断、実績、個別案件の可否は人が見ます。

この記事の要点

• 士業サイトのAI検索対策は、FAQを増やす作業ではなく、相談前の不安をページ本文で減らす作業です。

• Claude Codeには、ページ本文、FAQ、著者情報、更新日、根拠リンク、相談CTAの抜けを表に出させます。

• 人が見る範囲は、料金、対応範囲、資格表示、法令判断、個別案件の可否、守秘情報です。

• 成果はインプレッションだけでなく、問い合わせ数、相談予約率、同じ質問の減少、CVRで見ます。

• 今日の1手は、既存ページ1本を渡し「AIが要約したら誤解されそうな表現」を10個出させることです。

士業ページで起きる失敗シーン

よくある失敗は、ページの上部に「相続税に強い」「労務相談に対応」とだけ書き、具体的な相談前情報を下に隠す形です。読者は専門家の実力を疑っているのではなく、いま自分が問い合わせてよい段階かを迷っています。必要資料、初回相談の範囲、概算料金、対応できないケース、急ぎ案件の扱いが見えないと、フォームの前で止まります。

AI検索でも同じ問題が起きます。本文に「初回相談の持ち物」がなく、FAQだけに短く書いてある場合、AIはページ全体の意図をつかみにくくなります。構造化データに書いた内容が本文に見えない場合も危険です。Googleの構造化データ方針では、マークアップはページに見える内容と合っている必要があります。見えていない実績、料金、レビューを機械向けにだけ入れる運用は避けます。

士業サイトは信頼で選ばれます。だからこそ「すごい事務所です」と言うより、「この相談なら初回でここまで確認します」「この資料があると次が早いです」「このケースは別途見積もりです」と書くほうが問い合わせに近づきます。AI検索対策は、その読者向けの説明を抜けなく置く作業と考えると迷いません。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、既存ページの読み取り、読者の不安の分類、FAQ候補の作成、著者情報と更新日の抜け確認、相談CTAの位置案、内部リンク候補、公開前チェック表の作成です。たとえば相続税ページなら、読者の不安を「期限」「料金」「資料」「オンライン相談」「家族が遠方」「申告が必要か不明」のように分けます。

人が見る範囲は、法律や税務の判断、料金表、対応できる地域、担当者名、保有資格、守秘義務、顧客事例、実績表示です。AIに「このケースは申告不要」と断定させるのは危険です。Claude Codeの出力は、公開原稿ではなくレビュー表として扱います。最後は事務所の責任者が、言い切ってよい部分と「個別確認」と書く部分を分けます。

権限の置き方も大事です。Claude Codeへ渡す素材は、個人名、住所、電話番号、顧客資料、契約書の原本を伏せた版にします。ページ改善では、実案件の細部よりも「読者が迷う型」を集めれば十分です。入力を薄くしても、料金、持ち物、相談範囲、CTA、FAQの骨組みは作れます。

3つのUse case

Use case 1: 相続税ページのFAQを相談前の不安から作る

• 入力: 既存ページ本文、初回相談でよく聞かれる質問、必要資料、料金表、申告期限の説明。
• 出力: 「いつ相談するか」「何を持つか」「料金の見方」「家族が遠方のとき」「税務署から通知が来たとき」のFAQ案。
• 人の確認: 税務判断の断定、料金表の例外、対応できない案件、資料名の正確さ。

FAQは数を増やせばよいものではありません。相談前の不安を減らす順番に並べます。相続税なら「まず何から始めるか」「期限に間に合うか」「初回で費用が決まるか」を上に置きます。本文にも同じ答えを置き、FAQは拾いやすくする補助にします。

Use case 2: 労務相談ページの著者情報と根拠リンクを直す

• 入力: 社労士事務所のサービスページ、担当者プロフィール、対応分野、参考にしている公的情報。
• 出力: 著者・監修者の表示案、更新日の置き場、根拠リンクの不足表、断定しすぎた表現の一覧。
• 人の確認: 労働法の解釈、顧問契約の範囲、スポット相談の可否、個別事情への回答範囲。

AI検索で拾われたいからといって、ページに公的リンクを大量に並べるだけでは読者の助けになりません。根拠リンクは、どの説明の裏づけなのかが見える位置に置きます。たとえば「就業規則の見直し」は、労働条件、休職、ハラスメント、賃金規程など読者が見る章に分け、担当者の確認範囲も書きます。

Use case 3: 会社設立ページの相談CTAを上、中、末尾に分ける

• 入力: 司法書士または行政書士の会社設立ページ、料金表、必要書類、相談フォーム、電話受付時間。
• 出力: ファーストビュー、中盤、末尾に置くCTA文、押す前に読者が知りたい条件、フォーム項目の削減案。
• 人の確認: 登記費用、登録免許税、対応地域、電子定款、銀行口座開設などの表現。

CTAは「お問い合わせ」だけだと弱いです。読者は、何を相談してよいかをまだ決められていません。上部では「設立予定日と業種だけで相談できます」、中盤では「料金と必要書類を確認する」、末尾では「初回相談を予約する」のように、読者の段階に合わせます。Claude Codeには、同じCTAを使い回している場所を見つけさせます。

コピペで使えるプロンプト

あなたは士業サイトの編集担当です。下のページ原稿を、AI検索と通常検索の両方で誤読されにくい相談ページに直してください。

入力:
- 対象業務:
- 想定読者:
- 現在のページ本文:
- 著者・監修者:
- 更新日:
- 料金の書き方:
- 相談CTA:
- よくある質問:

出力:
1. 読者が最初に知りたい答えを3つ
2. AIに拾われても困らない事実と、拾われると困る未確定情報
3. FAQで補う質問5つ
4. 著者情報・更新日・根拠リンクの不足
5. 相談CTAを上、中、末尾のどこに置くか
6. 人が公開前に確認する項目

禁止:
- 実績、料金、対応範囲を盛らない
- 法令判断を断定しない
- FAQだけを増やして本文を薄くしない

このプロンプトでは、AI検索という言葉を出しても、作業はページ改善に戻します。狙いは「AIに見つけられる文章」ではなく、「読者が見てもAIが要約しても誤解が少ない文章」です。士業ページではここを外すと、短期的に流入が増えても相談には進みません。

動く確認コード

const page = {
  title: "相続税の初回相談",
  author: "税理士 山田太郎",
  updated: "2026-07-18",
  sourceLinks: [
    "https://www.nta.go.jp/",
    "https://www.jicpa.or.jp/"
  ],
  visibleClaims: [
    "初回30分は無料",
    "申告期限まで2か月を切った案件は事前確認が必要",
    "料金は財産額と資料の量で変わる"
  ],
  faq: [
    "何を持っていけばよいですか",
    "オンライン相談はできますか",
    "相続人が遠方でも相談できますか"
  ],
  ctaPositions: ["hero", "middle", "end"],
  structuredDataClaims: [
    "初回30分は無料",
    "料金は財産額と資料の量で変わる"
  ]
};

function auditAiSearchPage(input) {
  const errors = [];
  if (!input.author) errors.push("著者または監修者がありません");
  if (!/^\d{4}-\d{2}-\d{2}$/.test(input.updated)) errors.push("更新日がYYYY-MM-DDではありません");
  if (input.sourceLinks.length < 2) errors.push("根拠リンクが少なすぎます");
  if (input.faq.length < 3) errors.push("FAQが3件未満です");
  if (!input.ctaPositions.includes("middle")) errors.push("本文途中の相談CTAがありません");

  const hiddenStructuredClaims = input.structuredDataClaims.filter(
    (claim) => !input.visibleClaims.includes(claim)
  );
  if (hiddenStructuredClaims.length > 0) {
    errors.push(`構造化データだけにある表示: ${hiddenStructuredClaims.join(", ")}`);
  }

  return {
    status: errors.length === 0 ? "公開前レビューへ進める" : "修正が必要",
    errors
  };
}

console.log(auditAiSearchPage(page));

このコードは、ページ原稿の公開前レビューを小さく試すためのものです。実際のサイトでは、MDXやCMSからtitle、author、updated、FAQ、CTA位置を読み取り、同じチェックをかけます。Claude Codeには、このようなチェックをプロジェクトに合わせて作らせると、毎回の公開判断が見えます。

Pitfall: AI検索向けFAQだけを増やして本文が薄くなる

一番危ない落とし穴は、AI検索で拾われることを急ぎ、短いFAQを大量に足すことです。FAQは補助です。本文に料金、相談範囲、担当者、更新日、根拠がないままFAQだけ増やすと、読者は読み進めても判断できません。直し方は、FAQの答えを本文の章にも置き、読者がフォーム前に見る順番へ並べ替えることです。

次の落とし穴は、AIに法令判断をさせることです。「このケースは必ず対象外です」「この契約なら問題ありません」と書くと、読者にも事務所にも危険です。Claude Codeには「判断が必要な箇所」を抽出させ、公開文では「個別確認が必要」「資料を見て判断」と書く場所を残します。

最後の落とし穴は、構造化データだけを整えて満足する流れです。FAQPageやOrganizationのマークアップは、見える本文が薄いと助けになりません。Googleの方針でも、構造化データはページに見える内容と合っている必要があります。まず本文、次にマークアップ、最後にSearch Consoleで確認、という順番にします。

よくある質問

AI Overviewに出るための専用テクニックはありますか

専用の裏道を探すより、ページの基本を直すほうが堅いです。GoogleのAI機能向けガイドでも、通常のSearch方針、クロール可能性、ユーザー第一の情報が土台です。士業サイトでは、著者、根拠、更新日、相談範囲、料金、FAQを読者に見える形で置きます。

FAQPage構造化データを入れれば検索結果で目立ちますか

FAQのリッチリザルトは以前より表示対象が狭くなっています。だから、リッチリザルトだけを狙う設計に寄せすぎないほうがよいです。FAQは検索表示のためではなく、読者が問い合わせ前に迷う点を短く確認するために置きます。

どのページから直すべきですか

まずは問い合わせに近いページです。相続税相談、就業規則相談、会社設立、契約書レビュー、許認可相談など、読者が「相談するかどうか」を決めるページを1本選びます。PVの多い記事より、フォームに近いページを先に直すほうが売上に近づきます。

Claude Codeにどこまで読ませてよいですか

公開済みページ、匿名化した質問集、料金表、担当者プロフィール、社内で使う一般的なチェックリストまでにします。顧客名、契約書、身分証、住所、個別案件の資料は伏せます。必要ならダミー値に置き換えてから渡します。

研修・相談へのつなげ方

このテーマは、単発の記事作成よりも、士業サイト全体の問い合わせ導線として設計したほうが成果を見やすいです。まず5ページだけ選び、FAQ、根拠リンク、著者情報、CTA、フォーム項目を同じ基準で見ます。相談予約率、フォーム離脱、同じ質問の件数、初回面談までの日数を月ごとに見れば、AI検索対策が売上に近づいているか判断できます。

複数ページをまとめて直す場合は、研修・相談で「Claude Codeに下書きさせる範囲」と「士業側が確認する範囲」を分けて設計できます。記事を増やすだけではなく、問い合わせに近いページのCVRを見るのが、このサイトのマネタイズにも合っています。

実際に試した結果

この記事では、GoogleのAI機能向けガイド、ユーザー第一コンテンツ、構造化データ、FAQPageの公式情報を確認し、士業サイトでAI検索対策と呼べる作業を「FAQ、著者情報、根拠リンク、相談CTAの公開前レビュー」に絞りました。確認コードはNode.jsで実行できる形にし、構造化データだけにある表示やCTA抜けを検出できることを確認しました。