経産省SCS評価制度の43要求事項のうち、Aikidoが支援できるのはおおむね6〜7件。全体の地図と、架空の部品メーカーが★4に向けて動く半年の物語で、ツール以外に何が要るのか、そして★の目盛りの外にある自社コードの守り方を描きます。
ZDNET Japanの連載（松岡功氏、2026年10月1日）が、経済産業省の「SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）」を取り上げていました。
2026年度末頃に★3・★4の制度開始が予定され、ITベンダー各社も「SCS対応」を打ち出し始めています。
制度の骨格をおさらいしておきます。
| ★3 | ★4 | |
|---|---|---|
| 位置づけ | すべてのサプライチェーン企業の最低線 | 重要な取引先が標準的に目指す水準 |
| 要求事項 / 評価基準 | 26件 / 81項目 | 43件 / 153項目（★3を含む） |
| 評価の方式 | 専門家確認付きの自己評価 | 第三者評価（文書確認・実地審査・技術検証） |
| 有効期間 | 1年 | 3年 |
ここで最初に書いておきたいことがあります。
Aikidoを入れても★は取れません。
43件の大半は、規程、体制、ID管理、バックアップ、取引先との取り決めなどです。Aikidoが関われるのはその一部です。
しかも、その一部についても「ツールを導入した」だけでは評価基準を満たしません。
例えば脆弱性管理なら、必要なのは脆弱性を見つけることだけではありません。
誰が担当するのか。何を情報源にするのか。いつ確認するのか。いつまでに直すのか。間に合わない場合は誰が判断するのか。その記録が残っているか。
SCSが見るのは、そうした運用そのものです。
この記事では、まず43件の中でAikidoが関われる場所を整理します。
そのうえで、架空の部品メーカーの開発チームが★4に向けて半年間取り組む姿を追いながら、Aikidoでできることと、人が決めなければならないことを具体的に見ていきます。
凡例：◎ 運用の中心として使える ○ 一部を担える △ 材料・証跡を提供できる ― 範囲外
| 大分類 | ★3 | ★4 | Aikido | 理由 |
|---|---|---|---|---|
| ガバナンスの整備 | 3件 | 6件 | △ | 体制や方針を決めるのは人。脆弱性対応状況などは経営報告の材料にできる |
| 取引先管理 | 3件 | 5件 | ― | 契約、機密情報の取り決め、取引先の点検はAikidoの範囲外 |
| リスクの特定 | 4件 | 6件 | △〜◎ | 資産管理は補完。脆弱性管理では検出から担当・期限管理まで運用の中心に置ける |
| 攻撃等の防御 | 13件 | 21件 | ○ | ID、MFA、暗号化、バックアップは範囲外。安全な構成、サポート切れ、更新管理には関われる |
| 攻撃等の検知・対応・復旧 | 3件 | 5件 | △〜○ | 開発端末のパッケージや拡張機能の監視・制御は担える。ネットワーク監視や復旧は別の仕組みが必要 |
43件のうち、Aikidoが直接または部分的に支援できるのはおおむね6〜7件です。
中心になるのは、3-1-1、3-2-1、4-4-1、4-4-2、4-4-4、5-1-2の6件です。これに、経営層への報告（1-4-1）の材料として使える部分が加わります。
数だけ見れば43件の一部です。
ただし、この6〜7件は「規程を一度作れば終わり」というものではありません。
脆弱性を見つけ、担当を決め、期限を持たせ、直し、例外を判断し、その記録を残す。
毎週、毎月回し続ける必要がある項目に集中しています。
| 要求事項 | ★ | 求められていること（要旨） | Aikidoの担当 | ツール以外に必要なもの |
|---|---|---|---|---|
| 3-1-1 ハードウェア・OS・ソフトウェアの把握 | 3 | PC・サーバ等を把握し、管理ルールを定めて点検する | △〜○。Device Protectionで開発端末上のパッケージ、拡張機能、AIツール等を補完。アプリの依存関係はSBOMで把握 | PC・サーバの製造元、OS、台数等を持つIT資産台帳 |
| 3-2-1 脆弱性の管理体制・プロセス | 4 | 担当部署、役割、責任、情報源、ツール、確認頻度などを定めて運用 | 脆弱性の検出、トリアージ、担当チーム、SLA期限、対応状況の管理 | 責任者の指名、判断基準、例外承認のルール |
| 4-4-1 安全な構成の確立・維持 | 3/4 | 不要・未許可ソフトウェアの削除や無効化、不要サービスの停止等 | 開発端末の危険なパッケージ等の制御、CSPM、IaCの設定ミス検出 | 何を許可し、何を禁止するかという社内ルール |
| 4-4-2 サポート切れの管理 | 4 | サポート中のものを使用し、継続使用する場合は更改計画や代替策を持つ | サポート切れランタイム・ライブラリ等の検出 | 更改計画、代替策、承認者 |
| 4-4-4 パッチ・アップデートの手続 | 3/4 | 一定要件に該当する更新をリリースから14日以内に適用。困難な場合は代替策を実施 | 対象箇所の特定、AutoFix、担当・SLA期限・対応状況の管理 | リリース日を基準とした期限管理、テスト、検証環境、例外承認 |
| 5-1-2 機器の状態・挙動の監視 | 4 | 利用を許可するソフトウェアを管理し、不適切な導入等を把握・制御 | 開発端末上のパッケージ、IDE・ブラウザ拡張機能、AIツール等の監視・制御 | 開発者が守れる許可・例外ルール |
ここは混同しやすいところです。
★4では43件の要求事項への第三者評価に加えて、技術検証があります。
技術検証は43件のうちの「もう1項目」ではありません。★4の評価プロセスの一部です。
対象として想定されているのは、VPN装置やルータなど、インターネットから悪用された場合に社内への侵入口になり得る機器です。
AikidoのSurface MonitoringやAI PentestでWebアプリを調べることとは別です。
公開しているWebアプリをAikidoで調べておくことは有効ですが、それでSCSの技術検証を代替できるわけではありません。
VPN装置やルータのファームウェアについては、ネットワーク担当が別途管理する必要があります。
ここでもう一つ、SCSとAikidoの役割を分けておきます。
例えば、ある会社が取引先向けの受発注Webシステムを運営しているとします。
SCSでは、そのシステムを動かしているサーバやクラウドを適切に管理しているか、アカウント管理ができているか、脆弱性情報を確認して更新しているか、といった会社としてのセキュリティ管理を見ます。
一方、★4を取得したからといって、その会社が作ったWebアプリのコードまで安全だと認定されるわけではありません。
例えば、
といった部分です。
★4は、その企業が一定水準のセキュリティ管理を行っていることを示す制度です。そこで開発されたソフトウェア一つひとつの安全性まで保証する制度ではありません。
AikidoがSCS対応として関われるのは43件の一部です。
一方で、SAST、SCA、SBOM、マルウェア検知、Device Protection、AI Pentestなどを使えば、SCSだけでは直接確認しないソフトウェア開発側のリスクまで見ることができます。
この二つは分けて考える必要があります。
ここからは架空の会社の話です。
登場する会社、人物、数字はすべて説明のための創作です。
また、SCS評価制度そのものが★4取得を義務付けるわけではありません。ここでは、発注元が取引条件として★4を求めたケースを想定します。
東海精機（仮名）
従業員300人の自動車部品メーカー。生産管理システムと、取引先向けのWeb受発注ポータルを社内の開発チーム8人で内製しています。
情報システム課の佐藤さんがセキュリティ担当を兼ねています。
ある朝、完成車メーカーの調達部門から通知が届きました。
「来年度以降の取引継続にあたり、SCS評価制度★4の取得をお願いしたい」。
佐藤さんは43件の要求事項を一つずつ自社に当てはめ、ギャップを確認しました。
規程や体制は総務と整理する。
IDやMFAは既存の認証基盤で確認する。
バックアップやログ保管はインフラ担当。
取引先との機密情報の取り決めは法務。
そこで手が止まったのが、開発チームでした。
「利用しているソフトウェアを把握しているか」
「脆弱性を継続的に管理しているか」
「必要なアップデートを期限内に適用できるか」
受発注ポータルがいくつのOSSに依存しているのか。
誰がどの脆弱性を担当しているのか。
開発者のPCに何が入っているのか。
聞いてみると、誰も全体を答えられませんでした。
佐藤さんは、まずAikidoの無料プランで試すことにしました。
無料プランは2ユーザーまでなので、使うのは佐藤さんと開発リードの二人です。
この段階の目的は、8人で運用を始めることではありません。
自分たちの環境をAikidoで見ると、何が見えるのか。
まずそこを確認することにしました。
受発注ポータルと生産管理システムのリポジトリを接続し、AWSも読み取り専用で接続します。
すると、依存ライブラリの脆弱性、コード上の問題、クラウド設定など、それまで別々に確認していた情報がまとまって見えるようになりました。
ここで佐藤さんたちは、問題が「脆弱性を見つけられるか」だけではないことに気づきます。
見つかった脆弱性を、
誰が担当するのか。
いつまでに直すのか。
間に合わない場合、誰が判断するのか。
ここまで決めないと、継続的な脆弱性管理にはなりません。
無料版で「何が見えるか」を確認した後、開発チーム8人で本運用するため、有料プランへ切り替えることにしました。
有料プランへ切り替えた理由は、単にスキャン対象を増やすためではありません。
見つかった問題に、担当と期限を持たせるためです。
Aikidoでは、リポジトリやクラウドなどのリソースに担当チームを割り当てられます。
さらにSeverityごとにSLAを設定すれば、問題を検出した時点から対応期限を持たせることができます。
佐藤さんと開発リードは、これを使ってA4二枚の「脆弱性対応手順」を作りました。
ここで、期限の数え方には注意が必要です。
SCSの14日はアップデートプログラムがリリースされた日から数えますが、AikidoのSLAはAikidoがその問題を最初に検出した日から数えます。
例えばリリースの3日後にAikidoが検出した問題に「14日」のSLAを設定すると、そのままではSCS上の期限より3日遅くなります。
そのため、SCSの14日対象については、AikidoのSLAだけに任せず、アップデートのリリース日から残り何日あるかを確認して管理することにしました。
AikidoがSCSの期限を決めるわけではありません。
何をいつまでに直すかを決めるのは会社です。Aikidoは、その運用の中で担当と期限を持たせ、期限が近いもの、期限を超えたものを追えるようにします。
「脆弱性をスキャンしています」から、「脆弱性管理を運用しています」へ。
ここが大きな違いでした。
手順を決めて最初の月。
14日以内の適用対象となる依存ライブラリの更新が見つかりました。
担当チームも決まっています。SCS上の期限も確認しました。
AutoFixで修正案も作れました。
それでも期限に間に合いませんでした。
問題は、その先です。
生産管理システムには自動テストがほとんどなく、検証環境も本番と構成が違っていました。
ライブラリを更新しても既存機能が壊れないことを確認できず、誰も本番への反映を承認できなかったのです。
この一件は、手順に従って代替策と適用予定日を記録し、例外承認を取りました。
そこで開発チームは、自動テストと検証環境の整備を始めました。
最初に着手したのは受発注ポータルです。
取引先がインターネットから利用するシステムで優先度が高く、生産管理システムに比べて変更も多いため、まずここで「更新を検知したら、テストして、期限内に出す」という流れを作ることにしました。
最低限の結合テストを追加し、CIで自動実行できるようにします。
そのやり方を固めた後、生産管理システムにも順次広げました。
整備には2か月かかりました。
14日以内に修正するために足りなかったのは、脆弱性スキャナではありません。
直したものを安全にリリースできる開発環境でした。
同じ時期、生産管理システムで利用しているランタイムがサポート切れになっていることも分かりました。
すぐには更新できません。
そこで来年度上期までの更改計画を作り、それまでは外部からのアクセス経路を限定することを代替策として承認しました。
見つけるところはツールでできます。
直せないものをどう扱うかは、人が決めなければなりません。
次に問題になったのが、開発者の端末でした。
一般社員のPCなら、インストール可能なソフトウェアをIT資産管理側でかなり制御できます。
しかし開発者は違います。
npmやPyPIのパッケージ。
VS CodeなどのIDE拡張機能。
ブラウザ拡張機能。
AIコーディングツール。
MCPサーバ。
開発をしていれば、日々新しいものを使います。
全部を事前申請にすれば、今度は開発が止まります。
そこで開発チーム8人の端末にDevice Protectionを展開しました。
すると、従来のPC台帳では見えていなかった開発環境が見えるようになりました。
チームで決めたのは、次の線引きです。
目的は「開発者に何も入れさせない」ことではありません。
何が入っているか分からない状態をやめることです。
開発者と一緒に線を引いたことで、「セキュリティ部門が開発を止める」という形にもなりませんでした。
★4の技術検証に備え、ネットワーク担当はVPN装置やルータについて、ファームウェアのバージョンと脆弱性情報を改めて確認しました。
今後もベンダーの情報を週次で確認する運用を作ります。
これはSCSへの対応です。
一方、佐藤さんは別のことが気になっていました。
取引先が毎日使っている受発注ポータルです。
サーバやクラウドを適切に管理していても、アプリケーションの認可処理に間違いがあれば、取引先Aの利用者から取引先Bのデータが見えてしまう可能性があります。
そこで、これはSCSの技術検証とは別に確認することにしました。
Surface Monitoringで公開面を継続的に確認し、AI Pentestを検証環境に実施します。
ログイン後の機能も確認したところ、一件、権限チェックの漏れが見つかりました。
修正して、再度確認します。
VPN装置を確認したのは、★4への対応。
受発注ポータルの認可まで確認したのは、自分たちが提供しているシステムを守るためです。
目的は似ていますが、同じ検査ではありません。
半年後。
★4の要求事項に沿った準備は一通り整ってきました。
佐藤さんたちは、第三者評価を受けることを想定して、開発チームに関係する証跡を並べました。
脆弱性対応手順。
担当チームと責任者。
検出された問題と対応日。
期限内で対応できた割合。
期限を超えた問題。
例外にした理由と代替策。
サポート切れランタイムの更改計画。
開発端末の管理ルール。
経営層への報告資料。
ここで重要なのは、「Aikidoを導入しています」という画面を見せることではありません。
問題を見つけた後、誰が、いつまでに、どう処理したのかを説明できることです。
特に説明が必要なのは、直したものより、直さなかったものです。
なぜ今は直せないのか。
その間のリスクをどう下げたのか。
誰がそれを承認したのか。
いつまでに解消するのか。
ツールは、その判断を代わりにしてくれません。
ただし、一度決めた運用を、担当者と期限を持たせて回し、その結果を残すところでは大きな助けになります。
半年間の準備を振り返って、佐藤さんには一つ気になることが残りました。
★4では、自社のIT基盤やセキュリティ管理について幅広く確認されます。
しかし、★4を取得したからといって、東海精機が開発した受発注ポータルに脆弱性がないことまで証明されるわけではありません。
第6話で見つけた認可の不備は、その分かりやすい例です。
会社として脆弱性管理の手順を持っていても、コードに認可の間違いがあれば情報は漏れます。
端末を管理していても、開発途中で悪意あるOSSを取り込めば、製品側へ影響が及ぶ可能性があります。
SCSとアプリケーションセキュリティは、どちらか一方で置き換えられるものではありません。
SCSは会社としてセキュリティを管理できているかを見る。
Aikidoは、その中の脆弱性管理を回しながら、さらにコード、OSS、開発端末、Webアプリまで見る。
東海精機が取引先に示したいのは、「★4に対応しています」だけではありません。
どのOSSを使っているのか。
脆弱性が出たら、どのくらいの期間で直しているのか。
例外は何件あり、なぜ残しているのか。
公開しているWebアプリをどのように検査しているのか。
そうした実際の運用まで説明できて、初めて相手に安心材料を渡せます。
佐藤さんは、次の取引先との面談では、SCSへの対応状況と一緒に、受発注ポータルのSBOMと直近半年の脆弱性対応実績も持っていくことにしました。
半年間で分かったことを整理すると、Aikidoだけでは用意できないものがいくつもあります。
| 必要なもの | 中身 | 誰が決めるか |
|---|---|---|
| 人の指名 | 担当チーム、対応担当者、承認者、経営報告者 | 経営層・管理者 |
| 手順 | 情報源、確認頻度、期限、例外処理 | 情報システム・開発 |
| 期限 | SCS上14日以内となるもの、それ以外の社内SLA | 会社 |
| 14日の起算日 | SCSはアップデートのリリース日基準。AikidoのSLA起算日とは分けて管理する | 情報システム・開発 |
| 例外の責任 | 直せないものの代替策と解消予定日 | 管理者 |
| テスト・検証環境 | 更新を安全に本番へ出すための仕組み | 開発チーム |
| 開発端末のルール | パッケージ、拡張機能、AIツール等の扱い | 開発チーム・情報システム |
| Aikidoで見ない領域 | IT資産台帳、ID・MFA、バックアップ、VPN・ルータ、契約・取引先管理 | 各担当部門 |
そのうえで、Aikidoが担えるのは大きく四つです。
ただし、ここでも一つ区別が必要です。
AikidoのSLA期限は「Aikidoが検出してから」の期限です。SCSの14日は「アップデートがリリースされてから」の期限です。
Aikido上で期限管理をしているだけでSCSの14日を満たしたことにはなりません。
制度側の起算日を確認し、それを運用へ落とし込む必要があります。
SCS評価制度への対応は、チェックシートを埋める作業ではありません。
「毎週月曜に見る」「この人が担当する」「この日までに直す」「直せないならこの人が判断する」。
そこまで決めて初めて運用になります。
Aikidoを入れる意味があるのも、その運用を毎週回すところです。
そしてもう一つ。
★4を目指すことと、自分たちが作っているソフトウェアを安全にすることは、完全に同じではありません。
SCSへの対応を進めながら、その評価だけでは直接見ないコードやOSS、開発端末までどこまで守るか。
開発チームでは、そこまで一緒に考える必要があります。
※本記事は2026年10月2日時点の公開情報に基づいています。SCS評価制度は2026年度末頃の制度開始（★3・★4の申請受付開始）が予定されています。また、IPAは★3・★4の要求事項・評価基準の解説書を2026年10月頃に公開予定としており、公開後は本文中の制度解釈について改めて確認します。
Aikido Community Japan
公開日: 2026/10/2
最終更新: 2026/10/2
セキュリティの最新情報をお届けします。