Claude Code に追加されたリモートセッション系 5 コマンド徹底解説

はじめに

Claude Code を起動して / を入力すると、リモートセッションを起動するコマンドが新しく 5 つ並んでいることに気づきます。

• /autopilot — Spawn a remote Claude Code session that runs the autopilot workflow on your task
• /bugfix — Spawn a remote session that reproduces, root-causes, fixes, and regression-tests a bug
• /dashboard — Spawn a remote session that designs and builds a dashboard from your data sources
• /docs — Spawn a remote session that discovers a feature surface and writes or updates its docs
• /investigate — Spawn a remote session that root-causes an incident and produces a report with a suggested fix

いずれも共通して「ローカルの Claude Code から リモートセッション をスポーンする」という性質を持ちます。これまでも /autofix-pr や /ultraplan、/schedule（routines）など、Claude Code on the web に橋渡しするコマンドはいくつか存在していましたが、今回追加された 5 つはより タスク指向 のラインナップです。

この記事では、それぞれのコマンドの位置づけ、共通する仕組み、実際の使い分けを解説します。

共通する仕組み — 「Claude Code on the web」へのワークフロー特化エントリポイント

5 つのコマンドはどれも、ローカルセッションでコマンドを叩くと Anthropic 管理のクラウドインフラ上で動く Claude Code セッションを新しく起動する ように設計されています。すでに提供されていた以下のコマンドの仲間と考えるとわかりやすいでしょう。

新しく追加された 5 コマンドはこの「リモート起動系」のラインナップに、ワークフロー単位で目的特化したテンプレート を加えた位置づけです。

ローカルの作業環境を占有せずに長時間のタスクを走らせたい、結果だけブラウザで確認したい、複数のタスクを並列でクラウドに任せたい — こうしたユースケースに直接マッピングします。

これらのコマンドは Claude Code on the web を前提にしています。利用には Pro / Max / Team / Enterprise などのプラン要件と、Web 連携（/web-setup で GitHub アカウントを接続）が必要です。

## /autopilot — 汎用オートパイロット

> /autopilot リファクタした認証モジュールに対するテストを書いて、CI を通して PR を出して

/autopilot は 特定の領域に縛られない汎用のオートパイロットワークフロー を、リモートセッションで走らせます。

イメージとしては「ローカルでは時間がかかるが手順は明確なタスク」を、クラウドに丸ごと預ける用途です。たとえば次のようなタスクが向いています。

• まとまった量のリファクタリングと、それに伴うテスト修正
• 依存ライブラリのアップデートとビルド・テストの追従
• スキャフォールディングしたコードに肉付けして PR を出すまでの一連の作業

/autofix-pr が「すでに開いている PR の追従」に特化しているのに対し、/autopilot は タスク開始から完了まで を任せたいときに使います。

/bugfix — バグの再現・原因特定・修正・回帰テスト

> /bugfix /api/users で 500 エラーが返るときがある。再現と修正をお願い

/bugfix は、その名のとおり バグ修正フロー専用 のリモートセッションを起動します。コマンド説明にあるとおり、以下のステップを 1 セッションで完結させるよう設計されています。

1. Reproduce: バグを再現する手順 / 失敗するテストを作る
2. Root-cause: スタックトレースとコードを読んで原因を特定する
3. Fix: 修正コミットを作る
4. Regression-test: 同じバグが再発しないようテストを追加する

ローカルで再現まで行って /bugfix に投げると、原因特定からテスト追加までクラウドで完結し、ブランチに PR が積まれた状態で戻ってきます。

/autopilot との違いは、プロセスが「再現 → 原因 → 修正 → 回帰テスト」というバグ修正のお約束に固定されている 点です。曖昧な指示でも、Claude が「まず再現するテストを書く」というステップから外れにくくなります。

/dashboard — データソースからダッシュボードを生成

> /dashboard PostgreSQL の events テーブルから日次 KPI ダッシュボードを作って

/dashboard は、接続したデータソースを読んで ダッシュボード UI を設計・実装するリモートセッション をスポーンします。

ダッシュボード作成は、データの読み取り → スキーマ理解 → 可視化方針の決定 → コード生成 → デプロイ確認、と工程が長く、人間の確認ポイントも多いタスクです。/dashboard はこの一連の流れに対する ワークフロー特化のプロンプトテンプレート として用意されています。

データベースや BI ツールへのアクセスは、routines と同じく MCP コネクタや環境変数 を介してクラウド側に渡されます。事前にコネクタや環境変数を設定しておくことで、リモートセッションがそのまま読み書きできる状態になります。

/docs — 機能を発見してドキュメントを書く

> /docs 新しく追加した webhooks モジュールのリファレンスドキュメントを書いて

/docs は、対象とする 機能サーフェス（feature surface）を発見し、それに対応するドキュメントを新規作成または更新するリモートセッション を起動します。

具体的なフローは次のような流れになります。

1. 指定された範囲（例: webhooks/ ディレクトリ）のコードを読み、公開 API・型・設定項目を一覧化する
2. 既存のドキュメント（README、/docs 配下、コメント）と突き合わせる
3. 抜けているリファレンス、古くなった例、未文書化の挙動を抽出する
4. ドキュメントを生成または更新して PR を出す

特に「コードは進んだがドキュメントが追いついていない」状態を継続的に解消するのに向いています。routines の Docs drift ユースケース（マージ済み PR をスキャンしてドキュメント PR を起こす）を、その場で 1 回だけ走らせる版という捉え方もできます。

/investigate — インシデントの原因究明とレポート作成

> /investigate 昨夜の決済 API のレイテンシ悪化について原因と対策案をまとめて

/investigate は、インシデントの根本原因を特定し、提案する修正を含むレポートを生成するリモートセッション を起動します。

ポイントは「修正コミットを直接出す」ではなく、レポートを成果物とする ところです。原因が複数のコンポーネントにまたがる、本番影響を伴う、人間の判断を挟むべき — そうした性質のインシデントを扱う前提になっています。

典型的なフローは次のとおりです。

1. インシデントの症状（エラーメッセージ、メトリクス、影響範囲）を入力として受け取る
2. 関連するログ・メトリクス（コネクタ経由）と、リポジトリ内の関連コードを横断的に読み込む
3. 直近の変更履歴（コミット、デプロイ、設定変更）と症状を突き合わせる
4. 根本原因の仮説を立て、最も確度の高いものを選ぶ
5. 修正案（コードパッチや設定変更）を含むレポートを成果物として返す

/bugfix がコードの修正までを目的にするのに対し、/investigate は 「人間の意思決定材料となるレポート」 を出すことが目的です。アラート対応や障害ポストモーテムの初動を半自動化するのに向いています。

どのコマンドをいつ使うか

5 つのコマンドの使い分けを表にまとめると次のようになります。

既存の routines・/autofix-pr との関係

新しい 5 コマンドは routines（/schedule） や /autofix-pr と機能的に重なる部分がありますが、用途は明確に分かれています。

• routines は「保存して、繰り返し走らせる」設定です。スケジュール、API、GitHub イベントといった トリガ を持ちます。
• /autofix-pr は「現在のブランチの PR」を対象にした、用途特化のリモートセッションです。
• 新しい 5 コマンド は、ワンショットで起動する、ワークフロー特化のリモートセッション です。トリガは「ユーザーが今コマンドを叩いたこと」だけで、繰り返し性はありません。

つまり関係は次のように整理できます。

ワークフロー特化  汎用
    ┌────────────┬────────────┐
ワンショット     │ /autopilot │            │
                │ /bugfix    │ （/teleport│
                │ /dashboard │  /ultraplan│
                │ /docs      │  ...）      │
                │ /investigate│           │
    ┌────────────┼────────────┤
リピート       │ /autofix-pr│ /schedule  │
                │            │ (routines) │
    └────────────┴────────────┘

ワークフローを毎日定期実行したくなったら、その内容をベースに /schedule で routine 化する、という流れにも自然に乗ります。

実践 Tips

コネクタと環境変数を先にそろえておく

リモートセッションはローカル環境を見られません。/dashboard がデータベースに、/investigate がログ基盤に、/bugfix が CI ログにアクセスする必要がある場合は、MCP コネクタ と クラウド環境 の Environment variables を事前に設定しておきます。

Settings > Connectors でコネクタを接続し、必要であれば routines と同じ「クラウド環境」を作っておくとリモートセッションから一貫してアクセスできます。

プロンプトは「成功の定義」を含める

リモートセッションは途中で人間が止めて方向修正する機会が少ないため、プロンプトには 何が完了条件か を含めるのが安全です。

> /bugfix /api/users で発生する 500 を直して。完了条件は (1) 失敗を再現する Jest テストがあり、(2) 修正後に test:e2e が green、(3) PR の説明に再現手順と修正内容がある

ブランチは claude/ プレフィックスがデフォルト

routines と同様に、リモートセッションのデフォルトでは claude/ プレフィックスのブランチにしか push できないようガードされています。protected branch を直接さわらないため安全に走らせられます。

結果はブラウザでも確認できる

リモートセッションには共有可能な URL があり、ブラウザで実況を確認できます。長いタスクの間にローカルの Claude Code セッションは別の作業に使えるため、「クラウドに重い作業を出して、手元で軽い作業を続ける」 という運用がしやすくなっています。

必要なら /teleport でローカルに引き取る

リモートセッションの途中で「やはり手元で続きをやりたい」となったら、/teleport（/tp）でローカルに引き取ることができます。リモートとローカルは分断されておらず、用途に応じて行き来できる設計になっています。

まとめ

新しく追加された 5 つのコマンドは、「リモートセッションを起動する」という共通の仕組みの上に、ワークフローごとのテンプレート を被せたものです。

• /autopilot — 汎用オートパイロット
• /bugfix — バグ修正フロー特化
• /dashboard — ダッシュボード生成
• /docs — ドキュメント補完・更新
• /investigate — インシデント原因究明レポート

それぞれのコマンドは、内部的には Claude Code on the web のセッションをスポーンしているという点で /autofix-pr や /ultraplan と同じ系統に属しますが、目的特化のプロンプトとフロー が組み込まれているぶん、曖昧な指示でも所定のステップを踏みやすくなっています。

長時間タスクや並列作業をクラウドに切り出す手段として、ローカルの Claude Code を「司令塔」として使う運用がますます自然になってきました。

参考

• Commands — Claude Code Docs
• Automate work with routines — Claude Code Docs
• Claude Code on the web — Claude Code Docs
• Changelog — Claude Code Docs