モジュール 5：Fable 5 時代 4 / 8
上級 S28 Workflow Quality Verification Patterns

オーケストレーション品質パターン

独立探索、敵対的検証、明示的な停止条件、監査可能な証拠を中心に、信頼できるマルチエージェント workflow を設計します。

2026年7月8日 15 分で読む
確認済み カリキュラム確認日: 2026年7月20日
Claude Code ≥ 2.1.154 公式情報 1 公式情報 2 公式情報 3

学ぶこと

セッション 27では Workflow ツールを扱いました。このセッションでは、より重要な設計上の問いを扱います。マルチエージェントの結果を、単一のもっともらしい回答より信頼できるものにするにはどうすればよいでしょうか。

7 つのパターンを学びます。

  1. 直交する探索
  2. 明示的な証拠契約
  3. 敵対的検証
  4. 段階的な統合
  5. loop-until-dry の停止
  6. 可視化されたカバレッジ境界
  7. 人または自動化による品質ゲート

これらはアーキテクチャパターンであり、未文書化の Workflow API 保証ではありません。タスクにパターンを明記し、Claude に現在サポートされるスクリプトを書かせます。

1. Clone Fan-out ではなく直交探索

同じプロンプトを 5 回実行すると、同じ盲点も複製されがちです。探索方法や境界で分けます。

  • 変更関数のローカルロジックを確認する。
  • Callers と downstream contracts を追う。
  • エラーと回復経路を調べる。
  • 認可または信頼境界をテストする。
  • ドキュメント、テスト、実装を比較する。
use a workflow to review this change through four independent lenses:
local logic, call-site contracts, failure recovery, and security boundaries.
Keep each lens separate until synthesis.

独立性が重要です。各 finder が最初から別の finder の答えを見ると、グループ全体が同じ初期ミスに引きずられます。

2. 証拠契約を定義する

Worker を増やす前に、finding が必ず含む項目を決めます。実用的な最小構成は次のとおりです。

フィールド目的
Claim反証可能な 1 つの主張
LocationFile、symbol、URL、command
EvidenceClaim を裏付ける観察
Reproduction該当する場合の inputs と手順
Impact実際に何が壊れ、誰に影響するか
ConfidenceConfirmed、plausible、unverified

Finder には簡潔な records を返させ、該当結果がない場合は NONE と答えさせます。最終 writer に、finder が提供していない証拠を推測させないでください。

3. 敵対的検証

Discovery と verification には逆の動機を持たせます。Finder は候補を見つけ、verifier はそれを反証しようとします。

For every candidate, launch an independent verifier with this instruction:
assume the claim is wrong; reproduce it, identify the strongest counterexample,
and mark it confirmed, refuted, or unverified with evidence.
Do not count a rate limit or tool failure as refutation.

最後の区別は現在の /deep-research と一致します。確認できなかった claim は unverified とされ、暗黙に false として扱われません。

高リスク作業では correctness、security、operational impact など複数の検証レンズを使えます。ただし、多数意見に価値があるのは evidence が独立している場合だけです。

4. 検証してから統合する

最終 synthesizer は agent output を連結するだけでは不十分です。役割を限定します。

  1. Refuted candidates を破棄する。
  2. Unverified claims を明確に分ける。
  3. 表現ではなく root cause で重複排除する。
  4. Confirmed findings を観測可能な impact で並べる。
  5. すべての結論に evidence record を付ける。

ここでは barrier が正当化されます。検証済み集合全体を見なければ、比較、統合、ランキングができないからです。

5. 探索が連続して空になるまで繰り返す

1 回の audit が示すのは、最初の prompts が何かを返したことだけです。オープンエンドな探索には明示的な停止条件を置きます。

use a workflow to find flaky tests in this repository.
Run independent rounds, deduplicate against every candidate already seen,
and stop after two consecutive rounds produce no new candidates.
Also stop if the same failures repeat without new evidence.

重要な点は 2 つです。

  • 却下済みも含めた既知の全 candidatesに対して重複排除しないと、却下された claim が永久に再発見されます。
  • 「進捗なし」は観測可能でなければなりません。新しい files なし、新しい evidence なし、failing check の変化なし、などです。

Dry-round rule は実用的な停止 heuristic であり、探索空間を数学的に網羅した証明ではありません。

6. カバレッジ境界を見える化する

有限のレビューには必ず境界があります。隠さず記録します。

  • 対象 directories と file types
  • スキップした files と理由
  • Sampling した経路と exhaustive に調べた経路
  • 失敗または timeout した commands
  • Unverified のまま残った claims
  • User、runtime cap、no-progress rule のどれで workflow が止まったか

高価な workflow の前に小さい slice で試します。/workflows では agent ごとのトークン使用量を確認し、run を止められます。Size guideline と Large workflow warning はどちらも助言で、文書化された token-budget API ではありません。

7. 失敗コストが高い場所にゲートを置く

不可逆または高リスクな phase の前に gate を置きます。

  • Synthesis 前にテスト合格を必須にする。
  • Confirmed finding ごとに reproduction を必須にする。
  • Implementation と deployment を別 run にする。
  • Schema changes や release actions の前に人の承認を求める。

Workflow は実行途中で通常の user question を聞けないため、人の承認は workflows の間に置きます。

Workers が継続的に議論・協調する必要があるなら、agent team の方が適する場合があります。Agent teams は tasks を共有し、peers に直接メッセージできます。一方、experimental でデフォルト無効、コストが高く、逐次作業や同一ファイル編集には向きません。TaskCompleted と TeammateIdle hooks は早すぎる完了を拒否し、teammates に修正指示を返せます。

参照レビュー構造

独立して探索
  ├─ ローカルロジック
  ├─ モジュール間契約
  ├─ 失敗経路
  └─ 信頼境界
          │
          ▼
Evidence records を正規化
          │
          ▼
候補ごとに敵対的検証
  ├─ confirmed
  ├─ refuted
  └─ unverified
          │
          ▼
重複排除、順位付け、coverage bounds の報告

この設計は小規模にも使えます。役割と evidence contract が明確なら、2 finders と 1 verifier が 20 clone agents より優れることがあります。

アンチパターン

  • **Clone swarm：**同じ曖昧なプロンプトを大量複製
  • **合意を証明にする：**独立した evidence なしで投票
  • **Verifier contamination：**全 reviewers に同じ結論を最初から見せる
  • **見えない sampling：**部分調査を exhaustive として提示
  • **Failure collapse：**timeout、拒否、取得不能を false と扱う
  • **終わらない探索：**dry-round、passing-check、no-progress 条件がない
  • **独自 runtime contract：**未文書化の cost、exception、null-return semantics に依存

要点

マルチエージェントの品質は agent 数ではなく、動機の分離と見える証拠から生まれます。 広く探索し、懐疑的に検証し、明示的に止まり、境界を正直に報告します。Workflow の価値はこの構造を繰り返しエンコードできることであり、fan-out 自体が正しさを保証するわけではありません。

次のセッション

セッション 29 では永続メモリを扱います。古い結論を無条件の真実にせず、長期知識を利用できるようにします。

公式情報源