AutoCAD VBAの限界を突破せよ：OSレベルで制御する「ウィンドウ・フォーカス」の実装術
AutoCADのAPIを叩き、Excelと連携させる。これは自動化の王道だが、多くのエンジニアがここで躓く。
「データは送った。だが、ユーザーはExcelがどこにあるか見失っている」。
COMオブジェクトの `AppActivate` は、時に気まぐれだ。特にマルチモニター環境や、AutoCADとExcelが複雑なZオーダー（重なり順）を形成している場合、その挙動は信用に値しない。
今日は、AutoCAD VBAの枠組みから一歩踏み出し、Windows APIの深淵に触れる。`FindWindow` と `SetForegroundWindow` を用い、OSの意志を強制的にねじ伏せる手法を授けよう。
—
1. なぜ「COM操作」だけでは不十分なのか
初心者は `ExcelApp.Visible = True` や `AppActivate` に頼る。だが、これが通用するのは「Excelがアクティブ化を拒絶しない環境」だけだ。
- Zオーダーの壁: Windowsは、現在アクティブなアプリケーションのフォーカスを奪うことを、ユーザー体験の保護という名目で厳しく制限している（`SetForegroundWindow` の制限）。
- 非同期の罠: AutoCAD側で重い計算や描画処理を行っている最中、Excelへの制御権の受け渡しは不安定になる。
真のエンジニアは、OSレベルのハンドル（HWND）を特定し、直接「そこへ行け」と命令を送る。これが、バグを排除し、ユーザーに確実なフィードバックを返す唯一の解だ。
—
2. プロダクションコード：APIによる確実な制御
以下のコードは、単にウィンドウを呼ぶだけでなく、最小化されている場合に復元するロジックまで含んでいる。堅牢なシステムには、常に「例外」への配慮が必要だ。
‘ 標準モジュールに記述すること
Option Explicit
‘ Windows APIの宣言：これらはOSの深部に直接命令を下すためのパスポート
If Win64 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Private Declare PtrSafe Function SetForegroundWindow Lib “user32” (ByVal hwnd As LongPtr) As Long
Private Declare PtrSafe Function ShowWindow Lib “user32” (ByVal hwnd As LongPtr, ByVal nCmdShow As Long) As Long
Else
‘ 32bit環境用（レガシーな現場用）
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function SetForegroundWindow Lib “user32” (ByVal hwnd As Long) As Long
Private Declare Function ShowWindow Lib “user32″ (ByVal hwnd As Long) As Long
End If
Private Const SW_RESTORE As Long = 9
”’
”’
Public Sub BringExcelToFront(ByVal windowTitle As String)
Dim hwnd As LongPtr
‘ Excelのウィンドウクラス名は通常 “XLMAIN” だが、タイトルで特定するほうが確実
hwnd = FindWindow(“XLMAIN”, vbNullString)
If hwnd <> 0 Then
‘ 最小化されている場合は復元
Call ShowWindow(hwnd, SW_RESTORE)
‘ フォーカスを強制奪取
Call SetForegroundWindow(hwnd)
Else
MsgBox “対象のExcelウィンドウが見つかりません。”, vbCritical
End If
End Sub
—
3. 実務で「負けない」ための設計思想
このコードを組み込む際、以下のポイントを遵守せよ。これが「趣味のスクリプト」と「業務システム」を分かつ境界線だ。
① インターフェースの独立性
`BringExcelToFront` は、ビジネスロジック（データの計算処理など）と分離せよ。データの転送が終わった直後の「完了通知」としてのみ呼び出すのが、疎結合なアーキテクチャの基本だ。
② ファイルロックとデータベースの同期
AutoCADからExcelへデータを流し込む際、Excelファイルが開かれているか、あるいは「読み取り専用」になっていないかを確認するロジックを必ず挟め。`SetForegroundWindow` でユーザーを呼び出した直後に「保存できませんでした」というエラーダイアログを出すのは、最悪のユーザー体験だ。
③ ユーザーの操作を奪いすぎない
APIによる強制フォーカスは強力だが、多用は禁物だ。ユーザーが別の作業中に割り込むと、入力内容を消失させるリスクがある。「処理が完了したタイミング」に限定して使用するという規律をプロジェクト全体で守れ。
—
最後に：エンジニアとしての矜持
AutoCAD VBAは古臭いと言われることがある。だが、それは使い手がその深淵に潜っていないからに過ぎない。Windows APIを組み合わせ、AutoCADをOSの一部として調律できる者こそが、真の自動化エンジニアだ。
コードは単に動けばいいのではない。メンテナンスする未来の自分、あるいは現場のユーザーが「なぜここでこのAPIが必要だったのか」を理解できるコードを書け。
さあ、スクリプトを書き換え、あなたのツールを「ただのプログラム」から「信頼できる相棒」へと進化させたまえ。君ならできるはずだ。
