J-SOXにおけるクラウド・SaaSのコントロール：SOC 1・共有責任・現代のITGC（2026年版）

J-SOXシリーズの一部です。日本の上場グループが財務システムをクラウド・SaaSに移行しても、コントロールはJ-SOXのスコープから外れません——形が変わるだけです。

日本の上場グループが財務システムをクラウドに移行するとき、現場でよく耳にする危険な思い込みがあります——「クラウドに移行したから、あのシステムはJ-SOXのスコープから外れた。だってプロバイダーがセキュリティを担うんだから」。これは誤りです。仕訳を登録するシステムは、自社のデータセンターで動いていようとクラウドで動いていようと、スコープに残ります。変わるのはコントロールの形と証明方法だけであり——そのシフトこそが、クラウド移行が静かにJ-SOX対応を崩す場所です。

私はCCSPとCISSPを保有する情報セキュリティの実務者であり、クラウドのコントロールモデルは私の専門領域です。これは、クラウド・SaaS環境における J-SOXの実務的な見方です。

クラウドはスコープを消さない——責任を分割するだけ

基本概念は共有責任です。クラウドやSaaSでは、プロバイダーが一部のコントロールを運用し、利用者が残りを運用します。財務システムであれば次のようになります。

• プロバイダーは、自身が運用するインフラやプラットフォームのコントロール——物理セキュリティ、ハイパーバイザー、マネージドサービスの運用——に責任を持ちます。
• あなたは、それをどのように設定・利用するか——誰がアクセスできるか、設定やデータの変更をどう管理するか、どんな財務データを投入するか——について責任を持ちます。

J-SOXの証跡はこの両側をカバーする必要があります。最もよく見る失敗は、チームが「プロバイダーがすべてカバーしているはずだから、自分たちは何もしなくていい」と思い込み、結果として何も文書化しないケースです。

プロバイダーへの依拠：SOC 1レポート

クラウドプロバイダーを自分で監査することはできませんし、J-SOXもそれを求めていません。代わりに、プロバイダーのSOC 1 Type IIレポート——利用者の財務報告に関連するサービス組織のコントロールを、単一時点ではなく一定期間にわたって独立した監査人が保証するレポート——に依拠します。

SOC 1 Type IIレポートは、プロバイダーが運用する層を直接テストのスコープから外し、同等のITGCを自社で再実装する代わりにそのコントロールに依拠させてくれます（SafePaaS）。しかし依拠は免罪符ではありません——以下の義務が伴います。

• レポートを読む。 対象期間、対象サービス、財務報告に関連するコントロール目標をカバーしているか確認する。
• 除外事項を確認する。 サービス監査人が指摘した例外はあなたの問題でもあります。
• 補完的利用者エンティティコントロール（CUEC）を実施する。 すべてのSOC 1レポートは、あなた側で一定のコントロールを実施することを前提としています。これらは明示的にあなたが証跡を取るべきものであり、依拠が崩れる最も多い箇所です。

移行の落とし穴

2023年のJ-SOX改正が照準を合わせているのがこの失敗パターンです。システムのアップグレード、クラウド移行、新規アプリケーション実装は文書化のギャップを生み出します（TeamBench）。旧オンプレミスシステムのコントロール記述は、新しいSaaSプラットフォームには自動的に引き継がれません。そして移行作業そのものが、監査人が注目するリスクの高い変更です。

セキュリティ設計の観点からすると、これはどんな大きな変更にも当てはまる教訓と同じです——カットオーバーのタイミングは最もコントロールが失われやすい瞬間です。なぜなら全員が「動かすこと」に集中していて、「コントロールされていることを証明すること」に誰も意識が向いていないからです。移行を「それ自体がスコープ内の管理された変更」として扱ってください——承認、データ変換の検証、そして移行後に再構築されたコントロール記述を含めて——「後で文書化しよう」という発想ではなく。「後で」こそがJ-SOXの指摘が生まれる場所です。

クラウド・SaaS対応 J-SOX実務チェックリスト

• 財務系クラウド・SaaSシステムをスコープ内に置き続ける——プロバイダーの責任があなたの責任を消すとは思わない。
• スコープ内の各サービスについて共有責任の境界をマッピングする：プロバイダーが何をコントロールし、あなたが何をコントロールするか。
• プロバイダーのSOC 1 Type IIレポートを入手・精査する——対象期間、対象サービス、コントロール目標、除外事項を確認。
• レポートが前提とするCUECを特定し、自社で実施する。
• 設定とアクセスを一級のITGCとして管理する——ITGCの詳細記事を参照。
• 移行はスコープ内の管理された変更として扱い、コントロール記述をカットオーバー前に再構築する（後からではなく）。

参考文献

• ITGC vs SOX controls: what’s the difference （SafePaaS, 2026-06-11 確認）
• J-SOX internal control documentation for listed companies （TeamBench, 2026-06-11 確認）
• J-SOX: Japan’s Sarbanes-Oxley equivalent （EisnerAmper, 2026-06-11 確認）