JobPosting型は、Googleの求人検索リッチリザルトに対応する標準的な構造化データです（出典: Google公式）。求人サイトを中心に実装が進んでいる型でもあります。
一方、Google公式ガイドが求めているのは実装の正確さだけではありません。掲載期間が過ぎた求人を放置すれば、手動による対策の対象になり得るとまで記載されています（出典: Google公式）。求人情報の引用設計は、実装そのものより運用の設計で差がつきます。この視点からGoogle公式ガイドを読み直していきます。
01この記事でわかること
- JobPosting構造化データの必須プロパティと推奨プロパティ
- 掲載期間が過ぎた求人情報を放置するリスクと3つの失効方法
- AI Overviewsが情報源を選ぶ一般原則との接続
- 求人ページの実務チェックリスト
02結論サマリー
Google公式のJobPosting構造化データガイドは、5項目を必須プロパティとして明記しています（出典: Google公式）。具体的にはdatePosted・description・hiringOrganization・jobLocation・titleです。ただし、正確に実装するだけでは不十分です。
人材業界にとって特に重要なのは、掲載期間が過ぎた求人を放置しないことです。Google公式は、募集を終了した求人を定められた3つの方法のいずれかで失効させるよう求めています（出典: Google公式）。実装の正確さは前提条件にすぎず、鮮度管理の運用こそが差になります。
対象は、自社採用ページを運営する事業者と、複数企業の求人を掲載する求人サイト・人材紹介会社の双方です。求人サイト側は、掲載元企業ごとの識別子（identifier）の扱いにも注意が必要です。
03人材業界のAI Overviews対策とは（基礎定義）
Google公式のAI最適化ガイドは、AI機能に表示されるための追加要件は無く、通常検索と同じ品質基盤が土台になると明記しています（出典: Google公式）。人材業界の場合、この一般原則に加えて、求人情報特有の構造化データ要件が重なります。
| 分類 | 必須プロパティ | 主な推奨プロパティ |
|---|---|---|
| JobPosting | datePosted・description・hiringOrganization・jobLocation・title | baseSalary・employmentType・validThrough・directApply・identifier・applicantLocationRequirements・jobLocationType |
04掲載期間が過ぎた求人情報の扱い
募集を終了した求人は、公式が定める方法のいずれかで速やかに失効させる必要があります。Google公式ガイドは、期限切れ求人への対応が遅れると手動による対策の対象になる可能性があると記載しています（出典: Google公式）。放置された古い求人は、求職者にとって不正確な情報源になります。
失効の方法は3つあります。validThroughプロパティを過去日付に更新する方法、ページ自体を削除し404または410を返す方法、構造化データそのものを削除する方法です（出典: Google公式）。Google公式は、求人ページのURLについてサイトマップではなくIndexing APIの利用を推奨しています（出典: Google公式）。Indexing APIのほうがGooglebotのクロールが早まるためと説明されており、古い求人情報がインデックスに残る期間の短縮にもつながります。
この3つのうち、どれか1つを機械的に実行できる運用体制の有無が、人材業界のAI Overviews対策における実質的な差になるとWEBMARKSは考えます。構造化データの実装は仕様書どおりに一度組めば終わりますが、鮮度管理は求人が増えるほど手作業では回らなくなるためです。
WEBMARKSが推奨する運用設計の一例を示します。終了理由ごとに処理を固定し、判断を挟まず機械的に実行できる形にすることが要点です。
| 終了理由 | 実行する処理 | タイミングの目安 | 確認方法 |
|---|---|---|---|
| 採用充足による募集終了 | ページを削除し410を返す | 充足確定の当日 | 該当URLのHTTPステータスコードを確認 |
| 掲載期限の到来 | validThroughを過去日付に更新 | 期限日の経過時点で自動実行 | リッチリザルトテストでvalidThroughを確認 |
| 掲載企業からの取り下げ依頼 | 構造化データを削除しページも非公開化 | 依頼受領から1営業日以内 | 依頼台帳と公開URL一覧の突合 |
| 上記いずれかの実行後 | Indexing APIで更新・削除を通知 | 処理と同時 | APIレスポンスの記録を保存 |
複数企業の求人を掲載する求人サイトの場合、掲載元企業ごとに識別子（identifier）を正しく設定することも重要です。識別子が曖昧だと、同一求人の重複投稿や、掲載終了処理の対象特定が難しくなる可能性があります。
05AI Overviewsとの接続と実務ポイント
AI Overviewsを含む生成AI機能は、Google検索のコアランキング・品質システムを土台にしていると公式に説明されています（出典: Google公式）。表示のための追加要件や特別な最適化は不要とも明記されています（出典: Google公式）。求人情報がAI Overviewsに引用される際も、この一般原則の上に成り立っています。
構造化データの実装がAI Overviewsでの引用につながるという公式の説明はありません。Google公式は、生成AI機能に構造化データは必須ではないと明記しています（出典: Google公式）。
では、JobPostingを実装する意味はどこにあるのでしょうか。答えは、AI Overviewsが通常検索の品質基盤の上に成り立つという構造にあります。JobPostingの実装と失効運用は、求人検索での適格性と情報の正確さを保つための手段です。その結果として通常検索での評価が保たれ、AI機能に引用される土台も維持されます。
つまりJobPostingは、AI Overviews専用の近道ではなく、土台を崩さないための運用です。Googleの構造化データが未整備な不動産業界とは異なり、人材業界には標準化された実装先が明確に存在します。この違いは業界別のAIO戦略を考えるうえで対照的であり、詳しくは別記事『不動産業界のAI Overviews対策｜物件情報の構造化設計』で扱っています。
- 必須プロパティ5項目を全求人ページで漏れなく実装する
- baseSalary・employmentTypeなど推奨プロパティを可能な範囲で追加する
- 掲載終了フローに、validThrough更新または404化を組み込んで自動化する
- リモート勤務求人にはjobLocationTypeへTELECOMMUTEを設定し、applicantLocationRequirementsで応募可能な国も明示する
- 掲載終了時はIndexing APIでの更新通知もあわせて仕組み化する
06チェックリスト
- 必須プロパティ5項目（datePosted・description・hiringOrganization・jobLocation・title）を実装している
- baseSalary・employmentTypeなど推奨プロパティを可能な範囲で追加している
- 掲載終了求人をvalidThrough更新・404化・構造化データ削除のいずれかで速やかに処理している
- リモート勤務求人にjobLocationType（TELECOMMUTE）とapplicantLocationRequirementsの両方を設定している
- 求人タイトルに職務コードや給与など不要な情報を含めていない
- 掲載終了求人の更新をIndexing APIでも通知している
07よくある失敗
求人情報の新規投稿時だけ構造化データを整え、掲載終了後の失効運用を仕組み化していない例が見られます。期限切れ求人への対応が遅れると手動による対策の対象になる可能性があると、Google公式は記載しています（出典: Google公式）。
もう一つの失敗は、求人タイトルに「急募」「高収入」といった訴求語を含めることです。Google公式ガイドは、職種名以外の情報をタイトルに含めないよう求めています（出典: Google公式）。
08FAQ
Q. 求人情報の掲載期間が過ぎても構造化データを消さなければ、AI Overviewsに古い求人が表示され続けますか？
AI Overviews固有の挙動は公式に確認できていません。ただしGoogle公式は期限切れ求人の削除を明確に求めており、通常検索・AI機能を問わず速やかな処理をおすすめします。
Q. baseSalaryは実装が求められていますか？
必須ではありません。Google公式ガイドでは推奨プロパティとされ、雇用主が提示する実際の基本給（推定値ではない）を記載する項目だと定義されています（出典: Google公式）。
Q. JobPosting構造化データを実装すれば、AI Overviewsへの引用が保証されますか？
保証されません。AI Overviewsは通常検索と同じ品質基盤を土台にしており、専用の優遇マークアップは存在しないと公式に明記されています（出典: Google公式）。
Q. 複数企業の求人を掲載する求人サイトも、識別子（identifier）を設定すべきですか？
設定を推奨します。Google公式ガイドは、identifierを採用組織の固有IDとして扱う仕様を示しています（出典: Google公式）。求人サイト側は、掲載元企業ごとの識別子管理が重複投稿の防止にもつながります。
Q. Indexing APIは何のために使うのですか？
求人ページの追加・更新・削除をGoogleへ通知するための仕組みです。Google公式は、求人ページのURLではサイトマップよりIndexing APIを推奨しており、Googlebotのクロールが早まると説明しています（出典: Google公式）。
09まとめ
必須プロパティ5項目の実装は数日で終わります。一方、失効運用の仕組み化は求人が増えるほど後から着手しにくくなります。人材業界のAI Overviews対策で最初に埋めるべき穴は、募集終了から失効処理までが人手の判断に依存している状態です。実装から先に着手して満足せず、この順序を逆にしないことをおすすめします。
