確率は、実行許可ではない――型付き判断を業務につなぐために
AIが「出荷してよい」と答えた。その答えは、どの条件を満たしたとき、組織としての実行許可になるのだろうか。
2026年9月15日、TypeSafe AIは、ソフトウェアが直接利用できる型付き判断を返すモデル「Jev」を早期アクセスとして公開した。同社が「System One Models」と呼ぶ設計は、文章の生成ではなく、選択・評価・確率をプログラムの処理へ組み込むことに重点を置く。［1・2］
本稿で考えたいのは、Jevが既存のモデルを置き換えるかどうかではない。モデルが判断を返すことと、組織がその判断を採用し、実行し、結果を確認することの間に、どのような接続が必要かである。
AI判断と実行をつなぐ4つの層
1．Jevの設計は、判断と制御の役割分担を明示する
Jevの公式資料では、状態と質問を入力し、あらかじめ定義した選択肢や評価尺度に沿う値を受け取る。複数の問いは分解し、その結果をどう組み合わせるかはコードで制御する設計が示されている。［2］
これは「AIが初めて判断できるようになった」という話ではない。確率を返す分類器は以前から存在し、TypeSafe自身も比較実験では、LLMを型付き判断へ変換するラッパーを使用している。Jevの登場だけから、「文章を生成するAI」と「判断するAI」が完全に別物になったとは言えない。［1・3］
注目したいのは、モデルが返す判断材料と、それを行動へ変換するコードの役割分担が、製品の設計として明示されていることだ。
実際、TypeSafeの公式資料は、行動のリスクに応じて閾値を変え、自動処理・確認・保留を使い分けることを説明している。したがって「確率と実行許可を分ける」という論点は、Jevに欠けているものを外から指摘するだけの話ではない。Jev自身が示す役割分担を、業務上の権限や実行条件まで具体化する問いである。［2］
2．型、確率、実行許可は、それぞれ異なる問いに答える
まず、型が正しいことと、判断内容が正しいことは違う。
TypeSafeが「Zero Hallucinations」として示す数値について、公開記事では、意味内容の誤りを実測したものではなく、スキーマへの適合の保証に基づく数値だと説明されている。定義済みの選択肢から外れないことを、その選択が現実について常に正しいことへ読み替えることはできない。［1］
また、JevのAPIでは、選択肢ごとの probabilities と confidence は同じ値ではない。公式仕様によれば、confidence は確率分布の集中・分散の形から算出する指標である。confidence = 0.94 を、そのまま「正答率94％」と解釈してはならない。［2］
そのうえで、確率推定自体にも検証の問題がある。Guoらの研究は、分類精度が高いことと、予測確率が実際の正答頻度に対応すること――確率校正――が別の性質であることを示している。校正は評価対象の分布に関する統計的な性質であり、個別の判断を無条件に正しいと証明するものではない。なお、この研究はJevを評価したものではない。［3］
しかし、本稿の論点は、校正の不完全さだけには依存しない。
仮に、ある用途で確率推定が十分に検証されていても、誤った場合の損失、実行権限、必要な承認、守るべき業務条件が異なれば、同じ確率から選ぶべき行動は変わる。確率から行動を決めるには、何を許容し、何を禁止するかという方針が加わる。
確率は、実行許可の根拠の一部にはなり得る。しかし、許可を出す規則や権限そのものではない。
これは閾値による自動化を否定する主張ではない。十分な条件が整った用途では、閾値と通常の業務ロジックで処理してよい。重要なのは、その閾値が何を意味し、どの条件と組み合わせて使われるかである。
3．出荷を提案できても、出荷を許可できるとは限らない
医薬品の温度管理輸送を、説明用に単純化して考える。ここでは、社内手順により「所定の温度記録が確認できない場合は出荷を保留し、品質部門へ確認する」と定められているとする。
モデルが出荷可を提案しても、次のような処理は矛盾しない。
モデルの提案：RELEASE（出荷可）
当該選択肢に割り当てた推定確率：0.94
必須の温度記録：一部を確認できない
業務手順に基づく処理：HOLD（出荷保留・品質部門へ確認）
※数値と処理は説明用の仮想例であり、Jevの実測結果や実際の品質判定手順を示すものではない。
保留の理由は、モデルを信用しないからではない。出荷を許可するための条件が、まだ確認できていないからである。推定で補ってよい情報と、指定された証拠による確認が必要な条件を区別している。
さらに、採用時の確認だけでは終わらない。承認後に対象ロットや搬送先が変われば、元の承認をそのまま使えるとは限らない。実行後も、「命令を送信した」という記録と、「対象物が指定先に届いた」という確認は別である。
この違いを、機能として整理すると次のようになる。
判断候補を得る → 採用条件を確かめる → 実行時の条件を確かめる → 結果を認定する
四つの製品や独立したサービスが必要という意味ではない。同じアプリケーション内でもよい。必要なのは、それぞれの確認対象と、次へ進める条件が混同されないことである。
4．既存のガバナンスも、モデルの出力だけを見ていたわけではない
この問題を、Jevの登場で初めて生まれたガバナンス課題として描くのは正確ではない。
NIST AI RMF 1.0は、信頼性に関する指標と閾値の設定に人間の判断を用いることを述べている。補助資料であるPlaybookのMEASURE 2.8も、人間による監督、出力を受けた後の行動や上書き、方針の例外、責任主体によるgo／no-go判断の記録を推奨している。いずれも任意のリスク管理資料であり、個々の判断に特定の製品や独立ゲートを一律に要求するものではない。［4］
広島AIプロセスの国際行動規範も、高度なAIシステムを開発する組織への任意の指針として、適用可能な範囲で設計・開発・配備・利用を含むライフサイクル全体を扱う。配備後の問題への対応や、利用者が出力を適切に解釈・利用するための情報提供も対象になっている。［5］
一方、EU AI Actでは、高リスクAIに関する第14条が、人間による監督の下で出力を採用しない、上書きする、運転へ介入するといった機能を扱い、第15条が精度・堅牢性・サイバーセキュリティを扱う。監督措置はリスク、自律性、利用文脈に応じるとされており、あらゆるAI利用への一律の人手承認義務ではない。［6］
これらの文書の法的性格や対象範囲は異なる。しかし、少なくとも「モデルの性能を評価すれば、出力の使い方まで自動的に決まる」という構成にはなっていない。
本稿の四つの区分は、これらの文書の公式分類ではなく、既に示されている要請を、業務のどこで、何によって確かめるかを議論するための整理である。
5．必要な機能には、既存の実装・研究がある
判断と実行の間に条件を置くこと自体を、新しい発明や、特定企業だけが提供できる機能として扱うべきでもない。
例えばOpen Policy Agent（OPA）は、権限や条件をコードとして定義し、ポリシーの判定と、その結果を実際に強制する処理を分離する。AIの出力を含む構造化データに、業務上の許可条件を適用する設計の部品になり得る。ただし、判定結果を実行経路へ反映する側の実装も必要である。［7］
形式手法では、BloemらのShield Synthesisが、指定した性質を実行時に守るため、システムの入出力を監視し、必要な場合に出力を修正する仕組みを扱っている。MitschとPlatzerのModelPlexは、モデル上の検証結果を現実の実行へ適用するため、実行がモデルの条件に適合しているかを実行時に確認する方法を示している。いずれも、指定された性質やモデルの前提の下での保証である。［8・9］
したがって、研究上の問いは「外側にもう一つチェックを置けばよい」で終わらない。
何を確認し、何が確認できなければ進めず、その判定を実際の処理が迂回しないようにするか。さらに、確認した条件と今回の実行・結果との対応を、どう保持するか。
既存の承認処理、ポリシーエンジン、形式検証、実行時監視を組み合わせて必要な条件を満たせるなら、その構成でよい。重要なのは名称ではなく、対象業務で必要な性質が成立していることである。
6．GhostDriftの研究は、その「接続」を検証対象にする
GhostDrift数理研究所が責任OS・ADICや実行結果閉包として取り組んでいるのは、モデルの判断能力を置き換えることではない。判断の根拠、採用条件、実行条件、結果の確認を、同じ対象と処理について結び付け、検証結果を次の処理へ進める条件に反映することである。［10］
例えば、Aロットについての承認がBロットの実行に使われていないか。「条件付きで実行可」という判断が、後工程では「無条件に実行可」と解釈されていないか。「命令送信済み」が、いつの間にか「目的達成済み」に置き換わっていないか。私たちは、こうした接続を研究上の焦点としている。
公開しているLean 4形式化「Physical AI Outcome Assurance」では、前提と入手済みの証拠に照らして、成功した履歴と成功していない履歴の両方がなお候補に残る場合、その情報だけから確実な成功認定はできない、という境界を扱う。これは確率的な推定を否定するものではなく、何を確実な結果として扱えるかを区別するための形式化である。また、事前の検証が対象となるすべての実行を十分に覆う場合には、追加の実行後証拠がなくても結果を認定できるケースを含む。［11］
もう一つの「Physical AI Verified Composition」は、各工程の保証が自動的に全体の保証になるわけではなく、前工程の結果と次工程の前提を結ぶ条件が必要になることを、抽象モデル上で扱っている。［12］
これらは、既存研究を置き換える唯一の方式の証明ではない。公開形式化が示すのは、明示した定義・前提から導かれる情報上の限界と成立条件であり、個別設備の安全性、現実の証拠の真正性、法令適合や実装全体の正しさまで自動的に保証するものではない。モデルと現実の対応や実行経路への適用は、別途検証が必要である。［11・12］
実装の有効性も、形式化の存在だけでは決まらない。条件違反の通過を防げたかに加え、正常な処理を不必要に止めていないか、追加の遅延は許容できるか、第三者が判断の根拠を確認できるか、といった観点で評価すべきだと考える。
おわりに――自動化を止めるためではなく、任せられる条件を明らかにする
低リスクでやり直しの利く処理と、物理的な作用を伴う処理に、同じ重さの確認を課す必要はない。保留や停止も、それ自体が常に安全とは限らず、継続や代替動作を含めた設計が必要になる。リスクに見合う制御という考え方は、NISTの枠組みや、前述の実行時検証の研究とも整合する。［4・9］
Jevを契機に考えたいのは、AIへの信頼を下げることではない。判断能力を活用するために、その判断をどの条件で行為へ変えられるのかを明らかにすることである。
確率は、実行許可ではない。実行許可は、結果が得られたことの証明でもない。
この違いを区別し、その間を確かめられる形でつなぐこと。それが、モデルの種類を問わず、AIに仕事を任せるための重要な設計課題である。
一次文献・公開資料
本文の番号に対応する。ウェブ資料の参照日は2026年9月20日。提供元の技術説明、学術研究、公的文書、自社公開資料は、それぞれ性格の異なる根拠として記載している。
［1］Diogo Almeida／TypeSafe AI（2026年9月15日）
“Introducing System One Models & Jev.”
Jevの公開、型付き出力、比較実験の条件、スキーマ適合に関する提供元の説明。第三者による性能評価ではない。
公式公開記事
［2］TypeSafe AI, Official Documentation
“Introduction”; “Confidence”; “Choice.”
型付き質問とコードの役割分担、probabilities と confidence の区別、リスクに応じた閾値の利用を説明する公式仕様。
Introduction ／ Confidence ／ Choice
［3］Chuan Guo, Geoff Pleiss, Yu Sun, Kilian Q. Weinberger（2017）
“On Calibration of Modern Neural Networks.” Proceedings of the 34th International Conference on Machine Learning, PMLR 70:1321–1330.
分類精度と確率校正の違いを扱う原著論文。校正の定義は第2節。Jevそのものの評価ではない。
論文・原文PDF
［4］National Institute of Standards and Technology（NIST）
Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1（2023）; AI RMF Playbook, MEASURE 2.8.
AI RMF本文12頁の指標・閾値と人間の判断、およびPlaybookの監督・下流の行動・例外・go／no-go記録を参照。いずれも任意のリスク管理資料。
AI RMF 1.0 ／ Playbook: MEASURE
［5］G7（2023）
Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems.
前文および行動項目1〜3を参照。高度なAIシステムを開発する組織への任意の指針であり、適用可能な範囲で配備・利用を含むライフサイクルを扱う。
外務省掲載・英文原文
［6］European Union
Regulation (EU) 2024/1689 — Artificial Intelligence Act, Articles 14–15.
EUR-Lexの2026年7月27日統合版を参照。第14条第3・4項のリスクに応じた監督、出力の不採用・上書き・介入と、第15条の精度等を区別して参照している。個別用途への適用や適用開始時期を判定するものではない。
EUR-Lex・統合条文
［7］Open Policy Agent Project
“Open Policy Agent (OPA).” Official Documentation.
ポリシー判定と強制処理の分離、構造化データに対する条件判定の公式説明。
公式ドキュメント
［8］Roderick Bloem, Bettina Könighofer, Robert Könighofer, Chao Wang（2015）
“Shield Synthesis: Runtime Enforcement for Reactive Systems.” arXiv:1501.02573v2.
指定した性質を守るための実行時監視と出力修正を扱う原著論文の公開版。
原著公開版
［9］Stefan Mitsch, André Platzer（2016）
“ModelPlex: Verified Runtime Validation of Verified Cyber-Physical System Models.” Formal Methods in System Design, 49:33–74. DOI: 10.1007/s10703-016-0241-z.
検証済みモデルの保証を実システムへ適用するための、実行時適合確認を扱う原著論文。
出版社掲載・原文
［10］GhostDrift数理研究所（2026）
「製造AIを、PoCから現場の実行へ。GhostDrift、フィジカルAIの実行・結果を検証するAIアシュアランス技術5件を国際出願」
自社の研究対象と公開形式化の位置づけを確認するための研究開発発表。第三者評価や認証を示す資料ではない。
自社発表原文
［11］GhostDrift Mathematical Institute
Physical AI Outcome Assurance.
実行結果の認定可能性、証拠の曖昧性、モデル上の保証を対象実行へ移す条件に関する公開Lean 4形式化。READMEの適用範囲・非主張事項も参照。
公開リポジトリ ／ 形式化ソース
［12］GhostDrift Mathematical Institute
Physical AI Verified Composition.
情報損失と、明示的な接続条件の下での有限工程の保証合成に関する公開Lean 4形式化。個別設備の安全性や実運用規模での性能保証とは区別する。
公開リポジトリ ／ 形式化ソース