株式会社TIMEWELLの濱本 隆太です。
「Level 3っていつ出るんですか？うちはLevel 2取ったので、次に行きたいんですけど」。先日、ある国内クラウド事業者のセキュリティ責任者から、半ば諦め交じりにこう聞かれました。
正直に答えます。 2026年5月時点で、CSA STAR Level 3は正式リリースされていません 。2023年に出る予定が、もう3年待たされている状態です。これは多くの人が知らない事実で、認証コンサルや監査ファームの中にも「Level 3は近い」と曖昧に答える人がいます。
ところが、です。Level 3の前提となる構成要素は、もう揃っているんです。Continuous Audit Metrics Catalog v1.1、CCM v4.1へのマッピング、STAR Continuous プログラム、ENISAの継続的証跡要求。要は 「認証スキームとしての正式化を待っている」だけ であって、技術的・運用的な準備は今すぐ着手できる、というのが2026年5月時点の現実です。
先行する米欧の事業者はすでに継続監査API（Continuous Auditing API）のプロトタイプを動かしています。日本企業は「正式化を待ってから動く」と決めると、2027〜2028年の本格運用フェーズで1年遅れます。今回は実装現場目線で、Level 3の現状、SLO/SQO、API設計、Vanta/Drata等のツール活用までを整理します。
要約
- Level 3は2026年5月時点で正式リリース未達。2023年予定が複数回延期され、現在も準備フェーズ
- ただし構成要素は揃っている：Continuous Audit Metrics Catalog v1.1（33メトリクス）、CCM v4.1へのマッピング、STAR Continuous プログラム
- 中核概念：SLO（定量目標）／SQO（定性目標） を各コントロールに紐づけ、自動収集する設計
- 正式化を待つのではなく、正式化に備える が現実解。準備期間は1〜2年
- Vanta（毎時テスト）、Drata（リアルタイム監視）等の自動化SaaSは部分対応、CSA独自CAMはまだ自社実装が必要
- WARP SECURITY演習でカバー：CCM v4.1 → SLO/SQO変換ワークショップ、継続監査API設計演習
Level 3はなぜまだ出ていないのか — 3年待ちの構造的理由
「2023年に出る予定だった」という事実は、Level 3を理解する出発点です。CSAはSTAR Level 3を「継続監査認証（Continuous Auditing Certification）」として2020年頃から構想を公表し、2023年内のリリースを目標にしてきました。ところが2024年、2025年、2026年と延期が続き、2026年5月の現時点でも正式リリースのアナウンスは出ていません。
なぜここまで遅れているのか。私が情報を整理した範囲では、3つの構造的な理由があります。
1つ目は 「継続監査」という概念自体が、従来の監査人ビジネスモデルと衝突する こと。CPAやISO認証機関は、年次（または3年）の現地監査でフィーを稼ぐビジネスモデル。これが「365日24時間自動で監査される」になると、誰がどう価格設定するのか、契約形態をどうするのか、業界の根本設計から見直す必要があります。
2つ目は 証跡の信頼性をどう担保するか の技術的論点。継続監査は「事業者が自社で集めたログ・メトリクスを監査基盤に流し込む」仕組みになりますが、 「事業者が証跡を改ざんしていないか」をどう検証するか が未解決です。ブロックチェーンや改ざん検知型ログを使う案、第三者監査人がリアルタイムで証跡をプル取得する案、複数の検討が走っています。
3つ目は 業界横断の合意形成に時間がかかる こと。CSAはオープン標準団体で、AWS、Microsoft、Google、欧州事業者、日本のNTT等を含む多数のステークホルダーの合意が必要。EU CSA Schemeとの整合性、ENISAとの調整、AICPA（米国公認会計士協会）との連携など、調整事項が多すぎて時間がかかっています。
私の見方としては、Level 3の正式リリースは 2027〜2028年 のどこかになると予想しています。これは悲観論ではなく、複雑な制度設計には時間がかかるという現実の話。ただし、この「3年待ち」を「3年休んでいいよ」と読み替えてはいけません。
AI Security training, taken seriously
A 2-day intensive course fully aligned with OWASP, NIST, ISO/IEC 42001, and METI. Take it as executives, practitioners, or both.
構成要素はすでに揃っている — Continuous Audit Metrics Catalog v1.1の中身
正式認証スキームは未完成でも、Level 3の 技術的な構成要素はすでに公開済み です。これを知らずに「Level 3はまだ出ていない」だけで止まっていると、競合に大きく差をつけられます。
中核となるのが Continuous Audit Metrics Catalog（CAM） 。CSAが公開しているv1.1には、CCM v4.1の各コントロールにマッピングされた 33個の継続監査メトリクス が定義されています。
例えば、CCMのIAM（Identity & Access Management）ドメインに対しては、次のようなメトリクスが定義されています。
| メトリクスID（例） | 内容 | SLO / SQO |
|---|---|---|
| IAM-M1 | 特権アカウントの多要素認証適用率 | 100%（SLO） |
| IAM-M2 | アクセス権レビューの実施頻度 | 四半期1回（SLO） |
| IAM-M3 | 退職者アカウント無効化までの時間 | 24時間以内（SLO） |
| IAM-M4 | 異常アクセス検知の精度 | False positive rate < 5%（SQO） |
注目すべきは、これらのメトリクスは 「測定可能な数値またはステータス」に翻訳されている ことです。従来のISO 27001監査では「適切に管理されているか」という曖昧な評価でしたが、CAMは「数字で答えなさい」という設計になっている。これは継続監査の根本思想で、 「人が判断する監査」から「機械が判断する監査」への移行 を意味します。
私はCAMを「監査の言語変換装置」だと捉えています。CCMという静的な要件リストを、ログ・メトリクスというマシン可読なデータに翻訳する。この変換ができていない事業者は、Level 3が正式リリースされてもすぐに対応できません。
SLOとSQO — 「数字で答える監査」への翻訳
CAMの中核概念が SLO（Service Level Objective） と SQO（Service Qualitative Objective） です。SREの文脈でのSLOと類似していますが、目的が異なります。
SLOは 定量的なサービス目標値 。例えば「暗号鍵のローテーション頻度は90日以内」「インシデント検知から通知までの時間は4時間以内」など、数値で測定できる目標です。
SQOは 定性的なサービス目標値 。例えば「ログ分析プロセスがNIST 800-92準拠であること」「インシデント対応手順が文書化され、年次レビューされていること」など、ステータスや存在で評価する目標です。
なぜこの二層構造が必要かというと、 すべてのコントロールが数値化できるわけではない からです。アクセスログの保管期間は数値化できますが、「インシデント対応マニュアルが適切に整備されているか」は数値ではなく状態で評価する必要があります。SLOとSQOの組み合わせで、コントロール全体を可視化する設計です。
実装現場で重要なのは、 既存のSLI/SLO（Service Level Indicator/Objective）と継続監査のSLO/SQOは混同するな という点。SREのSLOは「サービスの可用性99.9%」のような顧客向け目標で、継続監査のSLOは「セキュリティコントロールの達成度」を測る監査向け目標です。同じ「SLO」という言葉でも目的が違うので、ダッシュボードを分けて運用するのが私のおすすめです。
私の経験では、CCM v4.1の207コントロールをSLO/SQOに翻訳する作業に 3〜6か月 かかります。これは外注でも可能ですが、できれば社内で議論しながら作る方が、後の運用で詰まりません。SLO/SQOを決める過程で「うちはこの程度のセキュリティでいいんだっけ？」という経営判断が必要になる場面が多発するからです。
API設計の現実 — Continuous Auditing API のプロトタイプ
Level 3の運用フェーズで決定的に重要になるのが 継続監査API（Continuous Auditing API） の設計です。CSAは2025年から「STAR Continuous」というプログラムを稼働させており、参加事業者は自社のSLO/SQOデータを定期的にCSAに送信する仕組みを試験運用しています。
技術アーキテクチャの一般形は次のとおりです。
- メトリクス収集層 ：CloudWatch、Datadog、Splunk、Prometheus等から生メトリクスを取得
- CCMマッピング層 ：生メトリクスをCAMのSLO/SQOフォーマットに変換
- 改ざん検知層 ：データの完全性を保証（ハッシュチェーン、署名、ログ集約サービス）
- API公開層 ：監査人が引っ張れるエンドポイント、または定期的にプッシュ送信
- 可視化層 ：内部ダッシュボード、外部顧客向け透明性ダッシュボード
このアーキテクチャを社内で構築するのが、Level 3の本質的な準備です。私が現場で見ている範囲では、 API公開層のスキーマ設計が一番難しい 。CSAが公式スキーマを正式リリースしていない現状では、各社が独自スキーマで先行構築し、後から正式仕様に合わせて改修するアプローチを取らざるを得ません。
これを聞いて「じゃあ正式化を待った方が無駄が少ないのでは？」と思う方がいるかもしれません。しかし私は逆の意見です。 正式化を待っていると、組織内のデータ収集パイプラインが間に合いません 。改修コストよりも、ゼロから構築する時間の方が圧倒的に長い。先行構築して、正式化したらスキーマだけ書き換える方が、トータルでは速いという結論です。
加えて、API公開層を持っていること自体が、 顧客向けの透明性アピール になります。AWS、Google Cloud、Microsoft Azureはコンプライアンスレポートを顧客向けに公開する仕組みを持っており、これを真似した「コンプライアンスAPI」を提供する中堅SaaSが2026年に入って増えてきました。Level 3が正式化される前から、この方向は不可逆だと考えています。
Vanta、Drata、Secureframe — 既存ツールでどこまでカバーできるか
「Level 3対応のために自社で全部作らないといけないのか？」という質問が必ず来ます。答えは 「半分くらいは既存ツールでカバーできるが、残り半分は自社実装が必要」 です。
主要なコンプライアンス自動化SaaSの比較は次のとおりです。
| ツール | 監視頻度 | 統合数 | CSA STAR対応 |
|---|---|---|---|
| Vanta | 毎時テスト | 250〜375+ | SOC 2/ISO 27001ベースで部分対応 |
| Drata | リアルタイム監視 | 75〜130+ | カスタムフレームワーク経由で対応可能 |
| Secureframe | 数時間ごと | 200+ | カスタム対応 |
Vantaは250〜375+の統合数で広く浅く、Drataは統合数では劣るがリアルタイム監視と深いカスタマイズが可能。Secureframeはその中間。共通点は、 SOC 2、ISO 27001、PCI DSS、HIPAA、GDPRをネイティブサポート していること。CSA STAR独自のCAMにネイティブ対応している製品はまだ少数です。
実装現場目線で言うと、 VantaやDrataで自動化されたSOC 2/ISO 27001の証跡を、CCMフォーマットに変換するブリッジ層を自社で書く のが現実的なアプローチです。具体的にはAWS LambdaやGoogle Cloud Functionsで、Vantaのレポートを定期的にCAMフォーマットに変換するスクリプトを動かす。完璧ではないですが、ゼロから作るよりは圧倒的に速い。
私は中堅SaaS事業者には 「VantaまたはDrataを導入し、CCMマッピングのブリッジ層を自社で書く」 をベースラインとして推奨しています。ハイパースケーラー（AWS、Azure、GCP）はもっと作り込んだ自社基盤を持っていますが、中堅以下は既存ツールに乗っかる方がROIが高い。
ただし、 「ツールを買えばLevel 3対応完了」は誤りです 。Vanta/Drataは「証跡を集める手段」であって、SLO/SQOをどう定義するか、どこまで自動化するか、改ざん検知をどう実装するか、という意思決定は人間が行う必要があります。ツールは武器、思考は人間、というのが私の整理です。
日本企業が今すぐ着手すべき3つの準備
Level 3の正式リリースを2027〜2028年と想定すると、今から逆算して動くべきことは明確です。私の現場経験から、3つに絞って提示します。
1つ目は CCM v4.1 → SLO/SQOマッピングを社内で完了させる こと。これは3〜6か月の作業で、外注でも可能ですが社内議論をしながら進めるべき。207コントロールを「うちはどこまで数値で監視できるか」「数値化できないものはSQOとしてどう定義するか」を決める作業は、経営層とセキュリティ部門が同じテーブルで議論する貴重な機会です。
2つ目は 継続監査APIのプロトタイプを構築する こと。CSAの正式スキーマを待たず、まず自社内で「VantaのレポートをJSONでエクスポートし、CCMフォーマットに変換するLambda関数」を1か月で作る。これがあると、Level 3正式化時にスキーマ調整だけで対応可能になります。
3つ目は 顧客向け透明性ダッシュボードを公開する こと。AWSやAzureが提供するコンプライアンスポータルの簡易版を、自社サービスのStatus Pageと並列で公開する。「うちはこの程度の継続監視をやっています」を顧客に見せられる事業者は、2026年時点ではまだ少数派。今やればブランディング効果が大きい。
この3つを2026年中に着手していれば、Level 3正式化時に半年で取得できる体制が整います。逆に着手していない事業者は、正式化発表から取得まで2年かかると見ています。 「3年待ち」を「3年休み」に変えるか、「3年準備」に変えるかの分岐点が今 、というのが私の結論です。
Level 2を飛ばしてLevel 3に行けるのか — 答えはNo
たまに「Level 1とLevel 2を飛ばして、いきなりLevel 3に行きたい」という相談がありますが、構造的に不可能です。Level 3は Level 2 の上位拡張であり、 Level 2の取得が前提 です。
正確には、CSAの公式定義では「Level 2の認証を保有していること」がLevel 3の必須要件。継続監査は 「Level 2で確認したコントロールが、365日24時間維持されていることを継続的に証明する」 仕組みなので、ベースラインのLevel 2がないと監査対象が定義できません。
ですから優先順位は明確で、 Level 1 → Level 2 → Level 3 の順番に進む必要があります。すでにLevel 2を持っている事業者は、Level 3への準備に進めますが、まだLevel 2を取っていない事業者はまずそちらが先。詳しくはLevel 1セルフアセスメント記事とLevel 2第三者監査記事を参照してください。
ちなみに、 Level 2のサーベイランス監査（年次）に継続監査の要素を組み込んでおく と、Level 3への移行がスムーズです。AWS、Microsoft Azureは既にこのアプローチを取っており、Level 2の定期監査の中で自動化された証跡収集を見せている。これが事実上のLevel 3先取りとも言えます。
WARP SECURITYで「継続監査API」設計演習を回せる
Level 3の準備で最大のハードルは、 「組織横断でSLO/SQOを合意し、APIアーキテクチャを設計する」 プロセスです。これはセキュリティ部門だけでは決められません。エンジニアリング、SRE、プロダクト、経営、すべてのステークホルダーが関与する必要があります。
TIMEWELLの WARP SECURITY では、Level 3に向けた「継続監査API設計演習」を実施しています。具体的には次の3モジュールです。
1モジュール目は CCM → SLO/SQO変換ワークショップ 。3日間で17ドメイン207コントロールを実際にSLO/SQOに翻訳する作業を、参加者全員でホワイトボードに書き出します。「うちは暗号鍵のローテーションを何日にするか」「インシデント通知のSLOを4時間にするか8時間にするか」を経営判断含めて議論。コンサルが代わりに決めるのではなく、参加者が決める設計です。
2モジュール目は 継続監査APIアーキテクチャ設計レビュー 。各社の既存メトリクスパイプライン（Datadog、CloudWatch、Splunk等）からCCMフォーマットへの変換層をホワイトボードで設計し、改ざん検知方式、API公開方式を決定します。AWS Solutions Architect経験者のメンターが伴走するので、技術的なフィージビリティも同時に確認できます。
3モジュール目は 顧客向け透明性ダッシュボードのモックアップ作成 。AWS Compliance Centerや Microsoft Trust Centerを参考に、自社版のダッシュボードのワイヤーフレームを作成。法務・営業・セキュリティが同じテーブルで「どこまで公開するか」を決める場を提供します。
私は「Level 3はセキュリティ部門のプロジェクトではなく、組織変革のプロジェクトだ」と考えています。継続監査を導入するということは、 「365日24時間、自社のセキュリティ状態を外部に見せる覚悟をする」 ことを意味します。この覚悟は文書を読んでも生まれない。手を動かす演習を通じてしか作れない、というのがWARP SECURITYの設計思想です。
まとめ — 「待たない」が最適解
CSA STAR Level 3は2026年5月時点で正式リリースされていません。しかしこれは「動かなくていい」という意味ではなく、 「今から動けば、正式化された時に先行できる」 という意味です。
着手すべき3つのアクション（社内SLO/SQOマッピング、APIプロトタイプ構築、顧客向けダッシュボード公開）は、いずれも単独で価値があります。Level 3が永遠に出ないとしても、これらの投資は無駄になりません。むしろ 「Level 3を待たずに継続監視の文化を社内に作る」 という副次効果の方が、長期的には大きい。
このシリーズの関連記事として、CSA STAR Level 1セルフアセスメント、CSA STAR Level 2第三者監査、ISO/IEC 27001完全ガイド、ISO/IEC 42001入門も合わせて読んでください。日本企業の対応優先順位はマスターガイドで整理しています。
私はこの3年間、CSA STAR Level 3の正式化を待ち続けてきました。待つのに疲れた、というのが正直なところです。それでも継続監査という方向性そのものは正しい。だから「待つ」ではなく「備える」に切り替えるべき、というのが2026年5月時点での私の結論です。
参考文献
[^1]: Cloud Security Alliance, "Continuous Auditing - STAR Continuous," 2019年3月19日, https://blog.cloudsecurityalliance.org/2019/03/19/continuous-auditing-star/ [^2]: Cloud Security Alliance, "The Continuous Audit Metrics Catalog v1.1," https://cloudsecurityalliance.org/artifacts/the-continuous-audit-metrics-catalog-v1-1 [^3]: Cloud Security Alliance, "The Evolution of STAR: Introducing Continuous Auditing," https://cloudsecurityalliance.org/artifacts/evolution-of-star-introducing-continuous-auditing [^4]: Quod Orbis, "The CSA STAR Level 3: Why We're Still Waiting for Continuous Monitoring," https://www.quodorbis.com/the-csa-star-level-3-why-were-still-waiting-for-continuous-monitoring-and-what-it-means-for-your-compliance-strategy/ [^5]: Cloud Security Alliance, "CCM v4.1 Transition Timeline," 2026年2月19日, https://cloudsecurityalliance.org/blog/2026/02/19/ccm-v4-1-transition-timeline [^6]: Sprinto, "Vanta vs Drata: Detailed Comparison," https://sprinto.com/blog/secureframe-vs-vanta-vs-drata/ [^7]: ENISA, "Star Methodology - European Union Cybersecurity Certification," https://certification.enisa.europa.eu/publications/star-methodology_en