タスクごとの専用ハーネス: Claude Codeの動的ワークフロー

• 動的ワークフロー は、Claude Codeがタスクに合わせた ハーネス(harness) をその場で自ら作成する機能で、これまで別途構築していたカスタムハーネスをコード内部でネイティブに処理
• JavaScriptファイルを実行して サブエージェント(subagents) を生成・調整し、各エージェントが使うモデルや worktree の分離有無まで選択可能
• 単一のコンテキストウィンドウで発生する agentic laziness, self-preferential bias, goal drift のような失敗モードを、分離されたコンテキストで構造的に防止
• マイグレーション、ディープリサーチ、ソート、トリアージ、根本原因調査 など、コーディング以外の非技術タスクにも活用可能
• トークン消費が多いためすべての作業に必要なわけではないが、創造的な活用 によって Claude Code を新しい形で拡張する出発点

---

動的ワークフローの概要

• 先週、Claude Codeで 動的ワークフロー を公開。Claudeがタスクに合わせて ハーネス をその場で作成可能に
• 標準の Claude Code ハーネスはコーディング向けに作られているが、多くのタスクはコーディング作業と似ているため、他タイプの作業にも有用
• Research, security analysis, agent teams, Code Review などは、これまで Claude Code 上に別個のカスタムハーネスを構築して最高性能を確保してきた
• ワークフローはこうした問題を Claude Code 内でネイティブに解決し、他者との共有・再利用 もサポート
• ベストプラクティスはまだ発展途上であり、トークン消費も大きいため、使うタイミングと方法は慎重に考える必要がある

例示プロンプト

• "このテストは50回の実行中1回程度失敗する可能性があります。これを再現できるワークフローを構築してください。race condition について複数の仮説を立て、証拠に基づいて妥当な仮説が得られるまで続けてください。"
• "ワークフローを使って最近の50セッションを見直し、繰り返し修正している箇所を見つけ、そのうち反復している部分を CLAUDE.md のルールに変換してください"
• "ワークフローを使って過去6か月間の Slack の #incidents を分析し、誰もチケットを提出していない反復的な根本原因を見つけてください。"
• "私の事業計画書を使って、投資家、顧客、競合の観点から複数の担当者が綿密に分析するワークフローを実行してください。"
• "ここに履歴書80件が入ったフォルダがあります。ワークフローを使ってバックエンド職に適した履歴書を順位付けし、上位10件をもう一度確認してください。AskUserQuestion ツールを使って、評価基準表に従って私に面接してください。"
• "この CLI ツールに名前を付ける必要があります。ワークフローを使って複数の候補をブレインストーミングし、トーナメント方式で上位3つを選んでください。"
• "ワークフローを使って、あらゆる場所で User モデルの名前を Account に変更してください。"
• "私のブログ記事の下書きを綿密にレビューし、ワークフローを使ってコードベースとすべての技術的主張を照合してください。誤った内容を公開したくありません。"

動的ワークフローの仕組み

• サブエージェント の生成・調整を支援するいくつかの特殊関数を含む JavaScriptファイル を実行
• JSON、Math、Array などの標準 JavaScript 関数も含み、データ処理をサポート
• エージェントが使う モデル選択 とサブエージェントの worktree 分離有無 を決定可能で、必要な知能レベルと分離レベルを Claude が選択
• ユーザー操作やターミナル終了でワークフローが中断されても、セッション再開時に中断地点から続行

なぜ動的ワークフローが必要か

• 標準ハーネスは 単一コンテキストウィンドウ で計画と実行を同時に行うため、多くのコーディング作業には効果的だが、長期・大規模並列・高度に構造化された敵対的タスクでは限界がある
• 複雑なタスクを1つのコンテキストで長く進めるほど、特定の失敗モードに弱くなる
  • Agentic laziness: 複雑な多段階タスクを完了前に打ち切り、部分完了のまま完了を宣言すること（例: セキュリティレビュー50項目中20項目しか処理しない）
  • Self-preferential bias: ルーブリックに照らした検証・判断で、自分の結果を好む傾向
  • Goal drift: 複数ターンにわたり元の目標への忠実さが徐々に失われること。特に compaction 後に起こりやすく、エッジケース要件や「Xしないこと」という制約が失われる
• 別々のコンテキストウィンドウと、集中・分離された目標を持つ複数の Claude を調整することで、これを防止

動的 vs 静的ワークフロー

• これまでは Claude Agent SDK や claude -p により、複数の Claude Code インスタンスを調整する 静的ワークフロー を作成できた
• 静的ワークフローはすべてのエッジケースに対応しなければならないため、一般により汎用的
• Claude Opus 4.8 と動的ワークフローにより、今では Claude がユースケースに合わせたカスタムハーネスを自ら書けるほど十分に賢くなった

動的ワークフローの活用パターン

• Claude にワークフロー生成を依頼するか、トリガーワード ultracode を使うことでワークフロー生成を保証
• Claude がワークフロー構築時に組み合わせて使う共通パターンが存在

• Classify-and-act

  • 分類エージェントがタスク種別を判断した後、タスクごとに異なるエージェント・動作へルーティングする、あるいは最後に分類器で出力を決定

• Fan-out-and-synthesize

  • タスクを小さな段階に分け、各段階でエージェントを実行してから結果を統合
  • 小さな段階が多数ある場合や、各段階がクリーンなコンテキストウィンドウの利点を受ける場合に有用で、相互干渉やクロスコンタミネーションを防止
  • synthesize 段階はバリアとして機能し、すべての fan-out エージェントを待った後、構造化された出力を1つに統合

• Adversarial verification

  • 生成された各エージェントごとに別のエージェントを実行し、出力をルーブリック・基準に照らして敵対的に検証

• Generate-and-filter

  • あるテーマについて多数のアイデアを生成し、その後ルーブリック・検証でフィルタリング、重複除去を行い、最高品質の検証済みアイデアのみを返す

• Tournament

  • タスクを分割する代わりにエージェント同士を競わせる。N個のエージェントが異なるアプローチで同じタスクに挑み、審査エージェントが pairwise 方式で勝者が出るまで判定

• Loop until done

  • 作業量が不確実な場合、固定回数の代わりに停止条件（新しい発見がない、ログエラーがない）が満たされるまでエージェントを繰り返し生成

活用事例

• ワークフローは非技術タスクでむしろより有用な場合がある

• マイグレーションとリファクタ

  • Bun はワークフローにより Zig から Rust へ再実装され、詳細は JarredのXスレッド で確認できる
  • callsites、失敗するテスト、モジュールなどの作業段階へ分解することが鍵
  • 各修正ごとに worktree 内でサブエージェントを生成し、別のエージェントが敵対的レビュー後にマージ
  • リソース集約的なコマンドを避けるよう指示し、マシン資源を枯渇させずに最大限の並列化を実現

• ディープリサーチ

  • 動的ワークフローを使う deep research skill (/deep-research) を公開。Web検索を fan-out し、ソースを取得し、主張を敵対的に検証し、引用付きレポートを統合
  • Web検索以外にも、Slack コンテキストを用いたステータスレポート作成、コードベースの深掘りによる機能動作の調査などに活用可能

• ディープ検証

  • レポート中のすべての事実主張を確認して出典付けするには、1つのエージェントがすべての事実主張を特定し、サブエージェントがそれぞれを詳細に確認するワークフローを生成
  • 検証エージェントは、ソースサブエージェントの出典品質も点検可能

• ソート

  • 定性的な評価基準で項目を並べ替える際に有用（例: バグの重大度順のサポートチケット）
  • 1000行超を1つのプロンプトでソートすると品質低下やコンテキスト超過が起こるため、代わりにトーナメント、pairwise 比較パイプライン、並列 bucket-rank 後のマージを活用
  • 比較判断(comparative judgment) は絶対スコアより信頼性が高く、各比較が別エージェントなので deterministic loop がブラケットを維持し、実行順序だけがコンテキストに残る

• メモリとルール順守

  • CLAUDE.md に入れても Claude が見落とすルールについては、ルール一覧を用意し、ルールごとに1つの検証エージェントで確認するワークフローを生成
  • 偽陽性を減らすため、ルールをレビューする skeptic ペルソナのサブエージェント を生成
  • 逆方向も可能で、最近のセッションやコードレビューコメントから繰り返し修正を掘り起こし、並列エージェントでクラスタリングし、各候補を敵対的に検証（「このルールは実際にミスを防げただろうか？」）した後、生き残ったルールを CLAUDE.md に洗練

• 根本原因調査

  • デバッグは複数の独立した仮説を立てて検証すると効果的だが、単一コンテキストウィンドウでは self-preferential bias が生じやすい
  • ワークフローは分離された証拠（ログ、ファイル、データ）ごとのエージェントで仮説を生成することで、これを構造的に防止し、各仮説は検証者・反証者パネルにかけられる
  • コード以外にも、営業（3月の売上低下の原因）、データエンジニアリング（パイプライン失敗の原因）などのポストモーテムにも活用

• 大規模トリアージ

  • 人手では処理しきれないサポートキュー、バグレポート、バックログ向けのトリアージワークフローが各項目を分類し、既存の追跡項目と重複排除し、対処（修正の試行または人間へのエスカレーション）を行う
  • 有用なパターンは quarantine で、信頼できない公開コンテンツを読むエージェントによる高権限行動を遮断し、情報処理担当エージェントに任せる
  • /loop と組み合わせて継続実行も可能

• 探索と嗜好

  • デザインやネーミングのように嗜好ベースで、かつルーブリックの利点を活かせる解決策探索に有用
  • 複数の解決策を探索させ、レビューエージェントに良い解決策の基準となるルーブリックを与え、レビューエージェントが基準を満たすと判断したら完了。トーナメントで並べ替え・選択も可能

• 評価(Evals)

  • worktree で別エージェントを生成し、比較エージェントでルーブリックに照らして採点することで軽量評価を実行。例: 作成した skill を特定基準で評価・改善

• モデル・知能ルーティング

  • タスクに応じてモデルを決める分類エージェントを生成し、多数のツール呼び出しを伴うタスクで事前調査により最適モデルを特定
  • 例: 「auth モジュールの動作説明」タスクに最適なモデルは auth モジュールのファイル数やコードベース形状により異なり、分類器が調査後、複雑度に応じて Sonnet・Opus にルーティング

使うべきでない場合

• ワークフローは新機能であり、大きな成果を出すユースケースは多いが、すべての作業に必要なわけではなく、トークンを大幅に余計に消費する可能性がある
• これまで試せなかった方法で Claude Code を押し広げる創造的な活用に向いている
• 一般的なコーディング作業では「本当にもっと多くの計算資源が必要か？」と自問すべきで、ほとんどの従来型コーディング作業に5人のレビュアーパネルは不要

動的ワークフロー構築のヒント

• プロンプティング

  • 前述の手法を使った詳細なプロンプティングが最良の結果を導く
  • 大規模タスク専用ではなく、"quick workflow" とプロンプトして前提条件への素早い敵対的レビューなども可能

• /goal および /loop との組み合わせ

  • トリアージ・リサーチ・検証のような反復可能ワークフローは /loop と組み合わせて定期実行し、/goal で厳格な完了要件を設定

• トークン使用予算

  • 明示的なトークン使用予算を設定することでタスクごとのトークン上限を指定でき、"use 10k tokens" のようなプロンプトで上限を設定

• 保存と共有

  • ワークフローメニューで "s" を押して保存し、~/.claude/workflows にチェックインするか skill として配布可能
  • skill として共有する場合は JavaScript ワークフローファイルを skill フォルダに入れて SKILL.md から参照し、柔軟性のため skill 内ワークフローをそのまま実行するスクリプトではなく テンプレート と見なすようプロンプトする

• 拡張の出発点

  • ワークフローは Claude Code を拡張する新しい方法であり、最適な活用法はこれからまだ多くが見つかる出発点