| 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. タスクからプロセスへ ― Agentic Workflow とは
第4回で整理した構造を思い出してください。Skill は1つの動作、Agent は目標の自律実行、そして Agentic Workflow は複数のエージェントを連結し、業務プロセス全体を通して動かす層です。違いは「規模」ではなく、連携（オーケストレーション）があるかどうかにあります。
単一エージェントの世界では、所見作成エージェントが仕事を終えた後、その結果を受けて次に何をするかを決めるのは人でした。Agentic Workflow では、この受け渡し自体が設計に組み込まれます。計画段階のエージェントが立てたスコープ案が、テスト段階のエージェントの入力になり、その検証結果が所見作成エージェントに渡り、さらに報告・是正のエージェントへ引き継がれていく ― こうした段階間の受け渡し（ハンドオフ）と実行の順序をオーケストレーション層が制御することで、プロセスが途切れずに流れます。
図1 単一Agent と Agentic Workflow ― 連携の違い。オーケストレーション層のもとでプロセス全体が流れる一方、要所には人の関所が置かれる
図1の右側で注目していただきたいのは、人の関所（黄色い箇所）が消えていないことです。プロセスが自律的に流れるようになっても、人の判断を挟む場所はむしろ明示的に設計されます。第4回で述べた「監査判断に相当する箇所に承認ゲートを置く」という規律は、Agentic Workflow でも変わりません。変わるのは、関所と関所のあいだを人が手作業で埋めなくてよくなる、という点です。
ServiceNow では、複数のエージェントを連携させて業務プロセスを動かす Agentic Workflow の提供が始まりつつあります。IRM 領域でも、第4回で紹介した GRC 向け AI Agent のうち、Issue action plan AI agent が示したアクションプランを、Remediation tasks AI agent が是正タスクに落とす ― という関係は、あるエージェントの出力が次の動作の入力になる、連携の原型と見ることができます。ただし「監査プロセス全体を通貫する Agentic Workflow」は、標準機能として完成された形で提供されているものではありません。本章は目指すべき方向性と設計の考え方として読んでください。提供状況の最新は、リリースノートおよび ServiceNow Store をご確認ください。
02. 監査プロセスを貫くとどうなるか ― USBメモリ統制の1年
連載を通じて追いかけてきた、USBメモリ利用制限の統制を担当する監査人・Aさん。最終回では、Aさんの1年を通して見てみましょう。第1回で描いた監査サイクル（計画・スコーピング → 実施・証拠収集 → 報告・是正）が、Agentic Workflow の上でどう流れるか、という視点です。
2-1. 計画 ― 「例年どおり」からの脱却
年度初め。リスク特定のエージェントが、CMDB上の資産構成の変化、直近のインシデント、規制アラート、前年度の是正状況を横断して読み込み、「今年注視すべき領域」の候補を提示します。第2回で挙げた落とし穴 ―「Risk Assessment の最新結果が計画に反映されず、例年どおりの網羅になる」― は、ここで構造的に解消されます。Aさんの仕事は、候補リストを眺め、監査部門としての優先順位を決めることです。
2-2. 実施 ― 証跡は「集める」から「差分を見る」へ
テスト段階では、証跡収集のエージェントが、Attestation の回答、CMDB上のデバイス管理設定、例外承認の記録を突き合わせ、食い違いの候補を提示します。第3回で議論した「証言と記録の突合」が、人がボタンを押すのではなく、プロセスの一部として自動的に走る形です。Aさんが向き合うのは、証跡の山ではなく、差分のリストになります。
2-3. 所見・報告 ― ドラフトを検証する立場へ
検出された差分から、所見作成エージェントがドラフトを起草し（第4回で見た流れです）、承認ゲートでAさんのレビューを求めます。Aさんが承認した所見は、報告・是正のエージェントに引き継がれ、Issue の起票、是正タスクの割り当て、期日管理まで流れていきます。第2回の落とし穴で挙げた「Issue の状態更新が遅れ、実態と乖離する」という問題も、追跡がプロセスに組み込まれることで軽減されます。
この1年を振り返ると、Aさんが手を動かした場面は、どれも判断でした。何を監査対象にするか。この差分は不備なのか、許容される例外なのか。この所見を経営に報告すべきか。逆に、Aさんが手を動かさなくなったのは、記録を集め、突き合わせ、文章にする ― 第3回で監査業務を分解した際の「読む・書く・分析する」、すなわち判断以外の3動作です。連載の冒頭で立てた仮説が、ここで一つの姿に結実します。
03. 監査人の役割はどう変わるのか
ここで、率直な問いに向き合いましょう。「作業がAIに移るなら、監査人の仕事は減るのか」。答えは、減るのではなく変質する、です。3つの方向で新しい仕事が生まれます。
第一に、関所の設計者として。どの段階に承認ゲートを置くか、エージェントにどこまでの権限を与えるか、どの出力を人が必ず検証するか ― これはAIの設定作業ではなく、監査の独立性をどう担保するかという監査固有の設計判断です。第2回で権限境界の設計は監査部門が主導すべきだと述べましたが、Agentic Workflow の時代には、この設計そのものが監査人の中核業務の一つになります。
第二に、AIの出力の検証者として。ドラフトを読み、根拠を確かめ、必要なら差し戻す。これは受け身の確認作業ではありません。生成された所見が事実に基づいているか、見落としがないかを見抜くには、監査人としての専門性がむしろ強く求められます。第1回で引用した「専門的能力の不足」という日本企業の課題は、AI導入によって消えるのではなく、求められる能力の質が変わるのです。
第三に、より高度な監査テーマへ。作業時間が空いた分をどこに使うか。第1回で触れたとおり、ESG・セキュリティ・DXといった高度な専門性を要するテーマの監査ニーズは高まり続けています。これまで人手が足りず着手できなかった領域に、監査部門が踏み出せるようになる ― これが、AI活用の本当の成果です。効率化それ自体がゴールではありません。
04. そして、AIそのものが監査対象になる
最後に、この連載の射程を一歩超えるテーマに触れておきます。ここまで、AIは「監査を支える道具」として語ってきました。しかし組織の中でAIが当たり前に稼働するようになると、監査部門の前に別の顔で現れます ― 統制すべき対象として。
問いは具体的です。組織の中でどのAI・どのエージェントが、どの業務で稼働しているのか（インベントリ）。それは誰が承認し、どんな権限で動いているのか。出力の妥当性は、誰がどのように検証しているのか。実行ログは、統制が有効に機能していることを示す証跡として十分なのか。― これらは、監査人が他の統制に対して日常的に投げてきた問いと、まったく同じ形をしています。
ここで、本連載が第2回から一貫して述べてきたことが効いてきます。統制の対象は、実在するものに紐づいていなければ検証できない。AIエージェントも同じです。組織で稼働するエージェントが、管理対象として台帳（インベントリ）に登録され、承認記録と権限設定と実行ログを伴って存在していれば、監査は成立します。逆に、誰がいつ何のために作ったか分からないエージェントが業務の裏側で動いていれば、それは第2回で述べた「Excelに散らばった証跡」と同じ、監査できない領域になります。
ServiceNow は、この領域に向けて、組織で稼働するAIを一元的に可視化・管理する仕組みとして AI Control Tower を打ち出しています。また外部の枠組みとしては、第3回で触れた ISO/IEC 42001（AIマネジメントシステム）や、経済産業省・総務省の「AI事業者ガイドライン」が、監査部門がAI統制を説明する際の共通言語になります。
「AIを監査する」という論点は、それ自体で一つのシリーズに値する広がりを持っています。本記事では、Agentic Workflow の先に必ず現れる課題として提起するに留めます。関心をお持ちの方は、ぜひコメントでお知らせください。
05. 全5回を振り返って
最後に、連載全体を1本の線で振り返ります。
第1回では、日本企業の内部監査が抱える課題 ― 証跡の属人化、複数フレームワーク対応の重複、そして専門人材の不足 ― を整理し、ServiceNow IRM が3ラインモデルの中でどう位置づくかを示しました。ここで、課題をツールで解けるものとAIで解くものに分けたのが、連載全体の設計図でした。
第2回では、前者に答えました。規制から手元のPCまでが一本の鎖でつながるデータ基盤。同じ統制・同じ資産を Compliance・Risk・Audit が共有する「統合」の価値。そして、その価値は自動では手に入らず、業務の合意・データ品質・監査独立性を先に押さえる必要があるという落とし穴。
第3回から後者、AIの領域に入りました。監査業務を「読む・書く・分析する・判断する」に分解し、前3者がAI支援の対象であること。Now Assist のスキルは標準スキルの複製と視点の書き換えで監査向けに調整できること。そしてAIの出力の質は、データ基盤の質で決まること ― 第2回を先に扱った理由が、ここで明らかになりました。
第4回では、支援から自律実行へ。目標を渡すと手順を組み立てるエージェント、その規律としての承認ゲート・最小権限・実行ログの監査証跡化。そして本記事で、タスクからプロセス全体へ ― 監査人が判断に集中する姿と、AIそのものを監査するという次の課題まで。
連載を通じて、一つのことを繰り返し述べてきました。AIは監査人を置き換えない。独立した立場で統制の有効性を評価し、リスクを見極め、経営に伝える ― この判断は、監査という職能の存在理由そのものであり、譲るべきものではありません。AIが引き受けるのは、その判断に至るまでの作業です。そして、その作業を安心して任せられるかどうかは、結局のところデータ基盤の質と、人の関所の設計にかかっています。技術の話に見えて、実は監査部門自身が主導すべき設計の話 ― それが、この連載でお伝えしたかったことです。
第5回のまとめ
- Agentic Workflow は、タスクからプロセスへの拡張。オーケストレーション層が段階間の受け渡しを制御し、計画からテスト・所見・報告までが途切れずに流れる。ただし要所の人の関所は消えず、むしろ明示的に設計される。
- 監査人の役割は減らず、変質する。関所の設計者として、AI出力の検証者として、そしてこれまで着手できなかった高度な監査テーマの担い手として ― 求められる専門性の質が変わる。
- そして、AIそのものが監査対象になる。稼働するエージェントを管理対象として可視化し、承認・権限・実行ログを統制の証跡として整える。第2回で述べた「実在に紐づかないものは検証できない」という原則が、AIにもそのまま当てはまる。
全5回、お読みいただきありがとうございました。本連載は、日本企業の内部監査に携わる方、ServiceNow IRM の導入を検討・推進されている方に向けて、実務に即した一本の道を示すことを目指しました。ご質問・ご意見、そして「自社ではこう進めている」という知見の共有を、コメントでお待ちしています。
より体系的に学びたい方には、ServiceNow University の研修（Now Assist for Integrated Risk Management (IRM) Implementer 等）もあります。導入のご相談は担当営業までお問い合わせください。
