速い判断と熟慮の推論：AI 見積にはなぜ両方が必要なのか

見積を準備している最中に、顧客から次のような確認の連絡が届いたとします。

ブラケット B-214 について、更新後の見積には図面 Rev D をご使用ください。Rev C ではアルマイト処理が必要でしたが、Rev D ではコーティングなしの削り出し仕上げに変更しています。発注数量は引き続き 5,000 個です。仕上げの変更を反映した見積の再提出をお願いいたします。

これを積算担当に回すべき連絡だと判断するのは簡単です。手間がかかるのは見積の更新のほうです。Rev D を確認し、優先される仕様書と照合し、どの工程が変わるかを洗い出したうえで、積算をやり直す必要があります。

この一連の作業には、それぞれ向いている道具が異なります。メッセージを適切な担当に届けるだけなら、素早い分類で足ります。要求事項の解釈には、言語モデルと関連資料が必要になることがあります。コストの変更には、明示的な入力値と計算が必要です。そして最終的な結果は、引き続きエンジニアが承認します。

こうした小さく頻繁な判断は、System One モデルの使いどころです。Nyotta では、このブラケットの確認事項を含む合成のサプライヤーメッセージで Jev をテストし、分類結果と再現性を測定しました。

ここでいう System 1 と System 2 とは

ダニエル・カーネマン（Daniel Kahneman）は、速く直感的な思考である System 1 と、意識的に労力をかけて考える System 2 という区別を広めました。AI のワークフローを設計するうえで役立つたとえであり、モデルの内部動作をそのまま説明するものではありません。『ファスト&スロー』

見積業務でいえば、納期についての苦情を見分けるのは小さな判断です。図面と仕様書が食い違うときにどちらの要求事項を優先するかを決めるには、根拠を集め、食い違いを一つずつ解きほぐす必要があります。両方を同じ種類のモデルリクエストとして扱うと、単純な作業に余計な手間をかけたり、難しい作業への指示が足りなくなったりします。

この区別は、タスクの側にも当てはまります。汎用 LLM は、メッセージを素早く分類することも、時間をかけて問題を推論することもできます。また、どちらにも当てはまらない作業もあります。承認済みの単価に数量を掛ける処理は、モデルの直感に頼らず計算で行うべきものです。

Jev とは？

Jev は、TypeSafe が最初に公開した System One モデルです。評価してほしい情報と、回答の型をあらかじめ定めた質問を渡して使います。ドキュメントに記載されている基本機能（プリミティブ）は、選択肢から一つを選ぶ Choice、評価基準（ルーブリック）に沿って採点する Score、命題を 0 から 1 の値で評価する Noul の 3 つです。Choice と Score は、確率分布と確信度もあわせて返します。TypeSafe ドキュメント

たとえば今回は、メッセージを次のいずれかに振り分けるよう Jev に指示しました。

quality | logistics | estimating | purchasing | review | none

アプリケーション側では、この回答を使って作業を振り分けられます。TypeSafe によると複数の質問は並列に評価されるため、同じ入力について小さな判断をいくつも行いたい場合には、試してみる価値のあるインターフェースです。Introducing Jev

ワークフローに必要なのが判断だけなら、長い説明は要らないこともあります。もっとも、これはインターフェースについてのジョークで、汎用 LLM も構造化された出力を返せます。

テストの内容

2026 年 9 月 21 日、jev-1.13.0 を使ってメッセージ分類とリクエストのレイテンシをテストしました。Jev に渡したのは合成テキストと当社の指示だけで、図面、受注履歴、過去のやり取りは含めていません。期待するラベルは、実行前に決めておきました。

30 件のビジネスメッセージについて、1 回の呼び出しごとに 2 つの Choice 質問を行いました。

1. この依頼はどのチームが担当すべきか？ 選択肢は quality、logistics、estimating、purchasing、review、none です。review は内容を特定できない問題や無関係な問題、none は対応不要と明記された連絡に使います。
2. 情報はどのような状態か？ 選択肢は clear、conflicting、insufficient、no_action です。clear は依頼や問題を特定できるという意味で、事実が検証済みであることや、対応の許可が出ていることまでは意味しません。

メッセージの内容は、不具合、納期遅延、価格改定、食い違う報告、背景情報の欠落、定例の連絡、見積依頼にわたります。複数の問題が同時に含まれる場合は、quality、logistics、estimating、purchasing の順に優先して振り分けるルールとしました。再現性を測るため、各メッセージを 3 回ずつ送信しています。

冒頭のブラケットの確認事項に対して、Jev は 3 回とも estimating と clear を返しました。次のメッセージにも、estimating と clear を返しています。

顧客の仕様書には「割れのある部品は不合格とする」と記載されています。これは受入基準を示したもので、不良品の発生を報告するものではありません。必要な割れ検査を見積に含めてください。

検査要求と、現に起きている不具合とを区別するという、当社の意図どおりの結果です。

指標	結果
チームの選択が当社のラベルと一致	90/90 回（100%）
情報の状態の選択が当社のラベルと一致	87/90 回（96.7%）
3 回すべてで両方のラベルが一致したメッセージ	29/30
3 回すべてで同じラベルの組み合わせを返したメッセージ	30/30（100%）

最後の行は、当社のラベルと一致したかどうかとは別に、ラベルの再現性を測ったものです。選ばれた回答は繰り返しても変わりませんでしたが、確率分布が変わることはありました。入力ごとに 3 回の呼び出しは小規模な一貫性の確認にすぎず、今後のリクエストや将来のモデルバージョンでも常に同じ結果が返ることの根拠にはなりません。

ラベルが一致しなかったのは、次のメッセージです。

昨日御社のご担当の方とお話しした PO 4812 の件について、解決をお願いします。その方から詳細を確認のうえ、次の対応を教えていただけますか。

Jev は 3 回とも review と clear を返しました。当社が期待していたのは review と insufficient です。肝心の問題の中身が書かれていないためです。ただ、当社の定義の書き方では、clear は特定可能な依頼を指すとも読めます。担当者に詳細を確認してほしいという依頼は、それに該当します。Jev の回答にも十分な理由があります。Jev は 90 回中 87 回で当社の期待どおりの回答を返しました。残る 3 回の不一致は、曖昧な質問 1 件を 3 回繰り返したことによるもので、どちらの回答にも妥当性があります。

ワークフローを定義するときには、ここが重要になります。「依頼の内容は理解できるか？」と「問題を解決するのに十分な情報があるか？」は、別々の質問として立てる必要があります。定義の曖昧さは、モデルの確信度では補えません。

質問数を増やしたときのレイテンシ

納品遅れ、検査で見つかった割れ、次回発注分の値上げ要請を 1 通にまとめたメッセージを使いました。そのうえで、割れの報告が含まれるか、納期遅延に触れているか、発注番号が書かれているかなど、16 個の命題質問を用意しました。

最初の質問だけ、最初の 4 問をまとめて、16 問すべてをまとめて、という 3 つのグループで、それぞれ 6 回ずつ呼び出しています。

1 回あたりの質問数	レイテンシ中央値	観測範囲
1	211 ms	176–285 ms
4	198 ms	190–208 ms
16	237 ms	199–290 ms

いずれもネットワークのオーバーヘッドを含むエンドツーエンドの HTTP 計測値です。呼び出しは逐次実行で、アプリケーション側での再試行も、ウォームアップ分の除外も行っていません。今回のテストでは、16 問をまとめて尋ねても 16 倍の時間はかかりませんでした。ただし各グループ 6 回の観測だけでは、本番環境でのスループットや、他のモデルに対する速度面の優位性までは言えません。

このほか、7 件の診断用メッセージをそれぞれ 3 回（計 21 回）送信しており、評価全体では成功したリクエストは 129 件、すべてがローカルでのレスポンス形式チェックを通過しました。診断用メッセージは、指示を乗っ取ろうとする攻撃や無関係な依頼への挙動を確かめるもので、上記のビジネスメッセージの結果には含めていません。

Nyotta での活用方法

Nyotta では、資料の分類・抽出と、数値の積算を分けて処理しています。図面の領域をまず分類してから特徴を抽出し、抽出した特徴にはレビュー用に元の位置情報を残します。積算は専用のコードが担い、こうして得た入力から積算結果を算出し、注意すべき点を警告として示します。

こうすることで、各コンポーネントの役割がはっきりします。モデルはエンジニアリング情報の解釈を助け、積算モデルとコードが数値を算出します。レビュー担当者は、元資料の解釈と積算結果を別々に確認できます。

ブラケットの例で Jev が担うのは、ごく限られた役割です。顧客からの確認事項を分類し、積算担当に振り分けることです。今回の実験では、3 回とも期待どおりの振り分け先を返しました。見積を完成させるには、引き続き実際の図面と仕様書、承認済みのコスト入力、そしてエンジニアの承認が必要です。

汎用 LLM に見積を任せず、Nyotta を使う理由は？

Nyotta も LLM を使っています。 要求事項の解釈、情報の抽出、レビューが必要な点の説明に、LLM の言語理解力と推論力を活用しています。そのうえで見積には、エンジニアリングデータ、定義された積算手法、計算、そして承認が欠かせません。

Nyotta では、図面から抽出した特徴に元の位置情報が残ります。数値の積算、入力のチェック、警告の報告は専用の積算コードが担います。役割を分けているので、レビュー担当者は元資料の解釈と積算結果を、それぞれに適した観点で確認できます。

見積システムでは、次のように役割を明確に分けておくべきです。

タスク	適したツールまたは担当者
要求事項の解釈、確認事項の文案作成	言語モデルまたはマルチモーダルモデル（元資料を参照して確認できる状態で）
範囲を絞った依頼の分類	そのタスク向けに評価したルールまたは判断モデル
食い違う要求事項の整理	関連資料、推論、エンジニアによるレビュー
コストや価格の積算	必要な業務上の入力をそろえた、定義済みの積算モデル
単価、数量、制約条件の適用	コード、計算式、検証ルール
前提条件の受け入れと見積の発行	権限を持つエンジニアまたは承認者

LLM はこれらのツールを呼び出せます。それでも、計算は承認済みの入力に対して実際に実行される必要があり、結果にはその根拠が残っていなければなりません。ブラケットの例なら、アルマイト処理がなくなった分は該当する工程のコストに反映され、新しい価格は積算結果から導かれる必要があります。

Nyotta の価値は、モデルによる解釈と、こうしたエンジニアリングの作業とをつなぐところにあります。Jev のようなモデルは分類のステップに適しています。その有用性がタスクの内容と周囲のチェック体制によって決まる点は、LLM と変わりません。

比べるべきは、実際の引合での結果です。要求事項を出典までたどれるか、コストの入力値を確認できるか、まだ承認が必要な項目を把握できるか。自社チームでそれができるかどうかを確かめてください。