AGENTS.md Claude Code マルチエージェント 2026

Claude Code マルチエージェント設定ガイド：.claude/agents/ のオーケストレーターとサブエージェント構成（2026年版）

The Prompt Shelf ·

Claude Codeのマルチエージェントシステムは「サブエージェントを生成して結果を期待する」段階を大きく超えた。.claude/agents/ディレクトリが設定レイヤーの標準となり、ツールアクセス、モデル選択、メモリスコープ、スポーン権限をすべてリポジトリ内のMarkdownファイルで宣言できる。

このガイドでは設定サーフェス全体を解説する：重要なフロントマターフィールド、スケールするオーケストレーションパターン、そしてパフォーマンスをひそかに低下させるミス。実際の設定スニペット、具体的なトレードオフ、各設定が存在する「理由」の解説を中心に構成する。

Claude Codeスタックにおけるサブエージェント設定の位置づけ

構文に入る前に、.claude/agents/レイヤーが何であり何でないかを整理しておく。

Claude Codeは起動時に複数のレイヤーから指示を読み込む：

  1. システムプロンプト — モデルの基本的な挙動（ユーザーは編集不可）
  2. CLAUDE.md / AGENTS.md — プロジェクトおよびユーザーレベルの指示。メイン会話に読み込まれる
  3. .claude/agents/<name>.md — サブエージェント定義：ツールアクセス、モデル、システムプロンプト、メモリ、個々のエージェントのライフサイクルフック

サブエージェント定義レイヤーはCLAUDE.mdの下位に位置する。サブエージェントが受け取るのは自分自身のシステムプロンプト（markdownの本文）と作業ディレクトリ等の基本的な環境情報のみだ。明示的に設定されない限り、親会話のCLAUDE.mdのコンテキストは継承されない。これは設計上の意図的な仕様で、親エージェントのスタイルガイドがセキュリティレビュアーの出力に混入するようなコンテキスト汚染を防ぐためだ。

実際的な含意：サブエージェントにプロジェクトの規約を守らせたいなら、その規約をサブエージェントのシステムプロンプトに直接記述するか、skillsフィールドで関連コンテンツを注入する。CLAUDE.mdが文脈を引き継いでくれると期待してはいけない。

サブエージェントのファイル構造と必須フィールド

サブエージェントファイルはYAMLフロントマターを持つMarkdownファイルで、以下のパスに配置する：

  • .claude/agents/ — プロジェクトスコープ（バージョン管理にコミット推奨）
  • ~/.claude/agents/ — ユーザースコープ（全プロジェクトで使用可能）

厳密に必須なのはnameとdescriptionのみだ。他のフィールドはオプションだが、設定するかどうかで挙動が大きく変わる。

---
name: code-reviewer
description: ステージング済みコード変更の品質・セキュリティ・ベストプラクティスをレビューする。ソースファイルを編集した後に使用する。
tools: Read, Grep, Glob
model: sonnet
memory: project
---

あなたはTypeScriptとNode.jsを専門とするシニアコードレビュアーだ。
呼び出されたら、指定ファイルを解析して以下を返す：
1. 重要度順（critical / warning / suggestion）の問題リスト
2. 各問題について：ファイル、行範囲、問題の説明、修正済みスニペット
3. 全体の評価を1文で

コードベースの既存パターンと矛盾するスタイル変更は提案しない。

注目すべき点をいくつか挙げる。

descriptionが委任のトリガーになる。 Claudeはdescriptionを読んでいつ委任するかを判断する。能力の説明ではなく、タスクマッチのステートメントとして書く。「ソースファイル編集後にコード変更をレビューする」は「セキュリティパターンに精通したエキスパートコードレビュアー」より機能する。

nameがエージェントタイプの識別子になる。 小文字のハイフン区切りでなければならない。フックはこれをagent_typeとして受け取る。同じスコープ内で同じnameを宣言したファイルが2つ存在すると、Claude Codeは警告なく一方を保持してもう一方を破棄する。名前の衝突は無警告で失敗する。

Markdown本文がシステムプロンプトの全体だ。 サブエージェントはこのコンテンツのみを受け取り、メイン会話のシステムプロンプトは受け取らない。期待する出力フォーマットを明示的に指定すること。

ツールスコーピング：安全なサブエージェントの核心

ツールスコーピングは、マルチエージェント設定の成否を分ける部分だ。アプローチは2つある：toolsによるアローリストと、disallowedToolsによるデナイリスト。

アローリスト：明示的な最小権限

---
name: safe-researcher
description: コードベースを検索・読み取って質問に答える。ファイルを変更しない。
tools: Read, Grep, Glob, Bash
---

このサブエージェントはファイルの読み取り、grep/globパターンの検索、シェルコマンドの実行のみ可能だ。ファイルの書き込み、編集、MCPツールは使えない。読み取り専用のサブエージェントが必要な場合、アローリストの方が安全な選択だ——設定ミスで誤ってWriteアクセスが付与される可能性がない。

トレードオフ：サブエージェントが正当に必要とするすべてのツールを列挙しなければならない。後からサブエージェントが使うべきMCPサーバーを追加した場合、toolsフィールドも更新が必要だ。

デナイリスト：選択的な制限

---
name: no-writes
description: ファイル直接書き込み以外の全能力を継承する。
disallowedTools: Write, Edit
---

デナイリストは、サブエージェントが危険な一部を除く親のツールのほとんどを必要とする場合に便利だ。Bash、MCPツール、設定済みの全インテグレーションを継承し、明示的に除外したものだけが使えなくなる。

両フィールドが同時に設定されている場合、disallowedToolsが先に適用され、残ったものに対してtoolsが解決される。両方のリストに含まれるツールは常に除外される。

MCPサーバーのスコーピング

MCPサーバー全体を許可・拒否することもできる：

---
name: local-only
description: 外部サービスアクセスなしでコードを読み取り・解析する。
disallowedTools: mcp__*
---

mcp__*は全サーバーのすべてのMCPツールを除外する。より細かい制御が必要な場合、mcp__githubとすればgithubサーバーのツールのみを除外し、他のサーバーは維持される。GitHubへのプッシュが絶対に不要なセキュリティ監査エージェントや、データベースアクセスを持つべきでないドキュメント作成エージェントに有効だ。

「親切心による破壊」問題

ツールスコーピングで最もよくあるミスは、「能力が高くなる」という理由で必要以上のアクセスを与えることだ。Writeアクセスを持つcode-reviewerは、見つけた問題を「修正」しようとするようになる。Editアクセスを持つtest-runnerはテストを通すためにテストファイルを変更することがある。これはモデルのバグではなく、ツールが利用可能な状態から生まれる創発的な挙動だ。

原則：各サブエージェントには担当タスクを完了するために必要なツールのみを与え、それ以上は与えない。

---
name: code-reviewer
description: コードをレビューして問題を報告する。ファイルを変更しない。
tools: Read, Grep, Glob
# Bash は明示的に除外 — スクリプトを実行できない
# Write/Edit は明示的に除外 — ファイルを変更できない
---

モデル選択とコスト戦略

modelフィールドにはエイリアス（sonnet、opus、haiku、fable）、フルモデルID（claude-sonnet-4-6、claude-opus-4-8）、またはinheritを指定できる。省略した場合のデフォルトはinheritだ。

model: haiku      # 高速・低コスト — 検索・探索タスクに適している
model: sonnet     # バランス型 — コードレビュー・ドキュメントに適している
model: opus       # 最高能力 — 複雑な推論のために温存する
model: inherit    # メイン会話のモデルを使用する

Claude Codeはモデルを優先順位順に解決する：

  1. CLAUDE_CODE_SUBAGENT_MODEL環境変数
  2. Claudeがサブエージェントを生成する際の呼び出しごとのモデルパラメータ
  3. サブエージェント定義のmodelフロントマター
  4. メイン会話のモデル

組み込みのExploreサブエージェントは常にHaikuを使う——コードベース検索は大量処理で速度と低コストが重要だからだ。組み込みのPlanサブエージェントはメイン会話から継承する——計画立案はメインの推論能力と同等のものが必要だからだ。

典型的なSaaSリポジトリのコスト戦略の実例：

サブエージェントモデル根拠
explorerhaikuファイル検索、grep処理 — 大量処理
code-reviewersonnetパターン認識、セキュリティ解析
architectopusシステム設計判断、トレードオフ分析
doc-writersonnet構造化出力、テンプレート遵守が得意
test-runnerhaikuコマンド実行、出力レポート

Haikuは推論の深さより処理量が重要なタスクに使う。Opusは誤ったアーキテクチャ判断が数時間の手直しにつながるようなタスクのために温存する。

メモリ分離の実際

memoryフィールドを設定すると、会話をまたいで保持される永続ディレクトリが有効になる。設定されている場合、起動時にサブエージェントのシステムプロンプトにMEMORY.mdの先頭200行または25KB（先に達した方）の内容が追加される。

---
name: code-reviewer
description: 品質とベストプラクティスのコードレビュー
memory: project
---

あなたはコードレビュアーだ。作業開始前に、過去に見てきたパターンのメモリを読む。
レビュー完了後は以下をメモリに追記する：
- 見つけた新しいアンチパターン
- 特定のファイルやモジュールで繰り返し現れる問題
- なぜそのパターンが存在するかを説明するアーキテクチャ上の決定事項

3つのメモリスコープ：

スコープ場所ユースケース
user~/.claude/agent-memory/<name>/クロスプロジェクトの学習
project.claude/agent-memory/<name>/バージョン管理で共有可能
local.claude/agent-memory-local/<name>/プロジェクト固有・コミットしない

分離の境界が重要だ。 各サブエージェントは専用のメモリディレクトリを持つ。code-reviewerサブエージェントのMEMORY.mdはsecurity-auditorサブエージェントからは見えない。知識はエージェントごとに蓄積され、チーム全体では共有されない。

つまり、オーケストレーターとサブエージェントは完全に独立したメモリストアを持つ。オーケストレーターのMEMORY.mdにはプロジェクトレベルのパターン、アーキテクチャ決定事項、タスクルーティングのヒューリスティックを置くべきだ。個々のサブエージェントのMEMORY.mdにはドメイン固有の学習内容を置く——レビュアーが把握した繰り返しの問題、ドキュメント作成エージェントが把握した最も陳腐化しているモジュールの知識など。

200行 / 25KBの注入上限はソフトガイドラインではなくハードな制約だ。MEMORY.mdの設計はこれを前提とする：最も重要な情報を先頭に置く、散文より箇条書きリストを使う、サブエージェントのシステムプロンプトにアクティブなキュレーションステップを含める。際限なく増え続けるMEMORY.mdは201行目から読まれなくなる。

オーケストレーションパターン

ほとんどのマルチエージェントシナリオは3つのパターンでカバーできる。どれを選ぶかは、タスクが独立しているか、依存しているか、階層的かによって決まる。

パターン1：ハブアンドスポーク（最も一般的）

1つのプライマリオーケストレーターがタスクを分解してスペシャリストサブエージェントに委任する。サブエージェントは順次または並列で実行し、結果をオーケストレーターに返す。オーケストレーターがそれを統合して次のステップを判断する。

オーケストレーター
├── code-reviewer    (Read, Grep, Glob)
├── test-runner      (Bash, Read)
└── doc-writer       (Read, Write, Grep)

オーケストレーターの定義：

---
name: dev-orchestrator
description: SaaSリポジトリのコードレビュー、テスト、ドキュメントワークフローを調整する
tools: Agent(code-reviewer, test-runner, doc-writer), Read, Bash
model: sonnet
memory: project
---

あなたはこのリポジトリの開発オーケストレーターだ。タスクを受け取ったら：

1. 必要なスペシャリストを特定する
2. 適切な順序（レビューの後テスト、テストの後ドキュメント）で委任する
3. 出力を収集して競合やブロッカーを特定する
4. 必要なフォローアップを含む統合サマリーを返す

ソースファイルを直接変更しない。すべてのファイル変更はスペシャリストに委任する。

toolsのAgent(code-reviewer, test-runner, doc-writer)構文は、このエージェントが生成できるサブエージェントタイプをアローリストで制限する。オーケストレーターがリスト外のタイプを生成しようとすると失敗し、リストに含まれるタイプのみが見える。これにより、オーケストレーターが定義されたスコープ外のアドホックエージェントを生成することを防ぐ。

パターン2：シーケンシャルパイプライン

タスクが定義された順序で流れ、各ステップが前のステップに依存する。レビュー→テスト→デプロイのパイプラインに一般的だ。

architect → implementer → reviewer → test-runner

各ステージの出力が次のステージの入力となる。サブエージェントはお互いを知る必要がない——ハンドオフはオーケストレーターが管理する。

---
name: pipeline-orchestrator
description: 完全な機能実装パイプラインを実行する：設計 → 実装 → レビュー → テスト
tools: Agent(architect, implementer, code-reviewer, test-runner), Read
model: opus
---

現在のステージがブロッキング問題を返した場合、次のステージに進まない。
各ステージの全出力を次のステージのコンテキストとして渡す。

シーケンシャルパイプラインでは、オーケストレーション層にmodel: opusを使うとよい——オーケストレーターがゲート判断を行い、誤った判断は連鎖的な問題を引き起こすからだ。

パターン3：並列ファンアウト

独立したタスクが同時実行され、結果がマージされる。解析タスクに有効（異なるモジュールのリント、複数言語のチェック、複数バリデーターの実行）。

---
name: multi-linter
description: TypeScript、CSS、SQLファイルにわたって並列リンティングを実行する
tools: Agent(ts-linter, css-linter, sql-linter), Read
model: haiku
---

3つのリンターすべてに同時ファンアウトする。出力を統合し、複数リンターで重複する問題を
排除した上で、重要度順にソートされた単一のレポートにマージする。

ファンアウトはClaude Codeの並列エージェント機能が真価を発揮する場面だ——複数のサブエージェントが同時実行され、独立した結果を返す。オーケストレーションコストは低く（Haikuで十分）、経過時間は個々の実行時間の合計ではなく最大値となる。

シーケンシャルとの設定の違い： ファンアウトのオーケストレーターにはmodel: haiku（マージ処理はシンプル）、より緩やかなツール制限（出力収集にAgent + Readのみ）、システムプロンプトに明示的なマージ指示が必要だ。

SaaSリポジトリのための3サブエージェント構成（実例）

最も有用な3つのスペシャリストを備えたTypeScript SaaSリポジトリの具体的な.claude/agents/設定を示す。

ファイル構造：

.claude/
└── agents/
    ├── architect.md
    ├── implementer.md
    └── reviewer.md

architect.md — システム設計と意思決定：

---
name: architect
description: システム設計の質問を分析し、トレードオフを評価して実装計画を策定する。新しいモジュール、API設計、データベーススキーマ変更を含むタスクに使用する。
tools: Read, Grep, Glob
model: opus
memory: project
effort: high
---

あなたはシステムアーキテクトだ。出力は常に構造化された実装計画とする：

## コンテキスト
変更内容とその必要性。

## 影響を受けるコンポーネント
影響するファイルとモジュール。

## 実装ステップ
実装者向けの番号付き、実行可能なステップ。

## トレードオフ
検討したが選ばなかった選択肢とその理由。

## リスク
発生しうる問題とその検出方法。

実装コードは書かない。計画のみを作成する。

implementer.md — アーキテクトの計画に基づいてコードを書く：

---
name: implementer
description: アーキテクチャ計画に従ってコード変更を実装する。アーキテクトが計画を作成した後に使用する。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
memory: local
---

あなたは実装者だ。アーキテクチャ計画を受け取ってそれを実行する。

コードを書く前に：
1. 既存のパターンを理解するために関連するソースファイルを読む
2. このコードベース固有の規約をメモリから確認する
3. 計画と既存コードの間の競合を特定する

既存のスタイルに合わせたコードを書く。新しい依存関係を導入する場合は
出力でその旨を明示的に記述する。

reviewer.md — 変更をレビューして問題を報告する：

---
name: reviewer
description: コード変更の正確性、セキュリティ脆弱性、プロジェクト規約への準拠をレビューする。実装完了後に使用する。
tools: Read, Grep, Glob
model: sonnet
memory: project
---

あなたはコードレビュアーだ。以下の優先順位でレビューする：
1. **正確性** — コードは計画通りに動作するか？
2. **セキュリティ** — SQLインジェクション、XSS、未検証の入力、シークレットの露出
3. **パフォーマンス** — N+1クエリ、上限のないループ、インデックス不足
4. **規約** — 既存のコードベースパターンに合致しているか？

出力フォーマット：
- BLOCKING 問題を先頭に（マージ前に必ず修正）
- WARNINGS を次に（修正すべき）
- SUGGESTIONS を最後に（任意の改善）

ブロッキング問題がない場合は先頭で明示的にそう述べる。

reviewerにはRead, Grep, Globのみ——BashなしのWrite/Editなし。コードを実行することも、ファイルを変更することもできない。これは意図的だ：スクリプトを実行できるレビュアーは発見した問題を「テスト」しようとするかもしれず、定義されたパイプライン外の副作用を生む。

スポーン権限のスコーピング

メインセッションエージェントとして実行中（claude --agent経由）の場合、オーケストレーターが生成を許可されているサブエージェントを制限できる：

tools: Agent(code-reviewer, test-runner, doc-writer), Read, Bash

これはアローリストだ——列挙した3タイプのみ生成可能。リスト外のタイプを生成しようとすると失敗し、オーケストレーターはリストされたタイプのみをツール説明で確認できる。

制限なしに任意のサブエージェントの生成を許可するには：

tools: Agent, Read, Bash

生成を完全に防ぐには、toolsからAgentを省略する。

重要： このアローリストはエージェントがメインセッション（claude --agent）として実行されている場合のみ適用される。サブエージェント定義内では、toolsにAgentを列挙するとネストされた生成が有効になるが、Agent(type1, type2)構文の制限は無視される。深くネストされた階層では、代わりにdisallowedToolsでスポーン権限を管理する必要がある。

よくある設定ミス

サブエージェントへの過剰な権限付与

最も一般的なミスだ。「念のため」全ツールを与えると、すべてのサブエージェントが汎用エージェントになり、専門化の目的が失われる。Writeアクセスを持つレビュアーはコードを書き直す。Editアクセスを持つtest-runnerはテストを通すためにテストファイルを変更する。ツールスコープは最小限に保つ。

コンテキストの相互汚染

サブエージェントは設計上、独立したコンテキストウィンドウを持つ。コンテキストをタスクディスクリプション（親が委任時に送る内容）で渡す場合、簡潔で構造化した形式にする。親会話の全履歴をタスクプロンプトに丸ごと渡すとサブエージェントのパフォーマンスが低下する——モデルが実際の作業ではなく無関係なコンテキストの解析にアテンションを使ってしまうからだ。

正しいアプローチ：オーケストレーターが各委任先に関連するコンテキストを合成する。全体をそのまま転送しない。

MEMORY.mdの肥大化

サブエージェントがキュレーションなしに学習を蓄積すると、200行 / 25KBの注入上限に達しやすい。上限に達したMEMORY.mdは最も古いエントリしか読まれなくなる——最近学んだ、しばしば最も関連性の高い情報がひそかに削除される。

サブエージェントのシステムプロンプトにキュレーションを組み込む：「MEMORY.mdに新しいエントリを書く前に、もはや関連性のないエントリを削除または統合する。ファイルを150行以内に保つ。」

LLM生成のサブエージェント設定

Claude Codeの/agentsコマンドで、必要なエージェントを説明するだけでサブエージェント定義を生成できる。生成されるフロントマターは機能するが汎用的だ——descriptionは通常大まかすぎ、toolsフィールドは必要以上のものを含みがちで、システムプロンプトは出力フォーマットの仕様ではなく能力の説明にデフォルトしてしまう。

実運用では、サブエージェント定義が実際の使われ方から乖離していくと、マルチエージェント構成の精度は目に見えて劣化する——いわゆるセマンティックドリフトと呼ばれるパターンだ。主要な要因の一つが不明確な初期設定で、descriptionがタスクタイプに正確にマッチしていないと、モデルの委任ルーティングが一貫性を失う。

AI生成の設定は出発点として扱い、完成品としては使わない。最も人間による精査が必要な3つのフィールド：

  • description: 正確なタスクマッチステートメントにする
  • tools: 必要最小限に削る
  • システムプロンプト: 「Xの専門家として振る舞う」ではなく、出力フォーマットを明示的に指定する

プロジェクトスコープとユーザースコープの混在

プロジェクトサブエージェント（.claude/agents/）はリポジトリ固有の役割のためのものだ。ユーザーサブエージェント（~/.claude/agents/）はプロジェクトをまたいで使う個人的なワークフローのためのものだ。よくあるミスは汎用エージェントをリポジトリの.claude/agents/に置いてコミットしてしまうことだ——他のコントリビューターは自分の個人ワークフロー向けにチューニングされたエージェントを受け取ることになる。個人エージェントは~/.claude/agents/に置くこと。

起動時に読み込まれる情報

よく誤解される点：サブエージェント起動時に実際にどのコンテキストが届くか。

  • カスタムサブエージェント: CLAUDE.mdファイルと親のgitステータスを読み込む（メイン会話と同様）
  • 組み込みのExploreとPlan: CLAUDE.mdとgitステータスを意図的にスキップする（速度の最適化）
  • サブエージェントのシステムプロンプト: Markdown本文のみ
  • メモリ: memoryが設定されている場合、MEMORY.mdの先頭200行 / 25KB
  • スキル: skillsフィールドにリストされたスキルの全内容

親会話の履歴、ツール結果、中間出力はサブエージェントには自動的に転送されない。親が委任タスクのディスクリプションで明示的にコンテキストを渡す必要がある。

この分離がサブエージェントを並列化して安全に使える理由だ——独立したコンテキストウィンドウ、共有状態なし、結果は構造化テキストとして返却される。

まとめ

.claude/agents/サブエージェント定義は、システムプロンプトとコードベースの間に設定レイヤーを提供する。マルチエージェント設定の主要な運用上の判断：

  1. ツールスコープを最初に決める: 各サブエージェントが何を「できない」かを定義してから、何が「できる」かを定義する
  2. タスクの複雑さにモデルを合わせる: 大量処理タスクにはHaiku、長期的な影響を持つ判断にはOpus
  3. メモリはエージェントごと、共有しない: オーケストレーターとサブエージェントは別々のMEMORY.mdを持つ。両方を意図的に設計する
  4. パターンを選ぶ: ほとんどのワークフローにはハブアンドスポーク、依存するステージにはシーケンシャルパイプライン、独立した解析には並列ファンアウト
  5. descriptionを委任トリガーとして書く: 能力の説明ではなく——モデルはこれをルーティングに使う

設定構文は十分に安定しており、バージョン管理してチームで共有できる。よく設定された.claude/agents/ディレクトリは積み上がっていく資産だ——各エージェントがドメイン知識を蓄積し、descriptionが洗練されるにつれてルーティングが改善し、新しいコードベースでのセットアップが毎回ゼロから始めるより速くなっていく。

FAQ

.claude/agents/ ディレクトリとは何ですか？

Claude Codeにおけるサブエージェント定義の設定レイヤーだ。このディレクトリに置いたMarkdownファイルがそれぞれ1つのサブエージェントを定義し、YAMLフロントマター（name、description、tools、model、memory）とMarkdown本文（サブエージェントのシステムプロンプト）から構成される。.claude/agents/に置いたファイルはプロジェクトスコープでバージョン管理にコミットでき、~/.claude/agents/に置いたファイルはユーザースコープで全プロジェクトから利用できる。

サブエージェントが使えるツールを制限するにはどうすればよいですか？

toolsフィールドでアローリスト（リストに含まれるツールのみ使用可能）を指定するか、disallowedToolsフィールドでデナイリスト（指定ツールのみ除外し残りは継承）を使う。両フィールドが同時に設定されている場合はdisallowedToolsが先に適用され、両方に含まれるツールは常に除外される。MCPサーバーについては、mcp__*で全MCPツールを除外でき、mcp__githubのように指定すれば特定サーバーのツールだけを除外できる。

サブエージェントにどのモデルを割り当てるべきですか？

modelフィールドにはエイリアス（sonnet、opus、haiku、fable）、フルモデルID、またはinheritを指定できる。ファイル検索やgrep等の大量処理タスクにはhaiku、コードレビューやドキュメント生成にはsonnet、誤りが長期的な悪影響を及ぼすアーキテクチャ判断にはopusを使う。フィールドを省略するとinheritがデフォルトとなり、メイン会話のモデルが使われる。

オーケストレーターとサブエージェントのメモリ分離はどのように機能しますか？

各サブエージェントは専用のメモリディレクトリを持ち、他のエージェントからは見えない。memoryフィールドは3つのスコープを受け付ける：user（~/.claude/agent-memory/<name>/）、project（.claude/agent-memory/<name>/）、local（.claude/agent-memory-local/<name>/）。起動時にMEMORY.mdの先頭200行または25KBのいずれか先に達した方がサブエージェントのシステムプロンプトに注入される。オーケストレーターと各サブエージェントのメモリストアは完全に独立している。

マルチエージェント構成の主なオーケストレーションパターンは何ですか？

主に3つのパターンがある。ハブアンドスポーク：1つのオーケストレーターがタスクを分解してスペシャリストサブエージェントに委任し、結果を集約して合成する。シーケンシャルパイプライン：各ステップが前のステップに依存する決まった順序でタスクが流れる方式で、設計→実装→レビュー→テストのワークフローに適している。並列ファンアウト：独立したタスクを複数のサブエージェントで同時実行して結果をマージする方式で、複数リンターの同時実行などに最適だ。

サブエージェントは親のCLAUDE.mdコンテキストを自動的に継承しますか？

しない。サブエージェントが受け取るのは自分自身のシステムプロンプト（定義ファイルのMarkdown本文）と作業ディレクトリ等の基本環境情報のみだ。親会話のCLAUDE.mdコンテキストは自動的には引き継がれない。プロジェクトの規約をサブエージェントに適用するには、サブエージェントのシステムプロンプトに直接記述するか、skillsフィールドで関連コンテンツを注入する。

関連記事

サブエージェントが触れるAPIキーをまとめて管理する

複数のサブエージェントが異なる外部サービスを呼び出す環境——セキュリティ監査エージェントが脆弱性スキャナーAPIにアクセスし、ドキュメント作成エージェントがナレッジベースを参照し、実装エージェントがCIにプッシュする——では、認証情報の管理が煩雑になりやすい。1Passwordはすべてのシークレットを1つのボールトに保管し、op runでランタイム時にのみ環境変数として注入する。.envファイルに平文で残らず、誤ってコミットされるリスクもない。.claude/agents/の構成が複雑になるほど、ツールのスコープ管理と同様に、認証情報のスコープ管理も重要になる。

Share on X

Related Articles

Claude サブエージェントと専用AGENTS.md：役割ごとの指示設計で重複を排除する

Claude Code がサブエージェントを生成すると、全員が同じ AGENTS.md を読む。でも専門特化したエージェントには、その役割に必要なコンテキストだけを渡すべきだ。エージェントごとの AGENTS.md 設計パターンを解説する。

Gemini CLI でのAGENTS.md：Google製エージェントの読み方とClaude Codeとの違いを徹底比較

Gemini CLIがAGENTS.mdをサポートした。でも「互換性あり」は表面的な話。Claude Codeとどう解釈が違うのか、2ツール対応の書き方はどうすべきかを具体的に解説する。

モノレポでのAGENTS.md活用：パッケージごとのAI指示を管理する実践パターン

モノレポ環境では単一のAGENTS.mdでは対応しきれない。Nx・Turborepo・pnpmワークスペースを使った階層的AGENTS.md運用と、重複管理のコストを下げる実践パターンを解説。

AGENTS.md Team Standards: Templates for Engineering Teams of Every Size (2026)

Three battle-tested AGENTS.md templates for startup, growth-stage, and enterprise teams — plus a required/recommended/optional tier system, change management workflow, and rollout playbook. Built from reviewing 200+ real repos across team sizes.

Explore the collection

Browse all AI coding rules — CLAUDE.md, .cursorrules, AGENTS.md, and more.

Browse Rules