MacでAppleScriptやScripting Bridgeを使った自動化が、突然-1712で止まることがあります。対象アプリのプロセスは存在し、権限も以前は通っていたのに、簡単な一覧取得さえ返らない。この時にスクリプトを書き換え続けると、原因が対象アプリのハングでも調査が遠回りになります。
結論：AppleEvent経路とアプリ内部処理を別々に確認する
-1712はAppleEventの応答待ちが時間切れになった状態です。最初に、プロセス生存、最小AppleEvent、対象アプリ固有の一覧取得、System Events経由、データ保存先の読み取りを分けます。複数のAppleEvent経路が同じように止まり、対象アプリの再起動後に復旧するなら、スクリプトや権限ではなく対象アプリ側の応答停止へ原因を絞れます。
エラー-1712が示すこと
Appleの開発資料では、errAETimeout = -1712は「Apple event timed out」と定義されています。つまり、送信側が期待した時間内に返信AppleEventを受け取れなかったことは分かりますが、原因が権限、対象アプリ、処理負荷、ダイアログ待ち、データストアのどれかまでは示しません。
既定の待機時間を長くすれば必ず直るわけでもありません。AppleのAppleEventタイムアウト定数では既定値は約1分です。対象アプリが応答不能なら、待機を無期限にすると自動化全体が戻らず、次回処理や監視まで止める危険があります。
最初に5層へ分ける
| 層 | 確認すること | 分かること |
|---|---|---|
| プロセス | 起動中、CPU、ウィンドウ、前面操作 | 存在と応答は別だと分ける |
| AppleEvent | activate、version、件数取得 | 最小イベントが返るか |
| 対象API | アカウント、文書、項目一覧 | 特定オブジェクトだけ重いか |
| 補助経路 | System EventsやUI操作 | 対象アプリ全体の応答停止か |
| データ処理 | SQLite、ファイル、ネットワーク | AppleEvent外でも取得できるか |
「プロセスがあるから正常」「CPU使用率が低いから待てば返る」とは限りません。プロセスが生きたままイベントループが応答しない場合、見た目は起動中でもAppleEventは全滅します。逆に、最小イベントは返るが特定一覧だけタイムアウトするなら、データ量や壊れた項目、同期、検索条件を疑えます。
確認手順1：最小疎通から始める
最初から全件走査や複雑な検索を実行せず、対象アプリが短時間で返せる小さな問い合わせを試します。activateだけでは前面化しても内部APIの応答性を確認できないため、バージョン、最上位オブジェクトの件数、先頭1件の名前などを段階的に取得します。
- 対象アプリのプロセスが存在するか確認する
- 短いタイムアウトでアプリの
versionなど最小値を取る - 最上位の一覧件数だけを取る
- 先頭1件、限定フォルダ、限定期間へ広げる
- 全件取得は最後にし、各段階の秒数と失敗位置を記録する
権限ダイアログが背面に出ている場合もあります。システム設定のオートメーション権限を確認しますが、以前成功していた許可を闇雲に削除・再登録しません。権限変更は原因を増やすため、最小疎通と現在の許可状態を記録してから判断します。
確認手順2：対象アプリとSystem Eventsを比較する
対象アプリ固有のAppleScript APIと、System Events経由のUI要素取得は別経路です。固有APIだけが止まり、UI要素は取得できるなら、特定オブジェクトの処理やアプリ内部データを疑います。両方が同じようにタイムアウトし、画面操作にも反応しないなら、対象アプリ全体のハングの可能性が高まります。
実測例：4回連続失敗後、再起動で復旧
定時のメール確認処理で、対象アプリはプロセス生存・CPUほぼ0%でしたが、アカウント一覧の最小取得とSystem Events経由の両方が-1712になりました。4回連続で同じ失敗を確認し、状態ファイルを進めず停止。Mac再起動後は同じスクリプトと権限のまま復旧し、停止期間の新着も再取得できました。この結果から、スクリプトや認証ではなく対象アプリの応答停止と判断できました。
確認手順3：データストア経路は読み取り専用で試す
対象アプリが内部でSQLiteやファイルを使っていても、すぐに直接更新へ進まないでください。AppleEventが止まっている時にアプリのデータベースを書き換えると、ロック、同期、スキーマ差で破損範囲を広げる恐れがあります。必要ならコピーしたデータから読み取り専用で件数や最新時刻だけを確認します。
- 対象アプリがデータを書き込み中ではないか
- データベースや状態ファイルのコピーを作ったか
- スキーマやテーブル名を現行バージョンで確認したか
- 個人情報や本文をログへ残さず、件数と時刻だけにできるか
- 直接読取が失敗しても、アプリの正規APIへ戻せるか
データストアから読めるのにAppleEventだけ返らない場合、データそのものの消失ではなく、アプリのイベント処理やオブジェクト変換が詰まっている可能性があります。ただし、直接読取は診断用であり、通常運用の恒久経路へ安易に置き換えません。
失敗時に状態ファイルを進めない
定期監視では、最後に成功した時刻や処理済みIDを状態ファイルへ保存することがあります。タイムアウトした回でも「実行済み」として時刻を進めると、復旧後に停止期間のデータを飛ばします。取得、分類、保存、状態更新を分け、最後まで成功した時だけチェックポイントを進めます。
- 開始時に前回成功時刻を読み、作業用変数へコピーする
- 取得結果を一時領域で検証する
- 重複排除キーを使い、同じ範囲を再実行しても二重処理しない
- 全工程成功後にだけ新しい成功時刻を原子的に保存する
- 失敗時は前回値を保持し、エラーコードと再実行条件を残す
復旧後の二重実行を防ぐ考え方は定期タスクの二重実行を防ぐ確認手順、判断と機械処理を分ける設計は生成AIワークフローの品質を安定させる設計も参考になります。
復旧操作の順序
復旧は影響の小さい操作から進めます。対象アプリに未保存の下書きや編集中データがある場合、強制終了は最後の手段です。利用者へ保存状況を確認できない自動処理が、独断でアプリを終了しないようにします。
- 背面ダイアログ、同期中表示、未保存文書を確認する
- 短い最小疎通を再試行し、無限待機を避ける
- 通常終了できるなら対象アプリを終了・再起動する
- 通常終了できず、未保存データの安全を確認できた時だけ強制終了を検討する
- 複数アプリやSystem Eventsも不調ならMac再起動を検討する
- 復旧後は前回成功時刻から再取得し、件数と最新時刻を照合する
よくある質問
Q. エラー-1712は権限不足ですか？
A. -1712だけでは権限不足と断定できません。AppleEventの返信が時間切れになった状態です。以前成功した権限、最小疎通、対象アプリ、System Eventsを分けて確認します。
Q. タイムアウト時間を長くすれば直りますか？
A. 処理が単に重い場合は改善することがありますが、対象アプリがハングしている場合は待ち時間を伸ばしても戻りません。無期限待機より、短い最小テストと上限付き再試行を使います。
Q. 対象アプリを自動で強制終了してよいですか？
A. 未保存データを失う可能性があるため、通常は行いません。下書きや編集中データの安全を確認し、通常終了、アプリ再起動、Mac再起動の順で利用者の判断を入れます。
Q. 復旧後の取りこぼしを防ぐには？
A. 失敗した回は最終成功時刻や処理済みIDを進めず、復旧後に前回成功地点から再取得します。重複排除キーを用意し、同じ範囲の再実行を安全にします。
まとめ
AppleEventタイムアウト-1712が出た時は、プロセス生存だけで正常と判断せず、最小AppleEvent、対象アプリ固有API、System Events、データストアを分けます。失敗時は状態ファイルを進めず、復旧後に前回成功地点から再取得します。権限変更や強制終了は原因を増やし、未保存データを失う可能性があるため、影響の小さい確認から進めてください。
Macアプリを含む業務自動化の設計・保守を相談する場合はACSの開発依頼、どの支援が合うか整理する場合はACSサービス選択診断をご覧ください。
この記事は役に立ちましたか？
ありがとうございます！
