以下が、提供されたガイドラインに従って日本語に翻訳したテキストです。
ほとんどの Claude Code ユーザーは、まだ手作業でワークフローを書いています。プロンプトをつなぎ合わせ、出力をコピーし、次のプロンプトに貼り付け、間違いを修正し、それを繰り返しています。
10 人中 9 人の開発者は、Dynamic Workflows が 2 週間前にリリースされたにもかかわらず、一度も試したことがありません。
彼らは 1 つのワークフローで済むところを、50 のプロンプトを書いています。以下は、移行、調査、ソート、根本原因分析、トリアージ、評価のための 14 ステップのロードマップ と、Anthropic 自身のエンジニアが実際に使用する 6 つのパターン です。
最新の AI 情報を受け取るには、私の Substack をフォローしてください：
Dynamic Workflows は、2026 年 5 月 28 日に Claude Code でリリースされました。デフォルトの Claude Code ハーネスはコーディング用に構築されており、ほとんどのコーディングタスクでは問題なく機能します。しかし、1 つのコンテキストウィンドウでは対応が難しくなる作業のクラスがあります。それは、長時間実行、超並列処理、高度に構造化された処理、または敵対的な処理です。
このような場合、Anthropic はこれまで独自のカスタムハーネス（Research、Code Review、エージェントチーム）を構築していました。Dynamic Workflows を使用すると、Claude がそのハーネスをタスクに合わせて、JavaScript でその場で自動生成します。
14 ステップ。6 つのパターン。50 のプロンプトではなく、1 つのワークフロー。
パート 1 · メンタルモデル
01. ワークフローとは、Claude が書くハーネスです。
デフォルトの Claude Code ハーネスでは、Claude が同じコンテキストウィンドウ内で計画と実行を行います。ほとんどのコーディング作業ではこれで十分ですが、長時間実行、並列処理、または敵対的な作業では機能しなくなります。
Dynamic Workflow とは、Claude がタスクのために独自のカスタムハーネスを書くことです。これは、サブエージェントを生成し調整するいくつかの特別な関数と、それらの間を流れるデータを処理するための標準的な JavaScript（Math、JSON、Array）を含む JavaScript ファイルです。
これにより、デフォルトのハーネスでは実現できない 3 つのことが可能になります。
- エージェントごとの分離。 各サブエージェントは、1 つの焦点を絞った目標を持つ独自のコンテキストウィンドウを取得します。相互汚染はありません。
- エージェントごとのモデル選択。 ワークフローは、各サブエージェントが使用するモデルを選択します。難しい推論には Opus、安価な探索には Haiku、中間には Sonnet を使用します。
- エージェントごとの分離レベル。 Worktree（分離された git チェックアウト）または remote（チェックアウトなし）。ワークフローが各エージェントに必要なものを決定します。
開始するには、Claude に直接依頼するか（「〜するワークフローを作成して」）、トリガーワード「ultracode」を使用します。ワークフローが中断された場合（ユーザー操作、ターミナルの終了）、セッションを再開すると中断したところから再開されます。
02. ワークフローが解決する 3 つの障害モード。
ワークフローが適切なツールであることを知るには、それが何を修正するかを理解する必要があります。Claude が複雑なタスクを 1 つのコンテキストウィンドウで長時間処理するほど、次の 3 つの特定の障害モードの影響を受けやすくなります（Anthropic のローンチ記事で直接言及されています）。
- エージェントの怠惰 - Claude は複雑で複数部分からなるタスクを完了する前に停止し、部分的な進捗で完了したと宣言します。セキュリティレビューの 50 項目中 20 項目に対処し、残りは「対応済み」とします。
- 自己優先バイアス - Claude は、自分の結果をルーブリックに照らして検証または評価するよう求められたとき、自分の結果を優先します。利害関係のある検証者は、公平な検証者にはなれません。
- 目標の逸脱 - 特に圧縮後、多くのターンを経るうちに元の目的への忠実度が徐々に失われること。要約の各ステップは情報を損失します。「X をしないでください」という制約は、47 ターン目にはいつの間にか消えています。
ワークフローは、これら 3 つすべてを構造的に解決します。つまり、独自のコンテキスト、焦点を絞った目標、分離された状態を持つ、別々の Claude を使用します。タスクがこれらのパターンのいずれかに該当する場合、それがワークフローに頼るべきサインです。
03. 静的ワークフローと動的ワークフロー。
Claude Agent SDK または claude -p を使用して、複数の Claude Code インスタンスを調整する静的ワークフローをすでに構築したことがあるかもしれません。
- 静的ワークフローは汎用的です。すべてのエッジケースを処理するために一度記述されます。機能しますが、保守的である必要があります。
- Dynamic Workflows は異なります。Claude がこのタスクのためにこのワークフローを記述します。ハーネスはオーダーメイドです。以下は、同じ質問を両方の方法で処理したものです。
動的バージョンが勝る理由は、検索ステップではありません。どちらも検索できるからです。
それは、ワークフローがコンテキストに合わせて自身を形成できるからです。つまり、請求コードを読み、各機能を実際の新しいプロバイダーのドキュメントと照合し、取引量で価格を計算し、自身の生成中の回答に対して「移行しない理由」を敵対的に検証するパスを実行します。
静的ハーネスは、あなたのコードの存在を知らないため、これを行うことはできません。
04. コア API。agent()、parallel()、pipeline()。
3 つの関数がワークフローのほとんどの作業を実行します。これらを知っていれば、Claude があなたのために書く任意のワークフローを読み、特定の形状を望むときに Claude を微調整するのに十分です。
parallel() はバリアです。処理を分散し、すべてが返されるのを待ってから戻ります。pipeline() はストリーミングです。各アイテムはすべてのステージを独立して通過します。
質問に基づいて選択します：次のことを行う前に、すべての結果が必要ですか？ はい → parallel。いいえ → pipeline（より安価で、全体的に高速）。
05. 分類して実行。作業を実行する前にルーティングする。
分類エージェントがタスクの種類を決定し、ワークフローはその回答に基づいて異なるエージェントまたは動作にルーティングします。または、分類器が最後に実行され、生の出力を次のステップのためにバケットに分類します。
このパターンが効果を発揮するのは以下の場合です。
- タスクが異種混合である場合。つまり、異なるサブタイプには異なる処理が必要です。
- 複雑さが要求される場合にのみ、高価なモデルを使用したい場合（分類器は安価なモデルで実行し、必要な場合のみ Opus にルーティング）。
- 作業の分解自体が自明ではなく、モデルが形状を決定する恩恵を受ける場合。
例： 「認証モジュールがどのように機能するか説明してください。」分類サブエージェントが最初にコードベースを読み、複雑さを見積もり、実際の説明タスクを、10 ファイルのモジュールには Sonnet に、100 ファイルのモジュールには Opus にルーティングします。作業が理解された後に、タスクに適したモデルが決定されます。
06. ファンアウトして統合。多数の小さなステップ、1 つのマージされた結果。
タスクを多数の小さなステップに分割します。各ステップでエージェントを並列実行します。結果を 1 つの回答に統合します。
統合ステップはバリアです。すべてのファンアウトエージェントを待ち、それらの構造化された出力をマージします。
このパターンが実際に支配的である理由：単一コンテキスト作業の「一度にやりすぎ」という失敗を解決するからです。各サブエージェントは自分の部分だけを見ます。オーケストレーターは 50 の無関係な詳細に気を取られることはありません。
各ステップは、相互汚染を防ぐために、独自のクリーンなウィンドウの恩恵を受けます。
以下の場合に使用します。
- 明確に列挙可能な作業項目のリストがある場合（50 ファイル、200 エンドポイント、100 レビュー）。
- 各項目が独立している場合。つまり、どの項目も別の項目の出力を必要としません。
- 最後に、部分的なレポートの山ではなく、1 つの統合された回答が必要な場合。
1// ファンアウト：ファイルごとに 1 エージェント。バリア：すべてを待つ。2const reviews = await parallel(3 files.map(file => () => agent(4 `Review ${file} for security issues`,5 { model: "haiku", schema: IssueList }6 ))7)89// 統合：1 つの Opus エージェントがすべてをマージする。10const report = await agent(11 `Merge these reviews into one prioritized report:\n${JSON.stringify(reviews)}`,12 { model: "opus" }13)
07. 敵対的検証
これは、自己優先バイアスに対する構造的な修正です。生成された各エージェントに対して、その出力をルーブリックに照らして敵対的に検証する、別の生成されたエージェントを実行します。検証者は元の作業を見たことがないため、それを優先することはできません。
このパターンが最も重要なのは以下の場合です。
- 主張のチェック - レポート内のすべての事実文は、元のソースと照合する独自の検証サブエージェントを取得します。
- コードレビュー - 作成者エージェントが修正を書き、レビューアーエージェント（別のコンテキスト）がそれをレビューします。同じ Claude が自分自身を判断することは決してありません。
- 品質ゲート - アーティファクトが出荷される前に、敵対者がそれに対する最も弱いケースを見つけようとします。敵対者が見つけられなければ、出荷します。
ペアリングのルール： 検証者は、ルーブリックとアーティファクトのみを知っているべきであり、誰が作成したかは知っているべきではありません。そうしないと、プロンプトのヒントを通じて自己優先が忍び寄ります。
08. 生成してフィルタリング。
トピックに関する多数のアイデアを生成し、ルーブリックまたは検証によってフィルタリングします。重複を排除します。最高品質でテスト済みのアイデアのみを返します。
このパターンが効果を発揮する場面。
- ブレインストーミング - 30 の製品名を生成し、検証者が決まり文句、商標の競合、弱い発音を排除します。3 つだけが表示されます。
- 仮説生成 - 問題に対する 5 つの異なるアプローチを生成し、それぞれが制約に照らしてスコアリングされます。勝者はそれを獲得しました。
- ソリューション設計 - 問題に対する 5 つの異なるアプローチを生成し、それぞれが制約に照らしてスコアリングされます。勝者はそれを獲得しました。
Claude に「最良の答え」を求めるのとは逆です。最良の答えを求めると、Claude は早期にコミットします。生成してフィルタリングでは、すべてのオプションが挑戦された後、Claude は遅くコミットします。
09. トーナメント。ペアワイズ比較は絶対スコアリングより優れています。
作業を分割する代わりに、エージェントに競わせます。異なるアプローチを使用して同じタスクを試行する N 個のエージェントを生成し、1 つが勝つまでペアワイズ方式で結果を評価します。
比較判断は、絶対スコアリングよりも信頼性が高くなります。特に、好みに基づく作業の場合です。
これがスコアでソートするより優れている理由： 1 つのプロンプトで 1,000 項目をソートしようとすると、2 つの面で失敗します。品質が低下し、コンテキストに収まりません。トーナメントは、ブラケットを新しいエージェントに分割し、各エージェントは 2 つの項目のみを比較します。
ブラケット自体は、コンテキスト内ではなく、決定論的なループコード内に存在します。各比較は高速で、公平で、分離されています。同じ考え方は、好みに基づくランキング（デザインの選択、候補者の選定、コンテンツの優先順位付け）にも有効です。
10. 完了するまでループ。
作業量が不明なタスクの場合、固定回数のパスを実行する代わりに、停止条件が満たされるまで（新しい発見がない、ログにエラーがもうない、理論が検証された）エージェントを生成するループを実行します。
このパターンは、「実際に完了するまで続ける」ための答えです。
- 不安定なテストのデバッグ - 再現し、理論を形成し、テストし、1 つの理論が成立するまで。
- バグハンティング - 完全なパスがゼロを返すまで、バグを見つけ続けます。
- パターンの発掘 - クラスタリングし、ルールを特定し、新しいクラスターが現れなくなるまで。
このパターンを /goal と組み合わせて厳格な完了要件を設定し（「1 つの理論が機能するまで停止しない」）、ワークフロー自体を定期的なスケジュールで実行したい場合は /loop と組み合わせます。
ブラケットと停止条件はコード内に存在し、アクティブなイテレーションのみがコンテキスト内に残ります。
11. 実際のユースケースのためにパターンを構成する。1 つのワークフロー、複数のパターン。
6 つのパターンが単独で現れることはほとんどありません。実際のワークフローは、2〜4 つのパターンを構成します。以下のマトリックスは、Anthropic のローンチ記事の各ユースケースと、それが使用する傾向があるパターンをペアにしたものです。
- 移行とリファクタリング。 ファンアウト（worktree 内の呼び出しサイト/失敗テストごとに 1 エージェント）→ 敵対的検証（別のエージェントが各修正をレビュー）→ 完了するまでループ。これは Anthropic が Bun を Zig から Rust に書き換えるために使用したパターンです。
- ディープリサーチ（/deep-research スキル）。ファンアウト（並列 Web 検索）→ 敵対的検証（各主張が独立して検証される）→ 統合（1 つの引用付きレポート）。
- ドラフトのディープ検証。 すべての事実文を特定する（1 エージェント）→ ファンアウト（主張ごとに 1 検証者、各エージェントはソースと照合）→ メタ検証者（検証者のソースが高品質であることを確認）。
- 1,000 以上の項目のソート。 トーナメント（ステップ 5-9）- ペアワイズ比較、バケットランク、またはブラケット。比較判断、絶対スコアリングは決して使用しません。
- メモリとルールの遵守。 ルールごとの検証者（ファンアウト）→ 懐疑論者のペルソナがルール自体をレビューし、誤検出を回避します。
- 根本原因調査。 無関係な証拠から理論を生成する（異なるエージェントがログ、ファイル、データを読む）→ 各理論に対する検証者と反論者のパネル → 1 つが残るまでループ。
- 大規模なトリアージ。 分類して実行 → 既存のチケットと重複排除 → 修正を試みるかエスカレーション。継続的なトリアージのために
/loopと組み合わせます。 - 探索と好み（デザイン、命名、UI の選択）。生成してフィルタリング（5〜20 オプション）→ ルーブリックを使用したトーナメント → ランク付けまたは選択。
- 軽量評価。 候補を worktree で実行 → 比較エージェントがルーブリックに照らして採点 → 改良して再採点。ランキングではなく採点用ですが、トーナメントと同じ形状です。
これらを内面化する正しい方法：現在のタスクがどの障害モードで失敗しているかを特定し、それを構造的に防止するパターンを選択することです。
逸脱 → ファンアウト。自己優先 → 敵対的検証。未確定 → 完了するまでループ。採点が難しい → トーナメント。
12. /goal、/loop、トークンバジェットと組み合わせる。
ワークフローは高コストになる可能性があります。3 つのコントロールにより、「クールだがコストがかかる」ものから「無人で実行できるツール」に変わります。
- /goal は厳格な完了要件を設定します。ループパターンと組み合わせます：「1 つの理論が機能するまで停止しない。」 /goal がない場合、ワークフローはソフトな完了ポイントで停止します。/goal がある場合、実際の終了条件が満たされるまで反復します。
- /loop はワークフロー全体を定期的なスケジュールで実行します。継続的に実行したいワークフロー（トリアージ、毎週のリサーチアップデート、定期的な検証）に使用します。
- 明示的なトークンバジェット。 プロンプトで Claude に指示します：「10k トークンを使用してください。」 これにより、ワークフロー実行に上限が設定されます。上限がないと、野心的なワークフローは予想の 5〜10 倍のトークンに膨れ上がる可能性があります。
1> ultracode quick adversarial review of this assumption:2 "moving to Postgres eliminates our shard rebalancing."3 Use 5k tokens. /goal don't stop until you have either4 a counterexample or three independent confirmations.
Claude Code チームの言葉を直接引用します：「ベストプラクティスはまだ発展途上です。Dynamic Workflows は多くの場合、より多くのトークンを使用するため、いつ、どのように使用するかを慎重に検討してください。」 ほとんどの従来のコーディングタスクは、5 人のレビュー担当者のパネルを必要としません。
自問してみてください：このタスクは本当に、より多くの計算リソースを必要としますか？通常の Claude Code セッションで 5 分で完了するのであれば、ワークフローは必要ありません。
13. 信頼できない入力には隔離パターンを使用する。
信頼できない公開コンテンツ（サポートチケット、バグレポート、ユーザーフィードバック、スクレイピングデータ）を読み取るワークフローは、そのコンテンツにプロンプトインジェクションが含まれている可能性があると想定する必要があります。
修正方法：隔離。信頼できないコンテンツを読み取るエージェントが、特権の高いアクションを実行するのを禁止します。生のコンテンツに一切触れていない別のエージェントが、アクションを実行します。
ユーザーが送信したコンテンツ（サポートチケット、バグレポート、カスタマーフィードバック、ソーシャルメディア）を処理するワークフロー、公開 Web ページをスクレイピングするワークフロー、またはサードパーティ API からの出力に対して実行するワークフローはすべて該当します。
入力があなた自身または信頼できるチームメイトによって書かれたものでない場合は、隔離してください。 30 行の読み取り専用エージェントはほとんどコストがかからず、プロンプトインジェクションリスクのクラス全体を排除します。
14. ワークフローを保存する。スキルとして出荷する。
ワークフローが機能したら、保存します。ワークフローメニューで s を押します。保存されたワークフローは ~/.claude/workflows に保存されます。そこから 2 つのパスがあります。
- ローカルに保持する - 自分のプロジェクト間で再利用します。
- スキルとして出荷する - JavaScript ファイルをスキルフォルダ内にバンドルし、
SKILL.mdで参照します。スキルをインストールした人は誰でも同じワークフローを実行できます。
知っておく価値のある実用的なニュアンスが 1 つあります。ワークフローをスキルにパッケージ化する場合、Claude に、ワークフローをそのまま実行するスクリプトではなく、テンプレートとして扱うようにプロンプトで指示します。
これにより、全体的な構造を維持しながら、Claude がワークフローの形状を特定のタスクに適応させる余地が残ります。これは、「ディープ検証」や「トリアージ」など、ユースケースごとに柔軟に対応する必要があるワークフローに特に役立ちます。
ワークフローでトークンを無駄にする間違い
- 通常の Claude Code セッションで十分な場合にワークフローに頼る。 ほとんどの従来のコーディングタスクは、5 人のレビュー担当者のパネルを必要としません。
- トークンバジェットがない。 明示的な上限がないと、野心的なワークフローは予想の 5〜10 倍に膨れ上がります。
- 1 つのエージェントが作業と検証の両方を行う。 自己優先バイアスにより、検証者が作業者を優先するようになります。これらは分離されている必要があります。
- parallel() と pipeline() を交換可能として扱う。 バリアは重要です。parallel はすべてを待ち、pipeline はストリーミングします。
- ループパターンで /goal をスキップする。 ワークフローは最初のソフトな完了ポイントで早期に停止します。/goal はハードな完了を強制します。
- 信頼できないコンテンツがアクターに到達するのを許可する。 ユーザーが送信したものを処理する場合、隔離はオプションではありません。
- 絶対スコアでソートする。 比較判断の方が信頼性が高くなります。トーナメントを使用してください。
- 機能するワークフローを決して保存しない。 毎週同じ形状を再プロンプトする。
sで保存し、スキルとして出荷します。
