二段構えのモデル構成 — Haiku 4.5 オーケストレーター × Opus 4.6 ワーカーで保つコストと品質の均衡

何をワーカーに任せるか — 5つの判定基準

Haiku から Opus を呼び出す判断は、何となく「難しそうだから Opus」では再現性がありません。私の運用では、ルーティング層のプロンプトに次の5つの基準を明示的に書き込み、JSON で出力させています。

• 出力長が 2,000 トークンを超える見込みか
• 5ホップ以上の論理連鎖を要するか
• 対象ドメイン固有の文脈・用語を強く反映する必要があるか
• 既存の出力と類似度が高く、差別化が必要か
• 長く参照される技術的判断（アーキテクチャ選択など）を含むか

このうち2つ以上が true の場合のみ Opus に回し、それ以外は Haiku の継続出力で完結させます。実装の中核を抜粋すると次のようになります。

import os
import json
from anthropic import Anthropic
 
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
 
ROUTER_SYSTEM = """あなたはオーケストレーターです。タスク仕様を受け取り、
Opus 4.6 に処理を委譲すべきかを判定して JSON のみで返してください。
判定基準は次の通りです。
- output_long: 出力 2000 token を超える見込み
- multi_hop: 5 ホップ以上の論理連鎖が必要
- domain_voice: ドメイン固有の文脈/用語の再現が必須
- differentiation: 既存の類似出力との差別化が必要
- architecture: 長く参照されるアーキテクチャ判断を含む
2 つ以上が true なら escalate=true。
出力スキーマ:
{
  "output_long": bool,
  "multi_hop": bool,
  "domain_voice": bool,
  "differentiation": bool,
  "architecture": bool,
  "escalate": bool,
  "reason": "短い日本語の根拠"
}
"""
 
def route(task_spec: dict) -> dict:
    response = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=400,
        system=ROUTER_SYSTEM,
        messages=[{
            "role": "user",
            "content": json.dumps(task_spec, ensure_ascii=False)
        }]
    )
    raw = response.content[0].text
    return json.loads(raw)

ポイントは、ルーター側で max_tokens=400 と短く絞り、出力フォーマットを JSON に固定していることです。Haiku 4.5 は短い構造化出力が安定して速いため、ここで余計な前置きを書かれないようにシステムプロンプトで制約しておきます。私の運用では、ルーティング判定の平均レイテンシが 1.2秒、コストが1判定あたり約 $0.0006 に収まっています。

ワーカー側の起動と結果の取り回し

ルーターが escalate=true を返した場合のみ Opus 4.6 を起動します。ここで重要なのは、Opus に渡す入力を「ルーターの判断ログ + 元のタスク仕様」の2層構造にしておくことです。これにより、Opus 側が「なぜ自分が呼ばれたか」を文脈として理解し、より深く踏み込んだ出力を返してくれるようになります。

def delegate(task_spec: dict, routing: dict) -> str:
    if not routing["escalate"]:
        return run_haiku_inline(task_spec)
    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=8000,
        system=(
            "あなたは熟練ライターです。前段のルーターが以下の理由であなたに"
            "処理を委譲しました: "
            f"{routing['reason']}\n"
            "この理由に応じて、長文・論理連鎖・個人体験の反映を意識して"
            "成果物を作成してください。"
        ),
        messages=[{
            "role": "user",
            "content": build_prompt(task_spec)
        }]
    )
    return response.content[0].text

実装当初、私はこの「ルーターの理由を Opus に渡す」工夫を入れていませんでした。当時の Opus は呼び出されると確かに高品質な出力を返してきましたが、ルーターの基準と微妙にずれた書き方をすることがあり、後段の品質ゲート（生成物を機械的に検収する自作スクリプト）で違反を拾われ、差し戻しになる頻度が無視できませんでした。

ルーター理由を渡すように変えてから、Opus 出力の品質ゲート一発通過率が 62% から 84% まで改善しました。これは月単位では「再生成のための追加課金」が大きく減るということで、コスト最適化の観点でも見過ごせない差です。差し戻し1件はトークンを二重に払うので、通過率はコスト指標でもあります。

ストリーミングとブロッキングの使い分け

ルーター層は短い JSON 応答を返すだけなので、ストリーミングを使う旨味は薄いです。1.2秒のレイテンシをさらに削るより、レスポンス全体を受け取ってから JSON パースに進むほうが、エラーハンドリングがシンプルになります。

一方で Opus 側はストリーミングを積極的に使います。本文生成では5,000〜8,000 トークンの出力が普通で、最初の数十トークンを受け取った時点で品質ゲート相当のキーワード検査を回し、明らかな違反パターン（テンプレート導入文、禁止語句、自慢調のタイトル）が混入していたら早期に abort する設計にしました。

def stream_with_early_abort(prompt: str, banned: list[str]) -> str:
    buffer = []
    with client.messages.stream(
        model="claude-opus-4-6",
        max_tokens=8000,
        messages=[{"role": "user", "content": prompt}],
    ) as stream:
        for text in stream.text_stream:
            buffer.append(text)
            joined = "".join(buffer)
            for word in banned:
                if word in joined:
                    raise EarlyAbort(word)
            if len(joined) > 600 and looks_like_template_intro(joined):
                raise EarlyAbort("template_intro")
        return "".join(buffer)

この早期 abort は、Opus 出力の品質ゲート一発通過率を上げると同時に、無駄なトークン課金を防ぐ効果がありました。実測で、abort が発火したジョブ1件あたり 3,500 トークン程度の節約になり、月単位では 5〜8% のコスト削減につながっています。

ハイブリッド構成で詰まった3つの落とし穴

理屈はきれいに整理できるのですが、実運用に乗せると思わぬ場所で詰まりました。同じ構成を採用する方のために、私が経験した3つを書き残しておきます。

1. ルーターが「全部 escalate=true」に寄ってしまう問題

最初の2週間、Haiku ルーターはほぼ全リクエストを Opus にエスカレーションしました。原因は、システムプロンプトに「迷ったら escalate=true」と書いていたことです。Haiku は迷うのが上手な性格のモデルなので、この一文があると全部 true に寄せます。

修正後は「迷ったら escalate=false。Haiku 自身で処理して構わない」と明示し、5基準の判定を「2つ以上 true」と数値化しました。これでエスカレーション率が 92% から 30% 前後に落ち、本来の二段構成として機能し始めました。

2. キャッシュキーの衝突によるレイテンシ悪化

Opus 側で prompt caching を効かせていたのですが、システムプロンプトに「ルーター判断ログ」を入れたことでキャッシュキーが毎回変わり、キャッシュ命中率がほぼゼロまで落ちました。実測でレイテンシが平均 4.8秒から 11.3秒まで悪化しました。

対処として、ルーター判断ログは messages 側に入れ、システムプロンプトは固定文字列を保ちました。ephemeral cache breakpoint をシステムプロンプト末尾に置き、cache_control を明示することで命中率は 78% まで戻り、レイテンシも 5.2秒前後に収まりました。キャッシュ層をさらに前段へ持ち上げたい場合は、Claude API のセマンティックキャッシュを本番投入する で扱った類似判定としきい値設計が接続点になります。

3. 二段ロギングがログ容量を圧迫する

ルーターと Opus の両方のレスポンスをそのまま保存していたら、月次のログ容量が前年比 2.4倍に膨らみました。Cloudflare R2 のストレージコストが意外に効いてくる規模です。

対処として、ルーターのフルレスポンスは保存せず、escalate / reason の2フィールドだけを残し、本体は Opus の出力に絞りました。デバッグ用にルーター生レスポンスが必要なときは、当日分のみ別のテンポラリ KV に置く構成にしています。これで月次ログ容量を前年並みに戻せました。

採用に至るまでに捨てた3つのアプローチ

二段構成にたどり着く前、私はいくつかの別構成を試して、最終的に捨てました。失敗の記憶は再現性のある教訓になるので、書き残しておきたいと思います。

ひとつめは「Opus 単独 + temperature を下げてコスト圧縮」というアプローチでした。出力を短くしてトークン消費を抑える発想です。実際に temperature を 0.2 まで下げると出力長は確かに 20% 程度減りましたが、表現の幅も同時に痩せ、成果物から手触りが抜け落ちました。単価はわずかに下がっても、後段で人が手を入れ直す時間が増え、総コストではむしろ悪化しています。

ふたつめは「Sonnet 4.6 単独で全タスクを処理」する構成でした。Opus より一桁安く、Haiku より一段賢いという中庸路線です。これは半年ほど採用しましたが、論理連鎖が複雑になる長文タスクで Opus 同等の深さが出ない場面が増え、品質ゲートで差し戻される頻度が上がりました。月次の再生成課金が積み上がり、結果として Opus を一切使わない月のほうがコスト総額が高くなる、という逆転が起きてしまったのです。

みっつめは「ルーター層を別アプリケーションに分離して Cloudflare Workers 上で動かす」構成でした。ルーティング判定はステートレスなので、Workers の Edge ロケーションで動かせばレイテンシをさらに削れるはず、という設計です。実装してみると確かにルーター単独のレイテンシは 0.4秒まで下がりましたが、Workers の制約（CPU 時間、メモリ）と Anthropic SDK の依存解決が想像以上に厄介で、運用負荷の増加に対してメリットが釣り合いませんでした。今は素直に Python ランタイム上で同居させています。

これらを捨てた経験から学んだのは、コスト最適化を「単価を下げる方向」だけで考えると視野が狭くなる、ということです。再生成課金、運用負荷、後段の手直し時間といった周辺コストを含めた総コストを最小化する観点で構成を選ぶと、二段構成のような少し回りくどい設計に落ち着きました。

観測すべき指標 — オーケストレーターを健康に保つために

二段構成は「動いている」ことの確認だけでは不十分です。私は次の指標を Grafana で毎日眺めるようにしました。

• エスカレーション率（理想は 20〜40%）
• ルーター判定の平均レイテンシ
• Opus 出力の品質ゲート一発通過率
• Opus 入力に占める prompt cache 命中率
• ジョブ1件あたりの実コスト（Haiku + Opus 合算）

特に「エスカレーション率」は健康指標として大事で、20% を下回ると Haiku 単独で十分なケースが増えている可能性があり、40% を超えると Opus に頼りすぎている可能性があります。私の運用では、月次レビューでこの数値を確認し、ルーターのシステムプロンプトを微調整するというリズムが回っています。

月単位で見る実コスト試算 — 1日16件のジョブを回す場合

抽象的な単価より、自分の運用に当てはめた具体数字のほうが判断しやすいので、私の運用を例に置いて月次のコストを試算してみます。1日あたり16件、月当たり概ね 480 件の長文生成ジョブを回す規模を前提にします。

1件あたりの平均トークン消費は、ルーター入力 1,500、ルーター出力 300、Opus 入力 3,000、Opus 出力 5,000 程度になります。エスカレーション率を 30% と仮定すると、月当たりの消費は次のように積み上がります。

• Haiku ルーター入力: 480件 × 1,500 = 720,000 トークン
• Haiku ルーター出力: 480件 × 300 = 144,000 トークン
• Opus 入力（30%エスカレ）: 144件 × 3,000 = 432,000 トークン
• Opus 出力（30%エスカレ）: 144件 × 5,000 = 720,000 トークン
• Haiku 本体処理（70%）: 336件 × 4,500 = 1,512,000 トークン

これを単価に当てて加算すると、月次合計で約 $25 前後に収まりました。前年同月、Opus 単独で同規模を回していたときは月 $90 前後でしたから、絶対額にしてざっと月 $65、年間で約 $780 の差です。個人開発の予算感では、この差は「別の実験をもう一本回せる」金額に相当します。

数字を作るときに注意すべきは、エスカレーション率は固定ではなく、シーズンや扱うトピックで揺れるという点です。私の場合、年末年始に販促まわりの長文を集中して回す期間はエスカレーション率が 45% まで上がり、月コストが $35 を超えます。逆に定型の短い出力が多い月は 18% 程度まで下がり、月 $20 を切ります。月次でこの数字を観察して、ルーター基準を微調整するリズムが運用の核になります。

ロギング設計 — ルーター出力の二次活用

ルーターが返す JSON は、エスカレーション判断のためだけに使うともったいないと感じています。私の運用では、ルーター出力を構造化ログとして Cloudflare D1 に蓄積し、後段の分析に使っています。

import sqlite3
import datetime
 
def log_routing(task_id: str, task_spec: dict, routing: dict, escalated: bool):
    conn = sqlite3.connect("routing.db")
    conn.execute(
        """
        INSERT INTO routing_log
        (task_id, ts, topic, output_long, multi_hop, domain_voice,
         differentiation, architecture, escalate, reason)
        VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
        """,
        (
            task_id,
            datetime.datetime.utcnow().isoformat(),
            task_spec.get("topic", ""),
            int(routing["output_long"]),
            int(routing["multi_hop"]),
            int(routing["domain_voice"]),
            int(routing["differentiation"]),
            int(routing["architecture"]),
            int(escalated),
            routing["reason"][:200],
        ),
    )
    conn.commit()

このログがあると、月末のレビューで「どの判定軸が最もエスカレーション判断に効いているか」を集計できます。私の運用では、domain_voice フラグが立った場合のエスカレーション率は実質 100% に近く、逆に output_long 単独では 32% 程度しか escalate されません。基準ごとの寄与度を測れると、ルーター基準そのものの調整が定量的にできるようになります。

論理連鎖（multi_hop）の判定はとくに難しく、Haiku が誤判定しやすいポイントでもあります。私はここを補強するために、過去30日分の multi_hop=true でエスカレーションされたジョブの要約を、ルーターのシステムプロンプトに数例だけ追記する Few-shot 化を試しました。これにより判定一致率が体感で2割ほど上がっています。

3段構成にする選択肢 — Sonnet 4.6 を挟む場合

ここまでは Haiku と Opus の2段で書いてきましたが、運用が成熟してくると Sonnet 4.6 を中段に挟む「3段構成」も選択肢になります。私の場合、中核に置いている長文ジョブのうち、Opus に丸投げするほど深掘りは不要だが Haiku では物足りない、という中間帯が見えてきました。

3段構成のルーティング基準は、2段構成の5基準に「output_long」のしきい値を3段化した形で実装しています。たとえば 1,200 トークン以下は Haiku、1,200〜3,500 は Sonnet、3,500 以上は Opus、というふうに段階を切る形です。実コストでは Sonnet 中段が約 $3.00 / 1M、Opus 単独より一桁安いので、ここを上手に使うとさらに月単位で 10〜15% の追加圧縮が見込めます。

ただ、3段にすると保守の負担も上がります。プロンプトのバージョン管理、各段の品質ゲート、エスカレーション率のモニタリングが、それぞれ独立して必要になります。私は最初の半年は2段に絞り、運用が安定して数字に余裕が出てから3段に拡張するほうが、現場の感覚としては無理がないと感じました。

判定基準を月次で読み直す — ルーターログからの基準改訂

二段構成の弱点は、ルーターの判定基準が「書いた時点の想定」のまま固まってしまうことです。扱うタスクの傾向は数週間で変わります。私の場合、ジョブ種別を一つ増やしただけで output_long の分布が右にずれ、エスカレーション率が 30% から 44% まで上がっていたことに、月末の請求額を見るまで気づけませんでした。

そこで、月に一度だけルーターログを読み直す時間を取るようにしています。やることは3つだけです。

1. 直近30日のエスカレーション率を、タスク種別ごとに出す
2. Opus に上げたのに出力が短く済んだ案件（＝上げる必要がなかった可能性）を抽出する
3. Haiku で処理したのに後段の品質ゲートで差し戻された案件（＝上げるべきだった案件）を抽出する

2と3は、それぞれ偽陽性と偽陰性にあたります。ルーターの精度を一つの数字にまとめようとすると判断を誤りやすいため、私はこの二方向を分けて数えています。

前節の routing_log に、実際の出力トークン数と品質ゲートの結果を2列だけ足しておくと、この集計がそのまま SQL で書けます。

import sqlite3
 
REVIEW_SQL = """
SELECT
  CASE
    WHEN escalate = 1 AND actual_output_tokens < 1200 THEN 'false_positive'
    WHEN escalate = 0 AND gate_rejected = 1        THEN 'false_negative'
    ELSE 'ok'
  END AS verdict,
  COUNT(*)                AS n,
  ROUND(AVG(actual_output_tokens)) AS avg_tokens
FROM routing_log
WHERE ts >= date('now', '-30 day')
GROUP BY verdict
ORDER BY n DESC
"""
 
def monthly_review(db_path: str = "routing.db"):
    conn = sqlite3.connect(db_path)
    rows = conn.execute(REVIEW_SQL).fetchall()
    total = sum(r[1] for r in rows) or 1
    for verdict, n, avg_tokens in rows:
        print(f"{verdict:<15} {n:>4}件 ({n / total:.1%})  平均出力 {avg_tokens} tok")
    return rows

actual_output_tokens < 1200 というしきい値は、ルーターの output_long 判定に使っている値と同じものを置いています。判定に使った基準と、事後の検証に使う基準を別々の数字にしてしまうと、「基準がずれているのか、判定がずれているのか」が切り分けられなくなるためです。同じ数字を両側に置くことだけは、最初に決めておくことをお勧めします。

このスクリプトは判断を自動化しません。候補を並べるだけです。実際に基準を書き換えるかどうかは、必ず数件を自分の目で読んでから決めるようにしています。output_long のしきい値を 1,200 から 1,600 に引き上げた月は、偽陽性が 18 件から 5 件へ減り、品質ゲートの差し戻しは 2 件増えるにとどまりました。この程度のトレードオフなら受け入れる、という判断です。

基準を書き出し、実際の判定と突き合わせ、必要なら書き換える。この往復を月に一度回しておくと、コスト構造が静かに悪化していく事態を、請求書より先に捕まえられます。

2026年8月の単価改定を、中段のしきい値に織り込む

ここまでの数字は 2026年5月時点の構成で測ったものです。8月に入って前提が二つ動いたので、二段構成を運用している側で見直すべき点を書き足しておきます。

ひとつは既定モデルの入れ替わりです。8月3日に Sonnet 5 が Pro・Team Standard・Enterprise の既定になり、8月5日には Opus 5 が提供開始され Max の既定に置かれました。二段構成にとって厄介なのは、この変更が「設定を触っていないのに指揮役と作業役が同時に入れ替わる」形で効く点です。

エスカレーション率は、指揮役の判断傾向と作業役の実力の両方に依存する数字です。片方だけが変わっても意味が揺れますが、両方が同時に変わると、月次でモニタリングしていた 20〜40% のレンジが何を表していたのか読めなくなります。

対策は単純で、ルーター側もワーカー側も model を文字列で明示指定しておくことに尽きます。既定に寄りかかった実装は、ある朝の請求書で気づくことになります。予算側から二重に止める設計は、Claude API の本番運用で予算上限を確実に守る に置いたサーキットブレーカーが土台になります。

もうひとつは単価です。Sonnet 5 のプロモーション価格 $2 / $10 per Mtok は 2026年8月31日までで、9月1日から $3 / $15 per Mtok に戻ります。3段構成の中段に Sonnet を置いている場合、ここが素直に効きます。

前節の月次モデル（月480件、エスカレーション率 30%）で、従来 Opus に上げていた 144 件のうち半分を中段へ降ろした場合を計算してみます。入力 3,000・出力 5,000 トークンのプロファイルをそのまま当てると、中段が扱う量は入力 0.216M・出力 0.36M トークンです。

差は月 $2.02、率にして 50% 増です。前節の月次総額 $25 に対する中段の占有率は 16.1% から 24.2% へ上がります。絶対額としては小さく見えますが、比率で見ると中段の存在感が一段増すことになります。

同じ量を Opus に戻した場合（入出力合算 $15 / 1M の概算）は $8.64 ですから、中段を挟むことによる削減幅は $4.61 から $2.59 へ縮みます。中段は 9月1日以降も依然として得ですが、得の大きさは半分近くまで痩せます。

ここから導かれる実務的な結論は、9月1日を境に中段のしきい値を上下どちらかへ動かすべき、ということです。判断は「Sonnet に降ろした結果、後段の差し戻しが増えていないか」で決まります。差し戻しが出ていないなら中段の帯を広げて Opus をさらに減らす。差し戻しが出ているなら、単価が上がったぶん中段は割に合わなくなるので帯を狭め、二段構成に戻す。

私はこの判定を、前節の routing_log に品質ゲート結果を入れた集計でそのまま出せるようにしてあります。単価が変わったときに慌てて設計を考え直さずに済むのは、判定に使う数字を先に一箇所へ集めておいたおかげでした。

なお、価格・提供条件・既定モデルは変動します。数字を自分の構成に当てる前に、必ず一次情報で現在値を確認してください。

どこから始めるか

これから二段構成を試す方には、いきなり全タスクに導入するのではなく、次の順序で段階的に切り替えることをお勧めします。

1. 既存パイプラインのうち、定型的な分類タスク（タグ付け、カテゴリ判定、メタデータ抽出）を1つ選び、まず Haiku 単独に置き換える
2. 出力品質が落ちないことを2週間モニターする
3. 出力品質に揺らぎが出るタスク（本文生成、コード生成）に対して、ルーター層を挟む
4. エスカレーション率が想定範囲（20〜40%）に収まるまでシステムプロンプトを微調整する
5. prompt caching の命中率を高めるため、キャッシュ可能な前段を切り出す

私自身がこの順序を守れたわけではなく、いきなりルーターを差し込んで上記の落とし穴に全部踏みました。だからこそ、これから取り組まれる方には、もう少し穏やかな入り方をお勧めしたいのです。

二段構成の本当の価値は、コストが下がることそのものより、判断の道具と作業の道具が分かれることで、ふだん見えにくかった「判断の質」を別軸で測れるようになることだと感じています。

最初の一歩として今日できるのは、いま動かしているジョブのうち1つを選び、そこで走っているモデル指定が既定任せになっていないかを確認することです。文字列で固定されていなければ、まずそこを埋める。エスカレーション率を測り始めるのは、その次で構いません。