[AI書房] 第24章 サブエージェント: 仕事を分ける技術
Claude Code完全攻略
第7部
第24章 サブエージェント: 仕事を分ける技術
金京鎮
メインセッションとサブエージェントの関係
ターミナルウィンドウに Claude Code を起動しました。Carousel Skill を呼び出すと、画面の片隅に小さなエージェントの表示が現れます。「Carousel スライドの計画を行います。エージェントを使用します。」メインセッションが直接スライドを構成するのではなく、別のサブエージェントに作業を委譲したのです。
サブエージェントが熱心にスライドの構造を構築している間、メインセッションは他の作業を続けることができます。
この場面は、サブエージェントの本質を凝縮して示しています。
Claude Code で新しいセッションを開くと、私たちが対話する相手はメインセッションです。メインセッションは一度に読み込む範囲を持ち、会話履歴を蓄積しながら、プロジェクト全体を管理します。しかし、このメインセッションがすべての作業を直接行わなければならないとしたらどうなるでしょうか。
コードレビュー、リサーチ、検証の作成、デバッグ、ドキュメント化までをすべて一つのコンテキスト内で行うと、ウィンドウはすぐに飽和状態に陥ります。コンテキストの腐敗（Context Rot）が始まり、先ほどお話しした会話の文脈が曖昧になります。
サブエージェントは、この問題を解決するための構造です。メインセッションがプロジェクトリーダーだとすれば、サブエージェントは専門家チームのメンバーです。プロジェクトリーダーは全体像を統括し、具体的な作業は専門家に委譲します。
[図 24-1] メインセッションとサブエージェントの関係図：メインセッション（プロジェクトリーダー）が、コードレビュアー、ビルダー、デバッガー、検証ランナー、アーキテクト、リサーチャーという 6 つのサブエージェントに作業を割り当てる構造です。
サブエージェントの動作方式を、もう少し具体的にみていきましょう。
サブエージェントは眠った状態から目覚めます。普段は存在しないに等しいものです。メインセッションが「起きて、この作業をやって」と呼び出す瞬間、サブエージェントは全く新しいコンテキストとともに目覚めます。独自のモデルを使用でき、独自のツールセットを備え、独自の目的に集中します。
重要な点は、独立したコンテキストを持つことです。メインセッションの会話履歴を共有せず、メインセッションから渡されたプロンプトのみを入力として受け取り、独立して作業を実行した後に結果だけを返します。
他のモデルを使用できる点も重要です。メインセッションがオパス(Opus)を使用している場合でも、サブエージェントはハイキュー(Haiku)やソネット(Sonnet)で作業を行うことができます。これにより、コストと速度を細かく調整できる道が開かれます。
さらに、並列実行も可能です。あるデモでは、「中小企業向けと大企業向けのAI活用に関するリサーチを同時に実施してほしい」という依頼に対し、メインセッションは2つのリサーチ用サブエージェントを同時に派遣しました。各エージェントが独立して調査を完了し、結果をメインセッションへ報告しました。中小企業向けAI活用ブリーフ、大企業向けAI活用ブリーフ、そして両者の共通部分まで整理された形で戻ってきました。
この構造を組織に例えると、メインセッションは計画立案、業務の配分、結果の集約に集中する役割を担います。専門的な作業の実行自体はサブエージェントの担当です。これにより、メインセッションのコンテキストは常にクリーンに保たれます。
カスタムベーカリーの比喩
パーティーの準備を想像してみてください。本当に美味しいカップケーキが必要です。
二つの選択肢があります。一つは大型スーパーに行って大量生産されたカップケーキを買ってくる方法です。これは速く、安く、便利です。しかし味は平凡です。もう一つは地元の専門ベーカリーを訪れて注文する方法です。「バニラクリームにラベンダーの香りを加え、上に食用の花を飾ってください」と。時間はかかりますが、出来栄えの品質は比較になりません。
[図 24-2] カスタムベーカリーの比喩：スーパーマーケットのカップケーキ（汎用処理）とカスタムベーカリー（専門補助エージェント）の比較
補助エージェントとは、カスタムベーカリーのようなものです。
メインセッションがすべての作業を直接処理するのは、大型スーパーでカップケーキを買ってくるのと似ています。汎用的な能力で複数の作業を一度に処理するため速いですが、各作業の品質には限界があります。一度に読み込む範囲内にコードレビュー、リサーチ、検証作成、デバッグが混在すると、どれにも深く集中することが難しくなります。
補助エージェントに委任すると状況は異なります。「コードレビュー専門家」という補助エージェントは、コードレビュー専用のシステムプロンプト、コードレビューに最適化されたツールセット、そしてコードレビューに特化したコンテキストを備えています。オーダーメイドのベーカリーがカップケーキ一つに全精力を注ぐように、補助エージェントも委任された一つの作業にすべての能力を集中させます。
この比喩において、さらに注目すべき点があります。オーダーメイドのベーカリーに注文を入れる際、私たちは望むものを明確に伝えます。「バニラクリーム、ラベンダーの香り、食用の花。」補助エージェントに作業を委任する際も同様です。メインセッションが補助エージェントに送るプロンプトこそが注文書です。注文書が明確であればあるほど、返ってくる成果物の品質は高まります。
そしてオーダーメイドのベーカリーでは、再注文も可能です。「前回のあのカップケーキを、今回は20個だけ追加でお願いします。」補助エージェントも同様で、一度うまく作成しておけば、プロジェクトを超えて組織全体で再利用できます。
補助エージェントを使用すべき5つの理由
補助エージェントが何者であり、どのような構造で動作するかを理解しました。では、具体的にどのような状況で補助エージェントが真価を発揮するのか、見ていきましょう。
コンテキストを保持するためです。Claude Codeを使用する際、最も注意すべきリソースは一度に読み込む範囲です。コンテキストの劣化は現実的な脅威です。オペレータの役割は、一度に読み込む範囲を最大限効率的に管理することであり、サブエージェントはその中核的な手段の一つです。
大量のデータを処理し、広範なリサーチを実施し、その結果からメインセッションが実際に必要とする核心情報だけを抽出して送信します。あるデモでは、サブエージェントが約40,000トークンに相当する作業を処理しましたが、メインセッションは29,000トークン分の消費のみで維持されました。
サブエージェントが処理した40,000トークン分の内容が、メインセッションのコンテキストを汚染しなかったのです。
制約を適用するためです。メインセッションはさまざまなツールを呼び出す必要があります。しかし、危険な作業—GitHub Actionsや特定のコードベースに関する作業—を行う場合は事情が異なります。こうした作業を専門とするサブエージェントに制限されたツールセットのみを付与することで、意図しない被害を防ぐことができます。
メインセッションの強力な権限とサブエージェントの制限された権限を分離することで、全体のワークフローの安全性を高める戦略です。
設定を再利用するためです。サブエージェントは1つのMarkdownファイルで定義されます。このファイルを他のプロジェクトにコピーすれば、同じサブエージェントをすぐに使用できます。組織レベルで考えれば、プロジェクト管理や四半期計画に優れたサブエージェントを1つ作成しておけば、組織全体がその恩恵を受けられます。
スキルと似た原理ですが、サブエージェントには独自のコンテキストとモデル選択という次元が追加されます。
専門化のためです。AIは目的が具体的で狭いほど、より良い結果を出します。計画を立て、構築し、検証し、文書化し、調査し、レビューする万能エージェント1つよりも、各工程を専門とする小さなエージェントを複数持つ方が優れています。メインセッションはそれらの結果を統合すればよいのです。「小さなエージェントが勝つ」という原則は、実戦で繰り返し証明されています。
コスト削減のためです。各サブエージェントに異なるモデルを指定できるため、すべての作業にオパーズを使用する必要はありません。高速な調査が必要なサブエージェントにはハイキューを、コード生成が必要なサブエージェントにはソネットを割り当てれば、時間とモデルの両面でコストを同時に節約できます。
[表23-1] サブエージェント使用理由の要約
委任すべきか直接行うかの判断基準
補助エージェントの利点を知ると、すべての作業を委任したくなる誘惑に駆られます。しかし、そうすると過剰設計（オーバーエンジニアリング）に陥ってしまいます。委任すべきか直接行うべきかを区別する基準が必要です。
メインセッションで直接処理すべき場合:
対話の往復が必要な作業です。「この部分を直して」と依頼し、結果を確認して「いや、こちらの方へ」と修正を依頼する反復的なやり取りは、メインセッションで直接行う方が効率的です。補助エージェントに委任すると、毎回新しいコンテキストから始めなければならず、むしろ非効率的になります。
迅速な修正が必要な作業も同様です。変数名を一つ変えるだけ、誤字を直すだけ、あるいは簡単なロジックを修正する作業に補助エージェントを呼び出すと、エージェントを起動して結果を受け取るオーバーヘッドが、作業自体よりも大きくなってしまいます。
共有されたコンテキストを必要とする作業、つまりこれまでの会話記録に基づいて判断を要する作業は、メインセッションが担当する必要があります。補助エージェントは会話記録を受け継がないためです。
低遅延が求められる状況においても、メインセッションの方が有利です。補助エージェントを呼び出し、作業を実行し、結果を受け取るプロセスには、必然的に時間がかかります。
補助エージェントに委譲すべき場合:
自己完結型の作業です。「このコードベースを分析してセキュリティ上の脆弱性を見つけてください」のように、入力を受け取れば独立して実行し、結果を返却できる作業は委譲に適しています。
ツールの制限が必要な作業にも、補助エージェントが適しています。特定の補助エージェントに対して読み取り専用権限のみを付与したり、特定の MCP 接続サーバーのみを使用するように制限したりできます。
要約された結果のみが必要な場合も、委任のシグナルです。補助エージェントが膨大なデータを処理しても、メインセッションはその結果の核心となる要約のみを受け取れば十分です。これがコンテキストを保持する核心的なメカニズムです。
また、フォアグラウンド（前面）実行とバックグラウンド（背景）実行の選択肢があります。補助エージェントをフォアグラウンドで実行すればメインセッションはその完了を待ち、バックグラウンドで実行すればメインセッションは他の作業を継続できます。この選択は、タスクの緊急性と依存関係によって異なります。
[図 24-3] 委任判断フローチャート：「往復対話が必要か？」→はい：メインセッション／いいえ：「自己完結的か？」→はい：補助エージェント／いいえ：メインセッション
一つ、重要な区別を確認しておく必要があります。補助エージェントとエージェントチーム（Agent Teams）は名称が似ており概念が重複しているように見えますが、根本的な違いがあります。補助エージェントは双方向ではなく単方向の関係です。メインセッションが入力を送ると、補助エージェントは作業を実行し、その結果をメインセッションに返送します。補助エージェント同士が相互に会話することはできません。
並列で実行されても、それぞれが独立して作業を行います。
エージェントチームは双方向です。メンバーは共有タスクリストを持ち、互いにメッセージを送り合い、互いに作業を割り当てることができます。これは全く異なる次元の協業であり、次の章で具体的に解説する領域です。
これまで、サブエージェントとは何か、なぜ必要なのか、いつ使用するべきかという概念的な基盤を築いてきました。今度は、この概念を実際に実装する方法を手取り足取り解説する時が来ました。