| ServiceNow IRMではじめる監査DX（第1回） 内部監査はこう変わる（本記事） |
| ServiceNow IRMではじめる監査DX（第2回） 監査を支えるすべての情報をつなぐ |
| ServiceNow IRMではじめる監査DX（第3回） AIは監査人の最強のパートナーになる |
| ServiceNow IRMではじめる監査DX（第4回） AIエージェントが監査を自律実行する |
| ServiceNow IRMではじめる監査DX（第5回） 人は判断へ――Agentic Workflowが描く監査の未来 |
01. 日本企業の内部監査のプロセス
内部監査は、組織のガバナンス・リスクマネジメント・内部統制の有効性を、業務執行から独立した立場で評価し、改善を促す役割を担います。その実務は、おおむね次のサイクルで回ります。
年度監査計画の策定 → 監査対象の選定 → 往査・実査（ヒアリング、証跡の収集、整備状況評価、運用状況評価）→ 所見の作成 → 講評・報告 → 改善のフォローアップ。
このサイクルが対象とする範囲は、決して財務報告に関わる統制だけにとどまりません。J-SOX における内部統制の独立的評価において内部監査人が重要な役割を担うことはもちろん、コーポレートガバナンスや会社法が求める内部統制システムの運用評価にまで、その守備範囲は広がっています。
ところが、この広範なサイクルを支えているツールはどうでしょうか。多くの企業では、いまだに Excel の監査調書、メールでやりとりされる証跡、共有フォルダに積み上がるファイル ― という運用が現実です。プロセスは年々高度になっているのに、それを支える足元の仕組みが追いついていない。ここに、最初の問いが生まれます。
02. その現場が抱える課題
第1章で描いたプロセスには、ツール・運用の面と、人材・専門性の面の両方に、構造的な痛みがあります。
ツール・運用面の課題
まず、証跡管理の属人化です。どの証跡がどこにあるのか、担当者本人しか分からない。担当者が異動すれば、過去の監査の文脈ごと失われてしまいます。次に、監査対象の増加に人手が追いつかないこと。そして、J-SOX・ISMS・ISMAP といった複数のフレームワークに並行対応する中で、似たような作業が何度も重複して発生すること。さらに、過去の監査履歴やフォローアップの状況が追いにくく、「前回の指摘はどうなったか」を確認するだけでも手間がかかります。
加えて、近年の内部監査はリスクベース監査が主流です。チェックリストに沿って〇×を判定するだけの監査では、もはや十分とは言えません。にもかかわらず現場では、リスク評価と監査計画が分断され、「なぜこの対象を監査するのか」という根拠が弱いまま運用されているケースが少なくありません。
人材・専門性の課題
もう一つ、より根深いのが人材の課題です。日本企業の内部監査は、欧米と比べて歴史が浅く、専門的能力の不足が最大の弱点だと指摘されています。欧米では内部監査が経理や法務と並ぶ専門職とみなされ、豊富な経験を持つ専門家が担うのに対し、日本企業では「キャリアの最後に数年だけ在籍する部門」という色合いがいまだに濃く残ります。専門家として成熟する前に異動してしまい、知見が組織に蓄積されにくいのです。
その一方で、監査人に求められる水準は年々上がっています。リスク分析、根本原因分析、レポートライティングといった監査技能に加え、ESG・セキュリティ・DX など高度な専門性を要するテーマへの対応も迫られています。広範な業務領域を、限られた人数で網羅し続けることは、もはや現実的ではありません。
この連載が解いていく課題
ツールや運用の課題は、ServiceNow IRM が監査サイクルを1つのプラットフォームに統合することで解いていきます（本記事の第3〜4章）。専門的能力の不足や、広範な領域を少人数で網羅する限界といった人材面の課題は、後半の AI 活用編で核心に触れます ― Now Assist や AI Agent が「読む・書く・分析する」を支援し、監査人が本来集中すべき「判断」に時間を割けるようにする。本連載は、この2つの解を順を追って示していきます。
03. ServiceNow IRM 製品とは ― 何が役立つか
これらの課題に対する解が、ServiceNow IRM です。IRM の全体像をつかむうえで、内部監査に携わる方なら馴染みのある枠組みを切り口にしましょう ― 「3つのディフェンスライン」です。
組織におけるリスク管理の役割は、伝統的に3つの線で整理されてきました。内部監査の国際団体である IIA（内部監査人協会）は、この考え方を「Three Lines Model」として改訂し、各線を硬直的な「防衛線」としてではなく、それぞれの役割・機能として柔軟に捉える方向へと整理し直しています。まず、その関係性を見てみましょう。
この3つの線に、ServiceNow IRM/GRC （※1）の各製品が対応します。ただし注意したいのは、製品と防衛線が1対1で対応するわけではないという点です。多くの製品は複数の線にまたがって使われます。たとえば Policy and Compliance Management は、統制を業務に組み込む事業部門（第1線）と、遵守を管理するコンプライアンス部門（第2線）の両方が対象です。下の表で、主要な製品と、それを使う対象者（防衛線）を整理します。
この表から、内部監査を担う第3線が使う中核製品が Audit Management であることが分かります。同時に、監査人が検証する対象 ― 第1線・第2線が Policy and Compliance や Risk Management で整備・運用した統制やリスク ― も、同じ ServiceNow の上に載っています。だからこそ第3線は、それをそのまま検証に使えるのです。
重要なのは、これら3つの線が別々のツールやスプレッドシートで動くと、線と線の間で情報が分断されてしまうという点です。ServiceNow IRM は3つの線を1つのプラットフォームに載せます。第1線が記録した統制を第2線が評価し、それを第3線（監査）がそのまま検証に使える ― この「線をまたぐ情報の連続性」こそ、第2章で挙げたツール・運用面の課題に直接効く、統合の価値です。
※1：ServiceNow GRCとServiceNow IRMの関係性
ServiceNow GRC製品ファミリーは、Integrated Risk Management（IRM）、事業継続性管理（Business Continuity Management）、プライバシー管理（Privacy Management）、サードパーティリスク管理（Third-Party Risk Management） などで構成されています。
また、Integrated Risk Management（IRM） には、Policy and Compliance、Risk Management、Audit Management などのアプリケーションが含まれています。
04. Audit Management の活用術 ― J-SOX / ISMS 対応例
ここからが本題です。第3線の主役である Audit Management が、実際の監査業務をどう変えるのか。第1章で見た監査サイクルに沿って、具体的に見ていきましょう。
4-1. 監査サイクルが ServiceNow 上でどう回るか
Audit Management のデータモデルは、監査業務の流れに沿って3つの層で構成されています。計画・スコーピング（何を監査し、どう資源を割り当てるか）、実施・証拠収集（現場での検証作業）、報告・是正（不備の特定と改善）です。第1章で見た監査サイクルが、そのままこの3層に対応します。
監査業務の流れを Audit Management のデータモデルに当てはめると、以下のようになります。
-
Audit Plan（年間監査計画）で年間の監査計画を管理します。
-
Engagement（監査案件）では、個々の監査案件や監査範囲を定義します。
-
Auditable Unit（監査対象）には、業務プロセス・被監査部署・IT資産などの監査対象を登録し、CMDB やリスク、Control（統制）と関連付けます。
-
Audit Task（監査タスク）で統制テストやヒアリング、ウォークスルーを実施します。
-
監査の根拠となる資料はEvidence（証跡）としてタスクに紐づけて管理します。
-
監査で確認された問題はObservation（所見）やIssue（不備）として記録され、Remediation Task（是正タスク）により改善状況まで追跡します。
4-2. J-SOX 対応例
J-SOXは、金融商品取引法に基づく「財務報告に係る内部統制報告制度」の通称です。上場企業に対し、財務報告の信頼性を確保するための内部統制を自ら評価し、その結果を内部統制報告書として開示することを求めています。
評価は、大きく2つの階層で行われます。全社的な内部統制（全社統制）は、経営者の姿勢やコンプライアンス意識など、組織全体の「土台」が健全かを評価します。業務プロセスに係る内部統制（業務処理統制）は、販売・購買・在庫・決算といった個別業務から「キーコントロール」を識別し、それが有効に機能しているかを評価します。
評価の実務は、統制の文書化（RCM の整備）→ 整備状況の評価（ウォークスルー）→ 運用状況の評価（サンプルテスト）→ 不備の評価と是正 → 報告、という流れで進みます。ここで重要なのは、近年の J-SOX 評価が単なる〇×判定ではないという点です。承認の記録があるだけで有効と評価するのではなく、「承認の際に何をどう確認し、どんな基準で問題ないと判断したのか」まで踏み込んで検証することが求められます。
では、この監査の流れを、実際に ServiceNow 上でどのように管理するのかを、J-SOX の内部統制評価を例に見ていきましょう。
RCM で識別したキーコントロールは Control として登録します。整備状況評価（ウォークスルー）も運用状況評価（サンプルテスト）も、Control を検証する Audit Task（統制テスト）として実施し、その根拠となる証拠は Evidence として該当タスクに紐づけます ― これまで共有フォルダに分散していた証跡が、「どの統制の、どのテストの根拠か」が明確な形で一元管理されます。テストで見つかった不備は Issue として起票され、Remediation Task による是正まで追跡されます。
さらに J-SOX は毎年繰り返される評価ですが、前年度の構造をベースに当年度の評価を進められるため、毎年ゼロから RCM を作り直す必要がありません。評価結果は年度をまたいで蓄積され、統制の有効性の推移を追えるようになります。第2章で挙げた「証跡の属人化」「過去履歴の追いにくさ」という課題が、ここで具体的に解消されていきます。
4-3. ISMS 対応例
同じ仕組みは、情報セキュリティの世界でもそのまま活きます。ISMS（ISO27001）対応では、規格が定める管理策を Control として登録し、情報セキュリティ監査を一つの Engagement として計画・実施、各管理策の運用状況を Audit Task（統制テスト）で検証していきます。所見や是正も、J-SOX と同じ枠組みの中で管理されます。
ここで注目していただきたいのは、J-SOX も ISMS も、まったく同じ Engagement / Control / Audit Task という仕組みの上で回せるという点です。フレームワークが違っても、監査の土台となるデータ構造は共通。だからこそ、第2章で挙げた「複数フレームワークの並行対応による作業の重複」という課題に、本質的な解を与えられます。一つの仕組みを習得すれば、JSOX にも ISMS にも ISMAP等 にも応用が利く ― これが統合プラットフォームの強みです。
4-4. まとめ ― ServiceNow IRM が支える統合的な監査基盤
ここまで見てきたように、Audit Management は単に監査業務を効率化するためのツールではありません。ServiceNow IRM は、リスクやコンプライアンス、内部統制に関する情報を共通基盤で一元管理し、それぞれを関連付けながら運用できることが大きな特長です。
Audit Management を含む ServiceNow IRM の各機能は、「管理すべきリスク・コンプライアンス」と、それを適用する対象（組織・業務・システム）を結び付ける共通のデータモデルの上で動作しています。この仕組みにより、実務では大きく次の2つのレベルで価値を発揮します。
経営レベルの管理
内部統制報告の一元管理：金融商品取引法に基づく J-SOX の要求事項を、会社やビジネスプロセスという実体と結びつけ、自己点検（第1線）と独立的評価（第3線）をそれぞれ年次で回す。全社リスク管理：有価証券報告書に記載するリスク管理の根拠情報として、経営レベルのリスクレジスターを各部門のリスクにブレイクダウンし、リスクアセスメントの結果を集約する。
IT レベルの管理
情報セキュリティ基準の対応状況管理：ISO/IEC 27001 附則書A、CIS Controls、PCI DSS などのセキュリティ基準を、CMDB で管理している実際の機器やアプリケーションと結びつけて管理する。さらに、CMDB の情報を自動で収集し、遵守状況を自動評価することもできる ― 手作業のチェックリストから、継続的な自動モニタリングへ。
経営レベルの「制度対応・全社リスク」から、IT レベルの「セキュリティ統制の自動評価」まで。同じ基盤の上で、粒度の異なる監査・統制業務を一貫して扱える ― これが、第1章で見た広範な監査サイクルを ServiceNow が支えられる理由です。
第1回のまとめ
- 内部監査の現場には二層の課題がある。証跡の属人化や複数フレームワーク対応の重複といったツール・運用面の課題と、専門人材の不足という人材面の課題。
- ServiceNow IRM は3線を1つに統合する。第1線、第2線の Policy and Compliance Managementと Risk Management、第3線の Audit Management を1プラットフォームに載せ、線をまたぐ情報の連続性を実現する。
- Audit Management は共通の仕組みで多フレームワークに対応。Engagement / Control / Audit Task という同じ構造で、全コンプラアンスフレーム（J-SOX、ISMS、ISMAP、SOC2等） にも一貫して対応できる。
次回予告 ・ 第2回
監査を支えるすべての情報をつなぐ
数ある業務の中から「なぜこの対象を監査するのか」を、リスクを起点に組み立てていく ― 監査計画の根幹に踏み込みます。
