バックグラウンドワーカーを指示

このガイドでは、ワーカーとしてではなくディレクターとして会話を進める方法を説明します。セッションが読み取りと検証を行い、編集はバックグラウンドのエージェントが行います。

`/vibe` と入力すると何が変わるか

変わるのは 2 つあり、機構が強制するのは 1 つ目だけです。

セッション自身のツールが読み取り専用に落ち、さらに 5 つのワーカー動詞が使えるようになります。セッションがリポジトリに影響を与えられる唯一の経路はワーカー経由であり、何が起きたかを知る唯一の手段は、ワーカーが触れたファイルを読むことです。
信じるのではなく、読んで検証するよう指示されます。 ワーカーの報告は、それが何をしたかという主張であり、うまくいった証拠ではありません。

支えになっているのは 1 つ目のほうです。まだ grep や編集ができるディレクターは、負荷がかかると自分で作業をやってしまいます。それが、この仕組みが防ごうとしている失敗の形です。

/vibe migrate the auth module to the new session API

ワーカーはまっさらな状態で始まる

ワーカーはあなたの会話を見たことがなく、これからも見ることはありません。ブリーフがそのコンテキストのすべてです。

これがこのパターンを安く保つ理由であり — 20 体のワーカーがそれぞれディレクターの履歴を保持すれば、ディレクターのコンテキストの 20 倍のコストになる — 同時に、ブリーフを書くのを難しくしている唯一の点でもあります。「ではもう一方もやっておいて」は、ディレクターには完全な指示として読めますが、まっさらなセッションには何の意味も持ちません。

よいブリーフは、ファイル、コマンド、完了の定義を名指しします:

lib/features/auth/ 内の SessionStore.read(key) の呼び出しをすべて SessionStore.get(key) に置き換えてください。新しいメソッドは、古いメソッドが String? を返していたところで Future<String?> を返すため、呼び出し側には await が必要です。完了したら fvm flutter analyze lib/features/auth を実行し、修正できなかったエラーを報告してください。

5 つの動詞

動詞	動作
`vibe_spawn`	ブリーフを指定してワーカーを開始します。すぐに戻ります。
`vibe_list`	全員のティア、ステータス、経過時間、最後の結果
`vibe_send`	ターンを終えたワーカーへの追加のターン
`vibe_wait`	いずれかのワーカーが決着するまでブロックします
`vibe_kill`	1 つを停止します

スポーンは設計上非同期です。スポーンごとにブロックするディレクターは、ワーカーを 1 体ずつ実行していることになり、自分でやっていたことをより遅くやっているだけです。vibe_wait は、特定の回答なしには本当に先へ進めない場合にのみ使ってください。

2 つのティア

ティア	用途
`fast`	明確な仕様がある機械的な作業 — 編集、名前変更、下書き、コマンドの実行
`good`	設計、判断、または `fast` ワーカーが生み出したもののレビュー

よくある形は、fast ワーカーを独立したファイル群にファンアウトし、その後に good ワーカーを 1 体スポーンして、彼らが全体として何をしたかをレビューさせるというものです。

検証

ここが、このパターンに価値があるかどうかを決める部分です。

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

次に、ワーカーが名指ししたファイルを実際に読みます。ディレクターには read、search、lsp、ast_grep があります。それらを残しておく理由は、まさにそこにあります。報告を鵜呑みにするディレクターは、他のエージェントの楽観を要約するだけの存在です。

ワーカーを一巡させた後に lsp(action: "diagnostics", file: "*") を実行するのが、通常は最も速い単一のチェックです。

ワーカーが本筋を見失ったとき

停止して、ブリーフを書き直します。新しく修正されたブリーフのほうが、議論よりも安く済みます。また、vibe_send が機能するのは、すでにターンを終えたワーカーに対してだけです。

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

制限

同時実行ワーカーは 8 体です。 これは支出の上限であり、技術的な制限ではありません。各ワーカーは完全なモデルセッションであり、20 体をファンアウトしたディレクターは、それらすべてが何をしているかを追えなくなっています。
モードを超えて生き残るワーカーはありません。 実行が終わると、そのすべてが停止され、トランスクリプトに何体だったかが記録されます。会話が次に進んだ後もファイルを編集し続けるバックグラウンドエージェントは、この仕組みが絶対に起こしてはならない唯一の失敗です。
ワーカーの中身は普通のサブエージェントです。 深さの上限も、ガードレールポリシーも、実行ログの子も同じです。vibe が変えるのは誰が彼らを駆動するかであり、彼らに許されていることではありません — そのため、ワーカーの書き込みと exec の呼び出しには、引き続き承認プロンプトが表示されます。

使わないほうがよい場合

vibe モードは、独立したブリーフに分解できる作業に向いています。次のステップが前のステップの出力に依存するなら、それはパイプラインまたはオーケストレーションを説明しています。どちらも依存関係を適切に表現し、ディレクターに vibe_wait でそれを模擬させることはありません。