求人票の「AIエンジニア」が何を指すかは、会社によって10倍以上ズレている。
この記事の使い方
決めること: 求人票に書かれた肩書きを、実際の仕事内容に変換する読み方を身につける。
決めないこと: どの肩書きが「正しい」か、どのポジションが「格上」かのランキング。
前提: 日本国内の求人票を対象にする。英語圏の職種定義とは意図的に切り離して読む。
結論を先に
求人票の肩書きと、実際に手を動かす仕事の対応を整理すると次のようになる。
| 求人票の肩書き | 実際に多い仕事 | 見分けるキーワード | 地雷になりやすい条件 |
|---|---|---|---|
| AIエンジニア | モデル選定・API連携・PoC実装 | 「LLM活用」「生成AI」 | 要件が「検討中」のまま |
| 機械学習エンジニア | 学習パイプライン構築・特徴量設計 | 「MLOps」「学習基盤」 | データが社内に存在しない |
| データサイエンティスト | 分析・可視化・レポーティング | 「BI」「ダッシュボード」 | モデル開発が実は不要 |
| リサーチエンジニア | 論文実装・アルゴリズム改善 | 「SOTA」「実験管理」 | 事業化の見通しがない |
| AIプロダクトエンジニア | プロダクト組み込み・評価設計 | 「A/Bテスト」「推論最適化」 | MLとSWEの境界が曖昧 |
| MLOpsエンジニア | 基盤整備・CI/CD・モニタリング | 「Kubeflow」「Vertex AI」 | 運用対象のモデルがない |
まず用語の地図
肩書きの議論に入る前に、よく混同される言葉を整理する。
| 用語 | かみ砕いた意味 | 混同されやすい言葉 |
|---|---|---|
| PoC（概念実証） | 「動くか確かめる試作」。本番とは別物 | プロトタイプ、MVP |
| MLOps | モデルを本番で動かし続けるための仕組みづくり。DevOpsのML版 | データエンジニアリング |
| ファインチューニング | 既存モデルを自社データで追加学習させること | プロンプトエンジニアリング |
| 推論最適化 | 学習済みモデルを速く・安く動かすチューニング | モデル圧縮、量子化 |
| 特徴量（フィーチャー） | モデルに食わせる入力データを加工した変数。設計が精度を左右する | 生データ、ラベル |
| SOTA（ソータ） | State of the Art。現時点で最高精度の手法・モデル | ベースライン |
| A/Bテスト | 2つの施策を同時に試して効果を比較する実験設計 | ユーザーテスト |
肩書きインフレが起きる構造
なぜ「AIエンジニア」は万能ラベルになったか
2023年以降、生成AIブームに乗って採用競争が激化した結果、求人票の肩書きは実態より先行して膨らんだ。背景には三つの力学がある。
採用側の事情: 「AI人材を採っている」という社内外へのシグナルとして、肩書きをアップグレードするインセンティブがある。実際の仕事がAPI呼び出しの実装であっても、「AIエンジニア」と書けば応募数が増える。
候補者側の事情: 「AIエンジニア」という肩書きを経歴に載せたい動機がある。結果として、実態より広い定義で肩書きを使う合意が市場に形成される。
技術の変化速度: LLMの登場でAPIを叩くだけでAIらしい機能が作れるようになった。従来の機械学習エンジニアとは必要スキルが大きく異なるが、肩書きは統合されたまま使われている。
この三つが重なると、同じ「AIエンジニア」という肩書きの下に、論文を実装する研究者と、ChatGPTのAPIをラップするだけの実装者が並ぶ。
求人票を解剖する読み方
仕事の実態を炙り出す四つの問い
求人票を読むとき、肩書きではなく次の四点を探す。
① 何を作るか（アウトプットの形）
「モデルを開発する」と「AIを活用したプロダクトを作る」は別の仕事だ。前者は学習・評価・改善のループが中心で、後者はAPI連携・プロンプト設計・UX実装が中心になる。
② データはどこにあるか
「データ収集から」という記述は、モデル開発の前段階が未整備であることを示す。データが存在しない状態でのモデル開発は、仕事の大半がデータエンジニアリングになる。
③ 本番稼働しているものがあるか
「新規立ち上げ」と「既存サービスの改善」では求められるスキルが異なる。前者はゼロから設計する力、後者は既存コードと制約の中で動かす力が必要になる。
④ 評価指標が定義されているか
「精度向上」「コスト削減」など具体的な数字が書かれているか。「AI活用を推進する」のような動詞止まりの記述は、何を達成すれば成功かが決まっていない可能性が高い。
求人票の文言と実態の対応チェックリスト
以下の項目を求人票から読み取り、実態を推定する。
□ 「LLMを活用」→ 独自学習かAPI利用かを確認。後者ならMLスキルより
プロンプト設計とシステム設計が主戦場
□ 「機械学習モデルの開発」→ 学習インフラが社内にあるか確認。
なければ環境構築から始まる
□ 「データ分析」→ 意思決定に使われる分析か、モデル開発のための
EDA（探索的分析）かで仕事が変わる
□ 「AI戦略の立案」→ 実装を伴うかを確認。伴わなければPMに近い役割
□ 「研究開発」→ 論文サーベイと実装が主か、事業化が主かを確認
□ 「MLOps基盤構築」→ 対象となるモデルが既に本番にあるかを確認。
なければ基盤を作っても使われない
面接で確かめる検証ゲート
入社前に必ず聞く五つの質問
求人票の読み解きだけでは限界がある。面接で直接確認すべき点を絞る。
| 質問 | 何を確かめるか | 危険な回答のパターン |
|---|---|---|
| 「今動いている本番モデルを教えてください」 | 実装フェーズかPoC止まりかの確認 | 「これから作ります」「検討中です」 |
| 「学習データのサイズと管理方法は？」 | データ基盤の成熟度の確認 | 「まだ整備中です」「スプレッドシートで管理」 |
| 「モデルの評価指標と現在の数値は？」 | 成功基準が定義されているかの確認 | 「定性的に判断しています」 |
| 「直近6ヶ月でリリースしたAI機能は？」 | 開発サイクルの実態確認 | 「PoC段階のものが複数あります」 |
| 「このポジションの前任者は何をしていましたか？」 | ポジションの安定性と期待値の確認 | 「新設ポジションです」（理由なし） |
「新設ポジション」自体は問題ではない。ただし、なぜ新設するのか、何を達成すれば成功かが答えられない場合は、役割定義が未完成のまま採用しようとしているサインだ。
具体例：肩書きインフレでの検証ゲート
切り口は「求人票の読み方」。抽象論で終わらせず、次の三行をチケットに残す。
- 通ったら終わり — 観測可能な完了条件（数値・ログ・画面のどれか）。
- 壊れたらこう見える — 失敗1件と、人間が止める地点。
- 誰が責任を持つか — 客先／本社／ベンダーの分界を一文で。
この三行がない縦スライスは、速さ優先でも信頼優先でもない——ただの未定義作業だ。週次では、ベンダー比較表より先にこの三行を埋める。レビューでは「どのモデルか」より「どのゲートで止めたか」を先に聞く。止める地点が共有されていないチームほど、同じ失敗を別の肩書きで繰り返す。
持ち帰るチェック
- 受け入れ条件は数値か、画面の状態か、ログの一文か——どれか一つに固定する。
- 失敗モードは「起きてほしくないこと」ではなく「起きたときに見えること」で書く。
- 権限を広げた理由がログに残っていない変更は、本番相当に入れない。
- デモ環境と本番相当でデータが違うなら、完了定義も別物として書く。
- 同じ論点が再燃したら、ツール比較より用語表とゲート一覧を先に開く。
よくある偏り
「AIエンジニア」を選ぶ人が陥りやすい三つの罠
肩書きの格で仕事を選ぶ
「機械学習エンジニア」より「AIエンジニア」のほうが新しく聞こえるという理由で選ぶと、実態がAPI連携の実装だったときに「思っていた仕事と違う」になる。肩書きの新しさと仕事の深さは比例しない。
PoCの多さを成長環境と誤読する
「様々なAI技術を試せる環境」という表現は、裏返すと「本番稼働まで至ったものが少ない」可能性がある。PoCを量産する組織では、実装・運用・改善のサイクルを経験しにくい。
「AI」の前置きで技術スタックを確認しない
「AIエンジニア」という肩書きに引っ張られて、実際に使う言語・フレームワーク・インフラを確認しないまま入社するケースがある。PythonとPyTorchを想定していたら、実態はJavaScriptとOpenAI APIだったということは起きる。
いまの一手
本気の人
手元にある求人票を一枚選び、上記の「四つの問い」と「チェックリスト」を実際に当てはめてみる。答えが求人票から読み取れない項目が三つ以上あれば、面接で必ず確認する質問リストに加える。肩書きではなく、「何を作り、どう評価されるか」だけを軸に比較すると、候補の絞り込みが速くなる。
まだ様子見の人
いまの職場の求人票（自分のポジションの募集要項）を探して、同じチェックリストを当てはめてみる。自分が実際にやっている仕事と、求人票の記述がどれだけズレているかを確認することで、市場での自分の見え方と実態の差が把握できる。転職を考える前に、自分の仕事を言語化する練習として使える。
関連シリーズ: AI領域のスタートアップで働く場合、肩書きインフレはさらに激しくなる傾向がある。資金調達フェーズと実際の開発体制の読み方は AI Ventures シリーズ で扱っている。
このシリーズの他の記事は AI Careers シリーズ一覧 から読める。
Alex Ishiguro
編集長
MakuakeやCAMPFIREで話題になった商品の「その後」を追うメディアを運営。約束されたものが実際に届いたのか、消えてしまったのかを記録する。
この記事に追加情報や訂正がある場合は、お問い合わせよりご連絡ください。