以下では、「ユーザー権限管理：Accessで実装できる簡易認証と機能制限」をテーマに、Microsoft Accessでどのようにユーザーごとにアクセス制御（機能の制限や認証）を行うかを解説します。AccessはWebアプリやSQL Serverのように高度なユーザー管理機能を標準装備していないため、小～中規模のシステムであれば、簡易的なテクニックを用いてユーザー権限を振り分けるのが一般的です。ぜひ参考にしてみてください。

1. なぜユーザー権限管理が必要か？

• 共用データベースであっても、すべてのユーザーに同等の操作権限を与えると、誤更新や不正な削除が起きやすい
• 機密度が異なる情報（例：経理データや管理者向けフォーム）を一部ユーザーだけに見せたい・操作させたい
• 監査ログや履歴管理がなくても、最低限の制限UIだけでトラブルを防げるシナリオが多い

ポイント

• Accessは基本的に「ファイル1つ」として運用するため、大規模DBのようなロール管理はない
• 代わりに簡易的なログイン画面を自作して、機能を制御する方法が広く使われる

2. 過去のユーザーレベルセキュリティ(ULS)と現状

• Access 2003以前には「ユーザーレベルセキュリティ（ULS）」という仕組みがあり、.mdbファイルでユーザー/グループごとの権限を設定可能だった
• Access 2007以降(.accdb) ではULSが廃止され、同等のGUIでの権限管理は標準サポートされなくなった
• 現在はWindowsファイル権限やSQL Server側のセキュリティ、あるいは自前のログインフォームが実質的な対応策

注意: もし旧形式(.mdb)でULSを使っている場合も、新規採用は推奨されない。Modern Access(.accdb)に移行するなら自作の簡易認証やバックエンドをSQL Serverにするといった手段が無難。

3. 簡易認証フォームの作り方：基礎アイデア

ないものはない！お買い物なら楽天市場

3.1 テーブルにユーザーアカウントを持つ

1. tbl_ユーザー
   • ユーザーID / パスワード / 権限レベル(例: admin, staff, viewerなど)
2. フロントエンドにログインフォームを用意し、ユーザーIDとパスワードを入力させて照合
3. 照合に成功したら、グローバル変数やモジュール変数に“ログイン中ユーザー情報”を保持

照合コード例 (VBA)

Public Sub LoginCheck(strUser As String, strPass As String)
    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SELECT * FROM tbl_ユーザー WHERE ユーザーID='" & strUser & "' AND パスワード='" & strPass & "'")

    If rs.EOF Then
        MsgBox "ユーザー名またはパスワードが違います", vbExclamation
    Else
        ' ログイン成功
        g_strCurrentUserID = strUser
        g_strCurrentRole = rs!権限レベル
        DoCmd.OpenForm "メインメニュー"
        DoCmd.Close acForm, "ログインフォーム"
    End If

    rs.Close
    Set rs = Nothing
End Sub

注意: 上記は文字列連結なので、SQLインジェクションに注意。安全のためパラメータクエリ等を使うほうが望ましい（例示なので簡易です）。

3.2 フォームや機能を制限する

• ログイン後、権限レベルを元にフォームやボタンを表示/非表示したり、Enabled=Falseにしたりする
• 例えば権限レベル = "admin"なら「ユーザー管理画面」を表示し、それ以外のスタッフには非表示に
• 重要フォームに移動する前にIf g_strCurrentRole <> “admin” Then MsgBox “権限不足” などのチェックも挟める

Private Sub Form_Open(Cancel As Integer)
    ' メインメニューフォームで管理者ボタンを制御
    If g_strCurrentRole <> "admin" Then
        Me.btn管理者機能.Visible = False
    End If
End Sub

• このようにUIレベルでの機能制限を行う

4. Windowsファイル権限も併用しよう

1. バックエンド(.accdb/.mdb)の保管場所に対して、更新を行えるユーザーに書き込み権限を与え、それ以外は読み取りだけ
2. Windowsファイルのアクセス制御リスト(ACL)を設定し、無関係ユーザーがDBを触れないようにする
3. ただしUIレベルだけで制限しても、ユーザーが直接ファイルを開いてテーブル編集できるケースがある → Windows権限で実ファイルのアクセスも管理しよう

5. 大規模化するときはSQL Server側のセキュリティに任せる

• Accessの自作認証やファイル権限は小中規模向け。多人数・高セキュリティ要件の場合は、SQL Serverをバックエンドにし、最小権限ユーザーを付与する
• テーブルへの直接アクセスを禁止し、ストアドプロシージャまたはビュー経由での更新に制限できる
• Access側はフロントエンドとしてODBC接続を利用し、SQL Serverセキュリティを完全に使う設計が安全

6. レポート印刷やクエリ実行の制限はどうする？

• クエリやレポートにも、ボタンを押して起動するスタイルにし、権限チェックを挟む
• 例：「売上集計レポート」は管理者のみ → If g_strCurrentRole <> "admin" Then Exit Sub のような記述でボタンクリックを抑止
• ナビゲーションウィンドウの非表示: Options → Current Database で**「ナビゲーションウィンドウを表示しない」設定を行い、ユーザーはボタンメニュー**からしか操作できないようにする
  • Shiftキーで起動時のバイパス防止などを併せると、素朴なロックダウンが可能

7. まとめ：Accessの簡易認証と機能制限を活かす流れ

1. ユーザー情報テーブルを用意
   • ユーザーID、パスワード（簡易/平文でも内部用途ならOKだが、本来はハッシュ化が理想）、権限レベル
2. ログインフォームでユーザーID/パスワードを確認し、グローバル変数で保持
3. フォームやボタンを権限レベルで表示制御
   • If Role <> "Admin" Then btnAdmin.Visible = False など
4. Windowsファイル権限でバックエンドに対する直接操作を制限
   • DBファイルを読取/書込できるユーザーを最小化
5. 複雑要件や高セキュリティの場合はSQL Server等の本格的なRDBMSを利用し、サーバー側ユーザー管理をする

Accessの標準では高度なユーザー管理機能(ULS) は既に廃止され、自前でフォーム認証やUI制限を行うのが主流です。小～中規模であればこれで十分なケースが多く、簡易的にも安全性を高められます。要件に応じてSQL Server連携へ移行する選択肢も検討し、手軽さとセキュリティをバランスさせてみてください。

関連記事

• マルチユーザー運用時の注意：フロントエンド分割＆レプリケーションの概要
• Accessファイル(.accdb/.mdb)の構造を理解する：拡張子とエンジンの話
• セキュリティ強化策：認証、権限管理、SQLインジェクション対策

これらの方法を使えば、初心者でも簡易的な権限管理をAccessで組めます。少なくとも外部から一切の制限なしという状態よりははるかに安全。業務内容やユーザー数に応じて、スモールスタートしつつ将来は本格RDBMSにも視野を広げましょう。

DMM

まー

駆け出しブロガー

X

入社した会社では、Accessを活用した基幹システムが長年運用されていました。しかし、開発者の高齢化により保守が困難となり、システムの維持・更新が急務に。 ほぼAccessに触れたことのなかった私は、ゼロから学びながら基幹システムを再構築してみることに。ついにはAccessによるシステム開発エンジニアとしてのスキルを身につけるまでに成長。 元々の業務のノウハウとそれを効率化するためのツール(Access)によって業務効率化システムをいくつも開発してきました。 みなさんの”なにか（業務のノウハウ）”とAccessで業務効率化を実現するお役に立てれば幸いです。 月３０万の高配当投資も行っています。最新の銘柄情報もお届けしていきます。