DevOpsとIT統制は両立できるか｜職務分離・テスト承認・アクセス権の再設計

執筆　公認会計士・税理士 鈴木佑也

※本記事は2026年10月7日時点の公表資料に基づきます。

「原理・原則」と「解釈・通念」を分けて考える

コンプライアンス対応を考えるときは、2つの層を分けて見ると整理しやすくなります。1つ目は「原理・原則」で、その領域で事業をする以上は守らなければならない社会のルールです。法律や規制のように強制力のあるもの、認証制度のように任意だが事実上求められるものがあります。上場会社の内部統制報告制度（いわゆるJ-SOX）はその代表例です。

2つ目は「解釈・通念」です。原理・原則をどう実現するかについて、業界のガイドライン、社内ルール、監査人の経験などが積み重なってできた、一般的・伝統的な理解を指します。監査で使われるチェックリストの多くはこの層に属します。解釈・通念に従えば原理・原則はおおむね守れますが、原理・原則を実現する方法が伝統的な解釈しかない、というわけではありません。

図1　守るべき目的（原理・原則）は1つでも、それを実現する解釈・手段は複数ありうる

財務報告に係る内部統制の実施基準（2023年4月改訂、2024年4月1日以後開始する事業年度から適用）は、ITの統制目標の1つとして情報の信頼性を挙げ、その中身を正当性・完全性・正確性として説明しています。また、IT全般統制の例として、システムの開発・保守の管理、運用・管理、アクセス管理などシステムの安全性の確保、外部委託契約の管理を挙げています。つまり、守るべき目的は「承認されていない変更や不正なアクセスで、会計上の記録がゆがまないこと」です。

図2　内部統制の実施基準が示すITの統制の目的を、DevOps環境の例に置き換えたもの

この目的に立ち返ると、「誰が承認したか」という形式よりも、「承認されていない変更が本番に入らない仕組みがあり、その証拠が残っているか」が本質だと分かります。IT全般統制の評価の範囲や進め方については、IT全般統制の評価｜範囲の決め方と過年度の評価結果の利用もあわせてご覧ください。

衝突しやすい2つの伝統的な解釈

DevOpsとぶつかりやすい伝統的な解釈の代表は2つあります。1つは「開発担当者と運用担当者を分ける」こと、もう1つは「設計書・ソースコード・テスト結果などを工程ごとに上長が承認する」ことです。DevOpsは開発と運用の壁を取り払い、自動化されたデプロイ、自動テスト、メンバー同士のこまめなレビューでスピードと品質を両立させる考え方なので、字面どおりに比べると正反対に見えます。

なぜこうした衝突が起きるのでしょうか。IT統制の伝統的な解釈の多くは、1990年代から2000年代にかけて形づくられました。当時のIT導入の主な目的は、大量の取引を誤りなく、効率よくさばくことでした。基幹システムは年に数回まとめて改修し、運用部門が本番環境を厳格に管理するのが当たり前で、統制の解釈もその実装を前提にしています。

図3　伝統的な解釈は大量処理を正確・効率的に行う時代の実装を前提に形づくられた

一方、クラウドを前提にしたデジタル事業では、市場の変化をすばやくつかみ、柔軟に作り変えることがITの目的になっています。目的が違えば開発と運用のやり方も変わり、その結果として古い実装を前提にした解釈と衝突しやすくなるのです。衝突しているのは原理・原則ではなく解釈の側だ、と理解しておくことが出発点になります。

図4　字義どおりに読むと、DevOpsの基本的な進め方と正面からぶつかる

ケース：買収後のIT監査で指摘を受けたプロダクト部門

ここからは架空の事例で考えます。A社は中小企業向けに請求書発行のSaaSを提供する会社で、25名ほどのプロダクトチームが企画・開発・運用までを一手に担っています。週1回のリリースを基本とし、CI/CDツール、構成管理ツール、バージョン管理ツールを使って本番環境へ自動で反映しています。次に何を作るかはプロダクトオーナー（担当役員）を含む全員で決め、作業の計画と実行は開発メンバーに任されています。設計書はすべての変更について作るわけではありません。

図5　週1回のリリースを基本とし、企画からリリースまでを1つのプロダクトチームが担う

A社は事業が伸びた結果、上場企業グループに買収されました。グループ入り後、親会社の内部監査部門がIT監査を行い、次の3点を指摘しました。指摘はいずれも、A社のスピード重視の進め方とは相いれないように見えるものでした。

指摘項目	伝統的な解釈による改善の方向
職務の分離	開発担当者と、本番のデータ修正・インフラ変更・リリースを行う運用担当者を分ける
テストと承認	開発計画、設計書・ソースコード・テスト結果、リリースのそれぞれに上長の承認を残す
アクセス権の最小化	本番環境の権限は作業直前に付与して作業後すぐに外し、特権IDの使用を監視し、定期的に棚卸しする

さらに監査部門からは、「ルールや手順はある程度存在するが、そのとおり運用されたことを示すログが記録・保全されていない」というコメントもありました。今後は親会社の監査だけでなく、外部監査や取引先の評価を受ける機会も増えます。ルールどおりに運用されていることを効率よく示すには、ログを残し、事業部門みずから逸脱を見つけて直せる状態にしておくことが近道です。

図6　ルールどおりに運用されたことを、後から誰でも確かめられる状態をつくる

A社のプロダクトチームは「大事な仕事に集中し、価値を届けるスピードを最大にする」ことを掲げています。そこで、指摘を伝統的な解釈どおりに受け入れるのではなく、原理・原則に立ち返って「何が起きると困るのか」を極端なリスクシナリオで具体化し、それを防ぐ・見つける統制を自分たちで設計することにしました。

職務分離をツールの権限と通知で実現する

A社のメンバーは全員が、ソースコードの変更、開発環境の利用、本番へのデプロイ、各種ツールの設定変更を単独で行える状態でした。本番環境に常時アクセスできる人はいませんが、原理・原則から見れば「誰でも1人でアプリケーションを変えられる」状態です。そこで次のようなシナリオを想定しました。チームの賞与が月次売上と連動しており、あるメンバーが賞与を増やそうと、料金計算の割引ロジックを少しだけ書き換える。その結果、顧客への請求額と売上が過大に計上される、というものです。

図7　動機と機会がそろうと、1人で本番のロジックを書き換えられてしまう

A社が講じた対策は4つです。第一に、構成管理ツールの設定で、変更した本人以外の承認がなければマージできないようにしました。第二に、CI/CDツールなど開発ツールの設定変更権限を開発リーダーだけに絞りました。第三に、ソースコードの変更、本番への反映、ツール設定の変更が社内チャットの監視チャンネルに自動で通知されるようにし、毎朝の打合せで2名以上が内容を確かめてコメントを残すことにしました。申請漏れなどの疑問があれば開発リーダーが確認します。第四に、そのチャットツールのログ編集や保存設定を変えられる管理権限を、プロダクトチームの外（情報システム部）に移しました。

図8　承認の必須化・設定変更権限の限定・通知・通知ツールの管理権限の分離を組み合わせる

こうしておけば、仮に開発リーダーが単独で承認設定を外そうとしても、その操作自体が通知され、別の人の目に触れます。通知の記録を書き換える権限はチームの外にあるため、発見の仕組みそのものを無効にすることもできません。開発と運用を同じ人が担っていても、「1人だけでは不正な変更を完結できない」状態を作れば、職務分離の目的は達成できるのです。

図9　疑義のある操作は開発リーダーが事後承認または是正し、確認の記録もログとして残す

システムの外側での手当ても有効です。賞与と売上の連動を見直して動機を減らす、経理部門が請求額の異常値を月次で確かめて牽制を効かせる、といった業務側の対策を組み合わせると、統制はより強くなります。開発に関わる不正の典型的な手口と兆候は、ソフトウェア開発の不正リスクと内部統制｜工数付替え・外注費・資産計上で詳しく解説しています。

テスト承認：上長でなく能力のある人の確実なレビュー

A社では、何を作るかの決定とリリースの判定にはプロダクトオーナーが関わっており、伝統的な「上長の承認」に当たる行為はすでにあります。一方、開発中の確認は、自動テストの結果を含めてメンバー同士が随時レビューしており、承認するのは上長とは限りません。開発中の承認まで上長に集めれば、スピードは確実に落ちます。そこで、ここでも極端なシナリオを考えました。

毎月のように新しいメンバーが加わり、慣れるまでは指導役が伴走する決まりでした。ところがある月、指導役が急に休職し、新メンバーは十分な支援がないまま開発とテストを進めました。会計システムへの連携部分は重要機能として毎回テストが自動実行されるはずでしたが、テスト対象の指定が漏れていて実質的に何も検証されておらず、請求データの誤りが本番に入ってしまいました。月次締めの前に気づいて切り戻せたものの、財務諸表に影響しかねない事案です。

図10　承認者が上長であっても、テストが空振りしていれば不具合は止まらない

この事例から分かるのは、承認者が上長かどうかは本質ではないということです。大切なのは、「意図した変更が入っていること」と「余計な変更が入っていないこと」を、レビューできる力のある人が必ず確かめることです。A社は、開発環境へのコード移行のたびに自動テストを必ず起動させ、テストスクリプト自体も構成管理の対象にしてレビューを経なければ変更できないようにしました。さらに、リリース判定の場で、テストとレビューが実際に行われたかと各ツールの設定が妥当かを確かめる手順を加えました。

図11　テストスクリプト自体も構成管理の対象にして、勝手な書き換えや指定漏れを防ぐ

これにより、プロダクトオーナーは開発中の個々の成果物を承認しなくても、リリース判定で「テストとレビューがきちんと行われたこと」を証跡で確かめられるようになります。アジャイル開発で資産計上の開始時点やバージョンアップの扱いをどう区切るかは、アジャイル開発のソフトウェア資産計上｜開始時点とバージョンアップの線引きで取り上げています。

図12　承認の権限を上長に集めるのではなく、判定の場でテストとレビューの実行を確かめる

本番アクセス：スクリプト付与・時限権限・日次の棚卸し

本番のデータ修正など、クラウド上の本番環境に直接触れる作業について、A社では「必要なときに必要な分だけ権限を付ける」方針が共有されていました。作業内容をチケットに起票し、申請者以外がレビューしたうえで作業者のIDに権限を付けます。方針そのものは原理・原則と合っていますが、実際には強い権限が付いたままのIDが長く残り、付与の手順もはっきり決まっていませんでした。

想定したシナリオは次のとおりです。退職が決まっていたメンバーが障害対応で本番データを修正し、退職日当日に追加の修正が必要だと思い込みました。まだ外されていなかった権限を使い、申請を通さずに修正したところ、実はその修正は不要で、元に戻す作業が発生しました。悪意がなくても、権限が残っていればルール外の変更は起こります。

A社は、権限を付ける方法をレビュー済みスクリプトの実行だけに限り、管理コンソールやコマンドラインからは付与できない設定にしました。付与する権限には必ず有効期限（時限）を設け、その長さと範囲がチケットの作業内容に見合うかをスクリプトのレビューで確かめます。本番へのスクリプト実行は職務分離と同じく監視チャンネルに通知し、2名以上が日次で確認します。

図13　権限の付与経路をレビュー済みスクリプトの実行に一本化し、時限を必ず設定する

平常時の権限については、クラウドの権限設定と、人事データ（協力会社の要員を含む）に紐づく社内のログインIDをツールで毎日突き合わせ、結果を監視チャンネルに流して2名以上が確認する運用にしました。退職者や異動者の権限が残っていれば翌日には見つかります。

図14　クラウドの権限一覧と人事データ（協力会社を含む）を毎日突き合わせ、差異をチャットに流す

A社の例では、導入前は作業後も強い権限が残ったIDが毎週10件以上ありましたが、導入から数週間でほぼゼロになりました。特権IDの確認手順はITの内部監査｜アクセス権限と特権IDの確認手順で解説しています。ブロックチェーンを使うサービスでも、周辺のシステムには同じ考え方の統制が必要になる点はNFT取引の税務と内部統制｜所得区分・源泉・消費税と仕組みの信頼性をご覧ください。

図15　時限付与と日次の棚卸しを導入した5週目以降、作業後も残る強い権限はほぼなくなった

プロダクトチーム・内部監査・経営者それぞれの姿勢

A社の取り組みは、原理・原則を守っただけでは終わりませんでした。コーディングの誤り、デプロイの誤り、レビュー漏れ、本番データの保護といった、プロダクトの品質そのものを高める仕組みにもなったのです。原理・原則に立ち返って本質を考えたからこその副産物といえます。ただし、作り直した解釈が本当に機能するかは、その後のリスク対応力と事業の成果でしか確かめられません。関係者それぞれが姿勢を持つことが大切です。

図16　第1線が統制を作って回し、第2線が方針と権限の分離を支え、第3線が原理原則から評価する

立場	取りたい姿勢	避けたいこと
プロダクトチーム	監査対応もバックログの1項目として正面から扱い、自分たちのやり方で統制を作る	指摘を後回しにし、場当たりの手作業で取り繕う
内部監査	原理原則とその背景を説明し、リスクに応じてチェックリストを更新する	統制の記述を画一的に当てはめ、形式だけを求める
経営者	統制への対応を信頼（トラスト）を得るための投資として方向づける	監査対応を単なる追加コストとして扱い、現場任せにする

プロダクトチームにとって、監査対応が発生しているのは事業が順調に伸びている証拠でもあります。内部監査人から原理・原則とその背景を学び、対応をバックログに載せて進めれば、品質を高め、取引先を増やす武器になります。内部監査人にとっては、統制の記述は画一的に当てはめるものではなく、内外の環境を踏まえてリスクベースで適用するものだ、という考え方が出発点です。新しいIT実装に合わせて評価のチェックリストを更新する手間は、かける価値があります。

図17　統制を作り直した後もリリース回数は落ちず、切り戻しは減っていった

経営者にとっては、ITの活用とコンプライアンスを両立させることが、取引先や投資家から「リスクが適切に管理されている」と信頼してもらうための重要なテーマです。監査や認証への対応が単なるコストで終わるか、信頼を得る投資になるかは、経営の方向づけ次第です。開発投資の管理の仕方はソフトウェア事業のKPI管理｜ポートフォリオ管理とゲートレビューの作り方もあわせてご覧ください。

図18　伝統的な実装を外すときは、何を守るのかから順にたどる

よくある質問

最初の一歩は、変更経路の棚卸しです

まず、財務報告に関わるシステムについて、ソースコード、ツール設定、本番の権限のそれぞれを「誰が、どの手段で変えられるか」を表にしてください。1人で完結できる経路が見つかれば、そこが統制を作り直す優先箇所です。

まとめ

DevOpsとIT統制が衝突して見えるのは、原理・原則ではなく、昔のIT実装を前提にした解釈の側です。職務分離は承認の必須化と通知・日次確認と権限の分離で、テスト承認は自動テストとレビューの確実な実行で、本番アクセスはスクリプトによる時限付与と日次の棚卸しで、それぞれ原理・原則を満たせます。ログを記録・保全して可監査性を高めれば、監査対応は品質と信頼を高める投資に変わります。

本記事の根拠

• 金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」の公表（2023年4月7日）
• 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準」「財務報告に係る内部統制の評価及び監査に関する実施基準」（2023年4月改訂）
• 金融庁 基準・実施基準（抄）新旧対照表（2023年4月7日）
• 金融商品取引法（e-Gov法令検索）

免責：本記事は一般的な情報提供を目的とし、個別案件に対する法務、会計、税務その他の専門的助言を構成するものではありません。実際の対応は、最新の法令・取引所規則・公表資料を確認し、必要に応じて専門家へご相談ください。