年度末が近づいたある日、内部監査室の共有フォルダを開くと、「調書_最終」「調書_最終_修正」「調書_最終_修正_部長コメント反映」というファイルが並んでいます。どれが最新なのかを確かめるために、更新日時と中身を 1 つずつ見比べる作業が始まります。発見事項の是正状況は別の Excel にまとめられ、監査計画は部長のパソコンの中にあります。
「そろそろ専用のツールを入れよう」と決まり、3 社のデモを見ました。どれも画面はきれいで、機能一覧は似ています。営業担当者はみな「内部監査の業務はすべてこれ 1 つでまかなえます」と言います。けれども、どのツールが自社に合うのかを判断する基準を、室内の誰も持っていませんでした。これは、ツール導入を検討する多くの内部監査部門に共通する状況を組み立てた架空のモデルケースです。
内部監査ツールの選定がうまくいかない原因の多くは、製品の良し悪しではなく、「何を解決したいのか」が決まらないまま機能比較に入ってしまうことにあります。本記事では、特定の製品を比べるのではなく、ツールのタイプ分類、選定前に決めるべきこと、評価の観点と重み付けのシート、デモとトライアルの進め方までを順に解説します。
この記事の要点
- 内部監査ツールは「GRC 総合型」「監査管理特化型」「データ分析型」「汎用ツール組み合わせ型」の 4 タイプに分けて考えると比較しやすい
- 選定の出発点は機能一覧ではなく、現状の課題と「3 年後の監査部門の姿」。これが決まらないと総合型を過剰導入しやすい
- 評価は 8 つの観点に重みを付けたシートで行い、デモは自社の業務シナリオで実演してもらう
- ツール自体のセキュリティと、データを取り出せるかは、監査部門だからこそ厳しく確認する
内部監査ツールとは——Excel と共有フォルダから専用ツールへ移った理由
内部監査ツールとは、監査計画、リスク評価、監査調書、発見事項、フォローアップといった内部監査の業務と記録を、1 つの仕組みで管理するためのソフトウェアの総称です。多くはクラウドサービスとして提供され、監査手続の実施記録やレビューの承認履歴を残せることが特徴です。
規制対応が「GRC」という発想を生んだ
専用ツールが広がった背景には、内部統制の制度化があります。米国では 2002 年に成立したサーベンス・オクスリー法（SOX 法）により、上場企業に財務報告に係る内部統制の評価が求められるようになりました。日本でも、金融商品取引法に基づく内部統制報告制度（J-SOX）が 2008 年 4 月 1 日以後に開始する事業年度から適用されています。統制の文書化、評価、不備の管理を大量に、しかも毎年繰り返す必要が生じたことで、それらを一元管理する仕組みへの需要が高まりました。
この流れの中で生まれたのが「GRC（ガバナンス・リスク・コンプライアンス）」という考え方です。リスク管理部門、コンプライアンス部門、内部監査部門がそれぞれ別々に持っていたリスクや統制の情報を 1 つの基盤に集め、重複をなくそうという発想です。GRC 総合型のツールは、この考え方を製品にしたものといえます。
基準も「技術の活用」を求めている
内部監査人協会（IIA）の「グローバル内部監査基準」（2025 年 1 月 9 日発効）は、基準 10.3「技術的資源」で、内部監査部門長が内部監査のプロセスを支える技術の確保に努め、使っている技術を定期的に評価して改善の機会を追求することを求めています。新しい技術を導入する際には、監査人への研修を行い、情報システム部門や情報セキュリティ部門と連携することも求められています。
つまり、ツールの選定と導入は「便利だから」だけでなく、基準に照らして説明できる活動です。逆にいえば、選定の過程や評価の根拠を記録に残しておくことが、後の品質評価でも役に立ちます。基準全体の変化は グローバル内部監査基準の改訂ポイント で解説しています。
4 つのタイプ——GRC 総合型・特化型・データ分析型・組み合わせ型
市場にある内部監査関連のツールは、製品名や機能一覧で比べると違いが見えにくくなります。まず「どの範囲の業務を、誰と共有するためのツールか」で 4 つのタイプに分けると、比較の軸がはっきりします。
| タイプ | 主な対象範囲 | 向いている組織 | 注意点 |
|---|---|---|---|
| GRC 総合型 | 内部監査に加え、リスク管理、コンプライアンス、J-SOX 評価、規程管理などを 1 つの基盤で扱う | 第 2 ラインの部門が整っており、全社でリスク情報を共有する方針が決まっている組織 | 他部門の合意と運用設計が前提。導入と定着に時間と費用がかかる |
| 監査管理特化型 | 監査計画、調書、レビュー、発見事項、フォローアップなど内部監査の業務に絞る | 監査部門単独で導入を決めたい組織、調書管理が主な課題の組織 | 他部門とのリスク情報の共有は限定的。将来の連携方法を確認しておく |
| データ分析型 | 業務データを取り込み、全件検査や異常の抽出、継続的モニタリングを行う | データ分析監査や継続的監査を本格化したい組織 | 調書やフォローアップの管理は別の仕組みが必要。分析人材の確保が前提 |
| 汎用ツール組み合わせ型 | 表計算、文書共有、タスク管理、BI など社内で使っている汎用ツールを組み合わせる | 小規模な監査部門、まず運用を固めたい組織 | 承認履歴や版管理を自分で設計する必要がある。担当者の異動で崩れやすい |
総合型が「大は小を兼ねる」とは限らない理由
機能が多い総合型を選べば安心だと考えがちですが、ここに最初の落とし穴があります。GRC 総合型の価値は、複数の部門が同じリスクや統制の情報を使うことで生まれます。リスク管理部門やコンプライアンス部門がまだ独自の Excel で管理していて、共通化の合意もない状態で導入すると、内部監査部門だけが使う「高価な調書管理ツール」になりかねません。
3 つのラインの役割分担が整理されているかどうかが、総合型を選ぶかどうかの分かれ目です。考え方は 3 ラインモデルとは？ を参照してください。
組み合わせ型は「つなぎ」ではなく選択肢の 1 つ
一方、汎用ツールの組み合わせは、専用ツールを買えない組織の妥協策と見られがちです。しかし、監査部門の人数が少なく、調書の様式やレビューの流れがまだ固まっていない段階では、むしろ合理的な選択です。運用を固めてから専用ツールに移行すれば、要件がはっきりした状態で選定できます。その場合でも、承認の記録とファイルの版管理は、後から監査調書として説明できる形で設計しておく必要があります。
選定の前に決めること——課題の棚卸しと要件定義
ツールの選定で最初にすべきことは、デモを見ることではありません。現状の課題を棚卸しし、それをツールへの要件に言い換えることです。この順番を逆にすると、デモで見た便利そうな機能に引きずられ、本当の課題が解決されないまま導入が進みます。
課題から要件への変換の記入例
以下は、冒頭のモデルケースを想定した課題の棚卸しと要件の記入例です。要件には「必須（Must）」と「あると望ましい（Want）」の区分を付けます。
| 現状の課題 | 原因 | ツールへの要件 | 区分 |
|---|---|---|---|
| 調書の最新版がわからない | ファイル名で版管理している | 調書の版管理と変更履歴の自動記録 | 必須 |
| レビューの証跡が残らない | 口頭やメールでコメントしている | 調書ごとのレビューコメントと承認の記録 | 必須 |
| 是正状況の集計に時間がかかる | 部門にメールで確認し手作業で集計 | 被監査部門が自ら状況を更新できる機能と期限超過の通知 | 必須 |
| 監査計画と実績が結びつかない | 計画は別ファイルで管理 | 計画・工数・発見事項の紐づけ | 必須 |
| 委員会報告の資料作成が重い | 毎回スライドを手作業で作成 | 集計画面の出力、または BI への連携 | あると望ましい |
| 全件検査をしたい | データ抽出が IT 部門頼み | 業務データの取り込みと分析 | あると望ましい（将来） |
| 生成 AI で報告書の下書きを作りたい | 報告書作成に時間がかかる | 生成 AI 機能と、そのデータの扱いの明示 | あると望ましい |
「3 年後の姿」を 1 行で書く
要件を並べると、すべてを必須にしたくなります。そこで役立つのが、「3 年後に監査部門がどうなっていたいか」を 1 行で書くことです。たとえば「調書とフォローアップを一元管理し、重要な指摘の状況を委員会にいつでも示せる」であれば、特化型で十分かもしれません。「リスク管理部門と共通のリスク台帳を使い、監査計画をリスク評価と連動させる」であれば、総合型を検討する理由があります。この 1 行が、機能の取捨選択で迷ったときの判断基準になります。
関係者を最初に巻き込む
選定の初期段階で、情報システム部門と情報セキュリティ部門に相談しておきます。認証の方式、データの保管場所、既存システムとの連携など、後から問題になる論点を早めに洗い出せます。総合型を検討するなら、リスク管理部門やコンプライアンス部門の責任者との合意も欠かせません。
評価の 8 観点と重み付け評価シート
要件が決まったら、候補のツールを評価します。評価は、観点ごとに重みを付けた評価シートで行うと、声の大きい人の好みで決まることを防げます。
8 つの評価観点
| 観点 | 確認すること |
|---|---|
| 1. 業務適合 | 自社の監査手順（計画、調書、レビュー、報告、フォローアップ）を無理なく表現できるか |
| 2. 使いやすさ | 監査人と被監査部門の双方が、研修なしでも基本操作をできるか |
| 3. 証跡と統制 | 変更履歴、レビューと承認の記録、権限による操作制限があるか |
| 4. セキュリティ | 認証方式、暗号化、アクセスログ、第三者による保証報告書の有無 |
| 5. データの可搬性 | 調書や発見事項をいつでも一括で取り出せるか。契約終了時の扱い |
| 6. 連携と拡張 | BI、データ分析、社内の認証基盤、既存システムと連携できるか |
| 7. 支援体制 | 日本語での問い合わせ、導入支援、利用者コミュニティ、更新の頻度 |
| 8. 総保有コスト | 利用料、初期設定、データ移行、社内の運用工数、将来の拡張費用 |
評価シートの記入例
以下は、監査管理特化型を中心に比較する場合の評価シートの記入例です。候補名は伏せ、得点は架空のモデルケースです。重みは合計 100 とし、各観点を 5 段階で採点して、重み × 得点 ÷ 5 で加重点を出します。
| 観点 | 重み | 候補 A（得点） | 候補 B（得点） | 候補 C（得点） | 評価の根拠（メモ） |
|---|---|---|---|---|---|
| 業務適合 | 20 | 4 | 5 | 3 | B は自社の調書様式をそのまま再現できた |
| 使いやすさ | 15 | 5 | 3 | 4 | B は被監査部門の画面が複雑 |
| 証跡と統制 | 15 | 4 | 4 | 3 | C は承認の取り消し履歴が残らない |
| セキュリティ | 15 | 4 | 4 | 4 | 3 社とも保証報告書を提出済み |
| データの可搬性 | 10 | 3 | 5 | 4 | A は添付ファイルの一括出力に制限 |
| 連携と拡張 | 10 | 3 | 4 | 5 | C は BI 連携が標準機能 |
| 支援体制 | 5 | 4 | 3 | 4 | — |
| 総保有コスト | 10 | 4 | 3 | 4 | B は初期設定の工数が大きい |
| 加重点合計 | 100 | 79 | 80 | 75 | 差が小さいため、トライアルで最終判断 |
重みは、課題の棚卸しで「必須」とした要件に関わる観点を大きくします。重要なのは、重みをデモを見る前に決めておくことです。デモの後に重みを決めると、気に入った候補に有利な配分に無意識に寄っていきます。また、加重点の差が小さい場合は、点数だけで決めずにトライアルで確かめるべきだというのも、シートを作ることで見えてくる発見です。
監査部門だからこそ厳しく見る 2 つの観点
8 つの観点のうち、特に内部監査部門が厳しく確認すべきなのが「セキュリティ」と「データの可搬性」です。監査調書には、不正の疑い、個人情報、未公表の経営情報など、社内で最も機微な情報が集まります。クラウドサービスであれば、SOC 2 などの第三者による保証報告書や、政府情報システムのためのセキュリティ評価制度（ISMAP）への登録状況が判断材料になります。保証報告書の読み方は ITGC（IT 全般統制）とは？クラウド/SaaS 時代の評価ポイントと SOC 報告書の見方 で解説しています。
データの可搬性は見落とされがちです。監査調書には社内規程などで定めた保存期間があります。ツールを乗り換えたり契約を終了したりしたときに、過去の調書を読める形で取り出せなければ、保存ルールを守れなくなります。調書の保管ルールは 監査調書の書き方と保管ルール を参照してください。
生成 AI 機能の評価
最近は、報告書の下書きや調書の要約など、生成 AI の機能を備えたツールが増えています。評価の際は、機能の便利さより先に、入力したデータが AI の学習に使われるか、処理がどの地域で行われるか、出力の根拠をたどれるかを確認します。論点は 生成 AI で内部監査はどう変わる？ と 内部監査の AI 活用の落とし穴 で詳しく扱っています。
デモとトライアルの進め方——自社のシナリオで試す
ベンダーのデモは、製品の強みが最もよく見えるように組み立てられています。それ自体は当然のことですが、自社の業務に合うかどうかは、自社のシナリオで試さなければわかりません。
デモ依頼のシナリオ例
デモを依頼する際は、次のような業務シナリオを事前に渡し、その流れに沿って実演してもらいます。全候補に同じシナリオを渡すことで、比較の条件がそろいます。
| No. | シナリオ | 確認したいこと |
|---|---|---|
| 1 | 年間計画を登録し、監査 1 件を担当者に割り当てる | 計画と個別監査、工数の紐づけ |
| 2 | 調書を作成し、上長がコメントを付けて差し戻す | レビューの記録、版管理 |
| 3 | 発見事項を登録し、被監査部門が改善計画を入力する | 社外（部門外）利用者の操作性と権限 |
| 4 | 是正期限を過ぎた発見事項を抽出し、通知する | 期限管理、エスカレーション |
| 5 | 委員会向けに是正状況の集計を出力する | 集計の柔軟性、BI への連携 |
| 6 | 全データを一括で出力する | データの可搬性、出力形式 |
| 7 | 退職した監査人のアカウントを無効化し、履歴を確認する | アクセス管理、操作ログ |
シナリオ 6 と 7 は、デモでは省略されがちですが、監査部門にとって重要な確認点です。自らが監査で他部門に求めているアクセス管理やデータ保全を、自部門のツールでも満たしているかを確かめる機会になります。
トライアルのチェックリスト
候補を 1〜2 社に絞ったら、実際の業務の一部を使ったトライアルを行います。
- 実際に終わった監査 1 件分の調書を登録し、再現できるか確かめた
- 監査人だけでなく、被監査部門の担当者にも操作してもらった
- 権限の設定を変え、見えてはいけない情報が見えないことを確かめた
- データの一括出力を行い、出力したファイルを別の環境で開けることを確かめた
- 問い合わせを 1 回以上行い、回答の速さと質を確かめた
- 情報セキュリティ部門にセキュリティ関連資料の確認を依頼した
- トライアルの結果を評価シートに反映し、得点の根拠を記録した
導入と定着のロードマップ
ツールは導入した時点ではなく、使われ続けて初めて価値を生みます。導入は段階的に進め、各段階で「使われているか」を確かめながら範囲を広げます。
| 段階 | 主な作業 | 定着の目安 |
|---|---|---|
| 1. 準備 | 調書様式・発見事項の項目・権限の設計、マスタの整備 | 様式と項目が文書化され、部門内で合意されている |
| 2. 試行 | 監査 1〜2 件で試用し、運用ルールを修正 | 担当者が Excel に戻らずに作業を終えられた |
| 3. 本格運用 | 全監査への適用、被監査部門への展開、過去データの移行 | 発見事項の更新が被監査部門の手で行われている |
| 4. 拡張 | BI 連携、データ分析、他部門との情報共有 | 委員会報告がツールの集計から作られている |
総保有コストは「社内工数」まで含める
費用を比べるとき、利用料だけを見ると判断を誤ります。初期設定、データ移行、社内の研修、運用ルールの整備、そして担当者の異動時の引き継ぎまで含めた「総保有コスト」で比べます。特に、設定の自由度が高いツールほど、初期設定に社内の工数がかかる傾向があります。
導入後の活用範囲を広げる方向としては、内部監査に BI ダッシュボードを導入する方法 や 継続的監査・継続的モニタリングの始め方 が参考になります。
よくある失敗と対策
失敗 1: 機能一覧の「○」の数で選ぶ。 機能があることと、自社の業務で使えることは別です。課題から導いた要件と、自社のシナリオでのデモで評価します。
失敗 2: 監査部門だけで総合型を導入する。 他部門の合意がないまま総合型を入れると、機能の大半が使われません。総合型を選ぶなら、リスク管理部門などとの共同プロジェクトとして進めます。
失敗 3: 現行の Excel 様式をそのまま再現しようとする。 既存の様式を 1 対 1 で移すと、ツールの利点が生かされず、設定の手間だけが増えます。導入を機に、調書の項目やレビューの流れを見直します。
失敗 4: 被監査部門の使い勝手を確かめない。 是正状況を被監査部門が自ら更新する運用は、操作が難しいと定着しません。トライアルで必ず被監査部門の担当者に触ってもらいます。
失敗 5: 出口を考えずに契約する。 契約終了時のデータの返却方法と形式を確認しないまま導入すると、乗り換えが難しくなり、調書の保存ルールにも影響します。契約前に出力の方法と形式を確かめておきます。
よくある質問
Q. 監査部門が 2〜3 人でも専用ツールは必要ですか？
必ずしも必要ではありません。少人数の部門では、汎用ツールの組み合わせで版管理とレビューの記録を設計する方が、費用と手間のバランスがよい場合があります。まず運用を固め、監査の件数や被監査部門とのやり取りが増えた段階で専用ツールを検討するのも合理的な進め方です。
Q. J-SOX の評価ツールと内部監査ツールは分けるべきですか？
J-SOX 評価を内部監査部門が担っているかどうかで変わります。同じ部門が担い、統制の情報を監査計画にも使うのであれば、1 つのツールで扱える方が重複は減ります。別の部門が担っている場合は、統制やリスクの情報をどう共有するかを先に決めてから判断します。J-SOX の文書化については J-SOX 3 点セットの作り方 も参考になります。
Q. 選定にはどれくらいの期間をかけるべきですか？
組織の規模や候補の数によって大きく変わるため、一律の目安はありません。ただし、課題の棚卸しと要件定義、関係部門との調整、トライアルの 3 つは省略しない方が、導入後の手戻りは少なくなります。年度の途中で切り替えると調書が 2 つの仕組みに分かれるため、監査年度の区切りに合わせて本格運用を始める計画を立てるとよいでしょう。
Q. ベンダーの導入実績が多いツールを選べば安心ですか？
実績は判断材料の 1 つですが、それだけで自社に合うとは限りません。業種や規模、監査部門の体制が近い利用者の事例があるかを確認し、可能であれば利用者の話を聞く機会を設けてもらうとよいでしょう。最終的な判断は、自社の要件と評価シートの結果に基づいて行います。
まとめ
内部監査ツールの選定は、製品を比べる前に、自社の課題と 3 年後の姿を決めることから始まります。そのうえで、4 つのタイプから候補の範囲を絞り、8 つの観点に重みを付けた評価シートで比較し、自社のシナリオでデモとトライアルを行います。監査部門のツールだからこそ、セキュリティとデータの可搬性は他部門に求めるのと同じ厳しさで確かめてください。
次の一歩として、本記事の「課題から要件への変換」の表を使い、自部門の課題を 5 つ書き出してみてください。関連する記事として、内部監査に BI ダッシュボードを導入する方法、データ分析監査（CAAT）入門、生成 AI で内部監査はどう変わる？ も参考になります。監査業務の見直しや体制づくりのご相談は お問い合わせ からどうぞ。
参考資料
- The Institute of Internal Auditors「Global Internal Audit Standards」（2025 年 1 月 9 日発効）基準 10.3「Technological Resources」 https://www.theiia.org/en/standards/2024-standards/global-internal-audit-standards/
- 金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」
- 政府情報システムのためのセキュリティ評価制度（ISMAP） https://www.ismap.go.jp/
- AICPA「SOC 2 — SOC for Service Organizations: Trust Services Criteria」
- 一般社団法人日本内部監査協会 https://www.iiajapan.com/
