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

MLOpsエンジニアのスキルシートは、基盤の規模と利用者、自分が担当した工程、導入の前後で何が変わったか、自分が残した仕組みの4つを書き分けるのが基本です。使った道具を並べるだけでは、読み手は「何を任せられる人か」を判断できません。

MLOpsの仕事は、成果が「止まらなかった」「楽になった」という形で表れやすく、書かないと伝わりにくい性質があります。この記事では、項目ごとの書き方と、架空の記入例を紹介します。スキルシート全般の基本はスキルシートの基本の記事をご覧ください。

まず「基盤の規模」を一行で書く

MLOpsの経験は、規模によって中身が大きく変わります。プロジェクトの冒頭に、次の情報を一行でまとめると、読み手が経験の重さを判断しやすくなります。

• 基盤を使ったチームや部署の数
• 載っていたモデルの種類（表形式の予測、画像、言語モデルなど）
• 推論の形（バッチ、API、現場の機器）
• 使ったクラウドとオーケストレーションの方式

数は、守秘義務に反しない範囲で、おおよその表現（「数チーム」「十数モデル」など）でも構いません。具体的な数を書くかどうかは、契約の取り決めに従ってください。

担当した工程を表で示す

学習から監視までのどの工程を、どの深さで担ったかを表にすると、面談で聞かれる前に答えられます。

「設計した」と「運用した」は、同じ工程でも求められる力が違います。自分が判断した部分と、決まったものを動かした部分を分けて書きましょう。各工程で見られる力はMLOpsエンジニアのスキルの記事で整理しています。

成果は「前と後」で書く

MLOpsの成果は、仕組みを入れる前と後の違いで書くと伝わります。

• モデルを本番に出すまでの作業：手作業での受け渡し → 承認を経て自動で配置
• 再学習の失敗への気づき：利用者からの問い合わせで発覚 → 失敗を自動で通知し、前の版で動き続ける
• GPUの費用：使っていない資源が残りがち → 使っていない資源を自動で止め、チームごとに費用を見える化
• 新しいチームの利用開始：個別に環境を作っていた → テンプレートと手引きで自分たちで始められる

数字で示せる場合は、守秘の範囲で比率や期間の短縮を書くとさらに伝わります。示せない場合も、何が手作業から仕組みに変わったかが書けていれば十分な材料になります。

スキル一覧は「層」で分ける

道具の名前は、層ごとに分けて書くと読みやすくなります。

版の数字を書く場合は、使っていた当時の版を書き、今も保守されている版かどうかを把握しておきましょう。たとえばKubernetesは、公式のリリースのページで直近の3つのマイナー版が保守されると案内されています（2026年10月時点）。面談で版上げの経験を聞かれたときに、どの版からどの版へ上げたかを答えられると、運用の経験が伝わります。

障害対応と運用の経験の書き方

MLOpsの案件では、作った経験と同じくらい、動かし続けた経験が見られます。障害対応や運用の経験は、次の形で書くと伝わります。

• 起きたこと：再学習の失敗、推論の遅延、入力データの形式の変化など、種類を一般化して書く
• 気づき方：監視の通知か、利用者からの連絡か
• 自分の対応：切り戻し、原因の調査、再発防止の仕組み
• その後に変えたこと：監視の追加、手順の文書化、テストの追加

オンコールの当番を担った場合は、当番の体制の中での自分の役割（一次対応か、二次対応か）も添えると、任される範囲を想像しやすくなります。面談で深く聞かれやすい部分なので、MLOpsエンジニアの面談の記事とあわせて準備しておくとよいでしょう。

LLMOpsの経験の書き方

生成AIの運用の経験は、機能を作った経験と分けて書きます。MLOpsエンジニアとして見られるのは、次のような運用の仕組みです。

• プロンプトや設定の版の管理と、変更前後の評価の比較
• 呼び出しの記録と、回答の質・応答速度・費用の監視
• 複数のモデルやサービスへの呼び出しの統制（権限、費用の上限）

プロンプトや検索の設計を中心に書く場合は、生成AIエンジニアのスキルシートの記事の書き方のほうが合うこともあります。

書かないこと・伏せること

基盤の情報は、発注元の内部の構成そのものです。次の点は書かないか、一般的な表現に置き換えます。

• 取引先の社名、サービス名、内部のシステムの名前
• ネットワークの構成、アカウントの構成、権限の設計の詳細
• 学習データの中身や、個人情報を含む推論の記録の内容
• 障害の具体的な日時や、影響した利用者の数

伏せ方の考え方はスキルシートの守秘義務の記事で解説しています。

プロジェクト欄の記入例（架空）

以下は書き方を示すための架空の例です。実在の企業・案件・数字ではありません。

期間：1年2か月　役割：MLOpsエンジニア（チーム4名）

基盤の規模：数チームが利用する需要予測と画像検査のモデルの基盤。クラウド上のKubernetesで学習ジョブと推論APIを運用

担当：

• 担当者の手作業で行っていた再学習と配置を、パイプラインに移行（設計・実装）
• モデルの登録と承認の流れを作り、本番への配置は承認済みの版からだけ行えるようにした
• 入力データの傾向の変化と推論の応答速度の監視を追加し、異常時の連絡先と対応の手順を決めた
• 他のチームが新しいモデルを載せるためのテンプレートと手引きを作成

前と後：本番への配置が担当者の手作業から承認を経た自動の流れに変わり、再学習の失敗は通知で気づけるようになった。新しいチームが手引きを見て自分たちで利用を始められるようになった

使った技術：クラウドの機械学習向けサービス、Kubernetes、Terraform、パイプラインの道具、実験の追跡とモデルの登録の道具、監視と通知の道具

自己PRの欄では、「どの段階の基盤を、どこまで引き上げるのが得意か」を一文で書くと、プロジェクト欄の読み方が定まります。たとえば「手作業で回っているモデルの運用を、他のチームも使える仕組みに移す仕事が得意です」のように、得意な仕事の形を言葉にします。

この形で、プロジェクトごとに「規模・担当・前と後・技術」をそろえると、複数の経験を比べて読んでもらいやすくなります。

よくある質問

機械学習エンジニアのスキルシートと分けたほうがよいですか？

応募する案件の中心が、モデルを作ることか、基盤を作って運用することかで、前に出す経験を変えると伝わりやすくなります。同じ経験でも、MLOpsの案件では基盤の規模と残した仕組みを、機械学習の案件ではモデルの評価と判断を先に書きます。モデル側の書き方は機械学習エンジニアのスキルシートの記事をご覧ください。

インフラの経験が長く、MLOpsの経験は短いです。どう書けばよいですか？

インフラの経験を省く必要はありません。コンテナ、IaC、監視の経験は、MLOpsの基盤の土台として読まれます。そのうえで、MLOpsの経験は短くても、機械学習ならではの部分（モデルの版の管理、データの変化の監視など）に何をしたかを具体的に書きましょう。

個人で作った検証用の基盤は書いてもよいですか？

書いて構いません。業務の経験とは分けて、個人の取り組みとして書きます。何を確かめるために作り、何がわかったかを添えると、学び方の姿勢が伝わります。