case_1152

Claude CodeのAgent Teamsとは|有効化・使い方・制限

Claude CodeのAgent Teamsとは|有効化・使い方・制限

Claude CodeのAgent Teamsは、リード1つと複数のチームメイトが別々のコンテキストで同時に動く実験機能です。環境変数での有効化、表示モード、モデルの決まり方、権限、トークン費用、制限を公式ドキュメントから整理しました。

2026年10月6日時点の公式ドキュメントで確認した結論から書く。Agent Teamsは、1つのClaude Codeセッション(リード)が複数のClaude Codeセッション(チームメイト)を起動し、共有タスクリストとメッセージで協調させる実験機能だ。既定では無効で、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 をsettings.jsonか環境変数に書くと使える。チームメイトは1体ずつ別のコンテキストウィンドウを持つので、トークンは単独セッションより大きく増え、チームメイトをプランモードで動かすと約7倍になる。

「claude code agent teams」で調べる人の目的は、だいたい3つに分かれる。サブエージェントと何が違うのかを知りたい。どう有効化して、tmuxが要るのかを知りたい。費用と制限を知ってから試すか決めたい。この記事では、Anthropicが公開しているClaude Codeの公式ドキュメント(Orchestrate teams of Claude Code sessions・Manage costs effectively・CHANGELOG)に書かれている内容だけを使って、この3つに答える。

この記事の要点

  • 有効化は環境変数1行:CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 をsettings.jsonの env か、シェルの環境変数に置く。対話セッションが必要で、-p の非対話モードとAgent SDKではチームメイトは起動しない。
  • サブエージェントとの違い:サブエージェントは結果を呼び出し元へ返す。Agent Teamsはチームメイト同士が直接やり取りし、共有タスクリストから自分で仕事を取る。
  • 表示は2種類:既定の in-process はどの端末でも動く。チームメイトごとに画面を分ける split panes は tmux か iTerm2 が要る。
  • 費用:トークンはチームメイトの数に比例して増える。公式は、チームメイトをプランモードで動かすと標準のセッションの約7倍と書いている。
  • 制限:/resume で in-process のチームメイトは戻らない。1セッションに1チーム。チームメイトは自分のチームを作れない。
  • 導入時期:v2.1.32(2026年2月5日)でresearch previewとして追加された。特定の料金プランが条件だという記載は公式ドキュメントにない。

Agent Teamsとは|リード1つとチームメイトが同時に動く仕組み

公式ドキュメントの説明はこうだ。1つのセッションがリードとして働き、仕事を分け、タスクを割り当て、結果をまとめる。チームメイトはそれぞれ独立に動き、自分のコンテキストウィンドウを持ち、互いに直接やり取りする。利用者はリードを通さずに、どのチームメイトにも直接話しかけられる(公式ドキュメント)。

図: 上にリード、下に3つのチームメイト。リードから各チームメイトへ矢印、チームメイト同士は直接やり取り。利用者はリードにもチームメイトにも話しかけられる。下に共有タスクリストとメールボックス
図解1|リード・チームメイト・共有タスクリスト・メールボックスの関係

すでにあるサブエージェントとの違いは、公式の比較表が分かりやすい。

観点 サブエージェント Agent Teams
コンテキスト 自分のコンテキストウィンドウを持ち、結果を呼び出し元へ返す 自分のコンテキストウィンドウを持ち、完全に独立
やり取り 呼び出し元に結果を返す(名前を付けたサブエージェント同士はメッセージ可) チームメイト同士が直接やり取り
調整 メインが全部を管理 メッセージで自律的に調整し、Task ツールを持つエージェントは共有タスクリストも使う
向く作業 結果だけが要る焦点の絞れた作業 議論と協働が要る複雑な作業
トークン 低い(結果を要約してメインへ返す) 高い(チームメイト1体ずつが別のClaudeインスタンス)

公式はこの表の後に、「すばやく焦点の絞られた作業をして結果を返す作業者が欲しいならサブエージェント、チームメイトが発見を共有し、互いに反論し、自分たちで調整する必要があるならAgent Teams」と書いている。言い換えると、Agent Teamsは「並列にする」ための機能ではなく、「並列に動く者同士を会話させる」ための機能だ。並列だけなら、サブエージェントのフォークやバックグラウンド実行で足りる場面が多い。

4つの部品

部品 役割
リード チームメイトを起動し、仕事を調整するメインのセッション
チームメイト 割り当てられたタスクを担当する、別々のClaude Codeインスタンス
共有タスクリスト チームメイトが取って完了させる作業項目の一覧
メールボックス エージェント間のメッセージ機構

メールボックスは1体ずつ ~/.claude/teams/{team-name}/inboxes/{agent-name}.json にあるJSONファイルで、チーム設定は ~/.claude/teams/{team-name}/config.json、タスクリストは ~/.claude/tasks/{team-name}/ に置かれる。チーム名は session- にセッションIDの先頭8文字を付けたものだ。チーム設定のディレクトリはセッション終了時に消え、タスクリストのディレクトリはローカルに残る(アップロードはされない)。チーム設定には実行時の状態(セッションIDやtmuxのペインID)が入るので、手で編集したり、あらかじめ用意したりしても次の更新で上書きされる。プロジェクト側の .claude/teams/teams.json のようなファイルは設定として認識されない。

いつ使うか|サブエージェントで足りる作業との線引き

公式が「最も効く」と挙げる用途は4つだ。

図: 調査とレビュー、新しいモジュールや機能、競合する仮説のデバッグ、層をまたぐ変更はAgent Teamsへ。逐次の作業、同じファイルの編集、依存の多い作業は単独セッションかサブエージェントへ
図解2|Agent Teamsが向く作業と、単独セッションかサブエージェントで足りる作業
  • 調査とレビュー:複数のチームメイトが別々の側面を同時に調べ、発見を共有して互いに反論する
  • 新しいモジュールや機能:チームメイトが別々の部分を1つずつ受け持ち、互いの作業を踏まない
  • 競合する仮説のデバッグ:別々の説を並列に検証し、早く収束させる
  • 層をまたぐ変更:フロントエンド・バックエンド・テストをそれぞれ別のチームメイトが持つ

一方で、公式は「調整のオーバーヘッドが増え、トークンを単独セッションよりかなり多く使う」と明記し、逐次の作業・同じファイルの編集・依存の多い作業には単独セッションかサブエージェントの方が効くと書いている。チームを組む前に、サブエージェントや、自分で立てた複数セッション間のメッセージ(cross-session messaging)で済まないかを確かめるのが公式の推奨順だ。

初めて使うなら、公式は「コードを書かない、境界の明確な作業」から始めるよう勧めている。PRのレビュー、ライブラリの調査、バグの調査がそれだ。並列実装の調整の難しさに触れずに、並列探索の価値だけを確かめられる。

有効化の手順|settings.jsonに環境変数を1行書く

Agent Teamsは既定で無効だ。有効にするには、環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を 1 にする。シェルの環境変数でもよいし、settings.jsonに書いてもよい(公式ドキュメント)。

図: 環境変数、settings.json、対話セッション、チームメイトの順に矢印でつなぐ。下段に非対話モードとAgent SDKは起動しない
図解3|有効化の流れと、チームメイトが起動しない条件
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

この変数が無いと、セッション開始時にチームは作られず、チーム用のディレクトリも書かれず、Claudeはチームメイトを起動も提案もしない。

有効化で押さえておく条件が3つある。

  1. 対話セッションで起動すること。非対話モード(-pでは起動しない)とAgent SDKのセッションでは、チームメイトは起動しない。Claudeが名前を付けたサブエージェントも、そこでは普通のサブエージェントとして動く。
  2. 確認ダイアログは出ない。Claudeが名前付きで Agent ツールを呼ぶと、そのままチームメイトが起動する(フォークと、呼び出し側で isolation を指定した場合を除く)。
  3. 頼んでいなくてもチームになることがある。有効化中は、Claudeが後で連絡するために自分で名前を付けたサブエージェントもチームメイトとして起動する。これを止める方法は後述する。

手順としては、settings.jsonを保存し、対話セッションで起動し、依頼文でチームメイトを依頼する、の3段だ。

最初のチームを動かす|自然言語で人数と役割を指定する

有効化したら、やってほしい作業と欲しいチームメイトを自然言語で書くだけでよい。公式ドキュメントの例はこうだ(3つの役割が互いに待たずに探索できるので、うまくいく例として挙げられている)。

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Spawn three teammates to explore this from different angles:
one on UX, one on technical architecture, one playing devil's advocate.

するとClaudeは、共有タスクリストを埋め(Task ツールがあるセッションの場合)、役割ごとにチームメイトを起動し、探索させ、終わったら発見をまとめる。

ただし公式は、Claudeがチームでなくサブエージェントを使うことがある、とも書いている。サブエージェントもチームメイトと同じエージェントパネルに出るので、パネルを見ただけではチームができたかは分からない。サブエージェントだった場合は、もう一度、Agent Teamsを使うよう明示して頼む。

エージェントパネルの操作

リードの端末では、入力欄の下のエージェントパネルにチームメイトが並ぶ。

操作 動き
上下キー チームメイトを選ぶ
Enter 選んだチームメイトの会話を開き、直接メッセージを送る
Escape 選択を解除する。会話を見ている間は、そのチームメイトの現在のターンを中断する
x 選んだチームメイトを止める
Ctrl+T タスクリストの表示を切り替える

待機中のチームメイトの行は、他の誰かが作業中なら残る。全員が待機になると30秒後に行が隠れ、次のターンで戻る(隠れている間も動いていて、名前で呼べる)。待機中が3体を超えると、超えた分は「2 idle agents」のような1行にまとまり、Enterで展開、Escで戻せる。

表示モード|in-processとsplit panes(tmux・iTerm2)

表示モードは2つある(公式ドキュメント)。

図: 左はin-process。1つの端末の中にエージェントパネル、どの端末でも動く。右はsplit panes。画面が3つに分かれ、tmuxかiTerm2が要り、VS Codeの統合ターミナルでは使えない
図解4|in-processとsplit panesの違い
  • in-process:チームメイト全員がメインの端末の中で動く。エージェントパネルから選んで見る。どの端末でも動き、追加の準備は要らない。
  • split panes:チームメイトごとに画面(ペイン)を持つ。全員の出力を一度に見られ、ペインをクリックして直接やり取りできる。tmuxかiTerm2が要る。

設定キーは ~/.claude/settings.json の teammateMode で、値は4つだ。

値 動き
"in-process" 既定。メインの端末内で動く
"auto" すでにtmuxセッションの中で動いている時、またはiTerm2で it2 CLIが入っている時だけ split panes。それ以外は in-process
"tmux" split panes にする。tmuxかiTerm2かは端末から自動判定
"iterm2" iTerm2のネイティブの分割を明示的に使う。it2 CLIが無ければインストールコマンド付きのエラーが出る

1回のセッションだけ変えるなら claude --teammate-mode auto のようにフラグで渡せる。このフラグは実験的で、claude --help には出ない。

split panes の準備は、tmuxならOSのパッケージマネージャで入れる(tmux wiki)。iTerm2なら it2 CLI を入れ、iTerm2の設定で Python API を有効にする。公式は、tmuxは特定のOSで既知の制限があり、macOSで最もよく動くこと、iTerm2では tmux -CC が入口として勧められることも書いている。

注意点として、split panes は VS Codeの統合ターミナルでは使えない。Windows Terminal と Ghostty も非対応だ。既定の in-process はどの端末でも動くので、VS Codeから使うなら in-process のままでよい。

チームメイトのモデルと人数の決め方|優先順位は4段階

チームメイトの数は、Claudeが作業内容から決めるか、依頼文で指定する。公式の例は「4体を起動してこれらのモジュールを並列にリファクタリングして。各チームメイトはSonnetを使って」という形だ。

モデルは、次の優先順位で上から順に当てはまるものが使われる(公式ドキュメント)。

  1. 依頼文で指定したモデル
  2. サブエージェント定義のmodel(サブエージェント定義から起動したチームメイトの場合。inherit ならリードのモデル)
  3. CLAUDE_CODE_SUBAGENT_MODEL(inherit 以外が設定されている時)
  4. リードのモデル

CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 を設定すると上の1と2は使われず、CLAUDE_CODE_SUBAGENT_MODEL かリードのモデルで全員が決まる(v2.1.257以降)。v2.1.251より前は CLAUDE_CODE_SUBAGENT_MODEL が最優先だった。teammateDefaultModel という設定はv2.1.234で削除され、残っていても無視される。モデルは依頼文で名指しするのが公式の案内だ。

組織の availableModels の許可リストに引っかかるモデルを選んだ場合は置き換えが起きる。opus のようなファミリー名は、Anthropic API と AWS 上の Claude Platform ではそのファミリーで許可されている最新版に置き換わる(プロバイダ固有のモデル ID を使う環境ではこの置き換えは効かず、他の値と同じ扱いになる)。それ以外の値は、CLAUDE_CODE_SUBAGENT_MODEL が設定されていれば同じ規則でまずそれを試し、なければリードのモデルになる。effort(思考の深さ)は既定でリードを引き継ぐ。split-pane ではv2.1.186からこの引き継ぎが効く。チームメイトのモデルと fast mode は起動時に固定され、後から変えられない。

人数について公式は、3〜5体から始めるよう書いている。独立したタスクが15個あるなら3体が出発点で、「焦点の定まった3体は、散らばった5体に勝ることが多い」とある。1体あたり5〜6個のタスクを持たせると全員が働き続け、誰かが詰まった時にリードが仕事を振り直せる。

タスクリストとメッセージ|共有タスク・直接メッセージ・終了の頼み方

チームの仕事は共有タスクリストで回る。リードがタスクを作り、チームメイトが取って進める。状態は「未着手」「進行中」「完了」の3つで、タスクは他のタスクに依存できる。依存先が終わっていないタスクは取れない。割り当て方は2通りだ。

  • リードが割り当てる:どのタスクをどのチームメイトに渡すかをリードに伝える
  • 自分で取る:チームメイトはタスクを終えると、割り当てのない、取れる状態の次のタスクを自分で取る

同時に同じタスクを取ろうとした時の競合は、ファイルロックで防がれる。依存先が完了すると、依存していたタスクは自動で取れる状態になる。Task ツールを持たないエージェントは、タスクリストでなくメッセージで調整する。

やり取りの仕組みは4つある。メッセージはチームメイトが送れば受け手に自動で届く(リードが取りに行く必要はない)。チームメイトが作業を終えて止まると、リードに通知が届き、最終回答が含まれる。APIエラーでターンが終わった場合も、失敗した旨とエラー文がリードに届く。特定のチームメイトに名前で直接メッセージを送れる。全員に伝えたい時は1人ずつ送る。リードは起動時に各チームメイトへ名前を付けるので、後の依頼文で参照しやすい名前にしたいなら、起動の依頼文で呼び名を指定しておく。

チームメイトの会話を開いている間は、普通の文章とスキルはそのチームメイトに、組み込みコマンドはリードに送られる。/compact・/clear・/rewind はリードの会話に作用するので、この画面から打つと確認が入る。/model と /fast はリードの設定を変えるものなので、この画面からは実行されない。

チームメイトを終わらせたい時は、名前で頼む。「researcher チームメイトに終了を頼んで」のように書くと、リードが終了の依頼を送る。チームメイトは承諾して終了するか、理由を付けて断る。チームの共有ディレクトリはセッション終了時に自動で片付く。

仕上がりの基準を機械で強制したい時は、3つのフックが使える。TeammateIdle はチームメイトが待機に入る直前、TaskCreated はタスク作成時、TaskCompleted はタスク完了時に動き、終了コード2で返すとフィードバックを送って作業を続けさせる(または作成・完了を止める)。

権限とプランモード|承認はリードの画面に出る

チームメイトはリードの権限モードを引き継いで始まる。例外は dontAsk モードで、これは引き継がれない。リードが --dangerously-skip-permissions で動いていれば、チームメイト全員もそうなる。起動後に個々のチームメイトの権限モードは変えられるが、起動時にチームメイトごとに別のモードを指定することはできない(公式ドキュメント)。

チームメイトの権限の確認は、リードのセッションに出る。承認するのは利用者自身だ。確認が多すぎてつらい時は、公式はチームメイトを起動する前に権限設定でよく使う操作を許可しておくよう勧めている。auto modeの分類器を使っている場合、エージェント間のメッセージには2つの検査が入る。別のエージェントから中継された「承認済み」という主張は、利用者の確認ではなく信頼できない入力として扱われる。各メッセージは配信前に審査され、止められたメッセージは受け手に届かない。チームメイトは利用者の代わりに権限を承認できず、拒否された操作を別のチームメイトに頼んで迂回することもできない。

プランモードから起動すると、計画は自動で承認される

複雑で危険な作業は、先に計画させられる。リードをプランモードにしてからチームメイトを頼むと、そのチームメイトは計画ができるまで読み取り専用のプランモードで動く。計画が終わると、チームメイトはリードに計画の承認依頼を送る。ここが要注意で、Claude Codeは依頼が届くとリードのセッションで、リードが内容を確認せずに承認する。利用者に別の確認は出ない。承認後の編集やコマンドは、通常どおり権限の確認を通る。

トークン費用|プランモードで約7倍、キャッシュは5分

Agent Teamsは単独セッションよりはるかに多くのトークンを使う。チームメイトはそれぞれ自分のコンテキストウィンドウを持ち、使用量は動いているチームメイトの数に比例する。公式のコスト管理ページは、チームメイトをプランモードで動かすと標準のセッションの約7倍のトークンを使うと書いている。対策として、コスト管理ページはタスクを小さく自己完結にすることを、Agent Teams のページは日常的な作業には単独セッションを使うことを挙げている。チームメイトは終了するまでトークンを消費し続ける点も、同ページに注意として載っている。

図: 単独セッションの短い棒と、約7倍の長さのAgent Teamsの棒。プランモード、チームメイトの数に比例。下段にキャッシュは5分、設定はsubagentPromptCacheTtl
図解5|トークンの増え方とキャッシュの保持時間

プロンプトキャッシュにも違いがある。in-process のチームメイトのリクエストはメインの会話のキャッシュの枠に入らないので、キャッシュの保持は既定で5分だ(Claudeの定額契約でも同じ)。1時間にしたい時は subagentPromptCacheTtl を 1h にする。APIでは1時間のキャッシュ書き込みは高い単価で課金される。

費用の見方をまとめると、人数と稼働時間に比例して増える、ということだ。公式が「3〜5体から始める」「タスクは1人分の成果物が明確な大きさに切る」と言うのは、品質のためでもあり、費用のためでもある。並列セッションの律速がどこに出るかは、並列運用の3つの律速でも整理している。

既知の制限|/resumeで戻らない・1セッション1チーム・入れ子不可

公式が列挙している制限は次のとおりだ(公式ドキュメント)。

制限 内容
セッション再開 /resume と /rewind は in-process のチームメイトを復元しない。再開後にリードが存在しないチームメイトへ話しかけることがあるので、新しいチームメイトを起動するよう伝える
タスク状態の遅れ チームメイトがタスクを完了にし損ねて、依存するタスクが止まることがある。詰まって見えたら実作業を確かめ、手で状態を直すかリードに促させる
終了の遅さ チームメイトは今のリクエストやツール呼び出しを終えてから止まる
1セッション1チーム チームはセッションに1つだけ。名前付きの別チームや、セッション間でのチーム共有はできない
入れ子不可 チームメイトは自分のチームメイトを起動できない。チームを管理できるのはリードだけ
バックグラウンドのサブエージェント in-process のチームメイトのサブエージェントはフォアグラウンドで動く。background: true の定義はエラーになる
リード固定 メインのセッションが最後までリード。チームメイトを昇格させたり、リードを移したりできない
権限は起動時に決まる 起動後に個別に変えられるが、起動時にチームメイトごとの指定はできない
split panes の前提 tmux か iTerm2 が要る。VS Codeの統合ターミナル・Windows Terminal・Ghostty では使えない

自分で複数のセッションを立てて並列に進める方法としては、git worktree も公式が「手動の並列セッション」として案内している。チームの自動調整なしに、自分で複数のセッションを回す方法だ。

勝手にチームになる時の止め方|変数を0にする

有効化中は、リードのセッションでClaudeが名前を付けたサブエージェントはチームメイトとして起動する。Claudeは後で連絡するために自分で名前を付けることがあるので、チームの話をしていないのにチームができることがある。名前付きのサブエージェントを普通のサブエージェントに戻すには、変数を 0 にする。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "0"
  }
}

新しいセッションを始める必要はない。settings.jsonの env は保存時に実行中のセッションへ再適用され、Claudeがサブエージェントを起動するたびに変数が読み直される。ユーザー設定で 0 にすると、シェルの export より優先される。ただし、プロジェクト設定・ローカル設定・--settings で渡した設定は後から適用されるので、そこで 1 になっていればそちらが勝つ。管理者が managed settings で有効にしている場合は、管理者に変更を頼む。

そのほかの困りごとは、公式のトラブルシューティングにまとまっている。

  • チームメイトが出てこない:in-process ならエージェントパネルを上下キーで選ぶ。待機で隠れた行は止まったのではないので、名前でメッセージを送ると戻る。作業がチームを組むほど複雑でないとClaudeが判断した可能性もある。split panes を明示したのに出ないなら which tmux でPATHを確かめる。
  • 権限の確認が多すぎる:起動前に権限設定で許可しておく。
  • 途中で止まる:エラーで止まったチームメイトの出力を開き、指示を足すか、代わりのチームメイトを起動する。リードや他のチームメイトからのメッセージは、APIの再試行待ちのチームメイトをすぐ再試行させる。リードが全タスク完了前に「終わった」と判断したら、続けるよう伝える。
  • tmuxのセッションが残る:tmux ls で一覧を見て、チームが作ったものを tmux kill-session -t <名前> で終わらせる。

想定例|PRを3体で並列レビューする

公式の用例を、ここでは想定として1つだけなぞる。レビュアーが1人だと、1種類の問題に目が寄りがちだ。公式の例では、PR #142 に対してセキュリティ・性能・テスト網羅の3つの観点をそれぞれ別のチームメイトに持たせ、各自がレビューして報告し、終わった後にリードが3つの発見をまとめる。

Spawn three teammates to review PR #142:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

この型が向くのは、観点が独立していて、同じファイルを同時に編集しない作業だ。公式は「2体が同じファイルを編集すると上書きが起きる」と書いているので、実装まで任せる時は、チームメイトごとに持つファイルの集合を分ける。起動の依頼文にはタスク固有の情報(対象のパス、使っている技術、報告の形式)を入れる。チームメイトはCLAUDE.md・MCPサーバー・スキルは読み込むが、リードの会話の履歴は引き継がないからだ。

よくある質問

Agent Teamsはいつから使えるのか

Claude Code v2.1.32(2026年2月5日)で「research preview」として追加された。公式CHANGELOGには「トークンを多く使う機能で、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 の設定が必要」と書かれている。同じ版でClaude Opus 4.6が使えるようになり、Opus 4.6の発表でも、Claude Codeの agent teams が research preview として紹介された。

使える料金プランの条件はあるか

2026年10月6日時点の公式ドキュメントに、特定のプランを条件とする記載はない。有効化の条件は環境変数だ。なお翌日のv2.1.33で「現在のプランではAgent Teamsが使えない」という誤った警告が出るバグが修正されている。

tmuxは必須か

必須ではない。既定の in-process はどの端末でも動く。tmuxかiTerm2が要るのは、チームメイトごとに画面を分ける split panes を使う時だけだ。

Windowsで使えるか

in-process はどの端末でも動く。split panes は Windows Terminal では使えない。

チームメイトは何体まで起動できるか

公式に上限はない。実務上の制約として、トークンが人数に比例して増えること、調整の手間が増えること、ある数を超えると効果が頭打ちになることが挙げられ、3〜5体から始めることが勧められている。

Agent SDKや非対話モードで使えるか

使えない。-p の非対話モード(Agent SDKのセッションを含む)では、Claudeはチームメイトを起動しない。名前を付けたサブエージェントも普通のサブエージェントとして動く。

チームメイトは何を引き継ぐのか

CLAUDE.md・MCPサーバー・スキルといったプロジェクトの文脈は通常のセッションと同じく読み込む。リードを --setting-sources で起動した場合は同じ制限された設定元から読む(v2.1.281より前は、split-pane のチームメイトはすべての設定元を読んでいた)。リードの会話の履歴は引き継がないので、必要な情報は起動の依頼文に書く。

あわせて読みたい

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る(無料)

参考・出典

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、AI開発ツール導入の失敗を減らせます。

導入を相談する

チームで学ぶなら: Claude Code 法人研修(2日間ハンズオン) / 1人で習得するなら: 個別指導(週1マンツーマン)