Cowork 設定方法とエージェントチームの作り方【2026年】

Cowork 設定方法を知りたいけれど、どこから始めればいいか分からない——そんな方のために、この記事では Claude Code の Agent Teams（Cowork）の有効化から、エージェントチームの作成・役割定義・タスク管理・メッセージ連携まで、実際の設定ファイルと手順を丁寧に解説します。さらに「サブエージェントと何が違うの？」という疑問にも、設計思想の違いを踏まえてしっかり答えます。関連記事: IT技術カテゴリの記事一覧

Cowork（Agent Teams）の起動と基本設定
1. 有効化の方法
2. 2つの表示モード
エージェントチームの作成方法
1. チーム作成の基本的な指示方法
2. チームのアーキテクチャ
エージェントの役割定義と設定
1. 役割定義のコツ
2. プラン承認フローの設定
タスクの割り振りと進捗管理
1. タスクの割り当て方法
2. 進捗の確認とチームのクリーンアップ
エージェント間のメッセージ連携
1. Mailbox によるメッセージ送受信
2. 競合仮説によるデバッグの例
.claude/agents/ でカスタムエージェントを定義する
1. 定義ファイルの配置場所と形式
2. カスタムエージェントの呼び出し方
AgentTeams とサブエージェントの違い——設定方法だけでなく設計思想を理解する
Claude が自ら判断して AgentTeams を提案するケース
Cowork 設定方法の注意点とトラブルシューティング
1. 現時点の制限事項
2. よくある問題と対処法
あわせて読みたいおすすめ書籍
まとめ
引用・出典

Cowork（Agent Teams）の起動と基本設定

Cowork は Claude Code の実験的機能です。そのため、デフォルトでは無効になっています。まずは有効化の手順から確認しましょう。

有効化の方法

有効化には2通りの方法があります。まず、設定ファイルに環境変数を追加する方法です。~/.claude/settings.json を開き、以下のように記述します。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

一方、シェルの環境変数として一時的に設定する方法もあります。セッションの都度有効化したい場合に便利です。

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude

設定後に Claude Code を再起動すると、サイドバーに Cowork パネルが表示されます。なお、Agent Teams を使用するには Claude Code v2.1.32 以降が必要です。バージョンは claude --version で確認できます。（出典: Claude Code Docs）Claude Code のインストールがまだの方は、Claude Codeインストール方法と初期設定ガイドも参照してください。

2つの表示モード

Agent Teams には2種類の表示モードがあります。用途に合わせて使い分けましょう。

in-process モード（デフォルト）: すべてのチームメンバーがメインターミナル内で動作します。Shift+Down キーでメンバーを切り替えます。tmux 不要で、どのターミナルでも使えます。
split-panes モード: メンバーごとに独立したペインが開き、全員の進捗を同時に確認できます。tmux または iTerm2 が必要です。

表示モードを固定したい場合は、settings.json に teammateMode を追加します。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "teammateMode": "in-process"
}

split-panes モードで tmux を使う場合は、あらかじめ tmux セッション内で Claude Code を起動する必要があります。（出典: Zenn）

tmux new -s agent-team
claude

Claude Code Cowork 設定方法：settings.jsonとターミナルのセットアップ画面 — settings.jsonでCoworkを有効化し、tmuxで起動する手順

エージェントチームの作成方法

Cowork を有効化したら、実際にチームを作成してみましょう。チームの作成は、自然言語で Claude に指示するだけです。複雑なコマンドを覚える必要はありません。

チーム作成の基本的な指示方法

Claude に対して、チーム構成とタスクを自然言語で伝えます。以下はコードレビューチームを作成する例です。

PR #142 をレビューするエージェントチームを作ってください。
レビュアーを3名スポーンします：
- セキュリティへの影響を確認する担当
- パフォーマンスへの影響をチェックする担当
- テストカバレッジを検証する担当
それぞれがレビューして結果を報告してください。

この指示を受けると、Claude はチームを作成し、各チームメンバーを起動して、それぞれのタスクを割り当てます。なお、メンバー数を明示的に指定することも可能です。

4名のチームメンバーを作成して、これらのモジュールを並列でリファクタリングしてください。
各メンバーには Sonnet を使用してください。

チームのアーキテクチャ

作成されたチームは以下のコンポーネントで構成されます。（出典: Claude Code Docs）

コンポーネント	役割
Team Lead	チームを作成・管理するメインの Claude Code セッション
Teammates	独立したコンテキストウィンドウを持つ Claude インスタンス
Task List	全メンバーが参照できる共有タスクリスト
Mailbox	エージェント間のメッセージ通信システム

チーム設定は ~/.claude/teams/{team-name}/config.json に、タスクリストは ~/.claude/tasks/{team-name}/ にローカル保存されます。

エージェントの役割定義と設定

チームメンバーは、起動時に与えるプロンプトで役割を定義します。具体的な役割を与えることで、より精度の高い成果物が得られます。

役割定義のコツ

各メンバーへの指示は、スポーン（起動）プロンプトに含めます。チームメンバーはリードの会話履歴を引き継ぎません。そのため、タスク固有の情報を明示的に渡す必要があります。

以下のプロンプトでセキュリティレビュアーのチームメンバーをスポーンしてください：
「src/auth/ の認証モジュールをセキュリティ脆弱性の観点でレビューしてください。
トークン処理・セッション管理・入力バリデーションを重点的に確認してください。
このアプリは httpOnly Cookie に保存した JWT トークンを使用しています。
問題が見つかった場合は深刻度評価とともに報告してください。」

この例では、レビュー対象のパス・観点・前提知識・アウトプット形式を明示しています。具体的であるほど、チームメンバーの判断ブレが減ります。

プラン承認フローの設定

複雑なタスクや変更リスクが高い作業では、チームメンバーが実装前にプランを提出するよう設定できます。これにより、無駄な実装を事前に防ぐことができます。

認証モジュールをリファクタリングするアーキテクトのチームメンバーをスポーンしてください。
変更を行う前にプランの承認を必須にしてください。

プラン承認が必要なメンバーは、読み取り専用モードでプランを作成し、リードへ承認リクエストを送ります。リードが承認すると実装フェーズに移行し、却下するとフィードバックを元にプランを修正します。（出典: Claude Code Docs）

タスクの割り振りと進捗管理

共有タスクリストは、チーム全体の作業進捗を管理する中心的な仕組みです。タスクには「pending」「in progress」「completed」の3つの状態があります。

タスクの割り当て方法

タスクの割り当ては2つの方法で行われます。

リードが明示的に割り当て: 「このタスクを〇〇メンバーに割り当てて」とリードに指示します。
メンバーが自律的にクレーム: タスクを完了したメンバーが、次の未割り当てタスクを自分で引き受けます。

複数のメンバーが同じタスクを同時に取得しようとする競合を防ぐため、ファイルロックの仕組みが使われています。さらに、タスク間の依存関係も自動管理されます。前のタスクが完了すると、依存していた後続タスクが自動的に unblock されます。

進捗の確認とチームのクリーンアップ

in-process モードでは Shift+Down キーでメンバーを順番に確認でき、Ctrl+T でタスクリストをトグル表示できます。split-panes モードでは、各メンバーのペインをクリックして直接インタラクションできます。

作業が完了したら、チームリソースのクリーンアップを行います。必ずリードに対して実行してください。

チームをクリーンアップしてください

アクティブなメンバーが残っている状態ではクリーンアップが失敗します。そのため、先にすべてのメンバーをシャットダウンしてからクリーンアップを実行しましょう。

エージェント間のメッセージ連携

Agent Teams の大きな特徴の一つが、エージェント同士が直接メッセージをやり取りできる点です。この仕組みが、サブエージェントとの根本的な違いを生み出しています。

Mailbox によるメッセージ送受信

各メンバーは Mailbox を介してメッセージを送受信します。送信方法は2種類あります。

message（個別送信）: 特定のメンバーにメッセージを送ります。
broadcast（一斉送信）: 全メンバーに同時にメッセージを送ります。トークンコストがメンバー数倍になるため、使いすぎに注意が必要です。

メッセージは受信者に自動的に届くため、リードがポーリング（定期確認）する必要はありません。加えて、メンバーが作業を終えてアイドル状態になると、リードへ自動通知が送られます。（出典: claudefa.st）

競合仮説によるデバッグの例

メッセージ連携が特に効果を発揮するのが、競合する仮説を並列で検証するデバッグです。以下はその指示例です。

「メッセージを1回送ると接続が切れる」というユーザー報告があります。
5名のエージェントチームメンバーをスポーンして、それぞれ異なる仮説を調査してください。
科学的な議論のように、お互いの理論を否定しようとしながら議論させてください。
導き出されたコンセンサスを調査結果ドキュメントに記録してください。

この「科学的な議論」アプローチが有効な理由は、アンカリング効果を防ぐためです。単一エージェントが調査すると、最初に見つけた仮説に引きずられる傾向があります。具体的には、複数のエージェントが互いの仮説を否定しようとすることで、より信頼性の高い根本原因に到達できます。

.claude/agents/ でカスタムエージェントを定義する

毎回自然言語で役割を説明するのが面倒な場合、.claude/agents/ ディレクトリにカスタムエージェント定義ファイルを置くことで、再利用可能なエージェントを作成できます。

定義ファイルの配置場所と形式

カスタムエージェント定義は以下のいずれかのパスに配置します。

.claude/agents/{agent-name}.md
.claude/agents/{agent-name}/AGENT.md

ファイルの先頭に YAML フロントマターで属性を定義し、その下にエージェントへの指示（プロンプト）を記述します。以下はセキュリティレビュアーの定義例です。

---
role: security-reviewer
description: セキュリティの観点からコードをレビューする専門エージェント
tools:
  - read_file
  - search_files
---

あなたはセキュリティ専門のコードレビュアーです。
以下の観点でコードを分析してください：

- 認証・認可の実装が正しいか
- 入力バリデーションが適切か
- SQLインジェクションやXSSの脆弱性がないか
- 機密情報がハードコードされていないか

問題を発見した場合は、重要度（高/中/低）と修正方法を明記してください。

カスタムエージェントの呼び出し方

定義したエージェントは、Agent Teams のスポーンや Task ツールから参照できます。また、CLAUDE.md ファイルと同様に、チームメンバー起動時に自動的にプロジェクトコンテキストが読み込まれます。そのため、カスタム定義を活用することで、プロジェクト固有のレビュー基準や役割を標準化できます。関連記事: 生成AIカテゴリの記事一覧

Claude Code Cowork エージェントチームの通信アーキテクチャ図 — Agent Teamsの構成：Team Lead、Teammates、Shared Task List、Mailboxの関係

AgentTeams とサブエージェントの違い——設定方法だけでなく設計思想を理解する

筆者が Cowork を使い始めたとき、正直なところ「サブエージェントと違いが実感できない」という感想でした。ブログ記事の自動生成（リサーチ→執筆→画像生成→WordPress 投稿というパイプライン）で試してみたのですが、サブエージェントでやるのと結果がほとんど変わらなかったのです。

しかし、この「違いが実感できない」という感覚は、AgentTeams の設計思想を理解していなかったことが原因でした。そのため、ここで両者の違いを深掘りしてみましょう。

通信モデルの根本的な違い

最大の違いは、エージェント間の通信モデルです。（出典: Claude Code Docs）

比較項目	サブエージェント	Agent Teams
通信モデル	Fork-Join 型（一方向）	ピアツーピア型
エージェント間通信	不可。親への報告のみ	SendMessage で直接通信可能
調整方法	メインエージェントが全て仲介	共有タスクリストで自律調整
コンテキスト	独立したコンテキストウィンドウ	独立したコンテキストウィンドウ（最大1Mトークン）
トークンコスト	低め（結果のみ返す）	高め（メンバー数に比例）
最適用途	結果だけが重要な集中型タスク	議論・相互検証が必要な複雑なタスク

サブエージェントは「親→子→親」という一方向の通信しかできません。つまり、子エージェント同士は直接話せないのです。一方、AgentTeams では SendMessage を使い、メンバー同士が直接情報を共有したり、互いの成果を検証したりできます。

AgentTeams が有効なユースケース

AgentTeams の本領は「並列探索・相互検証」にあります。具体的には以下のようなタスクが適しています。（出典: charlesjones.dev）

並列調査・リサーチ: 複数の視点から同時調査して相互検証する
独立したモジュール開発: フロントエンド・バックエンド・テストを別担当で並行開発する
競合仮説によるデバッグ: 複数の原因仮説を並列で検証し、最も有力なものを絞り込む
大規模リファクタリング: レイヤー別に担当を分けて並行作業する

AgentTeams が不向きなユースケース

逆に、以下のようなタスクには AgentTeams は向いていません。筆者がブログ記事生成で効果を実感できなかったのも、まさにこのパターンに当てはまっていたためです。

順次依存パイプライン: 「記事生成→画像生成→SEO→WP投稿」のように前工程の出力が次工程の必須入力になるタスク
同一ファイルへの複数書き込み: 複数のメンバーが同じファイルを編集すると上書き競合が発生する
単純なバッチ処理: 独立した同一処理を繰り返すだけなら、コーディネーションのオーバーヘッドが無駄になる

つまり、筆者がブログ記事生成で「効果が実感できなかった」というのは、実は正しい直感でした。あのようなパイプライン型のタスクには、サブエージェントや単一セッションの方が適切なのです。AgentTeams を使うべき場面は、もっと「並列で探索して、互いに議論して検証する」ようなタスクです。（出典: Zenn）

このブログ運営で AgentTeams が生きる設計パターン

では、WordPress ブログ自動化の文脈で AgentTeams が本当に役立つのはどんな場面でしょうか。筆者の運用を例に、具体的なパターンを整理します。

① マルチ視点リサーチ（記事生成の Step 1 強化）

現在の generate-post スキルは1つのエージェントがリサーチから執筆まで担当しています。しかし「深いリサーチが必要な記事」では、AgentTeams に切り替えることで品質を引き上げられます。

Agent A（トレンド担当）: 最新ニュース・SNS の反応・競合記事のトレンドを調査
Agent B（技術検証担当）: 公式ドキュメント・技術仕様の正確性を検証
Agent C（SEO戦略担当）: 競合記事の構成分析・キーワードギャップの特定

3つのエージェントが並列で調査し、SendMessage で互いの発見を共有・補完したうえで執筆エージェントに渡す。これにより、単一エージェントでは見落としがちな視点が補われます。ただし、このパターンが有効なのは「3,000〜5,000字以上の深い記事」で、短い更新記事には過剰です。（出典: claudefa.st）

② ブログ分析の並列収集（blog-analytics スキルの強化）

現在の blog-analytics スキルは GA4 → Search Console の順に逐次アクセスしています。AgentTeams にすると次のように並列化できます。

Agent A: Google Analytics 4 のトラフィック・エンゲージメントデータを取得
Agent B: Google Search Console の検索クエリ・CTR・掲載順位を取得
Agent C: 両データを受け取り、コンテンツギャップ分析と改善提案を生成

A と B が並列で動き、完了後に C が両者の結果を統合して最終レポートを作る。現状は GA4 と Search Console の取得を合わせて5〜10分かかることがありますが、並列化によって半分近くに短縮できます。また、C が A・B の生データを「見ながら」分析できるため、気づきの質も上がります。

③ 記事一括監査スプリント

「全記事の SEO 問題をまとめてチェックしたい」「内部リンクが不足している記事を洗い出したい」といった一括監査タスクには AgentTeams が特に力を発揮します。

Agent A: 記事1〜10のタイトル・メタディスクリプション・キーワード密度を監査
Agent B: 記事11〜20の内部リンク・被リンク構造を監査
Agent C: 記事21〜30の更新優先度を古さ・検索ボリューム・掲載順位で評価

各エージェントが担当記事を独立して処理し、結果だけをリードに報告する。このパターンでは「エージェント間で直接会話する必要がほぼない」ため、実はサブエージェントでも代替できます。一方で、担当範囲が重なったり、あるエージェントの発見が別のエージェントの判断に影響するような場合（「記事 A が記事 B の内部リンク先として最適だと判明した」など）には、SendMessage で直接共有できる AgentTeams の優位性が出ます。（出典: Zenn）

判断基準：AgentTeams にすべきかどうかのチェックリスト

結局のところ、AgentTeams にすべきかどうかは以下の問いで判断できます。

✅ エージェント間で「互いの発見を踏まえてアプローチを変える」必要があるか？
✅ タスクを独立したドメインに分割でき、かつその成果を相互に参照したいか？
✅ 並列化によって質（深さ・多様な視点）が上がるか？（速度だけが目的なら並列サブエージェントでも十分）
❌ 前のステップの出力が次のステップの必須入力になっているか？（なっているなら不適切）
❌ 全員が同じファイルに書き込む可能性があるか？（あるなら競合リスクがある）

3つの ✅ のいずれかに当てはまり、❌ のどちらにも引っかからなければ、AgentTeams が効果を発揮できる設計です。

Claude が自ら判断して AgentTeams を提案するケース

ここまでは「ユーザーが明示的にチームを作るよう指示する」前提で解説してきました。しかし実際には、Claude 側がタスクの複雑さを判断してチーム作成を提案してくるケースもあります。この仕組みを理解しておくと、AgentTeams をより自然に活用できるようになります。

「完全自律」ではなく「提案→承認」モデル

重要な前提として、Claude Code の Agent Teams はユーザーの承認なしには起動しない設計になっています。公式ドキュメントには次のように明記されています。（出典: Claude Code Docs）

If Claude determines your task would benefit from parallel work, it may suggest creating a team. You confirm before it proceeds. Claude won’t create a team without your approval.
（日本語訳: Claude がタスクに並列作業が有効と判断した場合、チームの作成を提案することがあります。実行前に必ずあなたの確認を取ります。 あなたの承認なしにチームを作ることはありません。）

つまり Claude は「このタスクはチームで並列処理した方が良さそうです。チームを作りますか？」と提案し、ユーザーが「はい」と答えてから初めてチームを発足させます。ボタン一押しで承認できるため、実体験としては「いつの間にかチームが動いていた」ように感じることもありますが、設計上は必ず人間の確認が挟まります。

CLAUDE.md で提案のしきい値を下げる

Claude が Agent Teams を提案するかどうかは、CLAUDE.md の記述内容に大きく左右されます。たとえば、筆者のグローバル設定（~/.claude/CLAUDE.md）には次のように書いています。

## エージェントチームの活用
複雑なタスクにはエージェントチームを活用してください。
3ファイル以上・並列調査・複数領域のリサーチ・独立したワークストリームを含む場合は、
積極的にエージェントチームの作成を提案してください。

「proactively propose（積極的に提案せよ）」という一文がポイントです。この記述があることで、3ファイル以上・並列調査・独立したワークストリームを含むタスクで Claude が自発的にチーム作成を打診してくるようになります。逆に CLAUDE.md に何も書かなければ、ユーザーが明示的に指示しない限り提案は来ません。

実際のケース：本番インシデント調査

海外の開発者が公開した体験談（出典: magarcia.io）が、この「提案型 AgentTeams」の動作をよく示しています。

そのエンジニアは意図的に最小限のプロンプトだけを渡しました。

チームを使って根本原因を特定してください。
調査は必ず teammates に任せて、メインスレッドのコンテキストを埋めないようにしてください。

詳細な役割分担は一切指示しませんでした。すると Claude は自ら以下の構造を設計してチームを組みました。

Agent A（インフラ担当）: Datadog でサーバーメトリクスを調査
Agent B（エラー担当）: Sentry でエラートラッキングログを解析
Agent C（コード担当）: 直近のコード変更と差分を調査
Agent D（コミュニケーション担当）: Slack の障害関連スレッドを読み込み

さらに、Agent D が Slack で見つけた「設定パラメータの変更」という手がかりを Agent A に SendMessage で共有し、インフラ側の調査方向を修正するというエージェント間の自律的な情報連携も発生しました。最終的に10分で根本原因（設定パラメータ欠落 → Pod クラッシュループ → DB 接続枯渇）を特定しています。

このケースで重要なのは「Claude が自分でタスクを分解し、担当ドメインを設計した」という点です。ユーザーは「チームを使え」とだけ伝えており、何人に何を調べさせるかは Claude が判断しています。

サブエージェントとの自律性の違い

なお、Agent Teams より軽量なサブエージェント（Sub-agents）では、さらに一歩進んだ自律化が可能です。サブエージェント定義の description フィールドに「Use proactively（積極的に使え）」と書くと、ユーザー確認なしで Claude が自動的に委譲判断を下します。（出典: Claude Code Sub-agents Docs）

たとえば組み込みの Explore サブエージェントは、コードベース探索が必要と判断した際に自動起動し（軽量な Haiku モデル・読み取り専用）、コンテキストを節約しながら効率よく調査を行います。Agent Teams はこの上位版として、より複雑な「相互通信・相互検証」が必要な場面に使われます。

仕組み	自律度	ユーザー確認	向いている場面
Built-in サブエージェント（Explore 等）	高（完全自動）	不要	コード探索・単一集中タスク
カスタムサブエージェント（description: Use proactively）	高（完全自動）	不要	定型の専門タスクの自動委譲
Agent Teams（Cowork）	中（提案→承認）	必要	並列探索・相互検証・議論が必要なタスク

Cowork 設定方法の注意点とトラブルシューティング

実際に Cowork を使う上で知っておきたい注意点をまとめます。

現時点の制限事項

Agent Teams は実験的機能のため、いくつかの制限があります。（※2026年3月現在）

セッション再開不可: /resume や /rewind では in-process のチームメンバーが復元されません。
タスクステータスの遅延: メンバーがタスクを完了済みにし忘れることがあります。手動で状態を更新する必要が生じる場合があります。
シャットダウンに時間がかかる: メンバーは現在のリクエストを処理し終えてからシャットダウンするため、すぐには停止しません。
1セッションにつき1チームのみ: 複数チームの同時管理はできません。
ネストしたチームは不可: チームメンバーがさらにサブチームを作ることはできません。

よくある問題と対処法

メンバーが表示されない場合は、まず Shift+Down キーで確認してください。すでに動作しているメンバーが見えていないだけかもしれません。split-panes モードが動作しない場合は、tmux がインストールされているか確認します。

which tmux

tmux セッションが残ってしまった場合は、以下で確認・削除できます。

tmux ls
tmux kill-session -t <session-name>

Claude Code Cowork Agent Teams のターミナル画面 — Agent Teamsが起動した状態のターミナル（in-processモード）

あわせて読みたいおすすめ書籍

AIエージェントとマルチエージェントシステムの理解を深めたい方には、以下の書籍がおすすめです。

リンク

まとめ

この記事では、Claude Code の Cowork 設定方法とエージェントチームの構築について解説しました。要点を整理します。

有効化: ~/.claude/settings.json に CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1" を追加し、Claude Code v2.1.32 以降で使用できる
表示モード: in-process（デフォルト）と split-panes（tmux/iTerm2 必要）の2種類がある
チーム作成: 自然言語でメンバー構成とタスクを伝えるだけで、Claude が自動的にチームを編成する
カスタムエージェント: .claude/agents/{name}.md に定義ファイルを置くことで再利用可能なエージェントを作れる
サブエージェントとの違い: AgentTeams はメンバー同士が直接通信できるピアツーピア型。サブエージェントは親への一方向通信のみ
使い分けの基準: 「並列探索・相互検証」が必要なタスクには AgentTeams、順次依存パイプラインにはサブエージェントや単一セッションが適切