エージェントがLLMに聞いていることの大半は、はいかいいえだ
By Surya Pratap
2026年9月21日
11 min read
AI & Technology
2026年9月21日
11 min read
四つの判断と一つの文Hover to explore製品発表を、その測定値ではなく前提のほうで読む価値がある場合がときどきある。これは前提が正しいと思える一方で、数字のほうは社外の誰も確かめていないという珍しい組み合わせで、丁寧に切り分けて読む必要がある。
本記事は、2026年9月17日公開の Sydney Runkle と Hunter Lovell による LangChain「Building a harness with Jev」、TypeSafe AI 自身の発表、API の実践ガイド、そしてMindStudio による懐疑的な読みに基づく。以下の性能数値はすべて TypeSafe 自身のものである。それが何を意味するかは第7節に書いた。第2節以降の議論は筆者のものである。
TypeSafe AI が Jev を公開した。同社はこれを System One モデルと呼ぶ。テキストを生成するためではなく、ソフトウェアがそのまま使える速く構造化された判断を下すために作られたモデルの一群、という定義だ。LangChain は同じ週に、その上に組んだハーネスを公開した。
仕組みの形はこうだ。状態と型付きの質問の集合を渡すと、確率を添えて一度にすべてに答える。質問の型は三つ。
Choice — 最大255個の選択肢から一つを選び、選択肢ごとの確率を返すScore — 2〜10段階の順序尺度の上に入力を置くNoul — はいかいいえを、0から1の単一の数値として返すfrom typesafe_sdk import Choice, Noul, TypeSafeClient
client = TypeSafeClient()
response = client.system_one(
state={"ticket": "I was charged twice"},
questions={
"department": Choice(
instructions="Which team handles this",
criteria={"billing": "Payment issues", "technical": "Bugs"},
),
"urgent": Noul(instructions="Message conveys urgency"),
},
)
働いているのは二つの設計上の違いだ。モデルは自己回帰的にではなく、すべての出力を一回のクエリで並列にサンプリングする。レイテンシの主張はここから来る。そして RLCD、較正された判断のための強化学習と同社が呼ぶ方法で訓練されている。これは人間の評価者が承認する答えに向けて最適化するのではなく、その答えが実際に正しい頻度を反映した確率を伴った答えに向けて最適化する。
公表されている数字は、エンドツーエンドで70〜500ミリ秒、入力100万トークンあたり0.042ドルで出力は無料、そして同社自身のワークフロー評価で比較対象のフロンティアモデルに対し 193.6倍速く444.6倍安い。コンテキストは合計64kトークン、状態だけで32kが上限である。
ベンダーを取り払って、エージェントのターンが実際に何でできているかを見てほしい。
どのツールを呼ぶべきか。 列挙値だ。11個のうちの一つ。
この行動は止めるべきほど危険か。 はいかいいえ。
タスクは終わったか。 はいかいいえ。ループのたびに毎回問われる。
再試行か、上位に回すか、諦めるか。 これも列挙値。
そして最後に一度だけ、答えを書く。これには言語モデルが要る。ここで挙げた話はどれもそれを置き換えない。
エージェントのターンで高くつくのは、書くことではめったにない。それぞれがモデル呼び出し一回分かかる、四十の小さな判断のほうだ。
その判断のどれもが今は、文章を書くために作られ、トークン単位で課金され、自己回帰的に生成するモデルを通り、そのあとパースされて一語に縮められている。出力全体が1バイトに収まる仕事に、生成の値段と生成の待ち時間を払っているわけだ。
この主張を検討するのに費用はかからず、TypeSafe の数字が正しいかどうかにも依存しない。OLTP と分析を分けるのと、あるいはキャッシュをデータベースから分けるのと同じ動きだ。二つのアクセスパターンが一つの部品をまとっていた。二つだと誰もまだ気づいていなかったからである。
速度とコストの優位は競争で削られる。二四半期もすればこの種の製品は四つになり、価格は二番目に安いものが決める。私が実際に土台にするのは較正のほうだ。
実務上の違いはこうだ。LLM に「これは緊急か」と聞くと 緊急 が返る。較正された分類器は 0.71 を返す。
ラベルは分岐をくれる。確率はしきい値をくれる。そしてしきい値はつまみである。
0.9 を超えたら遮断、0.6 以上はレビューに回す、それ未満は記録だけ。質問は一つ、挙動は三つ、追加のモデル呼び出しはゼロ。素のラベルでは挙動は一つしかなく、適合率と再現率を取引する手段もない。
これはAnthropic の監視指標についての記事で主張した制御そのものだ。人間が週に何件レビューするかを先に決め、その件数になるまでしきい値を動かす。ラベルではこの算術ができない。
確信度が低い場合こそ、遅くても能力の高いモデルに回すべき事例である。今日のルーティングの多くは入力から複雑さを推し量るが、較正されたスコアは出力についての不確かさを測る。本当に知りたかったのはそちらだ。
重要なのは較正されたという語である。どんなモデルでも数字を求めれば数字を出すし、トークンの softmax 確率は正しさについての主張ではない。Jev の較正が本当に成り立つかどうかは、まさに第三者の測定を要する種類の問いであり、そしてその測定はまだ一度も行われていない。
TypeSafe は Jev の構造化出力エラー率が保証で0%だと述べており、これをベンチマーク結果ではなくアーキテクチャの数学的性質として提示している。文字どおりに取るなら、そして疑う理由もないが、それは宣言したスキーマの外にあるものをモデルが返せない、という意味だ。
形は正しさではない
型についての保証は、答えが整形式であることの保証であって、正しいことの保証ではない。11個のツールのどれを呼ぶかと問えば必ず11個のうちの一つが返る。そしてそれが毎回11個のうちの誤ったほうでありうるし、知らせてくれるパースエラーは出ない。ここははっきりさせておく価値がある。「決して幻覚を起こさない」という説明がすでにこのモデルについて流通しているが、それが意味するのは聞こえよりずっと狭い。決して形を幻覚しない、というだけだ。自信満々に誤って分類することを、このアーキテクチャは何一つ妨げない。
とはいえ、整形式でない出力をなくすのは実運用上の本物の利得だ。エージェントを出荷したことがあれば理由は分かる。パース失敗による再試行の経路には、驚くほどのレイテンシとコストと不可解な挙動が住んでいる。障害の一類型をまるごと消せるのは、それが最も心配な類型でなくても価値がある。
ここで製品を評価する前に、その前提が自分のシステムを言い当てているかを確かめてほしい。作業は一時間で、答えは最終的にどのベンダーを使うことになっても有効だ。
エージェントが行うモデル呼び出しをすべて計測し、分類する。
| 区分 | 判定 | 何が分かるか |
|---|---|---|
| 判断 | 出力が列挙値、真偽値、数値に落とされる | 分類器に移せる候補 |
| 抽出 | 出力が、より大きな入力から取り出した小さな固定スキーマ | スキーマが安定していれば候補 |
| 生成 | 出力が人間か別システムが読む散文 | 言語モデルに残す |
| 推論 | 出力が複数段階の計画で、途中の段階に意味がある | 残す。おそらく最良のモデルに |
そのうえで二つの数を出す。最初の二区分が占める呼び出し数の割合と、費用の割合である。私が見てきたエージェント構成の多くでは、前者は高く、後者はそれより低いが比例にはほど遠い。判断はたいてい短いプロンプトなので単価は安く、しかし数が多いので合計では効き、さらに毎ループの critical path に乗るのでレイテンシを支配する。
私が使う目安。
判断と抽出が呼び出しの三分の一に届かないなら、これは最適化であり、他に直すべきものがあるうちは放っておいてよい。三分の二を超えるなら——ツールループを持つものではこれが普通だ——あなたのアーキテクチャにはすでに二つの負荷が同居しており、それを分けられるかどうかはベンダーの選択一つの距離にある。
Jev は早期アクセスなので、実務上の問いは今何ができるかだ。労力の小さい順に三つ。
すでに聞いている質問をまとめる。 ここで一番安上がりな改善は新しいモデルとは無関係だ。同じ状態について四つのことを決めるのにループが四回別々に呼び出しているなら、構造化スキーマで四つを一回にまとめる。状態の代金を四回でなく一回だけ払えばよくなる。
簡単な判断は今すぐ小さなモデルへ移す。 「タスクは終わったか」に最良のモデルは要らない。制約付きデコードを添えた小さなモデルで関門の質問はたいてい足りるし、切り替える前に現行モデルとの不一致率を測れる。
確率が手に入る前にしきい値を作っておく。 二段の関門——上は遮断、間はレビュー、下は記録——を、中段が仮実装のままでも書いておく。較正されたスコアが来たとき、制御フローを設計し直すのではなく数値を差し込むだけで済む。
評価セットをモデル非依存に保つ。 いつか判断を分類器へ移したくなったとき、それを二週間ではなく二時間の仕事にするのは、その判断の入力と正解をラベル付けした集合があることだ。多くのチームはエンドツーエンドのタスクについてはこれを持っていて、その内側の個々の判断については何も持っていない。
最後のものが本当の前提条件だ。悪化したかどうかを知る手段なしに、判断を安いモデルへ安全に移すことはできない。そしてその集合を作るのは、System One モデルが登場しようとしまいと、自分に対して負っている作業である。
ここにある性能数値はすべて自己申告だ。 独立した第三者が Jev を測定してはいない。モデルは順番待ちの向こうにあり、評価は公開ベンチマーク上のものではなく、比較の数字はその製品を売る会社から出ている。だからといって偽だということではない。未検証だということであり、どのベンダーの自社数値にも当てる割引を、そのまま当てるべきだということだ。
TypeSafe は自ら方法論上の限界を公表しており、それは本物の限界だ。 ワークフロー評価は同社のモデル能力チームが作っており、偏りが入りうると同社自身が認めている。比較の基準はフロンティアモデル二つの平均である。デモには人間に読める鍵を使った簡略化されたクエリが用いられた。公表したことは評価に値するが、だからといって影響が消えるわけではない。
「193.6倍速く444.6倍安い」は上限であって期待値ではない。 TypeSafe 自身がそう言っている。現実の利得の高いほうの端だと見込んでいる、と。見出しの数字を自分が得られる値として引くのは、同社自身の但し書きを読み違えることになる。
筆者は使っていない。 以上はすべて公開資料を読んだものだ。私が勧めているのは設計上の問いであって、製品ではない。
最も検証されてほしいのは較正の主張だ。 工学的に本当の価値がある部分であり、同時に外から確かめるのが最も難しい部分でもある。ベンダーのワークフローで成り立つ較正曲線が、あなたのところで成り立つとは限らない。試すなら、重要な何かにしきい値を結ぶ前に、自分のデータで較正を測ること。
この発表は数字をめぐって論じられるだろうし、その論争は当面、社外の誰にも決着させられない。
数字に依存しない部分は、分解のほうである。エージェントのループはほとんど判断エンジンであり、最後に書き手がボルトで留めてある。そして業界はこの二年、その両方を同じ部品から供給してきた。使える部品がそれしかなかったからだ。誰かが気づくはずだった。いまその観察にベンダーと訓練手法と LangChain の統合がぶら下がっていることは、観察そのものより面白くはない。
自分のエージェントを計測し、モデル呼び出しのうちどれだけが、受け取った直後に単一の値へ縮められるものを返しているかを調べてほしい。その割合が三分の二なら、あなたはすでに二つの負荷を抱えている。そしてそれはいずれ分けるほかなかった。二つ目を誰が売ることになろうと。
出典：Sydney Runkle と Hunter Lovell による LangChain「Building a harness with Jev」、2026年9月17日。ハーネスとしての位置づけ、質問の型、ルーティングとガードレールの用途について。TypeSafe AI「Introducing System One Models & Jev」。System One の定義、並列サンプラー、RLCD、70〜500ミリ秒のレイテンシ範囲、入力100万トークンあたり0.042ドルで出力無料、ワークフローの193.6倍と444.6倍、型エラーゼロの主張、そして第7節で引いた方法論上の但し書きは、いずれも TypeSafe 自身のもの。Jev の実践ガイド。SDK の形、Choice の255選択肢という上限、合計64kと状態32kというコンテキスト上限について。MindStudio「RLCD vs RLHF」。独立した検証が一切ないことについて。分解の議論、速度より較正を採るべきという主張、形と正しさの区別、そして推奨事項はすべて筆者のものである。この話が乗っているコストの仕組みはエージェントが読んだファイルはすべて請求に残るを、しきい値の議論はAnthropic のエージェント監視の数字を参照。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
