SES費用の相場｜単価内訳と契約比較

2026年時点のSES月額相場は、週5日・準委任・精算幅140〜180時間を前提にすると、1人あたり80万〜120万円が中心です。
発注額は経験年数、担当工程、地域、商流で上下し、生成AIやMLOpsのような希少領域では120万円超も珍しくありません。

本稿は、AI人材や開発要員の外部調達を検討している発注企業向けに、相場の根拠を専門メディアや法務・人材系の複数情報で整理しつつ、見積書のどこを見れば妥当性を判断できるかを実務目線で解説します。
3社見積を並べる場面では、同じ月100万円でも法定福利費や教育費まで内訳を明記する会社のほうが、後から条件解釈でもめにくい傾向が複数案件で一貫していました。

あわせて、給与・法定福利費・採用教育・設備・管理費・会社マージンの内訳を表で可視化し、SES・派遣・請負・フリーランスを報酬基準、指揮命令権、費用感、向くケースで比較します。
常駐前提の基幹刷新を3名・6ヶ月で組んだ案件でも、商流の浅い一次と地方リモート併用に設計を切り替えて総額を約15%圧縮できたため、PoCは副業・業務委託の低稼働、中長期の常駐補強はSESといった初期判断までつなげられます。

SESの費用相場の全体像

2026年の中心レンジと前提条件

2026年3月時点で、SESの費用相場は月額80万〜120万円/人が中心帯です。
この数字は、週5日稼働、準委任契約、月間の精算幅が140〜180時間という実務上もっとも一般的な条件を置いたときに使いやすい目安です。
見積比較の場面でまず基準線になるのも、このレンジです。

前提条件をそろえずに単価だけ比べると、相場判断はすぐにぶれます。
SESはSystem Engineering Serviceの略で、実務では準委任契約として扱われることが多く、報酬は成果物そのものではなく、エンジニアの作業時間と技術提供に対して発生します。
そのため、発注側では「何を作るか」だけでなく、「何人月で、どの工程を、どの体制で支援してもらうか」という見方が欠かせません。

ここで出てくる人月（にんげつ）は、1人が1ヶ月稼働する単位です。
週5日フルタイム案件では、1日8時間×月平均20営業日で160時間が中心になり、そこに月ごとの営業日数の差を吸収するため、140〜180時間の精算幅が置かれる形が定着しています。
見積書に「月額単価100万円」と書かれていても、この精算幅の有無や超過・控除の計算方法まで読まないと、実際の支払総額は判断できません。

実務上は、同じ月額でも稼働設計で実効価値が変わります。
筆者の経験では、週5常駐から週3常駐＋週2リモートへ切り替えた個別案件で、移動待機や会議の隙間時間が減り、請求単価を据え置いたまま納品速度が向上した事例があります。
ただしこれは案件・チーム・運用設計に依存する個別事例であり、普遍的な効果として保証されるものではありません。

図表にするなら、まずは経験年数別レンジ表と地域差の目安表の2つが有効です。
金額だけでなく、「週5」「140〜180時間」「準委任」という前提を欄外で固定しておくと、相場表としてぶれません。
なお、SES相場は案件市況の影響を受けるため、2026年内でも更新前提で扱うのが実務的です。

経験・スキル別の単価目安

この表だけを見ると、若手案件の感覚と合わないと感じることもあります。
実際、若手層を広く集めた市場データではもっと低い水準も見られ、未経験〜1年目や運用保守・テスト中心では30万〜50万円台の案件も存在します。
ここに差が出る理由は、対象職種、担当工程、商流、常駐比率、フルタイム前提かどうかが揃っていないためです。
発注側の相場判断では、「企業が払うBtoB単価」なのか、「若手を含む案件全体の掲載単価」なのかを分けて読む必要があります。

単価差が最も出やすいのは、実装力そのものよりも上流工程を持てるかどうかです。
要件整理、顧客折衝、既存システムの制約把握、運用への落とし込みまで担える人材は、工数の読み違いを減らせるため、月額が上がりやすくなります。
反対に、作業範囲が明確なテスト実施や定型運用監視は、同じIT職でも単価が下がりやすい領域です。

発注実務では、経験年数だけで判断すると外す場面もあります。
5年経験でも特定業界の基幹システムに深く入っている人材は、中級レンジの上側で成立しやすく、10年以上でも技術更新が止まっている場合は上級レンジの下側にとどまります。
見積の妥当性を測るなら、「年数」よりも担当工程、技術スタック、リーダー経験、顧客折衝の有無の4点を並べて見るほうが精度が上がります。

地域差とAI人材の上振れ要因

地域差も単価を押し上げる要素です。
東京圏は案件数が多く、金融・大規模基幹・SaaS・データ基盤案件が集中するため、地方より高値になりやすい傾向があります。
公開情報では、東京エリアが70万〜100万円、地方が40万〜70万円台という目安も見られます。
加えて、雇用コストの観点では東京のベース給与が地方比で20%〜25%上乗せされやすい水準にあり、この差が外注単価にも波及します。

ただし、地域相場は単一の集計だけで断定できるものではありません。
地方でもプライム案件や高難度のモダナイズ案件なら東京圏に近い単価になる一方、東京でも運用・テスト中心なら下振れします。
実務では「東京だから高い」というより、東京プレミアムとして、案件密度、上流比率、顧客折衝の重さ、出社要件の厳しさが上乗せされると考えると整理しやすくなります。

地域差の目安を表にすると、次のような読み方が実務向きです。

AI人材は、この地域差よりもスキル差による上振れのほうが大きく出ます。
生成AI、MLOps、データ基盤、本番運用を見据えた要件定義まで扱える人材は、一般的なSES相場の上限を超え、120万円超で提示されるケースが増えています。
特に、LLMを使った社内業務改革や検索拡張生成、評価基盤、監視設計まで求められる案件では、単なる実装者では足りず、設計と運用をつなげられる人材にプレミアムが乗ります。

この領域は公開相場がまだ薄く、全国統計として固まっているわけではありません。
そのため、AI案件の見積を見るときは、一般SESの中心レンジを土台にして、希少スキル、上流関与、実運用経験の3点で上振れ幅を読むのが実務的です。
AIと書かれているだけで高単価になるのではなく、PoC止まりではなく本番運用まで視野に入るかどうかで、単価の説得力が変わります。

用語の基礎

相場を読むうえで、最低限そろえておきたい用語は多くありません。
まず押さえたいのは、SESが準委任で使われることが多いという点です。
準委任では、発注企業は成果物の完成を買うのではなく、一定の時間内で提供される技術支援を買います。
このため、請負契約のように「完成責任」を前提にした費用感とは分けて考える必要があります。

次に重要なのが人月です。
人月は1人×1ヶ月の稼働量を表す単位で、SESの見積はこの単位で組まれます。
たとえば2人月なら、1人が2ヶ月でも、2人が1ヶ月でも、工数上は同じ扱いです。
実務ではこの工数に対して月額単価を掛け合わせ、さらに精算幅の超過・控除ルールを契約で定めます。

精算幅は、月間稼働時間の許容レンジです。
代表例が140〜180時間で、範囲内なら月額単価を満額で支払い、下限を割ると控除、上限を超えると追加精算になる設計が一般的です。
中心の160時間は、1日8時間×20営業日から導かれるため、140〜180時間は160時間を軸にした実務上の幅と考えると理解しやすくなります。

もう1つ外せないのが指揮命令権です。
SESでは、現場で働くエンジニアに対する指揮命令権は発注企業ではなく所属会社側にあります。
発注側が個々のSES人材へ直接指示を重ねると、偽装請負と見なされるリスクが出ます。
費用相場の話に見えても、実際にはこの契約構造が単価に影響しています。
成果責任を持つ請負よりも、稼働確保と体制補強に向くのがSESであり、そのぶん見積書も「成果物単価」ではなく「人月単価」で並ぶわけです。

SES単価の内訳

人件費

SESの見積単価は、まずエンジニア本人にひもづく人件費から組み立てるのが基本です。
ここでいう人件費は、単純な月給だけではありません。
見積書の発注額と、本人に支払われる金額の間には、給与（基本給）、残業代、賞与相当の月次按分といった要素が入ります。
BtoBの見積単価は、従業員の手取りを積み上げた数字ではなく、会社が雇用を維持するために負担する総額を土台にして設計されます。

ISF NETの人件費分解でも、給与本体に加えて各種保険料や間接費が積み上がる構造が示されていますが、発注側が受け取る見積書では、その内訳が「技術料」や「人月単価」にまとめられて見えにくくなりがちです。
実務上は、見積単価の中心にあるのは基本給相当額で、その上に時間外対応分、賞与の月割り負担が乗ると考えると対応関係がつかみやすくなります。

特に見落とされやすいのが賞与相当です。
社員エンジニアをSESで稼働させる会社では、月額見積の中に、年2回支給する賞与や評価反映分を月次で按分して織り込むことがあります。
そのため、見積書上で月額100万円に見えても、その全額がその月の給与になるわけではありません。
給与、残業代、賞与相当を切り分けて考えないと、「本人報酬の割に高い」と誤読しやすくなります。

日本の総雇用コストは、ベース給与の130〜140%が目安です。つまり、基本給だけを見て単価の妥当性を判断すると、雇用側の実負担を過小評価します。

法定福利費・通勤交通費

給与の次に大きいのが、法定福利費と通勤交通費です。
法定福利費には、社会保険料などの会社負担分が入り、見積書では「福利費込み」と一行で処理されることも少なくありません。
ただ、この書き方は後から解釈が割れやすく、実務では火種になりやすい項目です。
福利費込みとだけ書かれた見積が、契約後に交通費や一部保険負担を別建て請求する流れに変わり、調整がこじれたケースは複数ありました。
費目名だけでなく、何を含み、どう算定したのかまで記載させたほうが、紛争の芽を早い段階でつぶせます。

通勤交通費も同じです。
常駐前提のSESでは、定期代や実費精算分を月額単価に含める会社と、別請求に分ける会社があります。
ここが曖昧だと、出社頻度が増えた局面で追加費用の扱いがぶれます。
とくに東京圏の常駐案件では、交通費の扱いだけで月次の実額に差が出るため、単価比較をするなら本体単価と交通費の関係を切り離して読む必要があります。

見積の読み方としては、給与本体の外側に法定福利費（社会保険等）と通勤交通費が積み上がる構造です。
発注企業から見るとどちらも「人に付随する費用」ですが、前者は雇用維持のための制度負担、後者は就業条件に伴う実費で性質が異なります。
この区別が曖昧な見積は、価格交渉の場では一見安く見えても、運用段階で総額が膨らみやすくなります。

採用・教育・設備コスト

SES単価には、稼働中のエンジニア本人に直接払われる金額だけでなく、将来の供給を維持するためのコストも含まれます。
代表例が採用費、教育費、PCや設備費です。
発注側から見ると間接的な費目ですが、SES会社にとっては継続的に人材を確保し、案件へ投入できる状態を保つための原価です。

採用費には、求人媒体、紹介料、採用担当の工数などが含まれます。
1人を採用して終わりではなく、待機期間や立ち上がり期間も含めて回収していく構造なので、現場にアサインされている1名の見積にも一定の按分が乗ります。
教育費も同様で、入場前研修、資格取得支援、技術研修、情報セキュリティ教育などを月次で薄く配賦するのが一般的です。
AI案件や上流案件では、学習コストを個人任せにできないため、この部分が単価に反映されやすくなります。

設備費では、PC・ソフト等の設備費が典型です。
業務用ノートPC、開発ツール、ライセンス、セキュリティ対策、アカウント管理、端末更新費用などがここに入ります。
発注側からは見えにくいものの、企業貸与PCや各種SaaSの契約を前提にした体制では無視できません。
見積に設備費が入っていない場合、実際には管理費側に含めていることもあるため、どこで負担しているのかを見ないと比較がずれます。

このあたりは、費目の有無よりもどう按分しているかで差が出ます。
採用費を短期回収する会社は単価が上振れしやすく、教育費を会社負担で厚く持つ会社は短期の価格競争では不利でも、継続案件では品質が安定しやすい傾向があります。
単価が安いか高いかだけでなく、どの費目をどこに持たせているかまで読むと、見積の性格が見えてきます。

営業管理費・会社マージン

見積単価の中で誤解されやすいのが、営業管理費と会社マージンの違いです。
どちらも「会社側の取り分」に見えますが、中身は同じではありません。
営業管理費は、営業担当の人件費、契約管理、請求処理、労務管理、現場フォロー、待機調整、拠点運営といった間接費です。
利益ではなく、案件を回し続けるための運営コストに近い位置づけです。

一方の会社マージンは、発注額から給与、福利費、採用教育、設備、営業管理費などを引いた残りで、営業利益やリスク吸収原資にあたります。
ここには待機リスク、離任リスク、未稼働期間、回収不能リスクへの備えも含まれます。
単に「中抜き」と片づけると構造を読み違えます。
とくに社員雇用型のSESでは、案件が切れても雇用コストが止まらないため、一定のマージンがないと供給体制そのものが維持できません。

ただし、見積書では営業管理費と会社マージンがまとめて「管理費」や「諸経費」に入っていることがあります。
この書き方だと、必要な間接費と利益水準の区別がつかず、価格交渉の論点がぼやけます。
実務では、営業管理費（間接費）と会社マージンが分かれている見積のほうが妥当性を判断しやすく、過度な上乗せも見抜きやすくなります。
商流が深い案件では、この部分に複数社の取り分が重なり、総額が膨らみやすいのも特徴です。

モデルケース：100万円/月の内訳サンプル

月額100万円のSES見積をモデルケースとして置くと、発注額は次のように分解できます。
ここでの金額は固定フォーミュラではなく、あくまで見積の読み方をつかむためのモデルです。

実務上の感覚としては、顧客支払い100万円に対して、給与相当が50万円前後に置かれ、そこから法定福利費、採用教育、設備、営業管理費を差し引いた残りが会社マージンになる構図が多く見られます。
還元率の公開例では幅がありますが、発注側の見積として読むときは、給与だけでなくその周辺コストを足して初めて比較の土台がそろいます。

このモデルを使うと、見積書の読み違いも減ります。
たとえば「本人に50万円程度なら、残り50万円はすべて会社利益だ」と見るのは誤りで、実際には社会保険、賞与按分、採用教育、端末、営業管理の積み上げが先にあります。
逆に、福利費や管理費の説明が薄いのにマージンだけ厚い見積は、価格の透明性に欠ける可能性があります。
見積単価の妥当性は、単価水準そのものより、費目の分解と算定根拠がそろっているかで見えてきます。

契約形態別の費用比較

4形態の比較表

外部人材の調達コストは、単価そのものよりも何に対して報酬を払う契約なのかで見え方が変わります。
SESと派遣はどちらも月額で並べて比較されがちですが、法的な立て付けと運用ルールは別物です。
とくにAI開発や基幹系のように、要件が動きやすい案件では、契約形態の選択がそのまま費用のブレ幅と管理負荷に直結します。

SESは準委任が一般的で、報酬は成果物ではなく作業時間や工数に対して発生します。
現場では月額単価で語られることが多く、中心帯は80万〜120万円/人です。
フリーランスとの直接契約は中間マージンを抑えやすい一方、候補者選定、契約管理、情報セキュリティ管理、稼働フォローまで発注側で持つ範囲が広がります。
請負は成果物完成が報酬基準なので、要件が固まっていれば総額を設計しやすく、逆に途中変更が多い案件では追加見積が増えやすい構造です。

実務で混同されやすいのが、SESと派遣の違いです。
SESは常駐していても発注側が直接指示を出す契約ではありません。
受託側の責任者を通じて業務を調整し、作業範囲や優先順位を合意して進める形が基本です。
派遣は派遣先に指揮命令権があるため、日々の業務指示を発注側が直接出せます。
現場のマネジメント自由度だけを見ると派遣のほうが扱いやすく見えますが、制度対応まで含めると検討軸は別になります。

請負は「完成責任」が乗るぶん、発注時点で要件を詰め切れているかが費用に直結します。
たとえば画面数、API本数、テスト範囲、受入条件が固まっていれば予算化しやすい一方、途中で仕様変更が続くと再見積が積み上がります。
AI関連では、学習データの状態や評価指標が走りながら固まるケースが多く、初期段階から請負に寄せると契約上の摩擦が起きやすい場面があります。

フリーランス/業務委託は、調達コストの見た目を抑えられる余地があります。
商流が浅くなるほど中間マージンの累積を避けやすいためです。
ただし、ここで削減できるのはあくまで仲介コストの一部で、発注側の手間が消えるわけではありません。
スキル確認、本人確認、NDA、持込PCルール、知財帰属、稼働レポート、離任時の引き継ぎまで自社で設計する必要があり、少人数の管理部門ではその負荷が表面化しやすくなります。

実際に、常駐現場で発注側の社員がエンジニアへその場で細かい口頭指示を出していた準委任契約を立て直したことがあります。
契約上はSESでも、運用は派遣に近い状態でした。
このときは、日次の口頭依頼をやめるのではなく、週次で「今週依頼する業務範囲」と「優先順位」を合意し、受託側リーダーがメンバーへ展開する形に整理しました。
あわせて、実施内容をレポート化して翌週の継続判断につなげたところ、現場のスピードを落とさずに運用の筋道が通り、追加費用の説明もしやすくなりました。
SESの費用比較では、単価表だけでなく、この運用設計まで含めて見ないと判断を誤ります。

ケース別の選び方

契約形態の選択は、単価の安さではなく、案件の不確実性、必要な管理権限、社内の受け入れ体制で決まります。
発注側が「誰に、何を、どの粒度で、どこまで直接コントロールしたいのか」を整理すると、費用の見方も揃います。

要件がまだ動く初期フェーズでは、SESか準委任型の業務委託が噛み合いやすい場面が多くあります。
AI導入のPoC、データ整備の立ち上げ、生成AI活用の要件定義のように、試しながら決める仕事は成果物を先に固定しにくいためです。
低稼働のアドバイザや上流支援なら、週1〜2日で20万〜40万円/月のレンジに収まることもあり、いきなりフルタイムのSESを入れるより小さく始められます。
ここでは「誰が判断するか」より「どこまで伴走してほしいか」が契約選定の軸になります。

一方で、社内PMや現場責任者が日々のタスクを細かく切り、優先順位も都度変える体制なら、派遣のほうが制度上の整合性が取りやすい局面があります。
たとえばヘルプデスク、運用監視、定型テスト、社内情シス支援のように、発注側の業務指示の比重が高い現場です。
SESで同じ運用をすると、費用は似ていても法的リスクの置き場所が変わります。
直接管理したいのにSESを選ぶと、契約上の建て付けと現場運用が衝突します。

請負が向くのは、画面、機能、納品物、受入条件が固まっていて、完成責任をベンダーに持たせたいケースです。
たとえば管理画面の追加開発、既存システムの機能改修、API連携の実装などは、成果物単位で区切ると予算化しやすくなります。
逆に、仕様変更が前提のプロジェクトで請負を選ぶと、変更管理の打ち合わせと追加見積に工数が吸われ、表面上の固定価格ほど運用は軽くなりません。

フリーランス/業務委託が向くのは、希少スキルをピンポイントで確保したいときです。
たとえばPythonでのML実装経験者、AWS上のMLOps設計者、OpenAI APIやAzure OpenAI Serviceを扱ったことのある技術者を短期間で入れたい場面では、直接契約の機動力が生きます。
生成AIやMLOpsのような希少領域では、月額が120万円超に乗る案件も珍しくありません。
ここで見るべきなのは単価の高低だけではなく、その人材が不足している期間に発生する機会損失まで含めた総コストです。

発注側の判断としては、次のように整理するとぶれません。
要件が未確定で、中長期にチームへ溶け込む支援が必要ならSES。
発注側が直接業務指示を出して日々管理したいなら派遣。
成果物を明確に切り出せるなら請負。
希少スキルを必要期間だけ確保したいならフリーランス/業務委託、という切り分けです。
費用比較の表は出発点として有効ですが、実務上は「誰が指示を出すか」と「何に対して報酬を払うか」の2点が揃ったときに、はじめて比較が機能します。

SES費用を左右する要因

スキル・工程と単価の関係

同じSESでも単価が割れる最大の理由は、経験年数だけでなく、どの工程を担うかで発注側が買っている価値そのものが変わるからです。
実装要員を補充するのか、要件定義や基本設計を任せるのかで、求める判断力も責任範囲も違います。
担当工程が下流から上流へ移るほど、単価は一段上がるのが実務上の基本線です。

工程で見ると、要件定義・基本設計のような上流工程は、実装・テスト・運用より単価が上振れやすい傾向があります。
発注側の事業要件を技術要件に翻訳し、関係者調整まで含めて前に進める人材は代替が利きにくいためです。
現場感覚では、同じ技術スタックでも上流を担える人材は、実装中心の人材に比べて月額で10万〜30万円ほど高くなることが珍しくありません。
特に要件が曖昧な立ち上げ期ほど、この差がそのまま見積に出ます。

経験年数も当然効きますが、年数だけでは足りません。
5年の経験があっても、担当がテスト固定なのか、基本設計と顧客折衝まで担ってきたのかで市場評価は変わります。
実務上は「何年目か」より「どの工程を一人称で回せるか」のほうが、単価の説明力を持ちます。
要件定義、設計、実装、テスト、運用のどこを任せる前提かが曖昧な見積は、あとから割高にも割安にも見えてしまいます。

専門スキルも単価差を広げます。
AWSやAzureを使ったクラウド設計、Kubernetesを含む運用基盤、ゼロトラストや脆弱性対応を含むセキュリティ領域は、一般的なWeb実装より単価が上に寄りやすい分野です。
AI領域ではその傾向がさらに強く、生成AI、MLOps、データ基盤をまたいで扱える人材は、単なるモデル実装だけでなく、評価指標設計、推論基盤、権限制御、運用監視まで見られるため、月額が120万円超に乗るケースが出てきます。
人材の希少性に加え、要件そのものが複雑だからです。

実際の案件設計では、上流を高単価人材に寄せ、下流を中級層へ切り替えるだけで総額の整え方が変わります。
要件定義を別枠の上級人材で短期集中させ、月額120万〜150万円のレンジで設計方針と論点整理を終わらせたうえで、その後の基本設計から実装を月額90万〜110万円の中級人材へ引き継いだ案件では、品質を落とさず予算の膨張を抑えやすい構成になりました。
上流を安く済ませようとして要件が曖昧なまま進むと、後工程の手戻りで結局高くつくため、単価は「高い人を入れるか」ではなく「どの工程に高い人を置くか」で見るほうが実態に合います。

要因ごとの強弱を整理すると、図表では「経験年数」「工程」「専門スキル」を軸に、影響度を高・中・低で並べるマトリクスにすると判断しやすくなります。
とくに上流工程と希少スキルは高、経験年数は工程実績とセットで見たときに高、という並びになります。

地域・勤務形態（常駐/リモート）の影響

勤務地も単価差を生みます。
東京と地方では案件の種類、顧客の予算帯、求められる調整負荷が違うため、同じスキルでも価格が揃いません。
東京圏は金融、基幹刷新、SaaS、データ基盤の案件が集まりやすく、顧客折衝や関係部署との調整が多い案件が多いため、地方案件より10〜20%ほど高いプレミアムが乗る場面があります。
勤務地は単なる通勤場所ではなく、案件難易度と期待役割の代理変数として働いています。

常駐かリモートかも無視できません。
常駐比率が高い案件では、現場調整、会議同席、セキュリティ制約への対応、通勤拘束といった運用コストが乗るため、フルリモート案件より単価が上がることがあります。
とくに機密データを扱うAI案件や、社内システムとの接続制約が強い案件では、常駐前提そのものが人材母集団を狭めるため、価格交渉力は発注側から見て弱くなります。

一方で、リモート比率が上がれば常に安くなるわけではありません。
フルリモートでも、要件定義やアーキテクト、生成AIの実運用設計のように代替しにくい職種なら単価は下がりません。
下がるのは、勤務地制約が外れたことで候補者層が広がり、地方人材や遠隔地人材を混ぜられるときです。
つまり、勤務地と常駐/リモート比率は単独で見るより、「その条件で人材プールがどこまで広がるか」で見たほうが実務に合います。

発注設計では、全員を同じ勤務形態にそろえる必要もありません。
顧客折衝が多い要件定義や初期設計だけ常駐比率を高め、その後の実装・テストはリモート比率を上げる構成にすると、必要な場面だけ東京単価と常駐コストを受け入れ、それ以外を抑える形にできます。
とくにAI導入では、業務ヒアリングやデータ確認の初期フェーズは対面の密度が効き、その後の実装や検証は遠隔でも進むことが多いため、この切り分けが効きます。

商流・契約期間・稼働率の影響

見積書で見落とされやすいのが、エンジニア本人のスキル以外に、商流、契約期間、稼働率が単価へ与える影響です。
同じ人材でも、元請に近い一次商流なのか、多重商流の下流なのかで、発注額は変わります。
商流が深くなるほど中間マージンが積み上がるため、発注側の支払総額は上がりやすく、同額を払っても現場に届く還元額は薄くなります。
一次で10〜30%、二次・三次で各社10〜20%程度のマージンが乗る構造は、SES単価の読み方として押さえておきたい部分です。

この差は、単に「高い・安い」では片づきません。
商流が深い案件は、情報伝達の遅れ、条件変更時の再交渉、責任分界の曖昧さも起きやすく、結果として追加コストが出やすくなります。
反対に商流が浅い案件は、同じ予算でもスキルの高い人材を当てやすいか、同等スキルをより低い総額で確保しやすくなります。
見積を比較するときは、月額だけでなく「誰が元請で、どこまでが再委託か」を見ないと、価格差の理由が読めません。

契約期間も単価交渉に効きます。
短期案件は立ち上がり負荷、離任リスク、次案件の空き期間リスクを織り込むため、月額は強気になりやすい傾向があります。
反対に、6ヶ月超の中長期契約では、単価据え置きか微減での交渉余地が出やすくなります。
発注側から見ると、長期で縛れば何でも安くなるわけではありませんが、アサインの安定性を提供することで、ベンダー側も営業コストと空きリスクを下げられるからです。

稼働率も同様です。
週5日のフルアサインだけでなく、0.6人月や週3日相当の契約では、月額は単純比例にならないことがあります。
フルタイム前提の人材に部分稼働を求めると、空き時間の埋め合わせが難しくなるため、稼働率が下がっても時間単価はむしろ上がることがあります。
業界でよく使われる精算幅140〜180時間は、月の標準的な160時間を中心に前後20時間のバッファを持たせた設定です。
週3日換算なら84〜108時間が一つの目安になります。
こうした時間設計が入ると、見た目の月額だけでは割安かどうか判断できません。

稼働率の低いアサインは、PoCやアドバイザ契約では機能します。
生成AIの要件整理や評価観点の設計を、週1〜2日で入る上流人材に任せる形なら、月額20万〜40万円のレンジで成立することがあります。
ただし、この価格で買っているのはフルタイム開発力ではなく、論点整理や意思決定の質です。
稼働率が低い案件ほど、「何を持ち帰ってもらう契約か」が単価の説明になります。

図表化するなら、要因×影響度マトリクスが有効です。
工程、専門スキル、商流は高、勤務地と常駐/リモート比率は中、契約期間と稼働率は条件次第で中、という整理にすると、同じSESでもなぜ価格差が出るのかを一枚で把握できます。
発注側にとっての実務上の論点は、単価の高低そのものではなく、どの要因で上がっているのかを分解できるかどうかです。

見積もり・契約で失敗しない確認ポイント

契約形態と法的注意点

見積書や基本契約書で最初に見るべきなのは、契約形態が準委任契約なのか、派遣なのか、請負なのかが明記されているかです。
SESでは準委任契約が一般的ですが、名称だけ準委任で、実態は発注側が日々の作業指示を直接出している形だと、契約と運用がずれます。
このずれがあると、価格の妥当性以前に、指揮命令権の所在が曖昧になり、現場運営そのものが不安定になります。

実務上は、誰が業務指示を出すかを起点に見ると判断しやすくなります。
準委任であれば、発注側は業務の目的や優先順位を伝え、ベンダー側の責任者がメンバーへ指示を落とす形が基本です。
派遣であれば発注側が直接指揮命令します。
請負であれば、完成すべき成果物と受入基準が中心で、日々の作業管理は受託側にあります。
ここが曖昧なまま常駐が始まると、契約書上は準委任でも、現場では発注側のマネージャーが個別にタスクを配り、勤怠の細部まで直接管理する運用になりがちです。

その状態は偽装請負リスクを招きます。
リスクは書類上だけでなく、現場の設計から生まれます。
たとえば、発注側がエンジニア本人へ直接チケットを割り当てる、日次で個別指示を出す、発注側社員と同一の承認経路で勤怠や評価を扱う、席配置や社内アカウント権限が自社社員と区別されていない、といった運用は危険信号です。
準委任で受けるなら、連絡窓口はベンダー側責任者に一本化し、レビュー依頼、作業報告、受入判定の流れも契約形態に合わせて組む必要があります。

この論点は、法務だけの話ではありません。
現場でありがちなのは、立ち上がりを急ぐあまり、契約形態の整理より先にJiraSlackGoogle Workspaceの権限付与と会議招待を進めてしまうケースです。
すると、本人に直接依頼が飛ぶ構造ができあがり、数週間で実態が固定されます。
契約設計のポイントとして、アカウント権限、依頼経路、日報や週報の提出先、受入の責任者までを最初に定義しておくと、後から運用をねじ戻す負担が減ります。

精算幅・業務範囲・変更管理の確認

準委任の見積レビューでは、単価の次に精算幅の読み方で差が出ます。
業界でよく使われるのは140〜180時間の月間時間幅で、月の標準的な160時間を中心に前後20時間のバッファを持たせた設計です。
見積書に「月額単価」とだけ書かれていても、精算幅があるのか、固定精算なのか、超過と下限未達の計算式が何かで、実際の支払額は変わります。

見ておきたいのは、上限超過時の追加単価、下限未達時の控除単価、計算方式が上下割なのか中間割なのか、みなし時間の扱いがあるのか、固定精算にできる余地があるのかです。
同じ月額でも、下限の計算が厳しい契約は、祝日が多い月や立ち上がりが遅れた月に受託側の不満が出やすく、反対に上限超過の精算が弱い契約は発注側の予算超過につながります。

以前、稼働の波が読みにくい案件で下限未達が連続した際、受託側と合意のうえで実務的に下限を実質的に8割程度に相当する保障条項を設けた事例があります。
こうした下限保障は当事者間の個別合意によるもので、公開された標準文言や判例が十分にあるわけではありません。
業界慣行として断定的に扱わず、事例としての合意であることを明記するか、代替策（みなし時間の設定や柔軟な調整メカニズム）を検討する旨を明示してください。

あわせて、業務範囲の明確化も外せません。
準委任は時間と知見の提供に対価を払う契約ですが、だからといって「何でも対応」では運用できません。
どの工程を担うのか、成果物があるなら何をどこまで出すのか、品質責任や障害対応の範囲はどこまでかを見積段階で定めておかないと、後から追加作業が雪だるま式に増えます。
たとえば、要件整理だけの想定だったのに、検証コード作成、ベンダー調整、運用手順書作成まで入ると、同じ単価では釣り合いません。

そのため、変更時の手続きもセットで見ます。
実務ではCR（変更管理）を設け、作業追加が発生したときに、工数増、単価改定、稼働率変更のどれで吸収するのかを決めておく形が安定します。
口頭で「ついでにお願いします」が積み重なる案件ほど、月末に請求差異ともめます。
業務範囲と変更管理は、価格表より先に原価を決める部分です。

商流・再委託・交代条件の確認

見積の比較で見落としやすいのが、商流と再委託有無です。
契約相手が実際にエンジニアを抱える会社なのか、一次受けなのか、さらにその先へ再委託する前提なのかで、価格だけでなく情報伝達の速度と責任の切れ目が変わります。
商流が深いほど、要件変更時の確認経路が増え、認識差分が入りやすくなります。

契約書では、再委託を認めるのか、事前承諾制なのか、何次まで許容するのかを明示しておくのが基本です。
発注側から見ると、再委託そのものが直ちに悪いわけではありません。
ただし、再委託先の管理責任、NDAやセキュリティ義務の引き継ぎ、個人情報に触れる範囲、事故時の報告経路が決まっていない再委託は、単価差以上の管理コストを生みます。
とくにAI案件では、学習用データ、ログ、業務文書の取り扱いが絡むため、誰がどのデータに触れるのかを商流ごとに分解しておかないと統制が効きません。

人の交代が起きたときの条件も、価格交渉と同じくらい効きます。
ここで見るのは交代条件です。
スキルミスマッチがあった場合に、どの程度のリードタイムで交代候補を出せるのか、引き継ぎ期間の費用はどうなるのか、交代による追加費用の有無はどうか、初月や試用的な立ち上がり期間の扱いはどうなるのか、といった点です。
現場では「合わなければ替えられる」と考えがちですが、条件が契約書に落ちていないと、交代のたびに費用と責任分担を再交渉することになります。

発注実務では、交代時の品質低下も織り込んでおく必要があります。
とくに要件定義、データ設計、顧客折衝を担う人材は、交代した瞬間にゼロから代替できません。
見積が安く見えても、交代時の空白期間やキャッチアップコストが発注側負担なら、総額では高くつくことがあります。
交代条件は、単に「交代可能」と書かれているかではなく、いつ、誰の費用で、どの水準の代替人材が出るかまで読めるかが分かれ目です。

セキュリティ・NDA・知財・解約条件

契約の後半条項で軽視されやすいのが、NDA、情報セキュリティ、知財、解約条件です。
ここはトラブルが起きたときに初めて効く条項ですが、見積時点で読み込んでおかないと、着任後に運用が止まります。

NDAでは、秘密情報の範囲、目的外利用の禁止、第三者提供の制限に加え、持込PCの可否、端末暗号化、ウイルス対策、ログ取得、資産台帳への登録、外部記録媒体の扱い、個人情報へのアクセス条件まで見ておきます。
常駐案件でも、会社貸与PCなのか持込PCなのかで準備期間が変わります。
Microsoft IntuneのようなMDM管理や、端末証明書の配布が前提の現場では、セキュリティ要件を満たせない人材は着任できません。
見積段階でここが抜けると、アサイン可能と聞いていた人材が直前で入れない、という事態が起きます。

知財の扱いも、準委任では見誤りやすい論点です。
SESのような準委任契約では、通常は時間と役務の提供が中心で、請負のように成果物の権利が当然に発注側へ移る構造ではありません。
つまり、設計書、スクリプト、プロンプト資産、検証コード、運用手順書などをどこまで成果物とみなすのか、著作権や利用許諾をどう整理するのかを契約で切り出す必要があります。
とくにAI導入では、プロンプトテンプレートや評価データの整理物が資産化しやすいため、成果物定義が曖昧だと後で再利用範囲でもめます。

解約条件も費用に直結します。
契約更新の単位、途中解約の予告期間、月中終了時の日割り精算、最低利用期間の有無、解約時の引き継ぎ義務とその対価が明記されているかで、撤退コストは変わります。
準委任は柔軟に見えますが、実際には月単位更新と予告期間の組み合わせで、止めたい月にすぐ止められないこともあります。
PoCや短期検証では、開始条件より終了条件のほうが収支に影響する場面もあります。

見積レビューで使うなら、少なくとも次の項目が一枚で確認できる状態が望まれます。

• 契約形態が準委任・派遣・請負のどれか明記され、実態の指揮命令系統と一致している

このあたりまで確認できている見積は、単価交渉の土台がぶれません。
逆に、契約条件が空白のまま月額だけで判断すると、発注後に調整コストが乗り、見積時点の安さが意味を失います。

コストを抑える現実的な方法

フェーズ分割と部分稼働の活用

コストを抑えるときに効くのは、いきなりフルタイムのSESを入れることではなく、どの工程に、どの稼働量で人を置くかを分けて考えることです。
とくにAI導入やデータ活用の案件は、最初の論点整理、データ棚卸し、評価指標の定義が曖昧なまま人月を積むと、実装前の手戻りで費用が膨らみます。

PoC段階では、週1〜2日の副業人材や業務委託を使い、月額20万〜40万円のレンジで仮説検証を進める設計が現実的です。
ここで求めるのはフル開発ではなく、テーマ設定、成功条件の言語化、簡易プロトタイプ、データの見立てです。
生成AIやMLOpsのように上振れしやすい領域でも、初期段階は「何を試すか」が固まれば十分なので、常時フル稼働の高単価要員を置く必要はありません。
効果が見えた後に、実装フェーズでSESへスケールするほうが、調達額と学習コストの両方を抑えられます。

実務では、PoCで必要なのは汎用的な開発力よりも、詰まる箇所を早く見抜ける専門性であることが多いです。
実際、データ準備だけを週1で担当する専門家を4週間だけ入れ、欠損の扱い、項目定義、前処理の順番を先に整えた結果、その後の開発が滞らず、全体の人月が約10%圧縮できたケースがありました。
要員を増やしたのではなく、前工程のボトルネックだけを低稼働で解消したことで、後続の実装メンバーの待ち時間と再作業が減った形です。
これはPoCを小さく始めるときの典型パターンで、部分稼働の使い方次第で総額が変わります。

スキル要件の最適化と役割分担

単価を下げる近道は、全員を安くすることではありません。
実務で効くのは、高単価人材を必要な場面だけ短く使い、実装と運用は中級人材へリレーする設計です。
要件定義、アーキテクチャ設計、モデル選定、セキュリティ方針の整理は、上級人材に任せたほうがむしろ安くつく場面があります。
ここを経験不足の体制で始めると、後で設計変更が重なり、安い単価で積んだ人月が無駄になります。

たとえば、上流だけ月額120万〜200万円以上のレンジに入る人材を短期投入し、設計方針が固まった後は、実装や結合、運用設計を中級層へ受け渡す形です。
発注側から見ると、チーム全体の加重平均単価を下げながら、最初の精度だけは確保できます。
AI案件では、プロンプト設計やモデル評価よりも、実際には既存システム連携、ログ設計、運用監視、権限制御に工数が乗ることが多いため、全期間を上級者で埋める必要はありません。

ここで前提になるのが、必要スキルの明確化です。
Must、Should、Won’tで切り分けておくと、見積の段階で「生成AIの経験が必須なのはどこまでか」「AWSやAzureの運用経験が必須なのか、類似環境で代替できるのか」「データ分析とアプリ実装を同一人物に求めるのか」が整理できます。
要件が曖昧なまま広く募集すると、過剰なスキルセットを持つ高単価人材ばかりが候補に並び、単価が自然に上がります。
役割を分ければ、必要なところにだけ高単価を当てられます。

地域・リモート・商流の見直し

調達コストを押し上げる要因のひとつが、東京圏前提の採用と、多重商流のまま比較してしまうことです。
すでに見た通り、東京には単価プレミアムが乗りやすく、地方やリモート併用のほうが抑えやすい構造があります。
ここで見るべきなのは、単に「地方のほうが安い」という話ではなく、どの業務が出社を必要とし、どの業務はリモートで品質を保てるかという切り分けです。

要件定義の初期ワークショップ、顧客部門との擦り合わせ、セキュア環境での検証などは出社比率を上げる一方、実装、テスト、データ整備、運用ドキュメント作成は地方人材やフルリモート人材を組み込みやすい領域です。
出社頻度を週単位や月単位で設計し、成果レビューのタイミングを固定すると、移動制約による単価上振れを抑えながら品質を落とさず進められます。
常駐前提で募集するより、出社が必要な工程だけを明示したほうが、候補者の母集団も広がります。

商流も同じです。
直契約や一次請けを優先すると、中間マージンの積み上がりを避けやすくなります。
SESでは商流が深くなるほど各段で管理費が乗り、最終的な総額が膨らみます。
比較時は「単価が安いか」だけでなく、管理費がどこまで可視化されているかを見るべきです。
一次経由で管理責任が明確な案件と、多重商流で責任が分散した案件では、見た目の月額が近くても、交代時や品質問題の調整コストが違ってきます。
6ヶ月以上のまとまった期間で発注できるなら、供給側も稼働計画を組みやすくなるため、単価調整の余地が出やすいのもこの局面です。

契約設計でのコスト最適化

単価そのものより先に効くのが、スコープの確定と精算条件の設計です。
Must、Should、Won’tで対象範囲を切り、やらないことを先に決めておくと、曖昧な追加作業が減ります。
AI案件では「簡易な評価環境だけ作るつもりが、ダッシュボード整備や本番監視まで含まれていた」といった膨張が起きやすく、ここが人月超過の起点になります。
必要スキルの明確化とセットでスコープが締まると、見積もりの精度が上がり、不要な予備工数も乗りにくくなります。

準委任では、精算幅も実務上の交渉材料になります。
フルタイム案件でよく使われる140〜180時間は、月間160時間を中心にした業界慣行です。
発注側としては、この幅を当然視するのではなく、実態に合った稼働量なのかを見る必要があります。
週3日相当なら、フルタイム基準をそのまま当てるのではなく、84〜108時間のように按分した設計が筋です。
スコープが明確で稼働変動が小さい業務なら、広い精算幅より固定月額や狭い時間幅のほうが総額を読みやすくなります。

契約期間のまとめ方も単価に影響します。
短い更新を繰り返すより、6ヶ月以上の前提で発注したほうが、供給側は要員確保と教育コストを回収しやすくなり、条件交渉がしやすくなります。
もちろん長期化そのものが目的ではなく、上流の高単価人材を短く、実装・運用の中級人材を必要期間で押さえる形に分けることが前提です。
調達設計が整うと、単価を無理に削らなくても、総額の着地を下げる余地が生まれます。

まとめ

調達判断では、まず相場感を起点にしつつ、自社が買いたいのが「稼働」なのか「成果」なのか「直接管理」なのかを切り分けることが先です。
中長期の常駐補強ならSES、成果物が明確なら請負、現場で直接指示したいなら派遣、限定スキルをピンポイントで押さえるならフリーランス直契も候補になります。
見積書は総額だけで見ず、給与・福利費・採用教育・設備・管理費・マージンの費目定義と算定根拠が通っているかで判断すると、割高な提案を見抜けます。

初期判断フローと次のアクション

最初に必要人数と期間を人月で置き直し、PoCと本番を分けて考えると判断がぶれません。
そのうえで候補ベンダーを、単価、精算幅、契約形態、商流の浅さで横並びにし、同じ前提で比較します。
SESだけで埋める前提にせず、上流だけ高単価人材、検証は低稼働の業務委託、本番は請負併用という組み方まで含めて設計すると、総額と実行性の両方を整えられます。