企業にとって、利用しているクラウドサービスの安全性を把握することは、重要なリスク管理の1つである。その検証は、外部の監査やセキュリティ評価の結果を基に行うのが一般的だ。
だが、クラウドの機能更新は日々行われており、アジャイル開発やAIエージェントの普及で変化はさらに加速している。そんな中、年に一度確認するだけでは、過去はともかく現在や近い将来の状態まで見通すことは難しい。
5月27日開催の「TECH+セミナー クラウドインフラ 2026 May. クラウド運用の落とし穴~コスト・セキュリティ・人材不足を克服する~」では、順天堂大学 健康データサイエンス学部 准教授の満塩尚史氏が登壇。企業が取り組むべきセキュリティ対策として、クラウドサービスのリスク管理自動化と、データ駆動型ガバナンスへの移行について解説した。
クラウドサービス利用者が果たすべき責任範囲とは
満塩氏はまず、ITガバナンスの基本から説明を始めた。ITガバナンスで欠かせないのは、システムの状況をモニタリングし、評価し、その結果に基づいて指示するという一連のサイクルである。システムの開発や運用といったITマネジメントは、このサイクルに沿って進められる。
一方で、クラウドサービスで同じようなサイクルを回すには、利用者とクラウドサービスプロバイダー(CSP)の責任範囲を理解する必要がある。オンプレミスでは、利用者がデータセンターからOS、アプリケーション、データまで全てを管理していた。これに対しクラウドでは、利用形態にもよるがCSP側がミドルウェアやOSなどを管理するケースが多い。これが「責任共有モデル」だ。
ただし、CSPの責任範囲について利用者側が把握しなくてよい、という考え方には注意が必要である。とくに気を付けなければならないのは、クラウドサービスの利用者でありながらビジネスサービスの提供者でもあるSaaS事業者や業務サービス企業、IT部門などだ。なぜなら、サービスを提供している以上、どのIaaS/PaaS事業者を選ぶかという判断や、その運用管理の事前確認までも責務に含まれるからである。ミドルウェアやOSがCSPの領域だからと切り離すことはできない。同氏曰く、「最終責任は、やはりビジネスサービス提供者にある」のだ。
しかも、近年は責任の所在が以前より見えにくくなっている。生成AIのAPIを経由するSaaSやAIエージェントが間に入り、責任の分解点が一段と複雑になっているためだ。
では、この責務を果たすために、利用者はどのような情報を活用すべきなのか。満塩氏が挙げたのが、SOC2レポートやISMAPクラウドサービスリストの登録情報である。
SOC2レポートは、CSPの内部統制を第三者の監査人が評価した報告書だ。セキュリティや可用性、機密保持などの観点から、一定期間の運用状況を確認する。
ISMAP(Information system Security Management and Assessment Program)は、政府情報システムのためのセキュリティ評価制度である。外部監査機関がCSPのセキュリティ要求事項への適合を評価し、クラウドサービスリストとして公開し、登録情報も提供する。実施している統制目標だけでなく、実施していない統制目標まで参照できる。
両者に共通するのは、CSPの責務を特定し、利用者が補うべき点を明らかにしているところだ。まずはこうした情報を活用することがリスク管理の第一歩になるというのが、同氏の見解である。
3つの変化が従来監査の課題を浮き彫りにする
ただし、SOC2やISMAPの情報だけで現在の状態を十分に把握することが困難になってきている。これらは、数カ月から1年にわたる運用を外部監査機関が評価し、レポートにまとめて公開するまでには時間がかかるからだ。利用者がこうしたレポートを通して確認できるのは過去の一定期間の状況であって、現在や将来の話ではない。
この時間差の課題をより深刻なものにしているのが、クラウドサービスの機能更新の加速、アジャイル開発、AIエージェントという3つの変化である。
まず、機能更新の加速だ。例えば、AWSのサービスリリースは、2015年には1日あたり2件ほどだったが、近年は1日8~10件だという。AI関連サービスでも同様で、OpenAI関連のライブラリやモデルも頻繁に更新されている。更新が速いほど、契約や監査の時点と実際に使う時点とでずれが生じてしまう。
「監査結果を適用できる範囲が限定的になったり、契約した後も評価されていないことを理由に最新の機能を使えなかったりする場合もあります」(満塩氏)
次に、アジャイル開発の浸透だ。ウォーターフォール開発では年単位だったリリースが、いまは数週間から数カ月単位でデプロイを繰り返すのが当たり前になってきた。年に一度の監査結果では、こうした継続的な変更に追いつけない。
AIエージェントの登場も大きい。これまでIaaS/PaaSのAPIは人が操作してきたが、その操作をエージェントが代理するようになりつつある。1人の利用者が複数のエージェントを並列で動かせば、誰が何を判断して実行したのかが見えにくくなるわけだ。
多数のAIエージェントがITマネジメントの実務を実行するようになり、人間には、その動きをモニタリングし、評価し、必要に応じて指示するガバナンスとしての役割がより求められる。その判断基準は、AIではなく人間が定める必要があると満塩氏は指摘した。
もっとも、エージェントを監視する仕組みは発展途上にある。入力と出力を見るだけでなく、どのツールをどう使い、エージェント間でどう合意形成したかという内部の動きまで監視する必要があるが、その多くはまだ研究段階だ。
これらの変化によって、従来の監査が前提としてきた条件が揺らいでいる。監査した時点の構成が現在も保たれていること、人が事前に承認していること、操作の主体が人であること。今後はこうした前提が成立しにくくなるため、新しい評価と情報提供の在り方が必要になる、というのが同氏の見解である。
リスク管理は自動評価と継続的モニタリングへ
そこで満塩氏が提示するのが、自動評価と継続的モニタリングだ。
自動評価のポイントは、2つのものを機械的に突き合わせることにある。1つは、守るべきセキュリティの基準を機械が読めるかたちで記述したポリシー(Policy as Code)。もう1つは、コードで記述・管理されたIaaS/PaaSの構成(Infrastructure as Code)だ。両者を自動評価エンジンで照合し、基準に適合しているか、外れているかを自動で判定する。不適合があれば、その結果を是正につなげるのだ。
この照合を支える標準形式が、米国NISTの定めるOSCAL(Open Security Controls Assessment Language)である。セキュリティに関する統制情報を、人も機械も読めるかたちで表現するための形式だ。これにより、監査作業の自動化や、リスク状況を継続的に追える仕組みがつくれるようになるという。
注目すべきは、今すでにあるSOC2やISMAPの情報との連携だ。これらは現状OSCALには書かれていないが、OSCALの形式で取り込める可能性がある。そうすれば、利用者が補完すべき統制の洗い出しや、自社の統制とのギャップ分析なども機械的に行えるようになる。
「これまではSOC2レポートもISMAPサービスリストの登録情報も、人間が直接読んで判断する世界でした。これからは機械が突合してリスク管理をする世界へと、だんだん移行していくのではないかと考えています」(満塩氏)
継続的モニタリングは、運用中のサービスを継続的に監視・評価する仕組みである。クラウド側には、構成の変化や不審なAPI呼び出しを検知するツールがすでに備わっている。例えば、AWSのSecurity Hub、Config、GuardDutyなどがそれに当たる。また、開発側のGitHubでも、コード変更の記録が日々蓄積されている。こうしたツールの記録をOSCALの形式で集約すれば、運用状態を継続的に評価できるというわけだ。
「点」のチェックから「線」での把握へ
では、こうした自動化は最終的にどこへ向かうのか。満塩氏が挙げたのが、データ駆動型ガバナンスへの移行である。
鍵になるのは、リスク状態をチェックする頻度だ。1年に1度だけの監査から、月次、日次と細かくしていき、さらにAIエージェントの時代には、時間・分単位に近い管理や観測が求められる。
「年に一回チェックすればよかった世界から、全ての状況を線として把握することが必要な世界になってきています」(満塩氏)
観測すべき対象も複雑になっている。かつては人がワークフローを決めて、ステップごとに承認し、順に処理が進んでいた。一方でAIエージェントの時代には、1つの指示から複数のエージェントが自律的・独立的に相互作用しながら動作する。いつ、誰が、何をしたのかが追いにくくなり、その行動ログや対話ログが新たな管理対象になることが予測される。
ただし、データ駆動型ガバナンスへの移行は、決して全てを機械に委ねるという話ではない。ガバナンスを動かすのは、これからも人間だ。最終的な判断は人間が下し、その判断をデータが支えるという考え方である。
まずは、CSPから提供されるSOC2やISMAPを活用し、現状におけるリスク管理を強化する。そのうえで、AIエージェントやアジャイル開発の拡大などに対応するため、Policy as CodeやOSCALを活用した自動評価、継続的モニタリングへ移行していく。最終判断を人間が担い、その判断をデータで支えることが、目指すべきデータ駆動型ガバナンスの姿なのだ。

