>
>
公開日
最終更新日
監査対応では、監査直前に資料を集めるのではなく、承認記録、アクセス権、システム変更、会計証憑を日常業務の中で証跡化する仕組みが成果を左右します。特にクラウドやSaaSが増えた企業では、Excel台帳の更新漏れ、退職者アカウントの残存、画面キャプチャの大量提出が監査工数を押し上げます。
この記事は、監査対応の全体像を整理したい情シス・経理・内部監査担当者と、IPO準備やJ-SOX対応を進める管理責任者が対象です。外部監査のPBCリスト対応から、監査証跡の設計、アカウント棚卸し、参照型監査、AI-OCRの使い分けまで、実務で判断できる基準を示します。
監査対応とは
監査対応とは、業務やシステムが社内規程、法令、契約、監査基準に沿って運用された事実を、客観的な資料と監査証跡で説明する一連の活動です。
本記事のポイント
監査対応は、依頼資料の提出だけでなく、質問への回答、サンプル抽出、例外の原因分析、是正状況の報告まで含みます。
証跡管理では、作業結果だけでなく、実施者、承認者、実施日時、対象、例外処理をひと続きで記録します。
改訂J-SOXでは、売上高だけで評価範囲を機械的に決めず、質的重要性を含めてリスクベースで判断します。
画面キャプチャの提出を減らし、監査ログや閲覧専用権限を使う参照型監査へ移行すると、収集作業を平準化できます。
監査対応と証跡の定義
証跡とは、誰が、いつ、何を、どの権限と承認に基づいて実行し、どの結果になったかを後から検証できる記録です。
証跡管理では、アクセスログや申請書を保存するだけでは足りません。申請番号、承認記録、作業チケット、設定変更ログ、テスト結果を相互にたどれる状態にします。この関連付けが「証跡化」であり、監査人は記録の有無に加えて、母集団の完全性、記録の作成元、保存中のアクセス制御も検証します。
内部監査と外部監査の相違点
内部監査と外部監査では、実施主体と目的が異なるため、同じ証跡を利用する場合でも質問の視点や提出形式が変わります。
比較項目 | 内部監査 | 外部監査 |
|---|---|---|
実施主体 | 社内の内部監査部門、監査役、監査委員会など | 監査法人、公認会計士、認証審査機関など |
主な目的 | リスク管理、業務改善、不正の予防、ITガバナンスの検証 | 財務諸表や内部統制の評価、法令・認証基準への適合性の検証 |
対象範囲 | 経営が定めた監査計画に基づく業務全般 | 監査契約、金融商品取引法、会社法、認証基準などで定めた範囲 |
主な成果物 | 内部監査報告書、改善提案、是正計画 | 監査報告書、内部統制監査報告書、審査報告書、指摘一覧 |
情シスの主な対応 | ログ分析、統制の自己点検、改善状況の報告 | 依頼資料の提出、サンプル証跡の提示、質疑回答、例外説明 |
内部監査が任意かどうかは企業の機関設計や適用制度で変わります。また、外部監査もすべての企業に一律で課されるわけではありません。自社に法定監査が適用される場合は法令上の範囲を起点とし、任意監査の場合は監査契約で対象と基準を確定します。
外部監査のPBCリスト対応
外部監査では、PBC（Prepared by Client）リスト、つまり監査対象企業が準備する依頼資料一覧を基準に、担当者、提出期限、対象期間、母集団、抽出サンプルを管理します。
依頼内容の整理：依頼番号ごとに対象統制、資料名、対象期間、形式、担当部門を記録します。
母集団の確定：全ユーザー、全変更申請、全仕訳など、サンプル抽出元となるデータの件数と抽出条件を固定します。
サンプル証跡の収集：監査人が指定した標本について、申請、承認、実行、確認の記録を一組にします。
質疑と例外の管理：追加質問、回答日、根拠資料、統制逸脱の原因、補完統制、是正期限を同じ台帳で追跡します。
依頼内容が曖昧な場合は、対象期間と母集団の定義を監査人と合意できれば収集に進み、合意できなければサンプル抽出を止めて範囲を再設定します。定義が異なるまま提出すると、資料の再作成や再抽出につながるためです。
▲ 内部監査と外部監査の特徴と役割の違い
改訂J-SOXと2025〜2026年の監査動向
2025年から2026年の監査対応では、改訂J-SOXのリスクベース評価、クラウド委託先の統制、AIを使ったデータ分析、継続的な監査が主要な論点です。
改訂J-SOXの適用時期と評価範囲
金融庁の改訂基準は、2024年4月1日以後に開始する事業年度から適用されており、2025年3月期以降の内部統制評価と監査に反映されています。
金融庁は、「財務報告に係る内部統制の評価及び監査の基準並びに実施基準の改訂について」で、評価範囲の決定において金額的重要性だけでなく、質的重要性を考慮する考え方を明確にしています。従来利用されてきた売上高のおおむね3分の2という基準は例示であり、それだけを機械的に適用して対象拠点を決める運用では、リスクの説明が不足します。
区分 | 制度上の位置付け | 情シス側の判断 |
|---|---|---|
経営者による内部統制評価 | 対象企業が実施する制度上の対応 | 対象システム、統制、評価手続、評価結果を記録します。 |
評価範囲の決定理由 | 金額面と質的リスクを踏まえて説明 | 重要拠点、重要業務、委託先、除外範囲の根拠を残します。 |
クラウド・SaaS統制 | サービスの利用自体を一律に義務化・禁止する規定ではない | 財務報告への影響がある場合に、アクセス管理や変更管理、委託先統制を評価します。 |
サイバーセキュリティ | 財務報告の信頼性に影響するリスクとして検討 | 攻撃シナリオが財務データや重要処理へ及ぼす影響を評価します。 |
クラウド利用やサイバー対策がすべての企業に同じ手続で義務付けられたわけではありません。クラウド障害や不正アクセスが財務報告へ影響するならIT全般統制の対象に含め、影響しないなら除外理由と代替管理を文書化する、というリスクベースの判断になります。
クラウド利用率と委託先管理
クラウド利用が一般化した現在は、自社の操作ログだけでなく、委託先が実施する変更、バックアップ、障害対応の統制も評価対象になり得ます。
総務省の「令和5年通信利用動向調査」は、クラウドサービスを一部でも利用する企業の割合を77.7％と集計しています。この数値は2023年時点の調査結果であり、現在の個社利用率を表すものではありませんが、監査対象が社内システムだけでは完結しにくい状況を示します。
財務報告に関係するSaaSを委託先へ依存している場合は、SOC報告書、契約上の責任分界、障害通知、再委託先、データ返却・削除条件を整理します。SOC報告書を取得できれば対象期間と補完的利用者統制を照合し、取得できなければ質問票、設定画面、契約書、運用実績を組み合わせて代替評価を設計します。
グローバル内部監査基準と継続的監査
内部監査は年次の適合確認だけでなく、経営目標、リスク、価値の創出と保全に結び付いた評価へ移行しています。
IIAはグローバル内部監査基準を2025年1月9日から適用しています。新基準への対応では、監査計画、品質評価、取締役会とのコミュニケーションに加え、データ分析を使って高リスク取引や権限変更を継続的に監視する体制が論点になります。
連続的監査は、監査人が常時すべての取引を確認する運用ではありません。高リスク権限の付与、未承認変更、退職後のログインなど、条件に合致した例外を日次または週次で抽出し、担当者が調査した結果まで記録する仕組みです。
生成AIとAI監査の拡大
2026年の監査実務では、生成AIやAI-OCRを証憑の読み取り、突合、開示チェック、異常候補の抽出に使う動きが拡大しています。
Wolters Kluwerは2025年に公表した内部監査部門向け調査（調査対象・地域・回答者属性は同社公表資料を参照）において、AIを利用する部門の割合を39％、2026年の利用見込みを80％と報告しています。予測値は導入完了率を保証するものではなく、利用範囲には試験導入も含まれ得ます。調査条件が自社の業種・規模と異なる場合は、数値をそのまま計画の前提にせず、自社では本番利用・限定検証・未利用を分けて把握します。
KPMGはChatKOMEIやKPMG Clara AI Agents、EYはDocument Intelligence Platformを公式発表で紹介しており、監査法人側でも文書処理や監査手続へのAI活用を進めています。被監査企業がAIで生成した突合結果を提出する場合も、元データ、処理ルール、例外一覧、担当者の確認結果を残し、AIの回答だけを証跡にしない設計にします。
監査対応が形骸化・負担増になる原因と課題
監査対応の負担は、証跡の量そのものよりも、保存場所の分散、母集団の不明確さ、手作業での収集、責任者の不在によって増加します。
スクリーンショット提出作業の限界
画面キャプチャをExcelやWordへ貼り付けてPDF化する方法は、取得日時や抽出条件を検証しにくく、画像編集による変更可能性も残ります。
キャプチャは画面表示や一時点の設定を説明する補完資料にはなりますが、ログ全体の完全性を示す証拠にはなりません。数百枚を手作業で保存すると、対象期間の取り違え、ユーザー名の欠落、同じ画像の重複、機密情報のマスキング漏れも起こります。監査ログのCSV出力やAPI取得が可能ならログを主証跡とし、画面キャプチャはログだけでは説明できない設定値に限定します。
Excel台帳とシャドーITの増加
Excelや共有スプレッドシートだけでSaaSの棚卸しを行うと、利用開始を申告していないシャドーITや個人契約を把握できません。
台帳への手入力は、契約部門が更新しなければ実態と一致しなくなります。さらに、アカウント管理が各SaaSへ分散すると、退職者のIDや異動前の管理者権限が数か月残るリスクもあります。IdP、経費データ、ブラウザー拡張、SaaS管理ツールなど複数の検出経路を照合すると、申告台帳だけでは見つからない利用を把握できます。
母集団とサンプルの不整合
サンプル証跡がそろっていても、抽出元となった母集団の件数や作成条件を説明できなければ、監査人はサンプルの妥当性を評価できません。
たとえば変更管理の監査で、Jiraの完了チケットだけを母集団にすると、チケットを作成せず実施した変更が除外されます。クラウド側の構成変更ログとチケット一覧を照合し、差分を例外として調査する方法なら、未起票変更も検出できます。抽出日、検索条件、対象期間、除外条件、総件数を母集団ファイルへ記載します。
部門間の役割分担の曖昧さ
経理、情シス、内部監査、セキュリティ部門が別々の管理表を使うと、同じ依頼に異なる資料を提出し、再確認が増えます。
PBCリストには資料作成者だけでなく、内容責任者、承認者、監査人への回答窓口を登録します。システム仕様の説明は情シス、統制目的と評価結果は統制責任者、法令解釈は法務・経理というように分ければ、一人の担当者に判断が集中しません。回答が確定していない場合は提出を急がず、事実、原因、影響、是正予定を分けて整理します。
証跡管理・監査証跡を効率化する具体策
証跡管理の効率化では、監査ログの完全性を確保し、承認記録と実行ログを関連付けたうえで、提出型から参照型へ段階的に移行します。
IT監査で利用する証跡の分類
監査証跡は、アクセス、変更、運用、取引、委託先の5分類で整理すると、統制と資料の対応関係を把握しやすくなります。
証跡の分類 | 代表例 | 確認する内容 | 不十分になりやすい例 |
|---|---|---|---|
アクセス管理 | ユーザー一覧、ログイン履歴、権限変更履歴 | 申請、承認、付与、削除、棚卸し | 現在の一覧だけで変更履歴がない |
変更管理 | 変更申請、Git履歴、テスト結果、リリースログ | 職務分離、事前承認、テスト、反映日時 | チケットと本番変更が結び付かない |
システム運用 | バックアップ、ジョブ、障害、監視アラート | 実施頻度、失敗時の再処理、責任者確認 | 成功記録だけで失敗対応が残らない |
取引・会計 | 請求書、仕訳、承認記録、マスタ変更 | 正確性、期間帰属、承認、証憑との一致 | PDFと仕訳の対応番号がない |
委託先管理 | SOC報告書、契約書、SLA、障害報告 | 責任分界、対象期間、補完的利用者統制 | SOC報告書を入手しただけで内容を評価しない |
操作動画や画面キャプチャは、特権IDによる複雑な作業やログに残らない画面設定を説明する補完証跡です。すべての操作で一律に取得するのではなく、監査対象統制とシステムのログ仕様を照合して利用範囲を決めます。
ログの完全性と改ざん困難性
ログに必要なのは「改ざん不可能」という保証ではなく、変更を困難にし、変更された場合に検知できる完全性と保全手続です。
運用担当者とログ管理者の権限を分けます。
ログを生成元とは別の保管先へ転送します。
保存先への削除権限を限定し、削除操作も記録します。
時刻同期、タイムゾーン、ユーザー識別子を統一します。
欠損、連携停止、保存容量超過を監視します。
エクスポート条件とファイルのハッシュ値を記録します。
ハッシュ値は取得後の変更検知には利用できますが、元のログが正しいことまで単独で証明するものではありません。生成元、取得者、取得日時、抽出条件、転送経路と組み合わせて管理します。
Read-Only権限による参照型監査
参照型監査とは、監査人へ期限付きの閲覧専用権限を付与し、Jira、GitHub、クラウド管理画面などの証跡を監査人自身が参照する方法です。
対象の限定：監査対象の組織、リポジトリ、期間、ログ項目を特定します。
情報分類：個人情報、営業秘密、他社データが表示される範囲を洗い出します。
権限設計：閲覧専用、MFA、利用期限、接続元制限、ダウンロード制御を設定します。
限定検証：少数の監査項目で、表示範囲と操作ログをテストします。
本番運用：発行、利用、停止、削除を申請ワークフローへ記録します。
閲覧専用でも、機密情報の参照やデータのダウンロードは発生し得ます。監査契約と情報管理ルールが直接閲覧を許容し、対象データを分離できれば参照型へ進みます。分離できなければ、監査用ビュー、マスキング済みCSV、安全なファイル共有を使う提出型を維持します。
GitHubの公式ドキュメントは、組織の監査ログを確認する方法を案内しています。AWSもAWS CloudTrailユーザーガイドで、操作履歴の記録と確認方法を説明しています。各サービスで取得できるログ項目と保持期間が監査対象期間を満たせば直接参照またはAPI取得を使い、満たさなければ外部保管先への転送を組み合わせます。
Acrobat利用ルールとPDF証跡
監査対応のためにAcrobatを利用する場合は、PDF化の手順だけでなく、原本との対応、編集権限、電子署名、保管場所、操作記録をルール化します。
元ファイルと最終PDFへ同じ依頼番号や証憑番号を付けます。
PDF作成者、作成日時、変換元、承認者を記録します。
墨消しは黒い図形の重ね置きではなく、復元防止処理を使います。
電子署名やタイムスタンプを使う場合は、署名検証手順と証明書の管理者を定めます。
編集パスワードだけを真正性の根拠にせず、承認ログや版管理と組み合わせます。
Admin Consoleの設定変更など、管理操作の監査ログを取得できる契約・構成かを確認します。
Adobeは公式ヘルプでAdmin Consoleの監査ログを案内しています。必要なイベントと対象期間を取得できれば監査ログを主証跡にし、取得できなければ申請ワークフロー、保管先の版履歴、電子署名の検証結果で補完します。
AI-OCRと生成AIによる証憑突合
AI-OCRは請求書や領収書の文字を読み取り、生成AIや照合エンジンは会計データとの不一致候補を抽出する用途に向きます。
ジーニアルテクノロジーズが公開した株式会社フジタ商会の導入事例では、紙・PDFの証憑と会計データの突合作業を自動化し、手動作業時間を80％削減したと報告しています。これは特定の帳票と運用における導入成果であり、他社で同じ削減率を保証する数値ではありません。
AI利用時は、金額、日付、取引先、税区分などの必須項目をルールで検証し、信頼度が低い読み取り結果と例外だけを人が確認します。月5日かかる突合作業を80％削減できる工程なら、単純計算では4日分を別業務へ振り向けられます。一方、元証憑、抽出結果、修正履歴、最終承認を保存しなければ、処理結果の再現性を説明できません。
監査対応の準備手順と規模別フロー
監査対応は、対象範囲の合意、母集団の作成、証跡の事前検証、サンプル提出、例外是正の順で進めると手戻りを抑えられます。
監査開始前のタイムライン
準備時期は監査契約や決算日で変わりますが、初回監査や統制変更が多い企業では監査開始の2〜3か月前から逆算します。
時期の目安 | 実施内容 | 完了条件 |
|---|---|---|
2〜3か月前 | 前回指摘、対象組織、重要システム、委託先、担当者の整理 | 監査範囲と責任分担を説明できます。 |
1〜2か月前 | PBCリストの受領、母集団作成、ログ欠損の確認 | 依頼番号ごとに資料と期限が登録されています。 |
2〜4週間前 | サンプル抽出、証跡の事前点検、機密情報のマスキング | 承認と実行ログを相互にたどれます。 |
監査期間中 | 資料提出、参照権限の発行、質問と追加依頼の管理 | 質問、回答、根拠資料、回答日が記録されています。 |
監査終了後 | 例外評価、原因分析、是正計画、再発防止の確認 | 責任者、期限、完了証跡が確定しています。 |
初回監査で対象システムが確定していない場合は3か月前から着手し、前年と範囲が同じで証跡が自動収集されている場合はPBCリスト受領後の差分確認を中心にします。
事前準備チェックリスト
監査開始前には、証跡の有無だけでなく、対象期間、母集団、承認、例外処理まで確認します。
□ 前回の監査報告書と指摘一覧を確認し、是正完了の証跡がある
□ 対象会社、拠点、業務、システム、SaaS、委託先の一覧が最新である
□ PBCリストに依頼番号、担当者、期限、提出先、状態が登録されている
□ 母集団の抽出条件、対象期間、総件数、除外条件が記録されている
□ 退職者・異動者のアカウント処理と承認履歴を追跡できる
□ 高リスク権限と共有IDの利用者、利用目的、棚卸し結果が分かる
□ 変更申請、承認、テスト、リリースログが同じ番号で結び付いている
□ ログ連携の停止や欠損を検知するアラートがある
□ SOC報告書の対象期間と補完的利用者統制を評価している
□ 監査人へ付与する閲覧権限の範囲、期限、削除手順が決まっている
□ 例外の原因、影響、補完統制、是正責任者、期限を記録できる
従業員50名未満の対応
50名未満では、利用サービスが少なく監査対象も限定的なら、責任者を決めた台帳管理と月次確認から開始できます。
ただし、人数が少なくても上場準備中、金融・医療などの規制業種、重要データを扱う企業では人数基準だけで簡素化できません。人事台帳、利用中SaaS、管理者権限、退職時の削除記録を一つの管理表へ集約し、毎月の確認者と確認日を残します。SaaSが10件を超えて更新漏れが出るなら、IdPや自動検出の導入範囲を検討します。
従業員50〜300名の対応
50〜300名では、入退社や異動の件数が増えるため、人事データ、IdP、SaaS管理、承認ワークフローの連携が中心になります。
IPO準備企業では、評価対象年度に入ってから仕組みを変えると運用実績が不足します。J-SOXの評価期間から逆算し、アクセス権棚卸し、変更管理、委託先管理を優先して設計します。人事イベントを起点にアカウントを発行・停止し、実行結果とエラーを保存すれば、Excelへの転記を減らせます。
従業員300名超の対応
300名超では、単一台帳よりも統合ID、SaaS管理、ログ基盤、ITサービス管理を連携し、統制を全社共通化する構成が適します。
連結子会社、海外拠点、複数IdPがある企業は、同じメールアドレスでも別IDとして存在する点を考慮します。人数だけで導入範囲を決めず、上場区分、連結範囲、業種規制、重要システム、外部委託、年間の入退社件数で優先順位を調整します。監査用ビューを分離できる企業は参照型監査へ進み、分離できない企業は中央ログ基盤から監査用データセットを作成します。
▲ 監査開始の2〜3か月前から監査終了後までの準備と対応の5段階プロセス
IT監査で情シスが取り組む対策
IT監査では、アクセス権管理、システム変更管理、ログ保全、委託先管理を、申請から実行結果まで一貫して説明できる状態にします。
アカウントの定期自動棚卸し
ユーザーアクセスレビュー、略してUARでは、在籍者、所属、職務、利用中アカウント、付与権限を照合し、不要権限の削除まで記録します。
人事データベースを基準に、IdPと各SaaSのAPIからユーザー一覧を取得すると、退職者ID、休職者ID、異動前権限、長期間未使用のIDを自動抽出できます。四半期ごとに全件を一括承認するのではなく、前回からの変更、高リスク権限、兼務終了者、共有IDを優先表示します。
APIで権限情報まで取得できれば自動棚卸しへ進み、ユーザー名しか取得できなければ管理画面のエクスポートを併用します。API連携に失敗したアカウントを母集団から除外せず、連携エラー一覧としてレビュー対象に残します。
システム変更管理の関連付け
変更管理では、変更理由、承認、テスト、実行者、本番反映、事後確認を同じチケット番号で関連付けます。
Jiraなどのタスク管理ツールとGitのコミット、プルリクエスト、CI/CDの実行履歴、クラウドの構成変更ログをリンクします。緊急変更では事前承認を省略できる条件、実施可能な担当者、事後承認の期限を規程に定め、通常変更と混在させません。画面キャプチャはログで取得できないテスト結果の説明に限定します。
▲ システム変更管理において証跡が求められる4つのステップ
コロケーション環境の監査
コロケーション環境の監査では、データセンター事業者と利用企業の責任分界を基準に、物理アクセスと自社機器の運用を分けて評価します。
データセンター側の入退館、監視カメラ、電源、空調、消火設備は委託先統制として扱い、自社側のラック鍵、機器持ち込み、保守ベンダー作業、OS・ネットワーク変更は自社統制として扱います。SOC報告書や認証書が対象拠点と対象期間をカバーすれば統制評価に利用し、カバーしなければ入退館記録、作業申請、現地確認結果で補完します。
例外と是正記録の管理
監査で例外が見つかった場合は、資料を差し替えて隠すのではなく、事実、原因、影響範囲、補完統制、是正策を分けて記録します。
たとえば退職者IDが7日間残っていた場合、削除日だけでなく、その期間のログイン有無、権限、データアクセス、原因となった連携エラー、再発防止策を記録します。アクセスがなければ統制逸脱と実害を分けて説明でき、アクセスがあればインシデント対応の要否を判断できます。是正完了後は設定画面だけでなく、次回処理が正常に動いた記録まで保存します。
▲ 共通チケット番号を軸としたシステム変更管理の証跡関連付け構造
監査対応を効率化するツール選定と国内事例
監査効率化ツールは製品名から選ぶのではなく、取得できる母集団、API連携範囲、承認との関連付け、ログ保持、監査人への提示方法で比較します。
ツール分類別の比較基準
SaaS管理、IdP、ワークフロー、ログ管理、AI証憑突合は役割が異なるため、一つの製品ですべてを置き換える前提にしません。
分類 | 主な用途 | 向く企業 | 導入時の確認点 | 主な注意点 |
|---|---|---|---|---|
SaaS管理ツール | SaaS検出、利用者・契約・権限の集約 | SaaSが増え、台帳更新が追い付かない企業 | 対象SaaS、取得可能な権限、API更新頻度 | 未対応SaaSや個人契約を別経路で検出します。 |
IdP・SSO | 認証統合、MFA、プロビジョニング | 入退社・異動が多い企業 | 自動停止、例外ID、特権IDの扱い | SSO対象外IDやローカル管理者が残ります。 |
ワークフロー | 申請、承認、変更履歴の保存 | メールやチャット承認が多い企業 | 版管理、代理承認、API、検索性 | 承認後の実行ログとは別に連携が必要です。 |
ログ管理・SIEM | ログ集約、検索、アラート、保全 | 複数クラウドや重要システムを扱う企業 | 時刻同期、欠損監視、保存階層、権限分離 | 収集設定の漏れがあると母集団が欠けます。 |
AI-OCR・証憑突合 | 読み取り、会計データとの照合、例外抽出 | 紙・PDF証憑の照合件数が多い企業 | 帳票精度、例外処理、学習利用、データ保管 | 低精度結果の人手確認と元証憑の保存が残ります。 |
SaaS管理ツール（Adminaなど）を検討する場合も、対象SaaSのユーザー一覧だけでなく、権限レベル、最終利用日、削除結果まで取得できるかを確認します。必要な属性をAPIで取得できればUARの自動化へ進み、取得できなければCSV取込や管理者レビューを組み合わせます。
国内企業の導入事例
国内事例では、承認証跡の検索、監査人の直接参照、証憑突合、SaaS台帳、外部ベンダーのアクセス制御で成果が報告されています。
企業・業種・規模 | 導入時期 | 課題 | 施策 | 公開された成果 |
|---|---|---|---|---|
株式会社アンドゲート | 公開事例で明示なし | チャット履歴から承認証跡を探す作業に1〜2時間を要していた | グルージェントフローで申請・承認と帳票出力を一元化 | 検索による即時提示と、印鑑使用管理簿などの自動出力を実現 |
情報通信業（企業名は公開事例で特定できていないため社名非掲載） | 公開事例で明示なし | 決算期に監査確認が集中していた | 会計事務所・監査人へ閲覧アカウントを付与 | 監査人が随時確認し、その場で指摘できる運用へ移行 |
カルビー株式会社 | 公開事例で明示なし | 紙証憑の手入力処理に時間を要していた | ジーニアルAI OCRで紙証憑の読み取りを自動化 | 1件あたりの手入力作業時間を約15分から約10分へ短縮 |
株式会社キャンサースキャン | 公開事例で明示なし | スプレッドシート台帳の記入漏れと属人化 | デクセコでSaaSアカウントとITデバイスを統合 | ISMS・プライバシーマーク審査準備の負担を軽減 |
株式会社鈴木商会 | 公開事例で明示なし | 外部ベンダーによる本番環境接続の統制 | コラボフローの承認とアクセス許可を連携 | 承認時間帯だけ接続を許可し、接続ログと承認証跡を蓄積 |
これらはツール提供企業が自社製品のマーケティング目的で公開した導入事例であり、削減率や運用成果は対象業務、処理件数、導入前の管理方法によって変わります。数値をそのまま自社の見込み効果として用いるのではなく、導入前の月間工数、証跡提出件数、差し戻し件数、退職者IDの残存件数を基準値として測り、導入後に同じ条件で比較します。
スモールスタートの判断基準
ツール導入は、監査指摘が多い統制または月間工数が大きい一工程に対象を絞ると、効果と連携漏れを検証できます。
たとえば棚卸しに月30時間を要する企業が、API収集と例外レビューによって月2時間へ短縮できれば、削減率は約93％です。ただし、この数値は自社測定の例であり、導入効果を保証する実績値ではありません。最初の8〜12週間は、手動結果と自動取得結果を並行比較し、取得漏れが許容範囲内なら対象SaaSを増やします。
▲ SaaS一元管理ツールによる監査証跡収集のシステム構成
よくある誤解・失敗パターンと対策
監査対応で避けるべき失敗は、キャプチャの大量提出、更新されないExcel台帳、内容を見ないアクセス権の一括承認です。
キャプチャ提出地獄
監査依頼を受けるたびに管理画面を撮影し、Excelへ貼り付ける運用は、件数が増えるほど取得ミスとマスキング漏れを招きます。
やってはいけないのは、キャプチャ枚数を増やすことで証拠の信頼性を補おうとする対応です。監査ログの取得可否、CSVの抽出条件、API連携、閲覧専用権限の順に代替手段を評価します。ログを取得できればキャプチャを補完資料へ格下げし、取得できなければ作成者、取得日時、対象期間、承認者をキャプチャ台帳へ付けます。
Excel台帳の更新停止
担当者が退職した後に数式やマクロを修正できず、台帳だけが残る状態では、記録件数と実際のアカウント数が一致しません。
台帳には責任者、更新頻度、データ取得元、最終更新日を表示し、実システムの件数と月次で照合します。差分が連続して発生するなら手入力の継続を止め、IdP、SaaS API、経費データから自動収集する範囲を増やします。自動化後も、API未対応サービスと連携エラーを手動確認対象として残します。
アクセス権棚卸しのハンコリレー
所属長がユーザー一覧を見ずに全件承認すると、棚卸しの記録は残っても、不要な特権IDを発見する統制目的を果たしません。
前回から変更がない一般権限と、管理者権限、共有ID、退職予定者、長期未使用IDを分けて表示します。承認者が権限の意味を理解できない場合は、システム管理者が用途とリスクを説明し、所属長が業務上の必要性を判断します。削除対象は承認だけで終わらせず、削除実行ログと再確認日まで記録します。
AI出力の無検証利用
AIが「一致」と判定した結果だけを保存すると、読み取り誤りや判定ルールの変更を後から検証できません。
AI処理では、モデルやサービスの版、入力元、抽出項目、信頼度、例外条件、人が修正した履歴を残します。個人情報や機密情報を外部AIへ送信する場合は、契約上の学習利用、保存地域、削除条件を確認します。条件が社内規程を満たせれば限定データで検証し、満たせなければ閉域環境または従来のルールベース照合を使います。
▲ 画面キャプチャ提出を削減するための効率的な証跡取得手段の決定フロー
よくある質問
監査対応で頻出する準備時期、ログ保存期間、J-SOX、閲覧専用権限、Acrobatの疑問に回答します。
Q：監査対応の準備はいつから始めますか？
A：初回監査や対象システムの変更が多い場合は、監査開始の2〜3か月前から対象範囲と母集団を整理します。前年と範囲が同じで証跡を自動収集できている場合は、PBCリスト受領後に差分とログ欠損を点検します。
Q：監査証跡としてシステム操作ログを何年保存しますか？
A：システム操作ログに一律の保存年数はなく、適用法令、業法、契約、監査対象期間、事故調査に必要な期間を基準に決めます。監査対象期間をカバーできればその設定を採用し、カバーできなければ外部保管への転送や保存期間の延長を行います。
Q：会計帳簿と操作ログは同じ期間保存しますか？
A：同じ期間とは限りません。会社法第432条は会計帳簿と事業に関する重要な資料を10年間保存する規定ですが、一般的なシステム操作ログへ一律に10年を適用する規定ではないため、対象データを分けて判断します。条文はe-Gov法令検索の会社法で確認できます。
Q：改訂J-SOXではクラウド統制が一律に義務化されましたか？
A：クラウドサービスの利用や特定の管理手続が、すべての企業へ一律に義務化されたわけではありません。クラウドが財務報告に関係する処理を担う場合は、アクセス管理、変更管理、委託先統制、障害時の影響を評価範囲へ反映します。
Q：監査人へRead-Only権限を付与すれば証跡提出は不要ですか？
A：すべての提出が不要になるわけではありません。閲覧範囲、利用期限、個人情報、ダウンロード可否、監査ログを設計できる場合は直接参照へ移行し、機密情報を分離できない場合はマスキング済みデータを提出します。
Q：監査対応のためにAcrobat利用ルールで押さえる点は何ですか？
A：元ファイルとの対応番号、PDF作成者、作成日時、編集権限、墨消し方法、電子署名の検証、保管先の版履歴を定めます。PDFのパスワード設定だけを真正性の根拠にせず、承認ワークフローや監査ログと組み合わせます。
まとめ
明日から始める監査対応の整備
監査対応を効率化する第一歩は、証跡を増やすことではなく、対象統制と証跡の関係を整理することです。まず前回の指摘を1件選び、申請、承認、実行ログ、確認結果を同じ番号でたどれるか確認します。たどれなければ保存場所と責任者を統一し、たどれるなら次に退職者アカウントと高リスク権限の棚卸しへ進みます。
その後、監査ログを取得できるシステムはキャプチャ提出からCSV・API・Read-Only参照へ移行します。取得できないシステムは、補完証跡と承認手続を明文化します。年次監査の直前作業を、月次の例外確認と日常的な証跡化へ変えることで、監査対応とIT統制を同じ運用の中で改善できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
