監査・内部統制でAccessは問題になる？指摘されやすい点と備え

結論：Accessの野良運用は、統制の観点で問題になりやすい構造を持っている

監査や内部統制の評価では、「誰がいつ何をしたか」を確認できる仕組みが求められることがあります。Accessの標準機能は、この観点に対して構造的な弱点を抱えています。オブジェクト単位の権限設定ができない、変更履歴が自動では残らない、本番と検証の分離も仕組みとしては存在しない。こうした状態のまま業務の根幹を担っていると、内部監査やIT統制の確認で指摘されることがあります。

ただし、この記事でJ-SOXや内部統制報告制度の具体的な適用要否を判断することはできません。自社のシステムが統制上の問題になるかどうかは、担当の監査人や専門家に確認してください。ここでは「一般的に統制の観点で確認されることが多い事項」と、Accessの機能上の限界を整理します。

統制の観点で確認されやすい5つの論点

IT統制（IT全般統制）で確認されることがある項目として、アクセス管理、変更管理、運用管理、開発・本番環境の分離が挙げられます。ただし、何が必要かは評価対象の範囲・リスク・補完統制によって変わります。Accessの野良運用は、これらの複数の観点で弱点を持ちやすい構造になっています。

アクセス権限の問題：.accdb形式の構造的な制約

Access 2003以前の.mdb形式には「ユーザーレベルセキュリティ」という、ユーザーやグループごとにテーブル・フォームへのアクセス権を設定する仕組みがありました。しかし現在の標準形式である.accdbでは、この機能はMicrosoftが廃止しています。

公式サポートページ（What happened to user-level security?）には「User-level security features are not available in Access web apps, web databases, or databases that use one of the new file formats（.accdb等）」と明記されています。

.accdbが標準で提供するアクセス保護は「ファイルを開くためのデータベースパスワード（暗号化）」とWindowsのファイル共有権限によるファイル単位の制限です。ACCDE形式でVBAコードやフォーム・レポートの設計変更を制限する方法もありますが、これはコード保護であって操作ユーザーの権限制御ではありません。Access単体でテーブルやフォームの単位にユーザー別権限を設定することはできず、「Aさんは自分の担当分だけ見られる」「Bさんはレポート閲覧のみ」といったオブジェクト単位の権限制御は、Access標準機能では実現できません。Accessのパスワード保護の実力と限界でも詳しく解説しています。

統制の評価でアクセス管理を確認する際、「ユーザー別に何ができるかが制御されているか」「権限の申請・承認記録があるか」は頻出の確認事項です（参考：エイアイエムコンサルティング「IT全般統制アクセス管理」）。Accessの.accdbではこの点を満たす仕組みがないため、当社が関わる現場でも指摘対象になりやすいと経験上感じています。

変更履歴・操作ログが残らない問題

Accessには、監査証跡を無設定で自動保存する仕組みがありません。Microsoft Q&Aには複数の問い合わせがあり、専門家が「カスタム実装が必要」と繰り返し回答しています（MS Access audit trail - Microsoft Q&A）。Microsoftのコミュニティ回答は公式の製品仕様声明ではありませんが、監査証跡が標準設定されていない点は機能上の事実です。

VBAのフォームイベントを使えばフォーム経由の変更ログを自作できます。またデータマクロ（テーブルの追加・更新・削除イベントに紐づく仕組み）を使えば、フォームを経由しないテーブル直接編集にも対応できます。ただし、どちらも「意図的に設計・実装する必要がある」という点は変わりません。設計が甘いとログの抜けが生じます。監査で「誰がいつ何を変えたか」を証明しなければならない場面では、この自作ログの網羅性と信頼性が問われます。

退職者や担当交代時に「過去の変更が誰によるものか判断できない」という状況も、Accessの属人化と組み合わさって起きやすい問題です。属人化したAccessのリスクと脱・属人化の進め方もあわせてご覧ください。

本番・検証の分離がない問題と改修の追跡

当社が関わるAccessの現場では、「ファイルをコピーして、担当者が直接VBAやフォームを修正し、本番ファイルに上書きする」という改修フローが多く見られます。本番環境と検証環境が明確に分離されておらず、改修内容の承認記録も残りません。

IT統制の変更管理では、「変更内容が文書化されているか」「変更前後のテスト結果があるか」「承認された変更だけが本番に反映されているか」が確認されることがあります。ファイルコピーと個人作業が主流の運用では、これらを事後的に証明するのが難しい状況です。

誰が何の目的でファイルを修正したのか、修正前の状態はどうだったのか。こうした変更の証跡を残す仕組みを意図的に設けない限り、Accessのファイルには残りません。

バックアップ・復旧の証跡も個人任せになりやすい

バックアップが実施されているかどうか、また復元テストが行われているかどうかについても、Accessでは個人の運用に委ねられているケースが多い状態です（当社経験）。「バックアップは毎日取っている」と担当者が言っても、その記録が残っていなければ、統制の評価上は「証明できない」と判断されることがあります。

特に復元テスト（バックアップから実際に復旧できるかの確認）の証跡は、内部監査でも確認されやすい項目です。バックアップファイルが存在していても「実際に復元できるか試したことがない」という現場は当社の経験上も多く、これ自体がリスクになります。バックアップ設計の詳細はAccessのバックアップ設計と復元テストで解説しています。

備え：Accessを使い続けながら統制を補完するには

すぐに移行できない状況でも、以下の補完策で統制上の問題を部分的に緩和できます。補完策の有効性はリスクの大きさや評価の対象範囲によって判断が変わります。自社の状況が補完策で対応できるかどうかは、監査人や専門家に確認してください。

• アクセス権の補完：Windowsの共有フォルダのアクセス権でファイルレベルの制限を設定する。編集権限が必要なユーザーとそうでないユーザーをフォルダ単位で分ける。Access自体のパスワードは「全員が同じパスワードを知っている」状態になりやすく、権限管理にはなりません。
• 変更履歴の補完：VBAのフォームイベントで変更ログテーブルに記録する実装を追加する。ただし前述の通り、フォームを経由しない操作には効かないため、直接テーブル編集を禁止するルールと組み合わせる必要があります。
• 改修の文書化：何をいつ誰が変更したかを手動でも記録するルールを定め、ファイルのバージョン管理（日付付きコピーの保管など）を運用で担保する。
• バックアップ証跡の整備：バックアップ実施日と復元テストの結果を記録するシートを作り、定期的に管理者が確認・押印する運用を設ける。

これらの補完策を整えた場合も、統制の評価上は補完策の存在と有効性を別途証明する必要があり、その証明自体の手間もかかります。

アクセス権管理や操作ログの仕組みが整えやすいSQL Serverや専用のWebシステムへ移行すれば、統制の基盤を作りやすくなります。ただし、SQL Serverに移行しただけで監査ログや権限設定が自動で整うわけではなく、ログ設計や権限設計を適切に行う必要があります。アップサイジング（Access画面はそのままにデータだけSQL Serverへ移す構成）はその第一歩として有効な場合があります。詳細はAccessのデータだけSQL Serverへ移す構成で解説しています。統制の観点で自社のAccessがどの程度問題になり得るか確認したい場合は、無料の解析可否チェックからご相談ください。

よくある質問

Q. J-SOXやIT統制の対象になっていなければ、Accessのままでも問題ありませんか。

統制上の問題になるかどうかは、自社の状況や監査人の判断によります。ただし、J-SOXの対象外であっても、内部監査・管理部門の評価・取引先からの要請など、さまざまな場面でシステムの統制状況を確認されることがあります。証跡が残らない構造は、こうした確認に対応できないリスクとして常に存在します。

Q. Accessでも変更履歴を残せますか。

VBAのフォームイベントでフォーム経由の変更を記録するか、Accessの標準機能であるデータマクロでテーブルの変更イベントにログを紐づけるかで実装できます。ただし、いずれも監査ログとしては標準設定されておらず、個別設計・実装が必要です。設計の穴が生じやすいため、実装後も網羅性の確認が必要です。「監査証跡として十分か」は監査人の判断によるため、実装前に確認することをおすすめします。

Q. ユーザーごとにアクセスを制限したいのですが、Accessでできますか。

現行の.accdb形式では、Microsoftが公式にユーザーレベルのアクセス制御を廃止しています。Windowsのファイル共有権限でファイルレベルの制限はできますが、テーブルやフォームの単位での制限は標準機能ではできません。ユーザー別の細かいアクセス制御が必要な場合は、SQL Server等への移行が現実的な選択肢です。

Q. 監査で指摘された場合、どう対応すればよいですか。

指摘の内容によって対応は変わりますが、まず「現状の把握」が先決です。どのAccess DBが存在し、何の業務を担っているか棚卸しを行い、統制上のリスクを整理したうえで、補完策か移行かを判断することになります。当社では現状のAccess DBを解析し、リスクと移行要件を整理する支援を行っています。