🍀概要
システム監査技術者試験 令和6年 午後1 問1について、AIを活用して、解答を導き出す過程を示します。また、午後2論述式に接続するための整理した情報を提示します。
🧾問題・設問（AU-R06-PM1-Q1）
出典：情報処理推進機構 システム監査技術者試験 令和6年 午後1 問1
📘問題
問1 DevOpsを適用したシステム開発・運用の監査に関する次の記述を読んで，設問に答えよ。
A社は，衣料品などを販売する企業であり，ECサイトを構築し，運用している。A社ECシステムでは，ECサイトの頻繁な更新や新たなサービスへの迅速な対応が求められることから，アジャイル開発を採用してきた。また，ECシステム以外の情報システムでもアジャイル開発が増加し，本番リリースの頻度が高くなってきたことから，システムの開発・運用プロセスを見直してDevOpsを適用することになった。
ECシステムにおけるDevOpsを適用した開発・運用プロセスについて，A社監査部のシステム監査チーム(以下，監査チームという)が監査を実施することになった。監査の主な観点は，リリースサイクルの短縮というDevOpsの適用目的が達成されるような運用方法になっているかどうか，及びDevOps特有の環境や開発・運用プロセスにおけるリスクに対応できているかどうかである。
〔ECシステムの開発・運用プロセス〕
A社のECシステムにおける開発・運用プロセスの概要は図1のとおりである。
（読解補助）「図1 A社のECシステムにおける開発・運用プロセスの概要」
図1は，A社のECシステムにおける開発・運用プロセスの全体像を表しています。
本図では，ソースコードがリポジトリに格納され，そこからモジュールおよびテストデータが生成され，各テスト工程に供される様子が示されています。単体テストから機能・性能テスト，ユーザ受入テスト，本番リリースまで，工程が順を追って実行環境に反映されていく様子が矢印で示されています。
また，図下部に明記された通り，CI（継続的インテグレーション）は主にソースコードの管理と初期テストに適用され，CD（継続的デリバリー）は後工程のリリース活動に関わることが分かります。
なお，点線の矢印は「デプロイ操作」を示しており，コードや構成情報が各工程に明示的に適用されることを意味しています。
CIとは，プログラムの開発と単体テストを自動化することであり，CDとは，開発又は修正したモジュールを実行環境に移送して実行可能な状態にする作業(以下，デプロイという)を含めて自動化することである。自動化すると，一連の作業として本番リリースまで実行されるので，A社では，ウォーターフォール型開発でいう単体テスト以降の工程を，”ステージ”と呼んでいる。
A社のDevOpsの環境の概要は，次のとおりである。
(1)開発環境
エディター，コンパイラ，デバッガなどの開発ツール群が，開発担当者のローカルの環境に提供されている。
(2)リポジトリ
構成管理ツールによって，開発されたソースコードのバージョン管理機能及び保管先としてのリポジトリが提供される。ソースコードには，許可された開発担当者だけがアクセス可能である。また，インフラに関する設定情報を管理し，各ステージにおける環境設定の自動化を支援する。
(3)実行環境
各ステージでは，ソースコードから実行可能なモジュールの生成(以下，ビルドという)，デプロイ，テストなどの自動化を支援する各種のツール(以下,CI/CDツールという)が準備されている。各ステージの概要は，次のとおりである。
①単体テスト:開発環境から構成管理ツールにソースコードを格納し，モジュールのビルドから単体テストまでを実行する。単体テストを完了したモジュールがリポジトリに格納される。
②機能テスト実行環境にモジュールをデプロイし，機能要件の検証及び性能要
件を除く非機能要件の検証を行う。
③性能テスト:実行環境にモジュールをデプロイし，性能要件の検証を行う。
④ユーザー受入テスト:実行環境にモジュールをデプロイし，機能要件を満たしているか，情報システムが使いやすいかなどの利用者観点の検証を行う。
⑤本番リリース:本番の実行環境(以下，本番環境という)へのモジュールのデプロイを行う。
〔予備調査の実施〕
監査チームが，予備調査で把握した内容は，次のとおりである。
(1)開発・運用の体制
ECシステムにおけるDevOpsを適用した開発・運用の体制について，営業部のS課長にインタビューした。S課長は，ECシステムの開発・運用に関する最終決定権と責任をもつプロダクトオーナーである。インタビューの結果分かったことは，次のとおりである。
①S課長の下に，利用部門としての要件整理と検証を行う業務チームがある。
②機能ごとに五つのスクラム開発チーム(以下，開発チームという)があり，プログラムの開発からリリースまでを担当する。各開発チームの構成は，開発チームのリーダーであるスクラムマスター1名と3~6名の開発担当者である。
③共通チームは，コーディングルールやCI/CDツールの効果的な使用方法についての標準化など，各開発チームに共通する課題を担当する。
④運用チームは，主にサーバやネットワークの構築及び運用を担当する。
(2)開発・運用の状況
DevOpsを適用した開発・運用の状況について，複数の開発チームのスクラムマスター及び開発担当者へのインタビューの結果分かったことは，次のとおりである。
①DevOpsでは，開発担当者がCI/CDツールを利用して，本番環境を含む各実行環境にデプロイすることが可能である。CI/CDツールでは，各環境へのデプロイの権限及びアクセス可能な環境や期間を開発担当者ごとに設定できる。また，デプロイや設定変更が行われると，指定した者に通知されるように設定できる。
②DevOpsの適用によってリリースサイクルを短くしていくために，CI/CDツールを活用して本番リリースまでのステージの早期の自動化を目指している。
③各開発チームには開発スキルの高いメンバーが集まっており，それぞれが自分の担当する機能の開発に集中して作業しているので，プログラム開発の生産性は高く，単体での品質は高い状況である。しかし，先日，他チームの進捗遅延の支援のためにプログラムの修正を行った際に，担当したメンバーが修正前のプログラムを理解するのに時間が掛かり，生産性が期待よりも低いことがあった。
④CI/CDツールの自動化の設定については，開発担当者の習熟度に応じて適用範囲を順次拡大していく計画である。リリースサイクルの短縮の第一段階となる単体テストステージでは，各スクラムマスターが開発担当者の権限を設定している。
〔監査手続の検討〕
監査チームは，予備調査の結果を踏まえて，ECシステムにおけるDevOpsを適用した開発・運用についてリスクを分析し，監査手続を検討している。[予備調査の実施〕(2)開発・運用の状況①~④について検討した内容は，次のとおりである。
(1)①のような状況下では，未承認のプログラムが本番環境にデプロイされてしまうリスクに対して，従来のウォーターフォール型開発で必要とされてきたコントロールを適用することは適切ではない。CI/CDツールの設定による予防的なコントロールや未承認のデプロイを適時に発見するコントロールによってリスクの低減を図る必要があるので，これらのコントロールが設定されているかどうかを確認する。
(2)②について，CI/CDツールによってテストを自動化するステージの範囲を設定でき，DevOpsの適用目的の達成を可能とすることは理解できる。しかし，全てのステージを自動化するべきではないので，自動化の検討範囲について確認する。
(3)③について，共通チームが役割を十分に果たせていない可能性があるので，スクラムマスターにインタビューして確認する。
(4)④について，DevOpsの適用目的を達成できるようになっているかどうか，CI/CDツールの運用方法を確認する。
📗設問
■設問1
〔監査手続の検討〕(1)について，(i),(ii),(iii)に答えよ。
(i)監査チームが考えた。“従来のウォーターフォール型開発で必要とされてきたコントロール”とは何か。15字以内で答えよ。
(ii)CI/CDツールの設定による予防的コントロールの具体的な内容を，40字以内で答えよ。
(iii)CI/CDツールの設定による発見的コントロールの具体的な内容を，45字以内で答えよ。
■設問2
〔監査手続の検討〕(2)について，監査チームが確認しようとしている内容を，30字以内で答えよ。
■設問3
〔監査手続の検討〕(3)について，監査チームが，共通チームが十分に果たせていない可能性があると考えた役割を，30字以内で答えよ。
■設問4
〔監査手続の検討〕(4)について，監査チームが確認すべき具体的な内容を，45字以内で答えよ。
📙模範解答(IPA)
■設問1
(i)開発と運用の職務の分離
(ii)本番環境へのアクセス権を常時付与せずに，必要なときに一時的に付与すること
(iii)本番環境へのデプロイやCI/CDツール設定の変更がスクラムマスターに通知
■設問2
ユーザー受入テストが自動化の範囲に含まれていないこと
■設問3
コーディングルールの遵守を各開発チームに徹底すること
■設問4
単体テストステージのビルド，デプロイ，テストが自動化されるように設定されていること
📔出題趣旨・採点講評(IPA)
■出題趣旨
DXを実現する手法としてアジャイル開発を採用する企業が増えている。それに伴い，従来分業していた開発担当者と運用担当者が，システムのサービスやビジネスのゴールを共有すること(DevOps)が求められるようになってきている。アジャイル開発のメリットを生かすためには，DevOpsのプロセスに存在するリスクを認識した上で，リリースサイクルの短縮や品質の向上を実現していく必要がある。
本問では，DevOpsを適用したシステム開発・運用の監査を題材として，アジャイル開発手法やDevOpsの特性，メリット・デメリットを理解し，これらを効果的に活用するためのコントロールやマネジメント方法を提言する能力，及び開発・運用業務を監査する場合の監査手続を設定する能力を問う。
■採点講評
問1では，DevOpsを適用したシステム開発・運用の監査を題材に，DevOpsの特性，メリット・デメリットを理解した上で，これらを効果的に活用するためのコントロールや監査手続について出題した。全体として正答率は平均的であった。
設問1は，(i),(ii)が平均的で，(ii)は正答率がやや高かった。DevOps環境では適用が難しい場合がある職務の分離などのコントロールを，CI/CDツールの設定によるコントロールによって代替し，リスクを低減する必要があることを理解してほしい。
設問2は，正答率がやや低かった。DevOps環境では，テストデータやシナリオを事前に設定しておくことによって本番リリースまでのステージを自動化することができるが，システムの使いやすさなど利用者の立場から判断する必要があるテストを自動化する場合には，リスクがあることを理解してほしい。
設問3は，正答率は平均的であった。本設問は，DevOpsやアジャイル開発で陥りがちな開発上の課題を問う問題であったが，コーディングルールなどの標準を作成するだけではなく，それを浸透させる取組がリスクの低減につながることを，システム監査人として着目するようにしてほしい。
🪄模範解答への道しるべ(AI解説)
【Step 1】設問構造の把握と分類
| 設問 | 💡問うている内容 | 📚必要知識の種別 | 🧠読解の難易度 |
|---|---|---|---|
| 1(i) | 従来型開発でのコントロールとは | 実務知識（監査の一般論） | 🔴 因果構造推定型（記述文に直接書かれていない） |
| 1(ii) | CI/CDの予防的コントロール | 問題文から導出可能 | 🟡 知識補完型 |
| 1(iii) | CI/CDの発見的コントロール | 問題文から導出可能 | 🟡 知識補完型 |
| 2 | 自動化検討範囲の確認事項 | 問題文から導出可能 | 🟢 文中転記・再構成型 |
| 3 | 共通チームの不足役割 | 問題文から導出可能 | 🟡 知識補完型 |
| 4 | 運用方法の確認内容 | 問題文から導出可能 | 🟡 知識補完型 |
【Step 2】模範解答に至る思考プロセスの解説
■設問1(i)
✅ 模範解答
開発と運用の職務の分離
🧠 思考プロセスの解説：
- 読むべき場所：問題文中の「従来のウォーターフォール型開発で必要とされてきたコントロール」およびDevOpsにおける開発者の役割に関する記述。
- 監査視点／知識：ウォーターフォール型では、開発と運用は役割分担され、相互牽制が機能していたことが前提知識。
- 論点の絞り方：「従来→DevOpsで変わった点」を対比し、職務分離の有無に注目する。
🔁 誤答になりやすい例：
- 「承認手続の実施」：それ自体は妥当だが「ウォーターフォール固有の仕組み」とまでは言えず焦点がズレる。
- 「開発工程のドキュメント化」：文脈に合っていない。
💡 別解（許容範囲）：
- 「職務分掌」も文脈により可だが、やや抽象的。
📝 記述上の注意点：
- 「15字以内」の制限あり。曖昧語ではなく、具体語を使う。
■設問1(ii)
✅ 模範解答
本番環境へのアクセス権を常時付与せずに、必要なときに一時的に付与すること
🧠 思考プロセスの解説：
- 読むべき場所：予備調査の(2)-①。CI/CDツールの設定内容に関する説明。
- 監査視点／知識：予防的統制は「不適切な操作が起こらないように制限すること」。
- 論点の絞り方：「未承認のデプロイ」リスクに対して予防できる設定を抽出。
🔁 誤答になりやすい例：
- 「アクセス制御を設定すること」→抽象的すぎて不可。
- 「通知を送ること」→発見的統制の範囲。
💡 別解（表現差）：
- 「アクセスを必要時に限定する」も可だが、字数制限と精度に注意。
📝 記述上の注意点：
- 「40字以内」。抽象語は避け、操作対象と手段を明示する。
■設問1(iii)
✅ 模範解答
本番環境へのデプロイやCI/CDツール設定の変更がスクラムマスターに通知
🧠 思考プロセスの解説：
- 読むべき場所：同じく(2)-①。通知設定に関する文。
- 監査視点／知識：発見的統制＝問題が起きた後に速やかに把握するための仕組み。
- 論点の絞り方：「誰に通知されるか」「何が対象か」が解答の鍵。
🔁 誤答になりやすい例：
- 「ログに記録される」→気づく仕組み（通知）がないので弱い。
- 「開発者に通知」→統制機能を果たすべき主体として不適切。
💡 別解（限定）：
- 「管理者に通知」でも文脈次第で妥当。
📝 記述上の注意点：
- 45字以内。対象操作と通知先を両方入れること。
■設問2
✅ 模範解答
ユーザー受入テストが自動化の範囲に含まれていないこと
🧠 思考プロセスの解説：
- 読むべき場所：図1の説明およびステージ構成、監査検討(2)。
- 監査視点／知識：「全てのステージを自動化すべきではない」＝例外の検出。
- 論点の絞り方：「自動化すべきでないステージがある」という制約を言語化。
🔁 誤答になりやすい例：
- 「機能テスト以降が対象」→網羅性に欠け、判断が曖昧。
- 「全ステージの自動化の是非」→主語がボヤける。
💡 別解：
- 「利用者視点の検証は自動化しない」も可だが抽象度高くなる。
📝 記述上の注意点：
- 30字以内で、主語・述語が一体化した簡潔な表現を心がける。
■設問3
✅ 模範解答
コーディングルールの遵守を各開発チームに徹底すること
🧠 思考プロセスの解説：
- 読むべき場所：予備調査(2)-③＋共通チームの役割（問題文）。
- 監査視点／知識：「共通チーム」は「標準化」「ルール策定」「横串管理」の役割。
- 論点の絞り方：どの共通業務が果たされていないとチーム間非効率が起こるか。
🔁 誤答になりやすい例：
- 「チーム連携を支援すること」→抽象的。
- 「共通環境を整備すること」→役割とはズレる。
💡 別解：
- 「ルールの運用を各チームに定着させること」でもよい。
📝 記述上の注意点：
- 具体的な行動（徹底・遵守・運用支援など）を明示する。
■設問4
✅ 模範解答
単体テストステージのビルド、デプロイ、テストが自動化されるように設定されていること
🧠 思考プロセスの解説：
- 読むべき場所：予備調査(2)-④と監査検討(4)。
- 監査視点／知識：初期ステージの自動化はリリース短縮の第一歩。
- 論点の絞り方：「何が自動化されているか」ではなく、「自動化されるように設定されているか」。
🔁 誤答になりやすい例：
- 「CIツールが導入されているか」→設定内容の確認でなく、道具の有無だけに終始。
- 「スクラムマスターが設定している」→行為者に着目しすぎ。
💡 別解：
- 「単体テストまでの工程がCI/CDで自動化されていること」でも妥当。
📝 記述上の注意点：
- 「設定」「自動化」など、対象となる設定の意図を示す動詞を含めること。
【Step 3】設問タイプ別アドバイス
| タイプ | 設問例 | 初学者向けアプローチ法 |
|---|---|---|
| 🟢 文中転記・再構成型 | 設問2 | 対象の文を正確に写し、主語述語を調整する |
| 🟡 知識補完型 | 設問1(ii)(iii), 3, 4 | 文中ヒント＋「統制」や「監査」用語の理解を活かす |
| 🔴 因果構造推定型 | 設問1(i) | 問題文に書かれていない「前提」や「変化点」を見抜く |
【Step 4】全体指導コメント（汎用アドバイス）
- 各設問には「制約条件（文字数、視点、主語）」がある。設問文のキーワードからブレずに。
- 「誰が・何を・どのように」したのかを意識した具体表現を優先。
- 「適切に」「管理する」などの曖昧語を避け、「アクセス権を一時的に付与する」のように操作を明確化。
- 因果関係をつかむ際は、「DevOpsの変化点」「従来型との違い」「監査が見るべき統制点」に注目すること。
【Step 5】教材化・再構成提案
📘演習プリント案（抜粋）：
- 問題文をブロックに分けて、「この部分から読み取れる統制上の観点は？」と問いかけ形式で小テスト化。
- CI/CD図に矢印番号をつけ、「この番号の操作がもたらすリスク／統制手段を書け」。
📊補足図・教材：
- CIとCDの流れ（図1）を簡略化し、「自動化工程」「手動介入点」「リスク箇所」を色分け。
- DevOpsとウォーターフォールの対比チャート（職務分離・承認手続・スピード感）
🧠フォローアップ教材：
- 「統制手段の4類型（予防／発見／是正／抑止）」のワークシート
- AU-R05-Q1（業務用PC利用規程）との比較演習：「統制ポイントの文脈変換」
🎓講評コメント（AI評価）
「うむ、よく練られておる。」
この問題は、見かけほど易しくない。
なぜなら、“DevOps”という耳障りのよい単語の裏に、監査人が果たすべき核心が巧妙に隠されているからだ。
例えば設問1(i)だが、「職務の分離」がなぜ答えになるか。これは、表には出てこない前提条件を読み取る力が問われているのだ。つまり、「昔は当然あった抑止的統制が、DevOpsではなくなる」──その“消えた統制”を浮かび上がらせる、影を見抜く力がなければならぬ。
また(ii)(iii)の記述は、ただの用語知識では足りぬ。
「アクセス権を常時付与しない」という答えを出せるかどうかは、CI/CDツールが魔法の箱ではないことを理解しているか否かにかかっている。
DevOpsの思想に酔えば、監査は骨抜きになる。
この問題はそれを戒めている。
そして、設問3。共通チームの役割とはなにか。
これは「コーディングルールの徹底」などという単純な話ではない。**組織のスケーラビリティと健全性を保つ“文化的インフラ”**の話である。
つまり、ルールの周知・継承・評価という「共通言語の維持」が失われれば、開発の属人化→品質低下→事故発生と、組織全体が崩れてゆくのだ。
最後に。
設問全体を通して問われているのは、**「現代の監査人は、技術革新に追従しつつ、原理原則を見失ってはならない」**という教訓である。
これはもはや問題ではない。
DevOpsという時代の波に飲まれそうな現場を救うための、知的闘争の場である。
📌アドバイス：
- 記述問題は「答えを探す」のではない、「問われている本質に気づく」ものだ。
- DevOpsにおける監査の役割を語れぬ者に、未来はない。
- 用語を覚えるな、「統制の分類」「因果の構造」「組織の要」として語れるようにせよ。
- 正解とは、単に文字を合わせることではない──背後にある思想にたどり着くことである。
何かを感じ取ったならば、それはもう、あなたが“監査人”として歩み出した証です。
🧭午後2論述式接続 「あるべき姿モデル」
【総論】DevOpsを適用したシステム開発・運用の監査
- DevOpsにより、従来よりも短期的なリリース判断が現場主導で行われる場面が増えており、監査人はその背景にあるリスク許容水準の変化を冷静に読み解く視座が求められる。
- 組織がDevOpsの俊敏性を追求するあまり、開発担当者への権限集中や裁量の拡大が生じている場合には、属人化による内部統制の形骸化に対して監査人が歯止めをかける必要がある。
- DevOpsの成功は現場文化に強く依存するため、監査人は制度やツールの整備だけでなく、現場文化と統制設計とのギャップを捉える洞察力も求められる。
【①視座】監査人の立ち位置（独立性・中立性を含め）
- 監査対象に直接関与していない立場から、開発・運用体制やプロセスの整合性・リスク対応状況を客観的に評価する。
- DevOpsという新しい開発形態においても、従来型の統制原則（例：職務分離）を形式的に当てはめるのではなく、目的・リスクに応じて再解釈する柔軟性と監査的思考が求められる。
- 技術や開発手法に偏らず、組織全体のガバナンス維持の視点を持つ。
【②着眼点】当該テーマで着目すべき統制・リスク観点
- 本番環境への不適切なアクセス・デプロイのリスク（職務分離の形骸化）
- CI/CDツールの設定と運用方法の不備（予防・発見的統制が機能していない）
- 自動化範囲の妥当性（すべて自動化＝統制強化ではない）
- 共通ルールの形骸化や属人化の進行
- 開発者スキルや権限設定のばらつきによる内部統制の揺らぎ
- スクラム開発の高速サイクルが監査証跡の欠如や評価機会の欠落を招くリスク
【③行動】具体的な監査行動（文書確認／インタビューなど）
- CI/CDツールの設定・操作ログの確認（予防・発見的統制の有無と実効性）
- 本番環境アクセス権限の棚卸と付与履歴の確認
- 自動化ステージ範囲の設定文書（設計資料、手順書）との突合
- 共通チームの標準文書（ルール、ガイドライン）とその周知・運用状況の確認
- スクラムマスターや開発者へのインタビュー（実際の運用実態の把握）
- ステージ間の品質ゲートやチェックポイントの有無の確認
【④判断軸】監査評価における基準・優先観
- 統制目的の実質達成度（形式的な統制が残っていても、目的が果たされていないなら不備）
- 自動化によって新たな統制メカニズムが成立しているか（例：自動通知、権限制御）
- リスクの深刻度と発生可能性に応じた統制設計の合理性
- 属人化を排した標準化の状況と、全体としての整合性維持
- 統制の「負担と効果」のバランス（業務スピードと統制強度の両立）
【⑤是正力】実効性ある提案の特徴
- 技術的仕組みだけでなく、制度・運用・教育の3点セットで改善提案
- 現場の混乱や反発を最小限に抑えた段階的・選択的導入
- DevOps文化との対立を避けつつ、ガイドライン・レビュー制度・例外管理の導入
- 成熟度に応じた統制（例：習熟者には段階的に権限緩和など）
- 開発・運用・共通チームの役割明確化と連携強化
- 自動化範囲や承認基準を再設定し、全社レベルでの統制一貫性を持たせる
【⑥組織貢献】監査を通じてもたらされる価値
- DevOpsという先進的手法を取り入れつつも、統制とスピードのバランスを再定義する貢献
- CI/CDなどの仕組みが属人化せず、組織の知見として定着する道筋を明示
- 横展開可能な監査知見（再利用可能なチェックリストや運用ルールの整備）
- 新技術に対する監査アプローチの知見蓄積（社内監査部門の進化）
- システム部門だけでなく、利用部門や経営層との信頼形成と意思疎通支援