AIコーディングの世界では、役割の異なる2つのモデルを組み合わせる構成が定番になりつつあります。
賢いモデルが計画を立てて、安いモデルが実際のコード編集を担当する。
いわゆるプランナーとエグゼキューターの分業です。
先日、この構成に関する興味深い投稿をRedditで見かけました。
主張はこうです。
「実行役のモデルは賢い必要がない。むしろ、エラーに対して素直に反応するモデルを選ぶべきだ」と。
なるほどと思わされる内容でした。
そこで本記事では、その投稿とコメント欄の議論を紹介します。
プランナーとエグゼキューターの分業構成
投稿者の構成は、よくあるパターンでした。
まず、高性能なモデル（投稿ではV4 Proと呼ばれるモデル）が計画と仕様書の作成を担当します。
そして、安価なモデルがコードの編集やツール呼び出しを引き受けるという役割分担です。
ここで多くの人がやりがちなのが、実行役のモデルを次々にアップグレードすること。
新しいモデルが出るたびに「賢い方が良いはず」と入れ替えていく。
投稿者も同じことをしていたそうです。
ところが、結果はほとんど変わらなかったと言います。
選ぶ基準は「エラーへの反応」
では、何が結果を変えたのか。
投稿者いわく、エラーに対する反応の良し悪しで選ぶようになってからだそうです。
理想の実行役は、次のように動くモデルです。
失敗したテストやコンパイルエラーを渡されたら、その箇所だけを直す。
そして、そこで止まる。
一方、避けたいのは正反対のタイプです。
同じエラーを見て「本当の問題は別の場所にある」と勝手に判断する。
さらに、3つのファイルをリファクタリングした挙げ句「完了しました」と報告してくる。
こういうモデルは実行役に向きません。
ここで皮肉なのが、後者のタイプの方がベンチマークでは高スコアを出しがちだという指摘。
つまり、賢さが余計なお節介につながるわけですね。
ベンチマークの数字だけでモデルを選ぶことの危うさを感じさせます。
具体例として挙がっていたモデル
投稿者が実行役に据えていたのは、Ling-3.0-flashというモデルでした。
総パラメータは124Bです。
ただし、トークンあたりのアクティブパラメータは約5Bという構成になっています。
つまり、決して最高性能のモデルではありません。
しかし、難しいエラーを渡すと、そのエラーだけを修正します。
そして、余計な場所をいじりません。
この「脱線しない性質」が実行役として都合が良かったそうです。
ただし万能ではありません。
曖昧な指示を与えれば、自信満々に間違ったことをやる。
この点は他のモデルと変わらないと投稿者も認めています。
成果を決めたのはハーネスだった
投稿の核心は、実はモデル選びの話ではありません。
投稿者が得た改善の大半は、モデルではなく「ハーネス」から来ていた。
これが投稿の結論です。
ハーネスとは、モデルを取り巻く作業環境の仕組みのこと。
具体的には、次のような要素を指しています。
- 厳格な型定義
- 充実したテスト
- 作業を小さなステップに分割すること
- 何かがパスするまで先に進ませないゲート
この仕組みが整うと、どうなるか。
実行役にどのモデルを置くかが、ほとんど問題にならなくなったそうです。
つまり、モデル選びに悩む前に環境を整えろ、というわけです。
これがこの投稿の一番の学びだと感じました。
コメント欄では反対意見も
面白いのは、コメント欄の反応が一枚岩ではなかったことです。
Ling-3.0-flashを好意的に評価するコメントもありました。
しかし、正反対の報告もあったのです。
あるコメントでは、Ling 3 flashは実装タスクにおいて最も怠惰なモデルだったと指摘されています。
作業を途中で切り上げて、早々に終了してしまう傾向があったそうです。
そのコメント主が使っている構成も紹介されていました。
API利用時は、V4 Proをプランナーに置きます。
そして、V4 Flashをビルダーにするという組み合わせです。
一方、コストを抑えたい場合は別の構成でした。
無料のオンラインLLMチャットサービスをプランナーにして、Qwen 3.6 35B A3Bをビルダーに置くという使い分けです。
他にも、実行役にmimo 2.5を使っているという声や、Lagunaを推す声もありました。
同じモデルでも、評価が真っ二つに割れる。
これはハーネスや使い方の違いが結果を左右している証拠かもしれません。
投稿者の主張を、コメント欄が図らずも裏付けている格好です。
まとめ
Redditの投稿から得られる教訓を整理しましょう。
まず、実行役のモデルは賢さではなくエラーへの反応で選ぶこと。
エラーを渡されたら該当箇所だけを直して止まる。
そんな「派手に失敗して素直に直す」モデルが理想です。
そして、それ以上に重要なのがハーネスの整備です。
厳格な型、テスト、小さなステップ、パスするまで進ませないゲート。
この仕組みさえあれば、モデル選びの重要度は下がります。
ベンチマークのスコアを追いかけて、モデルを乗り換え続ける。
それよりも、まず環境を整える。
AIコーディングの生産性を上げたいなら、この順番を意識してみてはいかがでしょうか。
