Accessを「ただのデータベース」で終わらせない。CommandBarsでUIを支配せよ
こんにちは。現場で泥臭い自動化を積み重ね、Accessの深淵を覗いてきたエンジニアです。
皆さんはAccessを触る時、「ボタンをポチポチ押すだけのツール」だと思っていませんか？もしそうなら、今日でその考えは捨ててください。Access VBAを掌握するということは、Accessというアプリケーションそのものを自分の意のままに操るということです。
今回は、Accessの顔である「リボンやメニュー」を動的に制御する技術、`Application.CommandBars`について解説します。これができるようになると、ユーザーの権限に合わせて操作を制限したり、特定の業務専用のメニューを追加したりと、システム開発者としてのレベルが一段階上がります。
—
1. なぜ「CommandBars」が必要なのか？
Accessの標準機能は強力ですが、全ユーザーに全機能を開放するのはリスクが伴います。「一般社員には閲覧のみさせたい」「編集ボタンは特定の部署だけに表示させたい」といった要望は、現場では日常茶飯事です。
ここで使うのが、かつてOfficeのメニューを司っていた歴史あるインターフェース、`CommandBars`オブジェクトです。
「リボンはXMLで書くものじゃないの？」という声も聞こえてきそうですが、小規模な業務システムや、動的に特定のメニューだけを隠蔽したい場合、`CommandBars`による制御は非常に直感的で、かつ強力な武器になります。
—
2. まずは「隠す」ことから始めよう
最もシンプルな制御として、「メニューバーやリボンの特定の項目を無効化する」コードを紹介します。
‘ 権限に応じてリボンやメニューを制御するプロシージャ
Public Sub SetUIConstraint(ByVal isReadOnly As Boolean)
Dim cmdBar As CommandBar
‘ Accessのメニューバー(MenuBar)全体を対象にする
‘ ※注意: 最近のAccessではリボンがメインですが、一部の右クリックメニュー等はこれで制御可能です
On Error Resume Next ‘ エラーを握りつぶすのではなく、存在チェックとして利用
‘ 特定のメニューコマンドを無効化する例
‘ 例: “ファイル”メニュー内の”印刷”ボタンを制御する場合
‘ ※CommandBarは階層構造であることに注意してください
If isReadOnly Then
‘ 読み取り専用ユーザーなら、特定のコマンドを不可視にする
Application.CommandBars(“Menu Bar”).Controls(“ファイル”).Controls(“印刷”).Enabled = False
Else
‘ 管理者なら許可する
Application.CommandBars(“Menu Bar”).Controls(“ファイル”).Controls(“印刷”).Enabled = True
End If
On Error GoTo 0
End Sub
ここが極限のポイント！
`On Error Resume Next` を入れている理由は、Accessのバージョンや設定によってメニュー構造が異なる可能性があるからです。「エラーで落ちるリスク」を制御しつつ、確実にUIを書き換える。 これがプロの現場の作法です。
—
3. オリジナルのメニューを追加する（応用編）
次に、ユーザーが特定のフォームを開いたときだけ出現する「専用メニュー」を追加してみましょう。
Public Sub AddCustomMenu()
Dim cmdBar As CommandBar
Dim btn As CommandBarButton
‘ 既存のメニューバーに新しくメニューを追加
Set cmdBar = Application.CommandBars(“Menu Bar”)
‘ 既に同名のメニューがあれば一旦削除（二重生成を防ぐ）
On Error Resume Next
cmdBar.Controls(“業務メニュー”).Delete
On Error GoTo 0
‘ メニューバーに新しいサブメニューを追加
Set btn = cmdBar.Controls.Add(Type:=msoControlButton)
With btn
.Caption = “在庫データ更新”
.Style = msoButtonCaption
.OnAction = “RunInventoryUpdate” ‘ 実行したいVBA関数名を指定
.Visible = True
End With
End Sub
知っておくべき「オブジェクトのライフサイクル」
`CommandBars`で追加したメニューは、Accessを閉じても設定が残り続ける場合があります。
必ず、フォームの `Form_Close` イベントや `AutoExec` マクロの終了処理で、作成したメニューを `.Delete` する習慣をつけてください。ゴミを残さないのが、真のエンジニアの流儀です。
—
4. 初学者が陥りやすい「罠」
1. 「リボン」と「コマンドバー」の混同
現在のAccessリボン（Office 2007以降）は、基本的に「USysRibbons」というテーブルを利用したXML定義が推奨されます。`CommandBars`は古い仕組みですが、VBAから即座に制御できるというメリットは今でも健在です。使い分けが重要ですよ。
2. 存在しない名前を指定する
`Application.CommandBars(“存在しない名前”)` を呼び出すと即座にエラーになります。必ず事前にイミディエイトウィンドウで `?Application.CommandBars(i).Name` と打って、現在のメニュー構成を確認する癖をつけましょう。
—
最後に：Accessを使いこなすということ
「ボタンを無効化する」という小さな制御の積み重ねが、堅牢なシステムを構築します。ユーザーに無駄な操作をさせない。ミスを未然に防ぐ。そのためのUI構築こそが、VBAエンジニアの腕の見せ所です。
今日のコードをコピペするだけでなく、ぜひ「どのボタンを、どんな条件で制御したいか」を想像しながら触ってみてください。ここをクリアすれば、あなたはもうただの「Accessユーザー」ではなく、「Accessアーキテクト」への第一歩を踏み出したことになります。
また次の極限の知見でお会いしましょう。質問があればいつでもどうぞ。あなたの開発が、より洗練されたものになることを願っています。
