J-SOX対応（金融商品取引法に基づく内部統制報告制度）において、IT全般統制（ITGC：IT General Controls）の評価は毎年実施が求められます。業務プロセスに関連するシステムを対象に、アクセス管理・変更管理・運用管理・委託先管理の4領域が主な評価対象です。
この記事では、実際のITGC評価の現場で繰り返し見られる指摘事項と、その現実的な改善アプローチを解説します。
1. アクセス管理：不要権限の残存
頻出指摘事項
退職・異動後も有効なアカウントが存在する
退職した従業員や異動後の担当者のアカウントが削除されずに残っているケースです。原因の多くは「ルールがない」ことではなく、退職・異動情報がIT部門に確実に届く経路が設計されていないことにあります。人事側が動いたことをITが知らないまま、規程に定めた対応期限だけが過ぎていくパターンが典型的です。
改善アプローチ
規程に対応期限を定めるだけでなく、情報が確実に届く通知経路を設計することが先決です。人事システムとの連携や、HR担当者からITへの定型メール・チケット起票など、退職・異動のイベント発生時に自動または半自動でIT側に伝わる仕組みが必要です。あわせて、依頼が完了したことを確認するフロー（チケットのクローズ、HR担当への完了連絡など）を設けることで、「依頼したが対応されていなかった」という見落としを防げます。定期的な権限棚卸しは、この仕組みが実際に機能しているかを検証する安全網として位置づけるのが現実的です。
頻出指摘事項
特権ID（管理者権限）の管理が不十分
システムの管理者権限が複数人で共有されていたり、利用記録が残っていないケースです。「誰がいつ何をしたか」が追跡できない状態は、内部不正リスクの観点からも問題ですが、レガシーシステムやベンダー提供のサービスアカウントなど、構造上すぐに共有IDを廃止できないケースも現実には多く存在します。
改善アプローチ
共有IDをすぐに廃止できない場合、まずは貸出管理を徹底することが現実的な第一歩です。「誰が・いつ・何の目的で使用したか」を記録する貸出管理台帳を整備し、使用後に操作ログと突き合わせてレビューする運用を設けることで、説明責任の担保に近づけます。その上で、廃止が可能なシステムから順次個人IDへ移行する計画を立てることが望ましい方向性です。共有IDの廃止と個人ID運用への移行は、統制の水準を高めるうえで最終的に目指すべきゴールです。
2. 変更管理：変更記録の欠如と承認プロセスの形骸化
頻出指摘事項
本番環境への変更が承認記録なく実施されている
「緊急対応だったので記録が取れなかった」「ベンダーに依頼したら直接本番を修正された」というケースが頻出します。変更管理手続きが整備されていても、緊急時や例外処理で抜け道になりやすい領域です。
改善アプローチ
変更管理手続きにおいて、緊急変更の場合でも「事後承認」の手順を明示的に定めることが重要です。専用のチケット管理ツールの導入がすぐに実現しない場合でも、当日の作業内容をメールで報告し翌営業日に承認を得るといった形でも、記録と承認の証跡を残すことはできます。まずは「記録する文化」を作ることが先決で、ツールはその後の話です。ベンダーによる本番作業については、立会い・作業報告書の受領など、第三者が関与した記録を残す運用を定めておくことが望まれます。
頻出指摘事項
開発・ステージング・本番の環境分離が不十分
開発者が本番環境に直接アクセスできる、本番データが開発環境にそのまま持ち込まれている、というケースです。J-SOX対応では環境分離（Segregation of Environments）がITGCの重要な評価項目ですが、事業会社の実務では本番と開発の中間的な位置づけの環境が存在することも多く、アクセスを一律に禁止すると業務に支障が生じる場合もあります。
改善アプローチ
開発者の本番アクセスを即時禁止することが理想ではありますが、現実的には現在の業務内容や役割を踏まえて「誰がどの環境にアクセスできるべきか」を棚卸しし、適切な職務分掌に近づけていくプロセスが現実的です。まず現状のアクセス権を可視化し、業務上の必要性がないアクセスを段階的に整理することから始める方法が、現場の混乱を最小化しながら統制を強化する上で有効です。本番データを開発環境に持ち込む場合は、マスキング処理の適用を要件として定めることも重要な統制の一つです。
3. 運用管理：バックアップとログの形骸化
頻出指摘事項
バックアップの取得確認が行われていない
「バックアップは自動で取得されている」と思い込んでいても、実際には設定エラーでバックアップが失敗していたというケースがあります。取得「設定」はあっても、取得「確認」の記録がないと評価上の問題になります。
改善アプローチ
バックアップの取得成否を定期的に確認し、記録を残す手順を整備する。加えて、年1回程度のリストアテスト（実際にバックアップからデータを復元できるか確認）の実施と記録を規程に組み込む。
頻出指摘事項
ログが取得されているが誰もレビューしていない
アクセスログや操作ログは設定されているものの、「取得するだけ」になっており定期的なレビューが行われていないケースです。ログの保持のみでは統制として不十分と評価されることがあります。
改善アプローチ
重要システムのログについては、定期的なレビュー（月次等）の担当者・手順・記録様式を整備する。異常検知の自動化（SIEM、クラウド監視サービス等）を活用することで、全量レビューを不要にしながら統制の有効性を高める方法も有効。
4. 委託先管理：SaaS・クラウドベンダーの評価漏れ
近年のJ-SOX対応で増えている指摘が、SaaS・クラウドサービスを業務システムとして利用しているにもかかわらず、委託先評価の対象として整理されていないケースです。「クラウドはベンダーが管理しているから」という誤解から、評価が省略されがちです。
評価のポイント：利用するSaaSのSOC 2 Type IIレポートや、ISO 27001認証の取得状況を確認し、委託先評価の記録として保持する。また、SOC 2レポートに記載された補完的ユーザー統制への自社対応状況を確認することも重要です。
ITGC評価に向けたセルフチェック
- 退職・異動発生時にIT部門へ確実に通知が届く経路（連携・チケット・メール等）が設計されているか
- アカウント削除依頼の完了確認フロー（チケットクローズ・HR担当への完了連絡等）があるか
- 特権IDを共有している場合、貸出管理台帳（誰が・いつ・何の目的で）を整備しているか
- 共有IDの操作ログを貸出記録と突き合わせてレビューする運用があるか
- 本番環境への変更は承認記録（緊急時は事後承認も含む）があるか
- 各環境へのアクセス権が業務上の必要性に基づいて整理・見直されているか
- バックアップの取得確認とリストアテストの記録があるか
- 重要システムのログを定期的にレビューしているか
- SaaS・クラウドベンダーを委託先として評価・記録しているか
- 利用するクラウドサービスのSOC 2レポートに記載された補完的ユーザー統制への自社対応を確認しているか
「整備はしているつもりだが、評価されると指摘が出る」という状況は、統制の設計ではなく運用の継続性・記録の問題であることが多いです。対外的な評価の前に、スポットでのレビューを活用することで、主要な論点を事前に把握することができます。