フリーランスエンジニアの単価相場と年収｜役割で開く差と単価×12の落とし穴

フリーランスとして案件を探すときや、独立を考えるときに最初に知りたいのは「相場はいくらか」です。結論から言うと、フリーランスエンジニアの相場は一つの金額では決まらず、職種、担う役割の重さ、商流で大きく変わります。また、月額単価を12倍した数字は年収とは別物です。

この記事は、フリーランスエンジニアの単価と年収の全体像をまとめた案内役の記事です。経験年数別の推定年収、公開案件の単価の読み方、職種と言語の見方、リモートと常駐の差、単価を年収に直すときの考え方、エージェントのマージン、自分の単価が相場どおりかを確かめる手順の順に整理し、個別のテーマはそれぞれの記事へつなぎます。正社員を含めたエンジニア全体の水準はITエンジニアの平均年収で扱っています。

結論：自分の相場は平均ではなく役割で決まる

フリーランスの単価相場を見るときは、どこかで見た平均を自分の基準にせず、近い職種と役割の案件と比べることが大切です。

理由は、案件の平均単価が、経験の浅い人向けの案件から、事業の判断に関わるマネジメントの案件までをすべて混ぜた数字だからです。平均より低い提示を受けても、職種と役割を揃えて比べると相場どおりということもあれば、平均を上回る提示でも、担う役割に比べて安いということもあります。

具体例として、Javaで業務システムの改修を担う人と、Goで自社サービスの基盤を設計する人では、同じ「フリーランスエンジニア」でも比べるべき案件の群れが違います。前者が平均を見て「自分は安い」と考えたり、後者が平均を上回ったことで満足したりすると、判断を誤ります。

ただし、平均に意味がないわけではありません。自分の提示額がどの程度離れているかを知る出発点にはなります。離れているなら、その理由を職種、役割、商流のどれで説明できるかを確かめる、という使い方をします。

公開案件の単価の読み方

案件サイトやエージェントが公開している単価は、掲載された案件の提示単価であって、実際に契約して支払われた額ではありません。読むときはこの違いを最初に押さえます。

提示単価には、エージェントの取り分が含まれている場合も、含まれていない場合もあります。「〜万円」と上限だけが書かれている案件では、面談の結果によってその額に届かないこともあります。平均を出している集計は、案件数の多い職種や言語の影響も強く受けます。

具体的な読み方として、提示単価を自分の手取りの目安にするのではなく、「市場で提示されている幅」という位置情報として使います。同じ職種と役割の案件を複数集めれば、一つの案件の数字に引っぱられずに幅をつかめます。高い単価の案件が見つかっても、それがどんな役割を求めているのかを読まなければ、自分に当てはまるかは分かりません。

例外として、特定の業界向けの案件や、紹介制で公開されない案件は、公開情報からは見えません。公開されている単価より高い案件も低い案件も、その外にあります。

職種別の単価の見方：名前より責任の範囲

フリーランスの単価を職種別に見るときは、職種名より、その案件が何に責任を持つ役割かを読むことが大切です。

当サイトが確認した範囲では、フリーランスの単価を職種別に集計した公的統計は見当たりません。民間の集計は、案件サイトごとに職種の分け方や掲載案件の構成が違い、同じ仕事でも別の職種名で掲載されることがあります。そのため、順位をそのまま職種の価値と読まないほうが安全です。

単価を押し上げやすいのは、何を作るかを決める役割、チームや進行に責任を持つ役割、障害や品質に責任を持つ役割です。こうした仕事は、判断を誤ったときの影響が大きく、任せられる人が限られます。反対に、決まった仕様に沿って進める作業が中心の案件は、職種名が同じでも代わりの人を見つけやすく、単価の伸びは限られます。

具体例として、同じSREという名前の案件でも、監視の設定と手順に沿った対応を担うものと、信頼性の目標を決めて設計を見直すものでは、求められる経験が違います。比べるときは職種名ではなく、案件の説明に書かれた担当範囲を見てください。

注意点として、需要の高い分野の案件は時期によって増減します。一時点の案件の多さで職種を決めつけず、自分の経験が数えられる分野かどうかで判断してください。職種ごとの正社員の年収は、インフラエンジニアの年収相場や機械学習・AIエンジニアの年収相場で扱っています。

開発言語別の単価の見方：言語より案件の中身で差がつく

開発言語で単価を比べるときは、言語そのものより、その言語がどんな案件で使われているかを見ます。

理由は、言語が決めているのは単価そのものではなく、案件の種類だからです。自社サービスを持つ会社の新規開発や基盤の開発で使われる言語は、設計から関わる案件の割合が高くなりやすい一方、大規模な業務システムで長く使われてきた言語は、案件の数が多く、保守や改修の案件や、何社も間に入る商流の深い案件も含まれます。言語ごとの平均を比べると、この案件の構成の違いが差として出ます。

具体例として、同じJavaの経験でも、決まった仕様に沿って改修する案件と、システム全体の設計や移行の方針を決める案件では、単価の水準が違います。案件の中身を選べば、Javaの経験でも単価を上げる余地はあります。言語ごとの正社員の年収は、Goエンジニアの年収相場やJavaエンジニアの年収相場で比べられます。

注意点として、複数の言語を使う案件では、どの言語で数えられているかによって集計の結果が変わります。言語を乗り換えれば単価が上がる、と短絡的に考えず、その言語の案件でどんな役割が求められているかを見てください。

経験年数別の目安：当サイトのモデルで見る

経験年数別のフリーランス単価を公表している一次統計は、当サイトが確認した範囲では見当たりません。そこで、当サイトの年収推定モデルを使い、同じ条件で正社員として働く場合と、業務委託として働く場合の年収の目安を並べます。

条件は、東京、企業タイプによる上乗せや割り引きがないスタートアップ、スコア50です。業務委託の列は、単価×12より控えめに置いた当サイトの係数を掛けた推定で、案件の空白や自己負担をある程度織り込んだ値です。

この表の読み方として、経験が長くなるほど業務委託の推定も上がりますが、それは経験年数そのものではなく、経験の中で任される役割が広がることを表しています。フリーランスの案件では、入ってすぐに自分で判断して進められることが前提になるため、経験が浅いうちは案件の選択肢が限られます。

具体例として、実務1〜2年で独立すると、表の推定どおりの水準の案件に入れても、案件が切れたときに次が決まるまでの期間が長くなりやすく、年間の実収入は推定を下回る可能性があります。反対に、10年以上の経験があっても、同じ作業を続けてきただけでは単価は伸びません。年齢と単価の関係は40代フリーランスエンジニアの単価と年収で詳しく扱っています。

このレンジはモデルによる推定で、実際の案件の提示額を示すものではありません。自分の条件でどこに位置するかは、診断で確かめられます。

リモート案件と常駐案件の単価の差

リモート案件と常駐案件は、リモートかどうかだけで単価の高低を決めつけず、案件の中身を揃えて比べます。

理由は、リモート案件では、指示を待たずに自分で進められる経験や、文章で状況を説明する力が求められやすく、募集する会社の種類や職種の構成も常駐案件と違うからです。平均を比べた差には、働く場所の差だけでなく、こうした構成の差が混ざります。

具体例として、同じ経験の人がリモート案件に応募すると、面談で「過去にリモートでどう進めたか」「進み具合をどう共有したか」を細かく聞かれることがあります。これに具体的に答えられる人ほど、リモートの案件に入りやすくなります。

例外として、セキュリティの制約が強い業界の案件や、機器を扱う組み込み系の案件では、常駐が前提で単価が高いものもあります。リモートかどうかだけで単価を判断せず、案件の中身と合わせて比べてください。

単価を年収に直すときの考え方

月額単価から年収を見積もるときに一番大切なのは、単価×12は年収ではなく、一年中途切れずに稼働し、自己負担がない場合の理想値だと理解することです。

理由は、フリーランスには案件の切れ目があり、国民健康保険と国民年金を全額自分で負担し、賞与や有給休暇、退職金もないからです。さらに、会計や請求、営業など、売上を生まない時間も自分の仕事になります。これらを差し引かずに正社員の年収と並べると、フリーランスのほうが大きく見えすぎます。どこをどう差し引くかはフリーランスの単価を12倍しても年収にならない理由で順に説明しています。

具体例として、同じ月額単価でも、年間の稼働月数が違えば年収は大きく変わります。半年ごとに案件が切れて次を探す人と、同じ会社で長く続く人では、単価が同じでも実収入に差が出ます。この比べ方はフリーランスの長期契約と短期契約の年収差で扱っています。また、週5日ではなく週3日や週4日で働く場合は、単価も年収の考え方も変わり、フリーランスエンジニアの週3・週4案件で条件を整理しています。

注意点として、手取りの計算は、経費の内容や家族の状況、加入する制度によって人ごとに違います。税金や社会保険料の具体的な金額は、税理士などの専門家に確認してください。

契約形態と精算方式で変わる実収入

同じ月額単価でも、契約の形と精算の方式によって、実際に受け取る額と負うリスクが変わります。

理由は、エンジニアの業務委託には、働いた時間や作業に対して報酬が支払われる準委任と、成果物の完成に対して支払われる請負があり、責任の範囲が違うからです。また、準委任でも、月の稼働時間に幅を持たせた時間精算と、時間にかかわらず固定の月額では、稼働が多い月と少ない月の受け取り額が変わります。

具体例として、時間精算で上限と下限の時間が決まっている契約では、上限を超えて働いた月は超過分が支払われ、下限を下回った月は減額されます。同じ単価でも、精算の幅が広い契約と狭い契約では、時間単価に直したときの価値が違います。準委任と請負の違いは準委任と請負の違い、精算の読み方は業務委託の月額固定と時間精算の違いで扱っています。

もう一つ見落としやすいのが、入金のタイミングです。月末締めの翌々月払いのように支払いまでの期間が長いと、単価が高くても手元の資金が先に減ります。独立した直後は特に、フリーランスエンジニアの支払サイトで扱っている入金の遅れも、単価と並べて確認してください。

エージェントのマージンと商流

フリーランスの単価を比べるときは、提示された単価が、発注元が払う額からどれだけ差し引かれた後の数字かを意識する必要があります。

理由は、エージェントを通す案件では、発注元が払う額とあなたが受け取る額の間に、エージェントの取り分が入るからです。さらに、発注元とエージェントの間に別の会社が入る商流の深い案件では、間の会社の取り分も重なります。同じ仕事でも、通る経路によって受け取る単価が変わります。

具体例として、同じ発注元の同じ役割の案件が、複数のエージェントから異なる単価で紹介されることがあります。この差は、エージェントの取り分の違いだけでなく、発注元に直接つながっているか、間に別の会社が入っているかの違いからも生まれます。マージン率の確かめ方と、手取りから逆算する手順はフリーランスエージェントのマージン率で扱っています。正社員の場合の商流の考え方は、SESの契約単価と給与の関係も参考になります。

注意点として、マージンが低いことだけを基準にエージェントを選ぶと、案件の紹介の数や、契約が切れたときの次の案件の探しやすさ、支払いの条件など、ほかの面で不利になることがあります。取り分と、受けられる支援を合わせて比べてください。

自分の単価が相場どおりかを確かめる手順

自分の単価が相場どおりかは、条件を揃えて比べることで判断できます。次の順に確かめてください。

1. 自分の職種と主な言語を決め、全体の平均ではなく、近い職種と役割の案件を比べる相手にする
2. 担っている役割を書き出す（決められた作業を進めるのか、設計や判断を任されているのか）
3. 同じ職種・同じ程度の役割の公開案件を複数集め、提示単価の幅を見る
4. 自分の契約の商流とエージェントの取り分を確かめ、発注元が払う額の目安を考える
5. 精算の幅、稼働日数、支払サイトを揃えて、時間単価や年間の受け取り額に直して比べる
6. 複数の経路から、同じ条件での提示額を聞く

この手順の要点は、2と3です。単価は役割で決まるため、自分の役割を言葉にできないと、どの案件と比べるべきかが決まりません。設計の判断を任されているのに、作業を進める役割の案件と比べて「相場どおり」と考えていると、本来より安く働いていることに気づけません。

具体例として、TypeScriptで画面の開発を担っている人がいたとします。役割を書き出すと、実際には画面の設計方針を決め、ほかのメンバーのコードの確認もしていた場合、比べるべきなのはリードの役割の案件で、単価には上げる余地がある可能性があります。

注意点として、公開案件の単価は掲載時の提示額で、面談や交渉で変わることがあります。一つの案件の数字ではなく、複数の案件の幅で判断してください。

単価を上げる・守るための打ち手

相場と比べて単価に上げる余地があると分かったら、契約の更新の時期に、担った役割と成果を根拠に交渉するのが基本です。

理由は、フリーランスの単価は、契約を更新するときに見直されることが多く、それ以外の時期に変えるのは難しいからです。また、単価を上げる根拠として発注元が受け入れやすいのは、相場の話よりも、契約時より広がった役割や、チームに与えた効果です。交渉の進め方はフリーランスエンジニアの単価交渉で手順を整理しています。

具体例として、契約時は機能の開発だけを担っていたのに、途中から設計の判断や新しいメンバーの受け入れも任されるようになった人は、役割が広がった事実を根拠に単価の見直しを相談できます。一社に依存しないために、複数社と業務委託を並行する働き方で稼働を分ける人もいます。

守る側の備えも欠かせません。契約は発注元の事情で突然終わることがあり、収入の空白が長引くと、年間の実収入は単価から想像するより大きく下がります。契約の終了の条件と通知の期間を事前に確かめ、終わったときの動き方を決めておくことは、フリーランスエンジニアの契約打ち切りで扱っています。

相場より低いと感じたときの選択肢

条件を揃えて比べても単価が相場より低い場合、交渉、案件の乗り換え、働き方の見直しの三つを順に検討します。

理由は、低い単価の原因が、交渉していないことにあるのか、商流の深い案件に入っていることにあるのか、そもそも求められる役割が自分の経験と合っていないことにあるのかで、取るべき手段が違うからです。原因を確かめずに乗り換えると、同じ問題を次の案件でも抱えることになります。

具体例として、商流が深いことが原因なら、発注元に近い案件を扱う経路を探すことが近道です。役割が原因なら、今の案件で設計や判断の経験を積み、次の更新や次の案件で役割を上げることを目指します。収入の安定を優先したい場合は、正社員に戻る選択もあります。その場合の年収の決まり方はフリーランス・業務委託から正社員に戻る年収で扱っています。

注意点として、フリーランスと正社員のどちらが得かは、単価の高さだけでは決まりません。収入の変動や保障を自分で引き受けるかどうか、どんな経験を積みたいかも含めて判断してください。

よくある誤解

「フリーランスの平均単価が自分の相場」という見方は正確ではありません。平均は職種や役割をすべて混ぜた数字で、比べるべきなのは近い職種と役割の案件です。

「単価×12が年収」という計算も成り立ちません。案件の空白、社会保険料の自己負担、賞与や有給がないことを差し引く必要があります。

「単価の高い言語に乗り換えれば単価が上がる」という考えも一面的です。言語で見える差の多くは、その言語が使われる案件の中身の違いから生まれています。

「マージンが低いエージェントが一番得」という判断も早すぎます。紹介される案件の数や支払いの条件、契約が切れたときの支援も合わせて比べる必要があります。

まとめ

• フリーランスエンジニアの相場は一つの金額ではなく、職種、担う役割、商流で変わる
• 公開案件の単価は提示額で、実際に支払われた額ではない
• 職種名や言語より、案件が何に責任を持つ役割かで比べる
• 経験年数別の一次統計はなく、モデルでは経験とともに任される役割が広がることで業務委託の推定も上がる
• リモートか常駐かの差には、案件の中身の違いが混ざるので、役割を揃えて比べる
• 単価×12は年収ではなく、契約形態、精算方式、支払サイト、マージンで実収入は変わる
• 自分の単価は、職種と役割を揃えた案件と比べ、商流と精算条件を揃えて判断する