タスクごとに最適なハーネスをResearch Preview
Claude Code に Dynamic Workflows（ダイナミックワークフロー） が登場した。Claude がタスクに応じてオーケストレーションスクリプトをその場で書き、ランタイムがバックグラウンドで実行する仕組みだ。1 セッション内で数十から数百の並列サブエージェントを走らせ、結果をまとめる前に検証する。週単位かかっていた複雑なエンジニアリング作業を、数日で完了させることを狙っている。
デフォルトの Claude Code ハーネスはコーディング向けに作られているが、多くのタスクはコーディングに似ているため幅広く役立つ。一方で Research、セキュリティ分析、エージェントチーム、コードレビューのように、ピーク性能を出すには専用ハーネスを別途組む必要があった領域もある。Workflows はそうしたハーネスを Claude Code 上でネイティブに、しかも動的に生成できるようにする。作ったワークフローは他者と共有・再利用もできる。
本記事は Anthropic の Claude Code チームに所属する Thariq Shihipar 氏と Sid Bidasaria 氏によるブログ記事「A harness for every task: dynamic workflows in Claude Code」をもとに、要点を整理したリサーチノートである。
なぜ動的ワークフローなのか
デフォルトのハーネスにタスクを依頼すると、Claude は同じコンテキストウィンドウの中で計画と実行を同時にこなす。多くのコーディングタスクではこれが極めて有効だが、長時間・大規模並列・高度に構造化された敵対的タスクでは破綻しやすい。単一コンテキストで複雑な作業を続けるほど、次の 3 つの失敗モードに陥りやすくなるためだ。
Agentic laziness
複雑な多段タスクを途中で打ち切り、部分的な進捗で「完了」と宣言してしまう。たとえばセキュリティレビュー 50 項目のうち 20 項目で終えてしまうような挙動。
Self-preferential bias
自分の出力や発見を優先しがちになる傾向。とくにルーブリックに照らして検証・採点を求められたとき、判定が甘くなる。
Goal drift
多くのターンを経るうちに当初の目的への忠実度が徐々に失われる。とくに要約（compaction）のたびに情報が欠落し、エッジケース要件や「X するな」という制約が抜け落ちる。
ワークフローを作ると、それぞれ独立したコンテキストウィンドウと、絞り込まれた目標を持つ複数の Claude をオーケストレーションできる。これによって上記の失敗モードを構造的に抑え込める。
3 つのプリミティブの使い分け
Workflows は Subagents、Skills に続く第 3 のオーケストレーションプリミティブだ。「次に何を実行するか、その判断とプランを誰が保持するのか」という軸で整理すると理解しやすい。
| Subagents | Skills | Workflows | |
|---|---|---|---|
| 正体 | Claude が spawn するワーカー | Claude が従う指示 | ランタイムが実行するスクリプト |
| 次の実行を決めるのは | Claude（ターンごと） | Claude（指示に従う） | スクリプト |
| 中間結果の保管場所 | Claude のコンテキスト | Claude のコンテキスト | スクリプト変数 |
| 再現できるもの | ワーカー定義 | 指示 | オーケストレーション自体 |
| スケール | 数タスク／ターン | 同左 | 数十〜数百エージェント／run |
Subagents や Skills では Claude がターンごとにオーケストレータを務め、すべての結果がコンテキストに載る。一方 Workflows ではスクリプトがループ・分岐・中間結果を抱え、Claude のコンテキストには最終回答だけが返る。これが大規模な並列処理を成立させる鍵になっている。
6 つの合成可能なパターン
Workflows を使うには、ただ「ワークフローを作って」と頼むか、トリガーワード ultracode を使えばよい。とはいえ、Claude がワークフローを組むときに使い、組み合わせる代表的なパターンを把握しておくと、いつ使うべきか、どうプロンプトで誘導するかの見通しが立つ。
| パターン | 内容 | 向くタスク |
|---|---|---|
| Classify-and-act | 分類エージェントがタスク種別を判定し振り分ける。末尾に置いて出力の判定にも使える | 種類が混在するキュー処理、モデルルーティング |
| Fan-out-and-synthesize | 細かいステップに分割して各エージェントが処理し、結果を統合する。synthesize は全 fan-out を待って構造化出力をマージするバリア | ステップ数が多い、各ステップにクリーンなコンテキストが要るとき |
| Adversarial verification | 各エージェントの出力を、別エージェントがルーブリックや基準に照らして敵対的に検証する | self-preferential bias の抑制 |
| Generate-and-filter | アイデアを多数生成し、ルーブリックや検証でフィルタ、重複排除して高品質なものだけ返す | ネーミング、設計案の絞り込み |
| Tournament | 分割でなく競争。N 個のエージェントが別アプローチで同一タスクに挑み、judging エージェントが pairwise で勝者を決める | 定性評価、ソート（絶対採点より比較判断が信頼できる） |
| Loop until done | 作業量が未知のとき、停止条件（新しい発見がない、ログにエラーがない）を満たすまで spawn を繰り返す | 不定量の triage、デバッグ |
プロンプト例
具体的にどんな依頼が可能か、記事で挙げられている例を引いておく。発想を広げる手がかりになる。
「50 回に 1 回失敗するテストがある。ワークフローを組んで再現し、仮説を立てて worktree で敵対的に検証して。どれか 1 つが通るまで止めないで」
「直近 50 セッションを掘り返し、自分が繰り返している修正を見つけて、頻出するものを CLAUDE.md のルールにして」
「業務プランを、投資家・顧客・競合それぞれの視点から別々のエージェントに引き裂かせて」
「80 件の履歴書をバックエンドのロール向けにランク付けして、上位 10 件を二重チェックして。ルーブリックは AskUserQuestion で私にヒアリングして」
「ブログ草稿の技術的な主張を、すべてコードベースと照合して。間違ったまま公開したくない」
ユースケース別の使いどころ
記事では「ワークフローは非技術的な作業でこそ、むしろ有用なことが多い」と強調されている。代表的なユースケースを整理する。
マイグレーションとリファクタ
callsite、失敗するテスト、モジュールなどを単位に分解し、各修正を worktree 内のサブエージェントが行い、別エージェントが敵対的にレビューしてマージする。リソースを大量消費するコマンドを使わせない指示を添えると、マシンのリソースを使い切らずに並列度を最大化できる。
ディープリサーチ
Claude Code には dynamic workflows で実装された /deep-research スキルが同梱されている。Web 検索を fan-out し、ソースを取得して主張を敵対的に検証し、引用付きレポートを統合する。Web 検索に限らず、Slack の文脈からステータスレポートを作る、コードベースを深く探索して機能の仕組みを調べる、といった用途にも応用できる。
ディープ検証
レポート内のすべての事実主張を 1 つのエージェントが洗い出し、各主張をサブエージェントが個別に詳細チェックする。さらにソースの質を確かめる検証エージェントを重ねることもできる。
ソート
1000 行を超えるリストを 1 プロンプトでソートさせると品質が劣化し、コンテキストにも収まらない。代わりに tournament、pairwise 比較のパイプライン、並列の bucket-rank からのマージを使う。各比較が独立したエージェントになり、決定論的なループがブラケットを保持するので、コンテキストには進行中の順序だけが残る。
メモリとルール遵守
CLAUDE.md に書いても守られないルールがあれば、「1 ルールにつき 1 検証エージェント」で確認するワークフローを作る。懐疑役（skeptic）のペルソナでルール自体を見直させると、誤検知を抑えられる。逆方向に、過去セッションやレビューコメントから繰り返している修正をマイニングし、並列エージェントでクラスタ化、各候補を敵対的に検証して、生き残ったものを CLAUDE.md に蒸留する使い方もできる。
根本原因の調査
デバッグは複数の独立した仮説を立てて検証するのが最も効くが、単一コンテキストだと self-preferential bias に陥る。ログ、ファイル、データのように分離した証拠から別々のエージェントに仮説を生成させ、検証役と反証役のパネルにかける。コードに限らず、売上分析（なぜ 3 月に売上が落ちたか）、データ基盤のパイプライン障害、あらゆるポストモーテムに使える。
大規模なトリアージ
サポートキューやバグ報告を、各項目を分類し、既存のトラッキングと重複排除し、アクション（修正の試行や人へのエスカレーション）を取る。有用なのが quarantine パターンで、信頼できない公開コンテンツを読むエージェントには高権限のアクションを禁じ、情報に基づいて動くのは別のエージェントに担わせる。/loop と組み合わせれば継続的に回せる。
探索とテイスト／評価／モデルルーティング
設計やネーミングのようにテイストが絡む探索では、レビューエージェントにルーブリックを与え、tournament で順位付けする。軽量な評価（eval）も、worktree で別エージェントを spawn し、比較エージェントがルーブリックで採点する形で回せる。さらに分類エージェントにタスクを調査させ、複雑さに応じて Sonnet か Opus かを振り分けるモデルルーティングも可能だ。
事例：Bun の Zig から Rust への書き換え
workflows による大規模ポート
Bun は dynamic workflows を使って Zig から Rust へ書き換えられた。タスクを callsite、失敗するテスト、モジュールといった操作対象の系列に分解するのが鍵になる。各修正のために worktree でサブエージェントを起こして直し、別エージェントが敵対的にレビューしてマージする。リソースを大量消費するコマンドを使わないよう指示することで、並列度を最大化しつつマシンのリソースを枯渇させずに済む。
使うときのコツと、使うべきでないとき
詳細なプロンプトほど良い結果が出る。上で挙げたパターン名を明示的に指示するのが効く。ワークフローは大きなタスク専用ではなく、「quick workflow を使って」と頼めば、ある前提に対する軽い敵対的レビューのような小さな用途にも使える。
/loop と /goal の併用： triage、research、verification のように繰り返せるワークフローは、定期実行する /loop と、ハードな完了要件を設定する /goal と組み合わせる。
トークン予算： 「use 10k tokens」のように予算を指定すると、タスクが使うトークンの上限を設定できる。
保存と共有： ワークフローメニューで s を押すと保存できる。~/.claude/workflows に置くか、スキルとして配布する。スキル経由で配布する場合は、ワークフローを「そのまま実行するスクリプト」ではなく「テンプレート」として扱うよう促すと、柔軟性が高まる。
使うべきでないとき
- ワークフローはまだ新しく、ベストプラクティスは発展途上。あらゆるタスクに必要なわけではない。
- 多数のエージェントを spawn するため、トークンを大幅に消費しうる。
- 通常のコーディングタスクでは「本当に追加の計算資源が必要か」を自問する。たとえば大半の伝統的なコーディングタスクに、5 人のレビューパネルは要らない。
まとめ
Dynamic Workflows は、Claude が自分でハーネスを書いて複数のエージェントをオーケストレーションできるようにする仕組みだ。鍵は「プランをコードに移す」点にあり、ループ・分岐・中間結果をスクリプトが保持することで、単一コンテキストの失敗モード（agentic laziness、self-preferential bias、goal drift）を構造的に抑え込む。
Classify-and-act、Fan-out-and-synthesize、Adversarial verification、Generate-and-filter、Tournament、Loop until done という 6 つのパターンを組み合わせることで、コーディングから研究、検証、トリアージ、ポストモーテムまで幅広いタスクに適用できる。価値があるのは「量産」ではなく「再現可能な品質パターン」をコードとして codify できる点だ。
一方でトークン消費は大きく、ベストプラクティスもこれからの領域だ。まずはスコープを絞ったタスクから、創造的に試していくのがよいだろう。