IT全般統制の変更管理｜GitHubのプルリクエストが監査証跡になる仕組み

この記事を読むと分かること

IT全般統制（ITGC）における「変更管理」の位置づけと、監査人がそこで何を確認しているか
GitHubのプルリクエストが監査証跡として機能する仕組み
監査に通るために設定すべきGitHubのブランチ保護・自己承認禁止・レビュアー固定
変更管理を形骸化させないための運用フローと、緊急対応時の記録の残し方

IT全般統制（ITGC）の変更管理カテゴリで、証跡として最もよく使われるツールがGitHubだ。

「GitHubを使っているから変更管理はできています」——そう言ったエンジニアに「プルリクエストを1件見せてください」と依頼をしたところ、申請者が自分でソースコードの変更をApproveしていた。それも全件であった。合わせてGitHubの設定を確認した所、ブランチ保護は設定されておらず、mainブランチに担当者が直接pushもできる状態だった。

「GitHubを使っている」と「IT全般統制の変更管理ができている」は、全然別の話である。GitHubを正しく設定・運用すれば、ITGCの監査で求められる変更管理の証跡はほぼ自動的に揃うが、きちんと運用されていなければ統制として意味がなくなってしまう。

そこで、本稿では、IT全般統制における変更管理について、GitHubのプルリクエストとの連携について解説を行う。

IT全般統制の変更管理を、監査人が見る理由

変更管理はIT全般統制（ITGC）の4カテゴリ（変更管理・運用管理・アクセス管理・外部委託管理）の一つで、監査で最も重点的に見られる領域だ。監査人が変更管理を見る理由は一つで、「誰でも好き勝手に本番のコードやデータを書き換えられる状態になっていないか」を確かめるためである。

会計システムや財務データに影響するプログラムが承認なしに変更できる状態は、数字の改ざんリスクに直結してしまう。そのため、IT全般統制の検証のために、プログラムの変更プロセスを適切に把握する必要がある。

ITGCの監査で見るポイントは4つに絞られる。

変更の要件（なぜ変えるのか）が記録されているか
承認者（申請者以外）がレビューして変更内容を承認しているか
本番環境への反映前にテストが行われているか
本番への反映が承認後に行われているか

GitHubのプルリクエストは、この4点をログとして記録するために使われる。

PRが監査証跡になる理由

一般的に、プルリクエストには以下の情報が記録される。

記録される情報	監査での意味
変更の内容（diff）	何を変えたか
PR作成者	誰が変更を申請したか
レビュアーの承認記録	誰が承認したか（タイムスタンプつき）
コメント履歴	レビューで何が議論されたか
マージした人・日時	いつ本番に反映されたか
紐付いたIssue/チケット	どの要件のための変更か

プルリクエストを用いた開発を行えば、自然と変更管理におけるドキュメント作成までカバーができる。しかし、その使い方を間違えると、証跡として不十分になることが多い。

監査に通るGitHub設定で行うべき重要なこと

ブランチ保護——最優先で入れる設定

mainブランチへの直接pushを許すと、承認なしの変更がそのまま本番に乗る。これを塞ぐのがブランチ保護だ。これを行うことで、変更されてはならないブランチがむやみやたらに変更されることを防ぐことができる。

良くあるのが、誰でもメインブランチにpushが出来る状況などである。これは少人数のスタートアップ等でよく見かける。

自己承認の禁止

PRを作成した本人が自分で承認できる状態も、良くあるエラーである。

GitHub上でソースコードの変更履歴を追うことが出来るようにするのは良いが、自己承認してしまうことで、悪意のあるコードが含まれてしまうリスクを排除しきれない。そのため、集団開発においては自己承認を行わないように設定で絞るのが良いだろう。

レビュアーを固定する

レビュアーを指定しないプルリクエストは、誰も見ないまま放置されやすい。そのため、.github/CODEOWNERS を置くことで、レビュアーの設定を義務化してあげれば、上長などにレビュー承認を指定してあげることができるだろう。

# .github/CODEOWNERS の例
# 財務計算に関わるコードのレビュアーを強制指定
/src/accounting/  @lead-engineer @cfo-reviewer

「設定していること」と「機能していること」は別物です

月次決算・IPO準備・IT統制の実務知見を、月1回メールでお届けします

無料でメルマガを受け取る

運用フローを回すための流れ

仮にGitHubで設定を行ったとしても、運用フローが定着していなければ、証跡は途中で切れてしまう。そのため、以下のような開発の運用フローを行うことが望ましい。

1. 変更要求の起票（Jira/Backlog等）
   ↓
2. 変更承認者による承認（優先度・影響度評価）
   ↓
3. featureブランチで開発
   ↓
4. PR作成・レビュアー指定
   ↓
5. コードレビュー（技術承認）
   ↓
6. CI/CDテストパス
   ↓
7. テスト/ステージング環境での動作確認
   ↓
8. 業務部門によるUAT・承認
   ↓
9. 本番移行承認（開発者と独立した承認者）
   ↓
10. mainへマージ＝本番デプロイ
   ↓
11. デプロイ後の動作確認・証跡保存

このフローが回っていれば、「誰がなぜ何を変えて、誰が承認したか」の記録はGitHubとチケット管理ツールに自動的に残る。

チケット管理ツールのIssue番号をプルリクエストのタイトルや説明に書くと（例：fix: 売上計上バグを修正 #1234）、要件から変更までの証跡が一本でつながる。監査人が「この変更の要件はどこに記録されているか」と聞いてきたとき、GitHubのプルリクエストからJiraのチケットに一本でたどれる。

緊急対応（ホットフィックス）の扱い

「本番で障害が起きたので緊急で直した」という状況は必ず発生する。このとき、プルリクエストのフローを守れないことがある。

その場合においても、修正フローや手続の記録を適切に残していくことが望ましいが、通常のフローよりも迅速性が求められることもある。

ホットフィックスの対応のための、エスカレーションフローを適切に整備することが望ましい。

IT全般統制における変更管理に起こりやすいミス

GitHubを使っているスタートアップの多くは、変更管理の形は整っている。問題が起きやすいのは以下の3パターンだ。

レビューが形骸化しているケース
プルリクエストは出しているが、レビュアーが内容を見ずに「LGTM」で承認している。設定上は問題なくても、実態は牽制が機能していない。監査でコメント履歴を確認されると、「これは本当にレビューしたのか」という話になる。
自分のプルリクエストを自分で承認しているケース
ブランチ保護で自己承認禁止を設定していないと、申請者が自分でマージできてしまう。人数が少ないスタートアップでよく見る。人数が少なくても、「プルリクエストを出した人と承認する人は別の人」というルールだけは崩さないこと。
デプロイ前のテスト等が不十分
デプロイ前のテストを適切に行わず、リリース直後にバグが発生してしまうケースも存在してしまう。テストを行うための体制が十分でないこともあるかもしれないが、形式的なチェックだけで防げることも多いので、可能な限りトライをするのが望ましい。

IT統制の構築・整備をご検討の方へ

「設定はしたが機能しているか自信がない」という段階からでもご相談いただけます。変更管理の設計から運用の定着まで伴走します。

無料相談・お問い合わせ

まとめ

GitHubのプルリクエストは、ブランチ保護・自己承認禁止・承認者1名以上という3つの設定と、Jira/Backlogとの連携運用があって初めて、IT全般統制（ITGC）の変更管理証跡として機能する。緊急対応も事後の記録さえ残せば問題にはならないが、現場で最も崩れやすいのはレビューの形骸化だ。「設定していること」と「機能していること」は別物である。

GitHubを使った変更管理の証跡整備や、IT全般統制（ITGC）の構築・見直しでお困りの方は、オントロジーへ気軽にご相談ください。