この記事は、Claude Code および Agent Teams を実務で使い込んだ経験をもとに書いた考察です。どう使うか・何に使えるかに焦点を当てています。
実際の体験談をもとにClaudeと共同で執筆しました。
1. 「コーディングツール」という誤解
「Claude Code？ああ、AIがコードを書いてくれるやつでしょ」
この認識は、半分正解で半分間違いだ。
確かにClaude Codeはコードを書く。ファイルを読み、テストを実行し、バグを修正する。でもそれは表面的な機能の話であって、本質ではない。
使い込んでいくうちに気づいた。Claude Codeの本質は自律的に知的作業を遂行できるエージェントであり、Agent Teamsを使えばそれが組織として機能するということだ。
コーディング以外の知的作業 — 調査、設計、議論、文書作成、意思決定支援 — これらすべてがClaude Codeの射程に入る。名前に惑わされてはいけない。
2. AIの進化レベルで理解する
AIがどう進化してきたかを、「どこまで自動か」という軸で3段階に整理する。
Level 1：汎用LLM
ChatGPTやClaudeに質問する使い方。人間がすべてを判断し、AIは「聞かれたら答える」だけ。実行するのは常に人間だ。
Level 2：Copilot / RAG
GitHub CopilotやRAG構成のBot。AIが文脈を読んで提案するが、承認・実行するのは人間。AIが「ここはこう書くといい」と示し、人間がそれを受け入れるかどうか判断する。
Level 3：AI Agent
明確な仕様とテストがあれば、AIが自律的にタスクを完遂する。Claude Codeはここに位置する。ファイルを読み、コードを書き、テストを実行し、修正までやる。人間は結果をレビューする立場になる。
そしてAgent Teamsは、この自律Agentを複数、連携させる仕組みだ。
3. Level 3だけでは足りない — シングルAgentの限界
Claude Code単体（シングルAgent）でも強力だが、複雑なタスクになると限界が見えてくる。
コンテキスト汚染（Context Rot）
会話が長くなるほど、モデルの集中力は落ちる。調査ログ、試行錯誤の履歴、途中の仮説 — これらが積み重なってコンテキストウィンドウを汚染していく。バックエンドの設計を議論していたはずが、気づけばフロントエンドの細部に引きずられる。
アンカリングバイアス
最初に立てた仮説に引っ張られる。シングルAgentが「このバグはAが原因だ」と判断したら、その後の調査はAの証拠を探す方向に偏りがちになる。
タスク切り替えコスト
フロントエンド、バックエンド、テストを一つのAgentが順番にこなすと、コンテキストスイッチのたびに精度が落ちる。人間でいえば、同じ人間が一日中マルチタスクし続けるようなものだ。
4. Claude Codeとは
他のAIコーディングツールとの違い
Claude CodeはAnthropicが開発したターミナルベースのエージェント型コーディングツールだ。Copilotとの違いを一言で言えば、「提案する」のではなく「実行する」。
Claude Codeはリポジトリの鍵を渡した開発者に近い。チケットを渡せば、ファイルを読み、コードを書き、テストを実行し、コミットまでやる（必要に応じて確認を求めることもある）。
基本的な操作感
ターミナルで claude を起動し、自然言語で指示するだけ。特別な構文はいらない。
claude
この認証モジュールにJWT対応を追加して。既存のテストが全部通ることを確認してから実装して。
これだけでClaude Codeは動き始める。コードを読み、実装方針を立て、変更し、テストを回し、結果を報告する。
できること
できること
- ファイルの読み書き・編集
- コマンド実行（テスト、ビルド、lintなど）
- 複数ファイルにまたがる変更
- MCPサーバ経由での外部ツール連携
- Agent Teamsによる並列・協調作業
注意が必要なこと
- 曖昧な指示では品質が下がる
- 大規模変更はコンテキスト管理が重要
- Agent Teamsはトークンコストが高い（後述）
5. Agent Teamという組織設計
SubAgentとの根本的な違い
Claude CodeにはもともとSubAgentという仕組みがある。親Agentが子Agentにタスクを委譲し、結果を受け取る。シンプルな委譲構造だ。
Agent Teamsはこれとは根本的に異なる。
SubAgentはfunction call。Agent Teamsはorganization。
SubAgentは親にしか報告できないが、Agent Teamsではテイメイト同士が直接メッセージを送り合える。フロントエンドAgentがAPIの仕様変更をバックエンドAgentに直接通知できる。コードが固まる前にインターフェースを交渉できる。これが決定的な差だ。
アーキテクチャ
┌─────────────┐
│ Team Lead │
│ タスク割当 │
│ 統合・品質 │
└──┬───┬───┬──┘
│ │ │
┌────────┘ │ └────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Backend │ │ Frontend │ │ Test │
│ Agent │ │ Agent │ │ Agent │
└──────────┘ └──────────┘ └──────────┘
↕ ↕ ↕
Agent同士が直接メッセージで連携
Team Leadがタスクを分割・割り当て、各テイメイトは独立したコンテキストウィンドウで作業する。そして必要に応じて横の連携を取る。
なぜ精度が上がるのか — 研究が示すもの
「一人の天才より、専門家チームのほうが精度が高い」というのは感覚論ではない。
ある研究では、マルチエージェントの相互検証アプローチがシングルエージェント比でコード精度を67%向上させ、複雑なタスクの成功率が95%に達したという報告がある。また複雑なタスク全般においても、相互検証によって精度が最大40%改善するという研究結果も出ている。
なぜか。理由は三つある。
専門特化による集中：各Agentが独立したコンテキストウィンドウを持つ。バックエンドAgentの頭の中にはAPIロジックだけが入っている。余計な情報がない分、一つの領域を深く正確に処理できる。
相互検証：複数のAgentが互いの成果物を批判的に検証し合う。シングルAgentでは最初の仮説にアンカリングされやすいが、独立した複数の調査者が動けば、最も堅牢な仮説だけが生き残る。エージェント間のディベートは推論・適応性・事実精度を向上させる有効な手法であることが研究で示されている。
並列実行：フロントエンド・バックエンド・テストを同時に進められる。これは副次的な効果だが、スループットが単純に上がる。
有効なユースケース
公式ドキュメントが示すAgent Teamsの強みが発揮される場面：
- 調査・レビュー：複数Agentが異なる観点（セキュリティ・パフォーマンス・テストカバレッジ）を同時に調査
- 新機能・新モジュール開発：Frontend / Backend / Testを各Agentが並列で担当
- 競合仮説によるデバッグ：複数Agentに異なる仮説を検証させ、互いに反証させる
- クロスレイヤー変更：API・UI・テストにまたがる変更を各Agentが同時進行
逆に、逐次的なタスク・同一ファイルへの編集・依存関係が多い作業にはシングルセッションのほうが効率的だ。
6. AIへの指示はどう進化したか — プロンプト→コンテキスト→ハーネス
AIとの関わり方は、この数年で大きく変わってきた。
プロンプトエンジニアリング（〜2023年頃）
「どう聞くか」を磨く技術。単発の指示をうまく書けば、より良い回答が得られる。ゼロショット、フューショット、Chain-of-Thoughtなど、指示の書き方が研究された時代。
コンテキストエンジニアリング（2024〜2025年頃）
「何を渡すか」を設計する技術。RAG、メモリ管理、ツール結果の整理など、コンテキストウィンドウに何を入れるかがパフォーマンスを左右するという認識が広まった。Andrej Karpathyが提唱して注目された概念だ。
ハーネスエンジニアリング（2025年〜）
AIエージェントを信頼性高く動かすための制約・環境・フィードバックループ・ドキュメントを設計する技術。人間が意図と境界を定め、Agentはその中で実行する。フォルダ構成、ファイル規約、ワークフロー、エージェント間通信、人間介入ゲートなど、AIが動く環境・構造そのものが対象だ。
馬具の比喩がわかりやすい。モデルは馬（速くて強力だが方向を知らない）、ハーネスはそれを正しい方向に導く装備一式、エンジニアは騎手。ハーネスなしのAgentはデモでは動くが、本番では予測不能に失敗する。
Agentが自律的に動くようになると、一回の指示の質よりAgentが動く舞台の設計が品質を決める。プロンプトを磨くより、ハーネスを整えるほうが効果的だ。具体的には、フォルダ構成はAgentの認知負荷を下げる環境設計、工程の分離はAgentが迷わないレール、チーム構成はコンテキストの分離設計にあたる。
7. 実践編 — タスク指示とチーム設計
ここからは自分の実体験をもとに、Claude Code（特にAgent Teams）を使いこなすための原則を共有する。
自分がやっていることを一言で言えばハーネスエンジニアリングだ。フォルダ構成の標準化はAgentの認知負荷を下げる環境設計、工程の分離はAgentが迷わないレールの敷設、人間介入のチェックポイントは承認ゲートの設計、チーム構成はコンテキスト分離の設計 — これらはすべてハーネスの構成要素にあたる。プロンプトをうまく書こうとするのではなく、Agentが最高のパフォーマンスを出せる「環境と構造」を人間が設計する。
この章ではタスク指示の原則・チーム構成の設計・実際の事例の3つを順に説明する。
タスク指示の原則
原則1：何を作るかではなく、なんのために作るかを伝える
「〇〇を実装して」ではなく、「〇〇という課題を解決するために、△△というアウトプットが必要だ」と伝える。
目的を理解したAgentは、手段の選択・構成・粒度を自律的に最適化する。逆に目的を隠して「これを作れ」と指示すると、仕様通りだが的外れなものが出てくることがある。
原則2：インプット資料を明示的に渡す
Agentは渡されたものしか知らない。関連ドキュメント、既存コード、参考資料、制約条件 — これらをあらかじめ明示的に渡す。「空気を読む」は期待しない。
原則3：フォルダ構成を標準化する
プロジェクト配下に以下のフォルダを用意する：
project/
├── input/ # インプット資料
├── prompt/ # タスク指示ファイル
├── plan/ # 計画・設計
├── intermediate/ # 調査結果・中間成果物
├── output/ # 最終アウトプット
└── review/ # レビュー記録
これはあくまで構造の例で、コード開発や、目的応じて構造を変化させる必要がある
Agentにとって「どこに何があるか」が明確になり、指示の解釈ブレが減る。チームで使う場合も再現性が上がる。
原則4：工程を分離し、段階的に指示する
一気に「全部やって」ではなく、工程を分けて指示する。
フェーズ1：プロンプト指示
prompt/task.md にタスクをまとめる。voiceモードで話しながら書いてもいいし、箇条書きを雑に放り込んでもいい。このファイルがAgentへの指示書になる。
どういった観点で調査をするか、どういうステップを踏むのかなど部下や取引先に依頼をするイメージで指示をする
フェーズ2：プランを作る
まずAgentに計画を立てさせ、plan/ に出力させる。いきなり実行させない。人間がプランを確認してGOを出してから次フェーズに進む。ここが最初の承認ゲートだ。認識のズレを一番安いタイミングで潰せる。
フェーズ3：調査フェーズ
intermediate/ に調査結果を出力させる。複数Agentで異なる仮説を並列調査させることもある。必要に応じてAgentどうしに議論させてレビューする。
フェーズ4：アウトプット生成
調査と計画が固まってから、初めてアウトプットを生成させる。
フェーズ5：レビュー
人間がレビューする。Agentにレビューさせることもある（視点を変えたAgentを投入する）。
フェーズ6：改訂
レビュー結果をもとに改訂。ここも自動化できる部分は自動化する。
共通原則：必要に応じて人間が介入する
フェーズとフェーズの間に人間のチェックポイントを設ける。全自動にこだわらない。重要な判断は人間がする。AIはその判断材料を揃える役割に徹させることもある。
チーム構成の設計
誰を入れるかが品質の肝
Agent Teamsを使うとき、最も重要な設計判断は「誰を入れるか」だ。
典型的なチーム構成の例：
| 役割 | 担当 |
|---|---|
| Team Lead | タスク分解・統合・品質管理 |
| 執筆者 | アウトプット生成 |
| 調査者 | 情報収集・事実確認 |
| 専門家A | 特定ドメインの深掘り |
| 専門家B | 別観点からの検証 |
| 体裁チェック | フォーマット・一貫性確認 |
役割が明確なほど、各Agentの集中度と出力品質が上がる。
動的なチーム拡張
チームは固定ではない。イテレーションに応じて役割を追加する。タスク特性が変わったら専門家を差し替える。議論の中で「この視点が足りない」と気づいたら、その場で新しいAgentを追加する。
これは実際の組織運営と同じ感覚だ。プロジェクトが進むにつれてチームの構成が変わる。
レビュー改訂のサイクル
品質を上げるのは、一回の生成ではなくサイクルの回転数だ。
生成 → レビュー（Agent or 人間）→ 改訂 → レビュー → ...
このサイクルをAgent Teamsで高速に回せることが、最大の価値だと思っている。
事例：ディスカッションペーパー作成
これらの原則がどう機能するか、実際の事例で見てほしい。
チーム構成
| 役割 | 人数 | 担当 |
|---|---|---|
| Team Lead | 1 | タスク分解・統合・品質管理 |
| リサーチャー | 1 | 業界動向・市場調査 |
| ドメイン専門家 | 約10 | 各技術・業界領域の深掘り・議論 |
| 執筆者 | 1 | アウトプット生成 |
専門家はAWS、Kubernetes、セキュリティ、財務など、ペーパーのテーマに関係するドメインごとに役割を立てた。
指示プロンプトの構造
# タスク概要
[ペーパーの目的・読者・期待するアウトプット]
# インプット資料
- input/direction.md # 自分の考える方向性
- input/internal_docs/ # 内部関連資料
# チーム構成
- Team Lead：全体統括・品質管理
- リサーチャー：市場調査・業界動向収集
- 専門家[ドメインA]：[役割の説明]
- 専門家[ドメインB]：[役割の説明]
- ...（必要なだけ）
- 執筆者：最終ドキュメント生成
# 進め方
1. まず実行計画を plan/plan.md に作成してください
2. 承認後に調査フェーズを開始
3. 調査結果は intermediate/ に出力
4. 専門家チームで議論・レビュー後、執筆
5. 完成稿は output/ に出力
これはあくまで構造の例。実際にはレポートの構成案、調査してほしい要素、論点の方向性など、もう少し細かく指示している。プロンプトの詳細度がそのままアウトプットの質に直結する。
このプロンプトをAgentに渡し、まずプランを作らせる。プランを人間が確認してGOを出してから実行フェーズに入る。
実際の流れ
- 自分の方向性と内部資料をインプットとして渡す
- リサーチャーが業界動向・市場調査を実施
- 構成と要素を抽出
- 専門家集団で議論・レビュー、修正
- 執筆方針をまとめる
- 人間承認：方向性・執筆方針を確認してGO
- 執筆
- 専門家集団で再レビュー
- 人間承認：内容を確認してGO
- 人間介入：追加調査・議論を指示し、必要なら3〜9を繰り返す
- 完成 → 必要に応じてスライド化
- 上司とやりとり → 追加修正ターン
- このサイクルを繰り返す
ポイント
全自動で終わらせようとしない。フェーズとフェーズの間に人間のチェックポイントを設け、方向性のズレを早めに修正する。サイクルを回すのは非効率に見えるが、一回のサイクルが高速なので、むしろ短期間で質の高いものができあがる。
その他の利用例
- MCPサーバ開発：調査・実装・テストAgentを並列で走らせ、仕様のすり合わせをメッセージングで実施
- 設計書レビュー：セキュリティ・パフォーマンス・保守性を別Agentに割り当て、独立レビューを実施
- 提案書作成：顧客課題の整理から提案構成、文章生成まで段階的にAgentを投入
- 技術的判断の比較資料生成：選択肢ごとにAgentを担当させ、推進派・懐疑派に分かれて議論させた
8. AI駆動の組織のあり方
ここからは少し視野を広げて、Agent Teamsが組織そのものをどう変えるかを考えてみたい。
大規模組織の構造的な問題
従来、大きな仕事には大きなチームが必要だった。人が増えるほど処理能力は上がる。しかし同時に、承認フローとコミュニケーションコストも爆発的に増える。
【従来の1プロジェクトチーム】
┌─────────┐
│ PM │ ← 最終承認
└────┬────┘
│ 承認・差し戻し
┌────┴────┐
│ PL │ ← 承認・調整
└────┬────┘
│ 承認
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│ TL-A │ ←→ │ TL-B │ ←→ │ TL-C │
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
人 人 人 人 人 人 人 人 人
↕ TL間調整・PL確認が随所で発生
AIが速くアウトプットを出しても
承認フローがボトルネックになる
AIが瞬時に成果物を作っても、TL確認 → PL承認 → PM承認という縦のフローと、TL間の横調整が重なると、スピードが出ない。組織の構造が変わらない限り、AIの恩恵は半減する。
Agent Teamsが変えること
【AI駆動の1プロジェクトチーム】
┌──────────────────────────────────┐
│ ハイレベル設計チーム（少数精鋭） │
│ 全体分解・制約定義・ガードレール設計 │
└────────┬──────────┬──────────┬───┘
│ │ │
┌────────▼──┐ ┌─────▼─────┐ ┌──▼────────┐
│マイクロチームA│ │マイクロチームB│ │マイクロチームC│
│ 人間 1〜3名 │ │ 人間 1〜3名 │ │ 人間 1〜3名 │
│ + Agent群 │ │ + Agent群 │ │ + Agent群 │
└───────────┘ └───────────┘ └───────────┘
↓ ↓ ↓
制約の中で 制約の中で 制約の中で
自律的に判断・実行 自律的に判断・実行 自律的に判断・実行
少数の人間がAgentを率いるマイクロチームに分解する。チームが小さいから、人間同士のコミュニケーションは迅速だ。Agentが調査・実行・検証を担うから、人間は判断と承認に集中できる。
思想の核心
ハイレベル設計チームの役割は、大きな仕事を分解し、制約とガードレールを定義することだ。アーキテクチャの方針、品質基準、セキュリティルール — これらを決めたら、あとはマイクロチームに権限を委任する。
マイクロチームは制約の中であれば、自律的に判断・実行していい。いちいち上位に確認しない。それができるのは、制約が明確だからだ。
これはソフトウェアのマイクロサービスアーキテクチャと同じ思想だ。モノリシックな大組織を、疎結合な小チームに分解する。各チームは独立して動き、インターフェース（制約）だけを守る。
10人が100人分の仕事をする
少数精鋭の人間チームに、専門スキルを持ったAgentが何人でも加わる。調査が必要なら調査Agentを立てる。レビューが必要なら複数のレビューAgentを並列で走らせる。執筆、検証、体裁チェック — 必要な役割を必要なだけ瞬時に用意できる。
10人のチームが、Agent Teamsを使いこなせば実質100人規模の処理能力を持つ。しかも人間の数が少ないから、意思決定は速い。
採用よりも先に、チームの分解設計とAgent Teamsの編成を考える。そんな時代が、もうすぐそこまで来ている気がしている。
9. さいごに
コーディングエージェントではない
冒頭に戻る。Claude Codeはコーディングエージェントと呼ばれているが、私の使い方を見てほしい。コードを一行も書かないタスクでも普通に使っている。
本質的な価値はどこにあるか。それは思考のサイクルが加速することだと思っている。単なる効率化ではない。
調査して、仮説を立てて、検証して、議論して、まとめる — この思考のプロセスが、AIの速度で回せる。アイデアが頭の中にある間に形になる。「もう少し練ってから」と寝かせていたものが、その日のうちに素案になる。
誰でも使いこなせるわけではない
ただし正直に言う。Agent Teamsは誰でもすぐ使いこなせるツールではない。
求められるスキルがある。
タスク分解と指示設計：これはPMの仕事と本質的に同じだ。何をゴールにするか、工程をどう切るか、誰に何を任せるか。この設計が甘いと、Agentは精度高く「的外れなもの」を作る。
成果物の品質判断：Agentのアウトプットを評価できる専門性が必要だ。間違っていても自信満々に出してくる。それを見抜けるのは、その領域の知見を持った人間だけだ。
自分の知見との組み合わせ：Agentが出したものをそのまま使うのではなく、自分のアイデアや経験と組み合わせて初めて価値が出る。AIは素材を出す。料理するのは人間だ。
コストについて
Agent Teamsはトークンコストが高い。特にAPI経由で使う場合、複数Agentが同時に動くためコストはAgent数に比例してスケールする。
ただし、ROIは成立すると思っている。数時間かかっていた調査・設計・文書作成が、数十分で回せる。エンジニアの時間コストと比較すれば、多くのケースで十分に元が取れる。
利用プランについては、MaxプランやAPI従量課金など自分の用途に合った選択を。
まず始めてみよう
最初は「コーディングツール」として触ってみるだけでもいい。徐々に使い方が広がる。
- コードを書かせる
- ドキュメントを書かせる
- 調査させる
- チームで動かす
この順番で自然に射程が広がっていった。
Claude Codeは今も進化している。Agent Teamsはまだexperimentalフラグが必要な機能だが、方向性は明確だ。AIを「使う」から「編成する」へ。この変化に早く慣れた人が、次の数年で大きなアドバンテージを持つと思っている。思考の速度でアウトプットが作れる時代が、もう来ている。