s16: Workflow Runtime — オーケストレーションをコードに書く

English · 中文 · 日本語

s15 → s16 → s17

計画をチャットの中だけに置かない。 順番はスクリプトが持ち、一歩ごとの判断はモデルが持つ。

Harness 層: オーケストレーション — 単一 agent ループの上で、マルチ agent スクリプトを走らせる。

問題

あなたはすでに、ひとつのループの中でモデルにファイルを読ませ、コードを直し、エラーを見させることができます。ところが仕事によっては、順番が最初から分かっているものがあります。次元ごとにレビューし、次に意地悪な検証、最後にまとめる——という具合です。その順番をチャットの記憶にだけ預けていると、モデルは途中で「完了」と言い、自分の宿題を甘く採点し、圧縮を何度か経ると「X を触るな」さえ消えます。

柔らかい会話は、並列も、結果の形の安定も、落ちてからの再開も支えきれません。もっとおしゃべりの上手なモデルが欲しいのではありません。書き下ろされたオーケストレーションが欲しいのです。

解決策

  あなたの会話 ──► Workflow(...) ──► 結果が一条で戻る
                    │
                    ▼
            スクリプト: agent / pipeline / parallel
                    │
                    ▼
              変数 + journal（半成品はここに。スレに詰め込まない）

ヘルパー（サブ agent）は相変わらず考えます。スクリプトがループ・分配・マージを持ちます。中間結果は変数と journal に置き、親の対話には入れません。

一言でいうと：オーケストレーションを「知性」から「構造」へ移す。

左：汎用の固定パイプライン。右：このタスク向けに裁断したオーケストレーション。

Claude Code には二つの扉があります。動的——モデルがこのタスク用に JS を書く（script / scriptPath）。保存済み——良いスクリプトを name + args で再実行。外側には SDK で先に書き切る静的オーケストレーションもあります。本章は Python の教材用 runtime（JS VM なし）です。考えは揃え、デモは「保存済み」の扉を使います。製品ではモデルはスクリプトを出せます——ここでは JS を走らせないだけです。

仕組み

1. 三つの動詞

  agent      一人のヘルパー、一件の仕事（schema で次に渡せる JSON も可）
  pipeline   各 item が自分の段階を進む（既定。同期しない）
  parallel   全部揃ってから先へ（バリア。多用しない）

失敗時：parallel のその枠は null。pipeline はその item を捨てます。艦隊は丸ごと沈みません。マージ前にフィルタしてください。

2. 再開はノートで。チャット記憶ではない

journal は agent() の呼び出し順で記帳します。再開は最長の未変更プレフィックスを再生し、最初の変更から先は全部ライブです。本番の JS runtime は Date.now() / Math.random() を禁じます——ノートがずれないように。教材スクリプトも決定的に書いてください。

  journal  [A] [B] [C] [D]
  再開      命中 命中 ✂ ライブ

3. サンプル一つ：Fanout + Adversarial

review-changes は「一つのパターン」ではありません。Fanout の中に Adversarial が入ります。次元ごとに pipeline(audit, verify)、検証で parallel に意地悪させ、残った finding だけ残します。

  correctness ── 監査 ── 検証 ──┐
  security    ── 監査 ── 検証 ──┤── confirmed
  performance ── 監査 ── 検証 ──┤
  style       ── 監査 ── 検証 ──┘

# code.py 抜粋 — 形だけ見ればよい
async def sample_workflow(ctx, args):
    ctx.phase("Review")
    results = await ctx.pipeline(DIMENSIONS, audit, verify)
    confirmed = [f for r in results if r for f in r["confirmed"]]
    return {"confirmed": confirmed}

艦隊は早逃げできず、著者は自分の審判にならず、トポロジも疲れたチャットのたびに書き換わりません。

よくある六つの形（パターン庫）

パターン	人の言葉	原語のスケッチ
Classify-And-Act	仕分けしてから適任へ	`agent` → 分岐 → `agent`
Fanout-And-Synthesize	分けてやり、またまとめる	`pipeline` / `parallel` → 統合
Adversarial Verification	狐に鶏小屋を採点させない	産出 → `parallel(verify)` → フィルタ
Generate-And-Filter	まず多く作り、それから篩	`parallel(gens)` → フィルタ
Tournament	一対一で優勝を決める	審判 `agent`
Loop Until Done	「まだ新しい？」なら続ける	`while` + 停止 + `budget`

review-changes ≈ Fanout + Adversarial。調査系はよく分配 → フィルタ → 検証 → 統合と積みます。

動的 / 保存済み / 静的と公式原語図

# 教材スケッチ
Workflow({ "name": "review-changes", "args": { "changes": "..." } })
# Claude Code はさらに: script | scriptPath | resumeFromRunId

信頼できない入力：読み書きを隔離

チケットを読む agent が、同時に PR を開ける鍵を持ってはいけません。読み手は読むだけ → 要約。信頼側は要約だけ見て動きます。

  バックログ → [隔離: 読 / 重複除去 / 要約] → [信頼: 実行]

計画を握るのは誰か。s06 は一回きりの委譲、s13 はメール箱つきの仲間、s15 は単一ループのチャット、s16 はスクリプト + journal、s17 は入り口で「全体は終わったか」と聞きます。普通の数ファイルの修正なら s15 か一つの s06 で足りることが多い。Workflow は token と調整のコストが要ります——構造が一度の会話より長生きしなければならないときだけ手を伸ばしてください。

試してみる

python s16_workflow_runtime/code.py demo
python s16_workflow_runtime/code.py resume

一回目は Review → Verify を見てください。同じ run の二回目は cached がほとんど（理想は agents=0 tokens=0）。完全なホストに載せるなら引数なしで code.py を。

s15 はあいかわらずそのループです。ここに増えるのは Workflow ツールだけ。s17 は別の問いをします。もう止まっていい？

7.3 KiB Raw Blame History Unescape Escape

s16: Workflow Runtime — オーケストレーションをコードに書く

問題

解決策

仕組み

試してみる

7.3 KiB

Raw Blame History