はじめに
Claude Code の実行モードが、この半年で一気に増えました。
対話モード、Plan Mode、/loop、Routines、Agent Teams、Subagents、Desktop Scheduled Task といった具合に、名前だけ見ると似たような機能が並んでいます。筆者自身、最初は「Routines と /loop って何が違うのか」「Agent Teams と Subagents はどう使い分けるのか」で混乱しました。
本記事では、筆者が実運用で触った範囲でメンタルモデルを整理します。判断軸を3次元に分解し、併用パターンまでまとめることで、「このタスクはどのモードで走らせるか」を迷わず決められる状態を目指します。
対象読者は、Claude Code を普段から触っていて、実行モードの選択肢を一度棚卸ししたい方です。個々のモードの詳細な使い方は公式ドキュメントや既存記事に譲り、ここでは選び方に寄せた整理を行います。
実行モード一覧
1. 対話モード（Interactive）
CLI を起動して claude と打った直後の、もっとも標準的なモードです。ユーザーのプロンプトに対して1ターンずつ応答が返り、ファイル編集やコマンド実行の許可も都度確認されます。
- 同期/非同期: 同期
- スコープ: 単発の対話セッション
- 並列性: 単一
- 実行場所: ローカル（手元のマシン）
- トリガー: ユーザーの入力
2. Plan Mode
「計画だけを立てて編集はしない」モードです。ファイルを書き換えずに計画案を提示し、承認されてから実装に移ります。
- 同期/非同期: 同期
- スコープ: 単発
- 並列性: 単一
- 実行場所: ローカル
- トリガー:
/planコマンド、--permission-mode planフラグ、または Shift+Tab による permission mode 循環（default → acceptEdits → plan）
対話セッションから直接入るときは /plan か起動オプションが確実です。Shift+Tab は permission mode を順に切り替える挙動なので、現在のモード表示を確認しながら使います。Plan Mode で計画を固めてから対話モードに戻ると、大きめのタスクでも手戻りが減る印象です。
3. /loop
対話セッションの中で、指定したプロンプトやスラッシュコマンドを一定間隔で繰り返すスキルです。/loop 5m /check-deploy のように書きます。
- 同期/非同期: 半同期（セッションを開いたまま）
- スコープ: 繰り返し
- 並列性: 単一（ただし同時に別セッションを開けば複数は可）
- 実行場所: ローカル
- トリガー: 時間間隔、またはモデル自身の自己ペーシング
/loop はセッション内スケジューリングです。対話セッションを閉じるとループも消えるので、「いまの作業中に何かを監視したい」ケース向きです。恒常的な定期実行が必要なら Routines や Desktop Scheduled Task を選びます。
4. Routines
2026年4月14日にリリースされた、クラウド実行型の定期タスク機能です。スケジュール、API 呼び出し、GitHub イベントの3種類のトリガーに対応しています。現時点では research preview 扱いで、仕様は今後変更される可能性があります。
- 同期/非同期: 非同期
- スコープ: 繰り返し
- 並列性: 複数（別タスクと独立）
- 実行場所: クラウド（手元のマシンがオフラインでも動作）
- トリガー: cron 式、Webhook、GitHub イベント
プランごとに日次の実行上限が設定されていますが、プラン枠を超えた分は extra usage として追加課金で継続できる仕様です。最新の枠は公式ドキュメントを参照してください。
出典: https://9to5mac.com/2026/04/14/anthropic-adds-repeatable-routines-feature-to-claude-code-heres-how-it-works/ / https://code.claude.com/docs/ja/web-scheduled-tasks
5. Agent Teams
複数の Claude Code インスタンス（teammate）を束ねて、役割分担しながら並列に走らせる仕組みです。各 teammate は独立したコンテキストを持ち、チーム定義ファイルで割り当てられた役割に沿って動きます。成果物やメッセージをやり取りすることで協調しますが、コンテキスト自体は共有されません。
- 同期/非同期: 同期
- スコープ: 単発（1タスクをチームで分担）
- 並列性: 複数（独立コンテキストの teammate を並列）
- 実行場所: ローカル
- トリガー: チーム起動スキルやチーム定義ファイルに紐づくコマンド（
/team系コマンドは非公式・experimental で既定では無効）
ポイントは「独立コンテキストの teammate を並列化して役割分担させる」ことで、後述の Subagents に近い構成ですが、チームとして構造化されている点が異なります。
6. Subagents
同一セッション内で動く、独立コンテキストの worker です。親エージェントから Agent ツール（v2.1.63 で Task からリネームされ、現在は Task は alias として残っています）経由で起動し、同じプロセス内で別コンテキストとして並列に走ります。結果だけが親に返り、途中経過のコンテキストは親に積まれません。
- 同期/非同期: 同期（親は結果を待つ）
- スコープ: 単発
- 並列性: 複数（独立コンテキスト）
- 実行場所: ローカル
- トリガー: 親エージェントからの委譲（例として筆者が自作した
/deep-researchのような skill から呼び出すケースもあります。/deep-researchは公式機能ではなく skill の自作例です）
親のコンテキストを汚さずにリサーチや調査を任せられる点が大きい利点です。
7. Desktop Scheduled Task
Claude Code Desktop アプリに内蔵されている、ローカル実行の定期タスク機能です。launchd や cron の別名ではなく、Desktop アプリ内のスケジューラとして独立しています。アプリが起動していて、かつマシンが起床中のときのみ実行される点に注意が必要です（スリープ中やアプリ終了中は走りません）。
- 同期/非同期: 非同期
- スコープ: 繰り返し
- 並列性: 単一〜複数（スケジュール設定次第）
- 実行場所: ローカル
- トリガー: Desktop アプリ内のスケジューラ
クラウドに投げづらい社内ファイルを触るケースで、いまも残る選択肢という位置づけです。
一覧表
| モード | 同期/非同期 | スコープ | 並列性 | 実行場所 | 主なトリガー |
|---|---|---|---|---|---|
| 対話モード | 同期 | 単発 | 単一 | ローカル | ユーザー入力 |
| Plan Mode | 同期 | 単発 | 単一 | ローカル |
/plan / --permission-mode plan / Shift+Tab |
/loop |
半同期 | 繰り返し | 単一 | ローカル | 時間間隔 |
| Routines | 非同期 | 繰り返し | 複数 | クラウド | cron/API/GitHub |
| Agent Teams | 同期 | 単発 | 複数（独立コンテキスト） | ローカル | チーム起動スキル |
| Subagents | 同期 | 単発 | 複数（独立コンテキスト） | ローカル | 親からの委譲 |
| Desktop Scheduled Task | 非同期 | 繰り返し | 単一〜複数 | ローカル | Desktop アプリ内スケジューラ |
判断軸の3次元
7つを並べると目移りしますが、次の3つの軸で整理すると迷いが減ります。
- ユーザー関与: 同期か非同期か（人が画面の前にいるか）
- スコープ: 単発か繰り返しか
- 並列性: 単一か複数か
この図だけでも、8割くらいのケースは分岐できる感触があります。
もう少し俯瞰したいときは、3軸を2次元にマッピングするのも手です。
左下に「同期・単発」系（対話/Plan/Agent Teams/Subagents）が集まり、右上に「非同期・繰り返し」系（Routines/Desktop Task）が来ます。/loop はその中間です。
各モードの典型的な使い所
ここからは、筆者が実際に使っている範囲での用途イメージです。
対話モード
- 手元のコードをその場で読んでもらう、小さな修正を入れてもらう
- エラーログを貼って原因を考えてもらう
- アイデア出しの壁打ち
いちばん頻度が高い用途です。1〜数ターンで終わる軽いタスクは、ここに収める前提で使っています。
Plan Mode
- 複数ファイルにまたがる機能追加
- 既存アーキテクチャの影響が読みにくい変更
- 設計判断が必要なリファクタ
「計画を見てから Go するか決める」という運用で、大きな変更での手戻りが減ります。小さな修正では逆に重いので、使い分けが要ります。
/loop
- デプロイログの監視
- PR のチェック状態を定期ウォッチ
- 長時間テストの完了待ち
「セッションを開いている時間内での繰り返し」がハマります。セッションを閉じると止まるので、そこは Routines や Desktop Task との住み分けになります。
Routines
- 毎朝のトレンド収集
- 毎晩の経理データ差分チェック
- GitHub Issue のトリアージ
クラウドで勝手に動くので、手元のマシンの状態に依存しないのが大きな違いです。日次・週次で人間が見返すタイプのタスクが合います。
Agent Teams
- 記事執筆の「企画→構成→初稿→レビュー」をパイプラインで流す
- 複数観点のコードレビュー
- 設計→実装→テストを1セッションで回す
各 teammate が独立コンテキストで動くので、役割ごとに前提を持ち込まず並列に進められる点が利点です。引き継ぎは成果物やメッセージを介して行います。
Subagents
- Web 検索の並列リサーチ
- 大きなドキュメントの分割要約
- 仕様書と実装コードの突き合わせ調査
親のコンテキストを汚さずに「重い読み物」を任せられるので、長時間セッションのコンテキスト枯渇対策にもなります。
Desktop Scheduled Task
- 社内ネットワーク内のファイルを触る定期処理
- クラウドに送れないデータを扱う夜間バッチ
- Routines の枠を超える頻度のタスク
Routines が出てからは出番が減りましたが、「ローカルでないと動かない処理」には依然として選択肢です。
併用パターンの一例
単独で使うより、組み合わせたほうが強い場面があります。あくまで一例ですが、筆者の環境で効いた3パターンを挙げます。
パターン1: Routines + Subagent
毎朝の情報収集タスクを Routines に登録し、その中から Subagent を複数呼んで並列リサーチする構成です。
Routines(毎朝7時) → 親エージェント
├─ Subagent(Qiitaトレンド調査)
├─ Subagent(Zennトレンド調査)
└─ Subagent(GitHub Trending調査)
親はまとめ役に徹し、重い読み物は Subagent が独立コンテキストで処理します。毎朝起きると、昨晩までの動向サマリーが output/ に並んでいる状態を作れます。
パターン2: Plan Mode + Agent Teams
Plan Mode で計画を固めたあと、実装フェーズを Agent Teams に渡して並列化するパターンです。
Plan Mode(設計) → ユーザー承認 → Agent Teams
├─ 実装エージェント
├─ テストエージェント
└─ レビューエージェント
Plan Mode で確定した計画ドキュメントを teammate 間で共有入力として渡すことで、チーム間での前提ずれを抑えられます。各 teammate は独立コンテキストで動くため、役割ごとの責務が混ざらないのが利点でした。
パターン3: /loop + Hook
/loop でデプロイ監視を回しつつ、特定の状態変化を Hook で検知して通知する構成です。Hook は lifecycle イベント（セッション開始・終了）、tool イベント（PreToolUse / PostToolUse）、file イベント（ファイル変更）の各フックポイントで発火できます。
/loop 5m /check-deploy
└─ 毎5分ごとの状態チェック
└─ PostToolUse Hook（tool イベント）
└─ 失敗を検知したら push 通知
人間は別作業をしていても、本当に必要なタイミングだけ呼ばれる、という運用に近づけます。
コスト目安
筆者の環境（Max プラン、Opus 4.7 中心、2026年4月時点）での参考値です。あくまで一例で、タスクの重さによって大きくぶれます。
| モード | 1時間あたりの感覚 | 備考 |
|---|---|---|
| 対話モード | 小〜中 | 会話の長さ次第。中盤以降で一気に増える |
| Plan Mode | 小 | ファイル編集しない分、単純対話より軽め |
/loop |
中 | 間隔とプロンプト長に比例 |
| Routines | 中〜大 | 1回あたりの処理量 × 日次回数 |
| Agent Teams | 大 | 並列数の分、素直に増える |
| Subagents | 中〜大 | 独立コンテキスト分の初期化コストが乗る |
| Desktop Task | 中 | 実行回数を cron で絞れる |
コスト面で気をつけたいのは、Agent Teams と Subagents を多用する場合の総トークン量です。並列数を上げるほど体感は速くなりますが、請求書も比例して伸びます。「いまこのタスク、本当に並列が必要か」を1拍置いて考える、くらいが現実的な運用感です。
選び方チェックリスト
迷ったら、上から順に自問する、というのをテンプレ化しています。
- そのタスク、人が画面の前にいる想定か
- 1回で終わるのか、繰り返すのか
- 繰り返すなら、手元がオフラインでも動くべきか
- 並列で走らせたいか。走らせるとして、コンテキストを共有したいか
- クラウドに投げていいデータか、ローカルでないと扱えないか
- 失敗時に誰がどう気づくか（通知・Hook・ログ）
- 止め方は決まっているか（セッション閉じ・Routines 停止・cron 無効化）
特に最後の2つは、非同期系のモード（Routines / /loop / Desktop Task）を使い始めてから「意外と大事」と感じた点です。動き出すのは簡単ですが、止め忘れで気づかないうちにコストが積み上がる、というのは筆者も経験があります。
Agent Teams と Subagents の違い（補足）
混同されやすいので、もう少し掘り下げておきます。
| 観点 | Agent Teams | Subagents |
|---|---|---|
| コンテキスト | 各 teammate が独立 | 独立（親には結果だけ返る） |
| 構造化 | チーム定義で役割を固定化 | 親がその都度アドホックに委譲 |
| 主な用途 | 役割分担された協調作業 | 重い調査、並列リサーチ |
| 結果の扱い | 成果物やメッセージで受け渡し | 成果物ファイルや要約で受け渡し |
| 起動単位 | 複数インスタンスを束ねる | 同一プロセス内の別コンテキスト worker |
| 起動コスト | インスタンス分のオーバーヘッド | 初期化分のオーバーヘッド |
どちらも独立コンテキストという点は同じですが、「チーム定義で役割を構造化したい」のが Agent Teams、「親セッションから必要に応じてその場で委譲したい」のが Subagents、という違いがあります。筆者は、記事執筆のように工程ごとの責務をあらかじめ切り分けたい作業は Agent Teams、Web 検索のように単発で重い読み物を任せたい作業は Subagents、という基準で使い分けています。
参考記事に挙げたように、Zenn でも「Subagent と Agent Teams の違い」を整理する記事が複数出ています（https://zenn.dev/toono_f/articles/claude-code-agent-teams-guide、https://zenn.dev/frontline/articles/d98d7e0a822205 など）。興味のある方は合わせて読むと輪郭がはっきりします。
まとめ
Claude Code の実行モードは、一見増えすぎに見えますが、3つの軸（同期/非同期・単発/繰り返し・単一/複数）で整理すると、各モードの居場所が見えてきます。
- 手元で人が見ているなら: 対話 / Plan Mode / Agent Teams / Subagents
- 繰り返しで走らせたいなら:
/loop（セッション内）/ Routines（クラウド）/ Desktop Task（ローカル） - 並列に走らせたいなら: Agent Teams（役割分担を構造化）/ Subagents（都度委譲）
筆者自身、「これが正解」という使い方はまだ模索中です。本記事の分類も、今後 Claude Code がさらに拡張されれば書き換える前提のものになります。それでも、現時点のメンタルモデルとして「3軸で配置する」アプローチは、複数モードの併用を考える土台にはなる気がしています。
読み進めて「この使い分けは自分はこうしている」という意見があれば、コメントで教えてもらえると嬉しいです。筆者側の運用も継続的にアップデートしていきます。