すべてをLLMに任せない。AIシステムにおける「判断」の設計
浦 将平· 13 min read目次
こんにちは。リチェルカの浦です。
TypeSafe AIの「Jev」が登場してから約1か月、各社から「判定AI」と呼ばれるモデルやAPIがリリースされ、世界中で多くの知見が公開されるようになりました。
LLMは文章の理解から分類、情報抽出、推論まで、あらゆる処理を器用にこなせます。開発を進めていると「とりあえずここもLLMに投げれば解決するのでは」と考えたくなる場面は少なくありません。
しかし、「LLMでできること」と「LLMに任せるのが適切なこと」は別ではないか。
今回は、業務システムにAIを組み込むという視点から、新しく登場してきた「判定AI」をどう捉え、LLMとどう役割分担させるべきかについて考えをまとめます。
大量のデータを分類・ルーティングするときにぶつかる壁
日々の業務で発生する多様なデータをシステムで受け取り、その内容に応じて「どの処理ルートに乗せるか」を自動で振り分けるような仕組みを考えます。
この「分類して振り分ける」という処理自体は、LLMにプロンプトを与えれば高い精度で実現できます。しかし、プロトタイプを超えて実業務のスケールで動かし続けることを考えると、いくつか悩ましいポイントが見えてきます。
まず、スループットとレイテンシの蓄積です。
1回あたりのリクエストでは気にならない数百ミリ秒〜数秒の待ち時間も、数万件、数十万件とスケールする環境では、システム全体のパフォーマンスに直結します。また、「どのカテゴリに当てはまるか」を知りたいだけなのに、毎回大きなコンテキストを汎用的なLLMに渡して推論させるのは、トークンコストの面でも過剰になりがちです。
次に、判断の安定性とプログラムからの扱いやすさです。
業務システムに組み込む以上、類似した入力に対しては常に一貫した分類結果が求められます。ここで本当に必要なのは「流暢なテキストを生成すること」ではなく、「あらかじめ決まった選択肢から、適切なものを1つ選ぶこと」です。
自由度の高い生成モデルに対して、プロンプトなどで出力形式を縛り、「判定器」として使うアプローチは手軽です。しかし、求めているタスクの性質に対して、モデルの責務が大きすぎるのではないか。そう考えたことが、判定特化のAIに注目したきっかけでした。
「生成」から「判定」を切り出すアプローチ
最近登場しているTypeSafe AIの「Jev」や、OpenAIの「Decisions API」は、まさにこの課題に切り込むアプローチです。
例えばJevは、文章を自由に生成するのではなく、最初から「構造化された判断」を返すことに特化しています。定義済みの選択肢から選ぶ choice、Yes/Noを判定する noul、段階的に評価する score などが用意されています。
システム設計の視点でこうしたモデルに魅力を感じるのは、単に「軽量で応答が速い」からだけではありません。「判定結果と一緒に返ってくる確信度（Confidence）などの情報を軸に、後続の処理ルートをプログラム側で設計しやすくなる」点にあります。
「この入力は何に分類されるか」だけでなく、「その判定をどこまで信用して自動処理に進めるか」という制御の責務を、プロンプトの中ではなくシステムアーキテクチャ側に持たせやすくなります。
単体での置き換えではなく、システム全体で組む
もちろん、「判定AIは速くて安いから、これまでLLMで行っていた処理をそのまま置き換えよう」というほど単純な話ではありません。
実際の業務データに向き合うと、軽量な判定モデル単体では、どうしても文脈の読み取りが浅くなり、LLMほどの分類精度に届かないケースが出てきます。かといって、すべてをLLMに頼り切ればレイテンシとコストの課題に逆戻りしてしまいます。
ここで重要になるのが、「単一のモデルで勝負するのではなく、複数の技術をどう組み合わせるか」という視点です。
例えば、前段で軽量な判定モデルを走らせ、確信度が高いものはそのまま後続の処理へ流します。そして判断に迷う境界線のケースだけを後段のLLMや別のロジックに引き継ぐ、という段階的な構成が考えられます。個々のモデルの単体性能だけで良し悪しを決めるのではなく、システム全体としてどう精度と速度を両立させるかが腕の見せどころになります。
ただ、この「どの基準で後段に引き継ぐか（閾値の設計）」も一筋縄ではいきません。
誤判定を恐れて基準を厳しくしすぎれば、結局多くのケースが後段のLLMに回ってしまい、前段に判定モデルを置いた意味が薄れてしまいます。実際、ある一定のラインを超えると、基準をどれだけ厳しくしても誤判定率はわずかにしか改善しないのに、追加判定に回る割合だけが急増するといったトレードオフが起きます。
単純に「慎重な設定にすれば安心」というわけではなく、実際のデータ分布を見ながら、精度と処理負荷のバランスが釣り合うスイートスポットを見極める必要があります。
どんなタスクで「判定AI」を検討すべきか
こうした特性を踏まえると、Jevのような判定モデルは、次の3つの条件が重なるタスクで特に検討する価値があります。
- 候補が先に決まっている：カテゴリの分類、問い合わせの振り分け、ステータスの判定など
- 結果をプログラムで扱いたい：処理を通す／止めるの分岐、人間のレビュー要否、優先度の判定など
- 大量に繰り返す：1件あたりの単価やわずかな遅延が、積み重なって効いてくる処理
逆に、選択肢自体をゼロから考えたり、曖昧な背景を深く解釈したりするタスクは、これまで通りLLMに任せるほうが向いています。
それでも、LLMに任せたいところ
判定処理を切り出して考えることは、LLMの利用を減らすこと自体が目的ではありません。むしろ、LLMにしか任せられない領域を見極め、そこにリソースを集中させるための整理です。
ひとくちに「分類」や「判定」といっても、その難易度はさまざまです。
特徴がはっきりしていて比較的容易に判断できる入力もあれば、複数のカテゴリに類似した表現が含まれていたり、前後の文脈を読み取らなければ判断できなかったりする複雑な入力もあります。
このように難易度が異なるタスクを、すべて同じ重厚なモデルに任せる必要はありません。
比較的単純な判定は軽量なモデルやルールベースで高速にさばき、高度な推論が必要な難所はLLMに任せる。さらに、どれだけモデルや構成を工夫しても、すべてのケースを100%正しく判定できるとは限りません。判断が難しいケースや誤判定の発生を前提に、ユーザーからのフィードバックを改善につなげられる仕組みを整えることも、モデル選定と同じくらい重要です。
目指しているのは、特定の技術を盲信したり排除したりすることではなく、それぞれの技術が得意な領域を担当し、システム全体として精度・速度・コストのバランスを最適化することです。
まとめ
今回、Jevをはじめとする判定AIに向き合う中で、「LLMでできること」と「LLMに任せるべきこと」は別物だと改めて感じました。
判定特化のモデルを使えば、無条件に速く、安く、正確になるわけではありません。それでも、「判断する」という処理を独立した責務として切り出し、軽量な判定モデル、LLM、ルールベースの処理を適材適所で組み合わせる設計には大きな可能性を感じています。
大切なのは、何でもLLMに投げることでも、無理にLLMを排除することでもありません。何を、どの仕組みに、どこまで任せるかを適切に設計することです。
AIを実業務へ深く組み込むほど、こうした役割分担の設計が効いてくるのではないでしょうか。