はじめに
この連載では、AIエージェントを支える考え方として、Harness、Loop Engineering、Tool Engineering、Memoryといった要素を扱ってきました。以前の記事では、Claude Codeの自動モードを取り上げ、Human-in-the-loopの実装例として紹介しました。
今回は少し視点を広げて、Claude Codeを使ったAI駆動開発そのものについて、公式ドキュメントをもとに現状を整理してみます。サブエージェントによる分業、複数タスクの並列実行、プロジェクト固有の知識をどう持たせるか。これらは、この連載で扱ってきた抽象的な概念が、実際の開発ツールの中でどう形になっているかを確認する、ちょうど良い題材だと感じています。
1. サブエージェントという考え方
Claude Codeには、サブエージェントという仕組みがあります。特定の種類のタスクを専門に処理する、独立したAIアシスタントのことです。
通常のClaude Codeは汎用的に動きます。コードを書き、テストを走らせ、ドキュメントも書く。柔軟ではありますが、公式ドキュメントでは、検索結果やログ、参照しないファイルの中身でメインの会話が埋まってしまう場面で、サブエージェントの活用が勧められています。サブエージェントはその作業を自分専用のコンテキストで行い、要点だけをメインの会話に返します。
これは以前の記事で扱ったMemoryとContext Engineeringの実践例そのものです。すべての情報をメインの文脈に溜め込むのではなく、必要な範囲だけを切り出して処理し、結果だけを持ち帰る。長時間の複雑な作業でも見通しを保つための、具体的な工夫だと言えます。
2. サブエージェントはどう定義するのか
サブエージェントは、YAMLのフロントマターを持つMarkdownファイルとして定義します。名前、説明文、使えるツールの範囲、そしてそのサブエージェント専用のシステムプロンプトを記述します。
保存場所は2種類あります。プロジェクトの.claude/agents/に置けば、そのリポジトリ内だけで使えるサブエージェントになります。~/.claude/agents/に置けば、すべてのプロジェクトで使える個人用のサブエージェントになります。公式ドキュメントでは、同じ種類の作業を何度も同じ指示で頼んでいると気づいたときが、専用のサブエージェントを作るタイミングだと説明されています。
具体的には、次のようなYAMLフロントマターを持つMarkdownファイルとして書きます。
---
name: code-reviewer
description: コードの品質・セキュリティ・保守性をレビューする専門エージェント。プルリクエストのレビュー時に使用する。
tools: Read, Grep, Glob, Bash
---
あなたはコードレビューの専門家です。セキュリティ、パフォーマンス、
ベストプラクティスの観点から、渡されたコードを精査してください。
それぞれのフィールドには役割があります。nameは、そのサブエージェントを呼び出すときの識別子です。descriptionは、Claude Codeがどんな場面でこのサブエージェントに委任すべきかを判断するための説明文で、ここが曖昧だと、意図しないタイミングで呼ばれたり、逆に呼ばれるべき場面で呼ばれなかったりします。toolsは、そのサブエージェントが使えるツールの範囲を制限するフィールドで、例えば読み取り専用のレビュー担当ならReadやGrepだけを与え、WriteやBashのような書き換え系のツールは含めない、という設計ができます。フロントマター以降の本文が、そのサブエージェント専用のシステムプロンプトになります。
ここで重要なのは、ツールの範囲を制限できるという点です。例えばドキュメントレビュー専用のサブエージェントに、読み取りと検索のツールしか与えなければ、誤ってファイルを書き換えてしまう心配がありません。これは以前の記事で扱ったTool Engineeringと権限設計の考え方が、そのままサブエージェントの設計にも当てはまることを示しています。
3. 並列実行という強み
複数のサブエージェントは、同時に動かすことができます。公式ドキュメントの例では、コードレビューの際に、スタイルチェック、セキュリティスキャン、テストカバレッジの確認を、順番にではなく同時に走らせることができるとされています。独立したサブタスクであれば、全体の処理時間は、一番遅いサブタスクの時間で済むことになります。
これは以前の記事で扱ったAgentic Workflowの設計パターンのうち、Parallel Agentという考え方の具体的な実装です。互いに依存しないタスクを並行して処理することで、全体のスループットを上げる。この発想が、実際の開発ツールの機能として使えるようになっています。
4. プロジェクトの知識をどう持たせるか
Claude Codeには、CLAUDE.mdというファイルがあります。プロジェクトのルートに置いておくと、Claude Codeがセッションの開始時に自動的に読み込みます。プロジェクト固有の規約や設計方針をここに書いておくことで、以後のやり取りは、その内容を踏まえた形で進みます。
これは以前の記事で扱ったContext Engineeringの、もっとも基本的な実践例です。すべてのセッションで同じ説明を繰り返す必要がなくなり、プロジェクトの前提知識を、ファイルという形で永続化できます。
5. スキルという拡張の仕組み
Claude Codeには、スキルという拡張の仕組みもあります。特定の作業手順やベストプラクティスをまとめたSKILL.mdファイルを用意しておくことで、Claude Codeがその手順に沿って作業を進められるようになります。
公式ドキュメントによると、スキルは基本的にプロンプトベースで、詳細な指示を与え、Claudeがそれをもとにツールを使って作業を進める仕組みです。以前の記事で扱ったLoop EngineeringとEvaluationの発想を、特定のタスク向けに事前に整理しておく、というイメージに近いと思います。実際、スキルにはテストケースを用意して評価する仕組みも用意されており、期待した挙動になっているかを確認しながら育てていくことができます。
6. クラウド上での並列タスク実行
比較的新しい機能として、Claude Codeをブラウザから使う仕組みも用意されています。これを使うと、Anthropicが管理するクラウド環境上でタスクを実行させることができ、ブラウザを閉じてもセッションは継続します。
公式ドキュメントの例では、複数のタスクをそれぞれ別々のクラウドセッションとして同時に開始し、並行して進行させることができるとされています。ローカルのターミナルを一つのタスクで専有する必要がなく、修正、ドキュメント更新、リファクタリングといった複数の作業を同時に走らせておける、という運用です。
これは以前の記事で扱ったHarnessという考え方の延長線上にあります。実行環境そのものがローカルマシンの制約から解放されることで、並行して回せるループの数が増える、という変化です。
7. AI駆動開発における役割分担の設計
ここまで見てきた機能を組み合わせると、Claude Codeを使ったAI駆動開発は、単に一つのAIにすべてを任せるという単純な話ではなく、役割分担をどう設計するかという問題に近づいていきます。
メインのエージェントが全体の方針を決め、専門化されたサブエージェントが個別のタスクを担当し、必要に応じてクラウド上で複数のタスクを並行して走らせる。これは、以前の記事で扱ったPlanner、Executor、Evaluatorという役割分担の考え方が、実際の開発ツールの中でどう具体化されているかを示す、良い実例だと感じています。
8. 実践するうえで意識したいこと
ここまでの内容を踏まえて、実際にAI駆動開発を進めるうえで意識したいポイントをいくつか挙げます。
まず、すべてを一つの汎用エージェントに任せようとしないことです。ここで言う「容量」は、パソコン自体のディスク容量というより、Claude Codeが一度に把握できる情報量、コンテキストウィンドウのことだと捉えると分かりやすいと思います。この容量には上限があり、会話が長くなるほど、あるいは扱うファイルやログが大きくなるほど、この上限を圧迫していきます。
具体的な場面で考えてみます。一つの汎用エージェントに「大きめのプルリクエストをレビューして、ドキュメントも更新して、関連するテストも書いて」とまとめて依頼したとします。すると、そのエージェントはまずコードの差分を読み込み、関連するファイルを検索し、既存のテストの内容を確認し、といった作業を、すべて同じコンテキストウィンドウの中で行うことになります。差分やログ、検索結果がどんどん積み上がっていくと、序盤に与えた細かい指示や、初期の設計方針といった情報が、ウィンドウの外に押し出されて忘れられてしまうことがあります。以前の記事で扱ったMemoryの回で触れた、何を保存し、いつ忘れるかという問題が、まさにここで起きています。
サブエージェントを使うと、この問題を構造的に避けやすくなります。コードレビュー担当、ドキュメント担当、テスト担当をそれぞれ別のサブエージェントに分けておけば、各エージェントは自分の役割に必要な情報だけを自分専用のウィンドウで扱い、メインの会話には結果の要約だけが返ってきます。メインのやり取りが、個々の作業の細かいログで埋まることがありません。実際に複数のサブエージェントを使ったパイプラインでは、単一の汎用エージェントに全部任せた場合と比べて、体感的な作業速度が数倍向上したという報告も見かけます。これは公式のベンチマークというより利用者の実感値ですが、コンテキストを分割することの効果を示す傍証として参考になると思います。
繰り返し発生する種類のタスクは、早めに専用のサブエージェントとして切り出しておく方が、長期的には見通しが良くなります。
次に、プロジェクトの前提知識は、口頭での指示ではなくファイルとして残すことです。CLAUDE.mdやサブエージェントの定義ファイルは、リポジトリに含めてバージョン管理できるため、チームで同じ前提を共有する土台にもなります。
そして、権限とツールの範囲は、タスクの性質に応じて絞り込むことです。読み取り専用で十分な作業に、書き込み権限まで与える必要はありません。これは以前の記事で扱ったRecovery EngineeringやHuman-in-the-loopの設計とも重なる部分です。
9. まとめ
Claude Codeを使ったAI駆動開発は、単に自動化の度合いを上げるという話にとどまりません。サブエージェントによる分業、並列実行による効率化、CLAUDE.mdやスキルによる知識の永続化。これらはすべて、この連載で扱ってきたHarness、Loop Engineering、Context Engineering、Tool Engineeringといった考え方が、具体的な機能として実装されたものだと感じています。
一つの万能なエージェントに全部を任せるのではなく、役割を分け、並行して動かし、知識を積み重ねていく。この設計思想は、これからのAI駆動開発において、ますます重要になっていくはずです。
関連記事
- AIエージェントのTool Engineering入門
- AIエージェントにおけるMemory設計
- Agentic Workflowの設計パターン
- 自己改善型コーディングエージェントとは何か？Claude Codeの「自動モード」から考える
- Agent2Agent Protocol（A2A）とは何か？AIエージェント同士がつながる標準規格