IoTエンジニアの年収相場と単価｜組み込みとクラウドで評価が分かれる3つの境界

IoTエンジニアの年収は、職種名ではほとんど決まりません。同じ求人名でも、デバイスの中のソフトウェアを書く仕事と、集まったデータを受けて動かし続ける仕事では、年収の天井の決まり方が別だからです。まずその分かれ目を確かめ、そのうえで自分がどちら側に立っているかを確認します。

職種ごとの水準そのものを比べたい場合は職種別の年収を先に見てください。この記事では、IoTという領域が持つ「境界に立つ職種」という性質に絞って扱います。

公的統計にIoTエンジニアという区分はない

結論から言うと、IoTエンジニアの平均年収を示した公的統計はありません。賃金構造基本統計調査の職種区分には、IoTという名前の職種が存在しないためです。代わりに、仕事の中身に応じて次の2つの区分に分かれて集計されています。

デバイスのファームウェアやアプリケーションを書く仕事は、前者のソフトウェア作成者に入りやすい区分です。一方、通信、サーバー管理、保守、セキュリティに寄る仕事は後者に含まれます。IoTの開発は両方にまたがるため、同じ「IoTエンジニア」という求人名でも、統計上は別の母集団として数えられていることになります。

この表の読み方には注意が必要です。年収換算額は当サイトが月額と年間賞与から算出した概算で、調査が公表した年収そのものではありません。また、どちらの区分も産業計・企業規模計の全職種平均で、IoTに関わる人だけを取り出した数字ではありません。使えるのは「どちらの系統に寄るかで出発点が違う」という向きの確認までで、自分の提示額を直接当てはめる根拠にはなりません。

平均年齢と労働者数の差も合わせて見ておくと、構造が見えます。ソフトウェア作成者は母数が大きく平均年齢が若い区分で、その他の情報処理・通信技術者は母数が小さく平均年齢が高い区分です。後者のほうが年収換算額が上に出ているのは、運用と保守の責任を長く持つ人が含まれているためだと考えられます。職種としての難易度がそのまま反映された差ではありません。

デバイス側とクラウド側で、年収の天井の決まり方が違う

同じIoTの案件でも、デバイス側とクラウド側では、年収を押し上げる要素が違います。デバイス側で効くのは、限られた資源と実時間の制約の中で動かし切る設計です。クラウド側で効くのは、台数が増えても壊れない収集と保存の設計、そして動き続けさせる運用の責任です。

この違いが年収に出るのは、代替可能性と原資の両方が違うからです。デバイス側は人が少なく代替が利きにくい反面、製品の原価に紐づく予算の中で動くことが多く、上限が製品側の採算で決まります。クラウド側は人の母数が大きい分だけ競争も強いものの、提供するサービスの売上に紐づくため、原資そのものが伸びる余地があります。どちらが有利かではなく、原資の出どころが違うという理解が出発点です。

具体例として、デバイスのファームウェアだけを担当してきた人が、同じ製品のデータ基盤まで引き受けられるようになった場合を考えます。このとき評価が変わるのは、技術が増えたからではありません。製品の不具合がデバイス側の実装由来かデータ側の欠損由来かを切り分けられる人が社内に少なく、判断を預けられる範囲が広がるからです。等級制度を持つ会社では、この「判断の範囲」が等級要件の文言として書かれていることが多くあります（等級・グレード制度と昇格）。

ただし例外もあります。設置と保守の現場対応が主な役割として設計されている配属では、両方を触っていても判断の範囲が広がりません。手を動かす量ではなく、決める範囲が増えるかどうかを見てください。

経験年数で見た推定レンジ

当サイトの診断モデルで、東京勤務・上場企業・スキル中位という条件を固定し、実務経験年数だけを変えるとこうなります。

この表は、IoTに限らずエンジニア全体の条件から推定したレンジです。IoT専用の係数を置いているわけではないので、職種固有の上乗せや下振れは含まれていません。読み方としては、経験年数という軸だけでどれだけ動くかの目安として使い、そこに企業タイプと勤務地の条件を重ねて考えます。

当てはまらないのは、同じ年数でも担当範囲が極端に狭い場合です。たとえば実務6〜9年のうち大半が特定製品の保守に閉じていた場合、年数に対応するレンジの下端に置かれることがあります。年数は経験の量を示す代理の指標にすぎず、評価されるのは範囲と判断です。

企業タイプで開く幅は職種より大きい

同じ実務3〜5年・東京・スキル中位でも、企業タイプを変えるとこうなります。

IoTの仕事は、メーカー、製品を持つ事業会社、受託開発、SESのいずれにも存在します。そして職種をデバイス側からクラウド側へ寄せて得られる差より、企業タイプを移動したときの差のほうが大きく出ます。これは事業の利益率と商流の深さという構造から来ているため、個人の交渉では埋まりません（企業タイプ別の年収相場）。

実務上の意味は単純です。IoTの技術を広げる努力と、どの原資の上に乗るかを選ぶ判断は、別々に進める必要があります。技術だけを広げても商流の下にいれば伸びにくく、商流を上げても担当範囲が狭ければ等級の下端に置かれます。

フリーランスの単価は担当範囲と契約条件で決まる

結論として、IoTの単価はデバイス側かクラウド側かだけでは決まりません。発注側が払うのは任せられる範囲に対してなので、担当範囲、商流、契約条件で動きます。

デバイス側では、実機や検証環境が発注側にあると作業場所が限られ、参画できる案件の条件が絞られます。クラウド側では環境を遠隔で扱いやすい反面、運用の当番まで含むかどうかで同じ月額の重さが変わります。同じ月額でも、精算の幅を超えた時間に追加の支払いがあるか、仲介が何社入るかで、手元に残る額は違います。

水準の見当をつけるなら、当サイトのモデルで実務6〜9年・東京・スタートアップ・スキル中位の業務委託を推定すると 782〜919万円 です。これはモデルによる推定で、実際の案件の提示額ではなく、IoTに限った数字でもありません。フリーランスの単価の読み方についてはフリーランスエンジニアの単価相場で扱っています。

デバイスの知見を持ったうえで、収集後のデータ基盤や運用まで引き受けられる形にすると、参照できる案件の範囲そのものが広がります。製品の不具合をデバイス側とデータ側のどちらの問題か切り分けられる人には、切り出した作業ではなく判断を任せやすいからです。ただし、複数の層を掲げても実績を説明できなければ、発注側は判断を預けられません。

業種が製造業か情報通信業かで原資が変わる

IoTの仕事は、製造業の会社にも情報通信業の会社にも存在します。業種の平均給与を並べると差があります。

どちらも技術者だけを取り出した数字ではなく、生産、営業、管理を含む業種全体の平均です。そのまま個人の年収差として読むことはできません。この差が何を意味するかは組み込み・制御系エンジニアの年収相場で詳しく扱っています。

IoTに固有の事情として、製造業側の会社では、ソフトウェア技術者の給与テーブルがハードウェア技術者と同じ体系に置かれている場合があります。この場合、ソフトウェアの市場価格が上がっても社内の等級と賃金表が追随しにくく、外の提示額との差が開くことがあります。逆に情報通信業側の会社では、デバイスの知見が等級要件に書かれておらず、評価されないまま終わることがあります。どちらの業種でも、自分の強みが等級要件の文言に入っているかを確認するのが先です。

IoTで評価される経験の中身

技術名を並べるだけでは評価されません。IoTで提示額が動く経験は、どれも「制約の中で何を決めたか」の形を取ります。

• 通信が切れる前提の設計 — 回線が不安定な場所で、再送、重複排除、順序の扱いをどう決めたか
• 台数が増えたときの設計 — 1台で動いたものを数万台で動かすときに、収集と保存の構成をどう変えたか
• 遠隔更新の設計 — 配信中に失敗した端末をどう戻すか、段階的に配るかを誰がどう判断したか
• 電力と資源の制約 — 電池の持ちや通信量の上限に対し、送る頻度と内容をどう削ったか
• 物理と安全の要求 — 誤動作が人や設備に影響する系で、検証の範囲をどう決めたか

これらが評価されるのは、どれもやり直しの費用が高く、設置後に直せない判断だからです。クラウド上のサービスであれば修正を配り直せますが、設置済みのデバイスは回収も更新も費用がかかります。その前提で決め切った経験は、社内でも代替が利きにくい領域として扱われます。

具体例として、職務経歴書に「MQTTを用いたデータ収集基盤の構築」と書いた場合と、「回線断が日常的に起きる環境で、欠損を許容する範囲を事業側と合意し、再送と重複排除の方式を決めた」と書いた場合を比べます。前者は使った技術の申告ですが、後者は判断の記録です。後者のほうが等級要件と突き合わせやすく、面接でも深く聞かれます（エンジニアの職務経歴書の書き分け）。

注意点として、これらの経験は言語や製品の名前では伝わりません。同じ技術を使っていても、仕様が上流から降ってきただけの立場なら、判断の記録として書けるものがありません。その場合は、まず決める側に入れる配属かどうかを確認してください。

求人票からどちら側の仕事かを読む手順

IoTエンジニアという職種名だけでは、実態が分かりません。次の順で読むと、どちら側の仕事かが判別できます。

1. 担当する層を特定する（ファームウェア、ゲートウェイ、通信、データ基盤、可視化のどこか）
2. 量産や設置が関わるかを確認する（関わるなら現場対応の比率を聞く）
3. 運用の当番があるかを確認する（あるなら手当の有無と頻度まで）
4. 商流上の位置を確認する（製品を持つ側か、受託か、常駐か）
5. 提示レンジの下端と上端が、どの等級に対応するかを確認する

この順にするのは、後ろの項目のほうが年収に効くのに、前の項目のほうが求人票に書かれているからです。担当する層は職種名や必須要件から読めますが、商流と等級は面接で聞かないと分かりません。レンジの読み方は求人票の年収レンジの読み方にまとめています。

年収が伸びにくい配属のパターン

IoTの領域で年収が伸びにくくなるのは、技術が古いからではありません。決める範囲が構造的に閉じている配属に入ったときです。

典型は、設置と保守の現場対応が主な役割になる配属です。この仕事は事業に必要で、現場の知見も蓄積されます。しかし担当範囲が個別の現場に閉じるため、等級要件に書かれた「方式を決める」「横断的に改善する」といった文言に対応する実績が作れません。評価の制度上、上の等級へ上げる根拠が揃わない状態になります。

もう一つは、仕様が上流から完成した形で降ってくる常駐の配属です。実装の品質は評価されても、判断の記録が残りません。SESの商流で単価と給与がどう決まるかはSESの契約単価と給与の関係で扱っています。

例外として、現場対応から入っても範囲が広がる場合があります。現場で見つけた不具合の原因を製品側の設計まで遡って提案し、次の世代の仕様に反映させた実績がある場合です。この形になっているなら、現場対応は不利な配属ではありません。配属名ではなく、提案が設計に届いた経験があるかで判断してください。

組み込みからクラウド側へ範囲を広げる順序

デバイス側を軸にしている人が範囲を広げるときは、順序があります。先にクラウドのサービスを広く覚えるより、自分が作ったデバイスのデータが流れていく先を、端から順に引き受けるほうが実績として説明しやすくなります。

理由は、評価されるのが技術の数ではなく、境界をまたいだ切り分けができる点にあるからです。デバイス側の実装を知っている人が収集側まで持つと、不具合の原因をどちら側か判断できます。この能力は、クラウド側だけを担当してきた人には作りにくく、デバイス側だけを担当してきた人にも作れません。境界に立つことそのものが希少性になります。

具体的な進め方としては、まず自分の製品のデータ収集部分の設計を読み、次に保存と再処理の構成を把握し、そのうえで監視と障害対応の当番に入る、という順になります。クラウド側の職種としての相場はクラウドエンジニアの年収相場とSRE・インフラエンジニアの年収で確認できます。

注意点として、当番に入る場合は手当と頻度を先に確認してください。深夜の呼び出しが発生する体制では、年収が上がっても実質時給が下がることがあります（オンコール・障害対応の当番手当）。

クラウド側からデバイス側へ寄せるときの注意

逆方向も成立しますが、難易度は対称ではありません。クラウド側の経験を持つ人がデバイス側に寄せる場合、覚えることの量よりも、やり直せない前提に慣れるまでの時間が壁になります。

クラウド側の開発では、問題が見つかれば修正を配り直せます。デバイス側では、量産に入った後の修正に製造と物流の費用がかかり、設置済みの機器では回収自体が難しいこともあります。この前提の違いは、検証にかける時間の見積りと、仕様を固める時期の判断に直接出ます。技術を覚えても、この時間感覚が合わないと設計のレビューで噛み合いません。

実務では、いきなりファームウェアを担当するより、デバイスに近い層から入るほうが現実的です。ゲートウェイやエッジ側の処理、デバイス管理の仕組み、遠隔更新の配信側といった領域は、クラウド側の経験がそのまま効き、かつデバイスの制約に触れられます。車載のように規格と安全要求が厳しい領域については車載ソフトウェアのエンジニアの年収を参照してください。

面接とオファーで確認する項目

IoTの求人は、職種名と実態の距離が開きやすい領域です。提示を受ける前に、次の項目を確認してください。

• 担当する層と、方式を決める権限がどこにあるか
• 現場対応と設置作業の比率（月あたりの日数で聞く）
• 運用当番の有無、頻度、手当の金額と計算方法
• 提示レンジの下端と上端が対応する等級、および次回の等級判定の時期
• ソフトウェア技術者の給与テーブルが、ハードウェア技術者と同じ体系かどうか

最後の項目は、製造業側の会社を受けるときに特に効きます。同じ体系に置かれている場合、ソフトウェアの市場価格が上がっても社内の賃金表が追随しにくく、数年後の差が開きます。制度の話なので入社後には変えられません。

統計が当てはまらないケース

この記事で使った数字には、当てはまらない場合があります。公的統計の職種区分は産業計の平均で、IoTに関わる人だけを取り出したものではありません。年収換算額は当サイトが月額と年間賞与から計算した概算で、調査が公表した年収ではありません。

診断モデルによる推定レンジも、エンジニア全体の条件から計算したもので、IoT専用の係数ではありません。業種の平均給与は、技術者以外を含む業種全体の数字です。これらはいずれも、自分の位置を確かめる出発点としては使えますが、提示額の妥当性を単独で証明する根拠にはなりません。

参考として、求人側の需給も見ておきます。情報処理・通信技術者の有効求人倍率は1.33倍で、全職業の1.06倍を上回っています。ただしこれはハローワークに出された求人の集計で、IoTの求人だけを取り出した数字ではなく、転職市場全体の体感とも一致しないことがあります。

最終チェック

提示を比べる前に、次を確認してください。

• 自分の仕事がデバイス側とクラウド側のどちらに軸足があるかを言葉にした
• 制約の中で下した判断を、技術名ではなく決めた内容として書けている
• 応募先の商流上の位置と、提示レンジが対応する等級を確認した
• 運用当番の頻度と手当を、年収ではなく実質時給で計算した
• ソフトウェア技術者の給与テーブルが独立しているかを確認した

IoTは境界に立つ領域です。年収を動かすのは、どちらの技術を選んだかではなく、境界をまたいで判断できる範囲です。自分の経験をその形で説明できるようにしてから、提示を比べてください。