Claudeのバックグラウンド動作を支える4機能と、任せ方の線引き

この記事のまとめ

Claudeのバックグラウンド動作は、作業を後ろで進めてもらい、人が必要なときだけ入る使い方です。この記事では、それを支える4つの機能と、任せる仕事と手元に残す仕事の線引き、委任した後の検証と安全のための設定を整理します。ポイントは4つです。

エージェントビュー、サブエージェントやフックとバックグラウンドタスク、ワークツリー分離の実行、Dispatchが後ろでの作業を支えます。
独立していて中間ステップを見なくてよいタスクは委任に向き、逐次のやり取りやリアルタイムのデバッグは前面に残します。
完了の報告だけで判断せず、差分の確認とテストの再実行を行い、チェックポイントで前の状態に戻せるようにします。
権限やサンドボックスで動ける範囲を決め、プロンプトインジェクションなどのリスクを踏まえて人の監督を残します。

バックグラウンド動作を支える4機能

エージェントビューによる並行管理

エージェントビューは、動いているセッションをまとめて見て、Claudeが人を必要とするときだけ手を入れるための機能です。私がAI活用プロジェクトを支援する中で感じてきた課題の一つは、「AIに任せたはずなのに、結局ずっと画面を見ていなければならない」という状態でした。エージェントビューは、その問題に直接応える設計になっています。

後ろで走らせたまま、状況を一覧で追えます。Claude Codeのエージェントビューでは、新しいエージェントを起動してバックグラウンドに送れます。

どのエージェントが自分を待っていて、どれがまだ作業中で、どれが完了したかを一目で確認できます。そのため、多くのエージェントに一度に指示を出しやすくなります（参照*1）。

送り方は2通りあります。既存のセッションは、/bgでエージェントビューに追加できます。

新しいセッションは、claude –bg [task]で起動すると、フォアグラウンドを完全に省略できます。長時間動くものでは、PRの見守り役やダッシュボードの更新担当といったループするジョブの次回の実行時刻が、一覧に直接表示されます（参照*1）。

利用には条件があります。エージェントビューは、Pro、Max、Team、Enterprise、Claude APIの各プランでResearch Previewとして提供されています。

claude agentsを実行してオプトインします。通常のレート制限が適用されます（参照*1）。

サブエージェント・フック・バックグラウンドタスク

サブエージェント、フック、バックグラウンドタスクは、Claude Codeが自分で作業を進めるための土台になる仕組みです。役割が分かれている点が重要で、「とにかくAIに全部やらせる」ではなく、どの工程をどの仕組みに担わせるかを設計する余地があります。

3つは役割が分かれています。サブエージェントは、専門的なタスクを委任する仕組みです。メインのエージェントがフロントエンドを構築している間に、バックエンドAPIを立ち上げるような並行した開発ワークフローができます。

フックは、特定の時点でアクションを自動的に起動します。たとえば、コードを変更した後にテストスイートを実行したり、コミットの前にリンティングを実行したりします（参照*2）。

バックグラウンドタスクは、動かし続ける処理のための仕組みです。開発サーバーのような長時間実行プロセスをアクティブなまま保ち、Claude Codeが他の作業を進めるのを妨げないようにします。Anthropicは、これらの機能を組み合わせることで、大規模なリファクタリングや機能探索などの広範なタスクを、安心してClaude Codeに委任できるとしています（参照*2）。ただし、「安心して委任できる」というのはあくまで仕組みの話であり、委任後の検証を省いてよい理由にはならない点は、後述の章で整理します。

ワークツリー分離のバックグラウンド実行

ワークツリー分離のバックグラウンド実行は、リポジトリの分けられたコピーの中でエージェントを動かすやり方です。

手元の作業とは別の場所で走ります。Claude Codeは、git worktreeを介して、リポジトリの分離されたコピー上でバックグラウンドで実行されるエージェントを起動できます。これにより、直線的なペアプログラミングのセッションが、独立したタスクを委任しつつ、実行中も自分の作業を続けられる並列ワークフローに変わります（参照*3）。

起動から完了までの流れは決まっています。まず、現在のHEADに基づいて新しいブランチを作成します。

次に、そのブランチを一時的なワークツリーディレクトリにチェックアウトし、そのディレクトリ内でエージェントを実行します。完了時には、ワークツリーのパスとブランチ名が返ります。エージェントが変更を加えなかった場合、ワークツリーは自動的にクリーンアップされます（参照*3）。

Dispatchによる離席中の委任

Dispatchは、席を外している間にタスクを割り当て、後から結果を受け取るための機能です。私自身、スマートフォンで指示を出して別の作業に移り、デスクトップで結果を確認するという流れは、日常の業務感覚にかなり近いと感じています。

スマートフォンとデスクトップで会話が1つにつながります。AnthropicはDispatchをClaude Coworkの新機能としてリリースし、現在はClaude Codeでも利用できます。

スマートフォンまたはデスクトップから、Claudeとの1つの継続的な会話を行えます。スマートフォンでClaudeにタスクを割り当て、別のことに注意を向け、その後コンピューターで完了した作業を開けます（参照*4）。

指示の例も示されています。Dispatchでは、毎朝メールを自動的に確認するようClaudeに指示したり、毎週いくつかの指標を取得させたりできます。レポートやプルリクエストのために、Claude CoworkまたはClaude Codeのセッションを開始させることもできます（参照*4）。

組み合わせるコンピューター操作には限界もあります。Claude CoworkとClaude Codeのコンピューター操作機能は研究プレビューで、常に完璧に動作するわけではありません。

複雑なタスクでは再試行が必要になることがあります。画面を通じた作業は、直接統合を使うより遅くなります（参照*4）。

任せる仕事と手元に残す仕事

バックグラウンド向きのタスク条件

後ろに回してよいのは、独立していて、途中の様子を見なくても困らないタスクです。逆に言えば、「結果だけ見ればよい」と言い切れないタスクをバックグラウンドに送ると、後から収拾がつかなくなるリスクがあります。

向いている条件は整理されています。ワークツリーエージェントが適したツールになるのは、タスクが独立している場合です。すべての中間ステップを見る必要がなく、最終結果だけが必要な場合にも向きます。

エージェントが並列で実行されている間、自分は現在のセッションで作業を続けたい場合も同じです。タスクがリスクを伴う場合や探索的な場合、現在編集中のファイルを変更されたくない場合も挙げられています（参照*3）。

具体的な例もあります。「認証に関係するすべての場所を探し、パターンを要約する」というコードベースの探索、「このモジュールの統合テストを書く」というテストの生成、「古いロガーのすべての使用箇所を新しいロガーに移行する」という並列リファクタリングが示されています（参照*3）。

タスクの種類によって、成果の受け入れられやすさは変わります。AIDevデータセットの7,156件のプルリクエストを分析し、OpenAI Codex、GitHub Copilot、Devin、Cursor、Claude Codeという5つの主要なエージェントを比較した実証研究があります。この数字は、何をバックグラウンドに回すかを選ぶ際の参考になります。

この分析では、PRのタスクタイプが受け入れ率に影響する主要な要因だと示唆されました。ドキュメント作成タスクの受け入れ率は82.1%で、新機能タスクの66.1%を16パーセントポイント上回りました（参照*5）。

前面に残すべき作業

手元に残したほうがよいのは、やり取りをしながら進める作業です。

適していない条件も示されています。ワークツリーエージェントが向かないのは、エージェントと一つずつ協力する必要がある場合です。

現在進行中の作業のコンテキストが必要な場合も同じです。リアルタイムのやり取りが必要なデバッグを行っている場合も、向いていない場面として挙げられています（参照*3）。

任せきりにしにくい理由は、開発者への調査でも指摘されています。共同で計画を立てることが重要なのは、エージェントに完全に手放しで作業させると、意思決定の空白を独力で正確に埋められないことが多いためです。参加者のP03、P05、P11は、具体性の不足した計画がエージェントに目標を誤解させ、制約を見落とさせると説明しました（参照*6）。これは私がコンサルティング現場で繰り返し見てきた現象と重なります。AIに何をさせるかを決める段階で業務を言語化できていないと、便利な実験で終わってしまいます。

タスク分解と指示の具体化

任せるときは、小さく分けたうえで、成果物と境界をはっきり書きます。私がプロンプト設計の支援をする際も、「AIへの依頼」が曖昧になる原因のほとんどは、依頼者自身がゴールを言語化できていないことにあります。タスク分解はAIのためではなく、まず自分の思考を整理するための作業です。

開発者への調査では、タスクの分解が共同計画の実践として挙がりました。参加者のP17は、タスクを小さな「まとまり」に分解し、それぞれを副作用が最小限で、独立してテスト可能な形にすると説明しました（参照*6）。

指示の書き方は、GitHub Copilot CLIのfleetの解説が具体的です。この解説は、すべての作業項目を、ファイル、テストスイート、ドキュメントのセクションといった具体的な成果物に対応付けるとよいとしています。

曖昧なプロンプトでは、オーケストレーターが独立した部分を特定できないため、順次実行になります。プロンプトに含める内容として、各トラックが担当するディレクトリまたはファイルという境界、テストの変更禁止や依存関係のアップグレード禁止といった制約、合格する必要があるLint、型チェック、テストという検証基準を挙げています（参照*7）。

委任後の検証と復旧の設計

差分確認とマージの手順

完了の報告をそのまま信じず、差分を見てテストを回してから決めます。この姿勢は、AIを使うかどうかに関係なく、ソフトウェア開発の基本です。むしろAIが絡む場合は、「完了した」という報告の信頼性がより問われます。

レビューの手順は3段階です。まず、現在のブランチとの差分をgit diffで確認するか、メインディレクトリでブランチをチェックアウトします。

次に、エージェントが実行済みであっても、メイン環境でもう一度テストを実行します。そのうえで、マージ、再実行、破棄のいずれかを決定します（参照*3）。

要約と実際の変更は別物です。エージェントの概要は、エージェントが実行するつもりだった内容を説明するものです。マージする前に、実際の差分を確認します（参照*3）。私が生成AI導入支援で繰り返し伝えているのも、「AIの出力がうまく見えるほど、内容も正しいと錯覚しやすい」という点です。差分確認はその錯覚を防ぐ最小限の手順です。

判断待ちのセッションには、その場で答えられます。エージェントビューでセッションを選択すると、最後のターンを確認できます。

セッションが判断を待っている場合は、インラインで回答すると、セッションが再開します。完全なトランスクリプトを確認したいセッションには、Enterキーを押して直接接続します（参照*1）。

チェックポイントによる巻き戻し

任せた作業が思った形でなかったときは、チェックポイントで前の状態に戻せます。この「いつでも戻れる」という設計は、AIへの委任を広げるうえで心理的にも重要な役割を果たします。

変更前の状態は自動で保存されます。新しいチェックポイントシステムは、変更する前にコードの状態を自動的に保存します。

Escを2回押すか、/rewindコマンドを使用すると、以前のバージョンにすぐに戻せます。Anthropicは、いつでも以前のコード状態に戻れると分かったうえで、より意欲的で広範なタスクに取り組めるとしています（参照*2）。

戻せる範囲は決まっています。チェックポイントに戻るときは、コード、会話、またはその両方のうち、どれを以前の状態に復元するか選べます。

チェックポイントはClaudeの編集に適用され、ユーザーの編集やbashコマンドには適用されません。Anthropicは、バージョン管理と組み合わせて使用することを推奨しています（参照*2）。

作業した場所の片付けも残ります。作業して変更を加えたワークツリーは、クリーンアップするまでディスク上に残ります。git worktree listですべてのワークツリーを一覧表示し、すでにマージしたものはgit worktree remove /path/to/worktreeで削除します（参照*3）。

並列運用の落とし穴と進捗把握

並列で走らせるほど、起動のしすぎや確認の滞りが起きやすくなります。これはAIエージェントに限らず、人間のチームマネジメントでも同じ問題です。バッチサイズを絞る発想は、実務では特に重要です。

起動しすぎると、自分の手が止まります。すべてのバックグラウンドエージェントは、完了時に人の注意を必要とします。

5分間で10個が完了すると、対応しきれなくなるため、バッチサイズが重要です。1日の作業全体がエージェントの出力に依存する重要な経路では、バックグラウンドタスクにせず、フォアグラウンドで実行して注意を払うことが挙げられています（参照*3）。

同じファイルへの同時書き込みも問題になります。GitHub Copilot CLIのfleetの解説によると、サブエージェントはファイルロックなしでファイルシステムを共有します。

2つのエージェントが同じファイルに書き込むと、最後に完了したエージェントの内容が、何も通知されずに優先されます。エラーもマージもなく、上書きされます（参照*7）。

進み具合を数値で見る手立てもあります。Claude Coworkの管理者向けガイドは、ユーザーごとの日次アクティビティとして、開始したセッション数、完了したツールアクション数、ディスパッチターン数、送信したメッセージ数、スキルの呼び出し数、コネクタの呼び出し数を挙げています。

ディスパッチターン数は自律的なバックグラウンド作業を表す、Claude Cowork独自の指標です。ダッシュボードのデータはT+1のスケジュールで更新され、昨日のデータが今日利用可能になります（参照*8）。

安全に任せるための境界設定

権限とサンドボックスの設定

任せる前に、どこまで動いてよいかを決めておけます。

権限システムで、実行できる操作を切り分けられます。すべてのツールとbashコマンドは、許可、ブロック、またはユーザーに承認を求めるよう設定できます。

globパターンを使って、すべてのnpmコマンドを許可する、sudoを含むコマンドをブロックするといったルールを作れます。組織は、すべてのユーザーに適用されるポリシーを設定できます（参照*9）。

実行環境そのものを狭める方法もあります。bashコマンドは、ファイルシステムとネットワークへのアクセスを制限するサンドボックス環境で実行できます（参照*9）。

sandbox-runtimeの主な機能は、HTTP/HTTPSやその他のプロトコルでアクセスできるホストやドメインを制御するネットワーク制限、読み取りと書き込みができるファイルやディレクトリを制御するファイルシステム制限、ローカルIPCソケットへのアクセスを制御するUnixソケット制限です。macOSでは、システムのサンドボックス違反ログストアを利用して、リアルタイムのアラートを取得します（参照*10）。

自動で進む場面でも、許可が挟まります。コンピューター操作では、Claudeは必要に応じてスクロールし、クリックして開き、探索しますが、必ず最初に明示的な許可を求めます。利用者はいつでもClaudeを停止でき、Claudeは新しいアプリケーションにアクセスする前に必ず許可を求めます（参照*4）。

自律実行に伴うリスクの把握

人が見ていない時間に動くからこそ、リスクの中身を知っておく意味があります。生成AI導入で私がよく受ける相談の一つは、「何かあったときの責任範囲が見えない」という不安です。リスクの輪郭を具体的に把握しておくことが、その不安を扱える状態にする第一歩です。

処理する内容によって、動作が影響を受けることがあります。エージェントは、処理するコンテンツに埋め込まれた指示であるプロンプトインジェクションや、モデルのエラーによって、意図しない動作をする可能性があります。

Claudeモデルはこれに抵抗するよう設計されています。評価の詳細は、デプロイするモデルのモデル概要とシステムカードで確認できます（参照*9）。

外から取り込むスキルファイルにも問題が見つかっています。Cloud Security Allianceの研究ノートによると、Snykの2026年2月のToxicSkills監査では、スキャンした3,984件のスキルのうち1,467件（36.82%）にセキュリティ上の欠陥が報告されました。全体の13.4%はクリティカルと評価され、悪意があるものや明確に武器化されたペイロードと確認された一部も含まれます。この数字は、「便利そうなスキルを外部から拾ってくる」行為が、従来のサードパーティ製コードの扱いと同じリスクを持つことを示しています。

ダウンロード数の上位7件のうち5件はマルウェアと確認されました。同ノートは、エージェントのコンテキストファイルを第三者のコード依存関係と同じ厳しさで扱い、内容の検証、レジストリの来歴管理、実行時の挙動監視を行うべきだとしています（参照*11）。

自律性が高い状況に関する研究もあります。この研究は、実際の導入でエージェント的ミスアラインメントが起きた証拠はこれまで確認していないとしています。

そのうえで、人間による監督が最小限で、機密情報にアクセスできる役割に現在のモデルを導入することへの注意を促しています。説明された行動はすべて管理されたシミュレーションで発生したもので、実験内の人物名と組織名は架空であり、実在の人物は関与していません（参照*12）。

おわりに

バックグラウンド動作は、人から作業を取り上げる仕組みではありません。エージェントビュー、サブエージェントやフックとバックグラウンドタスク、ワークツリー分離の実行、Dispatchはいずれも、後ろで進めておき、判断が必要なときだけ人が入る形をつくります。私はAI活用支援の現場で、「AIに任せる」と「AIに丸投げする」を混同している例を多く見てきました。この4機能の設計思想は、その混同を防ぐ構造になっています。

任せる範囲は、独立していて中間ステップを見なくてよいタスクから決められます。差分の確認とテストの再実行、チェックポイントによる巻き戻し、権限とサンドボックスの設定が、その委任を受け止める側の設計になります。どの工程をAIに渡し、どこで人が判断するかを言語化できた組織だけが、この仕組みを実務に定着させられると考えています。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））