定義
クライアントが「来月SAPからNetSuiteに移行します」と告げた瞬間、監査人の頭の中で計画書が崩れる。物理的にサーバールームを訪問してパッチ適用記録を確認する、という従来の手続が成り立たなくなるからだ。代わりに何を確かめるのか——その問いに答えるのが、クラウド監査リスクという論点。
クラウドコンピューティング監査リスクとは、被監査会社のデータ・処理・システムがサードパーティのクラウドプロバイダー上で稼動する場合に、監査人が財務諸表の重要な虚偽表示を発見できない可能性をいう。監基報315は、IT環境（クラウドを含む）に関連したリスクを識別し、それに応じた監査手続を設計する責務を監査人に課している。
統治基準: ISA 315 第33項～40項、ISA 330 第20項
---
ポイント
> - クラウド環境では、監査人が物理的なシステムにアクセスできない。データ置所もバージョン管理の追跡も、契約書とログ越しにしか見えなくなる。 > - SaaS・PaaS・IaaSで監査人の検証対象が異なり、依拠するコントロール報告書もISAE 3402かSOC 2かで分かれる。 > - プロバイダー側の改修や障害が、被監査会社の財務報告プロセスを直撃する。計画段階で識別できなければ、期末で慌てることになる。
---
仕組み
クラウド監査リスクは2つの層に分けて考えると整理しやすい。アーキテクチャと変更管理を1つにまとめ、データ所在地を独立させる構成。
第1層：アーキテクチャと変更管理のリスク
よくある誤解から入る。「ISAE 3402のType II報告書が手元にある＝大丈夫」と昔は思っていた時期があった。実際には違う。報告書のコントロール目標が当該被監査会社の財務報告プロセスに対応していなければ、依拠の余地は限定される。
監基報315.34は、情報システムの特性を識別する責務を定めている。オンプレミス環境であれば「特性」とは設定ファイル、バージョン、パッチ適用記録のこと。クラウド環境ではこれが契約条項、SLA、サービス提供者監査報告書（ISAE 3402 Type II等）に置き換わる。
ところが、SaaS型クラウド会計（Workday、NetSuite等）ではバージョンアップがプロバイダー側で自動的に行われる。被監査会社側の制御ポイントは限定されるのが実態。従来であれば「この月は何度バージョンを更新したか」を監査人が追跡できた。SaaSではそれができない。代わりに「プロバイダーが何を変更したか、その変更が当社システムに影響したか」を、文書化されたSLA・プロバイダー側の変更ログ・ISAE 3402報告書を介して読み取るしかない。監基報330.20が求めるのは、IT環境の変更が業務プロセスの有効性に影響しないことの確認。クラウドではその確認手段が間接的になる、というのが正直なところ。
グレーゾーン： ISAE 3402報告書のコントロール目標に「ネットワーク設定の変更権限の分離」が含まれていない場合、その項目について監査人は何を根拠にすればよいのか。基準は「補完手続を設計せよ」と言うが、現場では予算の制約で見送られることが少なくない。
第2層：データ所在地と多拠点処理のリスク
プロバイダーが複数地域にデータをレプリケートする運用を採るとき、被監査会社の財務データがどこに保存されているか、どの地域のサーバーが計算処理を実行しているかが曖昧になる。この曖昧性から派生するリスクは2つ。第一に、データ主権の問題（EU GDPR、その他地域規制で特定地域外への移転が禁止される場合がある）。第二に、サイバーセキュリティ侵害が発生したときの影響範囲と、監査証拠としてのデータ信頼性の評価が難しくなること。
監基報315の段階で、被監査会社がこれらのリスクをどう管理しているか理解する必要がある。理解の手段は概ね3つ：(1)被監査会社による内部システム監査報告書、(2)プロバイダー側のISAE 3402 Type IIまたはSOC 2 Type II報告書の入手と評価、(3)被監査会社とプロバイダー間のサービス契約書（SLA含む）の精読。
現場での見方が割れる点： パートナーAは「ISAE 3402 Type IIが網羅的であれば、それで十分な監査証拠になる」と主張する。パートナーBは「報告書はあくまでプロバイダー側のコントロールの説明であって、被監査会社のアサーションを直接立証していない。セキュリティのアクセス制御については自社による補完テストを必須にすべき」と反論する。どちらも筋が通っている。うちの事務所では後者寄りで運用しているが、案件の規模次第で前者を採ることもある。
---
実務例：岡田ファイナンシャルシステムズ
被監査会社概要 岡田ファイナンシャルシステムズ（東京、従業員120名）。2023年1月、オンプレミスのERP（SAP）からNetSuite（SaaS）に移行した。売上は前年度7.8億円、財務報告はIFRS適用。
ステップ1：リスク識別 監査人は計画段階で、移行に伴うリスクを以下のとおり識別した。
- 国内（金融庁の監督対象）のデータが、複数国のサーバー配置を持つパブリッククラウド環境に置かれることになった。 - 従前は「毎月第1営業日にバージョンアップを計画的に実行」していたが、NetSuiteの自動アップデートでは「プロバイダーが月1～2回、予定なしに更新」する運用に変わった。 - 給与計算サブシステムがNetSuiteに統合され、人事部と経理部の間のインターフェースが廃止された結果、自動データ受け渡しのみとなった。
文書化ノート：監査計画書（別紙A）に「クラウドシステムリスク」として上記を記載。評価レベルは「高（重要な虚偽表示の可能性が高い）」と判定。
ステップ2：プロバイダー監査報告書の入手と評価 NetSuiteのISAE 3402 Type II監査報告書の最新版を被監査会社から入手。オラクル・ジャパンが2024年1月に発行した報告書を確認したところ、セキュリティ（アクセス制御）、可用性（99.9% SLA）、処理の完全性（トランザクションログ）の3つのコントロール目標が監査対象となっていた。
文書化ノート：ISAE 3402報告書（コピーを調書フォルダ「クラウド証拠」に保管）をレビュー。チェックリスト「プロバイダー報告書評価」を完成。結論は「セキュリティと処理完全性は十分に監査されている。可用性SLAは99.9%で業界標準。依拠可能と判定。」
ステップ3：SLAと実績の比較 NetSuiteとの契約書から、約定SLAを抽出。可用性99.9%、データバックアップ24時間以内、障害検出から復旧までの目標時間（RTO）4時間。被監査会社のシステム運用ログ（2024年1月～6月）から、実績の可用性は99.92%、バックアップは全て約定通り、障害発生2件（いずれも2時間以内に復旧）を確認。
文書化ノート：SLA実績表（別紙B）に記載。結論：「契約上の約定は全て充足。財務報告プロセスに対する重要な無効化リスクは検出されなかった。」
ステップ4：システム変更ログの追跡と判断 NetSuiteの管理画面から、2024年1月～6月のシステム変更ログをエクスポート。14件の変更を確認し、各変更が被監査会社の財務報告に影響を与える可能性を評価した。「給与計算アルゴリズムの微調整」1件のみが会計的な影響を持つことが判明。当該変更は税務控除ロジックの更新で、被監査会社側では把握していなかった。経理部に通知した結果、売掛金台帳に1,200円の修正が必要と判定。
ここで現場の判断が問われる。被監査会社の経理部長が反論してきた——「1,200円は明らかに重要性の基準値以下、調書に記録するだけで修正は不要では」。確かに金額単独では重要性に達しない。しかし問題は別にある。クラウド側の自動変更を被監査会社が検知できていなかったという内部統制上の事実、そしてこれが監基報315.36でいう「外部情報源から得た情報の信頼性評価」に直結する点。うちのチームでは、金額の小ささより「検知漏れの兆候」を重く見て修正と内部統制上の指摘の両方を実施した。経験上、こうした小さな不一致を放置すると半年後に類似の漏れが顕在化する。
文書化ノート：変更ログ（別紙C）に赤色でハイライト。修正内容と判断プロセスを調書に明記。
結論 クラウド移行によるシステムリスクは存在する。だが、(1)ISAE 3402報告書によるプロバイダー側の制御検証、(2)SLA実績確認、(3)変更ログの直接追跡、(4)検知漏れの内部統制評価、を組み合わせることで、財務報告の有効性に対する信頼を維持できる。検証手段が「物理的アクセス」から「文書と契約とログの読み込み」に変わるだけで、リスク評価の枠組みそのものは変わらない。
---
監査人と経営者が見落とすもの
- 「クラウド＝自動的に安全」という誤解。複数の監査事務所が、ISAE 3402報告書の存在そのものを「十分な証拠」と見なしてしまう実態がある。Type IとType IIの違い、コントロール目標の範囲外項目を検証していないケースも少なくない。監基報315.36は外部情報源から得た情報の信頼性を評価する責務を定めている。プロバイダーが監査対象にしていない項目（例：ネットワーク設定の変更権限の分離）がある場合、監査人自らがそのリスク評価を補完する必要がある。
- SLAと監査証拠は別物。プロバイダーが「可用性99.9%を保証する」ことと、監査人が「実績がそのSLAを満たしている」ことを確認することは別の話。被監査会社がプロバイダーの監視ダッシュボードにアクセスできない場合、監査人が実績の99.9%を独立に検証する手段がない。当該項目がISAE 3402報告書のコントロール目標に含まれているか確認するのが先。含まれていなければ、個別評価の対象外として明記する判断が要る。
- マルチテナント環境でのデータ分離。SaaS提供者の多くは複数顧客データを同一データベース内に管理し、ロールベースアクセス制御（RBAC）で分離する。「自社のデータが他社の従業員に見えないか」という検証は、通常ISAE 3402の「セキュリティ」コントロール目標に含まれる。報告書がこの点を明示していない場合は、別途確認が必要。
- なぜ中堅事務所はISAE 3402に過度に依拠するのか。正直に言うと、構造的なインセンティブの問題。代替手続（独立IT検証）はエンジージメント予算の30%超を消費する。ISAE 3402への依拠で完結させる方が短期的には合理的に見える。ただし金融庁検査でこの判断の妥当性を問われたとき、依拠根拠が薄ければ品管上の指摘につながる——うちの事務所では、この一点を理由に2024年から補完テストの最低水準を引き上げた。
---
関連する用語
- ISA 315 リスク評価基準 - 情報技術環境の特性を識別し、それに対応したリスク評価を行う枠組みを定める基準。
- ISAE 3402 サービス提供者の監査報告書 - クラウドプロバイダー側が委託されたコントロールの有効性を証明する報告書。Type I（特定時点）とType II（期間）の2形式がある。
- SOC 2 監査報告書 - 米国公認会計士協会（AICPA）が定めたサービス提供者の監査基準。セキュリティ、可用性、処理完全性等を評価する。
- SLA（サービスレベル契約） - クラウドプロバイダーが被審査会社に対して約束するサービス品質（可用性、応答時間等）を定めた契約。
---
関連する基準と文書
ISA 315.33～40（リスク評価の詳細手続）、ISA 330.20（対応する監査手続の設計）、ISAE 3402（サービス提供者監査報告書）、被監査会社とクラウドプロバイダー間のサービス契約書（SLA含む）
---