監査法人のIT監査担当者から、ITGCの評価に関するメールが届きました。「販売管理システムの当期のプログラム変更一覧をご提出ください。あわせて、その一覧が網羅的であることをどのように確かめたかもご説明ください」。情報システム部門は、変更管理のチケットシステムから当期に完了した変更を出力し、42件の一覧を送りました。
数日後、監査法人から追加の質問が届きます。本番サーバーのプログラムファイルの更新日時を確認したところ、一覧にない日付で更新されているファイルが3つあったというのです。調べてみると、いずれも障害対応の際に担当者が直接修正したもので、チケットは起票されていませんでした。変更そのものに悪意はなく、修正も正しかった。それでも、「承認を経ない変更が本番に入り得る」という事実は、統制の有効性の評価に影響します（本記事の事例はすべて架空のモデルケースです）。
変更管理は、IT全般統制（ITGC）の中でも、アプリケーションに組み込まれた自動統制の信頼性を支える土台です。そしてこの場面が示すように、監査の成否は「承認記録があるか」よりも前の、「すべての変更を把握できているか」で決まります。この記事では、変更管理の監査を、母集団の作り方から緊急変更、職務分掌、クラウド時代の論点まで順に解説します。
この記事の要点
- 変更管理の監査は、変更チケットではなく本番環境側の記録から母集団を作り、チケットと突合して網羅性を確かめることから始まります
- 個々の変更は、申請・承認・テスト・ユーザー受入・本番移行の各段階の証跡を1件ずつ辿れるかで評価します
- 緊急変更は手続を省略してよい変更ではなく、事後承認とレビューの期限が定められた「別ルート」として評価します
- 開発者が本番環境へ直接移行できないことが職務分掌の核心で、分離が難しい小規模組織では移行ログのレビューなどの発見的統制で補います
- SaaS のバージョンアップ、設定変更、CI/CD パイプラインも変更管理の対象として範囲に含めます
変更管理とは何か：なぜITGCの中核なのか
自動統制を支える「前提」
財務報告に係る内部統制の評価では、金融庁の実施基準が、ITに係る全般統制の例としてシステムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理を挙げています。変更管理は、このうち開発・保守に係る管理の中心にあたる領域です。
変更管理がなぜ重要なのかは、自動統制の評価方法を考えると分かります。システムに組み込まれた自動計算や入力チェックといったIT業務処理統制（ITAC）は、一度正しく動作することを確かめれば、プログラムが変更されない限り同じように動作し続けると考えられます。この「変更されない限り」という前提を支えるのが変更管理です。変更管理が有効であれば、自動統制は毎年少数の検証で済ませられる余地が生まれます。逆に変更管理が有効でないと、自動統制が期中に意図せず書き換えられた可能性を否定できず、評価の範囲や方法を見直す必要が生じます。ITACとITGCの関係はITACとITGCの違いで詳しく解説しています。
変更管理の対象になるもの
「変更」はプログラムの修正だけではありません。監査の範囲を決める際には、次の種類を区別して扱います。
| 変更の種類 | 例 | 監査上の留意点 |
|---|---|---|
| プログラム変更 | 計算ロジックの修正、画面や帳票の改修 | 変更管理の中心。財務に影響する機能を優先 |
| 設定・パラメータ変更 | 承認上限額、税率、勘定科目の自動仕訳ルール | チケットを経ずに画面から変更できることが多い |
| データベース構造の変更 | テーブルや項目の追加、ストアドプロシージャの修正 | DBA の権限で直接実施されやすい |
| インフラ・ミドルウェア | OS・DBのパッチ、バージョンアップ | 業務影響の評価とテストの範囲を確認 |
| SaaS のバージョンアップ | ベンダーによる機能追加・仕様変更 | ベンダー側の統制は SOC 報告書、自社側は影響評価 |
| データの直接修正 | 障害時に本番データを SQL で修正 | 変更管理と別の手続で管理されることが多い |
設定・パラメータ変更は特に見落とされがちです。承認上限額や自動仕訳のルールは財務報告に直接影響するにもかかわらず、業務部門の管理者が画面から変更でき、プログラム変更の手続の対象外になっていることがあります。
変更管理の標準プロセスを理解する
5つの段階
一般的な変更管理のプロセスは、変更の申請、変更の承認、開発とテスト、ユーザー受入テストと移行の承認、本番移行という段階を踏みます。国際規格のISO/IEC 27001:2022の附属書Aでも、情報処理設備や情報システムの変更を変更管理手順の対象とする管理策（8.32）と、開発・テスト・本番の環境を分離する管理策（8.31）が別々に置かれています。経済産業省の「システム管理基準」や、NIST SP 800-53の構成変更管理（CM-3）も、同じ考え方を示しています。
各段階で何を確かめるか
各段階の確認ポイントと証跡を整理すると次のとおりです。
| 段階 | 統制の目的 | 主な証跡 | 典型的な不備 |
|---|---|---|---|
| 申請 | 変更の必要性と内容を明確にする | 変更要求票、チケット | 変更内容が「不具合修正」のみで具体性がない |
| 承認 | 変更の妥当性を責任者が判断する | 承認記録（承認者・日時） | 承認日が本番移行日より後になっている |
| テスト | 変更が意図どおり動作し、他に影響しない | テスト計画・結果、エビデンス | テスト結果が「OK」の記載のみ |
| ユーザー受入 | 業務部門が結果を確認し受け入れる | UAT 結果、業務部門の承認 | 開発者が業務部門の代わりに承認 |
| 本番移行 | 承認された変更だけを本番に反映する | 移行記録、移行者、移行日時 | 開発者自身が移行している |
承認の日時が本番移行の日時より前であることは、形式的に見えて重要な確認点です。事後に承認欄を埋めた記録は、統制が機能したことを示しません。
監査手順1：母集団の網羅性を確かめる
チケットから始めてはいけない理由
冒頭の場面が示すとおり、変更管理の監査で最初に確かめるべきは、評価対象の変更一覧が本番環境で実際に起きた変更をすべて含んでいるかです。変更管理のチケット一覧だけを母集団にすると、手続を通った変更の中から抽出することになり、手続を通らなかった変更は最初から評価の外に置かれます。これでは、統制の最大のリスクである「未承認の変更」を検出できません。
そこで、本番環境側の記録から変更の事実を集めます。移行ツールやデプロイの実行ログ、本番サーバーのファイル更新日時、データベースのオブジェクト更新日時、ソースコード管理システムの本番ブランチへのマージ履歴、SaaS の管理画面の監査ログなどです。これらをチケットと突合し、チケットのない変更がないかを確かめます。
突合の記入例
突合の結果は、次のような様式で調書に記録します。数値は説明のための架空の例です。
| 項目 | 記入例 |
|---|---|
| 対象システム | 販売管理システム（本番環境） |
| 本番側の記録 | デプロイツール実行ログ 45件、DB オブジェクト更新 6件（2025年4月〜2026年3月） |
| チケット側の記録 | 完了チケット 42件 |
| 突合結果 | 一致 42件、チケットなし 3件（いずれもプログラムファイルの直接更新） |
| 原因 | 障害対応時に本番サーバーへ直接ログインできる ID が開発者に付与されていた |
| 結論 | 母集団の網羅性に例外あり。チケットなしの3件について内容と影響を確認し、発見事項として報告する |
チケットなしの変更が見つかった場合、個々の変更が正しかったかどうかと、統制の不備であるかどうかは分けて考えます。変更内容が正しくても、手続を経ない変更が可能だった事実は統制の不備です。
監査手順2：個々の変更を追跡する
サンプルの抽出
網羅性を確かめた母集団から、評価対象の変更を抽出します。変更の件数が少ない場合は全件を確認することもあります。抽出件数は統制の頻度や母集団の大きさによって決めるのが一般的で、考え方は内部監査のサンプル数はなぜ25件なのかで解説しています。財務報告に影響する機能の変更や、緊急変更を意図的に含めるなど、リスクに応じた抽出も有効です。
1件ずつ辿る手続
抽出した変更ごとに、申請から本番移行までの証跡を順に確認します。ポイントは、証跡の「存在」ではなく「整合」を見ることです。申請の内容とテストの対象が一致しているか、承認者が権限規程で定めた者か、承認日時が移行日時より前か、本番に移行されたプログラムがテストされたものと同じかを確認します。最後の点は、移行ツールがテスト環境で検証したモジュールをそのまま本番へ移す仕組みになっているかで判断できることが多いです。
自動統制への影響を確認する
抽出した変更が、J-SOX で評価している自動統制（自動計算、入力チェック、自動仕訳など）に関わる機能を変更したものであれば、変更後もその自動統制が意図どおり動作しているかを確かめる必要があります。変更管理が有効であっても、変更そのものによって統制の動作が変わっている可能性があるためです。実務では、変更の影響範囲を記載した設計書やテスト結果から自動統制への影響を判断し、影響がある場合は変更後の自動統制を改めて検証します。ITGC の評価チームと業務プロセスの評価チームが別々の場合は、影響のある変更の情報を共有する仕組みを作っておくと、評価の漏れを防げます。
本番データの直接修正
障害や誤入力への対応として、本番データベースを SQL などで直接修正することがあります。これはプログラムの変更ではありませんが、財務データを業務画面の入力チェックや承認を経ずに書き換える行為であり、リスクはむしろ高いといえます。多くの組織では変更管理とは別の「データ修正手続」で管理していますが、監査の際は同じ考え方で、修正の依頼・承認・実施・結果確認の記録があるか、修正を実施できる者が限定されているかを確かめます。データベースの操作ログから更新系の操作を抽出し、依頼記録と突合する手続が有効です。
監査手順3：緊急変更を評価する
緊急変更は「別ルート」
システム障害や重大な不具合への対応では、通常の承認やテストを待たずに本番を修正せざるを得ない場面があります。これを緊急変更と呼びます。緊急変更の存在自体は問題ではありません。問題になるのは、緊急変更の定義や手続がなく、「急ぎだったから」という理由で通常の手続が省略されることです。
評価すべきは、緊急変更として扱う条件が定義されているか、実施時に最低限の承認（電話やチャットでの口頭承認を含む）を得る手順があるか、実施後に定められた期限内に正式な申請と事後承認、事後テストが行われているかです。事後承認の期限は、翌営業日以内など組織ごとに規程で定めるのが一般的です。
緊急変更の比率を見る
緊急変更の件数が全体の変更に占める比率は、変更管理の健全性を示す指標になります。緊急変更が常態化していると、実質的に通常の手続が機能していない可能性があります。期間ごとの比率の推移や、同じ担当者・同じシステムに緊急変更が集中していないかを分析すると、手続の形骸化の兆候をつかめます。
監査手順4：職務分掌と本番アクセスを確かめる
開発と移行を分ける理由
変更管理の職務分掌の核心は、プログラムを開発した者が、自らそれを本番環境に移行できないようにすることです。開発者が本番に直接移行できると、承認されていない変更や、テストと異なる変更を本番に入れることが技術的に可能になります。不正の意図がなくても、誤りを発見する機会が失われます。
監査では、本番環境への移行権限を持つ者の一覧を入手し、開発担当者が含まれていないかを確認します。本番サーバーやデータベースへの直接ログイン権限、特に特権 ID の付与状況も確認対象です。この部分はアクセス管理と重なるため、アクセス管理の監査手順とあわせて計画すると効率的です。
小規模組織での代替策
情報システム部門が数名の組織では、開発者と移行者を完全に分けることが難しい場合があります。その場合は、発見的統制で補います。本番の移行ログやファイル更新履歴を定期的に出力し、開発に関与していない責任者がチケットと照合してレビューする、本番へのログインを申請制にして作業後に操作ログを確認する、といった方法です。監査では、代替策が実際に行われ、レビューの記録が残っているかを確かめます。
クラウド・SaaS・CI/CD 時代の論点
SaaS のバージョンアップ
SaaS では、プログラムの変更はベンダーが行います。ベンダー側の変更管理の有効性は、SOC 1 報告書などの受託業務に係る内部統制の保証報告書で確認するのが一般的です。その際、報告書が利用者側に求める補完的な統制（相補的なユーザーエンティティ統制）を自社が実施しているかも確認します。報告書の読み方はITGC とSOC 報告書の見方で詳しく解説しています。自社側では、ベンダーのリリース情報を確認し、財務報告に影響する変更がないかを評価し、必要に応じて検証する手続があるかを見ます。
設定変更の管理
SaaS やERPでは、承認フローや仕訳ルールなどの重要な設定を管理画面から変更できます。これらの設定変更も、申請・承認・変更後の確認という手続の対象にし、監査ログで変更の事実を確認できる状態にしておく必要があります。監査では、管理画面の監査ログから当期の設定変更を抽出し、申請記録と突合します。
CI/CD パイプライン
ソースコードの変更を自動でテストし本番に反映する CI/CD の環境では、人による移行作業がなくなる代わりに、パイプラインの設定そのものが統制になります。本番ブランチへのマージにレビューと承認を必須にする設定、承認者と作成者が同一人物にならない設定、自動テストの通過を移行の条件にする設定などです。監査では、これらの設定が有効になっていること、設定を変更できる者が限定されていること、設定の変更自体が記録されていることを確かめます。
変更管理監査チェックリスト
ここまでの内容をチェックリストにまとめます。自社の成熟度をおおまかに把握するには、ITGC 簡易診断の変更管理領域（5設問）も活用できます。
| No. | 確認項目 | 主な手続 |
|---|---|---|
| 1 | 変更管理規程に対象（プログラム・設定・DB・インフラ・SaaS）が定義されている | 規程の閲覧 |
| 2 | 本番環境側の記録とチケットを突合し、未承認の変更がない | 突合分析 |
| 3 | 承認者が権限規程に沿い、承認日時が移行日時より前である | サンプルで証跡確認 |
| 4 | テスト結果とユーザー受入テストの承認が記録されている | サンプルで証跡確認 |
| 5 | 緊急変更の定義・事後承認の期限があり、守られている | 緊急変更の全件確認 |
| 6 | 開発者が本番環境へ移行できない、または代替のレビューがある | 権限一覧と移行ログの確認 |
| 7 | 重要な設定変更が申請・承認の対象になっている | 監査ログと申請の突合 |
| 8 | SaaS のバージョンアップの影響評価と SOC 報告書の確認をしている | 評価記録、報告書の閲覧 |
| 9 | CI/CD の承認・テスト必須設定が有効で、設定変更が記録されている | 設定画面と変更履歴の確認 |
よくある失敗と対策
チケット一覧を母集団にする
最も多い失敗です。承認を経た変更だけを見ても、未承認の変更を検出することはできません。対策として、本番環境側の記録の取得方法を監査計画の段階で情報システム部門と確認し、突合の手続を監査プログラムに必ず組み込みます。
設定変更とデータ修正を範囲から外す
プログラム変更だけを範囲にすると、財務への影響が大きい設定変更や本番データの直接修正を見落とします。範囲を決める際に、変更の種類ごとにどの手続で管理されているかを一覧にし、どの手続にも属さない変更がないかを確認します。
証跡の存在だけを確認する
承認欄が埋まっていても、承認日が移行日より後であれば事前の統制は機能していません。テスト結果が「問題なし」の一行だけでは、何を確かめたのかが分かりません。存在ではなく内容と日時の整合を確認する手順を、調書の様式に組み込んでおくと漏れを防げます。
緊急変更を例外として評価から外す
緊急変更は件数が少ないため、サンプルから漏れやすい領域です。リスクが高いにもかかわらず評価されないという逆転が起きます。緊急変更は全件を確認する、少なくとも意図的に抽出するというルールにしておくのが有効です。
前年の結論をそのまま引き継ぐ
前年度に変更管理が有効と評価されていても、当年度に移行ツールの入れ替え、担当者の交代、クラウドへの移行などがあれば、統制の設計そのものが変わっている可能性があります。前年の調書を出発点にしつつ、期中の変更点をインタビューで確認し、整備状況を改めて評価してから運用状況のテストに進むことが大切です。
よくある質問
変更が1件もない年は、変更管理の評価は不要ですか？
変更がなかったことを確かめる手続が必要です。本番環境側の記録を確認し、実際に変更がなかったことを検証します。あわせて、変更が発生した場合に備えた手続が整備されているか、未承認の変更を防ぐアクセス制限が機能しているかも確認します。
パッケージソフトをカスタマイズせずに使っている場合も対象ですか？
プログラムを変更しない場合でも、バージョンアップやパッチ適用、設定変更は発生します。これらが財務報告に影響し得るかを評価し、必要な手続の対象に含めます。プログラム変更の手続が不要でも、設定変更の管理は重要です。
アジャイル開発では承認のタイミングはどう考えればよいですか？
アジャイル開発でも、本番に反映する前に、責任者が変更内容を確認し承認するという原則は変わりません。スプリント単位のリリース承認や、プルリクエストのレビュー承認をもって承認とするなど、開発手法に合わせて承認の形を定め、その記録が残るようにします。どの形を統制として認めるかは、自社と監査人との協議で確認しておくと安心です。
変更管理の不備が見つかったら、財務報告の重要な不備になりますか？
ITGC の不備が直ちに重要な不備になるわけではありません。不備が影響する自動統制や財務報告の範囲、代替的な統制や補完的な手続の有無を踏まえて評価します。最終的な評価は、自社の評価手続と監査人の判断によって決まります。
まとめ
変更管理の監査は、「すべての変更を把握できているか」という網羅性の確認から始まり、個々の変更の証跡の整合、緊急変更の事後統制、開発と本番移行の職務分掌へと進みます。チケットに記録された変更を見るだけでなく、本番環境で実際に起きた変更から出発することが、統制の実効性を確かめる近道です。
次の一歩として、主要な財務システム1つについて、本番環境の更新記録とチケットの一覧を突合してみてください。未承認の変更の有無と、本番へ直接アクセスできる者の範囲が見えてきます。自社の現状はITGC 簡易診断で確認でき、評価項目の一覧化にはIT全般統制（ITGC）監査チェックリストも役立ちます。開発プロジェクト全体の監査はシステム開発・導入プロジェクトの監査をご覧ください。
ITGC の評価体制や変更管理の監査手続についてのご相談は、お問い合わせからお寄せください。
参考資料
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査に関する実施基準」（2023年4月改訂） https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 経済産業省「システム管理基準」
- 日本公認会計士協会 監査基準報告書315「企業及び企業環境の理解を通じた重要な虚偽表示リスクの識別と評価」
- ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements（附属書A 8.31、8.32）
- NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations（CM-3 Configuration Change Control） https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
