SCS評価制度★3とMicrosoft 365｜評価基準ごとの実装例と確認ポイント

本記事では、IPA（独立行政法人情報処理推進機構）が公開している「★3・★4 要求事項・評価基準」（2026年3月27日版）の★3評価基準に対して、Microsoft 365の機能で何ができるかを、評価基準の番号ごとに整理します。設定項目の一覧はMicrosoft 365で★3に対応する設定チェックリストにまとめているため、本記事では適合を判断するときに見落としやすいポイントを中心に解説します。★3全体の26要求事項・81評価基準は★3の要求事項一覧をご覧ください。

前提：SCS評価制度は製品の導入を求めていない

最初に前提を明確にしておきます。SCS評価制度は特定の製品の導入を求めていません。以下に挙げる機能は評価基準を満たすための実装例であり、設定するだけで適合が保証されるものではありません。適合の判断では、次の4点を評価基準ごとに確認する必要があります。

• 対象範囲: 設定が全ユーザー・全端末に及んでいるか。一部のグループだけに適用されていないか
• 設定内容: 評価基準が求める水準（多要素認証を常に使う、14日以内に更新を適用する等）に設定が合っているか
• 運用: 申請・承認、定期確認、未適用端末への対処など、設定だけでは完結しない作業が実施されているか
• 証跡: 上記を第三者に示せる記録（設定画面のエクスポート、申請書、確認記録等）が残っているか

逆に、Microsoft 365を使っていなくても、他社製品や手作業で同じ水準を満たせば評価基準は満たせます。以下の表には、手作業で代替する場合の方法も併記しています。

評価基準と実装例

★3の評価基準のうち、Microsoft 365の機能が実装例になるものを整理します。

表の「必要ライセンスの目安」は代表的な構成であり、全プランを照合したものではありません。導入前に自社の契約で利用可能かを確認してください。資産把握とパッチ管理のIntuneでの具体的な設定はIntuneでSCS評価制度に対応するで解説しています。

多要素認証（4-1-3）：既定値群だけで適合とは判断できない

評価基準4-1-3-2は、重要な機密情報を取り扱うクラウドサービスへのアクセスについて、ユーザ・管理者ともに常に多要素認証を使うことを求めています。

セキュリティの既定値群は、ライセンスを追加せずに基礎的な保護を有効にできる機能ですが、一般ユーザーへの多要素認証の要求は状況に応じて判断される仕様です。このため、既定値群を有効にしただけでSCSの多要素認証要件を満たすとは判断できません。

条件付きアクセスが使える場合は、対象ユーザー・対象アプリを明確にしたポリシーを作成し、次の点を確認してください。

• 除外ユーザー（緊急用アカウント、サービスアカウント等）が適切に管理されているか。除外の理由と一覧を記録に残す
• 管理者ロールが例外なく対象になっているか
• 旧来の認証方式（レガシー認証）がブロックされているか。レガシー認証は多要素認証を回避できるため、残っていると要件の抜け穴になる

なお「多要素認証で保護されている」ことと「アクセスのたびに追加認証画面が表示される」ことは同じではありません。セッションの有効期間や認証済みトークンの扱いも含めて、専門家確認の段階で説明できるようにしておくことを推奨します。認証要素について、評価基準ではメールやSMSのワンタイムパスワード、スマートフォンへの認証要求も所有情報として挙げられています（4-1-3-3）。

管理者ID（4-1-2）：PIMは必須ではない

Privileged Identity Management（PIM）は管理者権限を必要な時だけ付与できる機能ですが、Entra ID P2 または Entra ID Governance のライセンスが必要です。Business Premium の標準範囲には含まれません。

評価基準が求めているのは、管理者権限を持つ人の限定、用途に応じた最小権限、保有者の把握、不要になった管理者IDの削除、付与・変更・削除の申請・承認制です。PIMがなくても、ロール割り当ての一覧と申請・承認記録、定期的な確認で満たすことができます。グローバル管理者を最小限にし、ユーザー管理者・Exchange管理者など用途に応じたロールに分けること、保守事業者に付与した管理者権限も一覧に含めることがポイントです。大分類4のID・認証要件全体は「攻撃等の防御」の要件で整理しています。

更新適用（4-4-4-2）：設定だけでは14日以内を担保できない

利用している機能・設定に関するアップデートのうち、ベンダーが「重大」「高リスク」とする脆弱性を修正するもの、CVSS基本値7.0以上の脆弱性を修正するもの、または脆弱性のレベルの詳細が提供されていないものは、リリースから14日以内の適用が求められます。

更新リングで延期日数と期限を設定しても、電源が入っていない端末、再起動待ちの端末、管理対象外の端末があれば期限内に適用されません。次の管理を合わせて行ってください。

• 更新のリリース日と適用完了日の記録
• 未適用端末の把握と対処（Intune のレポートで確認し、担当者に再起動や接続を依頼した記録を残す）
• Microsoft 365 Apps、ブラウザ、サードパーティ製ソフトウェアの更新状況。Windows Updateの対象外のソフトウェアも評価基準の対象になる
• インターネット境界のネットワーク機器（ルーター、UTM等）の更新。Microsoft 365の管理外なので別途管理が必要
• 期限内に適用できなかった場合のリスク低減策の記録

検知（5-1-1）：端末側で満たせるかは個別確認

5-1-1-1は、境界または端末において、インターネットから社内への通信と、社内から不正なサーバへの通信の双方を、リアルタイムに検知・遮断する仕組みを求めています。Defender のネットワーク保護やWebコンテンツフィルタリングは端末側の実装候補ですが、自社の構成で要件を満たせるかは、自己評価の段階で★3確認責任者に確認することを推奨します。

アラートの通知先（5-1-1-3）が実際に対応できる担当者になっているかも確認してください。管理者の共有メールボックスに通知が届いているだけで、誰も見ていない状態では運用として機能していません。UTMとEDRのどちらで満たすかの考え方は「攻撃等の検知」の要件で解説しています。

バックアップ（4-3-4）：復元できる範囲を確認する

4-3-4では、取得対象・頻度・保管期間を定めたバックアップ、重要な機密情報の遠隔地バックアップ、バックアップ対象ごとのリストア手順書が求められます。

SharePoint・OneDriveのバージョン履歴、ごみ箱、保持ポリシーは、それぞれ目的の異なる機能です。これらをバックアップとして扱う場合は、次の点を確認して説明できるようにしてください。

• 対象データと保管期間
• 権限や設定まで復元できるか
• 保管先がアカウント侵害やテナント全体の障害の影響を受けないか
• リストア手順

テナント外に保管するバックアップ製品の利用は設計例の一つであり、制度上一律に必須とされているものではありません。バックアップ要件の考え方は★3のバックアップ要件、復旧全体の要件は「インシデントからの復旧」の要件をご覧ください。

Microsoft 365だけでは満たせない評価基準

次の要求事項は製品設定では完結しません。★3の26要求事項のうち、文書・体制・運用で評価される部分です。

• ガバナンスの整備（1-2-1、1-2-3、1-3-1）: 「ガバナンスの整備」の要件
• 取引先管理（2-1-1、2-1-2、2-1-4）: 「取引先管理」の要件
• ネットワーク・外部情報サービス・機密情報の管理（3-1-2〜3-1-4）: 「リスクの特定」の要件
• ネットワーク境界防護（4-5-1）
• 教育・訓練（4-2-2）: 従業員教育要件
• インシデント対応手順（6-1-1）: 「インシデントへの対応」の要件
• 復旧準備（7-1-1）: 「インシデントからの復旧」の要件

Microsoft 365の設定で対応できるのは技術的な評価基準に限られます。81評価基準のうち技術設定で完結するものは半分に届きません。設定作業と並行して、文書と体制の整備を進める必要があります。

★4を見据えるなら

★4ではログの取得（4-4-3）が加わり、認証サーバのログを6か月保管し、月1回以上モニタリングすることが求められます。クラウドサービスの利用も対象です。Entra IDのサインインログの保持期間がこれに満たない場合は、Log Analyticsワークスペース等へのエクスポートを検討してください。エクスポートの設定だけでなく、月1回の確認を誰が行い、何を見て、記録をどこに残すかまで決めておくと、★4の運用要件にそのまま使えます。ログ要件の詳細はSCS評価制度のログ管理要件で解説しています。

よくある質問

セキュリティの既定値群を有効にしていれば多要素認証の要件（4-1-3-2）を満たしますか？

既定値群を有効にしただけで満たすとは判断できません。評価基準4-1-3-2は、重要な機密情報を取り扱うクラウドサービスへのアクセスについて、ユーザ・管理者ともに常に多要素認証を使うことを求めています。セキュリティの既定値群はライセンスを追加せずに基礎的な保護を有効にできる機能ですが、一般ユーザーへの多要素認証の要求は状況に応じて判断される仕様です。条件付きアクセスが使える場合は、対象ユーザー・対象アプリを明確にしたポリシーを作成し、除外ユーザーの管理、管理者ロールが例外なく対象になっているか、レガシー認証がブロックされているかを確認してください。

Privileged Identity Management（PIM）を導入しないと管理者IDの要件を満たせませんか？

PIMは必須ではありません。評価基準4-1-2が求めているのは、管理者権限を持つ人の限定、用途に応じた最小権限、保有者の把握、不要になった管理者IDの削除、付与・変更・削除の申請・承認制です。PIMは管理者権限を必要な時だけ付与できる機能ですが、Entra ID P2 または Entra ID Governance のライセンスが必要で、Business Premium の標準範囲には含まれません。PIMがなくても、ロール割り当ての一覧と申請・承認記録、定期的な確認で評価基準を満たすことができます。

Microsoft 365 Business Premium以外のプランでも★3に対応できますか？

対応できますが、代替手段が必要になる評価基準があります。本記事の実装例のうち、条件付きアクセスはEntra ID P1、デバイス管理はIntune、マルウェア対策はDefender for Business等のライセンスを前提にしており、Business Premiumにはこれらが含まれています。これらを含まないプランの場合は、アドオンライセンスの追加、他社製品の利用、または手作業での管理（資産台帳、端末ごとの設定確認記録、月次の更新適用確認表など）で代替します。SCS評価制度は特定の製品を求めていないため、他社製品や手作業でも評価基準を満たせます。ライセンスに含まれる機能は変更されることがあるため、導入前に自社の契約内容を確認してください。

SharePointやOneDriveのバージョン履歴はバックアップ（4-3-4）として認められますか？

一律に認められる、または認められないという判断はできません。バージョン履歴、ごみ箱、保持ポリシーはそれぞれ目的の異なる機能であり、これらをバックアップとして扱う場合は、対象データと保管期間、権限や設定まで復元できるか、保管先がアカウント侵害やテナント全体の障害の影響を受けないか、リストア手順の4点を確認して説明できるようにしてください。テナント外に保管するバックアップ製品の利用は設計例の一つであり、制度上一律に必須とされているものではありません。

Entra IDのサインインログの保持期間は★4のログ要件に足りますか？

既定の保持期間では足りない可能性が高いです。★4で加わるログの取得（4-4-3）では、認証サーバのログを6か月保管し、月1回以上モニタリングすることが求められ、クラウドサービスの利用も対象です。Entra IDのサインインログはライセンスに応じて一定期間しか保持されず、執筆時点では6か月に満たないため、Log Analyticsワークスペースやストレージアカウントへのエクスポートを設定して6か月以上保管できるようにし、月1回の確認記録を残すことを検討してください。

まとめ

Microsoft 365を業務基盤にしている企業は、★3の技術的な評価基準の多くを既存ライセンスの機能で実装できます。ただし、SCS評価制度は製品の導入を求めておらず、設定の有無ではなく、対象範囲・設定内容・運用・証跡の4点がそろっているかで適合が判断されます。

見落としやすいのは、既定値群だけでは多要素認証要件を満たすと判断できないこと、PIMは必須ではないこと、更新リングの設定だけでは14日以内の適用を担保できないこと、バージョン履歴をバックアップと見なすには復元範囲の確認が必要なことの4点です。そして、ガバナンス・取引先管理・教育・インシデント対応・復旧準備は製品設定では完結しません。設定作業を進めながら、文書と体制の整備を同時に進めることが★3取得への最短経路です。