IoT機器の開発案件では、動作するモジュールを仕上げた時点で、仕事の山を越えたように感じられます。設計と実装に工数の大半を割いてきた案件ほど、その感覚は強くなります。ところがIPAが公開する通信機器向けの★3セキュリティ要件を見ると、対策の範囲は製品を出荷したあとの運用フェーズにまで広がっています¹。着手前にどこで手が重くなるのかを線引きしておくことが、案件を選ぶ材料になります。

1. 手のかかる山は、出荷の後に来ます

実装を終えた時点は、要件の入り口に過ぎません

IoT機器の開発案件に参画するとき、見積もりの目線はどうしても実装工数に向きます。要件定義から実装、単体テストまでを終えれば、案件の主要な部分は完了したという受け止め方が一般的です。設計と実装にかけた時間の分だけ、成果が形になったという実感も生まれやすいところです。

ところが★3の適合基準類は、満たすべき対策を定めた「★3セキュリティ要件」、その具体化である「★3適合要件」、評価の手順を示す「★3評価ガイド」という3つの文書に分かれています¹。3つの役割を混ぜて読むと、開発段階の作業と出荷後の対応の境目が曖昧になります。

この3つの文書を最初から読み分けておくと、着手前に「今回の案件でどこまで対応するのか」という範囲が見えてきます。満たすべき対策を洗い出す作業と、評価の手順に沿って進める作業とでは、求められる進め方が異なるためです。コードを書く力よりも、こうした制度の構造を読み解く力のほうが、参画後の役務範囲を見誤らない決め手になります。

実装の完成度よりも、出荷後にどこまで対応を続けられるかのほうが、案件の負荷を左右します。次の章からは、何が変わると手続きが重くなるのか、部品表や文書をどう扱うのかを、出荷後の視点で順に見ていきます。

出典：独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」（2026年2月）をもとに作成

2. 何を変えるかで、手続きの重さが変わります

変更の種類ごとに、進む先が変わります

出荷後の変更は、すべてが同じ重さで扱われるわけではありません。むしろ変更の中身によって、進む先がはっきり分かれています。セキュリティ機能等の変更が★3適合評価の結果に影響を及ぼす場合は、評価機関での再評価が必要になる場合があります²。ただし、この場合があるという幅を、常に再評価が必要という話に広げて読むと、対応の見積もりを過剰に重くしてしまいます。ファームウェアの更新やIoT製品への更新、変更等があった場合は、別途IPAのホームページを参照して個別に対応することになっています³。

見積もりの時点でこの4つの入口を意識しておくと、契約時に想定していなかった作業が土壇場で発生する事態を防ぎやすくなります。特にセキュリティ機能に関わる変更と、単なる保守目的の更新とを同じ扱いで契約に盛り込んでしまうと、対応の重さの違いがあとから表面化し、稼働の途中で役務範囲の協議が必要になります。

要件の項目追加や大幅な変更等が生じ、旧版と新版を並存させる猶予期間が終了した場合も、進む先は一様ではありません。猶予期間が終わってもラベルはその場で使えなくなるわけではありませんが、猶予期間後の有効期間の延長については延長の申請ができず、★3適合ラベル付与の再認証が必要になります⁴。使えなくなる話と、延長できなくなる話は別物として扱う必要があります。

変更の入口を4つに分けて見積もります

案件を見積もるときは、変更の入口をあらかじめ4種類に分けておくと、対応の重さを見誤りにくくなります。セキュリティ機能に関わる変更、ファームウェアや製品自体の更新、要件の大幅な改訂後の猶予期間満了、SBOMの脆弱性情報に基づく対応という4つの入口それぞれに、進む先と必要な手続きが対応しています。どの入口に当たるかを最初に切り分けることが、案件全体の負荷を見積もる出発点になります。表にまとめると、次のとおりです。

変更の種類	該当する内容	必要になる手続き
セキュリティ機能等の変更	★3適合評価の結果に影響を及ぼす変更	評価機関での再評価が必要になる場合がある2
ファームウェア・製品の更新	有効期間内のファームウェア更新や製品の更新・変更	IPAのホームページを参照して個別に対応する3
要件の大幅な改訂後	猶予期間（旧版と並存する移行期間）の終了	延長申請は行えず、再認証が必要になる4
SBOMの脆弱性情報に基づく対応	サポート期間内の定期的な脆弱性確認	優先度を判断したうえで更新か運用対処を選ぶ6

4つの入口を分けて見ると、変更のたびに評価機関へ持ち込む案件ばかりではないことが分かります。次の章では、この中でも出荷後の管理に直結する部品表の扱いを見ていきます。

3. 部品表は、出荷後のために作ります

一意に識別できる部品表を、更新し続けます

部品表という言葉から、開発段階で1回作成して終わる資料を思い浮かべる案件担当者は少なくありません。ところがセキュリティ要件S3.1-15では、サードパーティコンポーネントを含む一意に識別可能なソフトウェア部品表を、製品出荷後の運用フェーズにおける既知の脆弱性管理のために作成し、サポート期間内において更新することが基準の1つとして挙げられています⁵。作って終わりにできる資料ではなく、稼働している間ずっと動かし続ける資料だという理解が必要です。

更新だけでなく、その先の使い方も基準に含まれています。サポート期間内にSBOMの情報に基づいて定期的に脆弱性の確認を行い、対応優先度を判断したうえで更新あるいは運用対処等を行うプロセスを持つことが求められます⁶。加えて、同じSBOMの情報に基づいて使用するコンポーネントのライセンス管理を行うプロセスを持つことも基準の1つです⁷。部品表は脆弱性の管理台帳であると同時に、ライセンスの管理台帳としても機能します。1つの資料に2つの役割が乗っている分、更新の抜けはどちらの管理にも響きます。

部品表の運用を軽く見積もると、稼働後に想定を超える工数が発生しやすい領域です。開発時点で一度作成した後は更新が滞りがちな資料だからこそ、サポート期間内の更新体制を、あらかじめ案件の役務範囲に含めて協議しておく必要があります。作成した瞬間よりも、更新が止まった瞬間のほうが、この要件では問題になります。

1回作る労力よりも、更新とライセンス管理を回し続ける体制のほうが、案件の継続稼働に直結します。見積もりの段階で、この3つの基準がそろっているかを確かめておく価値があります。

出典：独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」（2026年2月）をもとに作成

4. 直せないときは、運用で対処します

更新できない場合の選択肢も、基準に組み込まれています

脆弱性を見つけたら、その場ですぐに更新できるとは限りません。稼働中の機器に手を入れられない事情や、更新の反映に時間がかかる事情は、案件によって異なります。ここで押さえておきたいのは、SBOMの情報に基づいて対応優先度を判断したうえで「更新あるいは運用対処等を行うプロセス」を持つことが基準に挙げられている点です⁶。更新一辺倒の設計ではなく、運用対処という選択肢があらかじめ用意されています。

更新に進むか運用で受け止めるかを分けるのは、コンポーネントそのものよりも優先度の判断です。優先度が高く、既存の仕組みに反映しやすい変更は更新に進みやすく、反映に時間や調整を要する変更は、当面のあいだ運用対処で影響を抑える形になります。どちらを選ぶにせよ、判断の記録をSBOMに残す姿勢が問われます。

直せる変更と、運用で受け止める変更

更新と運用対処のどちらに進むかは、対応優先度の判断を軸に整理できます。優先度をどう見立てるかによって、次に取る行動が変わることを、あらかじめ案件の想定に含めておくと、稼働中の判断で迷いにくくなります。

対応優先度の判断	選べる対応
優先度が高く、更新の反映がすぐに行える	SBOMの情報に基づいて更新する
優先度は高いが、更新の反映に時間や調整を要する	運用対処等でリスクを抑えながら判断を継続する

この判断をそのつどその場で下すのではなく、着手前に判断基準をどう合意しておくかが、稼働後の負荷を左右します。優先度の物差しが曖昧なまま進めると、本来は更新すべき変更まで運用対処に流れてしまい、あとで対応が追いつかなくなる恐れがあります。

更新できることよりも、対処の選択肢を残していることのほうが、稼働を止めない案件設計につながります。この選択の記録が、後の章で見る文書化の要件にもつながっていきます。

5. 文書は作るだけでなく保管します

文書化の要件は、保管までを含みます

要件のカテゴリの1つである「文書化する」は、製品開発ライフサイクルにおけるセキュリティ関連文書の作成及び保管を求める対策です⁸。作成という言葉だけを見ると、開発段階の成果物として書き上げれば終わるように読めますが、保管まで含めて1つの対策として扱われている点が、この要件の特徴です。

文書を書き上げる作業よりも、あとから示せる状態を保ち続ける作業のほうが、この要件では重視されています。設計段階の記録も、出荷後に更新した記録も、同じ扱いで保管の対象になると考えておくと、あとから慌てて資料をかき集める事態を避けやすくなります。

出典：独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」（2026年2月）をもとに作成

保管の対象になる文書は、設計書だけに留まりません。テストの結果や、更新あるいは運用対処のどちらを選んだかという判断の記録も、同じセキュリティ関連文書として扱われます。前の章で見た運用対処の判断も、ここでは保管すべき記録の一部として位置づけられます。

作成した文書を保管し続ける体制よりも、途中で保管が途切れる体制のほうが、あとになって手戻りを生みます。次の章では、文書化と並ぶもう1つのカテゴリとして、分析と実装、テストの関係を見ていきます。

6. 実装しただけでは要件を満たしません

分析・実装・確認の3つがそろって、要件になります

要件のカテゴリの1つである「脅威を特定しテストする」は、製品の利用上想定される脅威を分析し、必要なセキュリティ機能が実装されていることをテストして確認し、セキュリティリスクを低減するための対策です¹⁰。分析だけで終わらせず、実装したうえでテストによる確認までを1セットとして求めている点が要点です。実装しただけでは、この要件を満たしたことにはなりません。

もう1つのカテゴリである「製品に関する情報提供を行う」は、製品を安全に利用するために必要な情報をユーザへ提供することを求める対策です⁹。分析・実装・テストが機器そのものの安全性を作る工程だとすれば、情報提供は、その安全性を使う側に伝える工程だといえます。両者がそろって、出荷後も安全に使い続けられる状態が成立します。

案件の役務範囲を協議する際は、分析・実装・確認という3つの工程を、別々の成果物として契約に書き込めるかどうかが手がかりになります。「実装しかしていない」というすれ違いは、この3工程をひとまとめに扱った見積もりから生まれやすいものです。

3つの工程を別の成果物として扱います

脅威を特定しテストする要件は、1つの作業ではなく3つの工程の連なりとして読み解けます。分析で想定する脅威を洗い出し、実装でセキュリティ機能を組み込み、テストで機能が働くことを確認するという3段の対応が、それぞれ独立した成果物として扱われます。案件の見積もりでも、この3段を別工程として扱うかどうかが工数の見え方を左右します。分析だけを担う案件もあれば、実装からテストまでを一括して担う案件もあり、担う範囲によって求められる進め方は変わります。

工程	内容
分析	製品の利用上、想定される脅威を分析する
実装	リスクを低減するための必要なセキュリティ機能を実装する
確認	実装した機能が働くことをテストして確認する

出典：独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」（2026年2月）をもとに作成

分析の緻密さよりも、実装からテストまでを1セットで終える体制のほうが、要件全体を満たすうえでの土台になります。ここまで見てきた文書化、情報提供、脅威分析とテストという3つのカテゴリは、いずれも実装の外側にある作業であり、実装工数だけで案件を見積もると抜け落ちやすい部分です。

7. よくある質問

評価機関の再評価は、どんな変更でも必要になりますか

そうとは限りません。再評価が必要になる場合があるのは、セキュリティ機能等の変更が★3適合評価の結果に影響を及ぼす場合です²。ファームウェアの更新やIoT製品への更新、変更等については、別途IPAのホームページを参照して個別に対応する扱いになっています³。変更の中身によって進む先が分かれるという前提を押さえておくと、見積もりの精度が上がります。案件を受ける前に、想定している変更がどちらの入口に当たるのかをクライアントと擦り合わせておくと、稼働後の認識違いを防ぎやすくなります。

猶予期間が終わったら、ラベルはすぐに使えなくなりますか

猶予期間が終了しても、その場でラベルが使えなくなるわけではありません。変わるのは有効期間の延長のほうで、猶予期間後は延長の申請ができず、★3適合ラベル付与の再認証が必要になります⁴。使えなくなる話と、延長できなくなる話を混同しないことが、案件の対応スケジュールを組むうえで重要です。再認証に向けた準備をいつから始めるかは、猶予期間の残り時間を踏まえて逆算しておく必要があります。

SBOMは脆弱性を見つけたら、更新しないといけませんか

更新だけが選択肢ではありません。サポート期間内にSBOMの情報に基づいて定期的に脆弱性を確認し、対応優先度を判断したうえで、更新あるいは運用対処等を行うプロセスを持つことが基準として挙げられています⁶。更新に進むか運用で受け止めるかは、対応優先度の判断によって分かれる建て付けです。どちらを選んだかという判断そのものも、あとから示せる記録として残しておく姿勢が求められます。

IoT機器のセキュリティ要件に関わる案件は、リモートで進められますか

案件の90%以上がフルリモート可能です¹¹。SBOMの更新や文書の保管、テストによる確認といった作業は、実機の検証環境が必要な工程を除けば、拠点を問わず進めやすい性質を持っています。出荷後まで見据えた対応を積み重ねてきた経験は、こうした案件で条件を協議する材料になります。実装だけでなく、この記事で見た運用フェーズの視点を語れることが、参画先を選ぶ際の強みになります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件（2026年2月）
＊2 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件（2026年2月）
＊3 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件（2026年2月）
＊4 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件（2026年2月）
＊5 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件 S3.1-15（2026年2月）
＊6 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件 S3.1-15（2026年2月）
＊7 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件 S3.1-15（2026年2月）
＊8 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件 カテゴリ18（2026年2月）
＊9 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件 カテゴリ17（2026年2月）
＊10 独立行政法人情報処理推進機構「セキュリティ要件適合評価及びラベリング制度」通信機器レベル3セキュリティ要件 カテゴリ16（2026年2月）
＊11 Remoguサイト公開情報（案件の90%以上がフルリモート可能）