【図解】求人データフィードの基本構造｜XMLタグとよくあるつまずきポイント

求人データフィードとは、求人情報（職種・仕事内容・勤務地・給与など）を機械が読み取れる形式でまとめたデータのことです。 媒体ごとの管理画面へ手入力する代わりに、ATSや自社DBの情報を定期的に出力し、媒体側に取り込ませることで掲載内容を自動更新できます。

重要なのは、フィードは「ただのデータの塊」ではなく、媒体が審査・掲載・検索表示を行うための入力フォーマットである点です。 そのため、項目の欠落やフォーマット違いがあると、掲載停止や掲載遅延の原因になります。

手動投稿は、求人票の編集自由度が高い一方で、掲載数が増えるほど運用負荷が跳ね上がります。 フィード運用に切り替えると、「更新漏れ」「媒体ごとの二重管理」を抑え、採用スピードに直結する更新頻度を上げやすくなります。

• 求人の追加・停止・内容変更を、ATS側の更新だけで反映しやすい
• 媒体ごとに入力を繰り返さず、運用工数を削減できる
• 審査落ちの原因が「データ」に集約され、改善サイクルを回しやすい

Indeed・求人ボックス・スタンバイなど、媒体ごとに表現や要件が微妙に異なります。 媒体が増えるほど「人の手で合わせ込む」のは限界が来るため、フィード側で仕様を整える設計が重要になります。

例えば給与の表記、勤務地の粒度（都道府県/市区町村/番地）、雇用形態のコードなど、 フィード運用の品質がそのまま掲載可否・表示品質・応募率に影響します。

XMLは、タグ（<tag>）で項目の意味を表し、階層構造で「求人のまとまり」を表現します。 フィードの基本は、全体（ルート）→求人一覧→求人1件の形を守ることです。

<jobs>
  <job>...求人1件目...</job>
  <job>...求人2件目...</job>
  ...
</jobs>

実際のタグ名は媒体・連携方式（schema/仕様書）によって異なりますが、考え方は共通です。 「どのタグが必須か」「どのタグが推奨か」を整理し、まずは必須を100%満たすところから始めるのが安全です。

求人フィードで頻出の項目を、役割ベースで整理すると理解が速くなります。 下記は「媒体が求人を識別し、検索結果に表示し、応募導線へ遷移させる」ための最低限の部品です。

フィード構築は「一気に完璧」を狙うより、必須→推奨→拡張の順が失敗しにくいです。 必須が欠けると取り込み自体が止まることがある一方、推奨は「表示品質・マッチ精度」に効いてきます。

• 必須：求人ID、タイトル、仕事内容、勤務地、給与、応募URL など（媒体の仕様書で定義）
• 推奨：勤務時間、休日、福利厚生、交通費、最寄り駅、企業名、掲載期限 など
• 拡張：画像URL、動画、スキルタグ、職種分類コード など

運用面では、推奨項目まで揃えることで検索結果の露出やクリック後の納得感が上がり、結果として応募率改善に繋がるケースが多いです。

フィードの不具合は「構造が崩れている」「値の形式が違う」「禁止表現が混ざる」の3系統に大別できます。 特にXMLは1か所の崩れで全体が読み込めなくなることがあるため、エラーの起点を早く特定できる設計が重要です。

文字コードはUTF-8が基本です。Shift_JISなどが混ざると文字化けや取り込み失敗の原因になります。 また、仕事内容（description）に「&」「<」「>」などの記号が含まれる場合は、XMLとして正しく扱えるようエスケープが必要です。

<description>待遇：交通費支給 &amp; 社保完備</description>

次に多いのが「値は入っているが形式が違う」パターンです。例えば日付が YYYY/MM/DD と YYYY-MM-DD で混在したり、 給与が「月給20万〜」など曖昧表記になっていたりすると、媒体側で正しく解釈されないことがあります。

採用現場で特に重要なのは、データが整うほど「媒体のマッチング精度」と「求職者の理解」が上がる点です。 形式統一は審査対策に見えますが、結果として応募の質・量にも波及します。

フィード運用は「開発に丸投げ」だと改善が遅れがちです。非エンジニアでも、最低限の用語を押さえるだけで 原因特定のスピードと依頼の精度が大きく上がります。

• XML：タグで意味を表すデータ形式。階層があり、人間にもある程度読める。
• スキーマ（仕様）：どのタグが必要で、どんな形式で入れるかのルール。媒体が定義することが多い。
• エンドポイント：媒体がフィードを取得するURL（配信先）。更新頻度や認証方式が絡むことがある。
• バリデーション：仕様に合っているかの検証。構造エラー・必須欠落・形式違いをチェックする。

「どのスキーマに合わせるか」を最初に確定させると、後からの作り直しが減ります。 ATS側の出力仕様と媒体側の要求仕様がズレている場合は、フィードの加工（マッピング）で調整します。

コミュニケーションでは、「なんか取り込めない」ではなく、事象を分解して伝えるのがコツです。 例えば以下のように整理できると、修正が速くなります。

• どの求人（job_id）で起きているか
• 媒体側のエラーメッセージ（可能ならスクショや原文）
• 該当タグ（例：salary、location、description）
• 期待する形式（例：ISO日付、下限/上限の数値）

さらに、運用側で「修正優先度」を付ける（掲載停止に直結するエラーから直す）と、採用への影響を最小化できます。

フィード改善は、原因が「データ」「取得」「媒体仕様」のどこにあるかを切り分けることが肝です。 そのために、検証は小さく始めて、再現性を確保するほど早く進みます。

まずは全求人のフィードではなく、10件程度の求人に絞った検証用フィードを用意します。 その上で、以下の順で確認するとエラーが潰しやすいです。

1. XMLとして整形式か（タグの閉じ忘れ、文字コード、エスケープ）
2. 必須項目が揃っているか（空文字・欠落がないか）
3. 値の形式が仕様通りか（日付/給与/勤務地/雇用形態など）
4. 媒体側で取り込みログやエラーが出ていないか
5. 検索結果・詳細表示で意図した見え方になっているか

この手順をテンプレ化しておくと、求人追加やATS改修のたびに「同じ検証」ができます。

問い合わせは、情報が不足すると往復が増えます。下記のセットで伝えると解決が早いです。

• 対象フィードURL（エンドポイント）と取得方法（IP制限・認証の有無）
• 発生日時と症状（取り込み停止、特定求人だけNG、表示崩れ など）
• 該当求人のjob_id、該当タグ、該当箇所の抜粋
• 期待する表示（正しい値の例：給与は下限/上限、日付はISOなど）

また、運用の観点では「いつから・どのくらい影響が出ているか（掲載数、応募数）」を添えると優先度が上がることがあります。

求人データフィードは「媒体に求人を届けるための共通言語」です。非エンジニアでも、次の3点を押さえるだけで 運用改善のスピードが上がります。

• 構造：ルート→求人一覧→求人1件の階層が崩れないこと
• 形式：文字コード・エスケープ・日付/給与/勤務地の統一
• 検証：小さく試し、再現性のある手順でエラーを潰す

まずは「必須項目がすべて埋まっているか」「審査で止まりやすい形式（文字コード・給与・勤務地）にズレがないか」を棚卸しするのが第一歩です。 ATS側の出力仕様と媒体要件のギャップが見えたら、マッピングや加工ルールを定め、更新に強いフィード設計にしていきましょう。

「どこが原因か分からず止まっている」「媒体が増えて運用が破綻しそう」といった状況では、フィード設計と運用ルールの見直しだけで 掲載の安定化・応募獲得の改善に繋がるケースがあります。お気軽にご相談ください。