【AU-R06-PM1-Q3】ITサービス管理システムの監査

🍀概要

　システム監査技術者試験 令和6年 午後1 問3について、AIを活用して、解答を導き出す過程を示します。また、午後2論述式に接続するための整理した情報を提示します。

🧾問題・設問（AU-R06-PM1-Q3）

　出典：情報処理推進機構 システム監査技術者試験 令和6年 午後1 問3

📘問題

問3　ITサービス管理システムの監査に関する次の記述を読んで，設問に答えよ。
　P社の情報システム子会社のQ社は，P社のグループ各社(以下，各社という)にITサービスを提供している。提供するITサービスの種類と規模が拡大してきたので，より効率的かつ迅速に提供することを目的として，ITサービス管理システム(以下,新システムという)を新規に導入する予定である。P社の内部監査室はP社グループ全体を監査する役割を担っているので，新システムの目的が実現できるように検討されていることを確かめるために，社に対するシステム監査を実施することとした。

〔現在のITサービスと申請方法の概要〕
　現在，Q社が提供しているITサービスと申請方法の概要は次のとおりである。
(1)ITサービスの内容と申請方法
　ITサービスには，PC，サーバ，電子メールや事務処理のソフトウェアなどを利用するための定型サービスと，業務で利用する情報システムの開発などのSIサービスの2種類がある。Q社は，P社グループ内での情報共有のための掲示板システムに，ITサービスの仕様などを記載したサービスカタログと申請方法を掲載している。各社のIT部門は，次の(2)と(3)に述べる手順で利用部門からの申請を取りまとめて申請一覧表を作成し，電子メールに添付してQ社へ送付している。
(2)定型サービスの申請
　Q社では定型サービスの種類ごとに定型サービスチームが設置され，仕様と利用料単価がサービスカタログに記載されている。各サービスの仕様と利用料単価は原則として半年ごとに改定されるが，例外的に半年の間に改定される場合もある。
　サービス提供を希望する利用者は，上長の承認を得た上で各社のIT部門へ申請する。人事異動などに伴い多くの申請が必要な場合には，職場ごとに担当者が取りまとめて申請一覧表を作成し，上長の承認を得た上でIT部門へ申請する。
(3)SIサービスの申請と見積り
　SIサービスは，Q社のSIサービスチームが提供している。各社の利用者はSIサービスの依頼内容を検討し，上長の承認を得た上でIT部門へ申請する。
　SIサービスチームの担当者は，各社のIT部門から届いた申請について，必要に応じて個別にヒアリングした上で費用を利用料として見積もる。その結果は，リーダーが承認した上で，要員などの必要リソースが一定規模を超える場合はSIサービスチームの部長が承認した後，申請元のIT部門経由で利用部門へ通知する。見積りに対する利用部門からの回答が届いた後，正式な申請として受け付ける。
(4)ITサービス利用料管理
　ITサービス利用料は，毎月15日締切りでQ社から各社のIT部門へ請求する。決算期の最終月には16日から月末までの金額を算出して会計処理を行う必要があり，Q社と各社の両方で手間が掛かっている。

〔新システムの概要〕
　内部監査室の監査チームは，予備調査として，社内で検討中の新システムの導入企画書案を入手して閲覧するとともに，導入検討プロジェクトのリーダーを務めているQ社の技術管理部長にヒアリングした。その概要は次のとおりである。
(1)新システムの概要
　各社の管理業務を削減するとともに，利用者のニーズに迅速に対応する狙いから，新システムでは利用者が自身で社へ申請する。新システムはクラウドサービスを利用して構築する予定で，その概要は図1のとおりである。
(2)定型サービスの申請
　利用者はサービスカタログの内容を確認した上でサービス申請の画面に入力し，利用者の上長が申請を承認した後，関係する定型サービスチームへ通知される。

　定型サービスチームの担当者が受付した後に定型サービスチームのリーダーが承認する。多くの申請を効率的に処理するために，定型サービスチームのリーダーが申請を一覧画面で承認できる機能を提供する予定となっている。
　主要な定型サービスにおける申請の受付から提供までのリードタイムは，現在よりも短縮する予定であり，導入企画書案にリードタイムの目標が記載されている。
(3)SIサービスの申請と見積り
　新システムでは，SIサービスの申請に対して，SIサービスチームの担当者が画面から見積りを入力し，リーダーが承認する。
(4)ITサービス利用料管理
　新システムには，サービスコードをキーとして定型サービスの仕様や利用料単価などを管理する定型サービスマスターがあり，半年ごとに技術管理部が取りまとめて更新する。例外的に半年の間に改定があった場合は，各サービスを担当している定型サービスチームが更新する。
　毎月末には，サービス申請のデータに基づき，サービスコードが一致する定型サービスマスターの利用料単価を使用して各社へのサービス請求明細が作成される。サービスコードが一致しなかったサービス申請はエラーとなりリストが出力される。
　決算期の最終月の会計処理を効率よく行うために，経理部とITサービス利用料の締切日の変更を協議している。新システム導入の機会に，毎月末時点で当月分を各社へ請求して，当月中のITサービス提供の開始や終了による差額は翌月に精算する方法に変更することを検討している。新システム導入と同時に締切日を変更するので，開発とテストの作業量が多く，かなり厳しい日程となっている。

〔本調査のための検討〕
　予備調査の結果を基に，監査チームのリーダーであるT氏は，内部監査室長と本調査のための検討を行った。その内容の抜粋は次のとおりである。

室長:現在は定型サービスで多数の申請がある場合，利用者の上長は一覧表で承認できますが，新システムは申請ごとの承認なので上長は手間が掛かりそうですね。
T氏:定型サービスチームのリーダーに提供予定の機能を活用すれば対応が可能ではないかと思われるので，技術管理部にヒアリングして【a】を確認します。
室長:SIサービスの見積りについて必要な承認が行われるためのコントロールが，新システムで実装されることはどのように確認しますか。
T氏:新システムに，【b】機能があるかどうかを確認します。
室長:定型サービスの仕様や利用料単価が半年の間に改定される場合は，定型サービスマスターが適切に更新されない可能性がありますね。
T氏:各定型サービスチームの担当者のために，【c】を定めるといったコントロールが必要と思われます。
室長:サービスコードが一致しなかった場合のエラーが適切に処理されなければ，【d】というリスクがありますね。
T氏:エラーに対処する部署や処理方法が明確になっているかどうかを確認します。
室長:今回の新システムは，多くの利用者に直接影響を与えることから，移行時のリスクは極力回避する必要がありますね。
T氏:監査手続としては【e】によって，新システム導入後に運用が定着してから締切日を変更することを検討したかどうかを確認します。
室長:主要な定型サービスのリードタイムは，現在よりも短縮する目標を掲げていますが，定型サービスの利用者にも明確にしておく必要がありますね。
T氏:定型サービスを申請する際に閲覧できれば，利用者にも目標が明確になると考えられるので，【f】を確認することにします。

📗設問

■設問1
T氏が確認すべきと考えた事項として，本文中の【a】に入れる適切な内容を，45字以内で答えよ。
■設問2
T氏がコントロールとして実装すべきと考えた機能として，本文中の【b】に入れる適切な内容を，45字以内で答えよ。
■設問3
T氏が必要と考えたコントロールとして，本文中の【c】に入れる適切な内容を，25字以内で答えよ。
■設問4
室長が懸念したリスクとして，本文中の【d】に入れる適切な内容を，25字以内で答えよ。
■設問5
T氏が確認するために行った監査手続として，本文中の【e】に入れる適切な内容を，35字以内で答えよ。
■設問6
T氏が確認すべきと考えた事項として，本文中の【f】に入れる適切な内容を，45字以内で答えよ。

📙模範解答(IPA)

■設問1
【a】申請を一覧画面で承認できる機能について，利用者の上長への提供を検討していること
■設問2
【b】必要リソースが一定規模を超える見積りの回答はSIサービスチームの部長に回付される
■設問3
【c】定型サービスの仕様や利用料単価を改定する手順
■設問4
【d】ITサービス利用料の請求に漏れが生じる
■設問5
【e】締切日の変更についての経理部との協議の議事録を閲覧すること
■設問6
【f】定型サービスのサービスカタログにリードタイムの目標が明記される予定になっていること

📔出題趣旨・採点講評(IPA)

■出題趣旨
　企業におけるIT活用が高度化するにつれて，利用するITサービスの種類や規模は拡大している。ITサービスを提供する仕組みをできるだけ企業グループ全体で一元化して，効率良く，かつ，迅速に提供することが，事業を展開する上でも重要になっている。それを可能にするためのITサービス管理システムを整備する際には，当該システムに固有のリスクを踏まえて，対応するコントロールを整備・運用する必要がある。
　本問では，IT部門が企業内へ提供するITサービス管理システムの監査を題材として，企業グループとしての業務管理に係るリスクとコントロールを踏まえて監査を実施する能力を問う。
■採点講評
　問3では，ITサービス管理システムの監査を題材に，システムの導入と運用に関するリスク，監査の観点及び監査手続について出題した。全体として正答率は平均的であった。
　設問3は，正答率が平均的であった。マスター更新に伴うリスクへの対処を基本知識として学んでおくとともに，マスター更新の背景となっている業務リスクへの対処も視野に入れてコントロールを捉えてほしい。
　設問4は，正答率がやや低かった。エラーが処理されなければ，その分のサービス請求明細が作成されず，利用料の請求に漏れが生じるという，業務上の原因と影響を把握して，簡潔に表現できるように努めてほしい。
　設問5は，正答率がやや低かった。リスクへの対処を確認する監査手続では，どのような主題について，どのような監査技法を選択，適用し，どのような監査証拠によって確認するかを示す必要があることを理解してほしい。
　設問6は，正答率が平均的であった。リードタイムの目標が利用者にも明確になっているという状態を達成する前提として，サービスカタログの内容確認から，サービス申請の画面入力といった業務の流れを理解してほしい。

🪄模範解答への道しるべ(AI解説)

【Step 1】設問構造の把握と分類

設問	💡問うている内容	📚必要知識の種別	🧠読解の難易度
設問1	ユーザ上長が一覧画面で承認できる仕組みの確認	問題文から導出可能	中：機能の提供先と実装内容の整合性を見抜く
設問2	見積りの承認コントロールの確認内容	問題文から導出可能	中：回答・承認・回付の関係整理が必要
設問3	マスターの更新手順という統制手段	一般的な監査知識が必要	高：不備原因の想定と統制手段の結びつけが必要
設問4	サービスコード不一致時のリスク内容	問題文から導出可能	高：因果構造を推定して請求漏れと結論づける思考が必要
設問5	締切日変更の監査手続の内容	一般的な監査手続の知識が必要	高：監査証拠の選定が求められる
設問6	リードタイム目標の周知手段の確認	問題文から導出可能	中：ユーザが閲覧する内容として合理的な情報の把握

---

【Step 2】模範解答に至る思考プロセスの解説

■設問1（【a】）

✅ 模範解答：
「申請を一覧画面で承認できる機能について，利用者の上長への提供を検討していること」

🧠 思考プロセス：

• 🔍 ヒント：監査チームが「定型サービスチームリーダーに提供される予定の機能」を転用できるかどうかを検討。
• 🛠 対象機能がすでに開発予定にあるか確認 → 利用者側にも提供検討しているかが論点。
• 🔁 誤答例：「承認機能の整備」など機能の種類しか触れず、提供先を無視するとNG。
• 💡 別解：「一覧承認機能の上長向け提供の検討状況」などでも意味は通じる。
• 📝 記述注意：「誰に提供される予定か」が重要。

---

■設問2（【b】）

✅ 模範解答：
「必要リソースが一定規模を超える見積りの回答はSIサービスチームの部長に回付される」

🧠 思考プロセス：

• 🔍 ヒント：従来の承認ルートは「担当者 → リーダー → 部長」。
• 🔄 回付先と基準があるかが「コントロール」である。
• 🔁 誤答例：「承認機能の整備」など具体性のない表現は不正確。
• 💡 別解：「一定規模超過時の部長回付機能の有無」でも近いが、模範の方がより厳密。
• 📝 記述注意：文中の語彙を活かして構成。

---

■設問3（【c】）

✅ 模範解答：
「定型サービスの仕様や利用料単価を改定する手順」

🧠 思考プロセス：

• 🔍 ヒント：半年更新が前提、例外時は定型サービスチームが直接更新。
• ⚠ 属人的更新によるミスの予防には「定められた手順」が不可欠。
• 🔁 誤答例：「更新時の注意喚起」などでは統制にならない。
• 💡 他の表現：「例外改定時の更新承認ルール」もOK。
• 📝 記述注意：短文（25字）なので、簡潔かつ統制の体裁を崩さない。

---

■設問4（【d】）

✅ 模範解答：
「ITサービス利用料の請求に漏れが生じる」

🧠 思考プロセス：

• 🔍 ヒント：コード不一致 → エラー → リスト出力 → 未処理の場合は請求されない。
• ⚠ 「請求エラー」ではなく「請求されない」という結果がリスク。
• 🔁 誤答例：「サービス提供が遅れる」などはずれ。
• 💡 他の表現：「サービス利用料の一部が未請求になる」でも良い。
• 📝 記述注意：影響まで踏み込んで表現する。

---

■設問5（【e】）

✅ 模範解答：
「締切日の変更についての経理部との協議の議事録を閲覧すること」

🧠 思考プロセス：

• 🔍 ヒント：「検討したかどうか」を確認 → 検討記録の典型例が議事録。
• 🛠 文書監査の一種。議事録という具体的証拠に言及するのが望ましい。
• 🔁 誤答例：「確認する」だけでは抽象的。
• 💡 他の表現：「協議内容を記録した資料を確認する」も許容範囲。
• 📝 記述注意：誰の議事か（経理部との）が必要。

---

■設問6（【f】）

✅ 模範解答：
「定型サービスのサービスカタログにリードタイムの目標が明記される予定になっていること」

🧠 思考プロセス：

• 🔍 ヒント：ユーザが申請前に見られる情報 → カタログ。
• ✨ リードタイムは目標値の周知が肝。
• 🔁 誤答例：「画面に表示される」など根拠が不明瞭だと減点。
• 💡 他：「サービス仕様一覧に記載される」も準正答。
• 📝 記述注意：主語と記載場所の両方が必要。

---

【Step 3】設問タイプ別アドバイス

設問	分類	初学者向けアプローチ
設問1	🟢 文中転記・再構成型	提供対象（誰に）と機能のセットを明記
設問2	🔴 因果構造推定型	誰が・どの基準で承認するかを整理
設問3	🟡 知識補完型	属人更新に対する基本的統制として手順明文化
設問4	🔴 因果構造推定型	エラー処理不備→請求漏れという因果構造に着目
設問5	🟡 知識補完型	検討の有無は文書（議事録）で確認するのが基本
設問6	🟢 文中転記・再構成型	リードタイムの明記先（カタログ）に注目

---

【Step 4】全体指導コメント（汎用アドバイス）

• 👀「図1」や申請プロセスの整理が全設問の前提。サービスカタログ・申請・通知・請求の情報流を理解することが重要。
• 👤「誰が」「どの画面を使って」「誰に承認されて」申請が流れるかの認識がカギ。
• 🛑 抽象語や一般論に逃げず、「カタログ」「議事録」「リーダー承認」など具体名詞で書くこと。
• 🧩「コントロール」という語をただ使うのではなく、その手段（承認ルート、明記内容、更新手順）まで記述する癖をつけよう。

---

【Step 5】教材化・再構成提案

• 📝練習問題形式：
  • 【○】正しい記述はどれか（4択）として再構成しやすい
  • 【×】単なる暗記問題にはならないよう、申請プロセスを図と照らし合わせる設問形式が効果的
• 📊補助資料案：
  • 「図1」を簡易化したプロセス図（申請→通知→承認→請求の流れ）に注釈付きで提示
• 🔁フォローアップ学習：
  • 「サービスコード管理」や「マスタ整合性」に関する他年度の問題との横断比較
  • 「エラー処理と請求漏れ」などの業務リスク→統制パターン演習

🎓講評コメント（AI評価）

「ITサービス管理システム」──この語に“うわ、実務っぽい”と身構えた受験者もいることでしょう。でも安心してください。これは、システム監査人の“定型力”が試される極めて王道の一問です。

---

■試験の本質：これは“統制デザイン評価型”の問題だ

この問題の肝は、「これから導入される新システムに、必要な統制が設計段階で組み込まれているか」を冷静に点検する視座を持てるかどうかです。

つまりこれは、午後Ⅱで問われる“個別監査計画の論点抽出”を擬似的に体験させるタイプの問題。
内部統制の“盲点”を予見し、適切なコントロールや監査手続を提案できる力が試されます。

---

■設問1：機能の“活用範囲”まで見抜けるか？

「一覧承認機能の上長提供の有無を確認する」──一見すると“単なるUIの話”に見えるかもしれませんが、これは“統制の整備状況”そのものです。

上長の手間が増える設計であれば、申請遅延や無断利用の温床になる。それを防ぐには、現場の業務設計と機能の整合性を見る力が必要です。

---

■設問2：承認プロセスにおける“責任の所在”を可視化できるか？

この設問の本質は、承認ルートの明確化による職責統制の確保です。

“規模が大きければ部長承認”という話は、単なる手続に見えて、内部統制の要諦そのもの。
「業務のリスクレベルに応じた承認権限の割当」がなければ、すべての承認がリーダーレベルで止まってしまう。それを防ぐ仕組みがあるかどうか、監査人の観点から確認できているかが問われています。

---

■設問3：マスター更新は“属人リスク”の温床である

この問いは、マスタ管理に潜む“例外対応のリスク”を見抜けるかという問題。

更新手順が定まっていなければ、更新漏れ・誤更新による課金ミスが生じる。それは“設計不備”というよりも、“内部統制の欠如”です。
**「明文化された手順＝コントロール」**だという監査人の思考があるかが試されています。

---

■設問4：エラー＝単なる技術的問題ではない

ここで問われているのは、**「処理されなかった結果、何が起こるか」**です。

「エラーが出るだけなら統制が働いている」と考えるのは危険で、重要なのはその後の“対処の所在”が明確かどうか。

この設問では、“実在性の評価”が裏テーマ。請求できていない＝売上が未計上＝財務影響あり。こうした経営リスクへの接続ができるかが評価ポイントです。

---

■設問5：監査手続の記述に“証拠性”を盛り込めているか？

「検討したかどうか」を確認する方法として、“議事録を閲覧する”というのは、監査技法の王道です。

監査人にとって重要なのは、“何をもって確認したか”を明示できること。
午後Ⅱでも必須となる「監査証拠の選定と適用の技法」が、ここでは非常に端的に問われています。

---

■設問6：カタログは“運用設計そのもの”である

「カタログにリードタイムを明記する」ことは、単にユーザ周知の話ではありません。
これはサービス提供の可視性・説明責任・合意形成を支える重要な要素です。

つまりこの設問は、“統制の効果的な伝達手段”としてのカタログの役割に気づけるかという問題です。

---

■総括：これは“午後Ⅱの第2章＋第3章の原型”だ

この問題、設問1～6がそのまま「第2章 監査手続」「第3章 是正提案」の構成要素として流用できるほど、完成度の高い設計になっています。

📌 設問1～2：運用設計と統制手段
📌 設問3～4：統制不備と業務リスク
📌 設問5～6：監査技法と是正方針

これらを正確に読み解く力は、午後Ⅱに直結します。

---

🔍ワンポイント指南（設問別）

設問	評価軸	着眼ポイント
設問1	実効性	組織運用との整合性
設問2	責任性	承認権限とリスクレベル
設問3	手続性	例外時対応の統一ルール
設問4	実在性	財務インパクトへの波及
設問5	証拠性	監査証拠の妥当性と確保
設問6	周知性	可視化・伝達手段の有効性

---

この問題は「導入前監査」の基礎力を問う極めて優れた練習素材です。
午後Ⅰで解いて終わり、ではなく、「午後Ⅱの骨格（構造）に写像できるように自分の言葉で整理する」──これが三好流の活用術です。

🧭午後2論述式接続 「あるべき姿モデル」

【総論】ITサービス管理システムの監査

• ITサービス管理システムの監査は、単なるシステム導入の是非を問うものではなく、全社の業務遂行に関わるITサービスの提供体制と統制構造が、組織の目的に適合し、継続的に機能するかどうかを評価する営みである。そのため監査人には、開発部門やサービス提供部門と一定の距離を保ちつつ、申請・承認・提供・請求といった各プロセスの連動性と整合性を、設計思想・実装状況・運用実態の三面から冷静に検証する姿勢が求められる。
• とりわけクラウド基盤の活用や申請プロセスの自動化が進む現在、利便性と効率性の追求が統制の簡略化を招き、承認の形骸化や利用料の誤請求といったリスクが顕在化しやすい。監査人はこうした構造的リスクを捉え、制度設計上の想定と実務レベルの運用との乖離を浮き彫りにしなければならない。
• 監査の目的は、欠陥の指摘ではなく、仕組みとしての統制が“回る”状態を再構築することである。そのため監査人は、「なぜこの申請は通ってしまうのか」「なぜこの更新は漏れたのか」といった構造的な問いを持ち、再発を防ぐ仕組みづくりまでを見据えた是正提案を行う責任を担う。
• ITサービス管理システムは、組織全体の“業務の神経系”であり、その設計・運用の健全性を点検・改善する監査は、単なるIT監査にとどまらず、経営資源の配分や業務改革に対する貢献そのものである。監査人には、制度と現場の両面に目を配りながら、統制の実効性と改善余地を可視化する視座が求められる。

【①視座】監査人の立ち位置（独立性・中立性を含め）

• システム導入部門とは異なるグループ監査部門の一員として、全社最適の観点から、導入の妥当性とリスク統制の有効性を点検する立場。
• 関係者の期待（効率化・迅速化）に引きずられず、業務プロセス・承認・課金・誤課金など統制の整合性と網羅性を冷静に確認する。
• 開発プロジェクトの「推進・阻害」のいずれにも偏らず、制度と現場運用の乖離リスクに対して抑止的・予防的機能を果たす。

---

【②着眼点】当該テーマで着目すべき統制・リスク観点

• 承認手続の簡略化に伴う形式承認の形骸化リスク
• マスター未更新やサービスコード不一致による誤請求・請求漏れ
• 見積承認ルート未設定による高額サービスの無承認提供
• 締切日変更と運用負荷のバランスに伴う定着性の低下
• リードタイム短縮の公表に関する利用者への誤認リスク
• ユーザビリティと内部統制の相反関係（効率化の裏にある手続逸脱リスク）

---

【③行動】具体的な監査行動（文書確認／インタビューなど）

• 【導入企画書・設計書の閲覧】── 目的・効果・想定運用手順の妥当性確認
• 【技術管理部・サービスチームへのヒアリング】── 実装予定機能と運用想定の整合確認
• 【定型サービスマスター・更新手順書の確認】── 更新責任と頻度、記録の整備状況を確認
• 【部門間協議の議事録の閲覧】── 締切日変更等の合意形成過程を検証
• 【請求処理・エラーリスト出力状況のサンプルチェック】── 不整合時の実運用を評価
• 【サービスカタログの画面設計資料の閲覧】── リードタイムの公開方法と記載有無を確認

---

【④判断軸】監査評価における基準・優先観

• 【統制の実効性】：機能の実装有無ではなく、運用レベルで確実に機能する仕組みか
• 【責任の明確性】：マスター更新／見積承認／請求対応など、誰が、いつ、何をするかの明確性
• 【証跡の整備】：システム内の操作記録・エラー処理履歴が残り、追跡可能であること
• 【可視性と利用者認識】：リードタイムや仕様変更など、利用者にとって透明性が確保されているか
• 【移行時の配慮】：システム移行に伴う一時的な混乱・誤運用を回避する計画性

---

【⑤是正力】実効性ある提案の特徴

• 制度＋運用の両面に提言（例：マスター更新手順の文書化＋更新タイミングの自動通知）
• エラー処理の責任者明記と処理期限設定により請求漏れを抑止
• 緩和と統制のバランス（例：承認簡略化機能に上長向け一括確認画面を提供）
• リードタイムの画面表示で「明示責任」も利用者に付与（相互の認識ギャップを抑止）
• 日程が厳しい場合は段階移行（移行→定着→制度変更）を是正案とする

---

【⑥組織貢献】監査を通じてもたらされる価値

• 【サービス提供プロセスの一元管理】── 効率化と透明性の両立に寄与
• 【誤請求・未請求の低減】── 財務処理の精度向上・内部統制の強化
• 【現場との調整支援】── 承認・締切変更など、業務負荷と制度改変の橋渡し
• 【教訓蓄積と全社展開】── 移行時リスク・マスター管理ノウハウを他システム展開時にも活用可能
• 【プロジェクトのガバナンス強化】── システム導入プロジェクトの適正化とグループ全体のIT統制向上