SCS評価制度のログ・監視要件｜星3・星4とSIEM・SOCの役割

確認日：2026年9月17日

本記事の確認時点では制度の運用開始前です。星3・星4は2027年3月頃の運用開始、申請方法や取得ガイド等は2026年10月頃の公開が予定されています。最新の案内はIPAの制度FAQで確認してください。

SCS評価制度では、星3にもネットワークの不正通信を検知・遮断し、ログやアラートを分析して判断・通知する要件があります。星4では、これに加えて対象ログの6カ月保管や、認証ログの月1回以上の確認などが求められます。

準備の要点は、保存するログと、異常を見つけた後の担当・判断・連絡を対応付けることです。この記事では、IPAの公開評価基準を基に、星3・星4のログ・監視要件と、SIEM・SOCを検討する際の確認事項を整理します。

以下の制度説明は、IPA「要求事項・評価基準」の公式Excelの要約です。運用記録の表と記入例はヤグラ独自の準備例であり、公式様式や適合判定ではありません。制度全体はSCS評価制度の概要、評価方法や有効期間は星3・星4の比較をご覧ください。

SCSログ運用記録表をダウンロード（CSV・登録不要）。本文の要件と照合しながら、対象ログ・保管実績・確認結果・判断と通知の担当を記入できます。公式評価表ではなく、ヤグラ独自の準備資料です。

星3・星4のログ・監視要件を分けて理解する

公式Excelでは、一つの要求事項に複数の評価基準が対応します。たとえば「4-4-3」が要求事項ID、「4-4-3-1」が評価基準IDです。対応状況を管理する際は、評価基準IDまで記録します。

星4には星3の内容も含まれます。上表はログ・監視に関係する要求事項の抜粋で、全要求事項ではありません。たとえば星4の5-1-2には、会社支給パソコンの許可ソフトウェア一覧、インストール状況の年1回以上の点検、外部から受け取ったファイルの安全性確認に関する評価基準もあります。

出典：IPA 公式Excel、IPA 制度の詳細情報。

星3：検知した後の分析・判断・通知まで確認する

5-1-1-1は、社内外ネットワークの境界または端末で、外部からの不正アクセスと、内部から不正なサーバーへ向かう通信の両方に対する検知・遮断の仕組みを求めています。

5-1-1-2では、ネットワーク機器のログ・アラートを分析し、不審な事象を発見した場合に、セキュリティ担当部署の担当者または管理者がインシデントに当たるかを判断します。5-1-1-3では、対象の機器・サービスからアラートを速やかに発報し、インシデントの速報レポートを作成・通知する仕組みが必要です。

実務では、機器の設定に加えて、通知先、確認する担当者、担当者不在時の連絡先、判断結果を残す場所をそろえます。導入済みの機器があっても、通知が届かない、受け取った人が判断できない、結果が残らないといった不足がないかを点検します。

これらの運用整理は、ヤグラの準備例です。評価では、公式Excelの5-1-1-1〜3に照らして実際の仕組みを確認してください。

星4：何のログを、どれだけ残すか

4-4-3-1で示されている対象ログと取得項目は、次のとおりです。「すべてのログを一律6カ月」という指定として広げず、対象となる機器・機能と必要な項目を確認します。

ファイアウォールには、取引先と接続する閉域網の入口に設置されるものも含まれます。また、クラウドサービスの利用も対象です。

クラウドや構成上の制約がある場合

クラウドサービスやシステム構成の仕様によって要件を満たせない場合には、他の機器・機能を使って、調査に必要な相当するログを取得・保管する条件が設けられています。取得できないから記録しなくてよい、という意味ではありません。

準備時には「不足する項目」「仕様上の理由」「代わりに取得するログ」「何を調査できるか」を整理します。代替ログが要件に相当するかは、最新版の公式資料と評価を担当する専門家等に確認します。

保存先の保護と、認証ログの月次確認

4-4-3-2では、対象ログの保存媒体・システムにインターネット経由でアクセスする際、4-1-3-3に示す要素を使った多要素認証を常に利用することが求められます。管理画面だけでなく、実際にログを閲覧・取得する経路を把握して確認します。

4-4-3-3では、4-4-3-1の対象ログのうち、認証サーバーのログを月1回以上確認し、不審な認証試行を検知します。この頻度は、星3から求められる不正通信のリアルタイム検知や速やかな通知を置き換えるものではありません。

出典：公式Excelの4-4-3-1〜3、4-1-3-3、5-1-1-1〜3。

保存設定と、実際に使える記録を照合する

保存期間を6カ月に設定しても、収集を始めたばかりなら過去6カ月分の記録はありません。収集が途中で止まったり、必要な項目が欠けたりしていないかも確認します。

次の表は、ログごとの運用を整理するための独自の記録例です。この表を埋めるだけで公式基準への適合を判断できるわけではありません。

架空の記入例：クラウド認証ログ

以下は説明用の架空例です。実在する顧客の記録や、特定サービスの標準仕様ではありません。

この例は、完了事項と不足を分けて管理するためのものです。認証失敗の回数だけで被害を断定せず、実際の利用状況や関連する記録と照合して判断します。

SIEM・SOC・AI SOCは何を担うか

SIEMは、複数の機器・サービスからログを集約し、検索・分析するための基盤です。SOCは、アラートを確認し、調査・判断・連絡を行う運用を担います。AI SOCでは、その調査や情報整理にAIを活用します。具体的な対象範囲や、人が判断する場面はサービスによって異なります。

SCSへの対応を目的に検討する際も、製品名だけで判断せず、次を確認します。

• 対象の機器・クラウドから、必要な項目を取得できるか。

• 必要な期間を保管し、調査時に取り出せるか。

• 収集停止や欠損を、どのように把握するか。

• アラートを誰が確認し、インシデント該当性やレベルを誰が判断するか。

• 調査・判断・通知の記録を残せるか。

• 自社と委託先の役割、対応時間、連絡先が契約・運用手順で明確か。

経済産業省は、評価基準の達成に当たり特定のセキュリティ対策製品の導入が必須ではないと説明しています。SIEM・SOC・AI SOCの利用だけで取得が保証されるものでもありません。既存対策と不足を整理し、その不足に合った機能と運用を選びます。経済産業省の制度説明

製品・運用を比較する前に、SIEMの仕組みと選び方とAI SOCの仕組みと人が担う判断を確認すると、収集・分析の基盤と、日々の調査・対応を分けて検討できます。

担当・証跡・期限を決めて準備を進める

まずは対象のログごとに、取得項目、保存先、確認する担当、異常時の連絡先を一覧にします。次に、設定画面と実際の記録を照合し、不足する作業に担当者と期限を付けます。全体の作業管理には、SCS評価制度の準備チェックリストと入力用CSVをご利用ください。

監視やアラート調査の進め方を検討する場合は、ヤグラ AI SOCの支援内容をご覧ください。対象システムや必要な運用を整理したうえで、ご相談いただけます。

参考資料

2026年9月17日時点の公表資料を確認しています。評価基準の解釈や申請時の取扱いは、最新版の公式資料をご確認ください。

• IPA：要求事項・評価基準

• IPA：星3・星4要求事項・評価基準（Excel）

• IPA：SCS評価制度の詳細情報

• IPA：制度規程・委員会

• 経済産業省：SCS評価制度