AI求人の53％は職種名とスキルが不一致、肩書だけでは探せない

Andelaは2026年9月10日、Fortune 500企業のソフトウェア関連求人を分析した職種分類研究を正式発表した。前日の9月9日に公開された Andelaの原研究 は、4万7101件の求人から2026種類のスキルを評価し、既存職種の境界をまたぐ組み合わせを調べている。

焦点となる53％は、分析対象の全求人に占める割合ではない。9月10日付の Andelaの発表資料 によると、主に「AI Engineer」や「ML Engineer」と名付けられた約1832件のうち、53％が少なくとも二つの既存職種からスキルを取り込んでいた。つまり、肩書は同じでも、求人票が示す実際の仕事は一様ではない。

53％は「記載ミス」ではなく職種境界のずれ

この調査でいう不一致は、職種名と仕事内容が無関係だという意味ではない。ある求人の名称が一つの既存職種を示す一方、要求欄では別々の職種に属してきたスキルが反復して組み合わされている状態を指す。

対象となった1832件では、大規模言語モデル、会話型AI、OpenAI API、Vertex AI、評価用の仕組みなどが、職種をまたぐ代表的なスキルだった。発表資料はさらに、LLMオーケストレーション、自律型エージェント、ベクトルデータベースを、既存の肩書では表しきれない能力の例として挙げている。

したがって、53％を「AI求人の半数が誤記されている」と解釈するのは適切ではない。調査が示すのは、AI EngineerやML Engineerという広い名称だけでは、モデル開発、アプリケーション統合、評価、本番運用のどこを担う仕事なのか判別しにくいという問題だ。

求人検索は肩書と能力束を併用する

求職者にとっての直接的な影響は、肩書の完全一致だけで絞り込むと、経験に合う求人が検索結果から漏れうることだ。Software EngineerやData Scientistとして働いていても、LLMを既存サービスへ組み込み、評価や運用まで担当していれば、別の名称で掲載されたAI関連職と実務が重なる可能性がある。

検索語は、希望する肩書に具体的な技術と成果を足して組み立てられる。今回確認されたスキルを使うなら、次のような軸が考えられる。

• 構築対象：LLM application、conversational AI、autonomous agent
• 統合技術：LLM orchestration、API integration、vector database
• 品質評価：evaluation harness、benchmarking、model evaluation
• 本番運用：model deployment、versioning、ML observability、CI/CD for ML

たとえば、基盤モデルを使った業務アプリケーションを開発した人なら、「AI Engineer」に限定せず、「LLM application」「evaluation」「API integration」を組み合わせて検索できる。検索範囲を広げた後は、求人票に書かれた成果、必須要件、担当範囲を実際の経験と照合する必要がある。

23の候補すべてが新職種ではない

調査は、複数の既存職種をまたいで繰り返し現れる23のスキル束を検出した。単独の評価者による監査では、8件が形成中の役割、14件がすでに定着したハイブリッド役割、1件が分類上のアーティファクトと判定された。23件すべてを「新しいAI職種」と呼ぶことはできない。

候補には、モデルの配備、バージョン管理、監視を支えるMLOps Pipeline Engineerや、基盤モデル自体を訓練するのではなく、その上でアプリケーションを構築・評価するLLM Application Engineerが含まれる。独立系媒体の Tech Debriefの報道 も、AI・ML系1832件の53％が複数職種の能力を組み合わせていたという結果を確認している。

ここで見るべきなのは、新しい名称の数より、各スキル束がどの成果に結び付いているかだ。MLOps Pipeline Engineerは機械学習、DevOps、データエンジニアリングを横断するが、調査上の中心は、モデルを反復可能な形で配備し、監視するための基盤にある。

採用側は成果と責任範囲を先に書く

採用側が先に「AI Engineer」という肩書を置き、関連しそうな技術を後から追加すると、異なる役割が一つの求人票へ入り込みやすい。今回の結果を職務記述へ反映するなら、肩書より先に、担当者が実現する成果と責任の境界を定義する必要がある。

職務記述は、次の順序で分解できる。

1. 期待する成果を一文で示す。たとえば「既存の基盤モデルを使った顧客対応機能を構築し、本番環境で評価・監視する」と書く。
2. 中核能力を絞る。LLMオーケストレーション、評価、モデル提供基盤など、採用判断に使う能力を優先する。
3. 隣接能力を必須要件と歓迎要件に分ける。クラウド運用、データ基盤、製品設計を一律に必須扱いしない。
4. 責任の境界を明記する。モデル訓練、アプリケーション実装、インフラ運用、セキュリティ審査のうち、本人と他チームが所有する範囲を分ける。
5. 最後に、内容を代表し、候補者が検索できる職種名を選ぶ。

この構造なら、候補者は単なる技術一覧ではなく、入社後に責任を負う成果を判断できる。採用担当者も、選考時に確認する中核能力と、入社後に習得できる周辺能力を区別しやすくなる。

調査は市場全体の推移を示していない

適用範囲には明確な限界がある。求人データは2026年3月30日から5月2日までの約5週間に、Fortune 500企業の公開求人から収集された単一時点のスナップショットで、ソフトウェア開発ライフサイクルに関係する職種へ絞られている。53％を日本の求人市場や米国の全職種へそのまま当てはめることはできない。

分析はAndela独自の職種・スキル体系を基準に、スキルの共起、既存職種からの距離、技術の新しさを組み合わせて候補を抽出した。原研究は、スキル抽出に誤検出が残ること、技術の誕生年には判断が入ること、求人件数の増減を追った時系列研究ではないことを明記している。

現時点で確認できるのは、Fortune 500の一部のAI・ML系求人で、既存の肩書より広い能力束が要求されていることだ。同じ組み合わせが今後増えるのか、企業がより具体的な職種名へ移行するのかは、継続的なデータがなければ判断できない。53％は市場全体の固定値ではなく、肩書だけでは仕事の中身を特定しにくい状況を示す限定的な観測値である。