OpenClaw のサブエージェントは、いきなり複雑な分業構成を組むよりも、単一目的の小さなジョブから始めたほうが安定します。役割を絞ったうえで実行ログを観察し、失敗条件と再実行手順を先に固めておくと、後から責務を分割しやすくなります。
結論: OpenClaw のサブエージェント設計パターンと実践例は、最小構成で始めてログを見ながら段階的に広げるのが最短です。
Background
毎日の運用タスクは、手作業だと実行漏れや設定ブレが起きやすくなります。特に、定時チェックや要約、監視結果の整理のような反復処理は、人がやるよりもサブエージェントに切り出したほうが安定します。
ただし、最初から複数のサブエージェントを連携させると、失敗箇所の切り分けが難しくなります。まずは「1つの入力を受けて、1つの成果物を返す」単純な流れに限定し、観測可能な状態を保つのが基本です。
設計時に意識したいのは、役割の分離です。たとえば「情報収集」「実行」「要約」を一気に詰め込むのではなく、最初は 1 つの責務だけを持つサブエージェントとして定義し、その後必要に応じて分割します。
Step-by-step
1. 目的と対象範囲を決める
最初に決めるべきなのは、「何を自動化するか」ではなく「どこまでできれば成功か」です。たとえば「毎朝 9 時にジョブを実行し、結果を 3 行で要約できれば成功」のように、終了条件を明確にしておくと評価しやすくなります。
対象範囲は 1 つの処理に絞るのが安全です。最初から通知、再試行、後続処理まで入れず、まずは単体で完走するジョブを作ります。
2. 最小構成で設定する
最初のサブエージェントは、単純な定期実行ジョブとして登録するのが分かりやすい構成です。以下は、毎日 9 時に独立したセッションでジョブを実行し、結果を要約させる最小例です。
1
2
3
4
5
6
7
8
# 毎日 09:00 (Asia/Tokyo) に実行
# isolated セッションを使うことで、他の実行コンテキストの影響を受けにくくする
openclaw cron add \
--name "daily-sample" \
--cron "0 9 * * *" \
--tz "Asia/Tokyo" \
--session isolated \
--message "ジョブを実行して結果を3行で要約してください。失敗した場合は原因を1行で示してください。"
この時点では、メッセージも短く保つのが重要です。役割が曖昧な長文プロンプトよりも、入力、期待する出力、失敗時の振る舞いを簡潔に指定したほうが、ログの比較と改善がしやすくなります。
3. 実行結果を検証する
実運用に入れる前に、少なくとも数回は手動または初回スケジュール実行の結果を確認します。見るべきポイントは、「成功したか」だけでなく、「失敗したときに次の行動が分かるか」です。
ログ確認では、次の観点を揃えておくと運用が安定します。
- 実行開始時刻と終了時刻が想定どおりか
- 出力が毎回同じ形式になっているか
- 失敗時に、認証・依存サービス・入力不備のどれが原因か判断できるか
通知文や要約文は短く統一します。人があとで見返したときに、1 回分のジョブで何が起きたかを数秒で把握できる形式に寄せるのが実用的です。
4. 必要になったら責務を分割する
最小構成が安定したら、初めてサブエージェントを分ける判断をします。たとえば、情報収集と要約の失敗要因が異なるなら、そこで 2 つの責務に分離する価値があります。
分割の基準は「再利用したいから」ではなく、「失敗原因を切り分けたいから」です。運用設計では、抽象度の高さよりも障害時の追跡しやすさを優先したほうが、結果的に拡張も楽になります。
Common pitfalls
-
タイムゾーンを指定せずに登録して、想定より 9 時間ずれた時刻に動く
--tz "Asia/Tokyo"を明示し、初回実行日は予定時刻をカレンダー上でも確認します。ジョブ名にリージョンや用途を含めると、後で見分けやすくなります。 -
認証切れや権限不足でジョブ自体は起動しているのに、本処理だけ失敗する
実行前提となる認証情報や API トークンの更新期限を確認し、失敗時の出力に「認証エラー」と分かる文言を含めます。正常系だけでなく、期限切れ時の挙動も一度試しておくと安全です。 -
ローカル LLM や外部依存サービスが停止していて、原因不明の失敗に見える
依存先がある場合は、ジョブ本体の前にヘルスチェック手順を用意します。少なくとも「接続不可」「タイムアウト」「レスポンス異常」を見分けられるログにしておくべきです。 -
1 つのジョブに複数責務を入れすぎて、どこで失敗したのか追えなくなる
最初は収集、変換、通知を分けずに作りたくなりますが、障害解析の観点では逆効果です。まずは 1 ジョブ 1 成果物に絞り、安定後に必要な箇所だけ分離します。 -
出力フォーマットが毎回揺れて、人が確認しづらい
成功時と失敗時の文面を固定し、要約の行数や順序も揃えます。ログは「読むたびに解釈が必要な文章」ではなく、「見れば状況が分かる定型文」に寄せるのが運用向きです。
Summary
OpenClaw のサブエージェント設計では、最初から賢い分散構成を目指す必要はありません。まずは単一責務の最小構成を作り、ログを観察しながら失敗条件と運用手順を固めることが、最も再現性の高い進め方です。
実践では、「目的を絞る」「実行条件を固定する」「ログから改善する」という順番を崩さないことが重要です。最小構成で開始し、安定を確認してから段階的に広げることで、失敗を抑えながら運用を育てられます。