タスクごとにハーネスを
生成するエージェント運用

01 — 何が発表されたか

Claude Code 内の「動的ワークフロー」

claimAnthropic の Thariq Shihipar（@trq212）が、Claude Opus 4.8 と同じタイミングで発表した機能。中核アイデアは、Claude Code が特定タスクに合わせた JavaScript のハーネス／ワークフローを動的に生成できること。

interpret従来のサブエージェントは「あらかじめ決めた役割を呼ぶ」静的構成だったのに対し、動的ワークフローは制御フロー自体を Claude がコードとして書き起こす点が違う。分岐・ループ・ファンアウトといったオーケストレーションを、自然言語の指示からプログラムに落とす。

02 — なぜ重要か

対処する3つの失敗モード

claim出典は、長文脈の単一エージェントが陥りやすい次の3つを、動的ワークフローが狙って緩和すると説明している。

03 — 仕組み

ワークフロー・ランタイムの特徴

claimワークフローは、サブエージェントを生成・協調させるための専用関数を持つ JavaScript ファイル。出典が挙げる主な性質は次のとおり。

• claim素の JS が使える：JSON / Math / Array など標準機能が利用可能。
• claimエージェント単位でモデル選択：サブエージェントごとに異なるモデルを割り当てられる（知能ルーティング）。
• claim隔離 worktree：エージェントを独立した git worktree 内で走らせられる。
• claim再開可能：中断してもワークフローをレジュームできる。
• claim保存・共有・バージョン管理：JS ファイルとして保存し、再利用・共有できる。

// interpret: 出典の説明から起こした擬似コード。
// 実際の関数名・シグネチャは出典で確定していない。
const theories = await spawn({
  model: "opus",           // エージェント単位でモデル選択
  worktree: true,            // 隔離 worktree で実行
  goal: "flaky test の再現と仮説生成",
});

// fan-out: 仮説ごとに敵対的検証を並列実行
const results = await Promise.all(
  theories.map(t => verify(t, { adversarial: true }))
);

// loop until done: 1つでも通るまで止めない
while (!results.some(r => r.passed)) { /* 続行 */ }

04 — パターン

よく使われる5つの型

claim出典が挙げる代表的なオーケストレーション・パターン。多くは組み合わせて使う。

05 — 実用ユースケース

効きどころ

claim出典が「強いユースケース」として挙げる領域。共通するのは規模・検証・探索のいずれかでオーバーヘッドが正当化される点。

• 大規模な移行・リファクタ：本番事例として Bun の Zig→Rust 書き換えが言及された。unknown 詳細未確認
• 深掘り調査・インシデントの根本原因分析：例：過去6か月の Slack #incidents から、未起票の再発原因を掘る。
• 主張・事実の高確度検証：ブログ草稿の技術的主張をコードベースに突き合わせて1つずつ検証。
• 大量集合のソート／ランキング：履歴書・サポートチケット・バグを重要度で並べ替え、上位を二重チェック。
• 履歴からのルール抽出：過去セッションで繰り返す修正を CLAUDE.md ルールへ。

06 — プロンプト集

プロンプト・クックブック

fact出典の記事に例示されたプロンプト（英語原文）と、その日本語訳。原文は引用、訳は本レポートによる。

07 — コスト・リスク境界

使わないほうがよい場面

claim出典は「万能ではない」と明確に述べている。オーバーヘッドが見合わない使い方への注意。

• claimルーチンなコーディングには過剰：多くの定型作業はこのオーバーヘッドを必要としない。
• claimトークン浪費に注意：「このタスクは本当に追加計算が必要か？」を自問し、明示的な予算（例「10kトークンで」）を設定する。
• claim初回はプランを確認：生成された計画を最初の数回はレビューする。
• claimエンタープライズ既定無効の可能性：プランによっては既定で無効化されている場合がある。

08 — Hermes / ローカル運用への示唆

自前ワークフローとの接続

interpret以下は本レポートによる解釈で、出典が Hermes に言及しているわけではない。Hermes 側の既存サブエージェント運用への落とし込みとして。

• interpret既存の skill/サブエージェント資産を活かせる：保存ワークフローは ~/.claude/workflows や skill としてパッケージ化できるため、Hermes のレポート生成系（本サイトの HTML レポート生成など）も「保存済みワークフロー」として再利用しやすい。
• interpret検証フェーズを別文脈に切り出す：生成と検証を同一エージェントで回さず、敵対的検証エージェントを別 worktree・別モデルで噛ませると、自己選好バイアスを下げられる。
• interpret予算を運用既定に：Hermes の自動実行では「明示的トークン予算＋初回プラン確認」を標準ガードレールに据えるのが安全。
• unknown実 API の安定性：関数シグネチャや課金単位が固まる前に深く依存すると、後で書き換えコストが出る恐れ。初期は薄いラッパー越しに使うのが無難。

09 — 出典と限界

ソースと確度の注記

• fact一次ソース：Anthropic の Thariq Shihipar（@trq212）による X 投稿。Claude Opus 4.8 と同時に動的ワークフローを紹介。
• unknown取得方法の限界：本レポートは Grok ベースの x_search による要約に基づく。公式 API（xurl）での網羅的取得は行っていない。直接引用以外の細部は「出典の主張（claim）」として扱うべき。
• unknown未確定事項：正確な API（関数名・並列度・課金単位）、Bun の Zig→Rust 事例の詳細、GA 状況やプラン別の既定設定。
• interpret解釈の所在：「制御レイヤーをプログラムする」という枠組みや Hermes への示唆は、本レポートによる解釈であり出典の文言ではない。