エンジニアの職務経歴書で差をつける書き方とAI経験の例

エンジニアの職務経歴書で他の応募者と差がつくのは、使える技術の数ではありません。応募先の求人が挙げる条件に自分の経験を対応させ、その経験で何を変えたかを数字と役割で示せているかどうかです。

必須条件に並ぶ実務経験や経験年数は、書類選考の前提になります。差が出るのは、歓迎条件に該当する経験をどこまで具体的に書けるかと、成果の書き方です。

ここ2年で書き足す意味が大きくなったのが、生成AIやAIコーディングツールを開発でどう使っているかです。ツールの名前だけでなく、任せた作業・人が確かめた点・結果まで書くと、同じツールを使う他の応募者との違いが伝わります。

差別化できる職務経歴書は応募先の求人の条件から逆算して書く

差別化できる職務経歴書は、経歴を時系列に並べただけのものではなく、応募先の求人票の必須条件・歓迎条件を先に読み、それぞれに該当する経験を職務要約とプロジェクト欄の上のほうへ並べ替えたものです。採用担当者は書類で、求人の条件を満たすかと、入社後に同じような成果を出せそうかを確かめるので、条件と同じ言葉で経験を書くと読み手が対応を探す手間がなくなります。

Offers に掲載された正社員のエンジニア求人では、必須条件に実務経験（開発・運用・構築・設計の経験）を挙げる求人が73.9%、「◯年以上」の経験年数を挙げる求人が53.6%でした。テックリード・リーダー・マネジメントの経験は、32.1%の求人が必須条件か歓迎条件のどちらかに挙げています（Offers（株式会社overflow）調べ・必須条件を記載した正社員エンジニア求人 n=1,700・2022年3月〜2026年9月公開）。

必須条件は書類選考の前提なので差は歓迎条件と成果で出る

必須条件の実務経験や経験年数は、書類選考の前提になる条件です。差が出るのは、歓迎条件に挙がった経験をどれだけ具体的に示せるかと、同じ経験でも何を変えたかを数字で書けているかの2つになります。

歓迎条件の項目は求人ごとに違います。基本の職務経歴書を1つ作っておき、応募する求人ごとに職務要約の2〜3行目と、プロジェクト欄の並び順・強調する経験を入れ替えれば、全文を書き直す必要はありません。

転職理由は職務要約と自己PRの筋をそろえる

転職理由は職務経歴書に長く書く項目ではありませんが、職務要約と自己PRの筋がそろっていると、書類全体の説得力が増します。たとえば「設計から関わりたい」が転職理由なら、職務要約で設計に関わった経験を先に書き、自己PRを次の職場で設計の比重を上げたいという一文で結ぶ形です。

給与や働き方への不満が転職のきっかけでも、職務経歴書には「次の職場で何をしたいか」の形で書きます。待遇の希望は、面接や条件の確認の場で伝えれば足ります。

生成AI・AIツール経験を挙げる求人は2026年に25.2%

Offers に掲載された正社員のエンジニア求人で、必須条件か歓迎条件の欄に生成AI・AIツールを使った経験を挙げる求人は、2024年公開の2.4%から、2025年は9.4%、2026年（1〜10月公開）は25.2%になりました。Claude Code・GitHub Copilot・Cursor などのAIツールを開発や業務に使った経験を挙げる求人は、2026年公開の求人の15.3%でした。

出所：Offers（株式会社overflow）調べ・必須条件か歓迎条件を記載した正社員エンジニア求人 n=1,308・2024年1月〜2026年10月公開。

求人が挙げるAIの経験は、大きく2つに分かれます。1つは Claude Code や GitHub Copilot などのAIツールを開発や業務に使った経験で、たとえば「Claude CodeなどのAIエージェントを日常の開発に使っていること」を必須条件に、「AIエージェントを開発プロセスに組み込み、任せる範囲を広げた経験」を歓迎条件に書く求人があります。

もう1つは、生成AI・LLM（大規模言語モデル）を組み込んだ機能やプロダクトを作った経験です。職務経歴書でもこの2つを分けて書くと、求人の条件との対応が読み手に伝わります。

AIツールを開発に使った経験は任せた作業と人が確かめた点まで書く

AIツールの経験は、ツールの名前を並べるだけでは他の応募者と差がつきません。どの作業をAIに任せ、どこを自分で確かめ、結果として何が変わったかまで書くと、使い方の習熟が伝わります。

スキル欄の下に「AIツールの活用」の項目を立てる場合の記入例です。

【AIツールの活用】
・Claude Code（2025年4月〜）：既存機能のテストコードの作成と、JavaScript から TypeScript への型の移行（約120ファイル）に使用。生成したコードはすべてレビューとテストを済ませてからマージ。AIに渡す作業手順書をチームで整備し、新しく入ったメンバーにも同じ手順で使ってもらっている
・GitHub Copilot（2024年〜）：日常のコーディングの補完に使用
・運用のルール：顧客情報を含むデータや秘密鍵はAIツールに渡さない取り決めを、セキュリティ担当と決めて運用

書くときに押さえる点は次の4つです。

• 使い始めた時期と、使う場面（日常的に使うのか、特定の作業で使うのか）
• テストの作成・リファクタリング・調査・コードレビューの補助など、任せた作業の種類
• 人が確かめた点（レビュー・テスト・秘密情報の扱い）
• チームへの広げ方（手順書やルールの整備、勉強会）

「生産性が上がった」と書くより、移行したファイル数やテストを書き足したモジュールの範囲のように、作業の結果を事実の粒度で書くほうが読み手は評価しやすくなります。仕様の固まっていない機能の設計は自分で書いたほうが早かった、といった向かなかった用途を1行添えると、ツールの限界を分かったうえで使っていることも伝わります。

GitHub Copilot のモデル選択の欄で選べる Copilot Fusion の仕組みと、ツールとモデルの使い分けを転職で説明するときの観点をまとめたのが「Copilot Fusionとは：仕組みと料金・求人動向」です。

生成AIを組み込んだ開発経験は構成と評価の方法まで書く

生成AI・LLM を組み込んだ機能を作った経験で書くのは、使ったモデルや API（Application Programming Interface）の名前に加えて、構成（文書検索と組み合わせる RAG・ツール呼び出し・エージェントなど）、出力の品質をどう確かめたか、本番で運用したかどうかです。求人の条件には「LLMアプリケーションの評価・改善の経験」のように、出力の評価と改善まで担った経験を挙げるものもあります。

■社内問い合わせに答えるAIチャット機能の開発（2025年6月〜12月）
役割：バックエンド担当（チーム4名）
構成：社内文書の検索（RAG）と LLM の API を組み合わせ、回答の根拠になった文書を画面に表示
評価：想定質問200件の正解を人が判定する評価用のデータを作り、リリース前とプロンプトの変更のたびに確認
運用：本番公開後、回答できなかった質問を毎月集めて文書の追加と改善の優先順位づけに使用

生成AIの経験を条件に挙げる求人かどうかを確かめる場所は、求人詳細の必須スキル・歓迎スキルの欄です。Offers Jobs のエンジニア求人一覧では、求人詳細の業務内容・必須スキル/経験・歓迎スキル/経験を会員登録なしで読めるので、応募したい求人の条件を職務経歴書の並び順に反映させてから応募できます。

職務要約・スキル・経歴・自己PRの4つで組み立てる

エンジニアの職務経歴書は、職務要約・スキル（技術スタック）・プロジェクトごとの職務経歴・自己PRの4つで組み立てます。職務要約で経歴の軸と求人に合う経験を示し、スキル欄とプロジェクト欄で裏づけ、自己PRで次の職場で何をしたいかを結ぶ順番です。

職務経歴書の基本のフォーマットは「エンジニアの履歴書・職務経歴書｜52人調査と書き方」に、レジュメと呼ばれる書類の範囲や履歴書との違いは「レジュメとは｜転職での意味とエンジニアの書き方」にまとめています。

職務要約は経歴の軸と求人に合う経験を3〜5行で書く

職務要約は、採用担当者が最初に読む3〜5行です。経験年数・領域・担当してきた工程と、応募先の求人の条件に該当する経験を、条件に合う順に書きます。

Webサービスのバックエンド開発に7年間携わり、うち3年はテックリードとして5名のチームの設計レビューと技術選定を担当しました。Go と Python による API 開発、AWS（Amazon Web Services）上のインフラ構築、既存システムの段階的な移行を得意としています。直近2年は、生成AIを組み込んだ社内向け機能の開発と、AIコーディングツールを使った開発手順のチームへの展開に取り組みました。

スキル欄は技術ごとに経験年数と使い方を添える

スキル欄は、技術を分類ごとに表にし、それぞれに経験年数と使い方を添えます。読み手が求人の経験年数の条件と照らし合わせるときの手がかりになるのは、「上級」「中級」のような自己評価より、何年・どの規模で使ったかです。

プロジェクト欄は期間・規模・役割・課題・成果の順に書く

プロジェクト欄は、1件ごとに期間・規模・役割・使った技術・課題・対応・成果の順に書きます。課題と対応を書くと、成果が偶然ではなく自分の判断から出たものだと伝わります。

■ECサイトの基盤の刷新（2023年4月〜2024年3月）
規模：月間1,000万PV（ページビュー）／チーム10名（バックエンド5名・フロントエンド3名・インフラ2名）
役割：バックエンドのリードエンジニア
技術：Go、gRPC、Docker、Kubernetes、AWS
課題：1つのアプリケーションを複数のサービスへ分ける際、注文と在庫のデータの整合性を保つ必要があった
対応：サービスをまたぐ処理を Saga パターンで設計し、失敗したときの取り消しの処理を実装
成果：平均応答時間を約半分に短縮し、リリースを週1回から毎日に変更

成果は数字で示し、自分の担当とチームの成果を分けて書く

成果を示すのは、期間・人数・改善の幅などの数字です。チーム全体の成果を書くときは、その中で自分が担当した範囲を同じ行に書き分けると、読み手が貢献の大きさを読み違えません。

社外に出せない売上や顧客名は伏せ、「約」「前年比」などの形に置き換えます。概算の数字には「約」を付け、測っていない数字は書きません。

面接では職務経歴書に書いた成果の過程と判断の理由を聞かれる

書類選考を通った後の面接では、職務経歴書に書いた成果について、なぜその技術を選んだか、どこで詰まりどう解決したか、自分はどこを担当したかを聞かれます。プロジェクトごとに判断の理由と、うまくいかなかったことを1つずつ話せるよう準備しておくと、書類の内容と面接の受け答えがそろいます。

AIツールの経験を職務経歴書に書いたなら、面接で使い方を具体的に確かめられる前提で準備しておくのが確実です。どの作業で使い、どこを人が確かめるかを、職務経歴書の記載と同じ言葉で説明できるようにしておくと、書類と面接の話がずれません。

選考全体の進め方は「エンジニアが転職を成功させる方法と6つのステップ」で順を追って扱っています。

GitHub・技術ブログ・ポートフォリオは補足として載せる

GitHub のリポジトリ、技術ブログ、登壇資料、ポートフォリオは職務経歴書の内容を裏づける補足で、URL は末尾かスキル欄の下に載せる形です。業務のコードは公開できないことが多いので、職務経歴書の本文は業務での経験と成果で組み立て、公開できる成果物は読めば分かることが1つ増えるものだけを選びます。

載せる前に確かめるのは、次の4点です。

• README（リポジトリの説明文書）に目的・使った技術・自分の担当・動かし方が書いてあるか
• 職務経歴書に書いた技術と、リポジトリで使っている技術が対応しているか
• 業務の情報（社名・顧客名・社内のコード）が含まれていないか
• 試しに作っただけの古いリポジトリが、プロフィールの上位に固定されていないか

ポートフォリオの中身と作り方は「エンジニアのポートフォリオ一覧｜職種別の中身と作り方」に、経験者が成果物を出すべきかどうかは「エンジニアの転職に成果物は必要か｜経験者の実績の示し方」にまとめています。

職務経歴書のファイルは Word か Google ドキュメントで作り、提出するときは PDF（Portable Document Format）に書き出すと、相手の環境でもレイアウトが崩れません。

提出前に求人ごとに職務経歴書を見直す

職務経歴書は1つを使い回すより、応募する求人ごとに提出前の見直しを入れるほうが、条件との対応が伝わります。見直すのは、求人の条件との対応・成果の数字・機密の扱い・表記・ファイルの形式の5つです。

書き終えたら、同じ職種の知人や元同僚に読んでもらい、「どんな条件の求人に合う人か」を一言で言ってもらいます。返ってきた一言が狙った求人の条件と違えば、職務要約の並び順を見直す合図です。

応募先の技術ブログ・登壇資料・プレスリリースは、使っている技術と取り組んでいる課題を確かめ、職務要約と自己PRを求人に合わせるための材料です。

企業から声がかかる形で転職活動を始めたいときは、Offers に経歴を登録しておくと、企業から直接スカウトのメッセージが届きます。

エンジニアの職務経歴書で差をつける要点

エンジニアの職務経歴書は、応募先の求人の必須条件・歓迎条件から逆算し、条件に該当する経験を職務要約とプロジェクト欄の上のほうへ並べると、他の応募者との差が伝わります。

• 必須条件の実務経験・経験年数は書類選考の前提なので、差は歓迎条件に該当する経験と成果の書き方で出る
• 必須・歓迎条件に生成AI・AIツールの経験を挙げるエンジニア求人は、2026年（1〜10月公開）に25.2%
• AIツールの経験は、任せた作業・人が確かめた点・結果まで書く。生成AIを組み込んだ経験は、構成と評価の方法と運用の有無まで書く
• 成果は数字で示し、自分の担当とチームの成果を分ける
• GitHub・技術ブログ・ポートフォリオは補足として URL を載せ、提出前に求人ごとに見直す