| 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. 「支援」と「自律実行」は何が違うのか ― Skill と Agent
まず言葉を整理します。前回扱ったスキルは、「この Issue を要約して」「このインタビュー記録をまとめて」という1つの動作を、人の操作をきっかけに実行するものでした。優秀ですが、受け身です。次に何をするかを決めるのは、常に人でした。
一方のエージェントは、「この監査タスクの記録から、所見のドラフトを作ってレビューに回して」という目標（ゴール）を受け取ります。そして、目標を達成するために必要な手順 ― どのデータを読むか、どのスキルを使うか、何を作るか ― を自分で計画し、順に実行し、結果を確認しながら進みます。人に例えるなら、スキルは「頼まれた作業を一つずつこなすアシスタント」、エージェントは「ゴールを共有すれば段取りごと任せられるアシスタント」です。
重要なのは、この2つが対立するものではなく、積み上げの関係にあることです。ServiceNow の整理でも、スキルはビルディングブロック（積み木）と位置づけられています。エージェントは、その積み木を道具として組み合わせ、目標に向かって自律的に動きます。つまり、前回作ったインタビュー要約スキルは無駄になりません。エージェント時代には、そのまま「エージェントが使う道具」になるのです。（複数のエージェントがさらに連携して監査プロセス全体を支える「Agentic Workflow」の姿は、最終回で扱います。）
| 層 | 何をするものか | 扱う回 |
| Skill（スキル） | 人がボタンを押すと、1つの動作（要約する・推奨する・生成する）を実行する | 第3回 |
| Agent（AIエージェント） | 目標を与えると、複数のスキルやツールを組み合わせて一連のタスクを自律的に進める | 第4回（本記事） |
| Agentic Workflow | 複数のエージェントを連結し、業務プロセス全体を通して動かす | 第5回 |
02. まずはOOTBから ― 標準提供のAI Agentが生む価値
「エージェントを使うにはゼロから作らなければならないのか」― そんなことはありません。Now Assist for IRM には、OOTB（標準提供）の AI Agent がすでに含まれており、リリースごとに拡充が続いています。本記事執筆時点で公式ドキュメントに記載されている、GRC 向けの主な AI Agent を、監査業務の視点での価値と合わせて整理します（※1）。
| OOTBのAI Agent | 何を自律実行するか | 監査業務から見た価値 |
| Report a GRC issue AI agent | 申告された課題（Issue）の記述を、過去データとGRCの文脈で補強。課題の種類・発生時期などの要点を抽出し、GRC Issue として起票する | 現場・第1線からの「気づき」が、整った形で起票される入口になる。監査人にとっては、構造化された課題情報が集まり、第1線の統制文化が育つ |
| Issue action plan AI agent | 過去の類似課題の詳細を参照し、解決に向けた最適な手順を特定。段階的に要約したアクションプランとしてユーザーに提示する | 監査指摘後の是正の初動が速い。過去事例を踏まえるため対応の一貫性も上がる。監査人はAIが示したプランの妥当性を検証する立場に |
| Remediation tasks AI agent | Issue レコードのアクションプラン欄の記載を参照し、是正に必要な個々のタスクを特定する | アクションプランが具体的な是正タスクに落ち、是正が速く回り始める。前段の Issue action plan AI agent が示したプランを受けて動くため、プランの生成から是正タスクへの落とし込みまでが連鎖する ― 第5回で扱う Agentic Workflow の萌芽が、ここにある |
| Control objective change AI agent | コンプライアンス管理者として、関連する引用（Citation＝規制・規格）に照らし、統制目標（Control Objective）の記述・補足ガイダンスに更新が必要かを検証。必要なら新しい値を提案し、ユーザーの確認を得たうえで統制目標レコードを更新する | 第2回で見た「ISO/IEC 27001 改訂の影響洗い出し」の初動が自律化。統制が最新の規制に追随し、変更履歴も整うため、監査で「いつ・なぜこの統制になったか」を追跡しやすくなる |
一覧を眺めると、あるパターンに気づきます。OOTBのエージェントは、課題（Issue）の起票・是正の段取り、そして統制目標の維持 ― つまり日々の統制運用、すなわち第1線・第2線の業務から先に整備されています。これは前回の標準スキルと同じ構図です。第1線・第2線の記録の質が上がることは、それを検証する監査（第3線）にとって、そのまま監査環境の改善を意味します。一方で、監査人自身の業務に踏み込むエージェント ― たとえば所見のドラフトを起草するようなもの ― は、各組織の監査方法論に合わせて設計する領域です。そこで次章では、その一例として、カスタムエージェントの実装案に踏み込みます。
上記「何を自律実行するか」欄は、本記事執筆時点で ServiceNow 公式ドキュメント「Governance, Risk, and Compliance AI agents」に記載されている GRC 向け AI Agent の説明に基づいています。一方、「監査業務から見た価値」欄は、監査業務の観点からの筆者による解釈です。名称・提供状況・対象リリースは、リリースノートおよび ServiceNow Store の最新情報をご確認ください。
※参照：ServiceNow Docs ― Governance, Risk, and Compliance AI agents
03. カスタムAgentの実装案 ― 「監査所見作成エージェント」を解剖する
題材は引き続き、USBメモリ利用制限の統制を検証する監査人・Aさんです。第3回で、AさんはIT部門へのインタビュー記録を要約するスキルを手に入れました。そこには「一部の開発機については例外運用があるとの言及あり（要フォローアップ）」という気になる一文がありました。ここから所見に至るまでの道のりを思い出してみましょう ― テスト結果と突き合わせ、統制の要求事項と比較し、事実・基準・原因・影響を整理して文章化し、レビューに回す。1件なら30分。しかし監査項目が数十件あれば、この「整理と文章化」だけで数日が消えます。
この一連の流れを目標として渡せるのが、監査所見作成エージェントです。エージェントに与える目標はこうです ―「この Audit Task の記録をもとに、所見のドラフトを作成し、監査人のレビューに回すこと」。
図2 監査所見作成エージェントの実行フロー ― 収集・突合・起草はAIが進め、所見とするかの判断は承認ゲートで監査人が担う
設計のポイントを整理します。
| 設計項目 | 内容 |
| 目標（役割） | 内部監査を支援するエージェントとして、Audit Task の記録から所見ドラフトを作成し、監査人のレビューに回す |
| トリガー | 監査人による手動起動（Audit Task 上から）を推奨。将来的にはテスト完了時の自動起動も検討可 |
| 使用ツール | レコードの読み取り（Control・テスト結果・証跡）、インタビュー要約スキル（第3回で構築したものを再利用）、所見ドラフト生成、レビュー依頼、所見レコードの作成 |
| 承認ゲート | 所見レコード起票の前に必ず監査人のレビュー・承認を挟む。差し戻し時はエージェントが修正版を再提示 |
| 指示上の制約 | 統制が有効かどうかの評価・結論は生成しない。事実・基準・原因（候補）・影響の整理まで。原因は「考えられる候補」として提示し、断定しない。確信が持てない項目は N/A（第3回のプロンプト方針を継承） |
| 出力 | 承認済み内容に基づく 所見レコード（Engagement・Control に紐づく） |
注目していただきたいのは、使用ツールの欄です。第3回で作ったインタビュー要約スキルが、そのままエージェントの部品として再利用されています。スキルへの投資は、エージェント時代への積み立てになる ― 小さく始めることに意味がある理由が、ここにあります。
もう一つ。STEP 3 の制約 ―「評価・結論は書かない」― は第3回のプロンプト方針そのままです。エージェントが自律的に動く範囲が広がっても、「事実の整理まではAI、評価は監査人」という線は動かしません。動かすのは作業であって、判断ではないのです。
04. どう作るのか ― AI Agent Studio の基本構成
では、このエージェントはどうやって作るのでしょうか。ServiceNow には、エージェントを構築するための AI Agent Studio が用意されています。ここでは全体像だけつかんでください ― エージェントの定義は、大きく4つの要素で構成されます。
①役割と指示：エージェントが何者で、何を目標とし、何をしてはいけないか。自然言語で記述します。前章の「設計項目」の表が、ほぼそのまま指示文の骨格になります。
②ツール：エージェントが使える道具の登録です。レコードの読み書き、フロー、そして Skill Kit で作ったスキル。
③トリガー：いつ動き出すか。手動起動か、レコードの状態変化などによる自動起動か。
④実行環境と可用性：誰が・どこから使えるか。あわせて、権限などのセキュリティ制御もここで定義します。エージェントの実行はプラットフォームのオーケストレーション機能が管理し、各ステップの実行履歴が記録されます。
詳細な構築手順は本連載の範囲を超えるため、ServiceNow University の AI Agent 関連コースや公式ドキュメントに譲りますが、一つだけ強調しておきます。エージェント構築の中心作業は、コーディングではなく「業務の言語化」です。監査所見とは何か、何を根拠に、どんな構成で書くべきか ― それを明文化できる人こそが、良いエージェントを作れます。第2回の3-1で「暗黙知の棚卸しが先」と述べた理由は、エージェント時代にはさらに重くなるのです。
05. 自律実行時代の設計原則 ― 人の関所をどこに置くか
エージェントは強力です。だからこそ、監査で使うための規律を最後に定めておきます。原則は3つです。
第一に、承認ゲートの設置基準。どこに人の関所を置くかは、「それは監査判断か？」で決めます。所見として確定する、Issue を起票する、重要度を判定する、経営への報告内容を決める ― これらは監査判断であり、必ず人が担います。逆に、記録を読む・突き合わせる・ドラフトを書くといった作業は、エージェントに任せて構いません。実際、OOTBのエージェントにもこの発想は組み込まれています。たとえば前章で触れた Control objective change AI agent は、統制目標の更新を提案しても、実際に更新するのはユーザーの確認を得た後です ― 提案はAI、確定は人、という関所が、すでに標準の動作に埋め込まれているのです。関所を置くのは、AIを信用していないからではなく、責任の所在を明確にするためです。
第二に、最小権限。エージェントには、目標の達成に必要な最小限の権限だけを与えます。監査所見作成エージェントであれば、Audit Task 関連の読み取りと Observation の作成だけ。統制（Control）そのものの変更権限は与えません。第2回の3-2で「監査人が自らの監査対象の Control を変更できない」独立性設計を検証したのと同じことを、エージェントというもう一人の作業者にも適用するのです。
第三に、実行ログは監査証跡。エージェントの各ステップ ― 何を読み、何を生成し、誰が承認したか ― はプラットフォーム上に記録されます。これは第3回で述べた追跡可能性のエージェント版です。「AIが作業したから過程がブラックボックスになる」のではなく、むしろ人手の作業より詳細な過程が残る。この記録性こそ、監査という業務がエージェントと相性の良い、最大の理由かもしれません。
第4回のまとめ
- スキルは1動作、エージェントは目標の自律実行。両者は積み上げの関係にあり、スキルはエージェントの部品になる。第3回で作ったインタビュー要約スキルも、そのまま監査所見作成エージェントの部品として生きる。
- OOTBのAI Agentは、課題の起票・是正・統制目標の維持など第1線・第2線の業務から拡充が進む。監査環境の改善にそのまま効く一方、監査人自身の業務の自律実行はカスタムエージェントの領域 ― 「業務の言語化」ができる組織から実装できる。
- 自律実行時代の規律は3つ ― 監査判断に相当する箇所への承認ゲート、エージェントへの最小権限、実行ログの監査証跡化。動かすのは作業であって、判断ではない。
単一のエージェントは、1つの業務タスクを担いました。最終回は、複数のエージェントがオーケストレーションされ、計画からテスト、所見、報告までの監査プロセス全体を支える姿 ― Agentic Workflow へ。人が「判断」に集中する監査の未来像と、その先に現れる新しいテーマ ― AIそのものを統制し、監査するという課題 ― まで描いて、本連載を締めくくります。
