Access UIの「聖域」を制御せよ：CommandBarsによる動的リボン制御の極意
Accessで業務ツールを構築する際、多くの開発者が陥る罠がある。「フォームのボタンを非表示にする」だけで満足してしまうことだ。それでは不十分だ。ユーザーはナビゲーションウィンドウから、あるいは右クリックメニューから、禁じられた領域へ侵入してくる。
真のシステムアーキテクトは、UIを「フォームの中」ではなく「Accessアプリケーションの基層（CommandBars）」で制御する。今回は、権限に応じてUIを完全に掌握するための極限の手法を伝授する。
—
1. なぜ「フォームの制御」だけでは不十分なのか
Accessにおけるリボンやコンテキストメニューは、`Application.CommandBars` オブジェクトによって管理されている。多くの開発者がフォームの `OnOpen` イベントでボタンの `Enabled` を切り替えるが、これはあくまで「一過性の制御」に過ぎない。
プロフェッショナルな設計において、UIの制御は「アプリケーションの状態（ログインユーザーの権限）」と「永続的ではないコマンドの動的生成」を分離すべきである。
この設計を怠ると、予期せぬエラーや、特定の画面を閉じた後にメニューが無効のままになるという「UIのゾンビ化」を引き起こす。
—
2. CommandBars操作の鉄則：クリーンアップと例外処理
`CommandBars` はAccessのプロセス全体に影響を及ぼす共有リソースだ。不用意に触れば、他のフォームや最悪の場合はAccess本体の動作を阻害する。
- 鉄則1：必ず作成・削除の対を保証する
動的にメニューを作成した場合、フォームの `OnClose` イベントで確実に削除（Delete）しなければならない。
- 鉄則2：存在確認を怠らない
`CommandBars(“CustomMenu”)` にアクセスする際、存在しない名前を指定すると即座にランタイムエラーとなる。
—
3. 実践コード：権限による右クリックメニューの動的制御
以下は、ログインユーザーの役割（Admin / User）に応じて、右クリックメニューを動的に生成・削除する堅牢な実装パターンだ。
Option Compare Database
Option Explicit
‘ メニューの識別名
Private Const MENU_NAME As String = “AdminTaskMenu”
‘ — フォームの呼び出し元で制御 —
Private Sub Form_Load()
‘ ユーザー権限に応じたUI構築
If CurrentUserRole = “Admin” Then
CreateCustomContextMenu
End If
End Sub
Private Sub Form_Unload(Cancel As Integer)
‘ 終了時に必ずクリーンアップ（メモリリークとゴミ残りの防止）
DeleteCustomContextMenu
End Sub
‘ — CommandBars制御ロジック —
Private Sub CreateCustomContextMenu()
Dim cmb As CommandBar
Dim btn As CommandBarButton
‘ 既存のメニューがあれば削除
DeleteCustomContextMenu
‘ メニューバーの作成
Set cmb = Application.CommandBars.Add(Name:=MENU_NAME, Position:=msoBarPopup, Temporary:=True)
‘ ボタンの追加
Set btn = cmb.Controls.Add(Type:=msoControlButton)
With btn
.Caption = “管理者専用：データ再計算”
.FaceId = 487 ‘ アイコンID
.OnAction = “=RunAdminProcess()” ‘ 関数を直接呼ぶ
End With
End Sub
Private Sub DeleteCustomContextMenu()
On Error Resume Next ‘ 存在しない場合のエラーを無視
Application.CommandBars(MENU_NAME).Delete
On Error GoTo 0
End Sub
—
4. アーキテクトからの助言：保守性を高める設計思想
① OnActionの使い所
`OnAction` には、直接プロシージャ名を書くよりも、`=MyFunction()` のようにイミディエイトウィンドウ形式で関数を呼び出すのがコツだ。これにより、パブリック関数であればどのモジュールに書かれていても呼び出しが可能になり、設計の自由度が飛躍的に高まる。
② リボンXMLとの使い分け
Access 2007以降、本格的なリボンカスタマイズは `USysRibbons` テーブルを用いたXML定義が標準だ。しかし、今回解説した `CommandBars` は、「特定フォームのコンテキストメニュー」や「簡易的な動的制御」には依然として最強のツールである。
大規模な共通リボンはXMLで定義し、局所的・動的な制御は `CommandBars` で実装する。このハイブリッド戦略こそが、変更に強いAccessアプリケーションの正攻法だ。
—
最後に：なぜ「動的制御」にこだわるのか
あなたが作っているのは単なる「入力画面」ではないはずだ。業務を止めず、誤操作を防ぎ、権限のない者にデータの深淵を見せない「守りのシステム」である。
`CommandBars` を制する者は、AccessのUI層を自在に操る権利を得る。コードをただ書くのではなく、Accessのライフサイクルそのものを支配せよ。
次回の講義では、より高度な「Ribbon XMLの動的読み込み」について深掘りする。準備を整えておいてほしい。
