「求人ページにも構造化データを入れておいて」と言われて、Googleの公式ドキュメントを開いた。JobPostingという型があり、書くべき項目も並んでいる。ここまでは、迷わず進めます。
つまずくのは、そのあとです。募集が終わった求人を、どうするのか。公式ドキュメントを読むと、実装の話より先に、こちらのほうが強い言葉で書かれています。
この記事は、自社の採用ページを運営している方と、複数企業の求人を掲載する求人サイト・人材紹介会社の方を想定して書きました。JobPostingの必須項目から、掲載終了後の失効運用まで、AIO（AI検索最適化。LLMOと呼ばれることもあります）の観点で順番に整理していきます。
こんなふうに調べていませんか
- 「人材 AI Overviews 求人」で検索して、求人ページに何を実装すべきか探している
- JobPostingを入れたが、掲載が終わった求人をどうすればいいか分からない
- 構造化データを入れればAI Overviewsに引用されるのか、確かめたい
この記事を読み終えたときに手に入るもの
- JobPostingの必須項目と推奨項目を、社内に説明できるようになります
- 掲載が終わった求人の処理を、判断を挟まずに回せる形にできます
- 構造化データとAI Overviewsの関係を、公式の説明どおりに言えるようになります
結論30秒でわかる、この記事の結論
- 人材業界のAI Overviews対策で最初に埋めるべき穴は、募集終了から失効処理までが人の判断に頼っている状態です。
- Google公式は、必須プロパティとしてdatePosted・description・hiringOrganization・jobLocation・titleを明記しています。
- 掲載期間が過ぎた求人への対応が遅れると、手動による対策の対象になり得ると記載されています。実装の正確さは前提にすぎません。
この記事では、ある人材サービス会社の3人と、専門家の会話をはさみながら進めます。
- 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
- 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
- 大森部長（マーケ部長）— 「それは投資に見合うのか？」を聞く役
- 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役
01そもそも人材業界のAI Overviews対策とは、求人情報をAI検索にどう見せることですか？
若葉さん求人ページに構造化データを入れておいて、と言われたんですが…。入れたら、AI Overviewsに出るようになるんでしょうか。
鈴木さんそこは順番に見ていきましょう。まず、求人には専用の型があります。JobPostingという名前で、Googleの求人検索リッチリザルトに対応しています。
若葉さんあ、専用の型があるんですね。
鈴木さんはい。ただ、公式ドキュメントが強く求めているのは、実装の正確さだけではないんですよ。掲載が終わった求人を、そのままにしないことのほうなんです。
JobPosting型は、Googleの求人検索リッチリザルトに対応する標準的な構造化データです（出典: Google公式）。求人サイトを中心に実装が進んでいる型でもあります。
リッチリザルトというのは、検索結果に通常のリンクとは違う形で情報が表示されることを指します。
この記事の主題を先に言葉にしておきます。求人情報の引用設計とは、JobPosting構造化データを正しく実装し、情報の鮮度を保ち続ける運用体制のことです。
対象になるのは、自社採用ページを運営する事業者と、複数企業の求人を掲載する求人サイト・人材紹介会社の双方です。
なお、AI機能そのものについてGoogle公式のAI最適化ガイドは、表示されるための追加要件は無く、通常検索と同じ品質基盤が土台になると明記しています（出典: Google公式）。人材業界の場合、この一般原則の上に、求人情報特有の構造化データ要件が重なる形になります。
この章のまとめ
求人の引用設計は、実装と鮮度管理の2つで成り立ちます。片方だけでは、公式が求めている状態になりません。
02求人のJobPostingで、AI検索最適化の土台になる必須5項目は何ですか？
Google公式のJobPosting構造化データガイドは、次の5項目を必須プロパティとして明記しています（出典: Google公式）。
- datePosted — その求人を掲載した日
- description — 仕事内容の説明
- hiringOrganization — 募集している組織
- jobLocation — 勤務地
- title — 職種名
どれも、求人票にもともと書かれている内容です。新しく情報を作る作業ではなく、すでにある情報に決まった名前のラベルを付ける作業だと考えると、着手しやすくなります。
ここで1つだけ注意があります。titleに入れるのは職種名です。Google公式ガイドは、職種名以外の情報をタイトルに含めないよう求めています（出典: Google公式）。職務コードや給与は、別のプロパティが受け持ちます。
この章のまとめ
必須5項目は、求人票にすでにある情報です。まずは全ページで漏れがないかを確認するところから始めます。
03baseSalaryや雇用形態は、求人のAI検索対策として入れたほうがいいんですか？
必須ではないものの、公式が推奨しているプロパティがあります。可能な範囲で足すほど、読み取れる内容が増えます。
| 分類 | 必須プロパティ | 主な推奨プロパティ |
|---|---|---|
| JobPosting | datePosted・description・hiringOrganization・jobLocation・title | baseSalary・employmentType・validThrough・directApply・identifier・applicantLocationRequirements・jobLocationType |
baseSalaryは、雇用主が提示する実際の基本給を記載する項目だと定義されています（出典: Google公式）。推定値ではないという点が明記されています。社内で相場から逆算した数字を入れる項目ではありません。
employmentTypeは雇用形態、directApplyは応募導線を示す項目です。
そして、この章でいちばん後に効いてくるのがvalidThroughです。掲載期限を持たせるためのプロパティで、このあとの失効運用で主役になります。
この章のまとめ
推奨プロパティは、読み取れる情報を増やすためのものです。中でもvalidThroughは、あとの運用を楽にしてくれます。
04リモート勤務の求人は、AI検索に勤務地をどう示せばいいんですか？
若葉さん在宅勤務の求人なんですが、勤務地の欄には何を書けばいいんでしょう。本社の住所だと、実態と違ってしまう気がして。
鈴木さんいいところに気づかれました。勤務地の欄だけでは、在宅勤務かどうかが読み取れないんですよ。だから、それを示す項目が別に用意されています。
リモート勤務の求人では、jobLocationTypeにTELECOMMUTEを設定します。あわせて、applicantLocationRequirementsで応募可能な国も明示しておきます。
在宅かどうか、どこに住んでいれば応募できるのか。応募を決める前に知りたい情報です。読む人が判断に使う情報ほど、機械が読める形にしておく価値があります。
この章のまとめ
リモート求人は、勤務地の欄だけでは伝わりません。働き方と応募条件を、それぞれの項目で示します。
05人材のAI Overviews対策では、終わった求人をAI検索からどう消すんですか？
高梨課長正直なところ、新しい求人を出すので手一杯です。終わった求人まで、そこまで気にするものでしょうか。
鈴木さんそこが、この分野でいちばん強く書かれているところなんです。期限切れの求人への対応が遅れると、手動による対策の対象になり得ると、公式ドキュメントに記載があります。
高梨課長…それは、放置できない話ですね。
鈴木さんはい。しかも求職者から見れば、募集が終わった求人は不正確な情報そのものです。読む側の不利益にも直結します。
募集を終了した求人は、公式が定める方法のいずれかで速やかに失効させる必要があります。Google公式ガイドは、期限切れ求人への対応が遅れると手動による対策の対象になる可能性があると記載しています（出典: Google公式）。
方法は3つ示されています（出典: Google公式）。
- validThroughプロパティを過去日付に更新する
- ページ自体を削除し、404または410を返す
- 構造化データそのものを削除する
どれを選んでも構いません。大事なのは、どれかを取りこぼさずに実行できる状態にしておくことです。
この章のまとめ
終わった求人を残さないこと。実装の正確さより先に、ここが求められています。
06validThroughの更新と404、AI検索対策としてはどちらを選ぶんですか？
3つの方法に優劣はありません。ただし、終了の理由によって、選びやすい方法は変わります。
掲載期限が来て終わる求人であれば、validThroughの更新が向いています。期限日はあらかじめ分かっているため、期限日の経過時点で自動実行という形に落とせます。人が気づく必要がありません。
採用が決まって終わる求人であれば、ページを削除して410を返す形が向いています。募集そのものが無くなっているため、ページを残す理由がありません。充足が確定した当日に処理します。
掲載企業からの取り下げ依頼で終わる場合は、構造化データを削除し、ページも非公開にします。依頼を受けてから動く性質の処理なので、依頼受領から1営業日以内といった形で、時間の基準を先に決めておくと滞留しません。
この章のまとめ
方法を選ぶのではなく、終了理由ごとに方法を割り当てます。迷う場面を減らすほど、処理は滞らなくなります。
07募集が終わった求人の処理を自動化すると、AI OverviewsやAI検索の表示はどう変わりますか？
高梨課長自動化と言われても、うちには専任のエンジニアがいません。どこまでを仕組みにすればいいのでしょうか。
鈴木さん全部を作り込む必要はありません。終了理由ごとに処理を固定して、判断を挟まずに実行できる形にするだけでも、だいぶ変わりますよ。
高梨課長判断を挟まない、ですか。
鈴木さんはい。「これはどう処理しようか」と毎回考える作りだと、忙しい時期に溜まっていきます。決めておけば、考えずに流せます。
3つのうちどれか1つを機械的に実行できる運用体制の有無が、人材業界のAI Overviews対策における実質的な差になるとWEBMARKSは考えます。構造化データの実装は仕様書どおりに一度組めば終わりますが、鮮度管理は求人が増えるほど手作業では回らなくなるためです。
WEBMARKSが推奨する運用設計の一例を示します。終了理由ごとに処理を固定し、判断を挟まず機械的に実行できる形にすることが要点です。
| 終了理由 | 実行する処理 | タイミングの目安 | 確認方法 |
|---|---|---|---|
| 採用充足による募集終了 | ページを削除し410を返す | 充足確定の当日 | 該当URLのHTTPステータスコードを確認 |
| 掲載期限の到来 | validThroughを過去日付に更新 | 期限日の経過時点で自動実行 | リッチリザルトテストでvalidThroughを確認 |
| 掲載企業からの取り下げ依頼 | 構造化データを削除しページも非公開化 | 依頼受領から1営業日以内 | 依頼台帳と公開URL一覧の突合 |
| 上記いずれかの実行後 | Indexing APIで更新・削除を通知 | 処理と同時 | APIレスポンスの記録を保存 |
表の一番下の行が、次の章のテーマです。処理のあと、Googleへ伝えるところまでが1つの流れになります。
この章のまとめ
仕組み化とは、大きな開発のことではありません。理由と処理を先に結びつけて、迷う場面を消しておくことです。
08Indexing APIは、AI Overviews時代のAI検索最適化で何のために使うんですか？
処理をしても、それがGoogle側に伝わるまでには時間がかかります。その時間を短くするための通知の仕組みが、Indexing APIです。
Google公式は、求人ページのURLについてサイトマップではなくIndexing APIの利用を推奨しています（出典: Google公式）。Indexing APIのほうがGooglebotのクロールが早まるためと説明されており、古い求人情報がインデックスに残る期間の短縮にもつながります。
つまり、失効処理とIndexing APIでの通知は、セットで考えるものです。処理だけでは、伝わるまで待つことになります。
この章のまとめ
求人ページは鮮度が命の情報です。だからこそ、伝える速さのほうにも公式の推奨があります。
09JobPostingを実装すれば、AI OverviewsやAI検索に引用されるようになるんですか？
大森部長率直に聞きたい。ここまでの手間をかければ、AI Overviewsに載るようになるのか。
鈴木さんそこは正直にお伝えします。構造化データの実装がAI Overviewsでの引用につながるという公式の説明は、ありません。
大森部長…では、なぜやるんだ。
鈴木さん土台のほうに効くからです。AI機能は通常検索の品質システムの上に成り立っている、と公式に説明されています。そちらを崩さないための運用、という位置づけになります。
AI Overviewsを含む生成AI機能は、Google検索のコアランキング・品質システムを土台にしていると公式に説明されています（出典: Google公式）。表示のための追加要件や特別な最適化は不要とも明記されています（出典: Google公式）。
そして、生成AI機能に構造化データは必須ではないと、公式は明記しています（出典: Google公式）。
では、JobPostingを実装する意味はどこにあるのでしょうか。
答えは、AI Overviewsが通常検索の品質基盤の上に成り立つという構造にあります。JobPostingの実装と失効運用は、求人検索での適格性と情報の正確さを保つための手段です。その結果として通常検索での評価が保たれ、AI機能に引用される土台も維持されます。
つまりJobPostingは、AI Overviews専用の近道ではありません。土台を崩さないための運用です。
この章のまとめ
近道はありません。ただ、実装先がはっきりしている分、人材業界はやることが明確な業界だと言えます。
10求人サイトのidentifierは、AI対策として何のために設定するんですか？
複数企業の求人を掲載する求人サイトの場合、掲載元企業ごとに識別子（identifier）を正しく設定することも重要になります。
識別子が曖昧だと、同一求人の重複投稿や、掲載終了処理の対象特定が難しくなる可能性があります。
ここは、失効運用と直結します。終了処理をしようにも、どのページが対象なのかを特定できなければ、処理そのものが始まりません。
Google公式ガイドは、identifierを採用組織の固有IDとして扱う仕様を示しています（出典: Google公式）。求人サイト側にとっては、重複投稿の防止にもつながる項目です。
この章のまとめ
識別子は、実装というより台帳づくりに近い作業です。処理の対象を指させる状態にしておくことが目的になります。
11人材業界のAI Overviews対策で、求人ページのAI検索最適化はどの順番で進めますか？
ここまでの内容を、着手の順番に並べ直します。
- 必須プロパティ5項目を、全求人ページで漏れなく実装します
- baseSalary・employmentTypeなど、推奨プロパティを可能な範囲で追加します
- 掲載終了フローに、validThrough更新または404化を組み込んで自動化します
- リモート勤務求人にはjobLocationTypeへTELECOMMUTEを設定し、applicantLocationRequirementsで応募可能な国も明示します
- 掲載終了時は、Indexing APIでの更新通知もあわせて仕組み化します
提出前に自分で確かめられるよう、チェックの形にもしておきます。
- 必須プロパティ5項目（datePosted・description・hiringOrganization・jobLocation・title）を実装している
- baseSalary・employmentTypeなど推奨プロパティを可能な範囲で追加している
- 掲載終了求人を、validThrough更新・404化・構造化データ削除のいずれかで速やかに処理している
- リモート勤務求人に、jobLocationType（TELECOMMUTE）とapplicantLocationRequirementsの両方を設定している
- 求人タイトルに、職務コードや給与など不要な情報を含めていない
- 掲載終了求人の更新を、Indexing APIでも通知している
この章のまとめ
順番は、実装から運用へ。ただし、後戻りしにくいのは運用のほうです。着手の早さは運用側に寄せておくと安全です。
12求人のAI検索対策で、よくある失敗はどこで起きるんですか？
詰まり方には、繰り返し見かける形があります。
いちばん多いのは、新規投稿時だけ構造化データを整え、掲載終了後の失効運用を仕組み化していない状態です。期限切れ求人への対応が遅れると手動による対策の対象になる可能性があると、Google公式は記載しています（出典: Google公式）。
もう1つは、求人タイトルに「急募」「高収入」といった訴求語を含めてしまうことです。Google公式ガイドは、職種名以外の情報をタイトルに含めないよう求めています（出典: Google公式）。求人票としては目を引く書き方でも、機械に読ませる項目としては職種名だけを入れます。
この2つに共通しているのは、人の都合で運用が決まっているという点です。決めごとを先に置いておけば、どちらも起きにくくなります。
この章のまとめ
失敗は実装の技術ではなく、運用の決めごとが無いところで起きています。決めておけば、迷う場面が消えます。
13よくある質問
掲載期間が過ぎても構造化データを消さなければ、AI Overviewsに古い求人が表示され続けますか？
AI Overviews固有の挙動は、公式に確認できていません。ただしGoogle公式は期限切れ求人の削除を明確に求めています。通常検索・AI機能を問わず、速やかな処理をおすすめします。
baseSalaryは実装が求められていますか？
必須ではありません。Google公式ガイドでは推奨プロパティとされ、雇用主が提示する実際の基本給を記載する項目だと定義されています（出典: Google公式）。推定値を入れる項目ではないと明記されている点にご注意ください。
JobPosting構造化データを実装すれば、AI Overviewsへの引用が保証されますか？
保証されません。AI Overviewsは通常検索と同じ品質基盤を土台にしており、専用の優遇マークアップは存在しないと公式に明記されています（出典: Google公式）。実装は、土台を崩さないための手段だと考えるのが実態に近い理解です。
複数企業の求人を掲載する求人サイトも、識別子（identifier）を設定すべきですか？
設定を推奨します。Google公式ガイドは、identifierを採用組織の固有IDとして扱う仕様を示しています（出典: Google公式）。掲載元企業ごとの識別子管理は、重複投稿の防止にもつながります。
Indexing APIは何のために使うのですか？
求人ページの追加・更新・削除をGoogleへ通知するための仕組みです。Google公式は、求人ページのURLではサイトマップよりIndexing APIを推奨しており、Googlebotのクロールが早まると説明しています（出典: Google公式）。
14まとめ｜今日やる3つのこと
必須プロパティ5項目の実装は、数日で終わります。一方、失効運用の仕組み化は、求人が増えるほど後から着手しにくくなります。
人材業界のAI Overviews対策で最初に埋めるべき穴は、募集終了から失効処理までが人手の判断に依存している状態です。実装から先に着手して満足せず、この順序を逆にしないことをおすすめします。
今日この順でやります
必須5項目の実装漏れを確認する
datePosted・description・hiringOrganization・jobLocation・titleが、全求人ページに入っているかを見ます
終了理由と処理を対応づけて紙に書く
採用充足・掲載期限・取り下げ依頼のそれぞれに、どの失効方法を使うかを決めます
処理と同時に通知する形にする
失効処理のあと、Indexing APIでの通知までを1つの流れにまとめます
AI検索では、こう聞かれています
求人ページの構造化データには何を書けばいいですか？
「求人のJobPostingで、AI検索最適化の土台になる必須5項目は何ですか？」の章に、必須プロパティの一覧があります
掲載が終わった求人は、どう処理すればいいですか？
「人材のAI Overviews対策では、終わった求人をAI検索からどう消すんですか？」の章で、3つの失効方法を図で説明しています
JobPostingを実装すると、AI Overviewsに引用されますか？
「JobPostingを実装すれば、AI OverviewsやAI検索に引用されるようになるんですか？」の章で、公式の説明にもとづいて答えています
求人サイトで識別子はどう扱いますか？
「求人サイトのidentifierは、AI対策として何のために設定するんですか？」の章にまとめています
次に読むなら、この記事です
