Claude Code の Skill（定型手順を再利用できる仕組み）を使って複雑なタスクを自動化していると、ある段階で「次に何をすればいいか忘れる」という現象に遭遇する。たとえば筆者の環境では、10 ステップを超えるワークフローを Skill で組んだとき、STEP 8 を飛ばして STEP 9 に進んだり、途中で「もう完了したはず」と判断して停止するケースが繰り返し発生した。
なぜこれが起きるのか。原因は Skill の構造にある。キーワードは context の分離だ。ここでいう context とは、モデルがその場で参照している会話履歴のこと。解決にはこの context の分離が必要だが、実用的な方法がなかった — 最近まで。
Skill は「実行」と「管理」が同じ context にいる
Skill はメインエージェントの context 上で動く。Skill の実行結果もメインエージェントの context に蓄積される。
3 ステップの Skill を順番に実行する場合を考えてみる。STEP 1 の実行結果がメインの context に入り、STEP 2 の結果がさらに上に積まれ、STEP 3 の結果がさらにその上に来る。ステップが増えるたびに、過去の実行結果がメインの context を圧迫する。
問題は単にトークン量が増えることではない。「次にどの STEP を実行するか」という管理情報と「各 STEP の実行結果」という詳細情報が同じ context 上で混在することだ。管理情報が大量の実行結果に埋もれて、モデルが直近の情報に引っ張られやすくなる。
Anthropic も公式ブログで「モデルは context が埋まるにつれてコヒーレンスを失い、知覚した限界に近づくと作業を早期に切り上げる傾向がある」と指摘している。
Sub Agent なら context が分離される
Sub Agent（親とは別の context で走る子エージェント）は独立した context を持つ。メインエージェントが Sub Agent を起動すると、Sub Agent は自分専用の context で作業を行い、結果だけをメインに返す。
何ステップ実行しようと、メインの context には「STEP 1: 成功、STEP 2: 成功 …」というタスク管理のインデックスだけが残る。実行の詳細は各 Sub Agent の context に閉じ込められ、メインを汚染しない。マイクロサービスでプロセスを分離するのと同じ発想だ。
問題は Sub Agent の「起動の手間」だった
概念的には Sub Agent が正しい選択だが、実用上の問題があった。Skill なら Markdown ファイルに手順を書いておけば /skill-name の一言で実行できる。一方、Sub Agent に同じことをさせるには、メインエージェントが手順書の内容を自分の context に読み込み、それをプロンプトとして Sub Agent に渡す必要があった。context 分離のために Sub Agent を使っているのに、起動のたびにメインの context を消費するという矛盾だ。
Skill の手軽さと Sub Agent の context 分離を両立する方法がなかった。
initialPrompt: Sub Agent が Skill のように動く
Claude Code v2.1.83 で追加された initialPrompt は、この矛盾を解消する。エージェント定義ファイルの frontmatter に「起動時に自動実行するプロンプト」を宣言できる機能だ。
実際の定義ファイルを見ると、拍子抜けするほどシンプルだ。
---
name: test-runner
model: sonnet
initialPrompt: "npm test を実行し、失敗したテストがあれば原因を分析して修正してください。"
---
あなたはテスト実行の専門エージェントです。テストの実行と修正に集中してください。テストを実行して結果を報告するエージェントの定義で、initialPrompt にタスク内容を書いている。このファイルを .claude/agents/test-runner.md に置くだけで、メインエージェントが test-runner を起動した瞬間に、Sub Agent は自動的にテストの実行を開始する。メインエージェントがプロンプトを組み立てる必要はない。
つまり、Skill のように「起動するだけで決まったタスクを実行する」動作を、Sub Agent の context 分離のもとで実現できる。
Anthropic のブログが裏付ける方向性
この方向性は、Anthropic が 3 月 24 日に公開したエンジニアリングブログ「Harness design for long-running application development」と一致する。
ブログでは、長時間のエージェントタスクを安定させるために Planner（計画）・Generator（実行）・Evaluator（評価） の 3 エージェント構成を提案している。このブログが特に強調しているのが context のリセットだ。エージェント間の受け渡しにファイルやアーティファクトを使うことで、各エージェントはクリーンな context で作業を開始できる。これはまさに Sub Agent の context 分離と同じ考え方だ。
ブログの結論にある「ハーネスの各コンポーネントは、モデルが単体ではできないことについての仮定をエンコードしている」という一文は示唆的だ。この原則を Skill の問題に当てはめると、「モデルは長い context で管理と実行を同時にこなせない」という仮定が見えてくる。Sub Agent への分離は、その仮定に基づく設計判断だと考えられる。