Claude Sonnet 5 をコーディングエージェントに使うなら：デフォルト経路、昇格、fallback の設計
まず結論
| タスク状況 | 推奨経路 | 理由 |
|---|---|---|
| 複数ファイル実装、テスト修復、コードレビュー | Sonnet 5 を主候補にする | コード品質、ツール利用、文脈保持のバランスが良い |
| 簡単な説明、整形、大量ドキュメント | 低コスト経路を優先 | 補助タスクすべてに強い経路は不要 |
| アーキテクチャ、セキュリティ、課金、データのリスク | Opus/Fable クラスへ昇格 | エラーコストがモデルコストより高い |
| Sonnet 5 が繰り返し失敗、またはツールループが続く | 昇格、または状態要約後に再試行 | 盲目的な retry は token と時間を増やす |
| 新モデル挙動が不安定、遅延が高い、構造化出力が失敗 | 安定 fallback 経路へ戻す | fallback は障害対応だけでなく本番能力 |
| patch、test、retry、tool-call 指標がない | 先に観測性を追加 | Sonnet 5 が開発者時間を節約したか証明できない |
この記事が対象とする読者
この記事は、Claude Code 型ワークフロー、repo Q&A、コードレビュー、テスト生成、自動修復などのコーディングエージェントを構築または運用するチーム向けです。特に、品質、遅延、コスト、fallback、tool-call 信頼性の間でルーティング判断を行うチームに向いています。
コーディングエージェントは通常のチャットではない
コーディングエージェントは、1つの回答を生成するだけではありません。複数ファイルを読み、編集計画を作り、検索・編集・テスト・ビルドツールを呼び、失敗ログを解釈し、再計画し、patch やレビューを出します。さらに複数ターンで状態を保持する必要があります。
そのため、ルーティングは「どのモデルが賢そうか」だけでは決められません。ツール列を完了できるか、無駄な修復ループを避けるか、人間の手直しを減らすか、マージされた変更あたりのコストを下げるか、失敗時に明確に昇格または fallback できるかを見る必要があります。
Sonnet 5 が向いているタスク
| コーディングエージェントタスク | Sonnet 5 との相性 | ルーティング推奨 |
|---|---|---|
| 単一ファイル実装 | 良いが、まず分類 | 簡単なものは低コストから始め、失敗後に Sonnet 5 |
| 複数ファイルリファクタ | 強い | Sonnet 5 を主実装経路にする |
| リポジトリ全体のコードレビュー | 強いがリスク次第 | 通常レビューは Sonnet 5、高リスクは昇格 |
| テスト生成と修復 | 強い | Sonnet 5 で一度 retry、失敗時に昇格 |
| 長い trace のデバッグ | 文脈制御付きで良い | Sonnet 5、要約、fallback を組み合わせる |
| アーキテクチャ移行計画 | 慎重に使う | 中リスクは開始可能、高リスクは昇格 |
| 大量ドキュメントとコメント | 常に必要ではない | 低コスト経路を優先 |
| セキュリティ、課金、破壊的データ変更 | Sonnet 5 単独に依存しない | 昇格と人間レビュー |
Sonnet 5 は高価なタスク専用ではありません。コーディングエージェントシステム内のバランス型メイン経路候補です。
Sonnet 5 を default にすべきでない場合
多くのタスクがコード説明、整形、コメント、単純ドキュメントである場合、タスク分類層がない場合、tool call、テスト結果、retry、cleanup 時間を記録していない場合、または失敗時の fallback と昇格が明確でない場合、Sonnet 5 を全体 default にするべきではありません。
この基盤がないまま全量切り替えをすると、品質問題やコスト問題を解決するのではなく隠してしまいます。
Opus/Fable クラスへ昇格する条件
| 昇格シグナル | 昇格する理由 | 昇格しないリスク |
|---|---|---|
| 重要なアーキテクチャ判断 | 長期設計に影響する | 弱い計画が再利用される |
| セキュリティ、権限、課金、データリスク | エラーコストが高い | 本番事故やコンプライアンス問題 |
| Sonnet 5 が2回失敗 | 追加 retry の価値が低い | token と時間コストが増える |
| 複雑なクロスサービス依存 | より強い全体推論が必要 | 局所修正が全体を壊す |
| 複数人が実行する移行計画 | 出力がエンジニアリング資料になる | 悪い計画が広がる |
| 最終監査で不整合 | 独立した判断が必要 | 同じモデルの blind spot が残る |
EvoLink でモデル呼び出しを管理しているなら、これらの条件を workflow や routing rule にできます。
EvoLink 上の三層ルーティング
| 経路層 | 適したタスク | 目的 |
|---|---|---|
| 低コスト補助層 | タスク分類、簡単な説明、整形、大量ドキュメント、低リスク要約 | 不要な Sonnet/Opus 消費を避ける |
| Sonnet 5 実装層 | 複数ファイル実装、コードレビュー、テスト生成、テスト修復、長い trace デバッグ | 品質、コスト、agent 挙動のバランス |
| Opus/Fable 昇格層 | 高リスクアーキテクチャ、セキュリティ、課金、データ、複雑移行、最終監査 | エラーコストと長期判断リスクを制御 |
| fallback 層 | 以前の安定経路、または検証済みの別 coding model | 遅延、品質低下、パラメータエラー、挙動変化を吸収 |
これにより、モデルアップグレードは coding-agent traffic 全体の書き換えではなく、routing policy の変更になります。
fallback は任意ではない
| 失敗モード | 推奨アクション |
|---|---|
| サポート外パラメータや request error | 設定を修正して retry |
| 構造化出力の検証失敗 | schema 指示を強めて一度 retry |
| ツールループが続く | 状態を要約し、文脈を圧縮し、昇格を判断 |
| テストが繰り返し失敗 | Sonnet 5 で一度 retry 後に昇格 |
| 文脈が長すぎる | retrieval、要約、分割、trim を行う |
| 安定基準より品質が低い | 既知の安定経路へ戻し、サンプルを記録 |
| 遅延が異常 | 低リスクは軽量経路、高リスクは昇格経路 |
測るべき指標
| 指標 | 意味 |
|---|---|
| patch 採用率 | 実開発フローに入る出力か |
| テスト通過率 | 生成コードが動くか |
| retry 回数 | 隠れたコストと摩擦 |
| tool-call 成功率 | agent の信頼性 |
| マージ変更あたりコスト | モデル費用を事業成果へ結びつける |
| 人間の cleanup 時間 | 開発者工数を減らしたか |
| fallback 発火率 | 新経路の安定性 |
| 最終監査の指摘率 | 同一モデル blind spot と独立レビュー価値 |
Sonnet 5 を default にする前に、少なくとも 20-50 個の実タスクを replay してください。
推奨 rollout
| フェーズ | 内容 | 合格基準 |
|---|---|---|
| Replay | 過去 trace を旧経路と Sonnet 5 で比較 | 出力が受け入れ可能で構造が壊れない |
| Canary | 実タスクの小割合を Sonnet 5 へ送る | エラー、遅延、コストが閾値内 |
| Task split | 複数ファイル実装とテスト修復を先に移す | patch 採用率または retry が改善 |
| Escalation rules | Opus/Fable へ移る条件を定義 | 失敗と高リスクに明確な経路 |
| Fallback review | 安定経路を維持または調整 | fallback 発火が説明できる |
| Default decision | Sonnet 5 を default にするか判断 | 品質とマージあたりコストが目標内 |
製品パスとライフサイクル
関連記事
- 現在の製品情報: Claude Sonnet 5 製品ページ
- 既存 traffic の移行前: Claude Sonnet 5 vs Sonnet 4.6
- 予算影響: Claude Sonnet 5 のコスト影響
- より広いコーディングモデル選定: コーディングエージェント向け LLM 比較
最終提案
Claude Sonnet 5 は coding agent の default 候補として強いですが、すべてのタスクを送るという意味ではありません。低コスト経路で分類と簡単な補助を処理し、Sonnet 5 で実装と修復を行い、Opus/Fable で高リスクを扱い、安定 fallback で本番を守る設計がより安全です。
FAQ
Claude Sonnet 5 は coding agent の default にすべきですか？
タスク分類、fallback、observability があれば強い default 候補です。ただし単純タスクと高リスクタスクは別経路にすべきです。
いつ Opus や Fable を使うべきですか？
アーキテクチャ、セキュリティ、課金、データ、コンプライアンス、反復失敗、長期的な技術判断で使います。
Sonnet 5 は Claude Code 型 workflow に十分ですか？
優先的にテストする価値があります。十分かどうかは patch 採用率、テスト通過率、retry などの実 trace 指標で判断します。
簡単なコードタスクにも Sonnet 5 が必要ですか？
必ずしも必要ありません。説明、整形、小さな補助、大量ドキュメントは低コスト経路で足りることがあります。
コスト超過をどう避けますか？
タスク分類、文脈制限、安定 prompt の cache、retry 監視、明確な失敗条件での昇格が必要です。
最適な fallback は何ですか？
移行中は以前の安定 Sonnet 経路、または検証済みの別 coding model を残します。
最終コードレビューは同じモデルでよいですか？
可能なら別経路を使う方が、実装モデルの blind spot を減らせます。
default 前に何を測るべきですか？
patch 採用率、テスト通過率、retry、tool-call 成功率、fallback、マージあたりコスト、cleanup 時間です。
Sonnet 5 は Opus を完全に置き換えられますか？
その捉え方は避けるべきです。Sonnet 5 は多くのバランス型 coding task を担えますが、高リスクや長期判断では Opus/Fable が有効です。
この記事は製品ページを置き換えますか？
置き換えません。製品ページは現在の製品詳細を扱い、この記事は routing、昇格、fallback 設計を扱います。
