「今年もアクセス権の棚卸しが不備として指摘された」「退職者のアカウントが残ったままだった」——J-SOX対応を担当する情シス部門から、毎年こうした声が聞こえてきます。

2024年4月、内部統制報告制度（J-SOX）が約15年ぶりに改訂され、情シスが対応すべき範囲はさらに広がりました。SaaSやクラウドの利用が当たり前になった今、複数システムにまたがるアクセス管理、変更の証跡、監査ログの整備は、どの企業にとっても切実な課題です。

この記事では、IT全般統制の体系から具体的な対応手順、SaaS環境での実践ポイント、管理ツールを使った効率化の方法まで、情シス部門の担当者・責任者が実務で使える内容をまとめて解説します。

SOX対応とIT管理の関係を正しく理解する

「J-SOXは経理部門の話」と思われがちですが、現実には情シスが担う範囲が大半を占めます。対応を始める前に、IT統制の全体像を把握しておくことが重要です。

J-SOXにおけるIT統制の位置づけ

J-SOX（金融商品取引法に基づく内部統制報告制度）は、上場企業が財務報告の信頼性を確保するための制度です。企業は毎年、内部統制の整備・運用の状況を評価し、報告書として開示する義務があります。

現代企業の財務データは、ほぼ全てITシステムを通じて処理・保管・報告されています。そのITシステム自体が適切に管理されていなければ、財務報告の信頼性は根本から揺らぎます。だからこそ、IT統制が内部統制全体の基盤として重視されるのです。

情シス部門が中心的に担う役割は「ITを利用した内部統制」の整備と評価です。アクセス権限管理、システム変更のコントロール、監査ログの取得・保管、障害対応手順の整備——これらは全て情シスの仕事になります。

IT全社統制・IT全般統制・IT業務処理統制の違い

IT統制には3つの階層があります。

IT全社統制は、組織全体のITガバナンスに関する統制です。IT戦略、IT部門の組織体制、ITリスク管理方針、セキュリティポリシーの整備などが含まれ、経営層の関与が求められる領域です。

IT全般統制（ITGC: IT General Controls）は、個々のシステムが適切に機能するための基盤となる統制です。アクセス管理・変更管理・運用管理・開発管理の4カテゴリに分かれ、情シス部門が最も深く関わる領域でもあります。

IT業務処理統制は、個々の業務アプリケーションに組み込まれた自動統制です。入力データの検証、計算処理の精度、権限に基づく承認フローなどが対象になります。

情シスが主戦場とすべきは「IT全般統制」です。全社統制・業務処理統制への関与も必要ですが、ITGC整備・評価が情シスの中核業務です。

2024年改訂で何が変わったか

2024年改訂で情シスに特に影響の大きい変更点を整理します。

• クラウド・委託先への対応強化：改訂では「ITの委託業務にかかる統制の重要性が増している」と明記されました。SaaSやクラウドを利用している場合、委託先のIT統制についても評価・確認が求められます。
• サイバーセキュリティの位置づけ強化：クラウドやリモートアクセスに伴うサイバーセキュリティリスクへの対応が、内部統制評価の明確な項目として加わりました。
• 不正リスクの考慮：不正リスクを評価に含めることが求められるようになり、職務分離（Segregation of Duties）の重要性が一段と高まっています。
• 運用証拠の強化：整備状況の確認に加えて、「実際に運用していることを証明できる記録」がより明確に求められるようになりました。

参考: 15年ぶり改訂のJ-SOX、IT部門がいますぐ知っておくべき5つのQ&A

IT全般統制（ITGC）の4大カテゴリ

IT全般統制はJ-SOX対応の核心です。4つのカテゴリそれぞれが何を対象としているかを正確に理解することが、漏れのない対応への第一歩になります。

アクセス管理（Access Management）

アクセス管理はJ-SOX監査で最も頻繁に指摘を受ける領域です。「誰が・どのシステムに・どの権限でアクセスできるか」を適切にコントロールすることが目的です。

具体的に求められる統制は以下の通りです。

• ユーザーアカウント管理：入退社・異動に連動したアカウントの作成・削除・変更の手順
• アクセス権限の定期レビュー：年1〜2回の棚卸しと不要権限の削除
• 特権アカウント管理：管理者権限を最小化し、使用履歴を記録する
• パスワードポリシー：複雑性要件・有効期限・再利用制限の設定
• ログイン試行の監視：不正アクセス試行の検知と記録

SaaSを多数導入している企業では、個々のシステムでアクセス管理を個別に行うことになり、管理の複雑さが増します。これが現代の情シス部門における最大の悩みの一つです。

変更管理（Change Management）

変更管理は、システムへの変更（プログラム修正・設定変更・パッチ適用など）が適切なプロセスを経て実施されることを確保する統制です。

• 変更要求の承認フロー：変更内容の記録、リスク評価、権限者による承認
• テスト環境での検証：本番適用前に開発・テスト環境で動作確認
• 職務分離：変更の申請者・承認者・実施者を分離する
• 変更履歴の保管：いつ・誰が・何を変更したかの記録
• 緊急変更手続き：緊急時の対応手順と事後承認プロセス

「開発担当者が本番システムに直接変更を加えられる状態」は、J-SOX上の重大な不備として指摘されます。開発環境と本番環境を明確に分離し、全ての変更に証跡を残すことが必須です。

運用管理（Operations Management）

運用管理は、日常的なシステム運用が安定して継続されることを確保する統制です。

• ジョブ管理：バッチ処理の実行監視とエラー対応手順
• バックアップ：データのバックアップ取得・保管・リストアテストの実施
• インシデント管理：障害時の対応手順とエスカレーション体制
• キャパシティ管理：リソース監視と計画的な拡張
• セキュリティ管理：マルウェア対策、パッチ適用の管理

開発・実装管理（Development Management）

開発・実装管理は、新規開発や大規模改修が適切なプロセスで行われることを確保する統制です。

• 要件定義・設計レビュー：業務部門の承認を得た要件定義書
• テスト計画と実施：ユニット・統合・受け入れテストの文書化
• 本番移行の承認：リリース前の最終承認プロセス
• 文書化：システム仕様書・運用マニュアルの整備

参考: J-SOX実施基準の実務対応ガイド（OAGコンサルティング）

SaaS環境でのアクセス権限管理の実践手順

クラウド・SaaSの活用が当たり前になった今、アクセス管理の複雑さは以前とは比べものになりません。「Excelで管理しているが棚卸しが追いつかない」という声をよく聞きます。SaaS環境に特化した実践的な手順を解説します。

アクセス権限 棚卸し 方法

アカウント棚卸しの進め方

「アクセス権の棚卸しが実施されていない」「棚卸しの証跡が残っていない」——これはJ-SOX対応の典型的な指摘事項です。年に一度の作業だからこそ、手順を標準化して誰でも実施できる形にしておくことが大切です。

Step 1: 対象システムの洗い出し財務報告に影響を与えるシステム（基幹系・会計系・人事系など）を中心に対象範囲を確定します。SaaSを含む全システムのリストを作成しましょう。

Step 2: 現在のアカウント・権限リストの取得各システムから現在のユーザーリストと権限情報を取得します。SaaSの場合は管理画面のエクスポート機能を活用します。

Step 3: 人事情報との照合取得したアカウントリストを在籍者リストと照合します。退職者・異動者のアカウントが残っていないかを確認します。

Step 4: 権限の適切性確認各ユーザーの業務内容に対して付与されている権限が適切かどうかを確認します。「業務上不要な権限が付与されていないか」「最小権限の原則が守られているか」がチェックポイントです。

Step 5: 是正と記録不要なアカウントの削除、過剰権限の削減を実施し、棚卸しの証拠として記録を残します。業務承認者のサインも忘れずに。

監査ログ 取り方 SaaS

入退社時のプロビジョニング・デプロビジョニング

アクセス管理の不備の多くは、入退社対応の遅延や漏れから発生します。退職者のアカウントが残ったままの状態は、J-SOX上の問題であるだけでなく、情報セキュリティ上の深刻なリスクでもあります。

入社時（プロビジョニング）の手順:

1. 人事システムからの入社情報受け取り
2. 業務内容・役職に基づく必要システムの特定
3. 各システムへのアカウント作成と権限付与
4. 対象者への案内と初期設定の完了確認
5. アカウント作成の記録・証跡保管

退社時（デプロビジョニング）の手順:

1. 退社情報の早期入手（退社日前に連絡を受ける体制の整備）
2. 退社日当日の全システムアクセス無効化
3. データの引き継ぎ確認とアカウント削除
4. 対応完了の記録・証跡保管

多くの企業で問題になるのが「デプロビジョニングの遅延」です。人事部門と情シス部門の連携が取れておらず、退職後もアカウントが有効のまま放置されるケースは珍しくありません。この問題を根本から解決するには、人事システムとITシステムの連携を自動化することが有効です。

オフボーディング IT 自動化

最小権限の原則をSaaSに適用する

最小権限の原則（Principle of Least Privilege）とは、各ユーザーが業務遂行に必要な最小限のアクセス権限のみを持つという考え方です。財務データへの不正アクセス・不正操作のリスクを低減するためにも、J-SOXの文脈では非常に重要な原則です。

SaaSでこの原則を実践するポイントは以下の通りです。

• 役職・業務別の権限マトリクスを作成する：「このロールの人はこのシステムのこの機能にアクセスできる」というルールを文書化する
• 管理者権限の最小化：Admin権限を持つユーザー数を絞り、その理由を記録する
• 閲覧と編集の分離：閲覧のみの業務には編集権限を付与しない
• 定期的な権限レビュー：異動・役職変更に伴う権限の見直しを定期実施する

参考: 日本版SOX法（IT全般統制）への対応 - LogStare

監査ログの取得・保管・活用方法

監査ログは「誰が・いつ・何をしたか」を証明する重要な証拠です。監査人が証拠として求めるログを適切に取得・保管しておかないと、実際に統制が機能していても証明できない事態になりかねません。

SOX対応で必要なログの種類

J-SOX対応で取得・保管すべきログは多岐にわたります。主要なものを整理します。

認証・アクセスログ:

• ユーザーのログイン・ログアウト記録
• ログイン失敗（不正アクセス試行）の記録
• 特権アカウントによるアクセス記録
• アクセス権限の変更記録

業務処理ログ:

• 財務データ（会計仕訳・売上データなど）への変更記録
• データベースの直接変更記録
• 重要マスタ（商品・取引先など）の変更記録
• 承認フローの実行記録

システム運用ログ:

• バッチ処理の実行・完了・エラー記録
• システム設定の変更記録
• バックアップの実行記録
• セキュリティアラートの記録

変更管理ログ:

• プログラム変更の申請・承認・実施記録
• 本番環境へのデプロイ記録
• 緊急変更の実施記録

ログ保管期間と証拠管理のルール

J-SOXでは、内部統制の評価に必要な証拠書類を7年間保管することが基本です（会社法の書類保存義務に準じます）。実務的には以下の点を考慮したポリシーの策定が必要です。

• ログの種類別に保管期間を設定する：財務報告に直接関連するログは長期保管、日常運用ログは短期でよい場合があります
• 改ざん防止措置：保管ログが改ざんされていないことを証明できる仕組みが必要です。読み取り専用ストレージへの保管やハッシュ値による整合性チェックが有効です
• 検索・抽出の容易性：監査時に特定期間・特定ユーザーのログを迅速に抽出できる状態を維持してください
• 保管場所の台帳整備：どのログがどこに保管されているかを記録した管理台帳の整備も重要です

複数SaaSのログを一元管理する方法

数十〜数百のSaaSを利用している企業では、各サービスがバラバラにログを保管している状態が一般的です。このままでは棚卸し時に各管理画面を個別に確認する作業が発生し、監査対応の効率が著しく低下します。

SIEM（セキュリティ情報・イベント管理）の活用: 複数システムからログを収集・集約し一元的に管理・分析するツールです。セキュリティ観点では強力ですが、コストと設定の複雑さが課題です。

SaaS管理プラットフォームの活用: ジョーシスのようなSaaS管理プラットフォームを利用することで、各SaaSのアクセス状況や権限情報を一元管理できます。操作履歴の可視化や棚卸しの自動化にも対応しています。

API連携による自動ログ収集: 各SaaSのAPIを活用してログデータを自動取得・集約する仕組みの構築も可能です。ただし、構築・維持にコストがかかる点は考慮が必要です。

参考: ログをしっかり残して管理することがJ-SOX対応への一歩（インテック）

変更管理と運用管理の整備

変更管理の不備は、J-SOX監査でしばしば重大な問題として指摘されます。「本番環境への変更が承認なしで実施されていた」「変更履歴が残っていない」という状況は、財務報告の信頼性に直接影響するリスクとして評価されます。

システム変更の承認フロー設計

実効性のある変更管理には、以下の要素が必要です。

変更要求書（RFC: Request for Change）の起票:変更内容・変更理由・リスク評価・テスト計画・ロールバック計画を含む変更要求書を作成します。

承認プロセスの設計:

• 変更申請者（開発担当者）
• 技術レビュー担当者（シニアエンジニア・アーキテクト）
• ビジネスオーナー（業務部門責任者）
• IT管理者（情シス部門長）

財務報告に影響する重要システムの変更は、より厳格な承認プロセスが必要です。メール承認の場合はそのメールを証拠として確実に保管してください。

緊急変更（Emergency Change）の取り扱い:緊急時には通常のプロセスを省略せざるを得ない場面もありますが、事後承認の仕組みを整備し、緊急変更の記録を確実に残すことが重要です。「緊急だったから記録が残っていない」は通用しません。

運用・開発の職務分離（Segregation of Duties）

職務分離はIT全般統制における基本です。特に重要なのは「開発担当者が本番システムに直接変更を加えられる状態を排除すること」です。

小規模な情シス組織で完全な職務分離が難しい場合、補完的な統制（特権アクセスのログ監視・定期的な作業記録のレビューなど）で補うことが認められています。ただし、その場合でも監査法人との事前の合意が必要です。

変更履歴ドキュメントの作成と保管

変更管理の証拠として保管すべきドキュメントは以下の通りです。

• 変更要求書（承認者のサイン・電子承認記録を含む）
• テスト計画書とテスト結果報告書
• 本番移行手順書と実施記録
• ロールバック手順書
• 変更後の動作確認記録

これらは監査対象期間（通常1年間）のものを保管し、監査人の要求に速やかに対応できる状態を維持してください。

参考: 「内部統制報告制度（J-SOX）」改定における情報システム部門の関わり方（SBT）

J-SOX監査に備えるドキュメント整備

J-SOX対応では「実際に統制を実施しているのに、ドキュメントが整備されていないために不備と判定される」事態が少なくありません。実態以上にドキュメントを整備する必要はありませんが、実施した内容を確実に記録する習慣が重要です。

3点セット（業務記述書・フローチャート・RCM）の作成

J-SOX対応で必要な「3点セット」について整理します。

業務記述書（Narrative）:業務プロセスを文章で記述したドキュメントです。「誰が・何を・いつ・どのように」行うかを具体的に記載します。IT統制に関しては、システムの利用方法、アクセス管理の手順、ログの取得・保管方法などを記述します。

フローチャート:業務の流れを図示したドキュメントです。各ステップと判断ポイント、関連するシステムや帳票を視覚的に表現します。監査人が業務プロセスを理解するための重要な資料です。

リスク・コントロール・マトリクス（RCM）:業務プロセスに存在するリスクと対応するコントロールの対応関係を表形式で整理したドキュメントです。コントロールの種類（予防的/発見的）、手動/自動の区別、実施頻度、証拠書類の種類などを記載します。

監査人が特に確認するポイント

IT統制に関して監査人が重点的に確認するポイントです。

• アクセス権限の棚卸し：年1〜2回の実施と記録の有無
• 退職者アカウントの削除：退職後速やかに対応していることの証明
• 特権アカウントの管理：管理者権限の最小化と使用ログの保管
• 変更管理プロセスの遵守：全ての本番変更が承認を得ているか
• 職務分離の実現：開発担当者が本番環境にアクセスできない仕組み
• ログの取得・保管：必要なログが適切に保管されているか
• バックアップの実施：定期的なバックアップと復元テストの実施

指摘事項の典型例と対処法

指摘①: 退職者アカウントの残存

‍退職処理フローを見直し、人事部門と情シス部門の連携手順を整備します。HRシステムと連動したアカウント無効化の自動化を検討することも有効です。

指摘②: アクセス権棚卸しの実施記録なし

‍棚卸しの実施手順と記録様式を整備します。棚卸し結果に業務承認者のサインを得て保管する運用を確立してください。

指摘③: 変更管理プロセスの不遵守

‍変更管理ルールを明文化し、全担当者に周知します。緊急変更の場合も事後承認記録を確実に残す手順を整備します。

指摘④: 特権アカウントの管理不備

‍管理者権限を持つアカウントを棚卸しし、不要な管理者権限を削除します。特権アカウントの使用は必要時のみとし、使用ログを監視する仕組みを整えてください。

参考: J-SOX基準等改訂ポイントの解説（PwC Japan）

SaaS管理プラットフォームでSOX対応を効率化する

SaaSの数が増えるにつれ、手作業での管理は限界を迎えています。「棚卸しのたびに各サービスの管理画面を開いて確認する」という作業を毎年繰り返している情シス担当者も多いのではないでしょうか。SaaS管理プラットフォームを活用することで、対応の効率と精度を同時に向上させることができます。

手作業管理の限界とリスク

ExcelやスプレッドシートによるSaaSアカウント管理には、現実的な限界があります。

• 管理の漏れが発生しやすい: 数十〜数百のSaaSを手動で管理していると、退職者アカウントの削除漏れや権限変更の漏れが積み重なります。
• 棚卸し作業の工数が膨大: 年1〜2回の棚卸し作業に、各SaaSの管理画面を手動で確認する作業が発生し、担当者の大きな負担になります。
• 証拠書類の品質が属人化する: 担当者によって記録の方法や粒度が異なり、監査に耐えうる品質を維持できません。
• リアルタイムの状況把握が困難: Excelベースでは、現在のアカウント・権限状況をリアルタイムで把握することができません。

ジョーシスの活用でできること

ジョーシスは、SaaSの利用状況の可視化から、入退社時のアカウント管理自動化、デバイス管理まで一元管理できるAI駆動型SaaS管理プラットフォームです。J-SOX対応の文脈で特に役立つ機能を紹介します。

SaaS利用状況の一元可視化:社内で利用されているSaaS（シャドーITを含む）を自動検出し、契約情報・ユーザー数・利用状況を一つの画面で把握できます。対象システムの洗い出しが格段に容易になります。

SaaS可視化とは

アカウント情報の自動取得と管理:各SaaSのAPIと連携し、アカウント情報・権限情報を自動取得します。人事データとの照合で、在籍者と退職者のアカウント状況をリアルタイムで確認できます。

入退社時の自動プロビジョニング/デプロビジョニング:入社・退社情報をトリガーに、複数のSaaSに対するアカウントの作成・削除を自動実行します。退職者アカウントの残存リスクを大幅に低減し、J-SOX監査での指摘を防ぎます。

オフボーディング IT 自動化

棚卸しの自動化と証拠書類の生成:アクセス権限の棚卸しをシステムで自動実施し、結果をレポートとして出力します。監査人に提示する証拠書類の整備工数を大幅に削減できます。

操作ログの一元管理:各SaaSの操作ログを一元的に収集・管理します。監査時に必要なログを迅速に抽出できる環境を整備できます。

導入効果と運用改善のイメージ

ジョーシスを導入した企業では、以下のような変化が報告されています。

• 棚卸し作業時間の削減：従来数日かかっていた作業が数時間に短縮
• 退職者アカウント残存リスクの解消：自動デプロビジョニングにより即日対応が実現
• 監査対応工数の削減：証拠書類の自動生成により、監査準備の工数が大幅に減少
• シャドーITの発見：未申告のSaaS利用を自動検出し、アクセス管理の漏れを防止

J-SOX対応は「年に一度の監査のための作業」ではなく、「日常的なガバナンス活動の延長線上」にあります。ツールを活用して日常業務の中でIT統制を維持できる仕組みを構築することが、中長期的な対応コストの削減につながります。

SaaS管理とは

よくある質問と今後の対応ロードマップ

J-SOX対応を進める情シス担当者からよく寄せられる質問に回答します。年間スケジュールの考え方も合わせて整理します。

Q&A形式でFAQ解説

Q1. 上場していない会社でもJ-SOXに対応する必要がありますか？

J-SOXは上場企業（および上場準備中の企業）に義務づけられた制度です。非上場企業への直接適用はありません。ただし、上場親会社の子会社として連結対象になる場合や、SOC2認証の取得を目指す場合、大企業との取引でセキュリティ基準の証明を求められる場合には、実質的に準じた対応が必要になることがあります。

Q2. SaaSベンダーのIT統制はどのように評価すればよいですか？

2024年の改訂で、委託先（SaaSベンダーを含む）のIT統制評価がより重要視されるようになりました。実務的な対応としては、SaaSベンダーが発行するSOC報告書（SOC 1 Type II / SOC 2 Type II）を入手・確認することが一般的です。SOC報告書が入手できない場合は、ベンダーが公開しているセキュリティホワイトペーパーや契約上のセキュリティ条項の確認で補完します。

Q3. アクセス権の棚卸しはどれくらいの頻度で実施すべきですか？

年1回以上の実施が一般的に求められます。財務データを直接扱うシステムについては年2回以上を推奨する監査法人もあります。最終的な頻度は、会社のリスク評価と監査法人との合意に基づいて決定してください。

Q4. 小規模な情シス組織で職務分離を実現するにはどうすればよいですか？

完全な職務分離が難しい場合、「補完的統制」による対応が認められています。特権アクセスのログを定期的にレビューする（IT管理者以外の上位者が実施）、開発者の本番アクセスを承認制にして全記録を残す、外部顧問が変更内容をレビューするなどの方法があります。監査法人と事前に相談し、補完的統制の内容について合意を得ることが重要です。

Q5. ITの評価範囲はどのように決めればよいですか？

「財務報告に重要な影響を与えるシステム」を中心に特定します。ERP・会計システム・人事・給与システムが対象の中心です。SaaSについては、財務データを直接処理するもの（クラウド会計・給与計算SaaSなど）と、財務報告プロセスに間接的に影響するもの（人事管理・経費精算など）を評価対象として検討します。評価範囲の確定は監査法人との協議が必要です。

SOX対応の年間スケジュール例

4月1日を期首とする企業（3月31日決算）を例に、J-SOX対応の年間スケジュールをまとめます。

J-SOX対応は一度整備すれば終わりではありません。毎年、業務変更やシステムの追加・廃止に伴うドキュメントの更新と、運用状況の評価・記録の継続が求められます。早期に体制を整備し、日常業務の中で自然に統制が機能する状態を目指すことが、情シス部門の長期的な負担軽減につながります。

参考: J-SOXとは？IT統制で企業が気をつけるポイントを解説（EGG SYSTEM）

まとめ

J-SOX対応のIT管理において、情シス部門が取り組むべきことを整理します。

• IT全般統制の4カテゴリ（アクセス管理・変更管理・運用管理・開発管理）を体系的に整備する
• SaaS環境でのアクセス権限管理：アカウント棚卸しの定期実施、入退社時の迅速な対応、最小権限の原則の適用
• 監査ログの整備：取得すべきログの特定、適切な保管期間と改ざん防止措置、一元管理の仕組みの構築
• 変更管理プロセス：承認フローの整備、職務分離の実現、変更履歴の確実な記録
• ドキュメント整備：3点セットの作成と更新、監査証拠の適切な保管
• ツールの活用：SaaS管理プラットフォームによる自動化で管理工数を削減し、証拠書類の品質を向上させる

SaaSを多数活用する現代の企業環境において、J-SOX対応を手作業で維持し続けることには限界があります。ジョーシスのようなSaaS管理プラットフォームを活用することで、日常的な運用の中で継続的にIT統制を維持できる体制を構築することをお勧めします。

SaaS管理プラットフォームとは