よくある質問
Indeed API との連携に関するよくある質問への回答を確認します。OAuth認証情報はクライアントIDとシークレットです。パートナーコンソールでこれらの認証情報にアクセスします。クライアントIDとシークレットをアクセストークン（長い暗号化された文字列）と交換します。すべてのAPI呼び出しにこのトークンを含めて、アプリのIDと権限を認証します。アクセストークンの有効期限は1時間です。
認可コードフロー（3レグOAuth）が必要な連携を構築しているATSで、IndeedにOAuthアプリケーションを登録していない場合は、OAuthクライアントIDを作成する必要があります。
Indeedパートナーになると、IndeedはIndeedのAPIとサービスを製品に統合するアプリをセットアップします。IndeedはIndeedユーザーアカウントにパートナーコンソールへのアクセスを付与し、アプリのOAuth認証情報（クライアントIDとシークレット）にアクセスするために使用します。
これらのOAuth認証情報をアクセストークンと交換するために必要です。その後、Indeed API呼び出しにアクセストークンを含めて、アプリのIDと権限を認証します。
アクセストークンの有効期限は1時間のため、1時間ごとにOAuth認証情報をアクセストークンと交換します。
認可コードフロー（3レグOAuth）では、アプリは認可コードをリクエストする必要があります。認可コードは、ユーザーとその関連雇用主アカウントに代わってアプリが操作する権限を付与します。たとえば、このフローを使用してIndeed面接を作成したり、スポンサー付きキャンペーンを作成したりします。
アクセスしたいアカウントのユーザーがこのコードを付与します。コードの有効期限は10分です。認可コードを取得したら、Indeedユーザーアカウントでパートナーコンソールにログインします。
ダッシュボードで、アプリリストからアプリを選択します。アプリ詳細ページの認証情報タブには、OAuth認証情報（クライアントID、シークレット、認可コード）が表示されます。これらの認証情報をアクセストークンと交換します。
When you request an access token, you receive a response like this:
{ "access_token": "<access_token>", "refresh_token": "<refresh_token>", "id_token": "<id_token>", "scope": "offline_access employer_access email", "consented_scope": "offline_access employer_access email", "convid": "1er835qvtu54n800", "token_type": "Bearer", "expires_in": 3600}JWTデバッガーにアクセスします。
Indeed redirects the user to the page at the redirect_uri endpoint with the code and state parameters appended. For example:
http://www.companyname.com/oauth/indeed?code=rXZSABCyYQHQ&state=employer12https://apis.indeed.com/oauth/v2/tokensエンドポイントにPOSTリクエストを送信します。
code、client_id、client_secret、redirect_uri、grant_typeパラメータを指定する必要があります。オプションでemployerパラメータを指定できます。
See Get access token that represents an employer.
This authorization link triggers the display of these screens:
| Screen | Description |
|---|---|
| Authentication | Appears when the user is logged out of Indeed. |
| OAuth consent | Enables a user to grant consent for any scopes that the OAuth app requests, such as the employer_access scope. |
| Indeed employer selection | Enables a user to select an employer from a list of employers associated with the user account. |
ユーザーアカウントに雇用主が関連付けられている場合は、認可コードをリクエストする際にprompt=select_employerを指定する必要があります。このパラメータにより、認可するユーザーにIndeed雇用主選択画面が表示され、ユーザーが雇用主アカウントを選択できます。
アクセストークンは1つの雇用主のみを表します。雇用主を切り替えるには、アクセストークンを取得してください。
すべてのIndeed エントリー連携には、スクリーナー質問、人口統計データ取得を含む更新されたスキーマによる均等雇用機会（EEO）質問（米国雇用主をサポートする場合）、および応募者ステータス連携機能が必要です。
この短い動画では、新機能と組織が取るべきアクションを要約しています。Indeed エントリー機能強化プレゼンテーションのコピーにアクセスできます。
Indeedは、データループを完結させ、採用プロセスにおける応募者の進捗を正確に追跡するために、応募者ステータス連携を要求しています。この機能は、マッチングアルゴリズムの改善とクライアントのパフォーマンスの最適化に不可欠です。応募者ステータス連携は 、スクリーナー質問およびEEOコンプライアンス（該当する場合）とともに、すべてのIndeed エントリー連携の必須コンポーネントです。
Indeedは、進化する法律や規制に対応して義務を継続的に評価・調整しています。法的要件の変更に伴い、Indeedはコンプライアンスに引き続き取り組み、適用されるデータ保護およびプライバシー法との整合性を確保するためにポリシーと慣行を更新します。
Indeedは、GDPRおよびその他の関連プライバシー法を完全に遵守しています。応募者ステータス連携データの返却は、求人マッチングと採用成果の改善にのみ使用されるため、法的およびコンプライアンス義務に沿っています。すべてのデータ処理は、プライバシーポリシーおよび適用される規制に従って行われます。IndeedのGDPRコンプライアンスの詳細については、Indeed GDPRコンプライアンスをご覧ください。
現在、雇用主固有のデータはクライアント固有のマッチングを改善するものではありませんが、応募者ステータスデータは、雇用主がどの候補者を適任と考えるかをIndeedが理解するのに役立ちます。このフィードバックはIndeedのマッチングモデルに直接反映され、より精緻な候補者レコメンデーションが可能になります。
ATSからの候補者応募者ステータスデータを使用することで、インデックス済み求人は全体で14%多くのポジティブな成果を得ています。
雇用主がIndeed エントリー連携をオプトアウトする一般的な理由は、任意のEEOおよび必須のノックアウト質問をサポートしていないことです。
Indeedには、すべての連携がスクリーナー質問をサポートし、米国の求人についてEEO質問をフラグ付けすることを要求する全社的な要件があります。雇用主は、人口統計質問の方法について引き続き責任を負います。すべての連携がUS求人のEEO質問のフラグ付けをサポートすることを要求することで、Indeedは求職者に一貫した体験を提供するより高品質な連携を推進しています。
クライアント認証情報はIndeed エントリーAPIトークンとシークレットです。これらの認証情報はパートナーコンソールでアクセスします。
Indeed エントリーの認証情報タイプを持つ共有APIシークレットを使用します。
Indeedは、HMAC-SHA1アルゴリズムを使用してメッセージ署名を計算します。この署名はHTTP X-Indeed-Signatureヘッダーとして送信されます。
Indeed エントリーは、POSTリクエストの真正性を確認するために使用できるHTTPヘッダーを含むPOSTリクエストをpostUrlに送信します。
現在、EEO/人口統計質問はEEOコンプライアンスのために米国ベースの求人に限定されています。
Indeedには資格タイプの質問があります。これらは非ブロッキ ング質問であり、回答が資格で定義された仕様を満たしていなくても、応募者は応募フローの次のセクションに進むことができます。この場合、応募は配信されます。
Indeed エントリー質問ツールを使用して、スクリーナー質問JSONファイルの構文を確認できます。このツールは、Indeed エントリー応募フローでスクリーナー質問がどのように表示されるかを示します。
求人や連携をライブにプッシュする前にテストするために、IndeedはIndeed エントリーXML設定テストツールを提供しています。設定可能なパラメータタブで、関連情報を入力してエンドツーエンドの応募フローのテストを開始します。
Indeed エントリー設定のテストをご覧ください。
POSTリクエストの場合、応募は同じ求人IDと同じ求職者メールアドレスからのIndeed応募が過去120日以内にある場合、重複とみなされます。
POSTリクエストへの応答時に応募が重複かどうかを判断する際、Indeed以外のソースから最初に送信された応募を使用しないでください。また、同じ求職者メールアドレスから同じ会社の別の求人IDへの応募を重複とみなさないでください。
URLでクロールされるXMLまたはお客様が提供するFTPサーバーでホストされるXMLの場合、Indeedは最後のリクエストの時刻から6時間間隔で1日4回求人データを更新します。Indeedホストのインポートシステムの場合、Indeedは新しいファイルを受信すると、2時間ごとの頻度でXMLフィードを更新します。より頻繁なファイルアップロードは求人データの更新を遅延させる可能性があります。フィードインデックスの遅延を修正するには、アップロードの頻度を減らしてください。
標準フィールドを含む限り、<branch_id>などの任意のフィールドを含めることができます。特定の情報をIndeedに表示する必要がある場合は、<description>フィールドを使用してください。
検索結果での表示は、Indeedの表示ルールに基づいています。検索品質チームは、正当で、ユニークで、詳細な説明と勤務地があり、応募しやすい求人を優先します。
クライアントサイトのデータがIndeedのデータターゲットに対応し、タグが前述のタグのいずれかと一致する場合、検索結果ページに表示されます。
ただし、データタグがIndeedタグと一致しない場合、その表示は、求人がある市場、検索結果ページがデスクトップかモバイルで表示されているか、その他の要因など、さまざまな要因に依存します。
タグに表示する必要がある情報が含まれている場合は、クライアントに<description>タグ内に情報を追加するよう依頼してください。
これらの基準を満たさない求人は検索結果から非表示になる場合があります。クライアントが検索品質チームの投稿のベストプラクティスに従っていることを確認してください。
クライアントがIndeedで求人を見つけるのに問題がある場合は、Indeedにお問い合わせください。
Indeedは、応募ページではなく求人詳細へのURLを必要とします。理由は以下のとおりです：
- Indeed エントリーが失敗した場合、Indeedは求職者を求人URLに誘導します。
- クライアントがIndeed エントリーをオプトアウトした場合、Indeedは求職者が応募するための方法が必要です。
- Indeedのアグリゲーションエンジンは、求人内容と求人アクティビティを確認するためにアクティブなURLを必要とします。
Indeedに初めて掲載する企業、またはすでにIndeedに掲載している企業からの新しい求人ソースの場合、Indeedはアカウントの確認とオーガニックシンジケーションの有効化のために連絡先メールアドレスを要求します。
Indeedが一部のケースでメールアドレスを使用しないことがありますが、すべての求人に対して要求しています。
オープンポジションが存在する各言語で、XMLフィード内のユニークな求人として求人を提供してください。XMLフィードで参照番号を重複させると、最初に出現した求人のみがIndeedに表示されます。
オープンポジションが存在する各勤務地で求人を提供してください。地域全体の求人ではない地域全体の掲載は、Indeedでのオーガニック表示で拒否されます。各求人には固有の勤務地、固有の参照番号が必要であり、ユニークな求人を表す必要があります。そうでない場合、Indeedでの表示が失われます。
州全体の求人を投稿するには、stateおよびcountry要素を使用して州と国の情報を送信し、<city>と<postalcode>要素を空白のままにします。
例：テキサス州全体の求人：
<city> <![CDATA[]]></city><state> <![CDATA[TX]]></state><country> <![CDATA[US]]></country><postalcode> <![CDATA[]]></postalcode>例：東京都全体の求人：
<city> <![CDATA[]]></city><state> <![CDATA[東京都]]></state><country> <![CDATA[JP]]></country><postalcode> <![CDATA[]]></postalcode>国全体の求人を投稿するには、<country>要素を使用して国を送信し、<city>、<state>、<postalcode>に空白の値を送信します。
例：米国全土の求人：
<city> <![CDATA[]]></city><state> <![CDATA[]]></state><country> <![CDATA[US]]></country><postalcode> <![CDATA[]]></postalcode>例：日本全国の求人：
<city> <![CDATA[]]></city><state> <![CDATA[]]></state><country> <![CDATA[JP]]></country><postalcode> <![CDATA[]]></postalcode>可能な限り最も具体的で正確な勤務地に求人を投稿してください。すべての求人は、例に示すように要素が空白であっても、フィードで使用されるすべての要素を含める必要があります。
<city>または<state>要素を使用して、値「remote」を送信することで求人が完全リモートであることを示すことができます。この値を使用する場合、両方の要素に「remote」と入力してください。あるいは、一方の要素に「remote」と入力し、もう一方を空白のままにすることもできます。一方の要素に「remote」を入力し、もう一方に実際の勤務地を入力しないでください。
完全リモートだが特定の州に居住する必要がある求人の場合、<remotetype>要素を州全体の求人投稿スキーマと組み合わせて使用できます。
日本のみ。 日本でリモート求人を投稿する場合、<city>と<state>を空白のままにし、<remotetype>を使用してください。完全リモートだが特定の都道府県に居住する必要がある求人の場合、<remotetype>要素を都道府県全体の求人投稿スキーマと組み合わせて使用できます。
例：テキサス州の完全リモート求人：
<city> <![CDATA[]]></city><state> <![CDATA[TX]]></state><country> <![CDATA[US]]></country><postalcode> <![CDATA[]]></postalcode><remotetype> <![CDATA[Fully remote]]></remotetype>例：東京都の完全リモート求人：
<city> <![CDATA[]]></city><state> <![CDATA[東京都]]></state><country> <![CDATA[JP]]></country><postalcode> <![CDATA[]]></postalcode><remotetype> <![CDATA[Fully remote]]></remotetype>リモートタイプの値：
- Fully remote：従業員がリモートまたは自宅で働きます。
- Hybrid remote：従業員がオフィスとリモートの両方で継続的に働きます。
例：米国の完全リモート求人：
<city> <![CDATA[Remote]]></city><state> <![CDATA[]]></state><country> <![CDATA[US]]></country><postalcode> <![CDATA[]]></postalcode><remotetype> <![CDATA[Fully remote]]></remotetype>例：日本の完全リモート求人：
<city> <![CDATA[]]></city><state> <![CDATA[]]></state><country> <![CDATA[JP]]></country><postalcode> <![CDATA[]]></postalcode><remotetype> <![CDATA[Fully remote]]></remotetype>例：テキサス州オースティンのハイブリッドリモート求人：
<city> <![CDATA[Austin]]></city><state> <![CDATA[TX]]></state><country> <![CDATA[US]]></country><postalcode> <![CDATA[78701]]></postalcode><remotetype> <![CDATA[Hybrid remote]]></remotetype>例：東京都港区のハイブリッドリモート求人：
<city> <![CDATA[港区三田]]></city><state> <![CDATA[東京都]]></state><country> <![CDATA[JP]]></country><postalcode> <![CDATA[100-8602]]></postalcode><remotetype> <![CDATA[Hybrid remote]]></remotetype>できません。Indeed エントリーはすべてのクライアントの求人に対して有効です。クライアントはアカウントレベルでIndeed エントリーをオプトアウトできますが、求人レベルではオプトアウトできません。
いくつかの手順と考慮事項：
- ATSからのオプトイン：ATSプラットフォームからIndeed エントリーを直接オプトインまたはオプトアウトできます。サポートが必要な場合は、ATSにお問い合わせください。
- トラブルシューティング：Indeed エントリーが期待どおりに動作しない場合は、クライアントがオプトインしていることを確認してください。問題が解決しない場合は、かんたん応募が表示されない求人の例を提供し、Indeedサポートにお問い合わせください。
日本の都道府県には<state>フィールドを使用してください。
求職者にサイトを訪問するよう依頼することはできますが、応募を完了するために追加の質問に回答することを要求することはできません。
はい。X-Indeed-Signatureヘッダーは、IndeedからのPOSTリクエストを認証するために必須です。署名が一致しない場合、IndeedはHTTP 401レスポンスコードを返します。
Job Sync APIはIndeed Apply XMLフィードと同じ機能をサポートします。XML連携の代わりにJob Sync APIを使用してください。
Job Sync APIとの連携後、審査用に連携を提出してください。
オンボード時に、2-legged OAuth資格情報（クライアントIDとシークレット）を持つアプリが作成されます。パートナーコンソールで資格情報を取得し、アクセストークンと交換してください。API呼び出しにトークンを含めてください。トークンは1時間で失効します。
OAuthの資格情報はクライアントIDとシークレットで、Partner Consoleでアクセスできます。これらをアクセストークンと交換し、すべてのAPI呼び出しに含めてアプリを認証してください。アクセストークンは1時間で失効します。
求人を最新に保つため、APIはリアルタイムで呼び出してください。
Indeedはクライアントのニーズに応じてティ アとレート制限を割り当てます。レート制限をご覧ください。
いいえ。合計のみ取得できます。
Indeed UIは頻繁に変更されるため、ありません。
最大100件です。HTTPリクエストサイズに制限があるため、APIリクエスト1回につき1件の求人投稿のみ作成してください。
求人は投稿直後に公開されます。
createSourcedJobPostingsを呼び出してIndeed上に求人を作成します。employerIdsを設定して投稿を雇用主に関連付けます。例：
typeがFOOATS_EMPLOYER_IDで、ATS内の雇用主IDがabc123の場合、createSourcedJobPostingsを次のように呼び出します。{"employerIds": [{"type": "FOOATS_EMPLOYER_ID","id": "abc123"}]}このIDを作成するにはEmployer Data APIをプロビジョニングしてください。パートナーコンソールで確認できます。
これらの値で
patchEmployerを呼び出します。{"id":{"type": "FOOATS_EMPLOYER_ID","id": "abc123"}}idはemployerIdsと一致する必要があります。詳細はEmployer Dataを参照してください。
雇用主ごとに、一意のsourceName値を選択してください。sourceNameは、親組織など一括管理され採用を行っている求人グループの、人間が読める会社名または組織名です。
この値は数値やIDではありません。一意性のために数値やIDを名前に付加することはできます。例：
| 推奨 | 非推奨 |
|---|---|
| |
| |
1雇用主の複数求人グループ：求人グループごとに一意の値を使用してください。複数ブランド拠点を持つ子会社やフランチャイズは同じsourceNameを使用してください。値は求人グループ間で一意で、単一のsourceType（組織タイプ）を持つ必要があります。
会社名変更：元のsourceNameを維持し、companyNameを新名に更新してください。
別々に管理するフランチャイズ：店舗番号や店舗IDなどの値を使用してください。
sourceName: "ConvenienceMart store ID 345"重複するsourceName：ユーザーがソースを区別できるよう、名前を一意にしてください（例：所在地を追加）。
求人を別々に管理する支店：一意の値を使用してください。例：ConvenienceMartに2支店3店舗ある場合、支店・店舗ごとに求人を別管理するには、次のcompanyNameとsourceNameの組み合わせを使用します。
| 支店 | 店舗 |
|
|---|---|---|
| Tokyo | Shibuya station | |
| Shinjuku station | | |
| Osaka | Osaka station | |
この雇用主をIndeedの全言語・全国で使用するには、isGlobalDefaultをtrueに設定してください。
Indeedは投稿事業体の確認のためクライアントの連絡先メールを使用します。contactEmailはどこにも表示されません。
リモート求人は、特定の勤務地への出勤を必要としません。
次のいずれかの働き方ができます。
- リモート全国求人は、国内のどこからでも働けます。
- リモート地域求人は、都道府県などの地域内のどこからでも働けます。
リモート全国求人またはリモート地域求人を定義するには、次のフィールドを設定します。
| リモート求人タイプ | remoteType | cityRegionPostal | streetAddress |
|---|---|---|---|
| 全国 | Fully Remote | 空欄のままにします。 | 空欄のままにします。 |
| 地域 | Fully Remote | 日本の求人では空欄のままにし、それ以外では地域を設定します。 市区町村を設定すると、その求人はリモート求人になりません。 | 空欄のままにします。 |
createSourcedJobPostingsにはXMLの<keywords>タグに相当するフィールドはありません。
ポジションと勤務地の組み合わせごとに1件の求人投稿を投稿してください。
jobPostingId、sourceName、またはクライアントIDを変更すると、APIは新しいsourcedPostingIdを返します。
これらのフィールドを変更する前に、現在のsourcedPostingIdでexpireSourcedJobsBySourcedPostingIdを呼び出して求人を失効させてください。
sourcedPostingIdは必ず保存してください。求人の失効や再有効化に必要です。求人投稿の失効をご覧ください。
説明に、業務完了までの想定期間を記載してください。
例：
3か月プロジェクトで120万円の場合は、月40万円と記載
給与レンジまたは固定給与を定義するには、次のフィールドを設定します。
| 定義する内容 | minimumMinor | maximumMinor |
|---|---|---|
| 給与レンジ | 最低給与に設定。 | 最高給与に設定。 |
| 最低給与のみの給与レンジ | 最低給与に設定。 | |
| 固定給与 | 固定給与に設定。 | 固定給与に設定。 |
次のフィールドにデータを設定します。
| フィールド | 値 |
|---|---|
jobPostingId | ATS内で一意のID（UUID可）。このIDで再投稿すると、以前失効した求人を再開できます。 |
jobRequisitionId | 人間が読めるID。ATS内での一意性は不要です。 |
求人更新でcreateSourcedJobPostingsを呼び出してください。作成時と同じjobPostingId、sourceName、OAuthクライアントIDを使用してください。Indeedはこれらで重複排除します。変更がなくても必須の求人詳細はすべて含めてください。
日本では以前必須でしたが、現在は使用されていません。
findEmployerJobsPartnerを呼び出して求人投稿一覧を取得します。レスポンスには求人ごとにsourcedPostingIdが含まれます。そのIDをcreateSourcedJobPostingsまたはupdateSourcedJobPostingsで更新に、expireSourcedJobsBySourcedPostingIdで失効に使用します。
Indeedの基準を満たさない求人は審査の対象となり、採用企業から追加情報が必要な場合があります。求人が求職者に表示され続けるよう、求人投稿基準 - 英語または求人投稿基準 - 日本語に従ってください。
求人投稿を作成した後、Indeedに表示され求職者が検索できるようになるまで1〜2時間かかります。
Indeed PLUSは複数の求人掲示板と連携しています。表示フィールドは各求人掲示板が決定します。
日本の求人の場合：求人投稿については日本固有の求人フィールドの表示を、雇用主については日本の雇用主フィールドの表示をご覧ください。
いいえ。
クライアント向けに求人表示を有効にするには、Job Sync APIガイドをご覧ください。
ATSでは、クライアントに求人ごとの画像が表示され、次のいずれかが示されます。
- Indeedで検索可能。
- 検索可能にするにはスポンサーが必要。
見つからない（次のいずれか）：
- 求人が存在しない。
- ユーザーがその求人にアクセスできない。
クライアントが画像をクリックすると、Indeed上の求人に関する追加情報にアクセスできます。
クライアントが画像をクリックすると、複数のステータスが表示される場合があります。求人ステータスをご覧ください。
ユーザーがパートナーUIで求人を表示したとき、1時間に1回までステータスを更新できます。Indeedはこれを制御しません。
はい。
いいえ。Searchableと表示されます。
求職者はIndeedの検索結果でこれらの求人を表示できません。
いいえ。公開中の求人の表示のみ確認できます。
失効求人の表示ブール値は不正確な場合があります。ユーザーには表示しないでください。
IndeedはATSフィードの求人数と雇用主の採用サイトで表示されている求人数を比較します。差異がある場合、Indeedは調査を行い、契約上の義務の遵守を確認します。
各ATSパートナーがアクセス可能なすべての求人を送信していれば、ATSは準拠しています。フィードと採用サイトの求人数が異なる場合、パートナーマネージャーが不足している可能性のある求人とクライアントの特定を支援します。
Indeedに求人を送信しない場合（例：将来の求人、プライバシーまたは機密性のため）、雇用主は会社のレターヘッドで停止要請を提出する必要があります。手紙をパートナーマネージャーに共有するか、非管理の場合はmarketplacesupport@indeed.comに送信してください。
雇用主は機密または将来の求人リストをオプトアウトできます。Indeedは求人の記録を保持しますが、検索や雇用主アカウントには表示されません。
expireSourcedJobsBySourcedPostingIdを呼び出して求人投稿を失効させます。求人はIndeedに表示されなくなります。
再有効化は有効期限切れの求人を再有効化をご覧ください。
通常は保持されます。求人が30日以上失効したままの場合、変更することがあります。
createSourcedJobPostingsを呼び出してsourcedPostingIdを取得します。
求人投稿を失効させるには、その求人のsourcedPostingIdでexpireSourcedJobsBySourcedPostingIdを呼び出してください。
有効期限切れの求人を再有効化するには、アクティブな求人を更新するときと同様、失効した求 人と同じjobPostingIdとsourceNameでcreateSourcedJobPostingsを呼び出してください。
ATSで再有効化日を設定するにはdatePublishedを更新してください。
失効から30日以内であれば求人を再有効化できます。
30日を超えると、Indeedは求人統計と設定をアーカイブする場合があります。30日以降の再有効化では新しいsourcedPostingIdが返されることがあります。同じsourcedPostingIdと新しいIDの両方に対応するようコードを用意してください。
sourcedPostingIdを保存してください。求人の失効や再有効化に使用します。
求人を失効させるにはAPIを呼び出してください。
GRAPHQL_PARSE_FAILEDエラーは、GraphQL操作文字列の構文エラー（多くの場合descriptionフィールドのエスケープされていないHTML）を意味します。求人説明のフォーマットとGRAPHQL_PARSE_FAILEDエラーをご覧ください。
求人の掲載時に問題が発生する場合があります。連携を正常に機能させるため、データを確認して修正してください。
| 問題 | 説明 |
|---|---|
hasProbationaryPeriod のデフォルト値が UNKNOWN | 日本では、この値がスクリーニングに失敗することがよくあります。このフィールドは他のロケールでは適用されません。 |
| データが正しくフォーマットされていない | データのフォーマットが不正な場合、無効なAPI呼び出しが発生し、連携データの信頼性に問題があることを示します。求人の作成を参照してください。 |
| 求人リンクが求人詳細ページにつながらない | サイト上の求人詳細ページへのリンクを提供してください。Indeedはこれらのリンクを使用して、求人コンテンツの一貫性と有効性を確認します。 リンクが応募フォームやその他のページではなく、求人詳細ページに誘導するようにしてください。有効なリンクにより、Indeedはデータの整合性を保ち、求職者が貴社の採用サイトで求人を確認できるようになります。 |
| 求人説明が不完全 | 求人説明に必要な情報をすべて含めてください。特定のフィールドのデータが求職者に表示されるとは限りません。 求人説明は最終的な情報源です。求人説明のフォーマットを参照してください。 |
| パートナーサイトとIndeedの求人説明のレイアウトが異なる | Indeedはコンテンツが一致しているかどうかを確認するためにウェブサイトをチェックします。求人説明のレイアウトが大きく異なる場合、Indeedはコンテンツの不一致を理由に求人を非アクティブとしてマークし、期限切れにする場合があります。 サイトとIndeedのデータの間で求人説明の順序を一致させてください。 |
| データがIndeedのシステムと互換性がない | Indeedがデータの相当部分が正しくない表示を引き起こすと判断した場合、修正が必要です。 相当部分は、問題の発生頻度と求職者への影響によって判断されます。 例： |
| 求人コンテンツがAPIフィールドを誤用している | タイトルにクリックベイトを含める、場所フィールドに場所以外のデータを入力するなど、無関係な情報を提供すると、Indeedが連携をブロックする可能性があります。 相当部分は、問題の発生頻度と求職者への影響によって判断されます。 |
| 求人が最新の状態でない | Indeed上の求人は、サイトと一致するように期限切れにするか更新する必要があります。古い求人は求職者に問題を引き起こします。 求人を常に最新の状態に保ってください。そうしないと、Indeedが連携をブロックしたり、同期が取れていないコンテンツを期限切れにしたりする場合があります。求人のアップサートを参照してください。 |
多くの場合、クライアントがその求人にアクセスできません。
Indeedが雇用主アカウントと求人を紐付けられるよう、クライアントにIndeedサポートへの連絡を依頼してください。
Job Sync APIのエラーの多くは、切り分けに役立つ情報を含みます。
GraphQLエラーのトラブルシューティングをご覧ください。
エラーを解決できない場合は、次の内容でサポートリクエストを送信してください。
- リクエストとレスポンスのペイロード全体。
- 再現手順。
- エラー内容。
ATSで雇用主がIndeed候補者のステータスを変更すると、ATSは新しいステータスシグナルを匿名化された応募IDおよび日時スタンプとともに送信します。
Indeedがグローバルなインポートシステムから収集した応募者ステータスデータは、求職者プロダクトチームによって集計・分析されています。応募者ステータスデータは、求人広告のターゲティングの改善と応募体験の向上に使用され、候補者が自分の履歴書のスキルが要件をどのように満たしているかをより良く理解できるようにします。
すでにオプトインしているクライアントの応募者ステータスデータへの参加を促す良い方法は、ATS内で候補者をステージごとに移動させることの重要性を伝えることです。たとえば、CVを確認した後、ステータスを確認済み/スクリーニング済みに変更するなどです。
ステータスはATSによって異なりますが、最も重要なのは、Indeedが雇用主のパイプライン内の各候補者についてできるだけ多くの更新を受け取ることです。
継続的なステージ/ステータス更新を使用するクライアントにとってのメリットの一部：
- 雇用主は、Indeedが将来的により良くマッチした候補者を提供するのを支援します。
- 雇用主は、どの職種に十分な候補者がいるか/いないかを素早く特定できます。これにより、クライアントは苦戦している職種にフォーカスと予算をシフトできます。
- 雇用主は、プロセスの各段階に通常かかる期間を分析することで、採用タイムラインをより良く理解できます。
Indeedは品質シグナルを、NEW、INCOMPLETE、UNABLE_TO_MAP以外のシグナルと定義しています。ティアードステータスの資格を得るには、ATSは最低55%の品質シグナル採用率を達成する必要があります。
Indeedは、ATSの応募者ステータス採用率を、Indeedに応募者ステータスシグナルを送信しているIndeed エントリー対応求人の数で測定します。すべてのクライアントがIndeed エントリーにオプトインしており、ATSが応募者の受領確認をIndeedに送信している場合、100%の応募者ステータス採用率となります。クライアントの50%がIndeed エントリーにオプトインしていて、それらすべての求人で応募者ステータスシグナルを送信している場合、応募者ステータス採用率は100%となります。
Indeedは、ATSパートナーがクライアントの候補者の採用ファネルにおける移動を制御できないことを理解しています。応募者ステータスシグナル採用率は、シグナルが送信されたIndeed エントリー対応求人の合計割合で測定されます。IndeedがATSによって求人が受信されたことの確認を受け取れば、それはシグナル送信済みとなります。Indeedは、パートナーがすべての品質応募者ステータスシグナルをマッピングし、クライアントにそれらの使用を促し、応募マイルストーン達成後にIndeedへのシグナルのリリースを自動化して、Indeed エントリー連携のパフォーマンスを改善し、より高品質なパイプラインを構築することを推奨しています。
給与と勤務地のフィールドは、パートナーがクライアントの求人とともにIndeedに送信できるデータノードです。給与は求職者にとって最も重要な情報の1つです。
勤務地は求人情報で最も頻繁に要求される詳細の1つであり、可能な限り正確であることが理想的です。
給与と正確な勤務地を含む求人はより良いパフォーマンスを発揮します。給与と正確な勤務地を含むスポンサー付きインデックス済み求人は以下を獲得します：
- 2.5倍の求人あたりインプレッション
- 2.3倍の求人あたりクリック
- 3.3倍の求人あたり応募開始
Indeedはサンドボックス環境を提供していません。本番環境でIndeed APIからデータを読み取ることは、コストやアカウントへの影響なしに行えます。作成や更新のオペレーションをテストする場合は、支出を防ぐためにキャンペーンを一時停止状態（status=paused）で作成してください。
インデックス済み求人のクエリ形式をご覧ください。
アカウントの予算をクリアするには、クライアントサクセス担当者に連絡してください。
URLまたはATS提供のFTPサイトでクロールされるXMLの場合、Indeedは最後のリクエストから6時間ごとに1日4回求人データを更新します。IndeedがホストするFTPの場合、新しいファイルを受信すると最大2時間ごとにXMLフィードを更新します。ファイルのアップロード頻度が高すぎると、前回の実行が停止し、求人の更新が行われなくなる場 合があります。
標準フィールドが存在する限り、任意のフィールド（<job_type>、<branch_id>など）を含めることができます。
Indeedでは、求人説明ページ（応募ページではない）を指すURLが必要です。理由は以下のとおりです。
- Indeed エントリーが失敗した場合、求職者を求人URLに誘導します。
- クライアントがIndeed エントリーをオプトアウトした場合、求職者が応募する方法が必要です。
- アグリゲーションエンジンは、求人コンテンツと求人のアクティビティを確認するためにアクティブなURLが必要です。
現在掲載しているすべての言語で、その求人をXML内のユニークな求人として提供してください。XML内でリファレンス番号を重複させた場合、最初に出現した求人のみがIndeedに表示されます。
募集中のすべての勤務地で求人を提供してください。地域全体の求人ではない地域全体の投稿は、Indeedでのオーガニック表示が拒否され ます。各求人には固有の勤務地、固有のリファレンス番号が必要で、ユニークな求人を表す必要があります。それ以外の場合、Indeedでの表示が低下します。
Indeedでは、市区町村、都道府県/州、国、郵便番号の要素が必要です。これらの要素が提供されない場合、求人はデフォルトでオーガニック表示を受けません。
地域全体の正当な投稿やリモートワークの求人がある場合は、ファイルに含めてクライアントにオーガニック表示を依頼してください。クライアントがIndeedアカウントを持っている場合は、ログインしてサポートを受けられます。アカウントを持たないク ライアントは、Indeedのウェブサイトから直接お問い合わせできます。
Indeedに新しく登録する企業、またはすでにIndeedに掲載されている企業からの新しい求人ソースの場合、アカウントの確認とオーガニック配信を有効にするために連絡先メールアドレスが必要です。メールアドレスが使用されない場合もありますが、すべての求人に必要です。
XMLからクライアントの求人のすべての<job>要素を削除してください。クライアントは求人ごとにオプトアウトすることはできず、Indeedへの配信を完全にオプトアウトする必要があります。XMLとクライアントの求人ポータル間で求人数に差異がある場合、正確性のために求人数が最も多いソースが優先されます。
<remotetype>要素を含め、次のいずれかのオプションを指定してください。
- Fully remote
- Hybrid remote
- WFH Flexible（米国のみ）
「完全リモート」と見なされるには、次のフレーズのいずれかを含めてください：「This is a remote position」、「Employees work remotely」、「Remote work allowed」。
「在宅勤務の柔軟性がある」と見なされるには、次のフレーズのいずれかを含めてください：「Flexible work from home options available」、「Work from home days possible」、「Options for working from home」。
リモート求人を投稿するには、Indeedが勤務地データをキャプチャするために使用する要素（<city>、<state>、<country>、<postalcode>）を使用してください。
米国でリモート求人を投稿するには、<city>を「Remote」に設定し、<state>と<postalcode>を空にしてください。空にしない場合、求人はリモートポジションとして投稿されません。
すべての求人投稿インデックスは2020年2月1日をベースライン（= 100）として使用しています。このベースラインにより、国や期間を超えた一貫した比較が可能になります。
季節調整済み（SA）インデックスは、基調的なトレンドを示すために典型的な季節パターンを除去します。非季節調整（NSA）インデックスは、年末年始の採用などの通常の季節変動を含む生データを示します。
- 求人投稿およびリモートワークデータ：毎日更新
- 賃金上昇データ：毎月更新
- AI求人投稿データ：毎日更新
カバー範囲はデータセットによって異なります。各データセットと粒度レベルで利用可能な国を確認するには、findHiringLabCountriesPublicクエリを使用してください。
過去のデータを取得するには、カーソルベースのページネーションを使用してください。必要なフィルタを設定し、前回のレスポンスのafterパラメータとカーソル値を使用して結果をページネーションしてください。
リクエストあたりの最大結果数は50件です。より大きなデータセットを取得するにはページネーションを使用してください。
APIは時系列順でデータを返します。必要な期間にフィルタするには、アプリケーションロジックでページネーションと日付フィールドを使用してください。
はい。フィルタオプションを使用して、企業名、日付、またはステータスで求人を表示できます。
アクセスは日本のJob Syncインテグレーションを持つパートナーに限定されています。アクセスできるはずだと思われる場合は、Indeed担当者に連絡して ください。
Data viewerでのリジェクトは、求人は受信されたがモデレーションに通過しなかったことを意味します。
ガイダンスについてはクライアントサクセスチームに連絡してください。Data viewerでは具体的なリジェクト理由は表示されません。
インテグレーションタイプを切り替えると、モデレーションルールがIndeedとIndeed PLUSで異なるため、リジェクトされる求人が変わります。Indeed PLUSではリジェクトされてもIndeedでは受け入れられる求人がある場合があります。そのような場合、求人はIndeedのウェブサイトに表示されますが、Indeed PLUS機能の対象にはなりません。
いいえ、Data viewerでは有効期限切れの求人は表示されません。
いいえ。Data viewerでは、正常に投稿された求人のモデレーションステータスのみが表示されます。
Indeedは、プラットフォーム間でシームレスかつ安全な採用ソリューションを提供するための技術パートナーシップを構築しています。パートナーページでパートナーシップの目標についてフォームにご記入ください。
Indeedはキャパシティの拡大に取り組んでいます。Indeedが連携リクエストの優先順位を決定できるよう、貴社の年間推定求人数をご提供ください。次のステップが利用可能になった時点で、提供されたメールアドレスにIndeedからご連絡します。
プログラムは毎年6月に更新されます。パートナーはプログラム告知メールに添付されたGoogleフォームから適格性の証明を提出する必要があります。ティアードパートナーは、Indeed連携の最新ステータスに基づいて毎年更新されます。初回ローンチ後、採用基準は2四半期連続で満たし、プログラム年度を通じてその水準を維持する必要があります。
認定されたパートナーには6月にメールで通知され、7月にindeed.comでティアードパートナーとして公開されます。
すべての連携パートナーは、Indeedとの連携に対する技術サポートを受けることができます。Indeedはシルバーティアパートナーにはオンボーディングと連携ローンチのサポートを、プラチナパートナーには専任のパートナーマネージャーを提供します。専任のパートナーマネージャーを受けるには、プラチナティアの基準を満たす必要があります。
専任のパートナーマネジメントは、共通のお客様に高いインパクトのある連携を提供するために必須ではありません。
現在、ATSプラットフォームのみがこのプログラムに参加できます。日本企業を除くすべてのATSパートナーは、事業国に関係なく、指定された基準を満たせばティアリングプログラムの資格を得ることができます。Indeedには、日本のパートナー向けの日本固有のティアリングプログラムがあります。
Indeedは、インテグレーションデリバリーチームを通じてすべてのパートナーに連携サポートを提供しています。ティアードパートナーは優先的な技術サポートを受けられますが、すべてのパートナーはパートナーコンソールのサポートフォームからサポートを受けることができます。
1四半期にわたって採用率を満たさなかった場合、パートナーは警告を受けます。改善が見られない場合、2四半期連続で非適格となった後にティア特典を失うリスクがあります。
アクティブな連携は、プログラム年度を通じて運用可能な状態を維持する必要があります。パートナーはIndeedの製品リリースまたは更新スケジュールに従って連携を更新する必要があります。連携の維持を怠ったパートナーは、いつでもティア特典を失うリスクがあります。フィードソース承認 （FSA）に置かれたパートナーは、ティアードステータスを失うリスクがあります。
パートナープログラムの基準を満たす年間締め切りは6月1日です。ティアリングの資格を得るには、Indeed エントリーコンプライアンスの締め切りを満たしている必要があります。
| 締め切り | 要件 |
|---|---|
| 4月1日 | すべてのパートナーに対するIndeed エントリーポリシー。Indeed エントリー連携には、スクリーナー質問、均等雇用機会（EEO）質問（米国の求人の場合）、および応募者ステータス連携機能が必要です。 |
| 6月1日 | ティアードステータスの達成。パートナープログラムの要件をご覧ください。 |
ゴールドまたはプラチナステータスを達成するためにJob Sync APIへの移行を約束したパートナーの場合、開発作業を完了しライブにする締め切りは10月1日です。パートナーがティアードステータスを達成するためにローンチを約束し、10月1日までにライブにならなかった場合、ティアードステータスを失います。
応募者ステータス連携を通じて収集されたフィードバックデータは、Indeedのマッチングアルゴリズムの向上とクライアントの採用パフォーマンスの改善にのみ使用されます。このデータは他の目的には使用されず、法的およびコンプライアンス義務の範囲内でのみ保持されます。
- 短期的な使用：データは求人レコメンデーションの改良、候補者と雇用主のマッチングの最適化、採用結果に関するリアルタイムのインサイト提供に役立ちます。
- 長期的な使用：時間の経過とともに、集計されたデータはAI駆動モデルの継続的な改善に貢献し、雇用主と求職者にとってより良い採用効率と関連性を確保します。
Indeedは、プライバシーポリシーおよび法的義務に厳密に従って、応募者ステータス連携データを処理、保存、使用しています。
- 処理と使用：データは求人マッチングアルゴリズムの向上、クライアントの採用パフォーマンスの改善、応募者の進捗に関するインサイトの提供にのみ使用されます。これらの目的以外には使用されません。
- 保存とセキュリティ：データは安全に保存され、これらの機能を果たすために必要な期間のみ保持されます。すべての適用される法的および規制要件に準拠しています。
- データ共有：Indeedは、法律で義務付けられている場合またはプライバシーポリシーに明示的に記載されている場合を除き、応募者ステータス連携データを他の機関または第三者と共有しません。
Indeedのデータ取り扱いの詳細については、以 下をご覧ください：
Indeedはデベロッパー契約条件（Indeedデベロッパー契約）に記載されているとおり、APIの使用状況を追跡しています。また、Indeedは求人マッチング機能の向上と採用成果の改善のために、パートナーに応募者ステータスシグナルを要求しています。
Indeedのプライバシーポリシー（例：セクション4「情報の目的、使用、開示」）には、Indeedが個人データを処理する方法とその処理の目的が詳述されています。これには、Indeed製品の改善、ユーザーの嗜好の判定、不正行為の検出支援、および特定のマーケティング目的でのデータ使用が含まれます。デベロッパー契約がこれをカバーしています。
はい、応募者ステータスは匿名化され、プライバシー保護のために安全に処理されます。Indeedはプライバシー法へのコンプライアンスを確保し、すべての追跡データのセキュリティを維持するために厳格なデータ保護措置を実施しています。
Indeedは、データが収集または処理される目的に関連して必要な範囲で個人データを保持します。これらの目的はプライバシーポリシーに記載されています。また、法的義務の遵守に必要な場合も保持されます。Indeedが保存する個人データが保存される必要がなくなった場合、適用される法的要件に従い、Indeedはそのような個人データを削除します。
Indeedは、管理下にある個人データへの不正アクセス、開示、破壊、偶発的な喪失から保護するために、業界標準のセキュリティ対策を使用しています。Indeedが従う慣行は、データの性質、処理のコンテキスト、関連するリスク、および利用可能なテクノロジーによって異なります。詳細については、Indeed Trust Centerをご覧ください。
Indeed エントリーに準拠したATSを使用しているクライアントは、Indeedへの応募者ステータスシグナルの送信をオプトアウトするオプションがあります。このオプトアウトはATSを通じて行います。直接雇用 主が独自のフィードを所有しており、Indeedとシグナルを共有したくない場合は、応募者ステータス連携の構築をオプトアウトできます。
できません。Indeed エントリー連携を使用する場合、応募者ステータス連携の開発が必要です。準拠しない場合、Indeed エントリーを失うリスクがあります。
Indeedと連携する対象のATSかどうかを判断するには、応募者追跡システム（ATS）ガイドラインを確認してください。
利用規約、プライバシー、データ管理ポリシーについては、利用規約をご覧ください。
Indeedのポリシーにアクセスするには、ポリシーをご覧ください。
デベロッパー契約は、貴社がIndeedパートナーになるための申請を行うときに締結されます。Indeedパートナーになるから連携リクエストを送信してください。Indeedが申請を確認し、連携ビルドを審査し、オンボーディングの一環として署名するデベロッパー契約を提供します。開始する前にIndeedデベロッパー契約をご覧ください。
代理店契約は、異なる条件でIndeedのパブリックAPIへのアクセスを付与するデベロッパー契約とは別のものです。これら2つの契約は異なる目的を持ち、互いに独立しています。代理店契約はより広い関係を規定し、デベロッパー契約はAPIへのアクセスと使用に特化しています。
利用規約と技術文書は、法律や技術要件が変更された場合にIndeedが更新できるよう、オンラインのままにしています。重要な変更は当事者間で合意されます。
Indeedユーザーアカウントでパートナーコンソールにログインします。ダッシュボードで、アプリリストからアプリを選択します。アプリ詳細ページの認証情報タブには、OAuth認証情報（クライアントIDとシークレット）が表示されます。
すべてのパートナーは、パートナーコンソールのサポートフォームからサポートを受けることができます。ティアードパートナーは優先的な技術サポートを受けられます。
Indeedは、自動クローラーを使用して公開ウェブサイトから求人を収集してインデックス化します。Indeedクローラーには、Indeedbot（一般的な求人のインデックス化）とIndeedshopbot（小売求人のインデックス化）の2種類があります。ユーザーエージェント、IPレンジ、およびこれらのクローラーの許可またはブロック方法に関する技術的な詳細は、Indeedクロ ーラーについてをご覧ください。