Accessの/decompileとは｜VBA肥大化・不安定化への対処と注意

結論：/decompileはVBAの肥大化・不安定化を解消する可能性があるが、一般スイッチ一覧には未掲載のスイッチです

/decompile はMicrosoft Accessの起動時に指定できるコマンドラインスイッチで、VBAのコンパイル済みバイトコード（Pコード）をデータベースファイルから取り除き、その後VBEの「デバッグ」→「コンパイル」で実行したときに、ソースコードからPコードをゼロから再生成させる処理を行います。VBAが肥大化して動作が遅くなったとき、あるいは「Compile error」が頻発するのにコード上は問題が見当たらないときに、当社で試みることがある対処手順の一つです。

Microsoftの一般的なコマンドラインスイッチ一覧（/compact、/excl、/ro、/runtime、/x 等を掲載）には /decompile は含まれていません。一方、MicrosoftのサポートKB記事（KB814858: Access が MDE/ACCDE ファイル作成時に応答しなくなる問題）では、VBA Pコードの破損を回避する回避策として /decompile スイッチが手順に記載されています。つまり「Microsoftのサポート文書に登場するスイッチだが、一般スイッチ一覧には掲載されていない」という位置づけです。海外のAccess MVPコミュニティ（isladogs.co.uk など）では「undocumented but very useful」と呼ばれてきましたが、より正確には「サポート文書には登場するが、通常のスイッチ一覧には未掲載のスイッチ」です。

この記事では、/decompileが何をする処理なのか、どういうときに試す価値があるのか、正しい手順、そしてバックアップが必須な理由を整理します。バックアップの取り方はバックアップ設計の記事を、最適化/修復（/compactスイッチ）の詳細は最適化/修復の記事を参照してください。

VBAのPコードとは何か、なぜ肥大化するのか

AccessのVBAはコードを書いたとき（または保存・コンパイル時）に、そのソースコードから中間バイトコード（Pコード）を生成し、データベースファイル内に格納します。実行時はこのPコードを読み込んで動かすため、毎回ソースから解析する必要がなく高速に起動できる仕組みです。

問題が起きるのは、編集・保存・バージョン変更を繰り返した結果、Pコードとソースコードが微妙にずれてくる場合です。不要になったPコードのページがファイル内に残り続け、ファイルサイズが増え、コンパイルエラーや不可解な動作の原因になることがあります。Access MVPの Colin Riddington 氏（isladogs.co.uk）はこれを「コードの破損（code corruption）」と表現し、/decompile でPコードを一括削除してゼロから再コンパイルすることで解消できる場合があると解説しています。

ただし、PコードのずれがVBAの肥大化や不安定化の唯一の原因とは限りません。クエリの設計・データ量・インデックスの状態など別の要因が重なっていることもあり、/decompileで解決しないケースもあります。

/decompileを試す価値がある場面

当社の実務では、次のような状況で/decompileを検討することがあります。

逆に、VBAを一切使っていないデータベースでは/decompileを実行しても意味はほぼありません。テーブルとクエリだけのシンプルなファイルで動作が遅い場合は、インデックス設計やデータ量の問題を先に確認してください。

正しい手順：バックアップ→decompile→再コンパイル→最適化

/decompileを使うときは以下の順番を守ってください。飛ばすと「Pコードを削除したままコンパイルされていない状態」になります。

1. バックアップを取る（必須）。一般スイッチ一覧に未掲載のスイッチのため、通常のサポート窓口で案内を受けられるかは確認できません。accdbをコピーして別フォルダに退避してから作業を始めてください。
2. 他のユーザーに接続を切ってもらう。共有データベースの場合、他の人が接続したまま実行すると問題が起きる場合があります。
3. Shiftキーを押しながらコマンドを実行し、Accessが完全に起動するまで押し続ける（スタートアップコードを回避）。スタートアップ時にVBAが動くデータベースでは、意図せずPコードが再生成されてしまいます。Microsoftの公式手順では「Shiftキーを押しながらデータベースを開く。セキュリティメッセージを閉じる間もShiftキーを押し続けることが必要」と説明しており、コマンド実行と同時にShiftを押し始め、完全に起動するまで保持してください。
4. 上の状態でコマンドプロンプトまたはショートカットから /decompile を実行する。構文は以下のとおりです。

   "C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE" "C:\path\to\your.accdb" /decompile

   Accessのインストールパスはバージョンや環境によって異なります。msaccess.exe の場所は、Accessのショートカットを右クリックして「プロパティ」→「リンク先」で確認するのが確実です。
5. VBEを開いて手動でコンパイルする。Alt+F11でVBEを開き、「デバッグ（Debug）」メニュー→「〔プロジェクト名〕のコンパイル」を実行します。エラーが出た場合は、表示されたエラー内容を確認した上で、コードの誤り・参照設定の欠落・環境差（32/64ビット差など）を修正します。
6. ファイルを保存してAccessを閉じる。
7. 最適化/修復を実行する（/compactスイッチまたはUIから）。decompile後はPコードが削除されたページが空き領域として残るため、最適化でファイルを縮小します。公式に記載された /compact スイッチを使う場合：

   "C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE" "C:\path\to\your.accdb" /compact

   または、Accessを開いて「データベースツール」→「データベースの最適化/修復」から実行してください。最適化の詳細は最適化/修復の記事を参照してください。

なお、nolongerset.com の Mike Wolfe 氏は /decompile /compact /repair を1コマンドで連続実行するパターンを個人の配布前運用として紹介しています。ただし、複数スイッチの組み合わせはMicrosoftがサポートする構文ではないことに注意が必要です。当社では、手動コンパイル（手順5）を間に挟む上記の順番を推奨しています。コンパイルせずに最適化だけ行っても、次回起動時にAccessが自動コンパイルする際に問題が出るリスクが残るためです。

/decompileを使う前に知っておくべきリスク

一般スイッチ一覧に未掲載のスイッチを使う以上、いくつかの点は承知した上で使うことになります。

まず、一般スイッチ一覧に未掲載であるという点です。MicrosoftのKB記事（KB814858）では回避策として記載がありますが、通常のコマンドラインスイッチ一覧には含まれておらず、一般的なサポート窓口での案内対象かは確認できません。当社での経験では深刻な問題が起きたことはありませんが、確率ゼロとは言い切れません。

次に、バックアップなしで実行すると後戻りができないことです。/decompileはPコードを書き換えるためファイル自体が変更されます。エラーが出たり動作がおかしくなった場合、バックアップなしでは元の状態に戻せません。

また、VBAコードに潜在的なコンパイルエラーが隠れていた場合、/decompile後の手動コンパイルで初めてそのエラーが表面に出ます。これは「バグが現れた」のではなく「もともとPコードのずれで隠れていたエラーが見えるようになった」状態です。修正すること自体は良いことですが、急いで作業しているときは時間がかかる場合があります。

ファイルの破損が疑われる場合は、/decompileより先にAccessファイルが破損したときの修復手順を試すことをお勧めします。修復で解決しない場合に/decompileを検討する流れが安全です。

手元のデータベースで/decompileを試す前に、そもそも解析や修復が可能な状態かを確認したい場合は、ファイルを送らずに無料の解析可否チェックで事前確認できます。

よくある質問

Q. /decompileは公式のコマンドですか。

一般的なコマンドラインスイッチ一覧には含まれていません。ただし、MicrosoftのサポートKB記事（KB814858）ではVBAコード破損の回避策として手順に記載されており、「一切公式に存在しない」とは言い切れません。正確には「一般スイッチ一覧には未掲載だが、Microsoftのサポート文書に使用例がある」という位置づけです。海外のMVPコミュニティが「undocumented but very useful」と呼んできたのも、この曖昧な立ち位置を反映しています。

Q. /decompileを実行するとVBAのソースコードは消えますか。

消えません。/decompileが削除するのはコンパイル済みのPコード（バイトコード）だけです。標準モジュールやクラスモジュールのソースコード自体はそのままファイル内に残ります。その後VBEで手動コンパイルすると、ソースコードから新しいPコードが生成されます。

Q. /decompileと最適化/修復（/compact）は同じことをしていますか。

別の処理です。/compact（一般スイッチ一覧に記載あり）は未使用領域を除去してファイルを縮小し、軽微な破損を修復する処理です。/decompile（一般スイッチ一覧には未掲載だがKB記事に使用例あり）はVBAのPコードを削除して再コンパイルさせる処理です。目的も対象も違いますが、/decompile実行後に/compactを続けて実行するのが推奨される手順です。

Q. /decompileを定期的に実行するべきですか。

通常は必要ありません。問題が起きたとき、または配布前のクリーンアップとして実行するものです。Pコードのずれは日々の使用でも少しずつ生じる可能性はありますが、それが目に見えるパフォーマンス問題や不安定さにつながるかどうかはデータベースの規模や使い方によります。動作が安定しているなら、わざわざ実行する必要はないと考えています。