IRM 連載 第4回

Integrated Risk Management ・ Audit Management ・ AI Agent

 

ServiceNow IRMではじめる監査DX（第4回）　AIエージェントが監査を自律実行する 

 

「ボタンを押すたびに1動作」のスキルから、「目標を与えると一連のタスクを進める」エージェントへ ― OOTBで提供されるAI Agentの価値と、監査所見作成エージェントというカスタム実装案を、USBメモリ統制の監査を例に解剖します。

第4回： 高度化・AI活用フェーズ（自律実行） 　対象： 技術職・監査実務者（営業の方にも）

 

前回（第3回）は、Now Assist のスキルが監査人の「読む・書く・分析する」をどう支援するかを見ました。標準スキルを複製してプロンプトを監査人の視点に書き換える方法、そしてインタビュー記録を要約する独自スキルの実装案 ― いずれも共通していたのは、監査人がボタンを押すたびに、AIが1つの動作で応えるという形でした。

 

今回は、その一歩先に進みます。ボタンを押す代わりに「目標」を渡すと、AIが必要な手順を自分で組み立て、複数のタスクを連続して実行し、要所で人の確認を求めてくる ― それが AIエージェント（AI Agent）の世界です。監査業務はどこまで自律実行に任せられるのか。そして、任せてはいけない一線はどこか。具体的に見ていきましょう。

 

| 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回 |

図1　Skill と Agent の構造比較 ― スキルは積み木、エージェントはそれを道具として使い、目標に向かって自律的に動く

 

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線）にとって、そのまま監査環境の改善を意味します。一方で、監査人自身の業務に踏み込むエージェント ― たとえば所見のドラフトを起草するようなもの ― は、各組織の監査方法論に合わせて設計する領域です。そこで次章では、その一例として、カスタムエージェントの実装案に踏み込みます。

※1：OOTBのAI Agentについて

上記「何を自律実行するか」欄は、本記事執筆時点で 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. スキルは1動作、エージェントは目標の自律実行。 両者は積み上げの関係にあり、スキルはエージェントの部品になる。第3回で作ったインタビュー要約スキルも、そのまま監査所見作成エージェントの部品として生きる。
2. OOTBのAI Agentは、課題の起票・是正・統制目標の維持など第1線・第2線の業務から拡充が進む。 監査環境の改善にそのまま効く一方、監査人自身の業務の自律実行はカスタムエージェントの領域 ― 「業務の言語化」ができる組織から実装できる。
3. 自律実行時代の規律は3つ ― 監査判断に相当する箇所への承認ゲート、エージェントへの最小権限、実行ログの監査証跡化。 動かすのは作業であって、判断ではない。
   

次回予告 ・ 第5回（最終回）　

人は判断へ――Agentic Workflowが描く監査の未来

単一のエージェントは、1つの業務タスクを担いました。最終回は、複数のエージェントがオーケストレーションされ、計画からテスト、所見、報告までの監査プロセス全体を支える姿 ― Agentic Workflow へ。人が「判断」に集中する監査の未来像と、その先に現れる新しいテーマ ― AIそのものを統制し、監査するという課題 ― まで描いて、本連載を締めくくります。