Indeedでエンジニア採用完全ガイド｜求人設計と運用改善術

Indeedでエンジニアを採用するには、候補者が検索するキーワードを盛り込んだ求人票設計と、クリック単価・応募単価を週次で改善する運用体制が不可欠です。スカウト媒体と異なり「待ち」の応募獲得チャネルであるため、向いている職種と向いていない職種をまず見極めることが成果の分かれ目になります。

このページでわかること

• Indeedの仕組み・料金体系とスカウト媒体との根本的な違い

• Indeed PLUSで何が変わったか（連携配信・料金の考え方）

• エンジニア採用でIndeedが「効く職種」「効かない職種」の判断基準

• 検索にヒットする求人票のキーワード設計と構成

• クリック単価・応募単価を下げる週次PDCAの回し方

• スカウト媒体・リファラルとの組み合わせ戦略

TL;DR（要点まとめ）

• Indeedは求人広告ではなく求人検索エンジン。掲載して終わりではなく、検索キーワードへの最適化と継続運用が前提

• 無料掲載でも露出は可能だが、エンジニア職は競争が激しくスポンサー求人（クリック課金）の活用が実質必須

• 2024年1月開始のIndeed PLUSにより、1つの求人をリクナビNEXTなど複数の連携求人サイトへ同時配信できるようになった

• ハイクラス即戦力の獲得には不向き。社内SE・情シス・テックサポート・未経験/若手層・地方採用で力を発揮する

• 求人票には「職種名の一般化」と「技術スタックの明記」が必須。候補者の検索語に合わせないと表示すらされない

• スカウト媒体との併用が前提。Indeedは応募獲得の「面」、スカウトは即戦力獲得の「点」と役割分担する

1. Indeedとは｜求人検索エンジンの仕組みと特性

Indeedは求人情報に特化した検索エンジンであり、従来の求人広告媒体とは構造が根本的に異なります。求職者がキーワードと勤務地で検索し、条件に合致した求人が表示されるという、Google検索に近いモデルで動いています。

採用支援の実務でIndeedの相談を受けるとき、最初に伝えているのは「掲載媒体ではなく検索エンジンとして扱う」という発想の転換です。リクナビNEXTのような掲載型媒体は「枠を買って露出する」モデルですが、Indeedは「検索結果で選ばれる」モデルです。この違いを理解しないまま求人を置いただけでは、表示もクリックもされません。

掲載型媒体・スカウト媒体との違い

エンジニア採用のチャネルは大きく3タイプに分かれます。

1. 検索エンジン型（Indeed・求人ボックス・スタンバイ）: 候補者の検索行動に応じて表示される。応募を「待つ」チャネルで、量の獲得に強い

2. 掲載型媒体（リクナビNEXT・doda求人広告など）: 媒体内の枠に掲載して露出する。媒体の会員層に依存する

3. スカウト型媒体（BizReach・Forkwell・LAPRASなど）: 企業から候補者へ直接アプローチする「攻め」のチャネル。即戦力獲得に強い

筆者が13以上のダイレクトスカウト媒体を運用してきた経験から言うと、Indeedはスカウト媒体の代替にはなりません。役割がまったく違うからです。即戦力エンジニアの多くは転職サイトで能動的に検索しないため、Indeedで出会える層と、スカウトでしか出会えない層を分けて考える必要があります。

料金体系の基本

Indeedの基本的な料金モデルは次の通りです。

1. 無料掲載: 直接投稿すれば費用ゼロで掲載可能。ただし表示優先度は低く、競争の激しい職種では埋もれやすい

2. スポンサー求人（クリック課金）: 求人がクリックされるたびに課金される。クリック単価は競合状況に応じて変動し、一般に数十円〜数百円のレンジ

3. 予算上限の設定: 月額予算を設定でき、上限に達したら配信が止まる。固定掲載料と異なり「使った分だけ」の従量モデル

クリック課金モデルの実務上のポイントは、費用が「応募」ではなく「クリック」に対して発生することです。クリックされても応募されなければ費用だけが積み上がるため、求人票の中身（クリック後の体験）が費用対効果を直接左右します。

また、固定掲載型と違い「掲載期間」という概念が薄いことも特徴です。予算が続く限り配信され、止めたければいつでも止められます。採用計画の変動が大きいスタートアップにとって、この柔軟性は媒体契約の縛りがない分だけ意思決定をシンプルにしてくれます。一方で、放置していても費用が発生し続けるリスクの裏返しでもあるため、後述する週次の定点観測が欠かせません。

2. Indeed PLUSで何が変わったか｜連携配信の仕組み

Indeed PLUSは、1つの求人を複数の連携求人サイトへ自動配信する求人配信プラットフォームです。2024年1月に提供が開始され、Indeedに加えてリクナビNEXTやタウンワークなどリクルート系の求人サイトへ、求人情報をまとめて配信できるようになりました。

従来は「Indeedに出す」「リクナビNEXTに出す」を別々に契約・入稿する必要がありましたが、Indeed PLUS対応のATS（採用管理システム）経由で入稿すれば、求人内容と求職者の属性に応じて配信先が自動最適化されます。連携サイトはその後も拡大しており、エンジニア向けではQiita Careersのような技術者系サイトも連携先に加わっています。

採用担当者が押さえるべき変更点は3つです。

1. 配信面が広がった: 1求人で複数サイトに露出するため、単一媒体よりリーチが拡大した。特に若手・第二新卒層との接点が増える

2. 料金はクリック課金のまま: 連携サイト経由のクリックも含めて課金される。初期費用や媒体ごとの追加掲載料は不要

3. ATS経由の入稿が前提になった: Indeed PLUSの恩恵を最大限受けるには、対応ATSからの入稿が必要。自社のATSが対応しているかの確認が導入の第一歩

ATSの選定や連携の考え方はエンジニア採用に最適なATS（採用管理システム）の選び方と運用ガイドで詳しく解説しています。

3. エンジニア採用にIndeedは向いているか｜判断基準

結論から言うと、Indeedは「すべてのエンジニア採用に効くチャネル」ではありません。応募を待つモデルである以上、転職市場で能動的に検索している層にしか届かないためです。自社の採用ターゲットがどちらの層かで、投資判断は大きく変わります。

統計データで見る前提環境

経済産業省「IT人材需給に関する調査」（2019年）によると、IT人材の不足規模は2030年に最大約79万人と推計されています。また、dodaの転職求人倍率レポートでは、IT・通信系エンジニアの求人倍率は他職種を大きく上回る水準で推移しており、エンジニアは一貫して売り手市場です。つまり経験豊富なエンジニアほど「検索して応募する」のではなく「スカウトを受けて選ぶ」側に回っており、このことがIndeedの向き不向きを決定づけています。

Indeedが効く採用ターゲット

採用支援の現場で効果を実感しやすいのは、次の5つのケースです。

1. 社内SE・情シス・コーポレートIT: 「社内SE 求人 ○○県」のような検索行動が実際に発生する職種。地域名と組み合わせた検索流入が見込める

2. 未経験・ジュニア層・第二新卒: 能動的に求人を検索する層の中心。ポテンシャル採用の母集団形成に向く

3. テクニカルサポート・ヘルプデスク・QA補助: 経験者がスカウト媒体に登録していないことが多く、検索エンジン経由が主要な接点になる

4. 地方拠点・Uターン採用: 「勤務地×職種」検索が基本のIndeedは、地域を限定した採用と構造的に相性が良い

5. SES・受託企業の継続採用: 通年で一定数を採用し続けるモデルでは、従量課金で蛇口を調整できるIndeedが費用対効果を出しやすい

Indeedが効きにくい採用ターゲット

逆に、次のようなポジションでIndeedを主軸にするのはおすすめしません。

1. ハイクラス即戦力（テックリード・EM・アーキテクト）: この層はほぼ検索行動を取らない。スカウトかリファラル、エージェントが主戦場

2. モダンな技術スタックのWeb系経験者: GoやRust、機械学習などの経験者は転職潜在層が多く、待ちのチャネルでは出会えない

3. 採用人数1名の一点もの採用: 運用最適化に時間がかかるIndeedは、短期決戦の1名採用では強みを発揮しにくい

エンジニアとして自分が転職活動をした際も、Indeedで求人を検索した記憶はほぼありません。一方で、人材業界で採用を売る側にいた時代には、社内SEや地方採用でIndeedが圧倒的な応募数を生む場面を何度も見ています。「どの層を採るか」を決めてからチャネルを選ぶ。この順番を間違えないことが重要です。媒体選定の全体像はエンジニア採用媒体の選び方｜現役エンジニアが13サービス使って分かった最適解も参考にしてください。

4. 検索にヒットする求人票設計｜キーワードと構成

Indeedの求人票は「広告コピー」ではなく「検索対象ドキュメント」として設計します。候補者が入力する検索キーワードが求人票に含まれていなければ、そもそも検索結果に表示されないからです。SEOにおけるキーワード設計と同じ発想が求められます。

職種名は「検索される言葉」に合わせる

職種名は求人票の中で最も検索マッチングに影響する要素です。実務では次の3原則で設計します。

1. 一般的な職種名を使う: 「テックエバンジェリスト候補」「開発の仲間」のような独自表現は検索されない。「社内SE」「インフラエンジニア」「Webエンジニア」など、候補者が実際に入力する言葉を使う

2. 対象領域を補足する: 「バックエンドエンジニア（Java/AWS）」のように、職種名に主要技術を添えると、技術名検索にもヒットしやすくなる

3. 1求人1職種に絞る: 「エンジニア（フロント/バック/インフラ）」のような複数職種の同時募集は検索精度も応募率も下がる。職種ごとに求人を分ける

本文に技術スタックと働き方を明記する

エンジニアの検索語は職種名だけではありません。「Python リモート」「AWS 自社開発」のように、技術名と働き方を組み合わせて検索するケースが多いため、次の要素を本文に必ず含めます。

1. 開発言語・フレームワーク・インフラ環境: 使用するスタックを具体的に列挙する。「モダンな環境です」では検索にも候補者の判断にも引っかからない

2. 開発体制と開発プロセス: チーム規模、コードレビューやCI/CDの有無など。経験者ほどここを見て応募を判断する

3. 働き方の条件: リモート可否・フレックス・残業実態。検索フィルタと検索語の両方で使われる頻出条件

4. 給与レンジの明示: 「経験・能力による」だけの求人はクリック後の離脱が増える。レンジ公開は応募率に直結する

クリック後の離脱を防ぐ構成テンプレート

検索結果でクリックされた後、候補者は数十秒で「読み進めるか戻るか」を判断します。実務で離脱が少ないと感じる求人票の構成は次の順序です。

1. 冒頭3行で「何をする仕事か」を要約する: 事業内容の長い説明から始めない。職務内容→技術環境→働き方の順で結論を先に置く

2. 業務内容は箇条書きで具体化する: 「開発業務全般」ではなく「決済機能のバックエンドAPI設計・実装」のように粒度を下げる

3. 必須要件は3つ以内に絞る: 要件を盛りすぎると応募の心理的ハードルが上がる。歓迎要件と明確に分離する

4. 選考フローと日数の目安を明記する: 「カジュアル面談→技術面接→最終面接、最短2週間」のように見通しを示すと応募率が上がる

逆にやりがちなNGは、自社サイトの会社紹介文をそのまま貼り付けるパターンです。検索キーワードを含まない抽象的な文章は、マッチング精度と応募率の両方を下げます。求人票そのものの書き方はエンジニアが応募したくなる求人票（JD）の書き方完全ガイドで網羅的に解説しているので、併せて参照してください。

5. 運用改善の実践｜クリック単価と応募単価を下げるPDCA

Indeedの成果は「最初の求人票の出来」よりも「公開後の改善頻度」で決まります。クリック課金モデルでは、表示→クリック→応募→選考のファネル各段を数値で把握し、ボトルネックを特定して求人票と予算配分を調整するサイクルが必須です。

見るべき指標は4つに絞る

ダッシュボードには多くの数値が並びますが、実務で毎週追うべき指標は次の4つです。

1. 表示回数: 少なければキーワード設計の問題。職種名と本文の検索語を見直す

2. クリック率（CTR）: 表示されてもクリックされないなら、職種名・給与・勤務地の「検索結果での見え方」を改善する

3. 応募率（クリック→応募）: クリック後に離脱されるなら求人票本文の問題。情報不足・条件の不明瞭さ・応募フォームの長さを疑う

4. 応募単価（CPA）: 総費用÷応募数。最終的な費用対効果はこの数値で判断し、職種ごとに目標値を設定する

週次PDCAの回し方

スカウト運用を支援してきた経験から、Indeedでも同じく「週次・小さく・継続的に」が改善の原則だと考えています。具体的には次のサイクルを推奨します。

1. 週1回、4指標を定点観測する: 曜日を固定して記録する。変化の検知が改善の起点になる

2. 仮説を1つに絞って変更する: 職種名の変更、給与レンジの追記など、1回の変更は1要素に限定する。複数同時に変えると効果検証ができない

3. 2週間単位で判定する: 変更の効果は最低2週間のデータで判断する。日次の変動に一喜一憂しない

4. 応募が動かない求人は作り直す: 微修正を3サイクル回しても動かない場合、求人票の構造自体を見直す。職種の切り出し方から再設計した方が早いケースが多い

このPDCA設計の考え方は、スカウト運用のPDCA改善ガイド｜KPI設計と仕組み化で返信率を上げるで解説しているフレームと共通です。

応募対応のスピードが応募単価を左右する

見落とされがちですが、応募後の対応速度も実質的な運用指標です。クリック課金で獲得した応募が、連絡の遅れで選考前に離脱すれば、その分の広告費はまるごと無駄になります。検索エンジン経由の応募者は複数社に同時応募しているのが普通で、先に連絡した企業から選考が進みます。応募から初回連絡まで24時間以内を標準とし、自動返信＋当日中の個別連絡の二段構えを仕組みにしておくと、同じ応募数でも面接設定率が目に見えて変わります。

生成AIを使った求人票改善の効率化

求人票のABテストは効果的ですが、複数パターンの作成には工数がかかります。実務では生成AIに「現行の求人票」「ターゲット人物像」「狙う検索キーワード」を渡してバリエーション案を作らせ、人間が事実確認と最終調整を行う分業が効率的です。職種名の言い換え候補の洗い出しや、検索キーワードの網羅チェックもAIが得意とする領域です。ただし、技術スタックや待遇などの事実情報はAIが誤りを混入させやすいため、公開前の検証は必ず人間が行ってください。

6. 他チャネルとの組み合わせ戦略

Indeedは単独で完結するチャネルではなく、採用ポートフォリオの一部として設計すべきです。応募獲得の「面」をIndeedで広げつつ、即戦力獲得の「点」はスカウトで打ちにいく。この役割分担が、筆者が採用支援の実務で最も成果が出ると感じている構成です。

役割分担の基本パターン

1. Indeed＝量の確保: 社内SE・若手・QA・サポート職など、検索行動が発生する職種の母集団形成を担当する

2. スカウト媒体＝質の確保: テックリードやモダンスタック経験者など、転職潜在層への直接アプローチを担当する。設計方法はエンジニア採用ダイレクトリクルーティング完全ガイド｜媒体比較と運用設計を参照

3. リファラル・自社発信＝中長期の資産: 採用広報やリファラルで、チャネル費用に依存しない接点を積み上げる

予算配分の考え方

採用コンサル営業時代に見た中で、費用対効果を崩す典型は「1つの媒体に予算を全張りする」パターンでした。Indeedの従量課金は止めたい時に止められるのが強みなので、まず小さく試して職種ごとの応募単価を実測し、効果の出た職種に予算を寄せていく運用が合理的です。採用単価全体の相場観はエンジニア採用の費用相場・採用単価｜コスト最適化7つの実践ガイドで整理しています。

併用時に起きがちな失敗と対策

複数チャネルを併用する際の実務上の注意点も挙げておきます。

1. 求人票の使い回しによる劣化: スカウト媒体用の求人票をそのままIndeedに転載すると、検索キーワード設計が抜け落ちる。チャネルごとに「読まれ方」が違う前提で最適化する

2. 応募経路の計測漏れ: どのチャネル経由の応募かをATSで必ず記録する。経路別の応募単価・内定率が取れていないと、予算配分の判断材料がなくなる

3. 対応品質のばらつき: スカウト経由の候補者には丁寧で、Indeed経由の応募者への返信が遅い、という非対称な運用は口コミ評価の毀損につながる。応募経路にかかわらず対応SLAを統一する

7. 導入から成果までの90日ロードマップ

Indeedで成果を出すまでの標準的な進め方を、90日のロードマップとして示します。

1. Day 1-15（設計）: 採用ターゲットの整理とIndeed適性の判断。職種ごとに「検索される職種名」と想定検索キーワードを洗い出し、求人票を作成する

2. Day 16-30（公開・初期観測): 無料掲載または少額のスポンサー予算で公開。表示回数とCTRを観測し、キーワード設計の妥当性を検証する

3. Day 31-60（運用最適化）: 週次PDCAを開始。CTR・応募率のボトルネックを特定し、職種名・給与表示・本文構成を順に改善する。応募対応のスピードもこの期間に仕組み化する（応募から24時間以内の連絡を標準にする）

4. Day 61-90（拡張判断）: 職種別の応募単価を集計し、予算の増減と配信継続を判断する。効果の出た職種は予算を増やし、出ない職種はスカウト等の代替チャネルへ切り替える

90日かけても応募の質が合わない場合は、チャネル選定そのものを見直すサインです。Indeedに固執せず、ターゲット層がいる場所へ撤退・転進する判断も運用の一部です。

FAQ（よくある質問）

Q1. Indeedは無料掲載だけでエンジニア採用できますか？

職種によります。社内SEや地方採用など競合が少ない条件では無料掲載でも応募が入ることがありますが、エンジニア系職種は全般に競争が激しく、無料掲載のみでは表示順位が上がりにくいのが実情です。まず無料で掲載して表示回数を観測し、露出が足りなければスポンサー求人を少額から試す段階的な進め方をおすすめします。

Q2. Indeed PLUSと従来のIndeedはどちらを使うべきですか？

これから新規で始めるなら、Indeed PLUS対応ATS経由での運用を検討する価値があります。1求人で複数の連携求人サイトに配信されるため、同じ予算でリーチが広がるからです。ただし対応ATSの導入が前提になるため、既存の採用管理フローとの整合を先に確認してください。

Q3. クリック単価はどのくらいを見込めばよいですか？

クリック単価は職種・地域・競合状況で変動するオークション型のため、一律の相場を前提にしない方が安全です。一般に競争の激しい職種ほど単価は上がります。実務では「クリック単価」ではなく「応募単価（CPA）」を管理指標にして、職種ごとに実測値で予算を判断することを推奨します。

Q4. ハイクラスエンジニアの採用にIndeedは使えますか？

主軸にはおすすめしません。テックリードやアーキテクトクラスは能動的な求人検索をほぼ行わないため、待ち型のIndeedでは接点を作りにくいからです。この層はスカウト媒体・リファラル・エージェントを軸にし、Indeedは若手・社内SE・サポート職など検索行動がある職種に割り当てる役割分担が現実的です。

Q5. 応募は来るのに採用に至りません。何を見直すべきですか？

「応募の質」と「選考スピード」の2点を疑ってください。質が合わない場合は、求人票の要件記載が曖昧で広く集めすぎている可能性が高く、必須要件と歓迎要件の明確化で改善します。質は合うのに逃している場合は選考リードタイムの問題が典型で、応募から初回連絡まで24時間以内、書類選考は2営業日以内を目安に短縮します。

Q6. 求人検索エンジンは複数併用すべきですか？

余力があれば求人ボックスやスタンバイとの併用は選択肢ですが、優先度は「1つを運用しきる」ことです。検索エンジン型チャネルは運用の手間が成果を左右するため、リソースが限られる場合は最大手のIndeedに集中し、PDCAを回しきってから横展開する方が結果的に効率的です。

まとめ：Indeedは「設計と運用」で差がつくチャネル

Indeedでのエンジニア採用は、検索エンジンという仕組みの理解、向き不向きの見極め、キーワードを意識した求人票設計、週次の運用改善という4つの要素で成果が決まります。掲載するだけで応募が来る媒体ではない一方、ターゲットと運用が噛み合えば、従量課金で費用を制御しながら安定的に母集団を作れるチャネルです。

• Indeedは検索エンジン。候補者の検索語に合わせた求人票設計が出発点

• 効く職種（社内SE・若手・サポート・地方）と効かない職種（ハイクラス・モダンスタック経験者）を見極める

• 表示回数・CTR・応募率・応募単価の4指標で週次PDCAを回す

• スカウト媒体と役割分担し、採用ポートフォリオ全体で設計する

techcellarでは、エンジニア×AIの視点でスカウト運用代行・採用チャネル設計の支援を行っています。「Indeedとスカウトのどちらに投資すべきか」「運用リソースが足りない」といった課題をお持ちの方は、サービス詳細をご覧ください。自社の採用ターゲットに合ったチャネル設計から、一緒に整理するところから始められます。