11月7日、Kiro.devが「How Kiro Auto uses model cascading to match the model to the work」と題した記事を公開した。この記事では、AIコーディングアシスタント「Kiro」のAutoモードが採用する「モデルカスケード」という技術——セッションの難易度に応じてモデルを動的に切り替えるアーキテクチャ——について詳しく紹介されている。

モデルは最初から決めなくていい

LLMを使ったコーディングエージェントで生じる典型的なジレンマがある。強力なモデルを最初から使えばコストが嵩む。非力なモデルを選べば複雑なタスクで詰まる。しかし、タスクの難易度は開始時点では分からない。「日付パーサーのバグ修正」が、タイムゾーン前提の問題として3つのモジュールに波及するリファクタリングに化けることもある。逆に、大きく見えたタスクが2行の変更で終わることもある。

Kiroが採用したアプローチは「セッション開始時にモデルを1つ選ぶ」のをやめることだ。

カスケードの仕組み

モデルカスケードとは、1回のエージェントセッション中にモデルを段階的に切り替える手法だ。Kiro Autoは以下の4ステップで動作する。

1. 軽量モデルからスタート。 全セッションは初期モデル（efficient initial model）で始まる。多くのタスクはこのモデルだけで完結する。

2. バックグラウンドで独立レビュー。 セッションとは別のモデルが、非同期でこれまでの作業軌跡をレビューする。セッションはこのチェックを待たずに進行し続ける。作業中のモデルが自分の進捗を自己採点しない点が重要だ。

3. ハンドオフ。 チェックが「同じコードを繰り返し探索している」「完了済みの作業をやり直している」といった非効率の兆候を検出したとき、より高性能なモデルにセッションを引き継ぐ。引き継ぎはそれまでの作業内容を持ち越すため、最初からやり直しにはならない。

4. 必要なら繰り返す。 最上位モデルに達するまで繰り返せる。現時点では上方向のみ（下位モデルへの引き戻しは将来の課題）。

「チケットに取り組むエンジニアと、傍らでレビューする人間」というアナロジーが記事中で使われている。エンジニアは自分の進捗を自分で採点しない——それはレビュワーの仕事だ、という設計思想だ。

ベンチマーク結果：タスクの8割は初期モデルで完結し、残り2割でハンドオフが発生する

KiroチームはDeepSWE v1.1で3つの構成を比較評価した。DeepSWE v1.1はDatacurveが公開する長期ソフトウェアエンジニアリングベンチマークで、実際のGitHubリポジトリから収集した複数ステップにわたるタスクを対象に、エージェントの問題解決能力を測るものだ。SWE-benchと並んでコーディングエージェント評価の文脈で参照されることが多い。各構成はベンチマーク全体を3回独立して実行している。

カスケードは69.37%を達成した。高性能モデル単独（70.57%）とほぼ同等（差は誤差範囲内）で、初期モデル単独（63.96%）より5.40ポイント上回る。さらに、3回の実行間でのばらつきが最も小さかった。

タスクの内訳も重要だ。80.48%のタスクは初期モデルだけで完了し、ハンドオフが発生したのは19.52%（約5タスクに1つ）にとどまった。

ハンドオフが発生したタスクには共通の傾向があった。型・API・CLI・設定など複数レイヤーにまたがる変更や、キャッシュ・状態保存・実行順序に依存する挙動など、全体を通して正確に動かすことが難しい変更だったという。

エンジニアとして気になるポイント

このアーキテクチャで設計上の肝となるのは独立チェック（independent check）の存在だ。作業モデルとは別のモデルがセッションを監視することで、「自分の出力を自分で評価する」という自己採点バイアスを排除している。LLMが同じ場所をぐるぐると試行し続けるいわゆる「ループ問題」への対策として、外部オブザーバーを非同期で走らせる構成は実装上の参考になる。

なお、チームやエンタープライズ向けにモデルガバナンスの仕組みも用意されており、管理者がAutoで使用可能なモデルを制御できる。ハンドオフ先も同じガバナンス設定に従う（詳細はモデルガバナンスドキュメントを参照）。

詳細はHow Kiro Auto uses model cascading to match the model to the workを参照していただきたい。