AccScan
技術

ShiftキーでAccessの起動時設定を回避する|使い方とAllowBypassKey

Shiftキーを押しながらAccessを開くと起動フォーム・AutoExecマクロ・ナビゲーション非表示など8項目の起動時設定をスキップできます。保守で役立つ場面と、AllowBypassKeyプロパティでこれを無効化する公式VBAコード、万全な保護にならない理由を解説します。

まずは、自社のAccessが「解析できるか」を無料で確認できます。

約2分・ファイル送信不要・発注義務なし

結論:Shift起動は保守で使える正規の機能、ただしAllowBypassKeyで無効化しても完全な保護にはなりません

Accessにはファイルを開くとき、Shiftキーを押したまま開くと起動時の設定を丸ごと読み飛ばす仕組みがあります。Microsoftの公式ドキュメントに明記された正式な動作で、起動フォームが消えてナビゲーションウィンドウが出てきます。保守や設定変更の場面で助かる操作ですが、配布したデータベースにこの動作が残っていると、エンドユーザーが操作制限を意図せず突破できてしまいます。

それを防ぐのが AllowBypassKey プロパティです。VBAで False に設定するとShift起動が効かなくなります。ただしこれはAccess内部の操作制限であり、ファイル自体を保護するものではありません。VBAパスワードやaccde形式による保護は別の話で、それらはパスワード保護の限界accde/mde解析の記事に譲ります。

Shift起動で何が変わるか

Accessのファイルを開くとき、Shiftキーを押し続けながらダブルクリックすると、「現在のデータベース」に設定された起動時オプションがすべてスキップされます。セキュリティメッセージが出た場合はそれを閉じるまでShiftを離さずに押し続けないと、設定の読み飛ばしが途中で止まります。公式ドキュメントには「すべてのセキュリティメッセージを閉じる間もShiftキーを押し続けていなければ、起動時オプションは回避されない」と記されています。

具体的に何がスキップされるかを整理します。

設定グループ設定項目Shift起動時の挙動
アプリケーションオプションアプリケーションのタイトルカスタムタイトルは表示されない
アプリケーションオプションアプリケーションのアイコンカスタムアイコンは表示されない
アプリケーションオプションフォームの表示(起動時フォーム)指定フォームは開かず、フォームのイベントプロシージャも動かない
ナビゲーションナビゲーションウィンドウの表示非表示に設定していても、ナビゲーションウィンドウが表示される
リボンとツールバーリボン名(カスタムリボン)カスタムリボンは表示されず、既定のリボンタブが表示される
リボンとツールバーフルメニューの許可設定に関係なく既定のリボンタブがすべて表示される
リボンとツールバー既定のショートカットメニューを許可設定に関係なく既定のショートカットメニューがすべて表示される
マクロAutoExecマクロ実行されない

テーブルのデータ内容やクエリの実行権限など、「ファイルを開くときに何を表示・実行するか」以外の設定は影響を受けません。

保守で役立つ場面

Shift起動が最も助かるのは、起動フォームが画面を占有してナビゲーションウィンドウを隠しているデータベースを直さなければならないときです。起動フォームに閉じるボタンがなかったり、VBAでナビゲーションウィンドウを非表示にしていたりすると、通常の開き方では設定変更画面に辿り着けません。

具体的には次のような場面で使います。

  • 起動フォームが壊れていてAccessが起動直後にエラーを出す場合(フォームを開かせず、テーブルやクエリを直接確認する)
  • AutoExecマクロに問題があって毎回エラーになる場合(マクロを動かさずに中身を確認・修正する)
  • カスタムリボンが壊れていて操作できなくなった場合(既定リボンに戻して設定変更する)
  • 「現在のデータベース」の設定を変更したい場合(起動フォームが邪魔にならない状態でオプションを開く)

いずれも「作った環境が想定外の状態になったとき、外から開き直す」用途です。VBAの肥大化対処で使う/decompileスイッチも同じく「通常の起動を意図的に変える」操作なので、保守ツールとして覚えておく価値があります。

AllowBypassKeyで無効化する方法

配布するデータベースでShift起動を使えなくしたい場合は、AllowBypassKeyプロパティをVBAで設定します。このプロパティはデフォルトでデータベースのPropertiesコレクションに存在しないため、CreatePropertyメソッドで追加してからセットします。

公式ドキュメントに掲載されているコードをそのまま引用します。

Sub SetBypassProperty()
    Const DB_Boolean As Long = 1
    ChangeProperty "AllowBypassKey", DB_Boolean, False
End Sub

Function ChangeProperty(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer
    Dim dbs As Object, prp As Variant
    Const conPropNotFoundError = 3270

    Set dbs = CurrentDb
    On Error GoTo Change_Err
    dbs.Properties(strPropName) = varPropValue
    ChangeProperty = True

Change_Bye:
    Exit Function

Change_Err:
    If Err = conPropNotFoundError Then
        Set prp = dbs.CreateProperty(strPropName, _
            varPropType, varPropValue)
        dbs.Properties.Append prp
        Resume Next
    Else
        ChangeProperty = False
        Resume Change_Bye
    End If
End Function

VBEのイミディエイトウィンドウから SetBypassProperty を実行するか、適切なタイミングで呼び出します。設定の変更は「次にデータベースを開いたときから」有効になります。開いたまま設定しても、その場では効きません。

デバッグ中は AllowBypassKeyTrue に戻しておく必要があります。公式ドキュメントも「アプリケーションをデバッグするときはAllowBypassKeyをTrueにしておくこと」と明記しています。False のまま作業を続けると、Shift起動が使えない状態でデバッグすることになります。

AllowBypassKeyが万全の保護でない理由

AllowBypassKeyは「Shiftキーを押しながら開く」という操作を無効化するだけで、accdbファイルそのものへのアクセスを制限するものではありません。いくつかの点で保護として不完全です。

まずAllowBypassKeyを False にしたとしても、AllowBypassKeyはAccessがShiftキーによる起動時プロパティとAutoExecマクロの回避を許可するかどうかを指定するデータベースプロパティであり、ファイル自体へのアクセスを遮断するものではありません。当社の確認では、データベースパスワードなど別の保護がないaccdbについては、AllowBypassKeyだけでは別のAccess VBAプロジェクトからのインポートやDAOによるPropertiesの操作を防ぐことはできません。

また、AllowBypassKeyをFalseに設定していても、設定値自体はデータベースのPropertiesコレクションに格納されているに過ぎず、パスワードなどの保護がない状態では同様の手順で書き換えられます。

さらに実務で問題になるケースとして、AllowBypassKeyをFalseにしたうえにナビゲーションウィンドウを非表示・カスタムリボンのみに制限すると、設定ミスがあったときに開発者自身がデータベースにアクセスできなくなります。この「締め出し」状態への対処として、VBEのイミディエイトウィンドウが使えるならAllowBypassKeyをTrueに戻すVBAを実行する方法があります。それも使えない場合は、別のaccdbから DBEngine.Workspaces(0).OpenDatabase で対象ファイルをDAO.Databaseとして開き、そのPropertiesコレクションでAllowBypassKeyをTrueに書き換える方法があります(ただしデータベースパスワードが設定されている場合は接続時にパスワードが必要です)。変更は対象ファイルを閉じて次回開いたときから有効になります。

VBAソースコードを残さずフォーム・レポートの設計変更を制限したい場合はaccde形式への変換、テーブルデータを含めてファイル全体を暗号化したい場合はデータベースパスワードの設定を組み合わせる方法があります。ただしどちらにも保護の範囲に限界があります。詳細はパスワード保護の限界の記事で整理しています。

手元のデータベースがどの程度の保護状態にあるか確認したい場合は、無料の解析可否チェックでファイルの構成を事前に確認できます。

よくある質問

Q. Shiftキーを押しながら開いたら、いつも通りフォームが出てしまいます。なぜですか。

いくつか考えられます。一番多いのは、Shiftを押すタイミングが遅かったケースです。ファイルをダブルクリックした瞬間から、Accessが完全に起動してすべてのセキュリティメッセージを閉じ終わるまで、Shiftを押し続ける必要があります。もう一つは、そのデータベースでAllowBypassKeyがFalseに設定されているケースです。その場合はShift起動は機能しません。

Q. AllowBypassKeyをFalseにしたまま自分もフォームを回避できなくなりました。どうすればいいですか。

VBEのイミディエイトウィンドウ(Ctrl+G)にアクセスできるなら、そこから直接 ChangeProperty "AllowBypassKey", 1, True を実行するとShift起動が再び使えるようになります。VBEにもアクセスできない場合は、別のaccdbから DBEngine.Workspaces(0).OpenDatabase で対象ファイルをDAO.Databaseとして開き、そのPropertiesコレクションを操作する方法があります(データベースパスワードが設定されている場合は接続時にパスワードが必要です)。いずれも技術的な手順が必要で、ファイルのバックアップを取ってから作業してください。

Q. AllowBypassKeyをFalseにすれば、テーブルやクエリを直接見られなくなりますか。

なりません。AllowBypassKeyはShift起動という操作を無効化するだけで、accdbのテーブルやクエリへのアクセス自体を制限するものではありません。テーブルの内容を保護したい場合はデータベースパスワードの設定が必要です。VBAソースコードを残さずフォーム・レポート・モジュールの設計変更を制限したい場合はaccde形式への変換が有効ですが、テーブルやクエリへのアクセス自体は防げません。詳細はaccde/mde解析の記事を参照してください。

Q. AutoExecマクロをShift起動で回避されないようにできますか。

AllowBypassKeyをFalseに設定すれば、Shift起動でAutoExecが飛ばされることはなくなります。ただしVBAからAutoExecの代わりにフォームのOpenイベントで処理を行う設計のほうが制御しやすいケースも多く、マクロとVBAの使い分けについてはマクロとVBAの入門記事で整理しています。

触れないAccessが「診断できるか」だけ、確かめませんか。

顧客データは送信不要。発注の義務もありません。

約2分・ファイル送信不要・発注義務なし/説明はオンライン・売り込みはしません