Claude Dispatch実践ガイド — Claude Code CLIユーザーが「GUIの壁」を突破する連携パターン集
claude -p でビルド・テスト・デプロイまで自動化した。でも「Vercelの管理画面でドメイン設定を確認」「スプレッドシートに集計結果を転記」——その先のGUI操作で、毎回キーボードに手が戻る。
2026年3月リリースのClaude Dispatchは、まさにこの「CLIの届かない最後の1マイル」を埋めるピースだ。ただし成功率は非自明タスクで約50%。本記事では、CLI自動化を既に回している開発者の視点で、Dispatchを「どこに・どう組み込めば投資対効果が最大化するか」を実践パターンとともに解説する。
Claude Dispatchとは何か — Computer Useの「常駐版」という位置づけ
Coworkエコシステムの全体像
Claude Coworkは複数のモードで構成されている。
| モード | 概要 |
|---|---|
| Dispatch | スマートフォンからタスクを投げ、デスクトップのエージェントがバックグラウンドで実行 |
| Scheduled | 定期実行タスクをスケジュール設定し、自動で繰り返す |
また、Claude CodeのRemote Control機能(claude.ai/codeやモバイルアプリからCLIセッションに接続)を組み合わせることで、リモートからの操作体験がさらに広がる。
Dispatchは2026年3月17日にリサーチプレビューとして提供が開始された。Max 5x / Max 20xプランに先行提供された後、Proプラン($20/月)にも展開されている。
Computer Useとの違い:永続コンテキストとデスクトップ常駐
Computer Useが「APIから呼び出す1回限りのセッション」だったのに対し、Dispatchは「Claude Desktopに常駐するエージェント」だ。PCが起動状態かつClaude Desktopが開いていれば、スマートフォンのQRコードスキャンだけで約90秒でセットアップが完了する。APIキーの設定は不要。
重要なのは、DispatchはモバイルAIエージェントではないという点だ。あくまでデスクトップエージェントへのリモートインターフェースであり、実際の処理はすべてデスクトップ上で行われる。現時点ではmacOSとWindowsに対応しており、Linuxには未対応だ。
CLI vs Dispatch — 使い分け判断フローチャート
CLIが得意な領域
Claude Code CLIが圧倒的に強いのは、確定的・テキストベース・再現性重視のタスクだ。
- ファイル操作、git、ビルド、テスト、コード生成
- 成功率はほぼ100%、冪等性がある
- パイプラインに組み込みやすい
Dispatchが得意な領域
一方、Dispatchが真価を発揮するのはGUI操作・視覚確認・クロスアプリ連携だ。
- ブラウザでの管理画面操作
- スプレッドシートの集計・グラフ作成
- GUIアプリの設定変更
ただし注意点がある。DEV Communityの実測レポートによれば、単純なファイル操作やデータ取得は高い信頼性で動作するが、クロスアプリの書き込み操作(カレンダー作成、メール送信等)は約50%の成功率にとどまる。読み取りは書き込みより大幅に信頼性が高い。
判断フロー:5つの問いで振り分ける
flowchart TD
A[タスク発生] --> B{CLIで完結する?}
B -->|Yes| CLI[CLI で実行]
B -->|No| C{結果の検証がテキストで可能?}
C -->|Yes| CLI
C -->|No| D{失敗時のリカバリコストは低い?}
D -->|No| MANUAL[手動で実行]
D -->|Yes| E{GUI操作のステップ数 ≤ 5?}
E -->|No| MANUAL
E -->|Yes| F{成功率50%で許容できる?}
F -->|Yes| DISPATCH[Dispatch で実行]
F -->|No| MANUAL
正直なところ、最初はこのフローを意識しなくても「CLIで無理だからDispatch」と雑に投げていた。だが失敗が積み重なると、この5問チェックの有無で体験が大きく変わる。
実践パターン3選 — CLIとDispatchの補完ワークフロー
パターン1:デプロイ後のGUI検証自動化(CLI → Dispatch)
CLIでビルド&デプロイを完了した後、Dispatchでブラウザを開きVercel管理画面のステータスを確認する流れだ。
#!/bin/bash
# deploy-and-verify.sh
# 1. CLIでビルド&デプロイ
PROJECT_DIR=~/Repo/my-app
cd "$PROJECT_DIR"
claude -p "npm run build && vercel deploy --prod を実行し、デプロイURLを出力してください" \
--dangerously-skip-permissions \
> /tmp/deploy-result.txt 2>&1
DEPLOY_URL=$(grep -oP 'https://[^\s]+\.vercel\.app' /tmp/deploy-result.txt | tail -1)
if [ -z "$DEPLOY_URL" ]; then
echo "デプロイURL取得失敗"
exit 1
fi
# 2. Dispatchでブラウザ検証(Claude Desktop経由)
# Dispatch APIはリサーチプレビュー段階のため、
# claude.ai/chatからDispatchタスクとして以下を送信する想定
cat <<EOF
=== Dispatchタスク ===
以下の手順を実行してください:
1. Chromeで ${DEPLOY_URL} を開く
2. ページが正常に表示されるか目視確認
3. コンソールにエラーがないか確認
4. スクリーンショットを ~/Desktop/deploy-check.png に保存
EOF
成功しやすいタスク粒度: 「URLを開いてスクリーンショットを撮る」程度の1-2ステップ。管理画面のフォーム操作まで含めると成功率が落ちる。
失敗時のフォールバック: スクリーンショットが保存されなければ、手動でブラウザを開いて確認。デプロイ自体はCLIで完了しているのでリスクは低い。
パターン2:スプレッドシート集計 + Slack共有(Dispatch単体)
月次データの集計・グラフ作成・Slack共有は、CLIだけでは完結しにくい典型例だ。Dispatchに以下のような指示を送る。
Dispatchタスク:
1. Google Chromeで sheets.google.com を開く
2. 「月次売上レポート 2026」スプレッドシートを開く
3. Sheet1のA列(日付)とB列(売上)から、4月分のデータを集計
4. 合計値をC1セルに記入
5. B列のデータで折れ線グラフを作成
6. グラフのスクリーンショットを撮影し ~/Desktop/monthly-report.png に保存
このパターンではタスクを分割して投げるのがコツだ。「集計してグラフを作ってSlackに共有」を一度に投げるより、「集計+グラフ保存」と「画像をSlackに投稿」を分けたほうが成功率は上がる。
パターン3:bassimeledath/dispatch skillでClaude Codeからファンアウト
bassimeledath/dispatchは、Claude Codeのskillとして動作し、大きなタスクをサブタスクに分解してバックグラウンドワーカーに分散実行するツールだ。Anthropic公式のDispatchとは別物だが、併用することで強力なワークフローが組める。
# インストール(グローバル)
npx skills add bassimeledath/dispatch -g
# プロジェクトレベル
npx skills add bassimeledath/dispatch
インストール後、Claude Code内で /dispatch コマンドが使えるようになる。
# Claude Code内での使用例
/dispatch このリポジトリのテストカバレッジを改善してください。
- ユニットテストが不足しているモジュールを特定
- 各モジュールに対してテストを生成
- カバレッジレポートを統合
特筆すべきはマルチモデル対応で、タスクごとにClaude、GPT、Geminiを使い分けられる。初回実行時に ~/.dispatch/config.yaml が自動生成され、利用可能なCLI(claude, agent, codex)を検出してくれる。
プラン別コスト設計 — Pro・Max 5x・Max 20xで何が変わるか
各プランの利用上限と実質コスト
| プラン | 月額 | Dispatch利用 |
|---|---|---|
| Pro | $20 | 利用可(後発で追加) |
| Max 5x | $100 | 利用可(先行提供) |
| Max 20x | $200 | 利用可(先行提供) |
DispatchのタスクはClaude Desktopの利用枠を消費する。CLIの使用量(Claude Code)とは別カウントだが、同一プランの上限内で共有される部分もある。
CLIヘビーユーザー向けの最適化戦略
コスト最適化の基本方針は明快だ。CLIで90%のタスクを処理し、Dispatchは「CLIでは原理的に不可能なGUIタスク」のみに限定する。
自律開発デーモンを24/365で稼働させているケース(まさにこのブログの運用環境だ)では、CLIのレート制限との兼ね合いが重要になる。Max 5xの制限内でCLIタスクを回しつつ、Dispatchは1日数回のGUI検証に絞るのが現実的な運用ラインだろう。
ハマりポイントと制約の現実的な対処法
成功率50%時代のエラーハンドリング戦略
複雑なマルチステップタスクは、冪等な単位に分割して個別にDispatchに投げるのが鉄則だ。失敗しても同じタスクを再投入すれば同じ結果が得られる設計にしておけば、50%の成功率でも実用になる。
失敗時のリトライ判定はCLI側で行うのが堅い。Dispatchの結果(ファイルの存在確認、スクリーンショットの有無など)をCLIスクリプトでチェックし、なければ再度Dispatchに投入する。
プッシュ通知未実装への対処
リサーチプレビュー段階ではプッシュ通知が未実装のため、タスク完了を手動で確認する必要がある。以下のようなポーリングスクリプトで回避できる。
#!/bin/bash
# poll-dispatch-result.sh
# Dispatchタスクの結果ファイルをポーリングしてSlack通知
TARGET_FILE="$HOME/Desktop/deploy-check.png"
SLACK_WEBHOOK="$SLACK_WEBHOOK_URL"
MAX_WAIT=600 # 最大10分
INTERVAL=30 # 30秒間隔
elapsed=0
while [ $elapsed -lt $MAX_WAIT ]; do
if [ -f "$TARGET_FILE" ]; then
curl -s -X POST "$SLACK_WEBHOOK" \
-H 'Content-Type: application/json' \
-d "{\"text\": \"Dispatchタスク完了: ${TARGET_FILE} が生成されました\"}"
exit 0
fi
sleep $INTERVAL
elapsed=$((elapsed + INTERVAL))
done
curl -s -X POST "$SLACK_WEBHOOK" \
-H 'Content-Type: application/json' \
-d '{"text": "⚠ Dispatchタスクがタイムアウトしました(10分経過)"}'
exit 1
macOS限定とリモート運用の注意点
PCがスリープするとDispatchは停止する。24/365稼働環境では caffeinate コマンドとの併用が必須だ。
<!-- ~/Library/LaunchAgents/com.user.caffeinate.plist -->
<?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.user.caffeinate</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/caffeinate</string>
<string>-dimsu</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
</dict>
</plist>
-dimsu オプションでディスプレイ・ディスク・システムすべてのスリープを防止する。既にlaunchdで自律開発デーモンを動かしているなら、このplistを追加するだけでDispatchの常時稼働環境が整う。
まとめ
Claude Dispatchは「CLIの延長線上にあるGUI操作エージェント」として、Claude Codeユーザーにとって最も自然な追加ピースだ。ただし成功率50%のリサーチプレビューである現実を踏まえ、使い分けの方針は明確にしておきたい。
- CLIで処理できるものはCLIに任せる(成功率・再現性・速度すべてで優位)
- Dispatchは「CLIでは原理的に不可能なGUIタスク」に絞って投入する
- タスクは冪等な小さい単位に分割し、失敗前提で設計する
CLIの確定的な自動化とDispatchの柔軟なGUI操作を組み合わせることで、開発ワークフローの自動化カバレッジは確実に広がる。今後の成功率向上とLinux対応に期待しつつ、まずは「デプロイ後のスクリーンショット取得」あたりの小さなGUIタスクから試してみてほしい。
参考リンク
