AIエンジニアの職務経歴書の書き方｜書類通過率を上げる実例テンプレート
AIエンジニアの転職市場において、書類選考の通過率は職務経歴書の構成と記述の質によって大きく左右される。技術力があるにもかかわらず書類で落ちるケースの多くは、「何ができるか」ではなく「何を成し遂げたか」が伝わっていないことに起因する。本稿では、採用担当者・技術責任者の双方に評価されるAIエンジニアの職務経歴書の構成原則と、実務に即した記述の型を解説する。
AIエンジニアの職務経歴書が難しい理由
AIエンジニアの職務経歴書には、他の職種にはない固有の難しさがある。
第一に、成果の可視化が困難である。モデル精度の改善や推論速度の短縮といった技術的成果は、ビジネスインパクトに換算しなければ採用担当者には伝わりにくい。「Accuracyを0.83から0.91に改善」という記述は技術者には刺さるが、ビジネスサイドの意思決定者には文脈が伝わらない。
第二に、技術スタックの陳腐化が速い。AIの主要フレームワークは数年単位で様変わりするため、「何年前に何を使ったか」という書き方では評価が難しい。採用企業が知りたいのは、現在の実践的な習熟度である。
第三に、役割の曖昧さが書類に出やすい。MLエンジニア・データサイエンティスト・リサーチエンジニア・MLOpsエンジニアは業務領域が重複しやすく、自分の役割を正確に言語化できていない候補者は多い。
これらの課題を踏まえた上で、構成と記述の方針を設計する必要がある。
職務経歴書の全体構成
AIエンジニアの職務経歴書は、以下の構成を基本とすることが多い。
| セクション | 記載内容 | 目安文量 |
|---|---|---|
| スキルサマリー | 現時点での専門領域・強みの要約 | 3〜5行 |
| 技術スキル一覧 | 言語・フレームワーク・クラウド・ツール | 箇条書き |
| 職務経歴（時系列） | 各社での業務内容・役割・成果 | 各社200〜400字 |
| プロジェクト詳細 | 代表的な1〜3件のプロジェクト深掘り | 各300〜500字 |
| 資格・学歴・論文等 | 関連する公的資格・学術成果 | 箇条書き |
多くの候補者が「職務経歴（時系列）」のみを丁寧に書き、「プロジェクト詳細」を省略する。しかし技術職の採用では、プロジェクト詳細こそが技術力と問題解決能力の判断材料になる。この2層構造を意識することが通過率を左右しやすい。
スキルサマリーの書き方
冒頭のスキルサマリーは、採用担当者が最初に目を通す箇所であり、「この候補者を面接に呼ぶべきか」の判断に直結する。
避けるべき書き方の例：
機械学習・深層学習の経験があり、PythonやTensorFlowを用いた開発に携わってきました。
この記述は抽象的すぎて差別化にならない。
改善した書き方の例：
自然言語処理領域を専門とし、RAGアーキテクチャを用いた社内ナレッジ検索システムの設計・本番運用（月間10万リクエスト規模）に主担当として携わる。LLMの評価基準設計と継続的改善のサイクル構築を得意とし、MLOpsの整備経験（CI/CDパイプライン、モデルモニタリング）も持つ。
後者は専門領域・規模感・役割・周辺スキルが一段落に収まっており、技術責任者がスクリーニングする際の手がかりが多い。
技術スキル一覧の整理方法
技術スキルは「知っている」と「業務で使えるレベル」を分けて記載することが重要である。採用企業が最も嫌うのは、スキル欄に記載した技術が面接で深掘りされたときに答えられない状況である。
以下のような区分を設けることで、正直さと説得力を両立できる。
【言語】
Python（業務主軸・5年）、SQL（業務使用・4年）、Bash（補助的使用）
【MLフレームワーク】
PyTorch（主力・本番経験あり）、Hugging Face Transformers（主力）、scikit-learn（業務使用）
【MLOps・インフラ】
MLflow（実験管理）、Vertex AI（本番パイプライン構築）、Docker／Kubernetes（運用補助レベル）
【クラウド】
GCP（主軸）、AWS（基礎レベル）
括弧内の補足は採用担当者への配慮であると同時に、自分自身の習熟度を誠実に示す手段でもある。
プロジェクト詳細の記述テンプレート
ここが最も差がつくセクションである。以下の型に沿って記述することで、技術的な深さとビジネスへの貢献度を同時に伝えられる。
【プロジェクト名】 社内問い合わせ対応のLLMベース自動化システム開発
【在籍期間・役割】 20XX年X月〜20XX年X月 ／ MLエンジニア（4名チーム、自分がモデル設計・API設計を主担当）
【背景・課題】 カスタマーサポート部門への社内問い合わせが月間5,000件を超え、担当者の対応工数が慢性的に不足していた。既存のFAQシステムはルールベースで精度が低く、問い合わせの約60%が担当者への転送で終わっていた。
【取り組みと技術的判断】 RAGアーキテクチャを採用し、社内ドキュメントをベクトルDB（Qdrant）に格納した検索基盤を構築。LLMはAPI利用（GPT-4系）とし、プロンプト設計・チャンク戦略の最適化に注力した。回答精度の評価はG-Evalフレームワークを参考に独自の評価パイプラインを設計し、精度改善のPDCAを回せる体制を整えた。
【成果】 自動解決率：37%→64%（3ヶ月後計測）。担当者の対応件数が月間約1,500件削減され、コスト換算で年間XXX万円相当の工数削減に貢献。モニタリング基盤も整備し、本番稼働後も精度の継続的計測が可能な状態で引き渡した。
【技術スタック】 Python、LangChain、Qdrant、FastAPI、Vertex AI、Docker
この型のポイントは3つある。第一に「背景・課題」で問題の文脈を示すこと。第二に「取り組みと技術的判断」で複数の選択肢の中からその技術を選んだ理由を匂わせること。第三に「成果」でビジネス指標と技術指標を両方示すことである。
転職先の業種・規模別に強調点を変える
AIエンジニアが応募するポジションは一様ではない。スタートアップのMLエンジニアと大手事業会社のAI部門では、採用担当者が重視する点が異なる。
| 応募先の類型 | 強調すべき経験・能力 |
|---|---|
| スタートアップ・AI特化企業 | 少人数での設計〜運用の一気通貫、スピードと試行錯誤の姿勢 |
| 大手事業会社のDX・AI部門 | 社内調整・ステークホルダー連携、PoC→本番化の経験 |
| SIer・コンサルファーム | 要件定義・提案経験、複数業種への横展開 |
| 研究開発寄りの部門 | 論文実装経験、アーキテクチャへの深い理解 |
同じ職歴でも、どの経験を前面に出すかによって書類の印象は変わる。応募先ごとにプロジェクト詳細の選択と順序を変えることは、特別な虚偽記載でも誇張でもなく、伝え方の最適化である。
よくある質問
Q. GitHubやKaggleの実績は職務経歴書に記載すべきですか？
記載することを推奨する。ただし、単に「Kaggle Expert」と書くだけでは弱い。取り組んだコンペの難易度・解法のアプローチ・結果の順位帯を簡潔に補足すると技術力の裏付けになる。GitHubについては、採用企業が実際にコードを確認する場合があるため、掲載するリポジトリは整備されていることが前提となる。
Q. 研究職（アカデミア）からの転職の場合、論文はどう記載すれば良いですか？
査読付き国際会議・ジャーナルであれば記載する価値がある。ただし論文名の羅列だけでなく、「どのような問題に取り組み、産業応用上どのような意義があるか」を1〜2行で補足することで、ビジネス文脈での評価につながりやすくなる。
Q. 経験年数が浅い（2〜3年）場合、どう差別化すればよいですか？
経験の幅よりも深さで勝負することが有効な場合が多い。1〜2つのプロジェクトに絞り、自分が担当した設計上の意思決定・直面した技術的課題とその解決プロセスを詳細に書くことで、経験年数以上の実力を伝えられるケースがある。PoC止まりではなく本番運用まで関わった経験があれば、必ず前面に出したい。
Q. 年収交渉に職務経歴書は影響しますか？
直接的には書類よりも面接での交渉が主な舞台となるが、職務経歴書の記述の精度は面接前の期待年収設定に影響する傾向がある。採用担当者が「このレベルの人材なら〇〇万円帯」と判断する根拠は書類の記述にある。成果の定量化とプロジェクト規模の記述は年収の下限ラインを引き上げる効果が期待できる。
まとめ
AIエンジニアの職務経歴書で書類通過率を高めるには、技術スタックの列挙から脱し、「技術的判断の文脈」と「ビジネス成果への貢献」を明示する構成が不可欠である。スキルサマリーで専門領域と強みを絞り込み、プロジェクト詳細で背景・判断・成果の三層構造を記述することが、採用担当者・技術責任者の双方に刺さる書類の条件となる。応募先の類型によって強調点を変える柔軟性も、通過率に影響する要因の一つだ。職務経歴書は自己評価の場ではなく、採用企業の課題を自分が解決できるという仮説を示す場であると捉え直すことが、質の高い書類につながる。自分の市場価値や強みの言語化に迷いがある場合は、AIエンジニアの採用動向に精通したキャリアアドバイザーへの相談も有効な選択肢となる。