開発者は LLM をアシスタントとしてだけでなく、アプリケーションロジックの一部としても使うようになってきました。モデルがプロダクトの外側に置かれるのではなく、これまでコードやルール、より狭いアルゴリズムが担っていた仕事を引き受けるケースが出てきています。
これを LLM as backend と捉えてみてください。モデルはユーザーが手に取るツールではありません。システムが依存する仕事をこなす、システムの中の一部品です。
これはソフトウェアの抽象化でこれまでに起きてきた動きとよく似た変化です。開発者はすべてを最下層で書くのをやめ、より高いレベルのプリミティブで作業するようになりました。モデルはそのプリミティブのひとつになります。明示的なロジックを書かなければならなかった層の仕事を引き受けるのです。
この変化が今リアルに感じられるのは、モデルが十分に賢く、十分に安く、十分に速くなり、これまで手で実装していた狭いプロダクトロジックを吸収できるようになったからです。
言いたいのは、耳あたりの良いラベルを増やしたいということではありません。モデルがバックエンドロジックの一部になった以上、モデルを選ぶ基準もまた変わるべきだ、ということです。
モデルがアプリケーションロジックの一部なら、問うべきはもはやどのモデルが一般的に最も賢いかではありません。この特定の仕事を、システムにとって十分な水準でこなせるのはどのモデルか、に変わります。
これは開発者がソフトウェアスタックの他の部分についてすでにやっている考え方です。抽象的に最強の部品をいつも選ぶわけではありません。役割と制約と稼働環境にふさわしい部品を選びます。
データベースはアクセスパターンで選ばれるのであって、理論上の最大スループットで選ばれるのではありません。キューは配信保証で選ばれるのであって、機能の数で選ばれるのではありません。キャッシュは追い出しの挙動で選ばれるのであって、ベンダーの評判で選ばれるのではありません。振り返ってみれば、同じ理屈がモデルにも当てはまるのは当たり前に思えます。
一般的な知能はいつも見るべき指標とは限りません。仕事への適合こそが指標です。
プロダクトのタスクの多くは、終わりのない研究課題ではありません。範囲の定まったタスク、つまり制約された変換、タスク固有の分類、狭い領域の支援、構造化された意思決定の補助、繰り返される実装の手助け、ワークフロー固有のロジック、予測可能な入出力の対応づけに近いものです。
一定のフォーマットの文書から構造化データを抽出する機能を作っているなら、それは範囲の定まったタスクです。問い合わせを固定の分類体系に振り分ける機能を作っているなら、それも範囲の定まったタスクです。特定のライブラリを正しく使う、OAuth の設定パターンを確実に踏む、狭い種類のリファクタリングを行うといったコーディングのワークフローも、やはり範囲の定まったタスクです。
こうしたタスクでは、広い汎用性よりも、一貫性、コスト、レイテンシ、制御しやすさ、そして同種の仕事を繰り返し上手にこなせることのほうが効いてきます。タスクには形があります。モデルはその形に合っているべきです。
タスク特化の小さなモデルを支持する理由はコストだけではありません。それは事実ですが、話としては浅すぎます。
より強い理由はタスクへの適合です。特定の反復的なタスク向けに学習またはファインチューニングされた小さなモデルは、低いレイテンシ、予測しやすいコスト、容易なデプロイ、制約の厳しい環境への適合、挙動のより強い制御、そしてプロダクトのワークフローへの自然な組み込みをもたらしうるのです。
モデルがシステムの部品であるなら、部品としてふるまう必要があります。つまり、信頼でき、観測でき、運用できる必要があります。一般的な能力はわずかに劣っても、特定のタスクで明らかに一貫しているモデルのほうが、エンジニアリング上の良い選択であることがあります。
コストは重要ですが、それは適合の下流にある結果であって、主たる論拠ではありません。主たる論拠は、モデルは任された仕事の層に見合っているべきだ、ということです。
フロンティアモデルは今も多くの場面で正しい選択です。広い計画立案、曖昧な要件、開かれた推論、多段のオーケストレーション、汎用のコーディング支援。これらはフロンティアモデルの幅と深さが本当に効く領域です。これは譲歩ではなく、現実の重要な一部です。
対比になるのは、広いオーケストレーションと狭い実行です。コーディングエージェントのオーケストレーション層、つまりコードベースについて推論し、変更の手順を計画し、曖昧な要件を扱う層には、フロンティアモデルが正しい選択かもしれません。ですが特定のライブラリの正しい使い方、OAuth の設定パターン、狭い種類のリファクタリング、制約のある実装タスクには、タスク特化の小さなモデルで十分かもしれません。
これらは競合する主張ではありません。同じシステムの異なる層であり、それぞれ要件が違うだけです。問いはどのモデルが勝つかではありません。どのモデルがどの層に合うか、です。
狭いプロダクトタスクにフロンティアモデルを使うことは、間違いではないにしても過剰仕様であることがあります。そのタスクにそこまでの幅は要りません。プロダクトはその追加の汎用性から十分な利益を得ていません。システムは、意味のある形では使っていない能力に対して支払っています。
開発者は他の文脈での過剰仕様をすでに理解しています。すべてのサービスに最も複雑なインフラが要るわけではありません。すべての部品に最も柔軟なアーキテクチャが要るわけではありません。すべての機能に最も強力なツールが要るわけではありません。タスクが求める以上に高機能なツールを選ぶのは、見慣れたエンジニアリング上の失敗であって、安全なデフォルトではありません。
コストとレイテンシのトレードオフが正当化しないかもしれません。運用の複雑さが正当化しないかもしれません。そして場合によっては、フロンティアモデルの余分な汎用性が、狭くきちんと定義されたタスクの挙動をかえって予測しにくくすることもあります。
適合は今も重要です。ずっとそうでした。
どのモデルが最良かと問う代わりに、開発者はこう問うべきです。システムのこの部分に実際に必要な能力の水準はどれくらいか。本当の制約は何か。このタスクが要求する品質の基準はどこか。どのモデルならこの機能を現実的に運用できるか。
正しい能力の層は、手に入る最上位の層ではありません。仕事に見合う層です。リーダーボードに適合したモデルではなく、仕事に適合したモデルこそが、システムのその部分に置かれるべきモデルです。
この捉え方は、システム全体について考えることも容易にしてくれます。層ごとに要件は違います。広い推論が要る層もあれば、狭い信頼性が要る層もあります。モデルを層に合わせるのは妥協ではありません。良いシステム設計です。
LLM が普通のソフトウェアの一部になるにつれ、モデルの選択も他のエンジニアリング上の判断に似てくるはずです。「抽象的に最も高性能な選択肢は何か」ではなく、「システムのこの部分に実際に必要な能力の水準はどれくらいか」。多くの場合、その問いが導くのは手に入る最も賢いモデルではなく、仕事に合うモデルです。
