| 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. なぜ今、監査にAIなのか
監査の現場では、AI活用がすでに「検討」から「実装」の段階に移りつつあります。理由はシンプルです。監査業務の大半は、大量のテキストと記録を「読み」、定型性の高い文書を「書き」、データを「分析する」仕事であり、これらはいずれも生成AIが最も得意とする動作にあたるからです。だからこそ監査は、AIと最も相性の良い専門領域の一つとされ、監査プラットフォームへの生成AI組み込みを進める動きが各所で始まっています。
この移行は、印象論ではなく数字にも表れています。Gartner が2026年1月に公表した調査（CAE 119名を対象、2025年8月実施）によれば、監査部門の83%がすでにAIを試行または活用しており、さらに12%が1年以内に追随する予定です。同調査では、監査部門トップ（CAE）の70%以上が、データ分析や生成AIの活用を2026年の重要な優先事項に位置づけているとも報告されています。「一部の先進企業が試している」段階から、「業界の大多数が動いている」段階へ、状況は明確に移行しています。
出典：Gartner「Gartner Survey Shows Audit Departments Are Embracing AI and Data Analytics to Drive Innovation in 20...」（2026年1月27日）
AI導入が先行している監査部門の取り組みには、共通点が2つあります。「監査人が大量の文書を読み込む」工程を最初のターゲットに据えていること。そして、人による確認を組み込んだ Human-in-the-loop を、前提の枠組みとして明示していること。この2点は、本記事を通じて何度も戻ってくる論点になります。
一方、日本企業の内部監査に目を戻すと、第1回で整理したとおり、専門人材の不足が構造的な弱点として残っています。監査対象は増え、求められる専門性は上がり続けるのに、人は増えない。この需給のギャップを埋める現実的な選択肢が、AIによる業務支援です。
ここで最初に立場をはっきりさせておきます。AIは監査人を置き換えるものではありません。監査人の「判断」の時間を生み出すものです。独立した立場で統制の有効性を評価し、リスクを見極め、経営に伝える ― この判断こそが監査人の専門性の核心であり、AIに委ねるべきものではない。では、判断以外の時間を今、何が奪っているのか。それを見るために、監査業務を動作のレベルまで分解してみましょう。
02. 監査業務のどこにAIが効くか ― 4つの動作への分解
第1回で見た監査サイクル（計画・スコーピング → 実施・証拠収集 → 報告・是正）を、監査人の動作で輪切りにすると、あらゆる工程が「読む」「書く」「分析する」「判断する」の4動作に分解できます。
図1を見ると、監査人の時間の大半が「判断」以外の3動作に費やされていることが見えてきます。証跡を読み、サンプルを突き合わせ、調書化をする ― どれも監査に不可欠ですが、判断そのものではありません。
そして、この3動作にAIが手を出せるかどうかは、データ基盤の状態で決まります。AIに「この統制の現在地を教えて」と尋ねたとき、AIが辿れるのはレコードとレコードのつながりだけだからです。USBメモリ利用制限の Control から、それに紐づく過去の Issue へ、その是正タスクへ、直近の自己申告（Attestation） へ ― 前回組んだ鎖があるから、AIはこの経路を歩けます。同じ情報が Excel とメールとファイルサーバーに散らばっていれば、そこに鎖はなく、AIには辿るべき道が見えません。データ基盤は、AIを載せるための地盤でもあると第2回で述べた理由が、ここにあります。
この構造は、監査の実施だけでなく計画にも効きます。第2回で挙げた「Risk Assessment の最新結果が計画に反映されず、例年どおりの網羅になる」という課題 ― リスク評価データを読み込み、監査対象の優先順位案を組み立てる作業も、まさに「読む・分析する」の領域です。リスクベース監査への転換を阻んでいた作業負荷そのものが、AIの支援対象になります。
03. Now Assist for IRM でできること ― USBメモリ統制の監査を例に
それでは具体的に見ていきましょう。Now Assist は、ServiceNow プラットフォームに組み込まれた生成AI機能の総称で、IRM 領域向けには Now Assist for IRM として、リスク・コンプライアンス業務に特化したAIスキル群が提供されています。別のツールを立ち上げるのではなく、普段使っている IRM の画面の中に、AIの支援が現れる ― これが最大の特徴です。
その中身に入る前に、本連載の残り3回の見取り図を示しておきます。ServiceNow のAI機能は、次の3つの層で理解すると迷いません。
| 層 | 何をするものか | 扱う回 |
| Skill（スキル） | 人がボタンを押すと、1つの動作（要約する・推奨する・生成する）を実行する | 第3回（本記事） |
| Agent（AIエージェント） | 目標を与えると、複数のスキルやツールを組み合わせて一連のタスクを自律的に進める | 第4回 |
| Agentic Workflow | 複数のエージェントを連結し、業務プロセス全体を通して動かす | 第5回 |
下の層ほど自律性が高くなり、そのぶん「人の関所をどこに置くか」という設計が重くなります。だからこそ、まずは一番手前の Skill から始めます。本記事で扱うのは、この第1層です。
題材は前回と同じ、ISO/IEC 27001 Annex A 7.10 が求める「PC端末のUSBメモリ利用制限」という統制（以下、USBメモリ統制）を使います。この統制を検証する Audit Task を担当する監査人・Aさんの仕事の流れを、Now Assist のある場合とない場合で比べてみましょう。
なお以下では、第2章で挙げた4動作を、Aさんが実際に出会う順番 ― 計画・着手・報告 ― に並べ替えて見ていきます。
3-1. 監査計画をつくる ―「分析する」を支援する
Aさんの1年は、監査計画の策定に向けた、ある問いから始まります ―「今年、USBメモリ統制のテスト範囲は去年のままでよいのか」。この問いに答えるためには、リスクや過去の監査結果、統制の運用状況などを分析する必要があります。その分析を支えるのが、標準スキルです。例えば、次のような場面で活用できます。
- 規格・規制が改訂されたか ― 規制アラート（Regulatory Alert）の要約が、改訂の要点を短時間で示します
- その改訂は、どの統制に効くのか ― 関連する Citation・Control Objective・Control の推奨が、影響範囲を洗い出す入口になります。Annex A 7.10 の要求が変われば、USBメモリ統制と、それを検証する Audit Task にまで影響が及びます（第2回で扱った論点です）
- 統制が重複して肥大化していないか ― 類似 Control Objective の推奨や、共通 Control Objective の作成支援が、フレームワーク並行対応で増えがちな統制の棚卸しを助けます
- リスク評価の結果はスコープに効くか ― リスク評価サマリーが評価結果の要点を示し、それをそのままスコーピングの入力にできます。第2回で挙げた「リスク評価の最新結果が計画に反映されない」という課題への、直接の答えです
これらの分析を実際に手がけるのは、多くの場合コンプライアンス部門（第2線）です。それでもAさんに関係があるのは、Compliance と Audit が同じ統制データを共有しているから。第2線が整理した結果が、そのままAさんのスコーピングの入力になります ― 前回述べた「統合」の価値が、AI活用の場面でも効いてくる、ということです。
3-2. 監査に着手する ―「読む」を支援する
スコープが固まったら、次は対象の「現在地」を把握する段階です。
Aさんの朝は、まず情報を読み解くことから始まります。USBメモリ統制に紐づく過去のIssue（前年度には、一部部門で例外承認の記録漏れが指摘されていました）、その是正状況、直近の自己申告（Attestation）の回答、そしてリスク評価の結果 ― こうした情報を確認しながら、監査対象の状況を整理していきます。
Now Assist がなければ、関連するレコードを一つひとつ開き、活動履歴をさかのぼりながら文脈を組み立てる必要があり、この作業だけで午前中が終わってしまうことも珍しくありません。
Now Assist for IRM には、このようなレコードを要約する Summarization 機能が標準で用意されています。Aさんは数分で、「この統制の現在地」 ― 過去にどのような指摘があり、是正はどこまで進み、現在のリスクはどのように評価されているのか ― を把握できます。
その結果、「今回の監査ではどこを重点的に検証すべきか」という仮説を早い段階で立てられるようになります。
3-3. 結果をまとめる ―「書く」を支援する
各種監査手続きを実施し、フィールドワークを終えたAさんを待っているのは、書く仕事です。USBメモリ統制のテストで「例外承認の記録が3件欠落していた」ことを検出したとしましょう。テスト結果を調書として文章化し、検出した事実を所見（Observation）として整理し、是正を要するものは Issue として起票する ― 監査の品質を左右する重要な文書ですが、Now Assist がなければ、いずれも白紙から書き起こすことになります。時間もかかり、書き手による品質のばらつきも生じがちです。
本記事執筆時点で、Now Assist for IRM の標準スキルは要約と推奨を中心に構成されています。第1線・第2線のリスク・コンプライアンス業務を広くカバーする設計です。では、監査固有の文書 ― 監査サマリーや所見 ― の生成はどうか。ここはSkill Kit による拡張が想定されている領域です。Now Assist にはスキルを自作する仕組み（Skill Kit）があり、対象テーブル（たとえば Engagement）と、プロンプト ― 役割・文脈・指示・出力形式 ― を定義すれば、自社スキルとして組み込めます。実際、Engagement のフォームにボタンを置き、紐づく Issue などの情報から監査サマリーを生成して Engagement レコードに挿入するという実例が、ServiceNow の Community で公開されています（※1）。Aさんの仕事は「白紙に書く」ことから、「ドラフトを検証し、監査人としての評価を加えて仕上げる」ことに変わります。
ここまで紹介してきたNow Assist for IRMの主なスキルを、次に一覧として整理します。
| 支援する監査人の動作 | スキル | 提供形態 | 何をするか／監査業務での使いどころ |
| 分析する | 規制アラート要約 | 標準 | 規制・規格の改訂情報を要約。影響把握の初動を支援 |
| 規制アラートに対する Citation・Control Objective・Control の推奨 | 標準 | 改訂が影響する統制の洗い出しの入口。監査スコープの見直しに接続する | |
| 類似 Control Objective の推奨・共通 Control Objective の作成 | 標準 | 統制目標の合理化。フレームワーク並行対応で重複した統制の棚卸しに活用 | |
| 読む | Issue 要約 | 標準 | Issue の説明文・活動ログ・是正タスクを解析して要約。過去指摘の経緯把握を短縮 |
| リスク評価サマリー生成 | 標準 | リスク評価の提出時に評価者を支援。監査対象のリスク文脈の把握に活用 | |
| リスクイベント要約 | 標準 | 複数の担当者が関与したリスクイベントの経緯・要点を要約。引き継ぎ・承認を効率化 | |
| 書く | 監査サマリー等の生成 | カスタム （※1） |
Skill Kit で構築。Engagement に紐づく Issue 等から監査サマリーを生成する実例が Community で公開 |
| 判断する | ―（AIに委ねない） | ― | 有効性の評価・重要度の判定・報告内容の確定は監査人が担う |
※ 本表の「動作」は、スキル自体の動作（要約・生成など）ではなく、監査人のどの動作を支援するかで分類している。また本記事執筆時点の Now Assist for IRM の提供内容に基づく。このほか Agentic AI の提供も始まっています。Risk Identification Agent、Issue Submission Agent といったエージェントは第4回、それらを連結した Agentic Workflow は第5回で扱います。スキルはリリースごとに拡充されるため、最新は公式ドキュメント・ServiceNow Store をご確認ください。
改めて強調しておきたいのは、これらのスキルがすべて前回整えたデータの鎖の上で動いているという点です。Issue の要約が的確なのは、Issue が Control と Entity に紐づき、是正タスクまで一気通貫で記録されているから。監査サマリーのドラフトに文脈があるのは、Audit Task が Engagement・Control・Evidence とつながっているから。AIの出力の質は、データ基盤の質で決まります。基盤づくりを先に扱った本連載の順序は、そのままAI導入の順序でもあるのです。
※1：カスタムスキルの構築について
Now Assist のスキル作成機能（Skill Kit）では、対象テーブル（例：Engagement）と入力データ、プロンプト（役割・文脈・指示・出力形式）を定義することで、自社業務に合わせたスキルをローコードで構築できます。本文で触れた監査サマリー生成の実例を含む解説は、ServiceNow Community の Speed Learning 記事で公開されています。
Build your Gen AI and Agentic AI skills with Now Assist for IRM speed learning（ServiceNow Community）
より体系的に学びたい方には、ServiceNow University の研修「Now Assist for Integrated Risk Management (IRM) Implementer」もあります。なお Now Assist の利用にはライセンスの前提があります。詳細は担当営業へお問い合わせください。
04. 実装の実践 ― 標準スキルを「監査人の視点」に合わせる
本章は、実装を担当される方向けの内容です。「どこまで自社に合わせられるのか」の答えを先に知りたい方は、章末のまとめまで読み飛ばしていただいても構いません。
4-1. なぜ「視点」の調整が必要か
ここまでServiceNow OOTB（OOTB：Out-of-the-Box。標準提供）のスキルを紹介してきましたが、実装の現場ではもう一歩踏み込むことになります。というのも、OOTBスキルのプロンプトはIRM業務全般を想定した汎用的な視点で設計されているからです。
標準の要約系スキルがどう組み立てられているかは、Skill Kit でスキルを開けば確認できます。プロンプトの構成は、おおよそ次のようなものです（※2）。
標準の要約スキル ― プロンプトの構成（要旨）
- 入力：レコードの概要・説明・優先度・状態・活動ログ
- 出力：「①何が起きたか ②対応として何が行われたか ③解決したか」の3セクションに整理し、固定の JSON 形式で返す
- 制約：与えられた入力のみに基づくこと／確信が持てない項目は「N/A」とすること
注目したいのは出力の構成です。「何が起きたか・どう対応したか・解決したか」― これはレコードを処理し、解決する担当者の視点にほかなりません。IRM のレコード管理業務全般に広く効くよう、意図的に汎用的な視点が採られています。一方、監査人が同じ Issue を読むときに知りたいのは違います ― どの統制・監査対象に関わる不備か、是正は期日どおりに進んでいるか、過去の指摘との再発関係はあるか。標準スキルが不十分なのではなく、業務ごとに求められる視点が違う。だからこそ ServiceNow は、この視点を自社の業務に合わせて調整する仕組みを用意しています。
同時に、このプロンプトには書き換えの際も維持すべき「良い作法」が組み込まれている点も見逃せません。「与えられた入力のみに基づいて要約せよ」（グラウンディング）、「確信が持てない場合は N/A を返せ」（ハルシネーション抑止）、そして出力を固定の JSON 形式に限定する指示（後続処理の安定化）。視点は監査向けに書き換え、これらのガードレールは残す ― これがプロンプト調整の基本方針になります。
※2：プロンプトの構成について
上記は Now Assist Skill Kit の画面で確認できる標準の要約スキルの構成を、要旨としてまとめたものです。スキル名・プロンプトの内容は、リリースおよび構成されている LLM プロバイダーにより異なります。GRC 領域における要約スキルの設計・運用の考え方は、次の記事でも解説されています。
Now Assist summarization in GRC: How to make it part of your risk program（ServiceNow Community）
4-2. 調整の三つの選択肢
「視点が合わない」と感じたとき、取れる手は一つではありません。手間の軽い順に3つあります。
| 選択肢 | できること | 向いている場面 |
| ① 記録の中で手直しする （Now Assist コンテキストメニュー） |
生成された要約を、レコードを離れずに「もっと短く」「もっと硬い表現で」といった形で調整する | OOTBのままで概ね足りており、担当者ごとの好みを吸収したい場合 |
| ② 複製してプロンプトを書き換える | スキルを複製し、複製版のプロンプト（役割・観点・制約）を監査人の視点に差し替える | 対象テーブルも出力先も今のままでよいが、視点そのものを変えたい場合 ― 監査部門で最も出番が多い |
| ③ 新規カスタムスキルを構築する （Skill Kit） |
対象テーブル・入力・配置先を新たに定義して、業務専用のスキルを作る | 標準スキルが扱っていないレコードを対象にしたい場合（4-3節で扱います） |
監査部門の実装で中心になるのは②です。手順の骨子は次のとおりです（※3）。
- Now Assist Admin コンソールで対象スキルを複製（クローン）する ― 複製は Skill Kit 側からではなく Admin コンソール側から始めます
- Now Assist Skill Kit で複製版のプロンプトを編集する ― 複製直後のプロンプトは OOTB と同じ内容なので、ここで監査人の視点に書き換えます
- 実レコードでテストし、公開（Publish）する
- Now Assist Admin で複製版を有効化し、元の OOTB 版を無効化する
②で編集できるのはプロンプトと LLM プロバイダーのみです。入力・出力・配置先（ボタンの場所など）まで変えたくなった時点で、それは③の領域になります。コストの面では、複製・変更したスキルも元の OOTB 版と同じ量の assists（生成AI機能を呼び出した際に計上される消費単位）を使うため、追加の assist 消費なしに「視点」だけを差し替えられる ― ここが②の使い勝手の良さです。
なお、日本の監査部門で使う以上、出力言語も避けて通れない論点です。プロンプトに出力言語を明示できることは、②の実務上のメリットの一つでもあります。ただし日本語出力の品質はリリースおよび構成されている LLM プロバイダーによって差が出るため、展開前に検証環境で必ず確認してください。
※3：手順・画面名について
スキルの複製・プロンプト編集の画面構成や手順名は、Now Assist Skill Kit のバージョンにより異なります。実装時は、お使いのリリースに対応する公式ドキュメント、および ServiceNow Community の「Now Assist Skill Kit (NASK) FAQ」をご確認ください。
では、Issue 要約を監査人視点に書き換えると、プロンプトはどうなるか。あくまで一例ですが、骨格は次のようなものになります。
プロンプト改良の例（Issue 要約 → 監査人視点）
|
役割：あなたは内部監査部門の監査実施者です。以下の Issue を、監査調書に記載する前提で要約してください。 含める観点：(1) 関連する統制（Control）と監査対象、(2) 不備の内容と発生原因、(3) 是正タスクの進捗と期日超過の有無、(4) 過去の類似指摘・再発の有無。 制約：記録された事実のみを記載し、統制の有効性の評価や結論は含めないこと。出力は日本語で、監査調書に転記できる簡潔な箇条書きとすること。原文の安全策（与えられた入力のみを使用する・確信が持てない項目は「N/A」とする・固定の出力形式を守る）は維持すること。 |
最後の制約に目を留めてください。「評価や結論は含めない」― これは第5章で述べる Human in the Loop を、プロンプトのレベルで担保する仕掛けです。AIには事実の整理までを任せ、評価は監査人が行う。この線引きを運用ルールに書くだけでなく、プロンプトそのものに書き込んでおく。監査領域での実装では、ここが効きます。
最後に、実装で足をすくわれやすいポイントを挙げておきます。いずれも、プロジェクトで実際に議論になる論点です。
| 落とし穴 | 回避策 |
| OOTBスキルを直接変更しようとする／変更履歴が残らない | 必ず複製版を編集する。元のOOTB版が無傷で残るため、アップグレード時の安全性と切り戻し先が確保される。変更は更新セットで管理する |
| 複製版を作ったまま放置し、リリースごとに改良される OOTB 版の恩恵を受けられなくなる | 複製の目的はあくまで「視点の差し替え」。アップグレード時に OOTB 版のプロンプトとの差分を確認し、取り込むべき改良がないかを定期的にレビューする運用を、導入時に決めておく |
| 汎用視点の要約をそのまま監査に使い、「読んでも監査の役に立たない」と現場が使わなくなる | 展開前に監査部門とプロンプトをレビューし、ペルソナ（監査実施者）・含める観点・除外事項（評価・結論）を明文化しておく |
| 短い正常系レコードだけでテストして公開してしまう | 活動ログが長い Issue、是正遅延のある Issue、是正タスクが複数ある Issue など、監査で実際に遭遇する代表パターンでテストしてから公開する |
| 複製版を有効化したのに旧OOTBの応答が返り続ける | 複製を Now Assist Admin 側から開始したか、複製版が有効化・OOTB版が無効化されているかを確認する（既知のつまずきポイント） |
4-3. 独自スキルをどこに作るか ― 「突き合わせる」という発想
ここからは選択肢③、つまり新規構築の話です。何を作るべきか ― そのヒントは、第3章を時間軸で並べ直したときに見えた空白にあります。標準スキルが手厚いのは計画と報告の両端であり、監査人が最も長い時間を過ごす「実施」フェーズ ― とりわけ証言や記録を突き合わせる工程そのものには、標準スキルが用意されていません。
では実施の現場で何を作るか。ここで一つ、はっきりさせておくべき問いがあります。「インタビューの議事録を要約するだけなら、Web会議ツールの自動要約機能でもできるのではないか」 ― そのとおりです。文字起こしを短くまとめる作業に限れば、会議ツールのほうが得意でしょう。音声も話者情報も、そちらが持っているのですから。
会議ツールが持っていないのは、その発言を突き合わせる相手です。統制の定義、前年度の指摘、担当者自身が Attestation で回答した内容 ― 監査人が「その発言は本当か」を確かめるために必要な記録は、すべてIRMの中にあります。第2章で述べたとおり、AIが辿れるのはレコードとレコードのつながりだけ。だからこそ、プラットフォーム上で作るスキルの価値は「要約」ではなく「突合」に出ます。この視点で監査業務を見直すと、独自スキルの候補例（※4）が見えてきます。
| 候補例 | 何と何を突き合わせるか | 監査人に返すもの |
| 証言と記録の突合 | インタビューでの発言 × 統制の定義・Attestation の回答 | 「担当者はOA用PC全台に適用と説明。一方、直近の Attestation では開発機を対象外と回答」といった食い違いの候補。追加で確認すべき点のリスト |
| 再発性の確認 | 今回検出した事実 × 同一 Control・同一 Entity の過去 Issue | 過去に類似の指摘があったか、その是正が有効だったか。再発の可能性を判断するための材料 |
| 是正フォローアップの横断 | Engagement に紐づく全 Issue × 期日・是正タスク・証跡の有無 | 期日を超過しているもの、証跡なしでクローズされているものの一覧。フォローアップ監査の着眼点 |
3つを並べると、作りの重さに差があることも分かります。1つ目は単一レコードの文章を読ませる部分が中心で、標準の要約スキルに近い構造です。2つ目・3つ目は複数のレコードをまたいで情報を集める必要があり、そのぶん設計は重くなります。まずは軽いところから作り、効果を確かめてから広げる ― 監査部門でのAI活用は、この順序をお勧めします。
そして線引きは、どの候補でも変わりません。スキルが返すのは「食い違いの候補」「再発の可能性」「着眼点」であって、「統制が有効に運用されていない」という結論ではない。断定させず候補として出させ、それを所見にするかどうかは監査人が決めます。4-2節で見たプロンプトの制約 ―「評価や結論は含めない」― が、ここでも効いてきます。
ただ、この方向に進むと一つ限界にぶつかります。突き合わせる対象が増えるほど、監査人が押すボタンの数も増えていく。証言を突き合わせるボタン、再発を確認するボタン、フォローアップを洗い出すボタン ― どれも人が起点になっている以上、支援の総量は「人が押した回数」で天井を打ちます。この天井を越えるのが、次回扱うAIエージェントです。
※4：本節の位置づけについて
本節で挙げた3つの候補は、標準機能の紹介ではなく、Skill Kit を用いた実装アプローチの一例です。対象とするテーブルやデータ構造（インタビュー記録をどこに保持するか等）は、貴社の運用に合わせた設計が前提となります。具体的な構築手順は、※1に挙げた Community および ServiceNow University の研修コンテンツをご参照ください。
04章のまとめ ―「どこまで自社に合わせられるのか」
本章冒頭の問いへの答えです。標準スキルは、そのまま使うことも、複製して監査人の視点に差し替えることも、対象そのものを新たに定義して独自スキルを作ることもできます。監査部門で中心になるのは中間の「複製して視点を差し替える」であり、その際もグラウンディング・ハルシネーション抑止・出力形式といった標準の安全策は残す ― これが調整の基本方針です。
05. 「安心して使える」根拠 ― AIガバナンスと監査の独立性
ここまで読んで、監査実務に携わる方ほど、こう思われたのではないでしょうか。「便利なのは分かった。しかし監査という業務で、AIの出力を信じてよいのか」。この問いに正面から答えられることが、監査領域でAIを使う条件です。押さえるべき点は3つあります。
第一に、アクセス制御。Now Assist の出力は、プラットフォームのロールベースのアクセス制御に従う設計です。監査人が参照権限を持たないデータが、AIの応答に含まれない設計になっています ― 第2回で設計した権限境界（監査人・被監査側・経営層）が、AI利用時にもそのまま生きます。裏を返せば、ロール設計が整理されないままAIを有効化すべきではない。ここでも準備が先です。
第二に、Human in the Loop。本記事で紹介した支援は、すべて「ドラフト・要約・推奨」であり、確定は人が行います。所見として何を書くか、不備と評価するか、経営に何を報告するか ― 判断と承認は必ず監査人に残す。これは運用ルールであると同時に、監査の独立性の要件そのものです。前回「Attestation（自己申告）と Audit Task（独立検証）を混同してはならない」と述べたのと同じ構図で、「AIのドラフト」と「監査人の結論」も、明確に区別して扱うべきでしょう。
第三に、追跡可能性。AIの支援を受けた作業も、プラットフォーム上のレコードとして記録に残ります。どの情報をもとに、どんなドラフトが作られ、監査人がどう修正・承認したか ― この履歴が残ることは、監査調書の追跡性という監査固有の要求と整合します。「AIを使ったから調書の根拠が曖昧になる」のではなく、むしろ使った過程ごと記録に残る。これが、プラットフォームに組み込まれたAIの強みです。
なお、組織としてAI利用を進める際は、社内のAI利用ガイドラインの整備を導入の前提条件とすることをお勧めします。ISO/IEC 42001（AIマネジメントシステム）や経済産業省・総務省の「AI事業者ガイドライン」といった枠組みは、監査部門がAI活用の統制を説明する際の共通言語になります ― そして実は、この「AI自体をどう統制するか」という論点も、本連載の最終回の射程に入ってきます。
第3回のまとめ
- 監査業務は「読む・書く・分析する・判断する」の4動作に分解できる。前3者がAIの支援対象であり、監査人の時間の大半を占めているのもこの3動作である
- Now Assist for IRM は、普段のIRM画面の中で「読む・書く・分析する」を支援する。標準スキルは要約・推奨が中心。調整の選択肢は、記録内での手直し・複製してプロンプトを書き換える・新規構築の3段階があり、監査部門では「複製して視点を差し替える」が中心になる ― AIの出力の質は、データ基盤の質とプロンプトの視点で決まる
- 判断と承認は監査人に残す（Human in the Loop）。アクセス制御・人の確定・追跡可能性の3点を押さえることで、AIは監査の独立性を損なわずに、判断の時間を生み出すパートナーになる
次回予告 ・ 第4回
AIエージェントが監査を自律実行する
今回扱ったのは、人がボタンを押すたびに1つの動作を実行する第1層 ― Skill でした。次回は第2層へ進みます。目標を与えると、複数のスキルやツールを組み合わせて一連のタスクを自律的に進める「AIエージェント」の世界です。監査所見作成エージェントを例に、Skill と Agent の違い、AI Agent Studio による構築、そして自律実行の時代に人の関所（承認ゲート）をどこに置くかを、具体的に見ていきます。
