リモートMacのlaunchd定期タスクが動かない？2026年のトラブルシューティングガイド

Appleの資料では、launchdのジョブはLaunch AgentとLaunch Daemonに分けて説明されています。Appleのジョブ作成資料が示すこの区分が、最初の切り分けポイントです。

症状 → SSHでは成功するのに、自動実行では結果が出ない。
最短の対処 → スクリプトを作り直す前に、タスクがユーザーのログイン環境を必要とするか確認し、実行アカウント、環境、ログ、再起動後の結果を順に検証します。

独立開発者：リモートMacで保守、ビルド、データ処理を定期実行したい方。
DevOpsエンジニア：SSHでの手動実行は成功するのに、自動タスクで成果物が出ない原因を探している方。
プラットフォーム管理者：ユーザーエージェント、システムサービス、別の実行方式から適切な選択肢を判断する方。

ログイン環境で動かすか、システムのバックグラウンドで動かすか

定期タスクは、名前やファイルの置き場所だけで実行方式を決めないでください。ユーザーのログイン状態やアクセスできる資源が異なるため、SSHセッションでの成功は、自動実行の成功を保証しません。Appleのユーザーコンテキストに関する説明も、ユーザーとシステムの実行環境を分けて扱っています。

適合度は定性的な判断です。LaunchDaemonを選べば、LaunchAgentで起きた問題が自動的に解決するわけではありません。Appleのエージェントとデーモンの設計資料を参照し、必要な実行コンテキストに合わせて選んでください。

SSHでは動くのに、launchdから失敗するのはなぜですか。
SSHのシェルでは読み込まれる設定や環境変数が、launchdのジョブにも同じように渡るとは限りません。標準出力が見えないだけで、未起動と決めつけず、ジョブの設定、終了状況、標準出力と標準エラーの保存先を確認します。

ログインユーザー固有の処理はLaunchAgentで検証する

ユーザーのホームディレクトリ、ログイン後に利用できる認証情報、ユーザーセッション内のアプリに依存する処理は、まずユーザーエージェントとして成立するか確かめます。LaunchAgentがどのユーザー環境で動作するか、AppleのLaunch AgentとLaunch Daemonの説明と照らし合わせてください。

確認するのは、plistの所有者と権限、指定した実行ユーザー、対象ファイルへの読み書き権限、ジョブが対象ユーザーのコンテキストにあるかです。SSH接続に使うアカウントと、ジョブが動くアカウントが違えば、同じパスでも見えるファイルや利用できる資格情報が変わります。

ユーザーがログインしていない時間帯にも、同じ処理を走らせたい場合はどうしますか。
処理がユーザーのログインセッションを必要とするなら、LaunchDaemonへ移すだけでは要件を満たせない場合があります。ユーザーセッションが不要な部分を切り分けるか、実行をユーザーのログイン後に限定するか、別の実行方式に変えるかを選びます。ユーザーの状態に依存する処理を、権限の拡大だけでバックグラウンド化しないでください。

ログイン不要の処理はLaunchDaemonの境界を確かめる

システム起動後に、GUIやログインユーザーのデータなしで実行できる処理なら、LaunchDaemonを候補にできます。ただし、ジョブの実行ユーザー、読み書きする場所、利用するネットワーク資源を先に明確にします。Appleのバックグラウンドプロセスの設計資料に沿って、ユーザーのセッションとシステム側の処理を区別してください。

受け入れ条件は、設定ファイルが存在することではありません。必要なファイルだけを読めるか、指定した出力先に書けるか、タスク専用のアカウントで実行できるかを、実行後の記録で確認します。起動させるためだけにroot権限を与えるのは避けてください。

GUI、認証情報、外部資源の依存を切り分ける

グラフィカルアプリの操作、画面上の確認、ユーザーの操作を待つ処理は、SSHから呼び出せることと、ログインしていない状態で動くことが別問題です。Appleはスクリプトとlaunchdの利用を案内していますが、対象アプリが無人実行に対応するかは、アプリとタスクの実際の条件で確かめる必要があります。

資格情報をキーチェーンから取得する処理も、どのユーザーのキーチェーンを参照するか、ログイン状態でその項目にアクセスできるかを確認します。AppleのKeychain Services資料を参照し、パスワードをplistやログへ直接記録せず、実行コンテキストに応じた安全な受け渡し方法を検討してください。

さらに、実行ファイルは可能な限り絶対パスで指定し、作業ディレクトリも明示します。シェルの初期化ファイルを読まない前提で、PATHなど必要な環境変数をジョブ側に設定し、依存コマンドの有無を小さなテストで確かめます。AppleのShellスクリプトの基礎も、スクリプトの実行条件を確認する際の参照先になります。

SSH接続用の環境変数やコマンド設定は、そのまま自動タスクでも使えますか。
同じとは仮定しないでください。SSHの対話シェルで見える値を記録し、launchd用の設定に必要な値だけを明示したうえで、タスク自身のログと再現可能な最小処理で確認します。外部サービスへの接続が必要なら、認証方式、名前解決、到達先も別々に検証します。

再起動後と周期実行の完了記録で修復を判定する

設定ファイルがある、またはジョブが読み込まれたという状態だけでは、処理が完了した証拠になりません。実際のトリガー、開始と終了、終了ステータス、期待した出力を対応づけて確認します。Appleの定期ジョブに関する資料に記載されたスケジュール設定と、対象Macでの実行記録を照合してください。

再起動後に、タスクが復旧したと何で判断できますか。
設定ファイルの存在や読み込み状態だけで判定せず、再起動後に想定する条件でジョブが実際に起動し、処理を完了し、必要な出力を残したことを確認します。ユーザーのログイン後に実行する設計なら、そのログイン条件も含めて検証してください。

次の項目を上から確認し、実行結果を記録します。

• [ ] 手動実行とlaunchd実行で、実行アカウントと作業ディレクトリを比較する。
• [ ] plistの構文、所有者、アクセス権、指定した実行ファイルのパスを確認する。
• [ ] ユーザーのログイン状態、GUI、認証情報への依存を洗い出し、LaunchAgentとLaunchDaemonの適合性を見直す。
• [ ] 必要な環境変数、外部コマンド、ネットワーク資源をジョブのログから検証する。
• [ ] 実際のスケジュールで起動させ、開始・終了・出力の記録を残す。
• [ ] 再起動後にも同じ条件で実行し、成果物と終了状態を確認する。

上記のどこかで条件がそろわないなら、ジョブを無理に常駐化せず、ログイン後に動かす、GUI依存を取り除く、別の実行基盤へ移すなど、タスクの境界を調整します。

実行場所を選ぶときは、Macの維持コストも比べる

手元のMacを常時稼働させる方法は物理アクセスやローカル資源を使いやすい一方、電源、ネットワーク、保守を自分で管理する必要があります。LinuxサーバーはmacOS専用の処理には置き換えられず、仮想環境も、必要なmacOS環境や周辺機能を満たすか事前確認が欠かせません。実行基盤の違いを整理したい場合は、ベアメタルと仮想化の比較も判断材料になります。

Macが必要な周期処理を一時的に運用するなら、機材購入や常設機の保守を避けて、リモートMacを使う選択肢もあります。ただし、長期間の安定した高負荷処理や、手元の物理インターフェースを必要とする作業は、レンタルより自前のMacが適する場合があります。SSH接続を含む利用条件をリモートMacの案内で確認し、実際のジョブを対象環境で試してから運用方法を決めてください。