SES単価の相場【2026年版】スキル別月額・単価の内訳と発注前チェックリスト

最初に結論を三行で示す。

• 2026年のSES単価は、市場で一般に言われる水準として概ね テスターの月35万円からPM・AI/MLの月150万円 のレンジに収まり、緩やかな上昇圧力が続いている。
• ただし「SES単価」を直接集計した公的統計は存在しない。世に出回る単価表はすべて供給側（SES・フリーランス各社）が作った目安であり、鵜呑みにせず公的な給与統計から逆算して妥当性を検証すべきものだ。
• 発注側にとって本当に重要なのは相場表の数字ではなく、「払った月額のうちいくらが本人に届くのか（単価の内訳）」「安い提案の裏で何が起きているのか」「契約書のどこを見れば偽装請負や中抜きを避けられるのか」という判断の型である。

下表は本記事で扱う相場レンジの早見だ。根拠と読み方は本文で一つずつ検証していく。

なぜ2026年の今、単価を見直す必要があるのか。経済産業省が2019年に公表した「IT人材需給に関する調査」（みずほ情報総研への委託調査）は、IT需要の伸びが高位・生産性上昇率が低位となる「高位シナリオ」で2030年に最大約79万人のIT人材が不足すると試算しており、この構造的な人材不足は2026年時点でも解消されていない。加えて、内閣官房・公正取引委員会が2023年11月に打ち出した労務費転嫁の方針（公正取引委員会 パートナーシップによる価値創造のための転嫁円滑化）以降、SES企業側からの単価改定（値上げ）要請は商慣行として定着した。「昨年と同じ単価で更新できる」という前提はもう置けない。だからこそ、相場と内訳の両方を今のうちに掴んでおく価値がある。

この記事を読むべき人

• SES・準委任でエンジニアを迎え入れようとしているが、提示された単価が妥当か社内で判断できない経営者・事業責任者
• 相見積もりで単価にばらつきがあり、「なぜこの会社は20万円安いのか」を説明できないまま契約しそうな決裁者
• すでにSESで人を入れているが、成果が出ている実感がなく、更新・単価改定の可否を迷っている担当者
• 社内にITの目利き（強い情シス）がおらず、発注の失敗を避けたい年商1〜10億円規模の企業

逆に、エンジニア本人が自分の手取りや単価を上げる方法を探しているなら、本記事は発注側の視点で書かれているため向かない。ここでは「払う側がどう損を避けるか」だけを扱う。

---

目次

1. SES単価の相場一覧（役割別・経験年数別）と公的統計での検証
2. 技術スタック別の単価相場
3. 相場表を鵜呑みにしてはいけない3つの理由（相場の読み方）
4. 単価の内訳——あなたが払う80万円はどこに消えるのか
5. 多重下請けの見抜き方——商流を文書で確認する
6. 経営者が知らない落とし穴——「安い提案」の裏側
7. SES（準委任）vs 請負 vs 派遣の判断軸
8. SES単価を左右する5つの要因
9. 単価交渉のポイント
10. 発注前チェックリスト（面談・契約書）
11. まとめ
12. FAQ
13. GXOに相談すべきタイミング

---

1. SES単価の相場一覧（役割別・経験年数別）と公的統計での検証

まず市場で一般に言われる水準を、役割と経験年数で整理する。繰り返すが、これは公的統計ではなく、SES・フリーランス向けマッチングサービス各社の公開案件情報や業界慣行を突き合わせた目安である。

役割別・経験年数別の月額単価の目安

同じ役割でも経験年数で1.5〜2倍の差が出る。ここで多くの発注ガイドは表を出して終わるが、発注側が知りたいのは「この数字を信じてよいのか」だ。それは公的統計との照合で確かめられる。

この目安は公的な給与統計と整合するか

厚生労働省「令和6年賃金構造基本統計調査」の職種別データ（e-Stat 職種別 第5表、企業規模計・男女計）を見ると、

• ソフトウェア作成者（平均38.0歳）：きまって支給する現金給与額 月38.6万円、年間賞与110.7万円 → 年収換算 約574万円
• システムコンサルタント・設計者（平均41.4歳）：同 月48.1万円、年間賞与175.7万円 → 年収換算 約753万円

エンジニアの給与に、事業主負担の法定福利費（給与の約15〜16%）と会社の経費・利益を乗せると、中堅SEの月額65〜90万円という相場観は、この給与水準と矛盾しない。逆に言えば、この逆算から大きく外れる単価——たとえば「経験5年のSEを月40万円で」——は、給与水準から見て何かがおかしいと疑ってよい。実際の経験が浅いか、商流のどこかに無理があるか、スキルシートが盛られているかのいずれかだ。公的統計との照合は、発注側が唯一手にできる「客観的な物差し」である。 供給側が作った相場表を、供給側と無関係な統計で検算する——この一手間が、相見積もりの読み方を根本から変える。

なお、SESの人月単価とプロジェクト一括発注の費用感はまったくの別物だ。開発をまるごと外部に出した場合の概算を先に掴みたいなら、60秒の見積シミュレーションで規模感を把握してから読み進めると、「人を借りる」のと「成果物を買う」のとでどちらが安いかを比較しやすい。

セクションまとめ：SES単価は概ね35万〜150万円のレンジ。表は公的統計ではないが、賃金構造基本統計調査の給与から逆算するとレンジの妥当性を検算でき、外れ値は疑える。

---

2. 技術スタック別の単価相場

使う技術によっても単価は動く。需要と供給のバランスが単価に直結するからだ。以下も市場で一般に言われる水準の目安である。

プログラミング言語別の単価の目安（経験3年以上のPG/SE）

クラウド・インフラ別の単価の目安

発注側は、この表を「高い技術者を探すため」ではなく「技術選定がランニングコストを決める」という視点で読むべきだ。たとえば社内システムをRustで書けば、その後の保守要員の単価は恒常的に月90万円以上に張り付く。逆に、基幹システムと外部SaaSをつなぐだけなら、フルスクラッチではなくAPI連携で必要工数を抑える進め方で済ませたほうが、要求スキル帯も期間も下げられるケースが多い。AI/ML（Python）が月100万円を超える案件も珍しくないが、その前に「本当に自社に機械学習が必要なのか、要件は自動化やRPAで足りないのか」を切り分けるだけで調達単価は大きく変わる。ここを外部の目で見極めたいなら、AI開発の見積もり・導入可否の第三者診断を使うと、高単価人材を雇う前に「そもそも使えるか」を確認できる。単価表は採用の値札であると同時に、アーキテクチャ選定の値札でもある。

セクションまとめ：AI/ML（Python）、Go、Rust、Kubernetesが2026年の高単価帯。技術選定は開発時だけでなく保守フェーズの調達単価まで決めてしまうため、経営判断として扱う。

---

3. 相場表を鵜呑みにしてはいけない3つの理由（相場の読み方）

ここが、他社の相場ガイドが踏み込まない領域だ。単価表はそのまま使う道具ではなく、次の3点を割り引いて読む必要がある。

理由1：相場を作っているのは供給側だ

世に出回るSES単価表のほとんどは、SES企業・フリーランスエージェント・マッチングサービスが公開している。彼らにとって単価は「高いほうが望ましい」数字であり、相場が高めに提示されるインセンティブが構造的に働く。発注側がこの表を交渉の上限として使うと、供給側の希望価格を追認するだけになりかねない。だからこそ、第1章で示した公的統計からの逆算を「下側の物差し」として併用する。相場表を天井、給与統計から積み上げた金額を床として、その間で妥当性を判断するのが正しい読み方だ。

理由2：レンジの「幅」には意味がある

「SE 3年で65〜90万円」という25万円の幅は、単なる誤差ではない。この幅は、同じ肩書きでも中身がまったく違うことを示している。実装だけを速く回せるSEと、要件を発注者と詰めて設計まで落とせるSEでは、名前が同じでも価値が倍近く違う。発注側がやるべきは、幅の真ん中を取ることではなく、自社が必要としているのは幅のどちら側の人材かを先に定義することだ。「詳細設計から実装まで自走できる人」が要るのか、「指示された画面を実装できる人」で足りるのかを言語化しないまま単価だけ比べると、安いほうを選んで手戻りで高くつく。

理由3：単価は「相場」より「あなたの発注条件」で決まる

同じスキルの人材でも、商流の深さ・稼働場所・契約期間・業界要件で単価は上下する（詳細は第8章）。つまり相場表は出発点にすぎず、実際の見積りは自社が突きつける条件で変わる。発注側がコントロールできる条件（直請けを選ぶ、リモート可にする、長期契約にする）を整えれば、相場表の下限に近づけられる。逆に、条件を詰めずに「相場はいくら？」とだけ問うと、供給側は上振れした条件を前提に見積もる。

セクションまとめ：相場表は供給側が作った天井、給与統計は床。レンジの幅は人材の中身の差を意味し、実際の単価は自社の発注条件で決まる。表は鵜呑みにせず、床・天井・自社条件の三点で読む。

---

4. 単価の内訳——あなたが払う80万円はどこに消えるのか

SES単価の交渉力は「内訳を知っているか」でほぼ決まる。発注側が月80万円を払うとき、その金額は次のように分解される。

直請け（商流1層）の場合の試算

賃金構造基本統計調査のソフトウェア作成者の平均値（年収換算約574万円＝賞与込みで月割約48万円）を機械的に当てはめると、月額75万円で入る中堅SE 1名について、健全な直請けSES企業の内部構造はこう見積もれる。

健全な直請けSESなら、単価の7割強がエンジニア本人の人件費で、残り3割弱が会社の運営費と利益だ。この構造自体は正当で、「マージン＝中抜き」ではない。SES企業は採用・教育・案件が切れた期間の給与保証（待機リスク）を負っており、その対価がマージンに含まれる。マージンがあること自体を叩くのは筋違いで、問題になるのはマージンの「重ね取り」だ。

なぜこの試算を知っておくと交渉が変わるか

内訳を掴んでいると、見積りの読み方が一段深くなる。たとえば「月90万円のSEを、うちのグループなら月65万円で」という提案が来たとする。給与統計から積み上げた人件費だけで55万円前後かかるのに、65万円で提示できるということは、(1)本人の処遇が相場より相当低い（＝経験が浅いか、深い商流で処遇が削られている）、(2)営業・待機リスクを織り込まない薄利前提で回している、のどちらかだ。どちらも発注側にとってはリスクの前借りになる。内訳を知らなければ「安くてラッキー」で終わるところを、内訳を知っていれば「なぜ安いのか」を一次情報として問える。

セクションまとめ：直請けなら単価の約7割がエンジニア人件費で、マージンは正当なコスト。内訳を掴むと、安い提案の「安さの正体」を給与統計から逆算して問い詰められる。

---

5. 多重下請けの見抜き方——商流を文書で確認する

問題は商流が2層、3層と深くなる場合だ。あなたが払う80万円から、間に入る各社が営業手数料を差し引き、実際に働くエンジニアの所属会社に届く金額はどんどん目減りする。中間に入る1社あたりの手数料は、市場で一般に言われる水準で単価の5〜15%程度とされ、3次請け以降では現場エンジニアの処遇と支払額の乖離が深刻になる。

これは業界の噂話ではない。公正取引委員会が2022年6月に公表した「ソフトウェア業の下請取引等に関する実態調査報告書」は、ソフトウェア業の多重下請構造において、買いたたきや仕様変更への無償対応要求といった下請法上の問題が生じている実態を、資本金3億円以下の約2万1000社への調査を通じて公式に指摘している（※中間手数料の具体的な料率は本記事が示した市場相場であり、同報告書が数値を断定したものではない）。

発注側にとっての実害

1. 同じ支払額で低いスキルの人材しか来ない：エンジニア本人に届く処遇が低いため、優秀な人材は深い商流の案件を避ける。結果、あなたは80万円を払っているのに60万円相当の人材しか得られない。
2. 情報が伝言ゲームになる：要件・フィードバックが商流を経由するたびに劣化し、手戻りが増える。トラブル時の一次情報も遅れて届く。
3. 契約責任が曖昧になる：問題が起きたとき「どの会社が何に責任を持つのか」を辿れなくなる。

商流を確認する具体的な質問

対策はシンプルで、契約前に商流を文書で確認するだけだ。口頭ではなく、提案書・契約書の記載として次を求める。

• 「今回のエンジニアの所属会社（雇用元）はどこですか。貴社の社員ですか、協力会社の方ですか」
• 「自社（発注者）から見て何次請けにあたりますか。間に入る会社をすべて教えてください」
• 「再委託は発生しますか。発生する場合、所属会社を開示してもらえますか」

これらに明確に答えられない、あるいは回答を渋る会社とは契約すべきでない。商流の透明性は、それ自体が発注リスクの尺度になる。逆に、自社が直接雇用している社員を出す会社や、一次請けまでで完結する会社は、この時点で説明が明快だ。

なお、SES費用を含むIT投資全体が売上規模に対して適正かどうかは、業界別のIT予算・売上高比率ベンチマークで確認できる。単価の適正さ（1人あたりが妥当か）と総額の適正さ（会社の身の丈に合っているか）は別問題で、経営としては両方を押さえたい。

セクションまとめ：多重下請けの中抜きは公取委の実態調査でも指摘される実害。防御策は「所属会社・何次請けか・再委託の有無」を契約前に文書で確認すること。答えを渋る会社は避ける。

---

6. 経営者が知らない落とし穴——「安い提案」の裏側

相見積もりを取ると、1社だけ明らかに安い提案が出てくることがある。「月55万円でSEを出せます」——相場より20万円安い。飛びつく前に、安さの理由を必ず特定すべきだ。安い提案の裏側は、構造的に次の3パターンのいずれかに集約される。

パターン1：スキルシートと実物が違う（スキルミスマッチ）

スキルシートに「Java開発5年」とあっても、中身が自社研修と保守運用の待機だった、というケースは珍しくない。SES業界ではスキルシートの「盛り」が構造的に起きやすい。営業は案件を決めないと売上にならず、発注側にスキルを見抜く力がないと分かれば、経歴は楽観的に書かれる。

対策は面談で、経歴書のプロジェクトについて「あなた自身は何を担当し、何を判断したのか」を具体的に聞くことだ。本当に手を動かした人は、詰まった箇所や設計の迷いを具体的に語れる。語れないなら、その経歴は本人のものではない可能性が高い。

パターン2：深い商流の人材が出てくる（多重下請け）

前章の通り、安い単価で出せるのは「エンジニア本人の処遇がさらに低い」からという場合がある。目先の単価は安くても、品質低下・手戻り・早期離脱で総コストは高くつく。単価の安さと商流の深さは、必ずセットで確認する。

パターン3：契約形態にリスクが埋まっている（偽装請負）

SESは通常、準委任契約で提供される。準委任では、発注者がエンジニアに直接業務指示を出すことは法律上できない。指揮命令の実態があれば、厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準（昭和61年労働省告示第37号）」に照らして偽装請負（実態としての無許可の労働者派遣）と判断されるリスクがあり、これは受注側だけでなく発注側の法令違反として問われ得る。厚労省は具体的な判断例を37号告示に関する疑義応答集として公開している。

ここは他社の相場記事がほとんど触れない、発注側にとって最も重い落とし穴だ。多くのSESガイドは偽装請負を「エンジニア側の待遇問題」として扱うが、実際には指揮命令をしてしまった発注者の側が責任を負う。「うちの社員が直接指示して使っていいですよ」という営業トークは、価格の安さではなくコンプライアンスリスクの警告として聞くべきだ。安さと引き換えに、実態は派遣なのに準委任の体裁でコストと法的義務を回避しているスキームに乗せられていないか、契約書と運用の両面で確認する。

こうした落とし穴は、提案書と見積書の段階である程度見抜ける。社内に目利きがいない場合は、契約前に提案・見積のセカンドオピニオン（発注前レビュー）として第三者にレビューさせるのが、最も安い保険になる。数百万円/年の契約に対して、レビューのコストは誤発注1件の損失より一桁小さい。

セクションまとめ：安い提案の裏側は「スキルシートの盛り」「深い商流」「偽装請負スキーム」の3パターン。特に偽装請負は発注側が責任を問われる。安さの理由を特定できないまま契約しない。

---

7. SES（準委任）vs 請負 vs 派遣の判断軸

「SESで人を入れるべきか、開発会社に請負で出すべきか」は、単価表よりも先に決めるべき経営判断だ。契約形態ごとの違いを整理する。

判断のコツは「自社に指揮者がいるか」と「仕様が固まっているか」の2軸で考えることだ。

• 仕様が固まっており、社内に開発を采配できる人がいない → 請負。完成責任を業者に持たせる。費用感は業務システム開発の費用相場と予算の立て方を参照。
• 仕様が動き続ける長期開発で、社内に技術リーダーがいる → **SES（準委任）**が機能する。
• 仕様も動くし、社内に指揮者もいない → ここが最も危険な状態だ。SESで人だけ集めても采配する人がいなければ稼働は空転し、請負に出せるほど要件も固まっていない。

3つ目の状態にある企業は、実際にはとても多い。この場合、人単位のSESではなく、要件整理から実装・成果の刈り取りまでをチームとして請け負う形態——GXOではFDE+（プロ人材によるチームアサイン・伴走実装）として提供している——のように、指揮者ごと調達する選択肢を検討すべきだ。単価は個別のSESより高く見えるが、「采配不在で空転する人月」を買い続けるより総額は安くなる。そもそも自社が今どのフェーズにいて、どの契約形態から始めるべきかを整理したいなら、DX・システム開発の進め方と費用感の相談で、要件の固め方から調達方式まで一緒に棚卸しするところから始めるのが早い。

社内エンジニア採用との比較検討は社内SEと外注のコスト比較と使い分け、技術判断だけを外部に頼る選択肢はIT顧問・技術顧問の費用と選び方も参考になる。

セクションまとめ：SES/請負/派遣は「買っているもの」が違う。判断軸は「社内に指揮者がいるか」×「仕様が固まっているか」。両方ないなら人単位のSESではなくチーム単位の調達を検討する。

---

8. SES単価を左右する5つの要因

同じスキルのエンジニアでも、以下の要因で単価は変動する（いずれも市場で一般に言われる傾向）。発注側が見るべきは「自分でコントロールできる要因はどれか」だ。

要因1：商流の深さ（コントロール可）

商流が深いほど中間手数料が累積し、「同じ支払額で来る人材の質が下がる」形で現れる。エンド直請けのSES企業を優先することで、発注側が最も効かせやすいレバーがこれだ。

要因2：稼働場所（コントロール可）

フルリモート可の案件は地方在住エンジニアまで供給源が広がるため単価を抑えやすい。フル出社（都心）指定は通勤圏の人材に限定され、単価が上振れしやすい。出社要件が本当に必要か、セキュリティ要件から逆算して見直す価値がある。

要因3：契約期間（コントロール可）

3ヶ月以下の短期は割高に、6ヶ月〜1年以上の長期は割安になりやすい。SES企業にとって長期稼働は待機リスクの軽減であり、ディスカウント交渉の正当な根拠になる。

要因4：業界・セキュリティ要件（ほぼ固定）

金融・医療・官公庁など、業界知識やセキュリティ要件（入館手続き、端末制限、クリアランス）が重い案件は単価が上乗せされる。ここは要件そのものなので下げにくい。

要因5：地域（縮小傾向）

東京を基準に、大阪・名古屋・福岡など地方都市はやや低いと言われてきたが、フルリモート案件の増加で地域差は縮小している。地方企業でも、実態は全国の単価水準で調達競争をしていると考えたほうが近い。

セクションまとめ：発注側がコントロールできるのは主に商流（直請けを選ぶ）・場所（リモート可）・期間（長期契約）の3つ。業界要件と地域は動かしにくい。この3レバーを整えるだけで相場レンジの下限に近づける。

---

9. 単価交渉のポイント

相場を把握したら、次は交渉だ。発注側が使える交渉材料を整理する。

ポイント1：相場レンジと公的統計を根拠に求める

本記事の相場レンジと、第1章の給与統計からの逆算を手元に置き、レンジを超える提示には「どのスキル・実績が上乗せの根拠か」を文書で求める。根拠を具体的に説明できる会社は信頼でき、説明できない会社はその時点で候補から外してよい。

ポイント2：商流を交渉の前提にする

「エンド直請けか」「エンジニアの所属会社はどこか」を確認し、3次請け以降なら所属会社に近い商流への切り替えを検討する。中間手数料の分だけ、同じ支払額でより良い人材を調達できる余地がある。

ポイント3：スキルシートは面談で裏を取る

単価はスキルの対価である以上、スキルの実在確認は交渉の一部だ。面談で本人に担当範囲と技術判断を語らせる。曖昧な回答しか得られない人材に相場上限の単価を払う理由はない。

ポイント4：複数名・長期で条件を引き出す

3名以上の一括調達や6ヶ月以上の契約は、SES企業側の営業コスト・待機リスクを下げるため、単価ディスカウントの正当な根拠になる。値切りではなく「相手のコスト構造を下げる代わりに単価を下げてもらう」交渉が長続きする。

ポイント5：値上げ要請には査定で応える

前述の労務費転嫁の方針以降、更新時の単価改定要請は増えている。全部拒否するのは現実的でなく、優秀な人材の離脱を招く。推奨は「一律回答をやめ、個人ごとに稼働実績で査定して応じる」ことだ。成果を出しているエンジニアの値上げは受け入れ、そうでなければ交代も含めて協議する。

なお、そもそもの予算枠の立て方は中小企業のシステム開発費用ガイドで詳しく解説している。

セクションまとめ：交渉材料は「相場レンジ＋公的統計」「商流」「スキルの実在確認」「発注ボリューム・期間」の4つ。値上げ要請には一律ではなく個人別査定で応える。

---

10. 発注前チェックリスト（面談・契約書）

契約直前に、このチェックリストを通してから判を押してほしい。

面談（スキル確認の場）で確認すべきこと

• スキルシート記載のプロジェクトで、本人が担当した範囲と自分で下した技術判断を具体的に語れるか
• 直近1年で実際に書いた/構築した技術は何か（「経験あり」と「今できる」は別物）
• 自社の業務ドメイン（業界・業務フロー）への理解度、または学習意欲
• コミュニケーション：質問の意図を汲んで答えているか、報告が構造化されているか
• 稼働開始可能日と、現案件の引き継ぎ状況（前案件を突然抜けてくる人材は自社でも同じことをする）

契約書で見るべき条項

• 契約形態：準委任か請負か派遣か。準委任なのに「発注者の指示に従う」等の指揮命令を前提とした文言がないか（偽装請負リスク）
• 精算条項：基準稼働時間（例：140〜180時間）と、超過・控除の単価計算式。超過単価だけ高く設定されていないか
• 単価に含まれる範囲：交通費・機材・ライセンス費が別建てか込みか
• 交代・離任の条件：エンジニア交代時の事前通知期間（最低1ヶ月は確保したい）と引き継ぎの取り決め
• 再委託の可否と開示：再委託を許すか、許す場合に所属会社の開示義務があるか（商流の透明化）
• 秘密保持・データの扱い：自社データへのアクセス範囲と、契約終了時の返却・消去
• 中途解約条項：プロジェクト中止時に何ヶ月分の支払い義務が残るか

このチェックリストを全て自社で判定できるなら、SES発注の失敗確率は大きく下がる。判定できない項目が残るなら、そこがあなたの会社の発注リスクだ。契約書と提案書を持ち込んで発注前に第三者へ相談するほうが、判子を押してから気づくより遥かに安い。

セクションまとめ：面談では「本人が語れるか」、契約書では「指揮命令・精算・交代・再委託・解約」の条項を確認する。自社で判定できない項目が残るなら契約前に第三者に見せる。

---

11. まとめ

2026年のSES単価相場と、発注側が押さえるべき要点を総括する。

• 相場表は供給側が作った目安。賃金構造基本統計調査の給与から逆算した「床」と併せて読み、外れ値を疑う。
• 単価の約7割はエンジニア人件費で、マージン自体は正当なコスト。問題は多重下請けの中抜きで、公取委の実態調査でも指摘される。商流は契約前に文書で確認する。
• 「安い提案」の裏側は、スキルシートの盛り・深い商流・偽装請負スキームのいずれかであることが多い。偽装請負は発注側が責任を問われる。安さの理由を特定できるまで契約しない。
• SESが機能するのは「社内に采配できる指揮者がいる」場合のみ。指揮者不在なら、人単位ではなくチーム単位の調達（FDE+）か請負を検討する。
• 単価改定（値上げ）要請は2026年の商慣行として定着した。一律拒否ではなく個人別査定で応える。

---

FAQ

Q1. SES単価は消費税込みか？

一般に税抜表示だ。月額80万円の提示なら実支払いは88万円（消費税10%込み）になる。相見積もりの比較では税抜・税込を必ず統一する。

Q2. 「精算幅」とは何か？

SES契約に一般的な、月の基準稼働時間（例：140〜180時間）の取り決めを指す。下限を下回れば控除、上限を超えれば超過精算となる。控除単価と超過単価の計算式が契約書に明記されているかを確認すべきで、超過単価だけ高く設定されている契約は、残業が常態化した際に想定外のコスト増になる。

Q3. SES単価はなぜ上がり続けるのか？

構造要因はIT人材の需給ギャップだ。経済産業省の2019年公表の調査では、高位シナリオで2030年に最大約79万人の不足が試算されている。加えて2023年11月の労務費転嫁の方針以降、人件費上昇を取引価格へ転嫁する交渉が政策的に後押しされており、更新時の単価改定要請は今後も続くと見るべきだ。

Q4. SES（準委任）と派遣の違いは？

指揮命令権の所在が違う。派遣では発注者（派遣先）がエンジニアに直接指示できるが、準委任ではできない。準委任なのに直接指示する実態があれば、厚労省の37号告示に照らして偽装請負と判断されるリスクがあり、発注側も責任を問われ得る。

Q5. 相場より20万円安い提案が来た。頼んでよいか？

安さの理由を特定できるまで契約すべきでない。合理的な理由（直請けで中間手数料がない、長期契約前提、リモート前提で地方人材を活用）なら問題ないが、理由が説明されない安さは、スキルミスマッチ・深い商流・偽装請負スキームのいずれかを疑う。面談での実在確認と、契約書の再委託・指揮命令条項の確認が最低限の防御だ。

Q6. 経験1年のエンジニアに月40万円は妥当か？

市場の目安としては下限圏で、金額自体は妥当な範囲だ。ただし「経験1年」の中身に注意する。未経験転職1年目と、学生時代から開発経験がある1年目では戦力がまったく違う。単価ではなくスキルシートと面談で判断すべきで、判断材料をくれない会社なら見送ってよい。

Q7. SESとフリーランス直契約はどちらが安いか？

エンジニア本人に払う額だけを見ればフリーランス直契約のほうが中間コストは少ない。ただし、フリーランスは待機・交代・品質保証を自社が引き受けることになり、離脱時のリスクや偽装請負の判断も自社責任になる。「安い＝得」ではなく、どのリスクを自社で持つかの選択だと捉える。社内に管理できる指揮者がいない場合、直契約は必ずしも安くつかない。

---

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、契約書に判を押す前に一度相談してほしい。

1. SES・開発会社から提案書と見積書を受け取ったが、単価・体制・契約条件が妥当か社内で判断できない → 提案・見積のセカンドオピニオン。売る側でない立場で、本記事のチェックリストを含む観点から提案を診断する。
2. SESで人を集めたが、采配する人がいなくて開発が空転している／しそう → FDE+（プロ人材・チームアサイン）。指揮者ごと調達する形で、要件整理から成果の刈り取りまで伴走する。
3. そもそもSESか請負か、どの契約形態で始めるべきか決めかねている → まず60秒見積シミュレーションでプロジェクト一括発注時の概算を掴んだうえで、DX・システム開発の進め方と費用感の相談で調達方式から一緒に整理する。AI活用を含む案件ならAI開発の見積もり・導入可否の第三者診断も使える。

GXOは自社でSES人材を再販していないため、「SESをやめて請負にすべき」「この提案のまま進めてよい」という結論も含めて、発注側の利益だけを基準に回答できる。営業電話はしない。相談だけで終わっても構わない。

無料相談の日程を見る

発注ライフサイクルの関連記事: SES単価は「体制・実行フェーズ」の費用だが、その前段には要件の確定、後段には運用の維持費がある。単価を比較する前提となる要件書の作り方は「要件定義書テンプレート＆サンプル記入例」、リリース後に毎年発生する保守費の相場は「システム保守費用の相場｜適正価格の見抜き方」で確認できる。単価だけを他社と比べても、要件と運用の前提が揃っていなければ比較にならない。

GXO式「SES単価・契約妥当性」100点評価表

GXO独自分析の前提条件は、月単価だけでなく、必要な役割、稼働、指示系統、成果証拠、交代・終了を比較することだ。

80点以上は候補、60〜79点は3か月限定、59点以下は見送る。契約と指示実態が違う、個人へ直接指示する前提、交代条件なし、成果・作業ログなし、本番権限の停止手順なしは強制停止条件である。

月単価120万円、精算幅140〜180時間の3名を6か月なら2,160万円。別途PM月80万円なら合計2,640万円になる。このGXO計算例は市場相場でなく、請負2,000万円・採用・内製との同条件比較をするための費用表だ。

質問票テンプレート

役割 / 必須スキル / 稼働開始 / 期間：
月額___万円 / 基準___時間 / 超過___円 / 控除___円：
指示系統 / 管理責任 / 再委託 / 交代___日前：
成果証拠：設計 / コード / テスト / 作業ログ / 引継ぎ
終了：権限停止 / データ返却 / 引継ぎ___日

一次資料と根拠と検証方法

• 厚生労働省 派遣・請負を適正に行うためのガイド
• 経済産業省 モデル取引・契約書
• IPA 要件定義ガイド
• デジタル庁 標準ガイドライン

版番号: GXO-SES-20260717-v1.0。確認日: 2026年7月17日。検証可能性の証拠は契約、指示系統、見積、勤怠、作業ログ、権限、引継ぎ。単価・精算幅・体制・契約・指示実態の変更を更新条件にする。公式資料の事実とGXOの見解である配点・費用例を分離している。呼称だけで法的評価は決まらないという限界があり、適法性や生産性を保証しない。自社で契約と実態を説明できない会社は開発体制・見積相談が向く。