はじめに
「とりあえず全部 Sonnet で動かす」は確かに楽だ。モデルを気にせず書けるし、品質の上振れも期待できる。しかし 1 日あたりのリクエスト数が数十から数百になってくると、「Sonnet でやらなくてよかった処理」が積み重なってコストに跳ね返ってくる。
同時に逆の問題もある。Haiku に任せすぎると、提案書の本文生成や横断レポートの精度が落ちる。節約しようとしたはずが、やり直しコストのほうが高くついた経験もある。
八雲では Synapse（内部エージェント基盤）を運用しながら、モデルと処理の組み合わせについてポリシーを整理してきた。この記事ではその設計思想と具体的な境界線を記録する。
4 段の使い分け
中心となる考え方は「決定論的な処理に LLM を使わない」だ。入出力が決まっていてルールが明示的な処理は、コードで書けば決定論的で速く、コストもかからない。
| レイヤー | 用途 | 具体例 |
|---|---|---|
| スクリプト（LLM なし） | 決定論的処理 | テンプレ適用・replaceAllText・PDF 生成・Drive 操作・スクレイピング・データ変換 |
Haiku（claude-haiku-4-5-20251001） | 軽量な分類・抽出・判定 | B ランク案件レビュー・フォーマット判定・カテゴリタグ付け・短文要約 |
Sonnet（claude-sonnet-4-6） | 要約・整理・中程度の創造 | S/A ランク案件レビュー・議事録まとめ・提案書本文生成・競合リサーチ要約 |
Opus（claude-opus-4-7） | 戦略・複雑な判断 | 事業戦略策定・横断レポート・複雑な要件整理・アーキテクチャ設計 |
この 4 段は「コスト順」ではなく「判断の複雑度順」として読むのが正確だ。LLM を呼ぶかどうかを最初に決め、呼ぶとしたらどの難易度かを次に決める。
決定論処理に LLM を使わない原則
スクリプトで完結させるべきサインは 3 つある。
- 入出力が決まっている — プレースホルダ置換・列マッピング・テンプレ適用
- ルールが明示的 — 価格計算・辞書引き分類
- 繰り返し実行する — スクレイピング・PDF 生成・Drive 操作
これらは LLM を呼んでも精度が上がらないどころか、ランダム性が混入してバグの原因になる。見積書の金額計算を Haiku に計算させる理由はない。純粋な Python スクリプトとして書く。
Synapse では /estimate（見積 PDF 生成）・/invoice（請求書 PDF）・/onboard（フォルダ作成 + テンプレコピー）・/submit（フォーム自動入力）はすべてスクリプトのみで実装している。LLM を一切呼ばない。
# scripts/templates/sync-doc-templates.py
# テンプレ同期は完全に決定論的処理 — LLM 不使用
for template in config['templates']:
copy_template(template['source_id'], template['dest_folder'])
update_metadata(template)Haiku の使いどころ
Haiku が輝くのは「大量・高速・軽量」の組み合わせだ。1 件あたりの判断は単純でも、それが 100 件・1000 件になると Sonnet との差が無視できなくなる。
具体的には B ランク案件の AI レビューが典型例だ。Synapse の /scrape スキルは案件をスコアリングして B ランクに分類した後、Haiku でレビューを走らせる。S/A ランクは Sonnet へ昇格する。
RANK_CONFIG = {
"SA": {"model": "sonnet", "label": "S/A"}, # 精度重視
"B": {"model": "haiku", "label": "B"}, # コスト重視
}翻訳タスクでも同様の使い方ができる。コーポレートサイトやウェブページの多言語対応では、Haiku で草稿を生成して Sonnet でトーン調整レビューを挟む 2 段階パイプラインを推奨している。草稿と洗練を分離することで、Opus を呼ぶ場面をさらに絞れる。
Sonnet がデフォルトの理由
「迷ったら Sonnet」というルールにしているのは、適用範囲が最も広いからだ。
- 自然言語で多様な入力（案件説明の分類・メール本文の要約）
- 曖昧な判断が必要（提案推奨の是非・案件適合度）
- 中程度の創造的アウトプット（提案書本文・戦略書の素案）
これらはスクリプトでは書けないが、Opus ほどの熟考も要らない処理だ。Synapse の 3 人の領域責任者（sales-director / dev-director / web-developer）はデフォルトで Sonnet を使い、判断が自分の責務を超えると判断したときだけ上位に委任する設計にしている。
責任者が判断を下し、スキルが実行する委任チェーンという設計は、AI 駆動開発の記事で説明した Synapse の設計原則と一致している。モデル選択も同じ委任の考え方で整理できる。
Opus を呼ぶ条件
Opus（claude-opus-4-7）を呼ぶのは「熟考が必要な場面」に限定している。目安は「人間が数分以上考える処理」だ。
- 事業戦略策定 — P&L 統合・横断レポート・中期計画
- 横断分析 — 複数プロダクトをまたぐ依存関係・リスク評価
- 複雑な要件整理 — 曖昧な仕様から具体的なアーキテクチャへの落とし込み
- 最終判断 — 提案の go/no-go・パートナー選定
Synapse では director エージェントのみがデフォルト Opus で動く。他の責任者は Sonnet を使い、判断が事業横断の複雑さに達したときだけ director に委任する。
戦略的なコピーライティング（Hero / CTA / タグライン）も Opus 向きだ。訴求軸とトーンを言語横断で保持したまま仕上げるには、Sonnet では表現の揺れが出やすい。
コスト視点
モデル別のトークン単価は定期的に変わるため具体的な数字は書かないが、構造として重要なのは「呼び出し頻度 × 入出力トークン量 × 単価」の積がコストを決めるという点だ。
スクリプトで処理するとトークン消費がゼロになる。Haiku に変えると数分の一のコストになる。Sonnet と Opus の間は単価差が大きい一方で、呼び出し頻度が低い（戦略タスクは繰り返さない）ので絶対額の差は小さくなりやすい。
結果として「スクリプト → Haiku の切替」が最もレバレッジが大きく、「Sonnet → Haiku の切替」が次に効く。「Opus を使う頻度を減らす」はコスト的には意外と効果が薄いことが多い。
運用してわかった効果と落とし穴
効果として感じていること
テンプレ適用・PDF 生成・Drive 操作をスクリプト化したことで、定型業務の実行速度が大きく改善した。LLM 呼び出しのレイテンシがなくなり、ログが決定論的になってデバッグも容易になった。
Haiku / Sonnet の境界をランクで引いたことで、高スコア案件には精度を集中投下しながら中スコア案件のレビュースループットも維持できている。
落とし穴として踏んだこと
Haiku に任せすぎると判断品質が落ちる箇所がある。 短文要約は得意だが、文脈が複雑な提案の適合度判定を Haiku に任せると見落としが増えた。境界を引き直してランク B の中でも金額が大きい案件は Sonnet に昇格させるよう調整した。
スクリプトで書ける処理を LLM に流し続けていた期間があった。 気づかずに Sonnet でテンプレ適用していたスクリプトを発見して、Python に書き直した。見た目の品質は変わらず、速度とコストだけ改善した。
「迷ったら Opus」のルールを当初採用していたが撤廃した。 迷いは処理の設計で解消するべきであって、モデルのパワーで補うものではない。Opus を呼ぶ判断自体を厳格化することで、設計の質が上がる副作用があった。
まとめ
ポリシーの核心は 2 点に集約できる。
- 決定論的な処理はコードで書く。LLM は判断にだけ使う。
- 判断の複雑度に応じて Haiku → Sonnet → Opus を段階的に選ぶ。
このポリシーは月次で見直している。/scrape の AI レビュー結果を振り返り、Haiku と Sonnet の切替ラインを調整する。新しいモデル世代がリリースされたときも同様に再評価する。
ポリシーは一度決めたら変わらないのではなく、運用データと照合しながら育てるものだと考えている。