Microsoft 365 版Accessで「パフォーマンス アナライザー」「データベース ドキュメント」「テーブルの分析」などの解析ツールを開くと、マウス操作だけでFldListMouseMoveエラーやActiveX読み込み失敗が発生し、画面が操作できなくなることがあります。空の新規データベースでも再現する場合は、DB側ではなくAccess更新由来の不具合を疑うのが近道です。
Accessの解析ツールで「マウス操作だけ」でエラーが出る症状とは
今回のトラブルは、フォームやクエリを開いたときではなく、Accessに用意されている解析系のツール（ウィザード/ダイアログ）を開いた瞬間から発生するのが特徴です。特に「マウスを動かしただけ」「一覧の上にカーソルを乗せただけ」「クリックしただけ」でエラーが出るため、作業が一切進まなくなります。
影響を受けやすいツール例は次のとおりです。
- Performance Analyzer（パフォーマンス アナライザー）
- Database Documentation（データベース ドキュメント）
- Analyze Tables（テーブルの分析）
よく見られるエラーメッセージ例：
- 「FldListMouseMove の式がエラーを返した」
- 「フォーム/レポート上の ActiveX コントロールの読み込みに失敗」
- 「式はマクロ/ユーザー定義関数/イベントプロシージャとして評価できない」
ここで重要なのが、新規作成の空データベースでも再現するケースがある点です。これが確認できた時点で、VBAや参照設定、特定フォームの壊れなどよりも、Access本体（Microsoft 365 Appsの更新）側の問題として切り分けるのが合理的になります。
結論：空DBでも解析ツールだけ壊れるなら「Access更新不具合」の可能性が高い
Accessの解析ツールは、内部的にはウィザード用の画面（フォーム相当）や各種コントロールを使って構成されています。つまり、ユーザーDBの設計やコードが一切なくても、Access側のUI処理やコントロール読み込みで不具合が起きると、ツール操作が成立しません。
実際の現場では、特定の更新（例：Version 2507 の 32-bit）適用後に、複数環境で同様の症状が同時多発した、というパターンが見られます。こうした状況では、利用者側のDB修正や修復を繰り返しても改善しづらく、ロールバック（ダウングレード）が最短の回避策になりがちです。
| 判定のポイント | DB起因の可能性が高い | Access/環境起因の可能性が高い |
|---|---|---|
| 新規の空DBで再現 | 低い | 高い |
| 特定のDBだけで再現 | 高い | 低い |
| 解析ツール以外は概ね正常 | どちらもあり得る | 高い（更新不具合の典型） |
| Officeのオンライン修復で改善 | 改善する場合あり | 改善しないことが多い（同じビルドが再適用されるため） |
最短で切り分けるチェック：まず「空DBで再現するか」を確認
原因を早く確定するための切り分けは、次の順で行うのが効率的です。すでに空DBで再現している場合は、チェック項目の多くが「確認済み」になりますが、記事として全体像を整理しておきます。
- 空の新規データベースで再現するか 「作成 → 空のデータベース」を作り、解析ツール（パフォーマンス アナライザー等）を開いて、マウスオーバーだけでエラーが出るか確認します。
再現するなら、DB側ではなくAccess側の問題に寄せて考えます。 - Accessをセーフモード相当で起動して差が出るか COMアドインや外部ツールが絡むケースを排除します。社内PCでセキュリティ系の常駐が強い場合、ここで症状が変わることがあります。
（ただし今回のタイプは、セーフモードでも改善しないことが多いです） - Accessの「バージョン/ビルド/更新チャネル/32bit・64bit」を控える 後述のロールバックやMicrosoftへの報告に必須です。現象が「いつから」起きたか（直近の更新後か）もセットで確認します。
- 別PC（別プロファイル）で再現するか 同一ビルドのAccessが入っている別端末でも再現するなら「更新不具合」の確度が上がります。
まず確認：Accessのバージョン・ビルド・更新チャネル・32/64bit
症状が出ている環境では、以下をメモしてください。組織管理（MECM/Intune/GPO）環境の場合、情シスへ渡す情報としてもそのまま役立ちます。
| 確認項目 | 確認場所（例） | メモする内容 |
|---|---|---|
| バージョン/ビルド | Access → ファイル → アカウント → 「Accessについて」 | Version XXXX / Build XXXXX.XXXXX の形で控える |
| 更新チャネル | 同上（アカウント画面に表示されることが多い） | Current/Monthly Enterprise/Semi-Annual など |
| 32-bit / 64-bit | 「Accessについて」の表示、またはインストール情報 | 32-bitか64-bitか（特にActiveX絡みで重要） |
| 発生開始のタイミング | 更新履歴、更新日、直前の更新 | 「更新した翌日から」など分かる範囲で |
今回のように「新規DBでも解析ツールだけが壊れる」タイプでは、特定バージョンのAccess（Microsoft 365 Apps）の更新がトリガーになっていることが多く、ここを押さえておくと対応が一気に楽になります。
短期で効く回避策：直前のOffice/Accessビルドへロールバック（ダウングレード）
結論から言うと、同様の症状では「直前の正常だったビルドに戻す」のがもっとも即効性があります。オンライン修復は「同じビルドを入れ直す」挙動になりやすく、更新不具合が原因だと改善しないことが珍しくありません。
ロールバックの代表的な方法は次の2つです。
- 方法A：Click-to-Run（Microsoft 365 Apps）を特定バージョンへ更新（=実質ダウングレード）する
- 方法B：Office Deployment Tool（ODT）で指定バージョンを展開する（組織管理向き）
ここでは、個人PC～小規模環境でも比較的使われる「方法A」を中心に記載します。社内端末で更新が管理されている場合は、方法Bか情シス経由が安全です。
事前注意：ロールバック前に確認しておくこと
- すべてのOfficeアプリ（Access/Excel/Outlook等）を終了してから実行します。
- 可能なら作業前にPCを再起動し、バックグラウンドでOffice更新が走っていない状態にします。
- ロールバックは「不具合回避」を優先する手段です。修正版が出たら速やかに更新できるよう、状況を記録しておきます。
- 組織管理PCの場合、勝手に操作するとポリシー違反になる可能性があるため、情シスの指示に従うのが無難です。
方法A：OfficeC2RClient.exeで特定ビルドへ戻す（Click-to-Run）
Microsoft 365 Apps（クリックトゥラン）環境では、Officeの更新コンポーネントを使い、指定のバージョンへ「更新」する形で戻すことがあります。典型的なコマンド例は次のとおりです。
| Officeのビット数 | 実行ファイルの例 | 備考 |
|---|---|---|
| 64-bit Office | C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe | 64-bit Windows + 64-bit Officeの一般的な構成 |
| 32-bit Office | C:\Program Files (x86)\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe | 64-bit Windowsに32-bit Officeが入っている場合に多い |
コマンド例（ビルド番号は一例）：
"C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe" /update user updatetoversion=16.0.18925.20184ポイント：
- updatetoversion に指定するのは「16.0.xxxx.xxxx」形式のバージョンです。
- 例として、解析ツールの不具合が出る更新の直前にあたる Version 2506（Build 18925.20184） へ戻すと改善した、という報告があります。
- 環境の更新チャネルによって「戻せるビルド」「存在するビルド」が異なるため、社内環境では情シスがチャネル/配布を把握していることが多いです。
ロールバック手順（分かりやすい手順）
- Accessを含むOfficeアプリをすべて終了する
- 「Windowsの検索」で cmd を探し、管理者として実行する
- 上記のOfficeC2RClient.exeコマンドを実行（パスは環境に合わせる）
- 更新処理が完了したらPCを再起動する
- Accessを起動し、空DBで解析ツールが操作できるか再テストする
うまくいかない時のチェック
- パス違い：Program Files / Program Files (x86) のどちらにあるか確認
- 管理者権限：管理者として実行しているか
- 社内管理：更新が組織で固定されていて指定バージョンに戻せない
- チャネル差：同じ「Version 2506」でもチャネルによりビルドが異なる/存在しないことがある
方法B：Office Deployment Tool（ODT）で指定バージョンを適用する（組織・検証向け）
ODTは「特定チャネル・特定バージョンでMicrosoft 365 Appsを展開する」ための方法です。社内PCで検証用に一時的に戻す、パイロット端末だけ戻す、といった運用に向いています。
構成XMLのイメージ（概念例）：
<Configuration>
<Add OfficeClientEdition="32" Channel="Current" Version="16.0.18925.20184">
<Product ID="O365ProPlusRetail">
<Language ID="ja-jp" />
</Product>
</Add>
<Updates Enabled="TRUE" />
<Display Level="None" AcceptEULA="TRUE" />
</Configuration>ODTは環境差や運用ルールの影響を受けやすいので、組織利用では手順を固定化したうえで実施するのがおすすめです。
ロールバック後にやるべきこと：自動更新で「再発」しないようにする
ロールバックで直っても、何もしないと次回の自動更新で問題のあるビルドへ戻り、同じトラブルが再発することがあります。修正版が配信されるまでの間は、更新の扱いを調整しておくと安心です。
手軽にできる対策
- Access（Office）→ ファイル → アカウント → 更新オプション で、更新の停止/一時停止が可能か確認する
- 社内PCでメニューが出ない場合は、組織ポリシーで管理されている可能性が高いので情シスに相談する
- 更新を止めた場合は、修正版が出たタイミングで必ず更新を再開する（セキュリティの観点で重要）
更新チャネルの見直し（安定性を重視したい場合）
Microsoft 365 Appsには更新チャネルがあり、一般に「新機能を早く受け取るチャネル」ほど不具合の影響を受けやすくなります。業務でAccessを使う場合、更新頻度と安定性のバランスを見てチャネルを選ぶのが大切です。
| チャネル（例） | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| Current Channel | 新機能が比較的早く来る | 最新機能を優先、検証体制がある | 更新起因の不具合に当たりやすいことがある |
| Monthly Enterprise Channel | 企業向けに安定性を意識 | 業務利用で安定性を重視 | 新機能反映はCurrentより遅れる |
| Semi-Annual Enterprise Channel | 更新頻度が比較的低い | 大規模運用、変更を最小化したい | 利用できる環境が限定される場合がある |
チャネル変更は組織管理下では勝手に変えられないことが多いので、社内PCは必ず情シスの運用に合わせてください。
恒久対応：修正版の更新が来たら「固定解除→アップデート」で解消する
更新不具合が原因の場合、最終的にはMicrosoft側の修正が入ったビルドへ更新して解決します。ロールバックで一時回避している間は、以下の流れが安全です。
- 現象が出ていたビルド、ロールバック後のビルドをメモしておく
- 修正版の配信（更新）を確認したら、更新を再開して最新ビルドへアップデート
- 空DBで解析ツールを開き、マウス操作でエラーが出ないことを確認
- 問題が再発しないことを数日確認したうえで、通常運用へ戻す
「いつ修正版が来たか」をチーム内で共有するためにも、更新に関するメモ（Version/Build/チャネル）は残しておくと後で効きます。
Microsoftへのフィードバック：再現条件を添えて送ると通りやすい
この種の不具合は、ユーザー側の報告が多いほど優先度が上がりやすい傾向があります。Accessの[ヘルプ] → [フィードバック]から、できるだけ具体的に送るのがおすすめです。
フィードバックに入れると良い情報：
- AccessのVersion/Build、更新チャネル、32/64bit
- Windowsのバージョン
- 再現手順（「空DB→パフォーマンス アナライザー→マウスオーバーでエラー」など）
- 表示されたエラー文（FldListMouseMove、ActiveX読み込み失敗 等）
- 可能ならスクリーンショット
社内で複数台に発生している場合は、代表者がまとめて状況を添えて報告すると、調査の入り口が作りやすくなります。
補足：もし「特定のDBだけ」で起きるなら、DB側の要因も並行して確認
ここまでの内容は「空DBでも解析ツールだけが壊れる」ケースを中心に解説しました。ただし、もし特定のデータベースだけで発生しているなら、次のようなDB側要因も候補になります。
| チェック項目 | 確認方法 | 狙い |
|---|---|---|
| VBAのコンパイル | VBE（Alt+F11）→ デバッグ → コンパイル | 潜在的なコンパイルエラーを顕在化させる |
| 参照設定の「MISSING」 | VBE → ツール → 参照設定 | 壊れた参照がイベント評価エラーを誘発するのを防ぐ |
| ActiveX/OCXの32/64bit不一致 | 利用しているコントロールのビット数確認 | ActiveX読み込み失敗の典型原因を排除 |
| フォーム/レポートの破損 | 新規フォームへ移植、エクスポート/インポート | オブジェクト破損を切り分け |
| アドイン/常駐ツール | アドイン無効、セキュリティ例外の見直し | 外部干渉によるUI不具合を排除 |
参照設定（MISSING）があると起きやすい症状
参照設定が壊れていると、イベント評価時に「式はマクロ/ユーザー定義関数/イベントプロシージャとして評価できない」といったメッセージが出ることがあります。まずは以下をチェックします。
- VBEを開く（Alt + F11）
- 「ツール」→「参照設定」
- MISSING: が付いている項目があれば原因になり得るため、必要に応じて外す/正しい参照へ差し替える
ただし今回のテーマのように空DBでも解析ツールで同症状が出る場合、参照設定の問題である可能性は低く、Access更新不具合側に寄せて考えるのが現実的です。
よくある質問（Access解析ツールのFldListMouseMove/ActiveXエラー）
オンライン修復をしても直りません。やり方が悪いのでしょうか？
オンライン修復が悪いわけではありません。ただし更新不具合が原因の場合、オンライン修復は「同じバージョン/ビルドを再インストール」する動きになりやすく、根本原因が残るため改善しないケースが出ます。空DBでも再現するなら、ロールバックや修正版の適用が近道です。
なぜマウスオーバーだけでエラーになるのですか？
解析ツールの画面は、内部で一覧やボタン等のUIを持ち、マウス移動のタイミングでツールチップ表示や選択状態の更新などを行います。その際にイベント（例：FldListMouseMove）が走り、更新不具合やコントロール読み込みの問題があると、クリック以前の段階でもエラーが出ることがあります。
32-bitと64-bitは関係ありますか？
ActiveX絡みのエラーが出る場合、一般論としては関係します（32/64bit不一致は典型原因です）。ただし今回のように「新規DBでも解析ツールで発生」「特定更新後から一斉に発生」という状況では、特定ビルドの32-bitで多発など、更新不具合の形で表面化することがあります。
ロールバックは安全ですか？
業務継続のための現実的な回避策ですが、古いビルドに戻す以上、セキュリティ修正が最新ではなくなる可能性があります。可能なら修正版が来たら速やかにアップデートし、ロールバック状態を長期間放置しない運用がおすすめです。組織管理端末は必ず情シス判断に従ってください。
まとめ：解析ツールだけ壊れたら「更新不具合」を疑い、バージョン管理で復旧する
Accessの解析ツール（パフォーマンス アナライザー、データベース ドキュメント、テーブルの分析）で、マウス操作だけでFldListMouseMoveやActiveX読み込み失敗が出て操作不能になる場合、空DBでも再現するかが最大の分岐点になります。
- 空DBでも再現 → Access（Microsoft 365 Apps）の更新不具合を疑う
- 短期回避 → 直前のビルドへロールバックが効きやすい
- 中長期 → 修正版が配信されたらアップデートし、更新停止は解除する
- 並行して → フィードバック送信、更新チャネルの見直し、社内運用への連携
「DBが悪いのでは？」と疑って時間を溶かしやすい症状ですが、再現条件を正しく押さえると、対処の最短ルートが見えてきます。
コメント