「SCS評価制度に向けて、まず資産管理から手をつけよう」。社内でそう決まったところまでは早くても、そこから先で止まるケースをよく見ます。台帳ならある。Excelで管理している。ただ、それを制度の評価の場に出せるかと問われると、自信を持って「はい」と言えない。理由は、たいてい台帳の中身ではなく、台帳の作られ方にあります。

SCS評価制度が資産管理に対して求めているのは、一覧があることではありません。把握するための仕組みが整っていること、そしてその仕組みが回っていることです。この違いは条文を読むとはっきり出てきます。

この記事では、★3の評価基準81件のうち「リスクの特定」に分類される11件を軸に、制度側が何を「把握できている状態」とみなすのかを整理します。あわせて、従来のIT資産管理でSaaSとIDが抜け落ちる構造的な理由、申請ベースの台帳運用と利用実態ベースのツール運用の違い、そしてジョーシスが受け持てる範囲とそうでない範囲を分けて示します。基準日は2026年9月15日です。

制度そのものの全体像から確認したい場合は、SCS評価制度とは｜制度の全体像を先に読むと、この記事の位置づけが掴みやすくなります。

SCS評価制度が求めるIT資産管理とは｜★3の「リスクの特定」11基準

SCS評価制度が求めるIT資産管理とは、自社が使っている機器・ネットワーク・外部サービス・機密情報を把握する仕組みを整備し、その状態を維持することです。

★3の評価基準81件は7つの大分類に配分されており、「リスクの特定」はそのうち11件を占めます。件数だけ見ると全体の14%程度で、48件が集中する「攻撃等の防御」の陰に隠れがちな領域です。ところが実務で最初につまずくのはここになります。

★3の「リスクの特定」11件は、すべて資産管理に入る

まず押さえておきたい構造があります。「リスクの特定」という大分類には、中分類として「資産管理」と「リスクアセスメント」が置かれています。このうち★3で問われるのは資産管理の側だけです。脆弱性情報の収集体制や対応履歴の月次点検といったリスクアセスメントの中分類は、★4から立ち上がります。

つまり★3の段階では、リスク分析の手法を整えることは求められていません。求められているのは、分析の前提になる「自社に何があるか」を出せる状態です。ここを取り違えて、リスクアセスメント手順書の作成から着手してしまうと、★3の11件は一つも埋まりません。

11件が具体的に求めていること

11件を要求事項の単位でまとめると、次の4つになります。

表にすると穏当に見えますが、条文を読むと特徴のある言い回しが繰り返し出てきます。「把握するための仕組みを整備すること」です。一覧を作れ、とは書かれていません。

「仕組み」と書かれていることの意味

ここが、従来の資産棚卸しとの分かれ目になります。

年に一度の棚卸しでExcelを更新する運用でも、その瞬間の一覧は作れます。ただ、それは仕組みではなく作業です。仕組みと呼べる状態は、情報がどこから来て、どの頻度で更新され、いつ時点のものかを説明できることを指します。評価の場で「この台帳の最終更新はいつですか」「更新は誰の作業に依存していますか」と問われたときに、手が止まらない形になっているかどうか。

11件のうち2件が「年1回以上の頻度で点検すること」という独立した基準になっている点も、同じ方向を向いています。ルールを定めただけでは基準を満たさず、そのルールが守られているかを毎年確かめた記録まで求められます。

要求事項と評価基準の全体像を項目単位で確認したい場合は、★3の要求事項26と評価基準81の全一覧にまとめています。

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

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

資産インベントリで問われるのは「把握するための仕組み」

資産インベントリという言葉は広く使われていますが、SCS評価制度の文脈では中身が一段絞られます。問われるのは網羅性と鮮度、そしてその2つを示せるかどうかです。

申請ベースの台帳は、抜けを検知できない

多くの企業のIT資産台帳は、申請と報告を起点に作られています。新しいPCを配布したら台帳に追記する。部署からSaaSの利用申請が上がったら記録する。この運用は、申請が正しく出ている限りは成立します。

問題は、申請が出なかったものを検知する手段が台帳側にないことです。台帳に載っていない端末やサービスは、台帳の上では存在しないことになります。網羅性を自分で確かめられない構造になっている、と言い換えることもできます。

評価の場で問われるのは、まさにこの点です。「把握するための仕組み」という表現は、申請という人の行動に依存しない経路があるかどうかを問うている、と読むのが自然ではないでしょうか。実際、ネットワーク機器についても「把握するための仕組みを整備すること」と書かれており、そこには製造元・モデル・保守事業者まで含めるよう指定されています。申請書に書かれていない情報まで求められている、ということになります。

鮮度は「最終更新日」では示せない

もう一つが鮮度です。Excelの台帳には最終更新日の欄があるのが普通ですが、その日付は人が手で入れたものです。更新作業をした日なのか、情報を確認した日なのか、区別がつきません。

一方、システムから取得した台帳には取得日時が自動的に残ります。どの端末の情報がいつ取れたのか、取得できなかった端末はどれか、といった情報も同時に出せます。制度が想定している運用サイクルでは、資産台帳の維持は「常時」に分類されています。年1回の作業では応えられない頻度です。

証跡になるのは、出力ではなく経路

ここで見落とされやすいのが、評価で見られるのは台帳そのものだけではないという点です。その台帳がどこから来たかまで説明を求められます。

たとえばCSVを提出したとして、それが手入力で作られたものか、管理ツールからエクスポートされたものかで、示せる意味がまったく違います。前者は作業の成果物であり、後者は仕組みの出力です。同じ体裁のファイルでも、評価の場での扱いは分かれます。

★3の自己評価で領域ごとにどんな記録が求められるかは、★3の自己評価で求められる証跡で具体的に整理しています。

81基準のなかで資産管理がどこに位置するか（ジョーシス独自の整理）

ここから使う分け方は、制度が定めたものではありません。IPAが公開している評価基準を、証跡をどう集めるかという観点でジョーシスが独自に整理したものです。

ジョーシスでは、★3の81基準を「証跡をどう集めるか」という軸で3つに分けて集計しています。システムで取る40件（49%）、文書で示す25件（31%）、人手で回す16件（20%）という内訳です。

そのうちシステムで取る40件の中身を見ると、次のようになります。

資産管理に直接かかわる領域、つまり端末・脆弱性とネットワークとSaaSを足すと20件になります。システムで取る40件の半分です。ID側の15件も、誰がどのアカウントを持っているかという意味では資産の把握と地続きになります。

なお、この3分類と40件の内訳は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではありません。

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

SaaSとIDが台帳から抜けるのはなぜか

資産台帳を持っている企業でも、SaaSのアカウントだけは台帳の外にある。この状態が非常に多く見られます。担当者の意識の問題ではなく、従来のIT資産管理の設計がそうなっているためです。

従来のIT資産管理はPCとサーバを数えるものだった

IT資産管理という言葉が定着した時期、管理の対象は物理的な資産でした。PCが何台あり、どこに置かれ、誰が使っているか。サーバのライセンスが何本で、保守契約はいつまでか。資産という言葉が示すとおり、購買と会計に紐づく世界です。

この設計では、購買を経由しないものは視界に入りません。SaaSの多くは部門のクレジットカードや少額の経費で契約が始まります。情報システム部門に申請が来ないまま利用が広がり、数か月後に請求書で初めて存在を知る、という順序になりがちです。

外部情報サービスの管理は、独立した要求事項として立っている

SCS評価制度がこの状況をどう見ているかは、要求事項の立て方に表れています。「外部情報サービスの管理」が、情報機器の把握とは別の要求事項として置かれているためです。

求められているのは2点あります。利用にあたってのセキュリティ要件を定め、実際のサービスがその要件を満たしているかを確認すること。そして、提供事業者と機密情報の取扱いについて合意を取り交わすことです。

この2点に答えるには、前提として「自社が何を使っているか」が出せなければなりません。要件を定めても、適用先の一覧がなければ確認のしようがない。つまり、SaaSの棚卸しは制度対応の入口に位置しています。

IDは、資産が消えても残る

もう一つ抜けやすいのがIDです。こちらは理由が少し違います。

PCは退職時に回収され、物として手元に戻ってきます。回収されなければ現物が足りないため、気づく機会があります。ところがアカウントは、回収という行為がありません。削除の操作をしない限り、そのまま生き続けます。

しかも、削除すべきアカウントの一覧は一か所にありません。人事システムには退職者の情報があり、各SaaSにはアカウントの情報があり、その2つを突き合わせる工程が人手に残っているのが通常です。この工程が月次のまとめ作業になっていると、退職から削除までの空白が日数として残り、その空白が記録に残ってしまいます。

制度側では、退職IDの速やかな削除は「常時」対応が求められる項目に位置づけられています。手順の設計とその自動化については、退職者アカウントの削除手順で実務の流れに沿って扱っています。

制度の重心はアイデンティティ側にある（ジョーシス独自の整理）

この分け方も、制度が定めたものではありません。IPAが公開している要求事項・評価基準を、何について書かれた基準かという観点でジョーシスが独自に整理したものです。

ジョーシスが★3の81基準を内容の軸で分け直したところ、最も多かったのはアイデンティティ・認証で27件、全体の33%でした。2位のインシデント対応・復旧14件（17%）の約2倍にあたります。資産・脆弱性・マルウェア対策は12件（15%）で3位です。★4の153件で見ても、ID・認証の33件（22%）が最多という結果になりました。

この内容別の分類は、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。制度側の大分類（攻撃等の防御48件など）とは数え直す対象が違うため、2つを同じ表に並べて読むことはできません。

ただ、傾向として言えることはあります。資産管理を「機器を数えること」と捉えていると、制度の重心から外れます。誰がどのアカウントを持ち、どの権限で、どのサービスにアクセスできるか。この軸で資産を捉え直すほうが、評価基準の並びとは合致します。

台帳運用とツール運用は何が違うのか

ここまでの話を、運用の形として整理します。従来の台帳運用と、利用実態から台帳を生成するツール運用では、成果物が似ていても性質が違います。

抜けの性質が違う

表のなかで最も大きな違いは「抜けの種類」の行です。

申請ベースの運用では、抜けているものを台帳から見つけることが原理的にできません。台帳に載っていないのですから、探す手がかりがない。この状態で「網羅的に把握しています」と説明するのは難しくなります。

ツール運用では、抜けは「まだ連携していない領域」という形で現れます。どの範囲がカバーされていて、どこが未接続かを一覧で示せる。完全ではないにせよ、欠けている場所を自分で把握できる点が決定的に違います。制度対応の文脈では、この差が説明可能性の差になります。

「利用実態から出す」とは何をすることか

具体的には、各システムのAPIを通じてアカウントや端末の状態を定期的に取得し、それを台帳の一次情報として扱うことを指します。

SaaS側から見れば、そのサービスに実在するアカウントの一覧です。端末側から見れば、実際に起動しエージェントが応答している機器の一覧です。申請の記録ではなく、いま存在しているものが出てきます。申請台帳と突き合わせれば、申請されていないアカウントや、退職しているのに残っているアカウントが差分として浮かび上がります。

かつては、この突き合わせを年に一度の棚卸しでまとめて行うのが一般的でした。現在は各システムのAPI経由で利用実態を自動取得し、台帳を常に最新に保てるようになっています。制度が求める「常時の維持」に応えるには、この形に寄せるのが現実的です。

台帳そのものの項目設計や更新ルールをどう作るかについては、IT資産台帳の作り方と運用ルールで具体的に整理しています。

ツールを入れただけでは埋まらない部分

一方で、ツール運用に切り替えれば資産管理の基準がすべて埋まるわけではありません。

11件のうち「管理ルールを定めること」「機密区分の管理ルールを定めること」は文書の整備です。「年1回以上の頻度で点検すること」は、点検を実施した記録が必要になります。仕組みが自動で回っていても、点検を実施したという事実は人が残さなければなりません。

システムで示せる部分と、文書で示す部分と、人が回して記録に残す部分。この3つが混在しているのが資産管理の領域で、どれか一つを強化しても残りは残ります。

ジョーシスが受け持つ範囲と、別途必要になる範囲

ここからは自社の話になります。何ができて何ができないかを分けて書きます。

システムで取る40件のうち29件（ジョーシス独自の整理）

このカバー率も、制度が定めたものではありません。上の3分類と同じく、ジョーシスが独自に整理した区分にもとづく集計です。

ジョーシスの集計では、★3の81基準のうちシステムで証跡を取れるのは40件です。そのうち、29件（73%）を、Josys、Josys EMS、そして既存のIdP（アイデンティティプロバイダ）の組み合わせでカバーできると整理しています。

このカバー率は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではなく、評価基準番号との1対1対応でもありません。

IdPの4件は、いま使っているもので足ります

表の3行目について補足します。認証強度やアカウントロックにかかわる4件は、Microsoft Entra IDやGoogle Workspace、Oktaといった既存のIdPが持っている機能で証跡を出せます。新しく何かを導入する必要はありません。

この4件のために製品を検討する必要はない、というのが正直なところです。すでに認証基盤があるなら、設定状況をエクスポートできるか、監査ログをどの期間保持しているかを確認するところから始めれば足ります。

残る11件は別の手当てが必要になります

システムで取る40件のうち、29件を引いた11件は、ジョーシスの守備範囲の外にあります。ネットワークの境界防護や通信の監視、バックアップの取得とリストアテスト、教育・訓練の実施記録といった領域です。ファイアウォールやEDR、バックアップ製品、eラーニングの基盤といった、それぞれの専門の仕組みで証跡を出すことになります。

文書25件と人手16件は、まるごと別の話です

さらに大きいのが、システム以外の56件です。

文書で示す25件は、規程や手順書を評価基準の粒度に合わせて整備する作業になります。パスワードのルールだけで6件に分解されているように、「策定済みです」という回答では足りず、条文ごとにどの文書のどこが対応しているかを示す必要があります。

人手で回す16件は、全社への周知、年1回の点検、申請と承認の運用、アラートの判断といった領域です。これらは自動化できません。実施したことではなく、実施を示す記録が評価されるため、日付・対象者・内容がそろう様式をあらかじめ決めておく必要があります。

つまり、ジョーシスを導入すれば★3に準拠できる、ということにはなりません。システムで取れる領域の一部を機械化し、証跡として蓄積できる状態にする。そこが受け持てる範囲です。規程の整備、体制の構築、教育訓練の実施と記録、そしてSCSセキュリティ専門家による確認と署名は、いずれも別途必要になります。

なお、制度への対応状況を横断的に可視化し、必要な文書の更新や改善計画の策定、日々の実行タスクの提案までを支援する「SCSオンボード機能（仮称）」を2026年12月にリリース予定としています。仮称であり、詳細は今後の公表を待つ段階です。

自社のIT資産とアカウントを、どこまで機械的に把握できる状態にできるかを確認したい場合は、一元管理の考え方をまとめた資料が参考になります。

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

取引先から資産の把握状況を聞かれたときに出すもの

SCS評価制度の運用開始は2026年度末頃の想定で、2026年9月時点ではまだ申請できません。それでも、取引先から資産管理の状況を問われる場面はすでに起きています。

聞かれ方には段階がある

実際に来る問い合わせは、おおむね3つの水準に分かれます。

1つ目は、資産台帳があるかどうかという水準です。この段階なら、台帳の存在と管理部署を答えれば足ります。

2つ目は、台帳に何が含まれているかという水準です。PCとサーバだけなのか、ネットワーク機器や外部サービスまで含むのか。SCS評価制度の要求事項に沿って聞かれる場合、ここで外部情報サービスの扱いを問われることが増えます。

3つ目は、その台帳がどう維持されているかという水準です。更新の頻度、情報の取得経路、年1回の点検の有無。制度対応を本気で進めている発注側は、ここまで確認してきます。

3つ目に答えられるかで差がつきます

1つ目と2つ目は、いまある台帳の説明で対応できます。差が出るのは3つ目です。

「申請があれば都度更新しています」という回答は、悪くはないものの、網羅性を担保する説明にはなりません。「各システムから自動取得しており、直近の取得日時はこちらです」と答えられる状態と比べると、相手が受け取る確度が変わります。

制度の運用が始まると、取引先の★の確認は年1回の頻度で求められることになります。一度きりの問い合わせではなく、毎年繰り返されるやり取りになる前提で、説明できる形を作っておくほうが負荷は小さくなります。

業界ガイドラインが先に来ることもあります

自動車業界のように、業界団体のガイドラインが先に浸透している領域では、SCS評価制度より先にそちらへの対応を求められる場合があります。どちらを優先し、どう接続させるかについては、自工会ガイドラインとSCS評価制度の対応順序で整理しています。

参考：IPA SCS評価制度 よくある質問

2026年9月時点で着手できる3つのこと

申請はまだできませんが、資産管理の領域は準備の効果が最も出やすい場所です。優先順位の高い順に3つ挙げます。

台帳の出所を1つずつ確認する

最初にやるのは、新しい台帳を作ることではありません。いまある台帳の各列が、どこから来ているかを確かめる作業です。

PCの台数は購買記録からなのか、管理ツールからなのか。SaaSのアカウント数は申請書の集計なのか、各サービスの管理画面からなのか。手作業で入っている列がどれかを洗い出すと、仕組みとして説明できる範囲と、そうでない範囲が分かれます。この切り分けができていれば、どこから自動化すべきかも自然に決まります。

外部情報サービスの一覧を先に作る

2つ目は、SaaSの棚卸しです。機器の台帳より優先する理由は2つあります。

まず、機器の台帳は形だけなら既にあることが多いのに対し、SaaSの一覧はゼロから作る必要があるケースが大半だからです。着手から形になるまでの時間が長くかかります。

もう一つは、SaaSの棚卸しがID管理の入口にもなるからです。どのサービスを使っているかが分かれば、そこに誰のアカウントがあるかを次に確認できます。★3の重心がアイデンティティ側にあることを踏まえると、この順序は無駄になりません。経費精算のデータやクレジットカードの明細を突き合わせるところから始めると、想定より多くのサービスが出てきます。

年1回の点検の様式を先に決める

3つ目は記録の型づくりです。資産管理の11件のうち2件は年1回の点検を求めており、点検を実施した記録がなければ基準を満たしません。

実施の記録は、始めた時点からしか積み上がりません。申請の直前にまとめて作れる性質のものではないため、様式だけでも先に決めておく価値があります。いつ、誰が、何を対象に、どういう観点で点検し、結果はどうだったか。この5つが埋まる1枚を用意しておけば、実施のたびにそのまま証跡になります。

実施はしていたのに、形式がばらばらで証跡として使えない。制度対応の現場で最も惜しい結果がこれです。

よくある質問

IT資産管理ツールを導入すれば★3の資産管理は満たせますか

満たせません。「リスクの特定」11件のうち、管理ルールの策定は文書の整備にあたり、年1回の点検は実施記録が必要です。ツールで示せるのは把握の仕組みが動いている部分までになります。システム・文書・運用の3つを組み合わせて初めて11件が埋まる構造です。

SaaSも資産管理の対象に含まれますか

含まれます。★3では「外部情報サービスの管理」が独立した要求事項として立っており、利用時のセキュリティ要件の確認と、提供事業者との機密情報の取扱いに関する合意が求められます。PCとサーバだけの台帳では、この要求事項に答えられません。

資産台帳はどのくらいの頻度で更新する必要がありますか

制度が示す運用サイクルでは、資産台帳の維持は「常時」に分類されています。加えて、管理ルールの遵守状況と機密区分の管理ルールについて、年1回以上の頻度での点検が別の評価基準として立っています。年次の棚卸しだけでは、常時の維持という要件を説明できません。

ネットワーク図は★3でも作成が必要ですか

★3で求められるのは、ネットワークとネットワーク機器を把握する仕組みの整備までです。ネットワーク図そのものの作成と、その記載内容の年1回の点検は★4の評価基準に位置づけられています。ただし把握の方法として図を使うこと自体は妨げられません。

まとめ

SCS評価制度とIT資産管理について、2026年9月15日時点で押さえておきたい点を3つに絞ります。

1つ目は、★3の「リスクの特定」11件がすべて資産管理の中分類に入り、リスクアセスメントは★4から立ち上がるということ。★3の段階で求められているのは、分析の手法ではなく、分析の前提になる把握の仕組みです。

2つ目は、条文が一貫して「把握するための仕組みを整備すること」と書いていること。一覧を作る作業ではなく、情報がどこから来て、どの頻度で更新され、いつ時点のものかを説明できる状態が問われます。申請ベースの台帳は、抜けているものを自分で見つけられない点が弱みになります。

3つ目は、ツールだけでは埋まらないということ。システムで取れる40件のうち29件はJosys、Josys EMS、既存のIdPでカバーできる見込みですが、残る11件は別の専門の仕組みが必要で、文書25件と人手16件はそもそも領域が違います。ジョーシスを入れれば★3に準拠できる、ということにはなりません。

なお、ここで触れた3分類とカバー率は、制度が定めた区分ではありません。ジョーシスが独自に整理した区分にもとづく集計です。

その上で、資産管理は準備の効果が最も早く出る領域でもあります。台帳の出所の確認、SaaSの棚卸し、点検の様式づくり。この3つは今日から始められて、どれも制度の運用開始を待つ必要がありません。

ジョーシスは、ITデバイスとSaaS、アカウント情報を一元管理するAI駆動のアイデンティティセキュリティ基盤です。国内外1,000社を超える企業に導入いただいており、350以上のアプリケーションと連携して、利用実態から台帳を生成し、評価のときに出せる記録として蓄積します。自社の資産をどこまで機械的に把握できるか確かめたい場合は、資料または個別のデモをご利用ください。

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

個別デモの日程を調整する

関連記事：アクセス権レビューの進め方と自動化

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