データ・AIエンジニアのスキルシートの書き方｜モデル精度と基盤規模の定量表現

対象読者と本記事の位置づけ

本記事は、データエンジニアリング・機械学習・生成AIの実務を担ってきたフリーランス／独立検討中のエンジニアが、すでに汎用のスキルシート書式は把握している前提で、データ・AI固有の実績表現に絞って読める内容にしている。

スキルシートの基本フォーマット（基本情報・職務経歴・スキル・自己PRの並び方）や、案件詳細の共通ルールについては別記事に委譲する。

• 汎用のフォーマットや記入例：フリーランスエンジニアのスキルシートの書き方を徹底解説！記入例や今すぐ使えるフォーマットも紹介！

• 冒頭3行の職務要約：スキルシートの職務要約の書き方｜冒頭3行で読ませる型と職種別テンプレ

• 案件詳細（担当フェーズ・規模・体制）：スキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度

• 単価に効く定量表現の総論：スキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳

インフラ職種向け（サーバ・NW・クラウド・SRE・セキュリティ）はインフラエンジニアのスキルシートの書き方｜構築・運用実績の数値化と職種別テンプレ、PM／PMO職向けはPMOスキルシートの書き方｜PMとの違いと体制規模・予算・工数の定量化を参照してほしい。

モデル開発実績の書き方｜精度指標・データ量・改善幅

モデル開発案件の実績は、課題（分類／回帰／推薦／生成）ごとに使う指標を選び、ベースラインとの改善幅で語る。指標を1つに決めた上で、副指標を1〜2個添えると読み手が判断しやすい。

使う精度指標を課題別に選ぶ

課題タイプ別の主要指標は以下のとおりで、選定理由（例：不均衡データのためAccuracyではなくF1）まで一言添えると評価されやすい。

指標名を書いても、評価データの切り方（時系列split／stratified k-fold）と評価期間を添えないと再現性が伝わらない。「過去12か月のうち最終3か月をテストセットに固定」など、split方針を1文で書く。

データ量の書き方（レコード数・特徴量数・クラス数・データ源）

「大規模データ」「大量ログ」のような形容詞は避け、レコード数と特徴量数を併記する。レコード数は桁のオーダー（数十万／数千万／億）まで書き、特徴量は「32次元（カテゴリ12＋数値20）」のように内訳を添えると、実装の重さが伝わる。

• NG：「大規模な購買データを用いた予測モデルを構築」

• OK：「購買履歴レコード約1.2億件・ユーザー約200万・特徴量48次元（カテゴリ22／数値26）を対象に、日次バッチで学習パイプラインを実行」

データ源（社内DWH／サードパーティAPI／スクレイピング／公開データセット）も一言添える。商用データの案件が中心なのか、公開データセット中心なのかで案件評価が大きく変わるため、商用データを触った実績は明示的に書き分ける。

ベースライン比較で改善幅を示す（Before/After）

「精度F1 0.86を達成」ではなく、「ベースライン（ロジスティック回帰）F1 0.72 → 施策後 F1 0.86」の形で改善幅を出す。ベースラインは自作のシンプルモデルでも構わないので、比較対象を明示する。

• Before：施策前の指標（既存モデルがない場合はロジスティック回帰・移動平均などのシンプルモデル）

• After：施策後の指標

• 改善幅：絶対値の差または相対改善率

• 施策内容：特徴量の追加／モデル変更／ハイパラチューニング／データ拡張のどれか

改善幅が小さくても、コスト削減や運用リスク低減とセットで書けば案件価値は伝わる。

オフライン評価とオンライン評価を分けて書く

学習データでの評価（オフライン）と、本番投入後のKPI変化（オンライン）は別物として書く。両方書けていると、本番運用まで担ったことが伝わりやすくなり、書類段階で「本番運用まで担ったのか、実験だけで終わったのか」の判断材料になる。

• オフライン：F1・RMSE・nDCGなどのモデル指標

• オンライン：CTR・CVR・売上・解約率など事業KPIの相対変化

オンラインの数値は事業上の機密に触れる場合が多いため、相対値（前月比＋4.2%）や「一部指標で有意な改善を確認」のように匿名化して書く。

データ基盤実績の書き方｜規模・スループット・SLA

データ基盤の担当実績は、取り扱うデータ量・処理スループット・SLAの3軸で書くと粒度が揃う。基盤の話は抽象的になりやすいため、規模の数字を最初に置くと読み手の想像が固まりやすい。

取り扱うデータ規模（TB／PBとレコード数を併記）

ストレージのバイト数（TB／PB）と、レコード件数の両方を書く。バイト数だけだとログ主体（メディア／IoT）か構造化データ主体（EC／金融）かが判別しづらく、レコード数だけだと1レコードの重さが分からない。

• NG：「大規模データウェアハウスの構築を担当」

• OK：「BigQuery上に日次追加3TB・累積約120TB／総レコード約8億件のDWHを構築・運用。テーブル数は約320、うちマート層60テーブル」

パーティション設計（日付／地域／テナント）とクラスタリング列も一言書くと、コスト設計まで担ったことが伝わる。

パイプラインのスループット・レイテンシ

処理性能はスループット（件／秒、GB／時）とレイテンシ（p50・p95・p99）を書き分ける。ストリーミング案件の場合はp99レイテンシまで書くと運用経験が伝わる。

• バッチ：「日次24時間ぶんのイベントログ約4TBを、Sparkジョブ12本で並列処理。総実行時間は平均3.5時間、SLA上限4時間」

• ストリーミング：「Kafka→Flinkでイベント秒間約1.2万件を処理。p95レイテンシ800ms、p99レイテンシ2.1s」

ジョブ本数・並列度・使用したクラスタサイズ（例：n2-standard-16 × 20台）まで書くと、コスト面の判断力を持っていることが示せる。

SLA・稼働率・データ鮮度（Freshness）

運用系の指標として、SLA・稼働率・データ鮮度を書く。Freshness（データ鮮度）はデータ基盤特有の指標で、書けている候補者は多くない。

これらの数値は、案件現場のダッシュボードをそのまま出せないケースが多いため、公開・記載可能な範囲で概数として1桁精度で書くとよい。NDAや秘密保持条項に触れないかを事前に確認し、面談で数値に触れる際は「概算」と明示すると齟齬を防げる。

コスト効果（月額削減額・削減率）

データ基盤案件は費用対効果を語りやすい。クラウドコストの月額と、施策による削減額／削減率を書くと、ビジネス価値の翻訳ができる人材と判断されやすい。

• OK：「BigQueryのクエリコスト月額約180万円のうち、パーティション再設計とマート層集約により月額約72万円（約40%）を削減」

削減額を出せない場合は、削減率と施策内容だけでも書く。数値の書き方が事業価値に結びついていると、採用担当者に技術成果を事業価値に翻訳して説明できる人材だと伝わりやすい。

MLOps・運用実績の書き方

MLOps案件のスキルシート表現は、「モデルを本番で回した」ことをどう証明するかがポイントになる。モデル配信基盤・A/Bテスト・監視・再学習の4要素で分けて書く。詳細はMLOpsとは？機械学習モデルの運用を自動化する仕組み・ツール・案件事情を解説にまとめている。

モデル配信基盤（レイテンシ・QPS）

推論APIの性能指標として、QPS（1秒あたり処理数）とレイテンシを書く。

• OK：「オンライン推論APIを構築（FastAPI＋Triton Inference Server）。ピーク時QPS約2,400、p95レイテンシ85ms、月間推論回数約9億回」

バッチ推論の場合は「日次で2億件を4時間で推論」のように書き換える。使用したフレームワーク（Triton／TorchServe／SageMaker Endpoints）とデプロイ先（Kubernetes／マネージド）も併記する。

A/Bテスト・オフライン→オンラインの成果検証

モデル刷新のA/Bテストを担当した場合、割り当て比率・期間・主要KPIの相対変化・有意水準まで書く。

• OK：「新モデルv2をランダム50/50で3週間A/Bテスト。処理対象は日次アクティブユーザー約12万人、主要指標CTRで前バージョン比+3.8%（p<0.01）を確認しロールアウト」

有意水準を出せない場合は「相対＋3.8%を確認」までで留め、断定を避ける。

モデル劣化検知・再学習パイプライン

本番運用中のモデル劣化検知（Data Drift／Concept Drift）と、それに応じた再学習の運用ルールを書けると、運用経験の深さが伝わる。

• OK：「特徴量分布の日次PSIとモデル指標の週次モニタリングを構築。PSI＞0.2で再学習トリガー、月次で自動再学習ジョブを実行」

• 使用ツール：MLflow の実験管理、Evidentlyのドリフト検知、Prometheus／Grafanaでのアラート

特徴量ストア・実験管理

特徴量ストア（Feast等）や実験管理ツールを運用した経験は、モデル開発の再現性・チーム開発の実務を担った証拠になる。使ったツール名だけでなく、何本のパイプライン／何名のチームで運用したかまで書くと運用規模が伝わる。

生成AI案件のスキルシート表現（LLM・RAG・エージェント）

生成AI／LLM案件のスキルシートは、書式がまだ定まっていない案件が多い。プロンプト設計・RAG構成・モデル選定・情報漏えい対策の4軸で整理すると読みやすい。生成AIエンジニアの職域については生成AIエンジニアとは？仕事内容・必要スキル・年収とAIエンジニアとの違いを解説にまとめている。

プロンプト設計と精度検証の書き方

「プロンプトを設計」だけでは実務内容が伝わらない。評価データセット・評価軸・スコア変化を書く。

• OK：「社内問い合わせQ&A用途で、評価データ150問に対する回答正答率をベースライン62% → 施策後83%まで改善（人手評価3名平均）。プロンプトのFew-shot例数・Chain-of-Thoughtの有無・出力形式指定を実験パラメータとして比較」

評価が人手評価の場合は、評価者数と評価基準を書き添える。

RAG構成の書き方（ベクトルDB・埋め込みモデル・検索精度）

RAG（Retrieval-Augmented Generation）案件では、検索フェーズと生成フェーズを分けて書く。

• 検索フェーズ：埋め込みモデル・ベクトルDB・チャンクサイズ・トップK・Recall@K

• 生成フェーズ：使用モデル・プロンプト設計・出力後処理・生成の正確性

書き方の例：「文書約8万件（総トークン約3,200万）を1,000トークン単位でチャンク化し、text-embedding-3-largeで埋め込み、pgvectorに格納。検索評価データ200問でRecall@5が0.78、生成後の回答正答率が85%（人手評価）」。

モデル選定と切り替え運用

APIモデル（Claude、GPT系、Gemini）とセルフホスト（Llama、Qwen等）の切り替え、コスト最適化の判断ロジックを書けると、実務判断力が伝わる。

• OK：「ユースケース別にモデルを使い分け、簡易分類タスクは軽量モデル・複雑推論はフラッグシップモデルにルーティング。月次APIコスト約240万円のうち、ルーティング導入で約90万円（約38%）を削減」

情報漏えい対策の書き方

生成AI案件では情報漏えい対策の実務経験が採否を分ける。PII検出・マスキング・入出力ログの保存範囲・監査ログの書き方が具体的だと通過しやすい。関連論点はスキルシートをAIで作る手順｜下書き活用と情報漏えい対策でも触れている。

• OK：「入力前にPresidioでPII検出・マスキング処理を挟み、監査ログを90日間保管。API送信ペイロードの学習利用オフを設定確認、社内ゲートウェイ経由で全通信をログ化」

職種別テンプレート

同じデータ・AI領域でも、職種によって強調すべき指標は変わる。自分の中心職種を1つ決め、案件詳細もその軸で並べる。全職種を並列に書くと採用側から「何屋さんか分からない」と評価されやすい。

データエンジニア（基盤中心）

書くべき項目の並び順：

1. 職務要約（3行）：担当DWH／データ量／SLA上限

2. スキル（言語・ETL基盤・DWH・オーケストレーション・IaC）

3. 案件詳細：

- データ規模（TB・レコード数・テーブル数）

- パイプライン本数と処理スケジュール

- SLA・Freshness・稼働率

- コスト削減の実績

書き方の詳細はフリーランスデータエンジニアになるには？案件の探し方と必要スキルを解説を参照。

機械学習エンジニア（モデル開発中心）

書くべき項目の並び順：

1. 職務要約（3行）：担当課題（推薦／需要予測など）／使用モデル／改善幅

2. スキル（Python・フレームワーク・特徴量エンジニアリング・分散学習）

3. 案件詳細：

- 課題設定と評価指標

- データ規模（レコード数・特徴量数・クラス数）

- ベースライン → 施策後の改善幅

- オンライン評価の相対値（開示可能な範囲で）

MLOpsエンジニア（運用中心）

書くべき項目の並び順：

1. 職務要約（3行）：担当推論基盤／QPS／SLA

2. スキル（コンテナ・オーケストレーション・CI/CD・監視）

3. 案件詳細：

- 推論APIの構成（QPS・レイテンシ・稼働率）

- 学習パイプラインの規模（ジョブ数・実行時間・並列度）

- 監視・ドリフト検知の運用ルール

- 再学習の自動化範囲

生成AIエンジニア（LLM／RAG中心）

書くべき項目の並び順：

1. 職務要約（3行）：担当ユースケース／使用モデル／精度改善幅

2. スキル（LangChain／LlamaIndex等・ベクトルDB・プロンプト設計）

3. 案件詳細：

- ユースケース（社内Q&A／要約／エージェント）

- 評価データセット規模と評価軸

- RAG構成（埋め込みモデル・DB・Recall@K）

- 精度・応答レイテンシ・APIコスト削減

データサイエンティスト／アナリスト

書くべき項目の並び順：

1. 職務要約（3行）：担当領域（マーケ／プロダクト分析／需要予測）／使用手法／意思決定貢献

2. スキル（統計・実験計画・可視化・SQL）

3. 案件詳細：

- 分析対象（データ規模・期間）

- 使った手法（回帰分析／因果推論／時系列予測）

- 意思決定に反映されたアウトプット（施策・KPI変化）

アナリスト案件は「意思決定に反映された」の粒度が採用側から見られやすい。打ち手が実装されたかどうかを1行で示すと、単なる分析屋との差別化になる。

単価に効きやすい定量表現のポイント

上位単価帯として扱われやすい案件（首都圏の主要フリーランスエージェントの公開案件を見る限り、データ・AI領域では月120万円前後以上が目安）に届きやすいスキルシートには、共通する書き方の傾向がある。単価は実績・市場需給・交渉力・商流の複合要因で決まるため、以下は「評価されやすい実績の見せ方」として読んでほしい。単価交渉で評価されやすい実績の見せ方の総論はスキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳にまとめており、ここではデータ・AI固有のポイントに絞る。

上流フェーズ・リード経験の書き方

要件定義・アーキテクチャ設計・技術選定の担当範囲を明示する。「モデルを設計・実装」ではなく、「モデル選定基準の策定・PoC実施・要件定義書化」まで書くと、上流を任される案件で評価されやすい。

• OK：「予測モデルの選定基準（精度／レイテンシ／再学習コスト）を策定し、3モデル候補のPoCを2週間で実施、要件定義書化まで担当」

リード経験は、チーム人数と自分のロールまで書く。「MLエンジニア3名・データエンジニア2名の混成チームでテックリード」など。

商用データ規模の客観化

自社サービスの利用規模を、公開可能な範囲で客観化する。総ユーザー数・DAU・月間トランザクション数などは、社名を伏せても書ける場合がある。

• OK：「月間アクティブユーザー約400万人規模のECサービスで、購買履歴を対象に推薦モデルを構築」

規模が公開情報になっている場合は、自分が関与したサービス・時期と対応する範囲でIR資料の数値を引用し、非公開の場合はオーダー（数百万〜数千万など）で書く。

一次公開KPIの引用

公開されているKPI（IR資料・プレスリリースで数値化された指標）を引用してよい案件は、「◯◯（一次公開情報）が前年比＋X%となった時期に、推薦モデルの刷新プロジェクトを主担当」の形で書ける。案件の重要度が伝わりやすい。

ただし、公開KPIは複数施策や外部要因の合算結果であることが多いため、自分の施策単独の成果として断定せず、プロジェクトの文脈情報として添えるにとどめる。機密情報と公開情報の切り分けは案件契約に依存するため、公開範囲は必ず契約書とNDAで確認する。

よくある失敗と対策

チェッカーの視点で、データ・AIエンジニアのスキルシートで頻出する失敗をまとめる。

「機械学習を経験」で終わっている

「機械学習を用いた予測モデルを開発」の1行だけで案件詳細が終わるパターン。担当課題／使用モデル／評価指標／データ規模のうち、最低3つは書く。

モデル指標がない・データ量がない

「精度の高いモデルを構築」「大規模データを処理」など、形容詞だけで数値がないパターン。可能な範囲で数値または桁のオーダーを添える。正確な数値を出せない場合は、概数・相対値・匿名化表現（数百万〜数千万件など）で補う。

商用と研究の切り分けが不明

「Kaggleコンペで銀メダル」と「商用データでの実装経験」は評価軸が違う。両方書く場合はセクションを分ける。研究／コンペ／自主学習と、商用プロジェクトの実績は分けて並べる。

ライブラリ列挙で終わる

「TensorFlow、PyTorch、scikit-learn、XGBoost、LightGBM、Sparkの使用経験あり」の羅列だけで、実際に何を作ったかが書かれていないパターン。「TensorFlowで◯◯モデル」の形で、ライブラリごとに1案件を紐付ける。

数字の母集団を書かずに「高い精度」と書く

「モデル精度98%を達成」だけだと、テストセットの切り方・不均衡データかどうかが分からず、疑いの目で読まれる。評価データの内訳・splitの方針・指標選定の理由をセットで書く。実績が少ない場合の書き方は実績が少ないフリーランスエンジニアでも通るスキルシートの書き方を参照。

提出前チェックリスト

スキルシート提出前に、以下の項目を確認する。案件応募直前の最終チェックとして使ってほしい。

• ☐

  各案件詳細に、指標名・数値・改善幅の3点セットが入っているか

• ☐

  レコード数・特徴量数・データ量のいずれかを1桁の精度で書けているか

• ☐

  ベースラインまたは施策前の指標を明示しているか

• ☐

  オフライン評価とオンライン評価を分けて書けているか

• ☐

  生成AI案件はプロンプト評価データ数・評価軸を書けているか

• ☐

  コスト削減・KPI改善の相対値を書けているか

• ☐

  中心職種を1つに絞り、案件詳細の並び順を統一しているか

• ☐

  商用データと研究・コンペを別セクションに分けているか

• ☐

  ライブラリ名の羅列だけで終わっていないか

• ☐

  機密情報と公開情報の切り分けを契約書で確認したか

通らない原因のパターン整理はフリーランスのスキルシートが通らない7つの原因｜書類選考の改善策にまとめている。

スキルシートを整えたら、実際の案件感を掴むためにフリコンの案件一覧で、データ・AI領域の募集要件と単価レンジを確認しておくと、書き方の粒度を案件側に合わせやすくなる。

まとめ

データ・AIエンジニアのスキルシートは、指標名・数値・改善幅の3点セットを各案件詳細に必ず入れることで、他の候補者との差別化が可能になる。モデル開発ならF1／RMSE／nDCG＋ベースライン比較、データ基盤ならTB／レコード／SLA／Freshness、MLOpsならQPS／レイテンシ／稼働率と、職種ごとに軸を決めて書く。

中心職種を1つに絞り、案件詳細の並び順を統一することで、採用側が「何を任せられる人か」を書類段階で判断できるようになる。数値を出せない案件は相対値や匿名化で改善幅を伝え、機密情報と公開情報の切り分けは契約書で確認しておく。

スキルシートが整ったら、自分の市場単価の見通しを立てるためにフリーランスエンジニア単価診断を活用してほしい。実際の応募先を選ぶ際は、フリコンの案件一覧でデータ・AI領域の案件要件と単価レンジを確認し、書き方の粒度を案件側に合わせて調整するのが効率的だ。