セールスエンジニア・プリセールスの年収相場｜企業タイプ差210万円と4つの評価軸

セールスエンジニアやプリセールスの年収は、商談に同席した件数では決まりません。 提示額を動かしているのは、顧客が求める要件に対して技術的な実現性の判断をどこまで自分で引き受けているか、そしてその判断が受注の数字にどれだけ直結しているかの2つです。

この記事は、プリセールスとして働いている人、または開発職からプリセールスへの異動・転職を検討している人が、いまの提示額や役割が相場のどこに当たるかを判断するために書いています。まず条件をそろえたレンジを見たうえで、提示額を分ける評価軸と、固定給とインセンティブの比率の読み方を順に扱います。

条件をそろえた推定レンジで自分の位置を測る

セールスエンジニアの求人は年収の幅が広く書かれることが多く、レンジだけを見ても自分がどこに置かれるか分かりません。実務3〜5年・東京勤務・スキル中位に条件を固定し、企業タイプだけを変えると次のようになります。

最上段のメガベンチャー・外資と最下段のSESを推定の中央値で比べると、210万円の開きがあります。同じ「提案を技術面から支える」仕事をしていても、自社で製品を持ち、その製品の売上から報酬を払う会社なのか、他社製品の導入工数を売っている会社なのかで、支払いの原資がそもそも違うためです（企業タイプ別の年収相場）。

この表は、職種ではなく企業タイプと経験年数から引いた推定です。そのため、インセンティブが年収の大きな部分を占める会社では、表の数字は固定給に近い部分しか説明しません。担当する製品の単価が極端に高い場合や、担当領域が特定の業界に深く寄っている場合も当てはまりにくくなります。実際の提示額を判断するときは、この表を出発点にして、以下の評価軸のどこに自分が立っているかを重ねてください。

職種名からは担当範囲が読み取れない

この領域の求人は、セールスエンジニア、プリセールスエンジニア、ソリューションアーキテクト、ソリューションコンサルタント、技術営業など、会社ごとに違う名前で出ます。名前の違いは担当範囲の違いとは対応していません。同じ「セールスエンジニア」でも、営業が持ち帰った質問に社内で答えるだけの職場と、顧客の要件を聞いて構成を描き、できないことをその場で断る職場が、同じ求人名で募集されています。

年収を比べるときに見るべきなのは名前ではなく、技術的な可否の判断が誰の責任になっているかという点です。自分の判断が提案書としてそのまま顧客に出る職場では、判断を誤ったときの損失が大きく、その分だけ代わりが利きにくくなります。逆に、開発チームへ確認を回してから回答する設計になっている職場では、担当者の熟練度が提示額に反映されにくくなります。

以降の4つは、その「引き受けている判断の重さ」を分解したものです。上から順に、提示額への効き方が大きくなります。

評価軸1：実現性の判断をその場で引き受ける

最初の分岐は、顧客の要望に対して「できる」「できない」「条件付きでできる」をその場で言い切れるかどうかです。言い切れる人は、商談の速度を落としません。持ち帰って確認する前提の人は、同じ内容でも回答までに社内の工数を追加で使うことになります。

具体的には、製品の制約、想定される負荷、既存システムとの接続方式、データの移行経路、権限や監査の要件といった観点を、その場で頭の中に並べられる状態を指します。この範囲まで自分で判断できると、提案の骨格が初回の打ち合わせで固まり、後戻りが減ります。会社から見れば、商談の成立までに必要な回数が減ることが、そのまま費用の削減になります。

注意したいのは、言い切る速さだけを評価してしまう状態です。できないことを曖昧にしたまま受注すると、導入の段階で破綻し、対応の負担は別の部署へ移ります。この軸で評価されるのは、断る判断を自分の責任で出せることであって、顧客の要望に合わせて可能性を広く見せることではありません。

評価軸2：検証の設計で受注確度を動かす

2つ目は、概念検証（PoC）や技術検証の設計です。提案の段階で顧客が最も不安に感じている点はどこかを見極め、そこだけを短い期間で確かめる形に落とせるかどうかで、受注の確度が変わります。

この軸が効くのは、検証の設計が顧客の意思決定の順番を変えるからです。すべての機能を広く試す検証は、期間が長くなり、結論が出る前に予算の時期を逃します。対して、意思決定の障害になっている一点に絞った検証は、結果が出た時点で決裁が動きます。どの一点に絞るかの見極めは、製品知識と顧客の業務理解の両方を必要とするため、担当者によって差が出ます。

具体例としては、性能が懸念されている案件で、本番相当のデータ量だけを再現して処理時間を測る設計が挙げられます。機能の網羅は後回しにし、数字が出る部分に検証を集めます。ただし、検証の環境構築を毎回ゼロから作っている場合、担当できる件数が自分の稼働時間で頭打ちになります。そこで次の軸が効いてきます。

評価軸3：提案を再現できる資産に変える

3つ目は、個々の商談から一段上がって、提案の型を組織に残す役割です。デモ環境の自動構築、業界別の参照構成、よく出る質問への回答集、見積もりの前提を整えたテンプレートなどが含まれます。

この範囲が評価されやすいのは、成果が自分の稼働時間から切り離されるからです。商談に出る力は、その人が働いた時間の分しか効きません。対して、他のメンバーが使える資産は、作った後もずっと効き続けます。同じ内容の提案を他の担当者が再現できる状態になれば、会社としての受注能力そのものが上がります。

一方で、この仕事は目の前の商談に追われていると後回しになります。評価の対象として認識されていない職場では、成果として説明する場も用意されません。作った資産が何件の商談で使われ、準備にかかる時間がどう変わったかを記録しておくと、昇給の場で説明できる形になります（自己評価シートの書き方）。

評価軸4：受注後の立ち上がりまで責任を持つ

4つ目は、契約が決まった後の稼働開始までを見届ける範囲です。提案した構成のまま導入できたか、想定した性能が出たか、運用に乗ったかを確認し、必要なら設計を修正する役割にあたります。

ここが年収に効くのは、更新や追加の受注に直結するからです。受注の時点で評価が終わる設計の職場では、提案の精度と実際の導入結果が切り離され、無理のある提案が通ってしまいます。稼働後の結果まで担当者の評価に含める職場では、提案の質が上がり、その分だけ担当者の市場価値も説明しやすくなります。

注意点として、この範囲を担当していても、評価の指標が受注額だけに置かれている場合は提示額に反映されません。面接では、評価の対象が受注の時点なのか、稼働後の継続なのかを直接確認してください。指標が受注額だけの場合、導入支援の負担は評価されない作業として積み上がります。

固定給とインセンティブの比率で同じ額面の意味が変わる

セールスエンジニアの提示額を他社と比べるときは、固定給と変動給を分けないと比較になりません。同じ提示総額でも、固定給が大半を占める設計と、目標達成を前提に総額を提示している設計では、実際に受け取る金額の振れ方がまったく違います。

分けて見る必要があるのは、変動給が保証された金額ではないからです。目標の設定が翌年に上がる、担当領域が変わって前提が崩れる、製品の販売計画が見直されるといった事情で、同じ働き方でも支給額は動きます。求人票に「インセンティブあり」とだけ書かれている場合、その金額が提示総額に含まれているのかどうかを確認しないと、固定給の水準を読み違えます。

確認したいのは、算定の基礎が個人の受注額か担当チームの目標か、支給の下限があるか、直近の達成率の分布はどうなっているかの3点です。賞与の比率が高い会社を比較するときと同じ考え方で、月給ベースに引き直すと並べられる形になります（賞与比率が高い会社と低い会社の比べ方）。なお、株式報酬や入社時の一時金が提示に含まれる場合も、固定給とは別に数えてください。

開発職と等級テーブルが共通かどうかで上限が決まる

提示額の上限を決めているのは、個人の交渉力ではなく制度です。同じ会社の中で、セールスエンジニアが開発職と共通の等級テーブルで評価されているのか、営業部門側のテーブルに置かれているのかで、到達できる上限が変わります。

共通のテーブルであれば、技術的な深さを理由に上の等級へ進む道が制度として残ります。営業部門のテーブルに置かれている場合は、昇格の条件が売上の達成に寄り、技術の深さは評価の言葉になりにくくなります。どちらが有利とは一概に言えませんが、自分が伸ばしたい方向と制度が噛み合っているかは確認する価値があります（等級・グレード制度の読み方）。

制度が分かれている会社で年収を上げる選択肢は、営業部門のテーブルの中で上の等級を目指すか、テーブルが共通の会社へ移るかの2つになります。カジュアル面談の段階でも、等級の体系がどの部門に属しているかは聞ける範囲の情報です（カジュアル面談で確認できること）。

経験年数で提示額はどこまで伸びるか

企業タイプを上場・大手に固定し、経験年数だけを変えると次のようになります。プリセールスは顧客の業務理解と製品知識が積み上がる職種なので、年数の効き方は開発職と同じ方向に働きます。

未経験帯と10年以上を推定の中央値で比べると、415万円の開きがあります。ただしこの表は、年数がそのまま報酬になるという意味ではありません。年数とともに担当する案件の規模と難度が上がり、判断の重さが変わることを前提にした推定です。前節の評価軸で言えば、軸1にとどまったまま年数が増えても、この曲線には乗りません。

また、この表は固定給に近い部分を説明するものであり、インセンティブの比率が高い会社では上端がさらに伸びることも、下端で止まることもあります。自分の位置を測るときは、年数の行を見てから、担当している案件が同じ年数帯の他の人と比べて大きいか小さいかを重ねて考えてください。

開発職の相場とどう比べるか

セールスエンジニアの提示額が妥当かを確かめるとき、開発職の平均と直接比べても答えは出ません。ITエンジニア全体の平均年収は 469万円（2025年） ですが、この数字には未経験者から10年以上の人までが含まれており、職種の違いも吸収されています（平均年収が適正額にならない理由）。

業界全体の水準を見るなら、情報通信業の平均給与 660万円 と、その中央値の推計 585万円 を並べたほうが実態に近づきます。平均が中央値より高いのは、上位に高額の層がいるためです。この業界で年収1,000万円を超える人の割合は 13.2% で、プリセールスはインセンティブの設計次第でこの層に届きうる職種の一つに当たります。

そのうえで、比較の対象を職種名ではなく責任の重さで選んでください。要件を聞いて構成を描く仕事は、社内で言えば技術選定の判断に近い性質を持ちます。開発職側で同じ重さの判断をしている人の提示額と並べると、職種名で比べるよりも実態に近い比較になります。

自社製品を売る会社と、他社製品を再販する会社

同じ職種名でも、会社の立ち位置で伸び方が変わります。自社で製品を持つ会社のプリセールスは、開発チームが社内にあり、顧客の要望を仕様の変更として持ち込めます。積み上がるのは「その製品で何ができるかを最もよく知っている」という価値で、社内での等級も上がりやすい構造です。

他社製品を再販し、その導入工数を売っている会社では、支払いの上限が仕入れと販売の差額に縛られます。製品の仕様そのものには働きかけられないため、提案の幅は代理店としての契約が想定する範囲に収まります。この構造は商流の問題であり、個人の努力では動かしにくい部分です（一次請けと二次請けで年収が変わる理由）。

判断の材料として、応募先が売っているものが製品なのか導入工数なのかを確認してください。製品を売っている会社では、プリセールスは製品価値を伝える役として扱われます。工数を売っている会社では、受注のための前工程として原価に近い扱いになります。この違いが、冒頭の表に出た開きの大部分を説明します。

開発職からプリセールスへ移るときの年収の動き

開発職からの異動や転職では、固定給が据え置きか、やや下がる提示になることがあります。理由は、開発職の等級と営業部門の等級の対応が会社の中で整理されていないためで、実力が下がったという評価ではありません。そのぶんインセンティブが乗る設計になっている場合、総額としては同等以上になることもあります。

確認すべきなのは、下がった固定給がその後どう戻るのかです。移った先のテーブルで、いまの等級から上に行く条件が言語化されていれば、下げ幅を回収する道筋が読めます。条件が曖昧なままの提示は、下がった水準がそのまま数年続く可能性を含みます（年収が下がる転職を受けてよい条件）。

英語の扱いも変わります。海外の開発元とやり取りする製品では、仕様の確認や不具合の議論に自分で入れるかどうかで担当できる案件が変わり、結果として等級に反映されることがあります。読み書きだけで止まるか、議論の場に出られるかで差が出る点は、開発職での評価と同じ構造です（英語が年収で効く場面）。

プリセールスから他の職種へ移る道

プリセールスの経験は、移る先によって評価のされ方が変わります。プロダクト側へ移る場合は、商談で拾った要望のうちどれを仕様の変更として通し、その後に受注や利用がどう変化したかを説明できると、要望の伝達役ではなく判断する側として見てもらえます（プロダクトマネージャーとエンジニアの年収比較）。

コンサルティング側へ移る場合は、製品に依存しない形で課題を整理した経験が材料になります。特定の製品を前提にした提案しか残っていないと、製品が変わった瞬間に説明できる実績が減ります（ITコンサルタントとエンジニアの年収比較）。

開発職へ戻る場合は不足が出ます。提案資料や商談の件数では、設計や実装の経験を説明できないためです。戻る前に、自分が構築した検証環境、書いたサンプル実装、自動化したデモの仕組みを具体的な形で残しておく必要があります。職務経歴書の書き分けは実績を書き分ける型にまとめています。顧客対応の比重が大きい職種という点では、テクニカルサポートエンジニアの年収と近い論点も出てきます。

求人票と面接で確認すること

提示額の妥当性は、次の項目が埋まると判断できるようになります。面接の場で聞いてよい内容であり、答えられない会社はその点が整備されていないと読めます。

• 提示総額のうち固定給と変動給の比率、変動給の算定基準と支給の下限
• 評価の対象は受注の時点か、稼働後の継続や追加受注まで含むか
• 技術的な可否の判断は自分が出すのか、開発チームの確認を経るのか
• 等級テーブルは開発職と共通か、営業部門側に置かれているか
• 担当する製品は自社製品か他社製品の再販か、仕様変更を持ち込めるか
• 担当領域の割り当て方（業界別・地域別・製品別）と、変更の頻度
• 検証環境やデモ資産は共有されているか、案件ごとに作り直しているか

求人票のレンジをそのまま自分に当てはめないことも重要です。上限は実在する人がいる金額とは限らず、想定している役割が自分の応募区分と違う場合もあります（求人票の年収レンジを読む）。

まとめ

• 年収を分けるのは商談の件数ではなく、技術的な可否の判断をどこまで自分の責任で出しているか
• 同じ実務3〜5年でも、製品を売る会社か導入工数を売る会社かで推定レンジは210万円開く
• 提示を比べるときは固定給と変動給を分け、変動給をゼロと仮定した金額で判断する