「社内のセキュリティ対策はNIST CSFの機能別に整理してあります」。そう答えられる状態にある企業は、SCS評価制度への対応でも有利な位置に立っています。機能ごとに現状を並べた表がすでにあり、どこが薄いかも把握できているからです。

ところが、その表をそのままSCS評価制度に持ち込むと、早い段階で手が止まります。SCS評価制度が使っているのは大分類7つという別の切り方で、NIST CSFの6機能とは名前も数も一致しません。どちらかに寄せて並べ替えれば済む話ではなく、2つの軸がそれぞれ何を数えているのかを先に分けておく必要があります。

この記事では、IPAが公開している要求事項・評価基準のデータを集計し、NIST CSFの機能別に評価基準の件数を並べました。★3の81件と★4の153件が6機能へどう配分されているのか、★3から★4へ上がるときにどの機能が増えるのか。件数で見ると、制度が実際にどこへ重心を置いているかがはっきりします。基準日は2026年9月15日です。

結論を先に書くと、件数は防御(PR)に大きく偏っています。★3では81件のうち48件、★4では153件のうち82件。どちらも半分を超えます。「SCS対応とは規程や文書を整える作業だ」という一般的な受け止め方とは、ずいぶん違う形をしています。

SCS評価制度とNIST CSFは別の切り方｜まず軸を分ける

SCS評価制度の大分類7つとNIST CSFの6機能は、対応づけて読むことはできますが、同じ軸として混ぜて数えることはできません。ここを曖昧にしたまま作業を始めると、あとから件数が合わなくなります。

NIST CSF 2.0が並べる6つの機能

NIST CSFは、セキュリティ対策を機能という単位に分けて整理するための枠組みです。2.0では統治(GV)・識別(ID)・防御(PR)・検知(DE)・対応(RS)・復旧(RC)の6つが置かれています。統治(GV)は2.0で加わった機能で、それ以前は識別から復旧までの5つでした。

特徴は、統制項目の網羅リストではなく整理の器である点です。自社の対策を機能ごとに並べ、現在の姿と目標の姿を突き合わせる。使い方が決まっているというより、使い方を自分で決める枠組みだと言えます。

SCS評価制度が使う大分類7つ

一方のSCS評価制度は、要求事項と評価基準を大分類7・中分類16で構成しています。大分類は、ガバナンスの整備、取引先管理、リスクの特定、攻撃等の防御、攻撃等の検知、インシデントへの対応、インシデントからの復旧の7つです。

並べてみると、NIST CSFの6機能とよく似た顔ぶれになっています。ただし取引先管理だけは、CSF側に同じ名前の機能がありません。サプライチェーンを主題に置いた制度なので、取引先の管理を独立した大分類として立てたと読むのが自然です。

制度の全体像や★3・★4の位置づけそのものは、SCS評価制度の全体像を先に押さえておくと、この先の話が追いやすくなります。

7つと6つはどう重なるのか（ジョーシス独自の整理）

大分類7つをNIST CSFの6機能へ対応づけると、次のようになります。なお、この対応づけは制度が定めたものではありません。IPAが公開している大分類を、ジョーシスがNIST CSFの機能へ独自に対応づけたものです。

6つの機能に対して大分類が7つあるのは、取引先管理が独立しているためです。NIST CSFではサプライチェーンのリスク管理を統治(GV)の配下に置いているため、対応づけの上では取引先管理も統治(GV)に合流します。★3ではガバナンスの整備8件と取引先管理4件を合わせて12件、★4では19件と7件を合わせて26件になります。

ここが読み替えの最初のポイントです。CSF側の整理表で統治(GV)を見たとき、そこに取引先の管理まで含まれているかどうか。含まれていなければ、SCS評価制度の側では独立した大分類ぶんがまるごと空くことになります。

参考：IPA SCS評価制度 要求事項・評価基準

NIST CSF機能別の件数分布｜★3の81件と★4の153件（ジョーシス独自の整理）

この機能別の対応づけは、制度が定めたものではありません。IPAが公開している評価基準を、ジョーシスがNIST CSFの機能へ独自に対応づけたものです。

前の表を機能ごとにまとめ直すと、SCS評価制度が何にどれだけの基準を置いているかが1枚で見えます。

この件数分布は、IPAが公開している要求事項・評価基準をジョーシスが集計し、NIST CSFの機能へ対応づけたものです。制度側が機能別の件数を公表しているものではありません。構成比は小数第1位を四捨五入しています。

数字を追うと、いくつかの特徴がすぐに読み取れます。

第一に、防御(PR)が突出しています。★3では59%、★4でも54%。2位以下を大きく引き離した水準です。

第二に、検知(DE)と復旧(RC)が極端に少ない。★3では検知が3件、復旧が1件で、合わせても4件しかありません。81件のうちの4件です。

第三に、★3と★4で構成比の形はさほど変わりません。防御(PR)の比率が59%から54%へ下がり、識別(ID)が14%から19%へ上がる。この2点が主な変化で、全体の輪郭は保たれています。

統治(GV)の12件は自社のガバナンスだけではない

機能別の表だけを見ると、統治(GV)が12件あるように読めます。ただし、この12件はガバナンスの整備8件と取引先管理4件を足した数です。自社の体制や方針に関する基準は8件で、残る4件は取引先に関するものになります。

この違いは実務に直結します。統治(GV)の対応を情報セキュリティ委員会だけで進めようとすると、取引先管理の4件が誰の担当にもならないまま残ります。取引先の★の状況を確認する、契約に求める水準を織り込む、といった作業は購買や法務との連携が前提になるためです。

機能別で議論するときは、統治(GV)を必ず2つに割って見ることをおすすめします。SCS評価制度が大分類を7つに分け、取引先管理を独立させているのは、この2つが別の部門で回る作業だからだと読むこともできます。

評価基準の条文と件数を往復する

評価基準1件ずつが具体的に何を求めているかは、★3の要求事項26と評価基準81の全一覧に項目単位で整理しています。件数の分布と実際の条文を行き来しながら読むと、精度が上がります。

参考：IPA SCS評価制度 ★3・★4 要求事項及び評価基準（Excel・2026年4月21日版／2026年9月15日取得）

防御(PR)への集中が意味すること

以下の機能別の件数も、前述のとおりジョーシスが独自に対応づけて集計したものです。制度が定めた区分ではありません。

★3の評価基準81件のうち48件が防御(PR)です。割合にすると59%。SCS評価制度への対応を計画するとき、この一点を押さえているかどうかで見積もりが変わります。

「規程を整える制度」という理解とのずれ

制度対応と聞いて最初に思い浮かぶのは、規程の作成と改訂、体制図の整備、承認フローの明文化といった文書側の作業ではないでしょうか。ISMSやプライバシーマークへの対応で、その進め方に慣れているケースも多いはずです。

ところが件数で見ると、文書側に寄る統治(GV)は★3で12件、全体の15%にとどまります。残る大半は、何かを設定し、何かを制限し、その状態を示すという技術的な実装の側にあります。規程を全部そろえても、埋まるのは7分の1程度という計算になります。

この構造を最初に共有しておかないと、社内の計画が文書作成に偏ります。そして実装側の工数が後半に集中し、証跡の準備が間に合わなくなります。

防御(PR)の48件は何を指しているのか

防御(PR)に入る基準は、管理者IDとユーザIDの管理、認証の強度、アカウントのロック、端末の資産把握、マルウェア対策、構成管理、パッチの適用、ネットワークの境界防護、バックアップの取得といった領域に広がっています。どれも「導入しているかどうか」ではなく「どういう状態で運用されているか」を問う形です。

ここが実務上いちばん効いてきます。ファイアウォールもEDRも入っている。IdPも使っている。それでも、いま誰にどの権限が付いているかを一覧で出せるか、退職者のIDが残っていないことを示せるか、という問いには別の準備が要ります。防御(PR)の48件は、製品の有無ではなく状態の可視化を求めていると読むのが実態に近い。

かつては、年に一度の資産棚卸しで台帳を更新し、その間の変更を差分で追いかける運用が一般的でした。製品を導入した事実と設定を入れた事実が記録に残っていれば、対策としては説明できたからです。現在は各システムのAPI経由で利用実態を取得できるようになり、いま現在の状態をそのまま出せる形に寄せられます。48件の多くは、この形に近づけておくほど証跡の準備が軽くなります。

もう一点、防御(PR)は担当が分散しやすい領域でもあります。IDと認証は情報システム部門、端末はヘルプデスク、ネットワークはインフラ担当、バックアップは別のベンダー。48件を1つの表に集めた段階で、誰も全体を見ていなかったことに気づくケースは珍しくありません。件数の多さは、そのまま関係者の多さでもあります。

対応(RS)と復旧(RC)が薄い理由をどう読むか

対応(RS)は★3で6件、復旧(RC)は1件です。インシデント対応や事業継続を重視している企業ほど、この少なさに違和感を持つかもしれません。

ただ、件数が少ないことと重要度が低いことは別です。制度が評価しているのは「インターネットに接続する自社IT基盤」の対策状況であり、事業継続計画そのものの精度を測る制度ではありません。件数の少なさは、制度の射程がどこまでかを示していると読むほうが正確です。

参考：IPA SCS評価制度 詳細情報

★3から★4で増える72件はどこに入るのか（ジョーシス独自の整理）

ここで示す機能別の増分も、制度が定めたものではありません。IPAが公開している評価基準を、ジョーシスがNIST CSFの機能へ独自に対応づけて集計したものです。

★3の81件と★4の153件の差は72件です。この72件がどの機能に配分されているかを見ると、★4を目指す場合に何が追加で必要になるかが具体的になります。

この増分も、IPA公開の要求事項・評価基準をジョーシスが集計しNIST CSFの機能へ対応づけた結果です。制度が機能別の増分を公表しているものではありません。

件数で見れば防御、伸び率で見れば検知と識別

以下の機能別の件数も、前述のとおりジョーシスが独自に対応づけて集計したものです。制度が定めた区分ではありません。

増える72件のうち34件、およそ半分が防御(PR)です。絶対量で最も重いのは変わらず防御になります。

ところが伸び率で並べると順番が入れ替わります。検知(DE)が2.7倍、識別(ID)が2.6倍。防御(PR)は1.7倍で、全体平均の1.9倍を下回ります。★4で新しく問われる比率が高いのは、防御ではなく検知と識別のほうです。

すでに★3相当の対策を積んできた企業にとって、防御(PR)の34件は既存の延長線上で埋められる部分が比較的多い。一方、検知(DE)と識別(ID)は、そもそも取り組み自体が薄いところから2.6倍に増えます。ここが★4の難所になります。

識別(ID)が11件から29件へ増えることの実務的な意味

識別(ID)の18件増は、増分72件の4分の1にあたります。★3の段階では11件しかなかったものが、★4では29件になる。

識別(ID)が問うのは、自社が何を持っているかを把握できているかどうかです。端末、SaaS、アカウント、ネットワーク機器、そして取引先。この把握が★4では大幅に細かくなります。棚卸しの頻度、把握する項目、把握できていない領域の扱い。★3の段階でも、資産台帳の維持は常時、全アクセス権の棚卸は年1回と頻度が決められています。★4ではこの把握の範囲と粒度がさらに広がると考えておくのが安全です。

把握の対象と粒度については、SCS評価制度が求めるIT環境の把握で領域ごとに扱っています。

対応(RS)だけが増えない

6機能のうち、★3から★4へ1件も増えないのは対応(RS)だけです。6件のまま変わりません。

これは読み替えの際に覚えておくと便利な特徴です。インシデント対応の手順や体制をすでに整えている企業は、★4を目指す判断をしても、この領域では追加の負荷がかかりません。逆に言えば、対応(RS)を手厚くしても★4への距離は縮まりません。

検知(DE)は★3で3件・★4で8件｜新規投資になりやすい領域

この機能別の件数も、前述のとおりジョーシスが独自に対応づけて集計したものです。制度が定めた区分ではありません。

6機能のなかで、対応の空白が生まれやすいのが検知(DE)です。件数だけを見れば復旧(RC)に次いで小さい機能ですが、★3と★4で性格が変わるため、投資判断が必要になりやすい領域でもあります。

★3の3件は最低限の監視にとどまる

★3の検知(DE)は3件しかありません。81件のうちの3件、構成比では4%です。求められているのは、認証ログの監視を月1回行うこと、不審な認証試行を点検すること、ネットワーク機器のログを分析してインシデントに該当するかどうかを人が判断すること。この範囲におさまります。

常時監視の仕組みまでは求められていません。ログを取り、決められた頻度で見て、判断した記録を残す。★3の段階ではこの形で成立します。

★4では8件に増え、性格が変わる

★4になると8件です。件数は5件しか増えていませんが、★3比で2.7倍という伸びは6機能のなかで最大になります。

ここが投資判断の分かれ目です。★3の3件は、既存のログと月1回の運用でおおむね対応できます。ところが2.7倍に増えた領域を人手の点検だけで埋めようとすると、頻度と対象範囲の両方で無理が出ます。検知の仕組みそのものを持っていない企業にとって、★4の検知(DE)は新しい投資として立ち上がりやすい領域です。

計画を作るときは、この点を先に切り分けておくことをおすすめします。★3までは運用の設計で足りるのか、★4を見据えて検知の基盤から入るのか。後者であれば、予算の確保が必要になる時期が変わります。

復旧(RC)は★3で1件・★4で2件

検知(DE)と並んで薄いのが復旧(RC)です。★3で1件、★4で2件。バックアップの取得とリストアのテストが中心になります。

件数は少ないものの、記録が残っていなければ証跡になりません。バックアップは取得しているがリストアのテストを実施した記録がない、という状態は珍しくないのではないでしょうか。1件だからこそ、抜けたときに埋め合わせがききません。

NIST CSFの機能別に並べた現状を、評価のときに提出できる証跡へどう変えていくか。ID・デバイス・SaaSを一元管理する考え方をまとめた資料が参考になります。

5分でわかるジョーシスの資料をダウンロードする

すでにNIST CSFで整理している企業の読み替え手順

ここからは実務です。CSFの整理表が手元にある前提で、SCS評価制度の側へ寄せていく順番を4段階に分けます。以下の手順で使う機能別の件数も、前述のとおりジョーシスが独自に対応づけて集計したものです。制度が定めた区分ではないため、社内で共有するときは出どころを添えてください。

手順1｜機能別の件数を自社の整理表に重ねる

最初にやるのは、本記事の件数分布を自社のCSF整理表へ列として足すことです。統治(GV)12、識別(ID)11、防御(PR)48、検知(DE)3、対応(RS)6、復旧(RC)1。★3を目指すならこの数字を並べます。

この作業だけで、自社の整理表の重みと制度側の重みのずれが見えます。6機能を横並びの枠として扱っている整理表であれば、SCS評価制度の重みは均等ではないという点がそのままずれになります。防御(PR)の欄に自社の記載が1行しかないなら、その1行を48件ぶんの粒度へ割り直す作業が待っています。

手順2｜統治(GV)から取引先管理を切り出す

次に、統治(GV)の中身を2つに分けます。自社のガバナンス（体制・方針・教育・点検）と、取引先の管理です。SCS評価制度では別の大分類になるため、切り分けておかないと後で対応表が作れません。

取引先管理は★3で4件、★4で7件です。件数としては小さいものの、この4件はCSFの整理表で最も書かれていない領域でもあります。取引先の★の状況を年1回確認する、といった運用はSCS評価制度に固有のものだからです。

サプライチェーンを起点にした攻撃の実際の経路については、サプライチェーン攻撃の対策と国内事例に国内の事例を整理しています。

手順3｜防御(PR)を証跡の出せる形に割り直す

3つ目が最も時間のかかる工程です。CSFの整理表では「多要素認証を導入済み」「EDRを全端末に展開済み」といった粒度で書かれていることが多いのですが、SCS評価制度の防御(PR)48件は、その一段下を問います。

たとえば導入済みと書かれた多要素認証について、対象は全アカウントか、管理者IDは例外になっていないか、例外があるなら承認の記録はあるか。この粒度まで下ろしたとき、初めて評価基準と突き合わせられる形になります。

割り直しの単位は、製品ではなく状態です。何を入れたかではなく、いまどういう状態にあり、それをどこから出せるか。この観点で書き換えていくと、あとの証跡収集がそのまま続きます。

手順4｜検知(DE)と復旧(RC)の空白を確認する

最後に、件数の少ない2機能を確認します。★3では合わせて4件しかないため見落とされやすいのですが、4件とも記録の有無で判定される性格を持っています。

認証ログを月1回見ているか。見た記録があるか。リストアのテストをしたか。した記録があるか。実施していても記録の様式が決まっていないと証跡になりません。件数が少ない領域ほど、記録の型を先に決めておく効果が大きくなります。

参考：IPA サプライチェーン強化に向けたセキュリティ対策評価制度

どの機能から着手すると効率が良いか

以下の機能別の件数も、前述のとおりジョーシスが独自に対応づけて集計したものです。制度が定めた区分ではありません。

4つの手順を踏まえて、着手の順番を整理します。件数の多い順とは一致しません。

識別(ID)を先頭に置いているのは、防御(PR)の48件が「対象がそろっていること」を前提にしているためです。端末の一覧が不完全なままパッチ適用率を出しても、母数が信用できません。SaaSの一覧が不完全なまま権限の棚卸しをしても、棚卸し漏れが残ります。

つまり、件数が最も多いのは防御(PR)でも、最初に着手すべきなのは識別(ID)になります。ここを逆にすると、防御の作業をひととおり終えたあとで対象の追加が見つかり、やり直しになります。

一方で、統治(GV)の12件は他の機能と並行して進められます。既存のISMS文書やセキュリティポリシーを出発点にできるためです。ただし前述のとおり、12件のうち4件は取引先管理にあたります。ここだけは文書の流用が効きにくく、購買や法務を巻き込む時間を別に見ておく必要があります。

リスクの特定にあたる識別(ID)の進め方そのものは、セキュリティリスクアセスメントの手法に手順として整理があります。評価基準へ当てる前に、自社が何をリスクとして扱っているかを一度そろえておくと、識別(ID)の11件を埋める作業が短く済みます。

なお、この順番は★3を目指す場合の目安です。★4を視野に入れているなら、検知(DE)の位置を4番目から2番目へ繰り上げる判断があります。★4の検知(DE)は8件で★3比2.7倍になり、仕組みの導入が必要になれば予算化と構築に時間がかかるためです。順番を決める基準は件数ではなく、着手から証跡が出るまでのリードタイムのほうだと考えるとぶれません。

読み替えるときに陥りやすい3つの落とし穴

最後に、CSFからSCS評価制度へ読み替える過程で実際につまずきやすい点を3つ挙げます。

落とし穴1｜機能名が同じでも問う粒度が違う

最も多いのがこれです。CSFの整理表で防御(PR)に「対策済み」と書いてある項目が、SCS評価制度の評価基準では複数件に分解されている。この差を吸収せずに対応表を作ると、埋まっているように見えて実際は埋まっていない状態になります。

対策としては、CSFの1行に対してSCSの評価基準が何件ぶら下がるかを先に数えることです。1対1で対応する前提を捨てると、作業の見積もりが現実に近づきます。

落とし穴2｜CSFのティアとSCSの★を対応させてしまう

NIST CSFには実装の状況を段階で示す考え方があり、SCS評価制度にも★の段階があります。名前の構造が似ているため、ティアが上なら★も上、という対応を作ってしまうことがあります。

この2つは測っているものが違います。★3と★4を分けるのは成熟度の自己評価ではなく、要求事項の件数（26と43）と評価の方法です。★3は専門家の確認と署名を伴う自己評価、★4は第三者評価に実地審査と技術検証が加わります。社内説明でティアと★を並べると、後から訂正が必要になります。

落とし穴3｜整理表がそのまま証跡になると考える

3つ目は、CSFで作った整理表を提出すれば済むという見立てです。

SCS評価制度で評価されるのは、対策を実施していることではなく、実施を示せる記録です。整理表は自社の現在地を把握するための資料であり、それ自体が証跡になるわけではありません。日付、対象、実施者、内容。この4つがそろった記録が別に要ります。

CSFで整理済みの企業ほど、現在地の把握は進んでいます。だからこそ、次に必要なのは把握を記録へ変える工程だと切り替えておくと、準備の順番を間違えずに済みます。

なお、ISMSやプライバシーマークとSCS評価制度の関係について、2026年9月15日時点で公式な整理は公表されておらず、免除規定も確認できません。既存の枠組みで作った文書や記録が証跡として使える場面はありますが、そのまま通ると考えないほうが安全です。

よくある質問

NIST CSFで整理していれば、SCS評価制度の準備はどこまで進んでいると考えてよいですか

現在地の把握は進んでいますが、証跡の準備はこれからになります。CSFの整理表は自社の対策状況を機能別に並べた資料であり、評価で求められるのは実施を示す記録のほうです。整理表の各行を評価基準の粒度へ割り直し、記録の様式を決める工程が別に必要になります。

ISO/IEC 27001で整理している場合もNIST CSFに読み替えたほうがよいですか

必須ではありません。NIST CSFへの読み替えが有効なのは、すでにCSFの機能別で整理している場合です。ISO/IEC 27001の管理策で整理しているなら、そのままSCS評価制度の大分類7つへ突き合わせるほうが早く終わります。中間に別の枠組みを挟むと、対応関係の確認が一段増えます。

評価基準の件数が多い機能から対応すればよいのですか

件数の多さと着手の順番は一致しません。★3で最も件数が多いのは防御(PR)の48件ですが、先に識別(ID)を固めておかないと、防御の評価に使う対象の一覧が確定しません。端末やSaaSの把握が不完全なまま防御の作業を進めると、あとから対象が増えてやり直しになります。

機能別の件数はIPAが公表しているものですか

IPAが公表しているのは要求事項と評価基準そのものです。本記事の機能別件数は、その公開データをジョーシスが集計し、NIST CSFの機能へ対応づけたものになります。制度が定めた区分ではないため、社内資料に転記する際は集計の出どころを併記しておくと、後の説明で齟齬が出ません。

まとめ

SCS評価制度をNIST CSFの機能別に読み替えるとき、押さえておきたい点は3つです。以下の件数は、前述のとおりIPA公開の要求事項・評価基準をジョーシスが集計しNIST CSFの機能へ独自に対応づけたものです。制度が機能別の件数を公表しているものではありません。

1つ目は、2つの軸を混ぜないこと。SCS評価制度は大分類7つ、NIST CSFは6機能で、取引先管理だけがCSF側では統治(GV)に合流します。対応づけて読むことはできますが、同じ軸として並べて数えることはできません。

2つ目は、件数が防御(PR)に偏っていること。★3では81件中48件で59%、★4では153件中82件で54%。「規程を整えれば対応できる」という理解のままだと、実装側の工数が計画から抜け落ちます。

3つ目は、★4を目指す場合に効いてくるのが検知(DE)と識別(ID)だということ。増える72件の絶対量では防御(PR)が最大ですが、伸び率は検知(DE)が2.7倍、識別(ID)が2.6倍で、防御(PR)の1.7倍を上回ります。検知の仕組みを持っていない企業にとって、ここは新しい投資として立ち上がります。

着手の順番は、識別(ID)から始めて防御(PR)へ進み、統治(GV)を並行させる形が現実的です。件数の多い順ではなく、前提が確定する順に進めると手戻りが減ります。

ジョーシスでは、ITデバイスとSaaS、アカウント情報を一元管理し、評価のときに提出できる証跡として蓄積する仕組みを提供しています。識別(ID)と防御(PR)を機械的にどこまで把握できるか確認したい場合は、資料をご覧ください。

5分でわかるジョーシスの資料をダウンロードする

関連記事：IT資産台帳の作り方と運用ルール

関連記事：ISMS対応で押さえる統制と実装ステップ