2026 DeepSeek Harness は launchd で起動時に自動起動する方法？

Apple公式のlaunchd資料では、ジョブ設定にLabelとProgramArgumentsが必須項目として示されています。したがって、2026年のDeepSeek Harness launchd 起動時自動起動では、普通の実行アカウントでLaunchAgentを作成し、絶対パス、作業ディレクトリ、Profile、認証情報を固定したうえで、プロセス・待受ポート・モデル呼び出し・再起動後の復旧を順番に確認するのが安全です。(Apple公式：launchdジョブの作成)

今週の推奨アクション： 1日目に托管対象を決め、2日目にplistとログ出力先を準備し、3日目に最小タスクを確認します。その後、異常終了、再ログイン、Mac本体の再起動を別々に試し、成功条件を記録してから本番運用へ移します。

この記事は、リモートMac上でDeepSeek Harness Web、Headless、または自動化処理をログイン後に動かしたい開発者向けです。プラットフォーム担当者は実行ユーザーとログの責任範囲を整理でき、納品担当者は「起動した」だけでなく、継続利用できる状態を受け入れ確認できます。

最初に、1つのLaunchAgentへ異なるライフサイクルの処理を詰め込まないことが重要です。Web UIは待受を続けるプロセス、Headlessは開始して成果物を出して終了する処理、定期自動化はスケジュールやキューを持つ処理として、托管対象を分けて記録します。

DeepSeek Harnessの公式リポジトリと実行方法で、対象バージョンの起動コマンドと引数を確認し、次の項目を作業票へ残します。

• DeepSeek Harnessの起動コマンド
• 実行ファイルの絶対パス
• dsh、node、またはnpxの実体パス
• Profile名
• 作業ディレクトリ
• 実行するMacユーザー
• 使用ポートと状態ディレクトリ
• 停止コマンド
• 標準出力と標準エラーの保存先
• API Keyを読み込む仕組み

macOSでは、ユーザー単位のLaunchAgentはユーザーのログインセッションに紐づいて起動します。一方、LaunchDaemonはシステム側のコンテキストで動くため、GUIセッションやユーザーのキーチェーンに依存するWebワークフローへ、そのまま適用しにくい場合があります。(Apple公式：システムコンテキストとログインセッション)

DeepSeek Harness Webを遠隔操作する構成では、まずrootではなく、専用の通常ユーザーでLaunchAgentを作成します。ログインセッション、作業フォルダー、ユーザー権限で扱う設定ファイルを同じ文脈に置けるため、rootで起動したプロセスと通常ユーザーが開くWeb UIの間で権限差が発生しにくくなります。

plistは完成品として配布せず、環境ごとに次のプレースホルダーを置き換えます。/ABSOLUTE/PATH/TO/dshは実際に実行できるファイルへ、PROFILE_NAMEは対象Profileへ、WORKSPACEは専用の作業フォルダーへ変更します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.deepseek-harness</string>

  <key>ProgramArguments</key>
  <array>
    <string>/ABSOLUTE/PATH/TO/dsh</string>
    <string>web</string>
    <string>--profile</string>
    <string>PROFILE_NAME</string>
  </array>

  <key>WorkingDirectory</key>
  <string>/ABSOLUTE/PATH/TO/WORKSPACE</string>

  <key>RunAtLoad</key>
  <true/>

  <key>StandardOutPath</key>
  <string>/ABSOLUTE/PATH/TO/logs/harness.stdout.log</string>

  <key>StandardErrorPath</key>
  <string>/ABSOLUTE/PATH/TO/logs/harness.stderr.log</string>

  <key>KeepAlive</key>
  <true/>
</dict>
</plist>

ProgramArgumentsには、シェルで普段使っているdshという短縮名ではなく、実際の実行ファイルの絶対パスを指定します。Label、ProgramArguments、RunAtLoad、KeepAlive、標準出力と標準エラーの扱いは、Appleのlaunchd.plistキーに関する公式リファレンスに沿って、対象処理の性質ごとに選びます。

Node.jsやパッケージマネージャーがシェルの初期化ファイルでPATHへ追加されているだけの場合、LaunchAgentからは見つからないことがあります。Appleのシェル環境とコマンド実行に関する資料も確認し、対話シェルだけで成立するPATHに依存しない構成へ変更します。

保存前に、plistとログディレクトリの所有者を実行ユーザーへ合わせ、API Keyをplistへ直接書かないようにします。plistは起動条件と引数の定義に限定し、認証情報はキーチェーン、専用ユーザーだけが読める環境ファイル、または実行ラッパーから読み込ませます。

LaunchAgentでAPI Keyを安全に渡すにはどうするか。

EnvironmentVariablesへ直接記載する方法は、plistを読めるユーザーに値が見えるため、長期運用では避けます。専用ユーザーだけが読めるファイルを作り、ラッパースクリプトがそこから環境変数へ設定してDeepSeek Harnessをexecする構成のほうが、設定と秘密値を分離できます。ログ出力へ環境変数を表示するデバッグ処理も必ず無効にします。

注意： rootでWeb UI全体を起動すると、設定ファイル、キャッシュ、状態ディレクトリの所有者がrootになり、通常ユーザーでの再利用や削除時に権限問題が起きやすくなります。管理者権限が必要な処理だけを別工程に分け、Harness本体へ広い権限を与えない運用を推奨します。

設定後はいきなりWeb UIやモデルタスクまで確認せず、まずプロセスの身元とログの流れを検証します。Appleのlaunchctlコマンドリファレンスで、対象ユーザーのGUIドメインへ登録する考え方を確認し、実際のユーザーIDに置き換えて実行します。

PLIST="$HOME/Library/LaunchAgents/com.example.deepseek-harness.plist"

plutil -lint "$PLIST"
launchctl bootstrap "gui/$(id -u)" "$PLIST"
launchctl print "gui/$(id -u)/com.example.deepseek-harness"

続けて、次を確認します。

• psで実行ユーザーが想定どおりか
• lsofまたは同等の確認方法で待受ポートが想定どおりか
• ログに「ファイルがない」「権限がない」「コマンドが見つからない」が出ていないか
• 作業ディレクトリにProfileと状態ファイルが作成されているか
• node、dsh、依存パッケージがLaunchAgentの環境で解決できるか

LaunchAgentでnpxやNode.jsが見つからない場合はどうするか。

まず、対話シェルとLaunchAgentでPATHが異なることを疑います。which node、which npx、command -v dshを対話シェルで確認し、その結果をplistのProgramArgumentsへ反映します。npxを直接常駐プロセスに使うより、検証済みの実体パス、固定したプロジェクト環境、またはリリース時に確認した実行ファイルを指定し、更新時に明示的に切り替えるほうが、再起動後の再現性を保ちやすくなります。

起動直後に終了する場合、KeepAliveを強くして再起動を繰り返すのは解決策ではありません。絶対パス、作業ディレクトリ、環境変数、権限、ポート競合を先に修正し、原因が消えたことをログで確認してから再ロードします。

Webモードでは、プロセスが存在するだけでは不十分です。待受アドレス、ポート、作業領域、Profile、認証情報、低リスクのモデル呼び出しを一つの閉ループとして確認します。外部公開が必要な場合も、最初から全インターフェースへ開放せず、ローカル待受と安全なアクセス経路を分けて検討します。

Web UIが開いてもタスクが動かない場合は、次の順番で切り分けます。

1. UIプロセスが想定ユーザーで動いているか確認する。
2. UIが表示するProfileとLaunchAgentが指定したProfileを比較する。
3. 作業ディレクトリ内の設定・状態ファイルを確認する。
4. API KeyがLaunchAgentの環境で読み込めるか、値そのものを表示せずに存在だけ確認する。
5. 低リスクの短いタスクを実行し、モデル呼び出しと成果物を確認する。
6. 標準エラーに認証、ネットワーク、権限のどの層の失敗が出ているか分類する。

Headlessでは、常駐していることを成功条件にしません。終了ステータス、生成物のパス、生成物の内容、二重実行の有無を確認します。単発処理へKeepAliveを無条件で付けると、正常終了後も同じ処理が再実行される設計になり得るため、Web用AgentとHeadless用の実行定義を分けます。Appleのlaunchdによるバックグラウンドタスクの説明でも、AgentとDaemonは実行コンテキストを持つ別の托管対象として扱われています。

JEXCLOUDで遠隔Macの構成を引き渡す場合も、DeepSeek HarnessのWeb UIアクセス案内と、実際の接続経路、待受ポート、認証方法を同じ受け入れ記録へまとめると、画面が開くだけの未完成状態を避けられます。

次の確認を別々に実施します。

• [ ] launchctlから対象ジョブを停止し、意図した停止状態になる
• [ ] プロセスを異常終了させ、LaunchAgentが再起動を試みる
• [ ] ユーザーからログアウトして再ログインし、WebまたはHeadlessが戻る
• [ ] Mac本体を再起動し、ログイン後にプロセス・ポート・モデル呼び出しを確認する
• [ ] Webでは低リスクの最小タスク、Headlessでは成果物と終了ステータスを確認する
• [ ] ログにAPI Keyやセッション情報が出ていない
• [ ] 同じポートや状態ディレクトリを使う二重インスタンスがない
• [ ] 復旧できず手動介入が必要になる条件を記録する

KeepAliveはプロセスを再起動させる仕組みであり、途中まで実行したモデルタスク、ブラウザー状態、承認待ち、外部APIのリクエストを自動的に再開する機能ではありません。異常終了後にプロセスが戻っても、タスクの再開点や重複実行を管理する仕組みが別に存在しなければ、処理は最初からやり直しになる可能性があります。

復旧時間を固定値として記載せず、ログの時刻、プロセスの再出現、ポートの再開、最小タスクの完了時刻を記録します。これにより、Macの起動、ユーザーログイン、ネットワーク利用可能、Harness起動、モデル認証という依存関係のどこで待ち時間が発生したかを判断できます。

経験則： 「再起動後にWeb UIが開いた」だけでは納品条件になりません。ログイン後のProfile読み込み、API Keyの存在確認、モデルへの低リスク呼び出し、成果物の保存まで通過して初めて、運用上の復旧と扱います。

停用時は、プロセスを止める、ジョブを無効化する、plistを退避する、ログを保管する、状態ディレクトリの扱いを決める、という順番にします。現在ロードされているplistを直接編集して済ませるのではなく、変更前後のファイルと実行コマンドを残します。

launchctl bootout "gui/$(id -u)" "$HOME/Library/LaunchAgents/com.example.deepseek-harness.plist"

更新時は、次の順番を崩さないようにします。

1. 現行プロセスと使用ポートを記録する。
2. 現行plistと起動ラッパーを保存する。
3. 旧プロセスを停止し、二重起動がないことを確認する。
4. 新しい実行ファイルの絶対パスを指定する。
5. plistの構文、所有者、ログ出力先を確認する。
6. LaunchAgentを再ロードする。
7. WebまたはHeadlessの最小タスクを実行する。
8. 問題があれば旧パスと旧plistへ戻す。

launchdはmacOSのプロセス管理機能ですが、DeepSeek Harnessの状態管理やタスクキューを代替するものではありません。公式の実行方式やコマンドが更新された場合は、既存plistをそのまま流用せず、最新のREADME、リリース情報、実行パラメーターを確認してから再検証します。macOSの起動制約が満たされない場合にプロセスが実行されない仕組みについては、Apple公式のlaunch環境制約資料も参照してください。

JEXCLOUDの遠隔Macを運用候補にする場合は、Macレンタルの利用形態を確認できる案内で継続占有の条件を確認し、短時間の検証環境と長期常駐環境を分けて見積もります。既存環境の日本向けMac利用プランを比較する際も、価格だけでなく、ログイン維持、再起動後の接続、データ退避、停止時の責任分界を確認する必要があります。

自前のMacは、物理インターフェースや長期にわたる固定負荷を確保しやすい一方、電源、ネットワーク、再起動対応、監視を自分で持つ必要があります。一般的なクラウド実行環境は一時タスクには向きますが、macOS固有のWeb UI、ユーザーセッション、キーチェーン、GUI依存処理では追加の中継や権限設計が増えます。現在の構成で安定した占有時間を確保できない場合に限り、JEXCLOUDのリモートMacを検証用または短期運用用として選ぶと、購入して常時電源を管理するより判断しやすくなります。

まずは、実行ユーザー、絶対パス、ログ、停止方法、再起動後の最小タスクを記録した、秘密値を含まない受け入れ票を作成してください。DeepSeek Harness launchd 起動時自動起動を本番へ移すか、JEXCLOUDの遠隔Mac環境へ切り替えるかは、その票でプロセス、WebまたはHeadless、モデル呼び出し、再起動復旧の4つを確認してから決めるのが安全です。