- サブエージェントは「もう1人の自分」——重いタスクをバックグラウンドで並列処理できる
- コンテキスト分離により、メインセッションのトークン消費を抑えつつ高品質な出力を維持
- SES現場ではコードレビュー・ドキュメント生成・データ分析を同時並行で委譲可能
「AIエージェントに1つずつ順番にタスクを頼んでいたら、結局自分でやった方が速いのでは？」と感じたことはありませんか？
OpenClawのサブエージェント機能は、メインエージェントが別のエージェントセッションを生成し、独立したタスクを並列で委譲できる仕組みです。人間のチームリーダーがメンバーにタスクを振り分けるように、AIエージェントも「分業」することで生産性を劇的に向上させることができます。
この記事では、セッション管理の基本概念からサブエージェントの設計パターン、SES現場での実践活用まで、手順付きで完全解説します。
1. OpenClawの「セッション」とは何か
OpenClawにおけるセッションとは、エージェントとユーザー（または他のエージェント）の間で維持される1つの会話コンテキストのことです。各セッションは独立したメモリ空間を持ち、会話履歴やツールの実行結果が蓄積されます。
セッションの種類
OpenClawのセッションは大きく3つに分類されます。
| 種類 | 説明 | 用途 |
|---|---|---|
| メインセッション | ユーザーとエージェントの直接対話 | 日常的な質問・指示 |
| cronセッション | スケジュール起動の独立セッション | 定期タスクの自動実行 |
| サブエージェントセッション | 親セッションから生成される子セッション | タスクの並列委譲 |
メインセッションはワークスペース設計で解説したAGENTS.mdやSOUL.mdのコンテキストを常に保持します。一方、cronセッションはEp.6のcronジョブ解説で紹介した通り、完全に独立した環境で起動します。
サブエージェントセッションは、親セッションが明示的に生成する子プロセスのようなものです。親から必要最小限のコンテキストを受け継ぎつつ、独自のタスクを遂行します。
セッションライフサイクル
ユーザー入力
↓
[メインセッション起動]
↓
コンテキスト読み込み（AGENTS.md, SOUL.md, memory/）
↓
タスク分析 → 単一タスク → 直接実行
↓ ↓
↓ 複合タスク → サブエージェント生成
↓ ├─ サブ1: コード修正
↓ ├─ サブ2: テスト実行
↓ └─ サブ3: ドキュメント更新
↓ ↓
↓ 完了を自動報告（プッシュ型）
↓ ↓
結果を統合してユーザーに返答2. サブエージェントの仕組みと設計原則
サブエージェントは、メインエージェントの「分身」として機能します。ただし、無計画にサブエージェントを生成すると、コスト増大やコンテキスト混乱を招きます。効果的な設計原則を理解しましょう。
プッシュ型完了通知
サブエージェントの最も重要な特徴は、プッシュ型の完了通知です。メインエージェントがサブエージェントの状態を繰り返し確認（ポーリング）する必要はありません。サブエージェントが処理を完了すると、結果が自動的に親セッションに通知されます。
❌ アンチパターン: ポーリングループ
while (サブエージェント未完了) {
5秒待機 → 状態確認 → トークン消費
}
✅ 正しいパターン: プッシュ型
サブエージェント生成 → 別タスクを処理 → 完了通知を受信コンテキスト分離の原則
サブエージェントに渡すコンテキストは必要最小限に絞ります。メインセッションの全会話履歴をコピーすると、トークン消費が膨大になります。コスト最適化ガイドで解説したトークン管理の考え方がここでも重要です。
サブエージェント設計の3原則
- 単一責任: 1つのサブエージェントに1つのタスクを割り当てる
- 自己完結: サブエージェントは親への問い合わせなしにタスクを完了できるよう、十分なコンテキストを初期投入する
- 冪等性: 同じ入力に対して同じ結果を返すよう設計し、リトライ時の副作用を防ぐ
3. サブエージェントの実践的な使い方
サブエージェントの生成
OpenClawでは、subagents ツールを使ってサブエージェントを管理します。メインエージェントのプロンプトやAGENTS.mdで適切な委譲パターンを記述すると、エージェントが自動的にサブエージェントを活用します。
タスク委譲のベストプラクティス
パターン1: 並列リサーチ
複数のトピックについて同時に調査が必要な場合、それぞれのリサーチをサブエージェントに委譲します。
メインエージェント:
「3つの競合ツールを調査して比較表を作成して」
↓
サブ1: ツールAの機能・価格調査
サブ2: ツールBの機能・価格調査
サブ3: ツールCの機能・価格調査
↓
結果を統合して比較表を生成パターン2: コードレビュー＋テスト
プルリクエストの処理をサブエージェントで分業するパターンです。GitHub連携ガイドで解説したPR自動化と組み合わせると強力です。
メインエージェント:
「PR #42をレビューしてテストも実行して」
↓
サブ1: コード変更のレビュー（セキュリティ・品質チェック）
サブ2: テストスイートの実行（CI結果の解析）
↓
レビューコメントとテスト結果を統合してPRにコメントパターン3: コンテンツ制作パイプライン
ブログ記事の作成をサブエージェントで分業するパターンです。マーケティング自動化ガイドの発展形です。
メインエージェント:
「次のブログ記事を作成して」
↓
サブ1: SEOキーワード調査＋競合分析
サブ2: 記事の下書き執筆
サブ3: OG画像・インフォグラフィック生成
↓
結果を統合してバリデーション→公開4. セッション管理のベストプラクティス
メモリとセッションの関係
メモリ管理ガイドで解説したメモリシステムは、セッション間のコンテキスト共有に重要な役割を果たします。
- ファイルベースのメモリ（MEMORY.md, memory/YYYY-MM-DD.md）はセッション間で共有される
- セッション内メモリ（会話履歴）はセッション終了と共に消える
- サブエージェントはファイルシステムを通じて結果を永続化できる
セッション数の最適化
サブエージェントを無制限に生成すると、API コストが急増します。以下のガイドラインを参考にしてください。
| シナリオ | 推奨サブエージェント数 | 理由 |
|---|---|---|
| 単純な調査タスク | 0（直接実行） | オーバーヘッドの方が大きい |
| 2-3の独立タスク | 2-3 | 並列効果が高い |
| 大規模プロジェクト | 3-5 | これ以上はコスト対効果が下がる |
エラーハンドリング
サブエージェントが失敗した場合の対処も設計しておく必要があります。エラーハンドリングガイドの原則がここでも適用されます。
- タイムアウト設定: サブエージェントが無限に実行され続けることを防ぐ
- リトライ戦略: 一時的なエラーに対する自動リトライ
- グレースフルデグレード: サブエージェントの一部が失敗しても、成功した部分の結果は活用する
5. SES現場での実践活用シナリオ
シナリオ1: 朝の自動ブリーフィング
SESエンジニアが出勤前に、その日必要な情報を自動で収集・整理するパイプラインです。
[cronジョブ: 毎朝7:30]
メインエージェント起動
├─ サブ1: メールチェック（重要メールの要約）
├─ サブ2: Slackの未読メンション確認
├─ サブ3: GitHubのPR/Issue更新確認
└─ サブ4: 当日のカレンダー予定取得
↓
結果を統合して「朝のブリーフィング」をSlackに投稿cronジョブの設定方法とSlack連携の方法を組み合わせることで、この仕組みを構築できます。
シナリオ2: プロジェクト横断レポート
複数の客先案件を同時に管理するSESエンジニア向けのレポート自動生成です。
「今週の全プロジェクトの進捗をまとめて」
↓
サブ1: プロジェクトA（GitHub + Slack）
サブ2: プロジェクトB（Jira + メール）
サブ3: プロジェクトC（GitHub + Teams）
↓
横断レポートを自動生成シナリオ3: 技術検証の並列実行
新しいライブラリやフレームワークの評価を複数同時に行うケースです。
「React, Vue, Svelteの最新版でTodoアプリを作って比較して」
↓
サブ1: React版の実装＋ベンチマーク
サブ2: Vue版の実装＋ベンチマーク
サブ3: Svelte版の実装＋ベンチマーク
↓
パフォーマンス・DX・エコシステムの比較表を生成6. 応用テクニック: ステアリングとサブエージェント監視
ステアリング（方向修正）
実行中のサブエージェントに対して、途中で指示を変更したい場合があります。OpenClawのsubagents steer機能を使うと、実行中のサブエージェントにメッセージを送信して方向修正が可能です。
# サブエージェントの一覧確認
subagents list
# 特定のサブエージェントに追加指示
subagents steer --target <session-id> --message "出力をCSV形式に変更して"サブエージェントのキル
不要になったサブエージェントや、暴走しているサブエージェントを停止するにはsubagents killを使います。
# 特定のサブエージェントを停止
subagents kill --target <session-id>深度制限
サブエージェントがさらにサブエージェントを生成する「ネスト」も可能ですが、深度制限を設けることが重要です。一般的には深度2までが実用的な上限です。それ以上のネストはコンテキストの希薄化とコスト増大を招きます。
7. コスト面の考慮事項
サブエージェントは強力ですが、各セッションがそれぞれAPIコストを消費する点を忘れてはいけません。
コスト計算の目安
サブエージェント1回あたりのコスト ≈
コンテキスト注入のトークン（入力）
+ タスク実行のトークン（出力）
+ ツール呼び出しのトークン
例: 3つのサブエージェントを並列実行
メイン: 5,000トークン
サブ×3: 各10,000トークン = 30,000トークン
合計: 35,000トークン
vs 直列実行:
全て1セッション: 40,000トークン（コンテキスト蓄積により増加）並列実行の方がトークン効率が良いケースが多いのは、コンテキストの蓄積を分離できるためです。詳しくはコスト最適化ガイドを参照してください。
モデル選択の最適化
サブエージェントには、タスクの複雑さに応じて異なるモデルを使い分けることも可能です。
- 単純な調査・データ取得: 軽量モデル（Claude Haiku, GPT-4o-mini）
- コードレビュー・分析: 中量モデル（Claude Sonnet）
- 複雑な推論・設計: 重量モデル（Claude Opus, o1）
まとめ: サブエージェントで「1人チーム」を実現する
OpenClawのセッション管理とサブエージェント機能は、1人のエンジニアを疑似的なチームに変える強力なツールです。
本記事で解説したポイントを振り返りましょう。
- セッションの理解: メイン・cron・サブの3種類を使い分ける
- 設計原則: 単一責任・自己完結・冪等性の3原則を守る
- プッシュ型通知: ポーリングせず、完了を待つ
- コスト意識: サブエージェント数とモデル選択を最適化する
- 実践活用: 朝ブリーフィング、横断レポート、技術検証の並列化
次回のエピソードでは、OpenClawのさらに高度な機能について解説予定です。シリーズ全体はOpenClaw 完全攻略シリーズからご覧いただけます。
出典・参考資料:
