目次
AIエージェントのPoCで、LLMが実際にやっている仕事を1件ずつ数えてみると、意外な事実が見えてくる。問い合わせを「請求」「解約」「技術」のどれに回すか。この書類は承認が必要か。次はどのツールを呼ぶか。人に引き継ぐべきか。呼び出しの多くは、文章を書く仕事ではなく「選ぶ」仕事である。
それでも私たちは、選ぶだけの仕事にも、文章を書くために作られた汎用LLMを使ってきた。答えを自由な文章で書かせ、その中から結果を読み取る。遅く、費用がかかり、正しかったかどうかも測りにくい。PoCでは目立たなかったこの非効率が、件数が数十万になる本番で効いてくる。
2026年9月中旬からの3週間で、この前提を変える製品が4つ続けて出た。文章を生成せず、決められた選択肢の中から確率つきで1つを選ぶ「決定モデル」である。同じ時期にOracleは、AIの推論と業務システムの計算をはっきり分けた実行基盤を発表した。
本稿では、この動きが大企業のAI本番化にとって何を意味するのかを整理する。結論を先に言えば、問われているのは「どのモデルを使うか」ではない。エージェントの仕事を「考える」「選ぶ」「実行する」に分けて設計しているかである。
3週間で揃った「決定モデル」― Jev、Decisions API、Clef、Strands Decider
2026年9月15日から10月1日までに発表された4つの決定モデル。9月15日にTypeSafeのJevが早期提供開始。選択・採点・Yes/Noを確率つきで返し、入力100万トークンあたり0.042ドルで出力は無料。Vercelでは24時間で有料チームの13%が利用した。9月29日にOpenAIのDecisions APIが限定プレビュー。問いとありうる答えを先に定義してモデルに選ばせる。10月1日にCloudflareのClefとClef-flash。Apache 2.0のオープンウェイトで、Clef-flashの応答の中央値は38.8ミリ秒。強化学習で自社向けに調整するサービスも発表。同じ10月1日にAWS Strands LabsのStrands Decider 2B。20億パラメータで手元のGPUやノートPCで動き、中央値は約115ミリ秒。学習データとスクリプトまで公開した
最初に出たのは、スタートアップのTypeSafeである。9月15日、同社は決定モデル「Jev」の早期提供を始めた。創業者のDiogo Almeida氏はOpenAIでChatGPTの指示追従の研究に携わった人物で、DCVCが主導する4,000万ドルのシード資金を得て、2年間の非公開開発を経ての発表だった。
Jevは、業務の状況（状態）と、型の決まった問いを受け取り、選択・採点・Yes/Noの3種類の答えを確率つきで返す。複数の問いは1回の処理でまとめて答え、応答は70〜500ミリ秒。価格は入力100万トークンあたり0.042ドルで、出力は無料だ。開発基盤を提供するVercelは、公開から24時間で有料チームの13%がJevを使い始め、同社のAI Gateway史上最も速く採用されたモデルになったと発表している。
9月29日には、OpenAIが年次開発者会議で「Decisions API」を限定プレビューとして公開した。開発者が問いと「ありうる答え」を先に定義し、モデルはその中から1つを選ぶ。用途として示されたのは、問い合わせの振り分け、内容の分類、そしてエージェントが次にとる行動の選択である。
10月1日には、大手2社が同じ日に続いた。Cloudflareは自社で初めて学習させたモデル「Clef」（270億パラメータ）と軽量版の「Clef-flash」（90億パラメータ）を発表した。いずれもApache 2.0のオープンウェイトで、同社のクラウドでも、自社の環境でも動かせる。同社の計測では、Clef-flashの応答時間の中央値は38.8ミリ秒だった。あわせて、自社データを使った強化学習で決定モデルを調整するサービスも発表し、当初は同社の技術者が顧客の現場に入って支援するという。
AWSのStrands Labsも同日、「Strands Decider 2B」を公開した。20億パラメータと小さく、一般的なGPUで応答の中央値は約115ミリ秒、ノートPCでも動く。重みだけでなく学習データとスクリプトまで公開しており、自社で中身を確かめて作り直せる。
4つの製品の作り手は、スタートアップ、モデルベンダー、クラウド事業者とさまざまだ。それでも出した答えは同じだった。エージェントの中の「選ぶ」仕事は、文章を書くモデルから切り離せる。
何が違うのか ― 「書く」AIと「選ぶ」AI
汎用LLMと決定モデルの比較。汎用LLMは自由な文章を出力し、JSONも文章として生成する。1文字ずつ生成するため遅くなりがちで、入力と出力のトークンに課金される。正誤の判定自体が難しく、標準のAPIでは確信度を得にくい。推論・計画・要約・コードが得意で、考える仕事に向く。決定モデルは決められた選択肢のどれかと確率を返す。応答は数十から数百ミリ秒で、入力のみ課金される。正解表と突き合わせて精度を数値化でき、答えごとに確信度が返るのでしきい値に使える。計算・数え上げ・日付比較・作文は苦手で、選ぶ仕事に向く。確信度は正解の確率そのものではなく、セキュリティ境界にもならない
汎用LLMにも、答えをJSONなどの決まった形式で出させる機能はある。決定モデルとの違いは、形式ではなく作りにある。
汎用LLMは、答えを1文字ずつ「書いて」いる。形式を指定しても、出てくるのは書かれた文章であり、その裏で選択肢ごとにどれだけ確かなのかは、標準の使い方では見えない。これに対して決定モデルは、最初から選択肢そのものを採点する。Strands Decider 2Bは、汎用モデルの文章を生成する部分を外し、選択肢を指し示す小さな部品（約100万パラメータ）に付け替えた構造だ。文章を生成しないので速く、答えは必ず選択肢のどれかになり、選択肢ごとの確率が返ってくる。
大企業の本番化にとって、この違いは3つの意味を持つ。
1つ目は、精度を数字で合意できること。 自由な文章の答えは、正しかったかどうかの判定そのものが難しい。選択肢から選ぶ形なら、過去の業務実績から作った正解表と突き合わせ、「この判断は正解率95%」と数字で示せる。本番化を阻む5つの壁のうち、最初に立ちはだかる「指標の壁」を越える前提が整う。
2つ目は、人に回す線を引けること。 答えごとに確信度が返るので、「確信度が一定以下の判断だけを担当者に回す」という運用が組める。すべてをAIに任せるか、すべてを人が確認するかの二択ではなくなる。
3つ目は、1件あたりの原価が読めること。 Jevは入力にのみ課金され、出力は無料だ。仮に1日10万件の振り分けを行い、1件あたり2,000トークンを入力するとすれば、入力は1日2億トークンになる。Jevの公表価格なら1日約8.4ドル、Clefでも約48ドルの計算になる（いずれも試算）。出力の長さで費用がぶれないため、件数から費用を見積もれる。
ただし、過大な期待は禁物だ。決定モデルは計算、数え上げ、日付の比較、複雑な推論が苦手で、文章も書けない。TypeSafe自身、確信度は「正解である確率」そのものとして読むべきではなく、セキュリティの境界にもならないと明記している。速度や価格の比較も、現時点ではベンダーの公表値が中心で、第三者による検証はこれからだ。決定モデルは汎用LLMの代わりではなく、役割を分けるための部品と捉えるべきである。
Oracleが示した三層の分業 ― 考える・選ぶ・実行する
エージェントの仕事を3つに分ける図。考えるのは汎用LLMで、目的の理解・計画・例外時の立て直しを担う。件数は少ないが1件ごとの価値が高い。選ぶのは決定モデルで、振り分け・分類・次の処理・人に回すかを担う。件数が多く正解表で精度を測れる。計算・実行するのは既存の業務システムで、金額計算・消込・伝票登録を担い、同じ入力なら同じ結果になる。外側には目的・規程・権限・リスク閾値・決裁権限・承認・エスカレーションを定める枠があり、実行ごとに適用した権限・使った根拠・下した判断・実行した取引・結果を記録する
同じ週、業務アプリケーションの側からも同じ方向の発表があった。Oracleは9月29日、エージェント型の業務アプリケーションの実行基盤「Fusion Claw」と、それを使った25本の新しいアプリケーションを発表した。財務の照合と例外処理、人員配置計画、出荷の集約、営業テリトリーの設計といった、基幹業務そのものの仕事である。
Fusion Clawの設計で注目すべきは、仕事の分け方だ。推論・計画・状況に応じた立て直しには最先端のAIモデルを使い、大量の取引の計算と実行は、従来の業務システムの決まった計算に任せる。同じ入力なら同じ結果になる処理を、AIに作文させない。
そのうえで、企業はあらかじめ「Enterprise Operating Envelope」と呼ぶ枠を定める。目的、業務手順、規程、権限、リスクの閾値、決裁権限、承認の要否、エスカレーションの範囲である。実行のたびに「Outcome Receipt」と呼ぶ記録が残り、適用した権限、使った根拠、下した判断、実行した取引、結果が監査できる形で残る。
決定モデルと並べると、エージェントの仕事を3層に分ける形が見えてくる。
- 考える（汎用LLM）：目的の理解、計画、想定外の事態での立て直し。件数は少ないが1件の価値が高い
- 選ぶ（決定モデル）：振り分け、分類、次の処理、人に回すかどうか。件数が多く、正解表で精度を測れる
- 計算・実行する（既存の業務システム）：金額の計算、消込、伝票の登録。同じ入力なら同じ結果になる
これは技術の流行の話にとどまらない。BCGが9月30日に公表した「Applied AI Index 2026」（経営層など1,330人の調査）によれば、AIが生む価値のうちエージェント型AIが占める割合は2025年の17%から2026年は22%に上がり、2030年には39%に達する見込みだ。2030年までにエージェントに実質的な意思決定を任せると答えた企業は42%にのぼる。
ところが、監督、ロールバックの関門、セキュリティ、監査、コストの上限といった統制をすべて備えている企業は、わずか5%だった。BCGは、6つの統制をすべて全社に備えた企業は、1つしか備えていない企業に比べて3倍のエージェント価値を生んでいるとも報告している。
統制をかけるには、何を統制するのかが見えていなければならない。汎用LLMに1つのプロンプトで「考えて、選んで、実行して」と任せた設計では、どこで何が決まったのかが文章の中に埋もれる。仕事を分ければ、判断ごとに精度を測り、権限を割り当て、記録を残せる。三層の分業は、統制をかけられる形にするための設計でもある。
日本企業への示唆 ― 「とりあえず最新モデル」の設計が高くつく
PoCの構成のまま本番に進むと、何が起きるか
日本の大企業のAIエージェントのPoCは、多くの場合、汎用LLMを中心に組まれている。ベンダーに依頼すれば、最も性能の高いモデルを1つ選び、プロンプトで業務の流れ全体を指示する構成が提案されやすい。PoCの段階ではこれで問題ない。動くものを早く見せることが目的だからだ。
問題は、その構成のまま本番に進んだときに表れる。
第一に、原価が読めない。 振り分けのような単純な判断にも、毎回、高価なモデルが長い文章を書く。件数が増えるほど、本番化を阻む5つの壁のうち「コストの壁」が高くなる。予算の稟議で1件あたりの単価を聞かれても、出力の長さ次第で変わるため答えにくい。
第二に、精度の合意ができない。 品質保証や監査の部門から「この判断の正解率は何%か」と問われても、自由な文章の出力では測り方そのものを決めにくい。本番判定の会議が、「なんとなく大丈夫そう」という印象論で止まる。
第三に、決裁規程と対応しない。 日本企業の業務は、金額や案件の種類ごとに「誰が決めてよいか」を細かく定めた職務権限規程で動いている。判断が文章の中に溶けた設計では、どの判断をAIに任せ、どこから人が決めるのかを、規程の言葉で説明できない。ここで止まるのが「ガバナンスの壁」である。
決定モデルの登場は、この3つを同時に解く選択肢が、製品として手に入る段階に来たことを意味する。しかも、CloudflareやAWSのモデルは自社の環境で動かせるオープンウェイトだ。外部のAPIにデータを出せない金融や公共の業務でも、判断の部分だけを社内で動かす構成が取りやすくなった。
一方で、注意も要る。3週間で4製品が出た分野は、半年後に勢力図が変わっていてもおかしくない。特定の製品に業務を深く結びつけるのではなく、判断ごとに「問い・選択肢・正解表」を自社の資産として持っておくことが重要だ。それさえあれば、モデルを替えても同じ物差しで測り直せる。
本番化の設計に入れる4つの実務
本番化の設計に入れる4つの実務。①判断の棚卸し：1件の処理でLLMを何回呼び、そのうち何回が選ぶだけかを洗い出し、選択肢を書き出せる判断は作文させない候補にする。②判断ごとの正解表：過去の実績から数百件の正解データを作り、判断ごとに目標精度を決める。モデルを替えても同じ表で測り直せる（指標の壁）。③確信度のしきい値：確信度が低い判断だけを人に回し、線の高さは決裁規程とリスクで決める。承認の全件チェックをやめ、見るべき件数を絞る（ガバナンスの壁）。④1件あたり原価：考える・選ぶ・実行するの費用を分けて集計し、どこを置き換えれば原価が下がるかを見えるようにする（コストの壁・ROIの壁）
では、PoCを本番に進める企業は何から手をつければよいか。決定モデルを導入するかどうかとは別に、次の4つを本番化の設計に入れることを提案したい。
① 判断の棚卸し：PoCの中の「判断」を数える。 1件の業務を処理する間に、LLMを何回呼んでいるか。そのうち何回が、選択肢を書き出せる「選ぶ」仕事か。これを一覧にするだけで、どこを汎用LLMに残し、どこを切り出すべきかが見える。多くのPoCでは、この一覧がそもそも存在しない。
② 判断ごとの正解表：本番化の基準を数字で合意する。 切り出した判断ごとに、過去の業務実績から数百件の正解データを作り、目標とする精度を業務部門と合意する。たとえば「問い合わせの振り分けは正解率95%以上」。この表があれば、モデルの更新や製品の乗り換えのたびに同じ物差しで測り直せる。指標の壁は、この表を作った時点で半分越えている。
③ 確信度のしきい値：人に回す線を業務の側で引く。 確信度が一定以下の判断だけを担当者に回す。その線の高さを、技術者ではなく業務部門が、決裁規程とリスクに照らして決める。金額の大きい案件は線を高く、定型の案件は低く。承認の全件チェックをやめ、人が見るべき件数を絞ることで、統制と効率を両立させる。
④ 1件あたり原価：判断の単価を分けて記録する。 「考える」「選ぶ」「実行する」のそれぞれにかかった費用を分けて集計する。合計しか見ていなければ、原価が高いときにどこを直せばよいのかが分からない。分けて見れば、どの判断を軽いモデルに置き換えれば原価が下がるかが分かり、経営に示すROIの根拠にもなる。
まとめ ― モデル選びの前に、仕事の分け方を決める
この3週間の動きを並べると、1つの構図が見える。AIエージェントの進化は、より大きく賢いモデルが1つですべてをこなす方向だけでなく、役割の違う部品を組み合わせる方向にも進んでいる。考えるのは汎用LLM、選ぶのは決定モデル、計算と実行は業務システム。その外側に権限の枠を置き、実行ごとに記録を残す。
これは、本番化に苦労してきた企業にとっては朗報だ。精度を数字で合意し、人に回す線を規程の言葉で引き、1件あたりの原価を見積もる。PoCから本番への移行で止まりやすかったこれらの論点に、設計で答えられる道具が揃い始めたからである。
ただし、道具が揃っても、どの判断を切り出し、正解をどう定義し、どこに線を引くかは、各社の業務を知る人にしか決められない。経営会議で問うべきは「どのモデルを採用したか」ではなく、「エージェントの判断を、いくつに分けて、それぞれ何で測っているか」である。
Wizitは、PoCで止まったAIを本番運用とROIまで動かし切る実装パートナーとして、大企業の現場でこうした本番化の設計に取り組んでいます。PoCの中の判断の棚卸しから、正解表づくり、確信度のしきい値と決裁規程の対応づけ、1件あたり原価の可視化まで、業務部門と情報システム部門の間に入って手を動かす形でご支援しています。
---
出典:
- Startup Fortune「TypeSafe AI's Decision Model Jev Becomes Vercel's Fastest Adopted Launch」（2026年9月）、Requesty「TypeSafe Jev explained: how it works, LLM differences and API pricing」
- OpenAI DevDay 2026 における Decisions API の発表（2026年9月29日）
- Cloudflare Blog「Introducing Clef: our open-source decision models, and new RL fine-tuning platform」（2026年10月1日）、The Register「Cloudflare tries to outplay Jev with open-weight Clef models」（2026年10月1日）
- Strands Agents Blog「Introducing Strands Decider 2B: a small, open source, decision model」（2026年10月1日）、SiliconANGLE（2026年10月1日）
- Oracle「Oracle Extends Fusion Agentic Applications with Introduction of Fusion Claw」（2026年9月29日）、Futurum Group「Oracle Fusion Claw: From AI Assistance to Governed Autonomous Execution」
- BCG「AI Is Starting to Pay Off. Almost 50% of Companies Now Generate Value with It.」（2026年9月30日）、BCG「The Formula for Agentic AI Value」（Applied AI Index 2026）