記事
思考停止の Fan-out はやめよう：Claude Haiku 5.5 を活かす 4 層オーケストレーション実践
Claude Haiku 5.5 は高速かつ安価ですが、すべてのタスクを無差別に並列で投げると、誤判断や評価バイアス、Supply Chain リスクを増大させるだけです。本稿では、Fable による判断、Opus によるオーケストレーション、Sonnet と Haiku による実装、CI による検証、Opus による検収という階層型アーキテクチャと、どのようなタスクこそが Fan-out に適しているのかを解説します。
· 9 分で読めます
Claude Haiku 5.5 が 2026 年 10 月 7 日にリリースされました。prompt が 100,000 tokens 以内の場合、価格は Sonnet 5.5 の 20 分の 1 であり、レイテンシも現行世代の Claude の中で最速です。
これほど安くて速いと、すべてのコーディングタスクを細切れにして複数の Haiku に並列で投げ、あとは待つだけ、という構成を組みたくなるかもしれません。
プロトタイプ段階なら、それでも動くでしょう。しかし、本番のエンジニアリング環境に持ち込むと、すぐに 3 つの壁にぶつかります。
- 小型モデルは曖昧さの処理に向いていない。 Haiku 5.5 の公式な位置づけは、分類、抽出、ルーティング、subagent といった大量かつ低レイテンシのワークロードです。要件にビジネス上の曖昧さが残っていたり、システム全体のコンテキストが必要だったりする場合、一見それっぽく見えて実は的外れな出力を平気で返してきます。
- モデルに答えを選ばせると評価バイアスが生じる。 何十もの成果物を大型モデルに読ませて選ばせると、ロジックや実行結果が本当に正しいバージョンではなく、「構造が美しく見える」バージョンを選びがちになります。
- Worker の数に比例して権限リスクが増大する。 並列で動く subagent にパッケージの自動インストールや設定変更を許可している場合、N 個の Worker を立ち上げれば、悪意あるパッケージが紛れ込む侵入経路も N 個に増えます。
そこで私は、階層型オーケストレーション（Hierarchical Orchestration）を採用しました。各層に得意なことだけを担当させ、Haiku の並列処理能力は真に必要な場所にのみ割り当てます。
結論から言えば、Fable が考え抜き、Opus が割り振りと検収を担当し、Sonnet が主実装を担い、Haiku は定型タスクと自動検証可能な探索型タスクのみを行う。そして候補案はモデルに見せる前に CI を通す、という構成です。
4 層アーキテクチャ：判断、オーケストレーション、検証、検収#
要件入力
│
▼
【判断層】Fable：アーキテクチャ決定、タスク分解、検収基準
│
▼
【オーケストレーション層】Opus Main Session：割り振りのみ、再分解はしない
├─► パス A：複雑だが境界が明確 ──► Sonnet 実装
├─► パス B：定型タスク ──► 単一の Haiku
├─► パス C：探索型・複数解法 ──► 複数の Haiku（各自独立した Git Worktree）
│
▼
【検証層】Build、Type Check、Test、Benchmark（パス C は上位 2–3 件のみ残す）
│
▼
【検収層】Opus が検収基準に基づき集約
失敗時はエスカレーション：Haiku が 2 回修正しても失敗 ➔ Sonnet ➔ Opus へ差し戻し
どのモデルをどの層に配置するかは、公式のポジショニングと価格設定に基づいて決定しています。以下は 2026 年 10 月 8 日時点の Anthropic 公式ドキュメントの数値です（価格の単位は 100 万 tokens あたりの米ドル）：
| モデル |
公式の位置づけ |
レイテンシ |
Input / Output 価格 |
| Claude Fable 5.1 |
高度な推論と長時間の agentic ワークロード |
遅め |
$10 / $50 |
| Claude Opus 5.5 |
長時間の agentic coding およびナレッジワーク |
中程度 |
$4 / $20 |
| Claude Sonnet 5.5 |
速度と能力の最適なバランス |
高速 |
$2 / $10 |
| Claude Haiku 5.5 |
大量・低レイテンシの分類、抽出、ルーティング、subagent タスク |
最速 |
$0.10 / $0.50 〜 |
Haiku 5.5 の価格は 2 段階になっており、prompt が 100,000 tokens を超えると $0.50 / $2.50 になります。
判断層：Fable によるアーキテクチャ決定と検収基準#
すべての要件に Fable が必要なわけではありません。最も高価で最も遅い層であるため、要件に曖昧さがある場合、複数システムにまたがるインテグレーションが絡む場合、あるいはコアアーキテクチャの意思決定を行う場合に限定して利用します。
Fable に出力させるべき成果物は次の 3 つです：
- ソリューション設計
- タスク分解
- 各サブタスクをテストで検証するための検収基準（Acceptance Criteria）
推論とタスク分解は、同一の層で完結させる必要があります。システムの盲点をクリアに見極められる層でなければ、境界線のきれいなサブタスクを切り出せません。アーキテクチャ設計を A に、分解を B に任せると、インターフェースの定義が曖昧になりがちです。
ただし、セキュリティタスクは例外です。現行世代の Claude モデルにはセーフティ分類器が組み込まれており、リクエストがブロックされると stop_reason: "refusal" が返されます。正当なセキュリティ業務であっても誤検知されることがあります。Fable 5.1 の分類器はセキュリティ関連コンテンツの大半をカバーしており、公式にもセキュリティ領域向けには設計されていないと説明されています。一方、Opus 5.5 はソースコード内の脆弱性探索が許可されています。そのため、脆弱性修正のような要件における上流の分析は、直接 Opus に任せています。
オーケストレーション層：Opus は割り振りのみ行い、再分解はしない#
Opus は Main Session として機能し、ルーティングとタスクのアサインを担当します。この層ではアーキテクチャを覆したり、二重にタスク分解を行ったりはしません。
- パス A、複雑だが境界が明確：ロジックは複雑だが、インターフェース境界が定義済みのタスクは Sonnet に渡します。実装の主力です。
- パス B、単純な定型タスク：ボイラープレート（Boilerplate）コードの生成、変数名のリネーム、単純なユニットテストの追加、ドキュメントの補完などは、単一の Haiku に任せます。
- パス C、探索型および最適化タスク：パフォーマンスチューニング、複雑な SQL や Regex の複数の書き方の検証、Flaky Test の原因究明などの場面で、初めて Fan-out を発動します。複数の Haiku を立ち上げ、それぞれ独立した Git Worktree 内で異なるアプローチを試行させます。
どのパスを通る場合でも、生成された成果物は必ず検証層へ送られます。
検証層：モデルの前に、まずマシンを通す#
並列生成したコードをすべて Opus や Sonnet に渡し、prompt でレビューさせるという手法がよく見られます。
問題は、モデルがコードを読む際、フォーマットが整っていて型定義がしっかりしているコードに引きずられやすい点です。しかし、それが境界値テストをパスしている保証にはなりません。だからこそ、候補案はまずマシンのチェックをくぐり抜ける必要があります。
- Build と Type Check：コンパイルが通り、型が正しいか
- Unit / Integration Tests：ユニットテストと結合テストを通過するか
- Benchmark / Profiling：パフォーマンスとメモリ消費量を計測
自動テストを通らなかったものは容赦なく脱落させます。パス C の候補案についても、Opus に見せるのはチェックを通過したメトリクス上位 2–3 件のみに絞ることで、context window と token を節約します。
検収層：Opus による集約、失敗時は上位へエスカレーション#
最終的に、判断層が定めた検収基準に沿って Opus が結果を集約します。Worker がスタックした場合は、エスカレーションパス（Escalation Path）に従って上位へ引き継ぎます：
- Haiku が失敗し、自動修正を 2 回試みても通らない場合はリトライを停止。
- Sonnet にバトンタッチして修正を担当させる。
- Sonnet でも検収をパスできない場合、通常はタスクの分解や前提条件に矛盾があることを意味します。タスクを Opus へ差し戻し、Fable に戻して再分解すべきかを Opus が判断します。
本番環境へ持ち込むための 3 つの鉄則#
むやみに Fan-out しない#
単純なタスクに複数の Worker は不要ですし、曖昧性の高いタスクは小型モデルでは解けません。「解空間が広い」かつ「自動テストで即座に検証できる」探索型タスクに絞ってこそ、複数の Haiku を並列で走らせる価値があります。
環境を分離し、Lockfile を固定する#
Git Worktree が隔離するのはコードの変更差分であり、並列で動く Worker 同士のファイル上書きを防ぐだけです。ネットワークアクセスやプログラムが触れるスコープまでは制限してくれません。Supply Chain Attack を防ぐには、sandbox の導入が不可欠であり、Worker が未検証のパッケージを勝手にインストールしたり Lockfile を変更したりすることを禁止しなければなりません。インストール権限を無防備に開放することは、素性の知れないパッケージやスクリプトを Agent にリポジトリ内へ持ち込ませるのと同じです。
モデルの講評ではなく、計測データで検収する#
テスト結果、カバレッジ、メモリ使用量、レイテンシこそが、再現可能で比較可能な根拠です。モデルによる定性的なテキスト評価は参考に留め、コード品質の検収基準にしてはなりません。
安価なモデルは、正しい場所で使う#
Haiku 5.5 によって並列化のコストは劇的に下がりましたが、並列化そのものが結果を正しくしてくれるわけではありません。判断、割り振り、検証、検収を明確に切り分けることで初めて、「安さ」と「速さ」が真の武器になるのです。
この階層構造は、私がAI エージェントは実質アジャイル開発チームであるで述べた Graph そのものです。誰が先に取り組み、終わったら誰に渡し、問題が起きたら誰へエスカレーションするのか、という流れに他なりません。