はじめに
2026年3月、Claude に3つの機能が立て続けにリリースされました。Dispatch、Computer Use、Channelsです。
3つをClaude CodeやCI/CDと組み合わせると、こういうことができます。
スマホからタスクを投げるだけで、AIが調査・修正・検証・デプロイまで自律的に回す。定型的なタスクであれば、開発者の介在は「最初の指示」と「最後の確認」が中心になります。
それぞれの機能は、開発者がこれまで当たり前に受け入れていたボトルネックを外します。
| 機能 | プラットフォーム | 外すボトルネック |
|---|---|---|
| Dispatch | Claude Desktop | 物理的な制約 — PCの前にいないと開発を始められない |
| Computer Use | Claude Desktop / Claude Code | インターフェースの壁 — APIがなければ自動化できない |
| Channels | Claude Code CLI | 通信手段の制約 — Claude専用アプリがないとやり取りできない |
Dispatch と Computer Use は主に Claude Desktop（Cowork）で使う機能ですが、Computer UseはClaude Codeでも利用可能です。Channels は Claude Code CLI のプラグイン機能です。まずDesktop側の2機能を組み合わせた想定シナリオから紹介し、その後で各機能を個別に掘り下げます。
Dispatch は2026年3月中旬、Computer Use は3月23日にresearch previewとして発表されました。Channelsも同時期にresearch previewとして提供されています。DispatchはmacOS / Windows対応でPro / Maxプラン向け、Computer Useは現時点でmacOSのみ（Windows対応予定）でPro / Maxプラン向けです。ChannelsはClaude Code v2.1.80以降で利用可能で、Team / Enterpriseプランでも組織設定で有効化できます。
事例1: Dispatch + Computer Use — 受託エンジニアの移動中バグ修正（想定シナリオ）
状況
受託開発を1人で回しているフリーランスエンジニアが、電車で移動中にクライアントから連絡を受けました。「本番環境でユーザー登録時にエラーが出ている」とのことです。
ノートPCは持っていましたが、テザリング回線は不安定。エディタを開いてコードを読み、ログを確認し、修正して、テストを回す。この一連の作業を不安定な回線でやるのは現実的ではありません。
ただし、自宅のデスクトップではClaude Desktopアプリが起動しています。
Dispatch + Computer Useの連携
ここでClaude Desktopの2つの機能がパイプラインとして機能しました。
時系列で整理すると、以下の流れです。
Step 1: Dispatchでタスク委譲
スマホのClaudeモバイルアプリからタスクを投げます。
本番でユーザー登録時にエラーが出てる。
エラーログ見て、原因特定して、修正して。
Dispatchは、スマホから投げたタスクを自宅のClaude Desktopに渡します。単なるリモート実行ではなく、スマホとDesktop間で会話が継続するため、途中経過の確認や追加指示も可能です。Claudeはタスクの性質に応じてCowork（Desktop UI）またはClaude Codeを選択し、自律的に作業を開始します。
Step 2: Claude Codeが並列調査
Claude Codeは内部でサブエージェントを複数起動し、調査を並列で実行しました。
| サブエージェント | 調査内容 | 結果 |
|---|---|---|
| ログ調査 | 本番エラーログの分析 | AuthenticationError: Token validation failed |
| コミット検索 | 直近1週間の変更履歴 | 3日前に認証ライブラリを v2.1.0 → v2.2.0 に更新 |
| 依存関係チェック | ライブラリの変更点 |
v2.2.0 でトークン検証がHS256からRS256に変更 |
3つの結果を統合すると、原因は明確でした。認証ライブラリのアップデート時に、環境変数の設定を追従していなかったのです。
Claude Codeは以下の修正を生成しました。
- JWT_ALGORITHM=HS256
+ JWT_ALGORITHM=RS256
+ JWT_PUBLIC_KEY_PATH=/secrets/jwt-public.key
export function validateToken(token: string): TokenPayload {
- return jwt.verify(token, process.env.JWT_SECRET);
+ const publicKey = fs.readFileSync(process.env.JWT_PUBLIC_KEY_PATH);
+ return jwt.verify(token, publicKey, {
+ algorithms: [process.env.JWT_ALGORITHM]
+ });
}
Step 3: Computer Useで検証
修正を適用した後、Computer UseがStaging環境のブラウザを実際に操作して動作確認を実行しました。
- ブラウザでStaging環境のユーザー登録画面を開く
- フォームにテストデータを入力
- 登録完了画面の表示を確認
- ログイン処理を実行
- ダッシュボードの正常表示を確認
すべてパス。Claudeがスクリーンショット付きでモバイルアプリに結果を報告してきました。
Step 4: 承認とデプロイ
エンジニアはスマホで報告を確認し、「LGTM、マージして」と返信。Claude CodeがPRをマージし、GitHub Actionsがデプロイを実行しました。
指示からデプロイ完了まで約15分。電車の中で完結しています。
洞察: Dispatch + Computer Useが作る「クローズドループ」
この事例が示しているのは、Claude Desktopの2つの機能が連結すると質的に異なるものが生まれるということです。
- Dispatch = 入力（スマホからDesktopへのタスク委譲）
- Computer Use = 出力の検証（ブラウザ操作による動作確認）
Dispatchでタスクを受け取り、Claudeが内部でサブエージェントを使って調査・修正し、Computer Useで検証する。これにより「指示 → 調査 → 修正 → 検証 → デプロイ」という開発ライフサイクル全体がクローズドループになります。
従来、このループを回すには開発者がすべてのステップに介在する必要がありました。エディタでコードを読み、ターミナルでコマンドを叩き、ブラウザで動作確認する。各ステップに人間の手と目が要る構造です。
Dispatch + Computer Useを組み合わせると、定型的なタスクでは開発者の介在ポイントが大幅に減ります。
- 最初の指示（何を解決したいか）
- 途中の確認（必要に応じて方針修正）
- 最後の承認（修正内容を受け入れるか）
間のプロセスの多くをAIが自律的に回します。ただし、research preview段階では複雑なタスクで再試行が必要な場合があり、完全な自律ではありません。
これは「開発者が不要になる」という話ではありません。AIが自律的に回せるのは、原因と解決策のパターンが比較的明確なケースです。「何を解決すべきか」の判断と「この修正で本当に問題ないか」の最終判断は、依然として人間の責任です。また、research preview段階のため完璧ではなく、複雑なタスクでは再試行が必要な場合もあります。
この構造変化が持つ意味を、もう少し考えてみます。
受託開発の現場では、「対応速度」がクライアントとの信頼関係に直結します。障害が発生してから修正完了まで何時間かかるか。この時間の大部分は、実は「エンジニアがPCの前に座るまでの待ち時間」と「原因調査に費やす時間」で占められています。コード修正そのものは10分で終わることも珍しくありません。
Dispatch + Computer Useのクローズドループは、この「待ち時間」と「調査時間」を圧縮します。結果として、インシデント対応の所要時間は「修正の複雑さ」にほぼ比例するようになります。「エンジニアが今どこにいるか」という変数が、対応速度に影響しなくなるのです。
ここからは、各機能を個別に掘り下げます。事例2・3はClaude Desktop、事例4はClaude Code CLIの事例です。
事例2: Dispatch — 外出先からバグ修正を非同期で委譲（想定シナリオ）
状況
スタートアップのCTOが外出中に、PagerDutyからアラートが届きました。ユーザー一覧APIのレスポンスが急激に遅延しています。
スマホしか手元にありません。従来であれば、帰宅してからPCを開いて対応するしかありませんでした。
Dispatchでの対応
Claudeモバイルアプリを開き、タスクを投げます。
本番のユーザー一覧APIが遅延してる。
直近のデプロイで何が変わったか確認して、
原因がわかったら修正のPRを作って。
Dispatchはこのタスクを自宅のClaude Desktopに転送します。Claudeはデスクトップ上で自律的に作業を開始します。
CTOが30分後にスマホを確認すると、Claudeから報告が届いていました。
原因を特定しました。
2時間前のデプロイでN+1クエリが発生しています。
- 変更ファイル: src/api/users.ts
- 原因: ユーザー一覧取得で関連テーブルを個別にクエリ
- 修正: eager loadingに変更
PRを作成しました: github.com/.../#142
レスポンスタイムは1200ms → 85msに改善見込みです。
CTOは「LGTMです。マージして」と返信。Claudeがマージし、CI/CDでデプロイが走りました。
外出先から一度もPCを開かずに完了しています。
洞察: 「PCの前に座るまでの待ち時間」が消える
Dispatchの本質は「非同期タスク委譲」と「デバイス間の継続的な会話」です。スマホから指示を出し、Claudeが自宅のDesktopで自律的に作業し、結果をスマホに返す。途中で方針を変えたければ、スマホから追加指示を出すこともできます。
ここで重要なのは、DispatchがClaude Desktop上のCoworkまたはClaude Codeと連携するという点です。単なるチャットボットではなく、デスクトップのファイルシステム、開発ツール、プロジェクト設定がすべて使える環境で動きます。Claudeはタスクの性質に応じて、Cowork（汎用作業）とClaude Code（コーディング特化）を使い分けます。
従来のフローでは「帰宅 → PC起動」だけで30分〜1時間のロスが生じていました。Dispatchはこのロスをゼロにします。
ただし、Dispatchは「Claudeに丸投げする」機能ではありません。あくまでタスクの委譲であり、最終判断は人間が行います。N+1クエリのeager loading修正のような定型的な修正は高い精度で対応できますが、アーキテクチャの判断が必要なケースでは、帰宅後にPCで確認する方が安全です。
Dispatchを使うにはClaude Desktopが起動している必要があります（macOS / Windows対応）。スリープ状態やシャットダウンでは受け取れません。常時起動のデスクトップ環境を用意しておくことをおすすめします。
事例3: Computer Use — レガシー社内システムのデータ移行（想定シナリオ）
状況
ある企業の経理部門で、月末の請求データを社内システムに手入力する作業がありました。
このシステムは10年前に構築されたWebアプリで、APIは存在しません。毎月約200件の請求データを、CSVからコピーして画面に貼り付ける作業を3人の担当者が分担しています。所要時間は合計で約6時間です。
RPAツールの導入も検討されましたが、社内システムのUIが頻繁にマイナーチェンジされるため、セレクタが壊れるたびにメンテナンスが必要で、結局は手作業に戻っていました。
Computer Useでの対応
Computer Useは、Claudeがマウスとキーボードを操作して、画面上のアプリケーションを直接制御する機能です。ブラウザの操作、ファイルのオープン、開発ツールの実行など、人間がデスクトップで行う操作をClaudeが代行します。
RPAとの大きな違いは、操作の認識方法にあります。
RPAは「画面上のこの座標をクリック → この入力欄にテキストを入れる」という手順を固定的に記録します。UIが変われば壊れます。
Computer Useは、画面のスクリーンショットを見て「ここが入力欄だ」と視覚的に判断します。ボタンの位置が多少移動しても適応しやすい構造です。ただし、これはUI変更に対する完全な耐性を保証するものではなく、大幅なレイアウト変更では再試行や手動介入が必要になる場合もあります。
実際の操作フローは以下の通りです。
1. CSVファイルから1行分の請求データを読み取る
2. 社内システムの新規請求画面を開く
3. スクリーンショットを撮影
4. 「取引先名」の入力欄を認識してクリック
5. 取引先名を入力
6. 「金額」の入力欄を認識してクリック
7. 金額を入力
8. 「登録」ボタンを認識してクリック
9. 確認ダイアログの「OK」を認識してクリック
10. 次の行に進む
200件の入力が約40分で完了しました。6時間の手作業が40分です。
洞察: 「APIがないから自動化できない」は過去の話になる
エンジニアの世界には「APIがなければ自動化できない」という暗黙の前提がありました。社内のレガシーシステムに対して「API作ってください」と依頼しても、予算も工数も確保できない。結局、人間が手で入力し続ける。
Computer Useは、この前提を覆します。APIがなくても、GUIがあれば自動化できるからです。
これまで「自動化したいがAPIがない」というシステムが社内にいくつあるか、考えてみてください。勤怠管理、経費精算、在庫管理、顧客管理。どの企業にも、GUIしかないレガシーシステムが複数存在します。
Computer Useは、これらのシステムに対して「AIがGUIを操作する」という形の自動化手段を提供します。事例1でもStaging環境のブラウザ検証に使われていましたが、開発以外の業務でも同じ原理が適用できます。
Computer Useはresearch preview段階です。初期段階のため完璧ではなく、複雑なタスクでは再試行が必要な場合があります。機密データを扱うべきではなく、一部のアプリケーションはデフォルトで制限されています。データの更新や削除に使う場合は、テスト環境で十分に検証してください。
ただし、現時点ではいくつかの制約も理解しておく必要があります。
- macOSのみ対応（2026年3月時点、Windows対応予定）
- 操作速度はAPI等の直接統合より遅い
- 2要素認証やCAPTCHAには対応できない場合がある
- 画面の描画が完了する前に操作すると失敗する
万能ではありませんが、「APIがない」という理由で自動化を諦めていた領域に、実用的な選択肢が生まれました。
事例4: Channels — Discordからリアルタイムで開発指示（想定シナリオ）
状況
5人チームのエンジニアリーダーが、週末の夕食中にSlackでCI失敗の通知を受けました。金曜日にマージしたPRがステージング環境のテストを壊しています。
月曜朝までに直さないと、他のメンバーの作業がブロックされます。ただし、PCは自宅に置いてきました。
Channelsでの対応
ChannelsはDispatchとは異なるアプローチです。Dispatchがモバイルアプリ経由でDesktopにタスクを投げるのに対し、Channelsは Telegram・Discord・iMessage から、起動中のClaude Code CLIセッションにイベントをpushするプラグイン（MCPサーバー）です。
技術的には、各チャットアプリ用のプラグインがMCPサーバーとして動作し、メッセージを受信するとClaude Codeセッションに転送します。利用にはClaude Code v2.1.80以降、claude.aiへのログイン、Bunランタイムが必要です。セッションが起動中である必要があるため、常時運用にはバックグラウンド実行やpersistent terminalの準備が要ります。
リアルタイムの双方向チャットが可能なので、作業の途中で方向修正したり、追加情報を渡したりできます。
[19:12] エンジニア:
CIが失敗してる。直近のマージで何が壊れたか
テストログを見て教えて。
[19:13] Claude Code:
調査を開始します。CI のテストログと
直近のマージ内容を確認します。
[19:16] Claude Code:
原因を特定しました。
金曜にマージした #287 でテストのfixtureが
変更されていますが、関連テスト3件の期待値が
更新されていません。
- tests/api/user.test.ts (2箇所)
- tests/api/auth.test.ts (1箇所)
修正しますか？
[19:16] エンジニア:
修正して。ただしfixtureの変更意図は壊さないで。
[19:19] Claude Code:
修正完了しました。
- fixture側の変更意図（タイムゾーン正規化）を維持
- テスト3件の期待値をfixtureに合わせて更新
- ローカルテスト全件パス
PRを作成しました: #289
[19:20] エンジニア:
ありがとう、マージして。
[19:21] Claude Code:
マージしました。CIの再実行を確認中です。
[19:25] Claude Code:
CI全件パスしました。
Dispatchとの違いに注目してください。Channelsでは途中で「fixtureの変更意図は壊さないで」という追加指示を出しています。この双方向性が、Channelsの強みです。
DispatchとChannelsの使い分け
| 観点 | Dispatch | Channels |
|---|---|---|
| 入力元 | Claudeモバイルアプリ | Telegram / Discord / iMessage |
| 接続先 | Claude Desktop（Cowork / Claude Code） | Claude Code CLI |
| セッションモデル | モバイルからDesktopセッションを起動・継続 | 外部チャットから実行中のCLIセッションへイベントをpush |
| 向いているケース | PCが手元にないが、Desktopに作業を任せたい | 既に起動中のCLIセッションに外部から指示を送りたい |
| 前提条件 | モバイルアプリとDesktopの同一アカウント | Claude Code v2.1.80+、Bun、claude.aiログイン、プラグインインストール |
洞察: 開発の「非同期化」が始まった
ChannelsとDispatchに共通するのは、開発のモデルが変わるということです。
これまで、ソフトウェア開発は「同期的」な作業でした。エディタを開き、コードを読み、修正し、テストを実行し、デプロイする。すべてに開発者のリアルタイムの注意が必要でした。
開発者が行うのは「意図の伝達」と「結果の承認」だけです。コードを書く人から、意図を伝えて品質を判断する人へ。手を動かす人から、方向を決める人へ。
もちろん、現時点ですべての開発作業がこのモデルに移行するわけではありません。複雑なアーキテクチャ設計や、微妙なUXの判断は、依然として開発者がエディタの前で考える必要があります。
ただし、「N+1クエリの修正」「テストの期待値更新」「環境変数の追加忘れ」のような定型的な修正は、非同期モデルで十分に対応できます。そして、日常の開発作業の多くは、実はこうした定型的な修正の積み重ねです。
3つの機能に共通する設計思想
ここまで見てきた4つの事例を並べると、Anthropicの設計思想が透けて見えます。
| 機能 | 開発者から外すもの |
|---|---|
| Dispatch | PCの前にいるという制約 |
| Computer Use | APIの有無という制約 |
| Channels | Claude専用環境という制約 |
共通しているのは、「開発者を開発環境から解放する」という方向性です。
従来の開発ツールの進化は、「開発環境をより良くする」方向でした。より高機能なエディタ、より速いビルドツール、よりリッチなデバッガ。開発者がPCの前に座っていることを前提にして、その体験を改善する方向です。
Claudeの3つの新機能は、そもそも「PCの前に座っている」という前提を外しにかかっています。
- Dispatchは「PCの前にいないと作業を始められない」という前提を外す
- Computer Useは「APIがないと自動化できない」という前提を外す
- Channelsは「専用アプリがないとAIとやり取りできない」という前提を外す
そして事例1が示したように、Dispatch + Computer Useを組み合わせるだけでも「開発者がすべてのステップに介在する」という前提が外れ始めます。Channelsを加えれば、普段使いのチャットアプリからも同様のワークフローが実現できます。
これは「便利になった」というレベルの変化ではありません。開発者の仕事の定義が変わりつつあるという、構造的な変化です。
まとめ
Claudeの3つの新機能は、それぞれ異なるボトルネックを解消します。
| 機能 | プラットフォーム | 単体の効果 |
|---|---|---|
| Dispatch | Claude Desktop | スマホからDesktopに非同期タスク委譲 |
| Computer Use | Claude Desktop / Claude Code | GUIを直接操作して自動化 |
| Channels | Claude Code CLI | Telegram/Discord/iMessageで双方向やり取り |
Desktop側では Dispatch + Computer Use で「指示 → 調査 → 修正 → 検証 → デプロイ」のクローズドループが成立します。CLI側では Channels がチャットアプリからのリアルタイム指示を可能にします。どちらのルートでも、定型的なタスクでは開発者の介在ポイントが最初の指示と最後の承認に集約されていきます。
いずれもresearch preview段階であり、制約や不安定さは残っています。ただ、ツールの完成度以上に重要なのは、自分の開発ワークフローのどこにボトルネックがあるのかを棚卸しすることです。「これまで当たり前だと思っていた制約のうち、どれがもう制約ではなくなったのか」を見極めてください。
答えは、コードの中ではなくワークフローの中にあります。