MLOpsエンジニアのフリーランス案件の選び方｜契約前に確かめたい7つの点

フリーランスのMLOpsエンジニアの案件を選ぶときは、報酬や稼働日数に加えて、役割の実態、基盤の今の段階、権限の手続き、運用と障害対応の範囲、費用の扱い、成果物と契約の形、契約期間と引き継ぎの7点を契約前に確かめておくことが大切です。MLOpsの案件は、同じ「MLOps基盤の構築」の募集でもこの7点の違いで、毎日の仕事も負う責任も大きく変わります。

特に見落としやすいのは、作る仕事として受けたのに、作った後の運用まで一人で背負う形になっていないかです。この記事では、MLOps案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

MLOps案件の選び方で差が出る理由

MLOpsは、インフラ、ソフトウェア開発、機械学習の境目にある職種です。そのため案件票には「MLOps基盤の構築」「機械学習基盤の運用」のように幅のある書き方が多く、参画してから想定との違いに気づくことが少なくありません。

よくあるずれは次のようなものです。

• 基盤の構築と聞いていたのに、実際はモデルの精度の改善やデータの加工が中心だった
• 本番の権限がなかなか付与されず、最初の数週間は資料を読むことしかできなかった
• 作ったパイプラインの夜間の失敗の通知が、自分だけに届く形になっていた
• 検証用のGPUの費用の扱いが決まっておらず、試したいことが試せなかった

こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。案件の種類ごとの働き方はMLOpsエンジニアの仕事内容で整理しています。

契約前に確かめたい7つの点

1. 役割の実態はMLOpsか、機械学習か、インフラか

最初に確かめたいのは、自分が担う役割の実態です。MLOpsとして募集されていても、実際にはモデルを作る仕事が中心だったり、クラスターの管理だけを求められていたりすることがあります。

面談では、「参画後の最初の3か月で、最も期待されている成果は何か」を聞くと、役割が見えやすくなります。答えが「学習から配置までを自動にする」ならMLOps、「精度を上げる」なら機械学習エンジニア、「クラスターを安定させる」ならインフラやSREに近い役割です。

2. 基盤の今の段階

案件票に書かれていない「今の段階」を確かめます。

• 学習と配置は、今どう回っているか（手作業か、一部が自動か、仕組みはあるが課題があるか）
• 基盤に乗っているモデルと、使っているチームの数
• 前任の担当者がいる場合、残っている文書と、引き継ぎを受けられる期間

立ち上げの案件と、手作業の読み解きから始まる案件とでは、最初の1か月の過ごし方がまったく違います。段階を知ったうえで受けることが大切です。

3. 権限の手続きと、使える環境

MLOpsの仕事は、クラウドのアカウント、データ、GPUの資源に触れられないと進みません。

• 本番と検証の環境に、どの権限が、いつまでに付与されるか
• 権限の申請に社内の審査があるか、かかる期間の目安
• 貸与の端末や、閉じたネットワークからの作業が必要か
• 学習に使うデータのうち、個人情報や機密の扱いが必要なものはあるか

権限が付与されるまでの期間に何をするかも、あわせて決めておくと、初月が空回りしません。端末と働く場所の確認点はMLOpsエンジニアのリモート案件の記事で整理しています。

4. 運用と障害対応の範囲

作る仕事と運用する仕事の線を確かめます。

• 本番の障害の一次対応は誰が担うか。自分は通知を受ける体制に入るか
• 夜間や休日のジョブの失敗に、どこまで応じる想定か
• 対応した時間の精算の扱いと、稼働の幅を超えたときの扱い
• SREやインフラのチームとの役割の分担

MLOpsの基盤は、作った人に問い合わせが集まりやすい性質があります。運用の範囲を決めないまま受けると、責任感から稼働日以外の対応が続くことになりかねません。精算の仕組みは精算幅の記事をご覧ください。

5. GPUとクラウドの費用の扱い

• 検証や学習に使える資源の範囲と、費用の上限を誰が決めるか
• 費用の削減が成果として求められているか、その場合の目標の決め方
• 自分のアカウントで費用を立て替える場面がないか

費用の削減を求められる案件では、削減の効果だけでなく、止まりにくさとの釣り合いを誰が判断するかを確かめておきます。費用を立て替える条件の考え方はMLOpsエンジニアの報酬の記事でも触れています。

6. 成果物と、契約の形

フリーランスのMLOpsエンジニアは、多くの場合、準委任契約で参画します。準委任では、基盤の完成や性能の達成そのものではなく、専門家として通常求められる注意を払って業務を行うことが約束の中身になります。

確かめたいのは、契約書や発注の書面の書き方が、この考え方と合っているかです。

• 「推論の応答速度を◯◯以下にする」「障害をゼロにする」のように、結果を約束する書き方になっていないか
• 納品が求められる場合、その範囲は何か（IaCのコード、パイプライン、手順書など）
• 作ったコードや設定の権利と、自分が以前から持っている雛形や道具の扱い

請負の形で受ける場合は、完成に対する責任を負うことになります。役割と契約の形が合っているかを確かめましょう。違いは準委任契約と請負契約の違いで解説しています。準委任の契約なのに、発注元の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。詳しくは偽装請負の記事をご覧ください。データやモデルの秘密の扱いは秘密保持契約（NDA）で確認することが参考になります。

7. 契約期間と引き継ぎ

契約の期間と、基盤の節目が合っているかを確かめます。たとえば、本番の切り替えの直前に契約の更新時期が来ると、更新されなかった場合に最も大事な局面を見届けられません。

あわせて、契約が終わるときに誰に何を引き継ぐかも確かめておきます。MLOpsの基盤は、作った人がいなくなっても回り続けることが期待されます。引き継ぎ先がいない案件では、手順書や設計の理由を残す時間を、契約の中で確保しておく必要があります。

フリーランス法では、6か月以上の業務委託で契約を解除したり更新しなかったりするときは、原則として少なくとも30日前までに予告することが求められています（2026年10月時点、公正取引委員会の案内による）。詳しくは中途解除の30日前予告の記事をご覧ください。

確かめた内容を書面と照らし合わせる

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、発注する事業者は業務を委託したら直ちに、取引条件を書面またはメールなどで明示することとされています。報酬の支払期日は、給付を受け取った日から60日以内のできる限り短い期間内で定めることとされています（いずれも2026年10月時点、公正取引委員会の案内による）。明示される事項はフリーランス法で明示される取引条件をご覧ください。

MLOpsの案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う範囲（設計、構築、運用、障害対応など）が書かれているか
2. 結果を約束する書き方や、障害そのものの責任を負う書き方になっていないか
3. 稼働の幅と、夜間や休日の対応を含めた精算の方法
4. 作ったコードや設定の権利、守秘の範囲
5. 契約期間と更新の時期、引き継ぎの扱い

面談で聞いておくとよい質問はMLOpsエンジニアの面談でよく聞かれる質問と答え方の逆質問の項目でも紹介しています。一般的な逆質問の考え方は面談で聞いておくべき逆質問をご覧ください。

よくある質問

立ち上げの案件と運用の案件、どちらを選ぶのがよいですか？

一概には言えませんが、立ち上げは設計の判断を任される分、構成を決めた経験として次の案件で話しやすくなります。運用の案件は、障害の対応や改善の前後の数字を残しやすく、止まりにくさへの責任を示す材料になります。今の経験で足りない側を補える案件を選ぶ考え方もあります。

権限がなかなか付与されないときはどうすればよいですか？

申請の状況と、付与されるまでにできる作業を発注元の担当者と確かめます。資料の読み込み、構成図の作成、検証の環境での試しなど、権限がなくても進められる作業を先に示しておくと、稼働の記録も説明しやすくなります。

報酬が高い案件と、運用の範囲がはっきりした案件で迷ったらどうしますか？

MLOpsの案件では、運用の範囲が曖昧なまま障害の対応が続くと、稼働が増えて時間あたりの報酬が下がることがあります。報酬の額だけでなく、夜間や休日の対応の見込みと精算の方法を合わせて比べるとよいでしょう。報酬の決まり方はMLOpsエンジニアの報酬の記事で解説しています。