機械学習エンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

機械学習エンジニアのスキルシートは、プロジェクトごとに「データ準備・学習・評価・推論の提供・監視」のどこを担ったかを書き分け、精度は数字そのものより「何と比べて、どう判断したか」で書くのが基本です。読み手は、モデルを作れる人なのか、モデルを本番で動かし続けられる人なのかを、シートから見分けたいと考えています。使ったアルゴリズムの名前を並べるだけでは、その区別がつきません。

全体の構成はスキルシートの基本、案件で求められるスキルの中身は機械学習エンジニアのスキルの記事で扱っています。この記事では、機械学習ならではの書き方に絞って説明します。

担当した段階を表で示す

機械学習のプロジェクトは、関わる段階が人によって大きく違います。同じ「需要予測のモデル開発」でも、特徴量を考えて学習させた人と、学習済みのモデルを定期実行の仕組みに載せた人では、合う案件が別です。

プロジェクト欄の「担当工程」は、一般的な「設計・開発・テスト」ではなく、機械学習の段階で書くと伝わります。

すべての段階を埋める必要はありません。担っていない段階は書かないか、「レビューに参加」「既存の仕組みを利用」のように関わり方をそのまま書きます。面談では、書いた段階について具体的な判断を聞かれます。

精度の数字は「比べた相手」とセットで書く

機械学習のシートで迷いやすいのが、精度の書き方です。「正解率○%を達成」とだけ書くと、次の問題が出ます。

• データの条件が分からないので、数字の良し悪しを読み手が判断できない
• 事業の数字に近い指標は、守秘義務に触れることがある
• 面談で「その指標を選んだ理由」を聞かれたとき、シートと話の重心がずれる

そこで、数字を出すかどうかにかかわらず、評価の組み立てを書きます。

• 何の指標を使ったか（例：再現率を重視。見逃しのほうが業務上の損失が大きいため）
• 何と比べたか（例：人手のルールで判定していた方法、前の版のモデル）
• どう検証したか（例：時点で区切った検証データ、本番の一部での比較）
• 結果をどう判断したか（例：基準を上回ったため本番へ。下回った案は見送り）

数字を書いてよいと確認できた場合も、「前のモデルより改善」のように相対で書くほうが、案件が変わっても誤解を生みにくくなります。数字を出してよい範囲の考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

見送った検証も実績になる

機械学習の案件では、検証の結果「機械学習を使わない」と判断することもあります。この経験を書かない方が多いのですが、見切りの判断は、検証の進め方を任せられるかどうかの材料になります。「検証の結果、ルールでの判定で十分と判断し、運用の手間を考えて導入を見送る提案をした」のように、判断の理由まで1行で書きましょう。

スキル一覧は「モデル」と「仕組み」に分ける

技術の欄は、モデルを作る道具と、モデルを動かす仕組みを分けて並べると、読み手が自分の案件に関係する部分を探しやすくなります。

ここでのポイントは、仕組みの側の行を空けないことです。モデルの欄だけが厚いと、検証中心の経歴に見えます。本番で動かした経験があるなら、仕組みの行に具体的に書きます。Pythonのライブラリの並べ方や、試作と本番運用の書き分けはPythonエンジニアのスキルシートの記事でも扱っているので、重ねて書かずにそちらを参考にしてください。

データの扱いで書かないこと

機械学習の経歴には、データの中身が入り込みやすいという特徴があります。次のような情報は、スキルシートに書かないでください。

• 学習に使ったデータの具体的な項目名や、顧客・利用者の属性の内訳
• データの件数と取得元の組み合わせ（業種と合わせると発注元が推測できることがある）
• モデルが判定した対象の具体例（不正と判定した取引の特徴など）

規模を伝えたいときは「数百万件規模の行動ログ」「数十の特徴量」のように、桁でぼかせば十分です。個人に関するデータを扱った経験は、中身ではなく「仮名化されたデータを、決められた環境の中だけで扱った」のように、扱い方を書くと、情報の管理を任せられるかの判断材料になります。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年）
案件概要：小売業向け 需要予測モデルの本番化と運用
規模・立場：データ・機械学習チーム5名（自分は機械学習の実装の担当）
担当した段階：学習・実験（一部）、推論の提供、監視・再学習
使用技術：Python、LightGBM、SQL、ワークフローの定義ツール、クラウドの機械学習サービス、コンテナ
担当内容：分析担当が検証で作ったモデルを、日次でバッチ推論する仕組みに作り直した。学習と推論で別々だった前処理を一つにまとめた
評価と判断：前の版のモデルと、時点で区切った検証データで比べ、上回ったときだけ切り替える手順にした
工夫・成果：入力データの分布の監視を入れ、変化があったときに再学習を判断できるようにした。推論が失敗したときに前日の結果を使う作りにした

「学習・実験（一部）」のように、主担当ではない段階も関わり方をそのまま書いています。検証で作られたものを本番に移した経験は、機械学習エンジニアの案件で特に読まれる部分です。

論文・コンペ・公開コードの扱い

業務の外での実績も、書き方を分ければ材料になります。

• 論文・学会発表：題名と発表先は公開情報なので書けます。ただし、業務の内容を含む場合は、所属先の許可の範囲を確かめてからにします
• データ分析のコンペ：順位よりも、どんな課題で何を工夫したかを1行で添えます
• 公開しているコード：リポジトリの場所と、何を作ったかを書きます。参画先のコードを個人のリポジトリに置くことはしないでください

いずれも、実務の経験とは欄を分けて「業務外の取り組み」として書くと、読み手が混同しません。

資格の書き方

資格がなくても参画できる案件は多くあります。書く場合は、正式な名称と取得年月をそろえます。

日本ディープラーニング協会のE資格は、ディープラーニングの理論を理解し、適切な手法を選んで実装する能力や知識を認定するものとされています。受験には、試験日の過去2年以内に同協会の認定プログラムを修了していることが必要です（2026年10月時点の公式サイトによる）。スキルシートには「E資格（日本ディープラーニング協会）20XX年X月 合格」のように書きます。クラウドの機械学習の認定など、ほかの資格の位置づけは機械学習エンジニアのスキルの記事にまとめています。

よくある質問

検証（PoC）だけで終わった案件ばかりです。どう書けばよいですか？

検証の進め方と、終わらせ方の判断を書きましょう。どの指標で、何と比べ、なぜ本番に進まなかったのかを書くと、検証を任せられる人として読まれます。本番化の経験を補いたい場合は、独立前の準備として機械学習エンジニアがフリーランスになるにはも参考になります。

データサイエンティストとして応募するシートと分けたほうがよいですか？

分けることをおすすめします。データサイエンティストの案件では、課題の設定や分析の結果の説明が読まれ、機械学習エンジニアの案件では、仕組みにして動かし続けた経験が読まれます。同じ経歴でも要約と並び順を入れ替えるだけで伝わり方が変わります。分析が軸の方はデータサイエンティストのスキルシートの記事をご覧ください。

生成AIの経験はどこに書けばよいですか？

機械学習のプロジェクトとは分けて、生成AIの案件として書くと読み手が混同しません。大規模言語モデルを使った検索や評価の仕組みを作った経験は、書き方の観点が違うため、生成AIエンジニアのスキルシートの記事を参考にしてください。