務めている会社では生成AIの活用を積極的に推進しており。AIで効率化を図れと口酸っぱく言われているので、今更ながら仕事でSkillsを使い始めたワタクシ。
自社製ライブラリの使い方とかをSkillsに落とし込んだりして使ってる。(これについては別の記事で話す)トークン数が節約できたり、バイブコーディングのクオリティが上がったりで便利なんだけど、最近「Sub-Agents」なるものがあると聞いて。概要だけ調べてみると、「それ、Skillsと何が違うん？」と思った。
ので、Claude先生(Sonnet4.5)に壁打ちして理解を深めてみた。題材が2周くらい遅れちゃってる気もするが気にしないのだ。
そもそもSkillsとSub-Agentsって何？
まずClaude先生に基本を聞いた。
Claude先生: SkillsはClaudeに特定のタスクを実行させるための指示セットです。プロンプトのパッケージ化みたいなもの。
例えば「技術記事を書くSkill」「コードレビューするSkill」みたいに、再利用可能な型を作れます。
一方、Sub-AgentsはClaudeが別のClaude（またはAI）に仕事を委譲する仕組み。
Claudeが複数のインスタンスを呼び出して並列処理させるイメージです。
| Skills | Sub-Agents | |
|---|---|---|
| 実体 | プロンプト | AIインスタンス |
| 実行 | Claudeが従う | Claudeが呼び出す |
| 並列 | × | ○ |
| 独立性 | 低い | 高い |
なるほど、並列処理がキーワードっぽい。
疑問1: 並列処理って、順次処理と何が違うん？
並列処理と言われても、1つのエージェントが複数のSkillを使って順々に処理していくのと何が違うのか。
Claude先生: いい質問ですね。
Skillsの順次処理はこう：
Claude（1つ）
↓
Skill A実行（リサーチ）
↓ 結果を引き継ぐ
Skill B実行（分析）
↓ 結果を引き継ぐ
Skill C実行（執筆）
前の処理が終わらないと次に進めない。コンテキストが累積していく。
Sub-Agentsの並列処理はこう：
Claude（親）
├─ Sub-Agent 1（視点Aで分析）
├─ Sub-Agent 2（視点Bで分析）
└─ Sub-Agent 3（視点Cで分析）
↓ 同時実行
3つの結果を統合
同時に走るから速いし、各Agentは独立したコンテキストを持つので干渉しない。
例えば5つのブログ記事を書く場合：
- Skills: 順番に5回実行（合計50分）
- Sub-Agents: 同時実行（合計10分）
なるほど、時間短縮とコンテキストの独立性がメリットか。
疑問2: コンテキスト独立って、容量が増えるってこと？
Sub-Agentsは「独立したコンテキスト」と言うが、具体的にどういう意味なのか。
1セッションに対するコンテキストの上限が増えるってこと？
Claude先生: いや、増えません。
これ、誤解しやすいポイントです。
コンテキスト独立 ≠ 容量が増える
コンテキスト独立 = 情報汚染されない
各Sub-Agentは独自の200K枠を持ちますが、お互いのコンテキストを見れません。
例えばレビュータスクで：
Skillsで3視点レビュー（順次）:
Claude（1つのコンテキスト）
↓
技術的視点でレビュー（結果A）
↓ コンテキストに蓄積
デザイン視点でレビュー（結果B）
↓ 結果Aも見える状態
ビジネス視点でレビュー（結果C）
後の視点が前の視点に引っ張られる。「技術的にOKって言ってるから、まあいいか」みたいなバイアス。
Sub-Agentsで3視点レビュー（並列）:
親Agent
├─ Sub-Agent 1（技術視点）→ 他の視点は見えない
├─ Sub-Agent 2（デザイン視点）→ 他の視点は見えない
└─ Sub-Agent 3（ビジネス視点）→ 他の視点は見えない
↓
親が3つの独立した意見を集約
各視点が純粋に判断できる。バイアスがかからない。
なるほど、容量じゃなくて「情報の分離」の話か。
疑問3: じゃあSub-Agentの200Kはどう活かされるの？
親も200Kなら、1つのSub-Agentの結果でいっぱいになっちゃわない？
Claude先生: めっちゃ鋭い指摘。Sub-Agentsの結果は「要約」して返します。
ダメな使い方：
親Agent（200K）
↓
Sub-Agent（200K使って超詳細レポート生成）
↓
親「200K全部受け取ります」
→ 親が即死
正しい使い方：
親Agent（200K）
↓
Sub-Agent（200K使って分析）
↓ 要約して返す（5K程度）
親「5Kだけ受け取る」
→ 親は余裕
例えば100ページのPDFを3つの視点で分析する場合：
親Agent
├─ Sub-Agent 1
│ └─ 100ページ読む（150K消費）
│ └─ 技術的要点を5Kにまとめて返す
│
├─ Sub-Agent 2
│ └─ 100ページ読む（150K消費）
│ └─ ビジネス要点を5Kにまとめて返す
│
└─ Sub-Agent 3
└─ 100ページ読む（150K消費）
└─ リスク要点を5Kにまとめて返す
親Agent
└─ 3つの要約（計15K）を統合
└─ 最終レポート作成
Sub-Agentの200Kは「作業場」。好きなだけデータを読み込んで処理して、圧縮して親に渡す。
工場と本社の関係みたいなもんか。
疑問4: 要約で重要な情報が抜け落ちるリスクがあるよね？
コンテキストを節約する仕組みはわかった。
でもそれ、Sub-Agentの要約によって重要な情報が抜け落ちるリスクがあるよね？
Claude先生: その通りです。これがSub-Agentsの最大のトレードオフです。
要約すると：
- ✅ 親のコンテキストを節約できる
- ❌ 情報が欠落するリスク
要約しないと：
- ✅ 情報は完全に保持
- ❌ 親のコンテキストが爆発
実際に起こる問題として、技術レビューで：
Sub-Agent（詳細分析）:
「Line 234のメモリリーク、
Line 456の例外処理の不備、
Line 789のスレッドセーフティ問題、
...全50箇所の問題を検出」
↓ 要約
親Agentへの返却:
「主要な問題3点:
1. メモリ管理の懸念
2. エラーハンドリングの不備
3. 並行処理のリスク」
Line 456とLine 789の具体的な行番号が消えた。
これを防ぐには：
- 階層的要約（詳細版を保持しつつ要約版を返す）
- 構造化された要約（「問題3件: Line 234, 456, 789」）
- 重要度フィルタリング（Criticalだけ詳細に）
結局どっちを選ぶかはタスク次第：
- 大量データの並列処理 → Sub-Agents（要約で十分）
- 精密な分析が必要 → Skills（全情報が必要）
- 独立した視点が欲しい → Sub-Agents（バイアス回避）
- 文脈の連続性が重要 → Skills（情報の流れ）
Sub-Agentsは「完璧な情報保持」を諦める代わりに「スケール」を手に入れる仕組み
なるほどね、情報の完全性とトレードオフで、処理のスケールを広げるのがSub-Agentsの特徴ってことね。
まとめ
Skills
- 情報の完全性を保つ
- 1つのコンテキストで順次処理
- 精密な作業向き
Sub-Agents
- 処理のスケールを広げる
- 並列実行、独立したコンテキスト
- 要約によって情報は削ぎ落とす
- 大量・多視点の処理向き
壁打ちしてみて、疑問をリレーしていくことで理解が深まった。
最初は「何が違うん？」だったのが、「並列って何？」「コンテキストって？」「要約のリスクは？」と掘り下げていくことで、本質的なトレードオフが見えてきた。
仕事でどっちを使うかは、タスクの性質次第。
情報を落としたくないならSkills、スケールさせたいならSub-Agents。
とりあえず、今のところはSkillsで十分そうです。
あとこの壁打ち、結構楽しかったのでシリーズ化します。聞くAIをGeminiにしてみたり、モデルを変えたときの回答の比較だったりしてみても面白そう。
コメント