Codexを日常的に使っていると、地味に悩むことがあります。
「このタスク、どのモデルでやるべきだろう？」
難しい実装なら強いモデルを使いたい。一方で、ちょっとした調査やログ整理まで毎回最上位モデルを使うのはもったいない。
たとえば自分の中では、ざっくり次のような使い分けがあります。
- 実装 → GPT-5.6 Sol / high
- 調査 → GPT-5.6 Terra / high
- 開発ログ作成 → GPT-5.6 Luna / high
ただ、毎回Codexを起動する前に、
「これは実装だからSol」
「これは調査だからTerra」
と人間が判断してモデルを切り替えるのも面倒です。
そこで今回、タスクの内容を見てCodexのProfileを自動選択する dev コマンドを作りました。
やりたかったこと
使い方はこれだけです。
dev "ログイン画面を実装して"
すると内部で、
implementation
↓
Codex
↓
GPT-5.6 Sol
↓
reasoning: high
というルートを選びます。
一方、
dev "Cloudflareの代表的なサービスについて調べて"
と入力すると、
research
↓
Codex
↓
GPT-5.6 Terra
↓
reasoning: high
になります。
さらに、
dev "今日の作業をdevlogに残して"
なら、
devlog
↓
Codex
↓
GPT-5.6 Luna
↓
reasoning: high
という具合です。
つまり、自分が指定するのはモデルではなくタスクです。
モデル選択はRouterに任せます。
CodexのProfileを役割ごとに分けた
まず、Codex側に用途別のProfileを用意しました。
概念的には次の3つです。
implementation
→ GPT-5.6 Sol / high
research
→ GPT-5.6 Terra / high
devlog
→ GPT-5.6 Luna / high
ここで重要なのは、モデル名を dev コマンド側にベタ書きしすぎないことです。
dev が決めるのは、
このタスクは implementation
というところまで。
実際にどのモデル・reasoning effortを使うかはCodex Profile側に持たせます。
この構造にしておけば、将来モデル構成が変わったとしても、Routerそのものを書き換えずにProfileだけ差し替えられます。
dev の正体は小さなNode.jsスクリプト
今回作ったRouterは、まだ非常に単純です。
入力されたプロンプトに特定のキーワードが含まれているかを見ています。
たとえば、
if (
/実装|修正|直して|追加して|作って|変更して|リファクタ|fix|implement|add|refactor/.test(
text
)
) {
return {
task: "implementation",
agent: "codex",
profile: "implementation",
mode: "interactive",
};
}
なら実装系。
if (
/調査|調べて|確認して|原因|分析|仕様を確認|読んで|把握|investigate|research|analyze/.test(
text
)
) {
return {
task: "research",
agent: "codex",
profile: "research",
mode: "interactive",
};
}
なら調査系です。
開発ログ系も同じように判定しています。
そして判定結果を使って、
spawn("codex", [
"--profile",
route.profile,
prompt,
]);
のようにCodexを起動します。
つまり現時点では、Router自身がLLMを使っているわけではありません。
かなり原始的なルールベースです。
でも、今のところこれで十分機能しています。
なぜ最初からAIに分類させなかったのか
もちろん、
このタスクは
implementation
research
devlog
のどれですか？
と小型モデルに毎回分類させることもできます。
ただ、今回はあえてやりませんでした。
理由は、モデル選択のためだけに毎回モデルを呼ぶと、Router自体のオーバーヘッドが増えるからです。
「実装して」
「調べて」
「ログに残して」
くらいなら、正規表現でかなり判定できます。
まずは、
明確なもの
→ ルールで判定
曖昧なもの
→ 将来的に小型モデルへ
という構成で十分だと考えています。
たとえば、
認証周りを調べて、問題があれば直して
のようなタスクは少し複雑です。
「調べて」があるのでresearchにも見えますが、最終的にはコード変更を伴うためimplementationとして扱いたい。
今回のRouterでは、実装系の判定を調査系より先に置くことで、
write intent > research intent
という優先順位を持たせています。
作ってみて一番面白かったこと
今回面白かったのは、Codexを「モデルを選んでから使うツール」と考えなくなったことです。
以前は、
タスクを考える
↓
モデルを選ぶ
↓
Codexを起動する
↓
依頼する
でした。
今は、
タスクを考える
↓
dev に投げる
↓
Routerがモデルを決める
↓
Codexが起動する
です。
人間側のインターフェースから「モデル選択」が消えました。
これは小さい変化ですが、かなり感覚が違います。
モデルではなく「仕事」を指定する
AIツールを使っていると、ついモデル名を中心に考えてしまいます。
今日はSolを使う
Terraで十分かな
Lunaにするか
でも、本来ユーザーが考えたいのはそこではありません。
考えたいのは、
これは実装
これは調査
これはレビュー
これはログ整理
という仕事の種類です。
モデルの性能や利用枠、コスト特性はRouter側が知っていればいい。
今回の dev は、それをかなり小さな形で実装したものです。
今後やりたいこと
現時点では、
implementation
research
devlog
の3種類程度ですが、今後はもう少し細かく分けたいと思っています。
たとえば、
implementation
debugging
research
architecture
review
testing
docs
devlog
git
あたりです。
そうすると、
新機能実装
→ Sol high
コードベース調査
→ Terra high
README更新
→ Luna
アーキテクチャ判断
→ Sol xhigh
のような使い分けができます。
さらに面白そうなのが、ルーティング結果を記録することです。
{
"task": "implementation",
"selected_model": "sol",
"override": false
}
のようなログを蓄積していけば、
「実際にはどのタスクでどのモデルを使っているのか」
「Solを使ったけれどTerraで十分だったケースはどれくらいあるのか」
といった分析もできます。
将来的には、
タスク内容
+ repoの規模
+ 変更範囲
+ 過去の成功率
+ モデル利用枠
まで見てモデルを決めるRouterにしても面白そうです。
Coding Agentを使う時代の「モデルルーター」
AIアプリの世界では、タスクによってLLMを使い分けるModel Routingという考え方は珍しくありません。
ただ、自分が今回やったのは、それを日々のCoding Agent利用に持ち込むことでした。
dev "やりたいこと"
だけ入力する。
あとはRouterが、
どのProfileか
どのモデルか
どのreasoning effortか
を決める。
まだ非常に小さな仕組みですが、この方向はかなり気に入っています。
今後Coding Agentの種類やモデルがさらに増えるなら、人間が毎回モデルを選択するより、
「仕事を入力したら、適切なエージェントとモデルが選ばれる」
という形のほうが自然になるのかもしれません。