Jevを業務につなぐ「責任OS」――判断を実行に変える接続層の設計

kanna qed

18 分前

読了時間: 11分

Jevに状況を判断してもらい、何を実行してよいかをシステムとして決める。

Jevを業務で使うとき、最初から「出荷してよいか」「設備を動かしてよいか」という最終判断を丸ごと任せる必要はない。連絡内容の分類や対応候補の選択など、状況の解釈が必要な部分にJevを組み込み、その先の処理をコードで制御する。TypeSafeの公式資料が示すのも、こうした役割分担である。[1]

前稿「確率は、実行許可ではない」では、モデルの出力と業務上の実行許可の区別を、特定の製品に依存しない形で整理した。今回は一歩進めて、その区別を、GhostDriftが研究する「責任OS」の観点から具体的な設計に落とすとどうなるかを考える。

本稿は公開資料に基づく設計上の考察であり、Jevとの接続実験や共同開発の報告ではない。

1．Jevの公式資料は、最初から「コードが制御する」と説明している

Jevは、状態と型付きの質問を入力し、ソフトウェアが利用できる構造化された回答を返す。例えばChoiceでは、あらかじめ指定した選択肢からの回答、選択肢ごとのprobabilities、分布から算出されるconfidenceを受け取る。[1][2]

ここで重要なのは、Jevがアプリケーションのすべてを自律的に決める、という設計ではないことだ。TypeSafeの「How to build with TypeSafe」は、制御フロー、決定的なルール、外部への作用をコード側に残し、モデルには範囲を絞った判断を担当させると説明している。[1]

また、公式のConfidence解説では、不確実性と行動のリスクに応じて、自動処理・確認・エスカレーションを使い分ける。閾値は用途と実データでの性能に合わせて調整するものとされている。[2]

したがって本稿の出発点は、「Jevには制御がないから別の仕組みが必要だ」ではない。

Jevが判断を部品として提供してくれるなら、その部品を使う側は、何をコードとして引き受けるべきか。

この問いから、業務への接続を設計していく。

2．Jevの判断と、業務上の許可を別々に扱う

例えば物流では、自由記述の連絡に「通常どおり進めたい」「不足資料を送ってほしい」「品質担当へ確認したい」といった異なる意味が含まれる。これらを分類する部分には、Jevを試す余地がある。

一方で、「必要な記録が登録されているか」「担当者に承認権限があるか」「実行対象が承認対象と一致するか」は、指定された記録や業務システムの状態を照合して扱うべき条件になり得る。ここまでをすべて、Jevへの一つの質問に押し込む必要はない。

以下は、その役割分担を考えるための仮想的な業務方針である。

Jevの判断をどう扱うか	必須の業務条件	この例での処理
用途別に検証した自動採用条件を満たす	必要条件が確認できている	許可範囲内の処理へ進む
自動採用条件を満たす	必要条件が欠ける、または未確認	当該処理を保留し、不足を確認する
自動採用条件を満たさない	必要条件が確認できている	担当者確認や別の判断経路へ回す
自動採用条件を満たさない	必要条件も確認できていない	当該処理を保留し、確認経路へ回す

ここでいう「自動採用条件」は、単一の数値を指すものではない。対象タスク、回答、不確実性の扱い、用途別の評価結果などを踏まえて定める方針である。なお、Jevのconfidenceは確率分布から計算される指標であり、そのまま個別判断の正答確率として扱わない。[2]

この例で分けたいのは、判断を自動採用できるかという条件と、業務として実行できるかという条件である。前者を満たしても後者の不足は消えず、後者を満たしてもモデルの判断が自動的に妥当になるわけではない。

逆に、両方が満たされた処理まで、一律に人手へ戻す必要もない。接続層の目的は、Jevの判断を使わないことではなく、使ってよい範囲を明らかにすることにある。

3．その接続を「責任OS」として設計する

GhostDriftが研究する責任OSは、AIの判断や処理を根拠に基づいて検証し、必要な条件や証拠が確認できない場合には重要な処理を進めない、という方向の数理・システム基盤である。[7]

本稿では、その考え方をJevの周囲に置く業務上の接続層として扱う。これはTypeSafeの公式用語ではなく、Jevを使うために必須の製品名でもない。通常のOSの置き換えではなく、組織が決めた実行条件を、判定・実行・記録に反映するための設計である。

構成のイメージは次のようになる。

業務データ・必要な文脈
    ↓
Jev：範囲を絞った質問に回答する
    ↓
接続層：回答を採用できるか、対象の処理を許可できるかを判定する
    ├─ 保留・担当者確認・別経路
    └─ 許可された処理
           ↓
       実行側：対象と実行時の条件を確かめ、処理する
           ↓
       結果確認：何が実際に完了したかを記録する

この図は機能の分担であり、別々のサービスを必ず構築するという意味ではない。一つのアプリケーション内で実装しても、既存の承認基盤やポリシーエンジンと組み合わせてもよい。

ただし、許可を判定することと、その判定を実行経路で守らせることは分けて確認する。 OPAも、ポリシーの判定と強制を分離する設計を取っている。[3] 接続層が「保留」と判断していても、別の処理経路から対象操作を実行できてしまうなら、その制御は目的を果たしていない。

もう一つ、コードにしたから正しいとは限らない。業務条件の選び方、証拠の信頼性、実行側の実装も検証対象になる。責任OSという名前を付けること自体が、これらを保証するわけではない。

4．温度管理輸送では、Jevをどこに置くか

具体例として、出荷準備中の温度管理輸送を考える。以下は設計を説明するための仮想例であり、実際の品質判定手順やJevの医薬品用途への適性を示すものではない。

連絡の解釈にはJevを使い、出荷条件は別に確かめる

運送会社から届いた連絡について、Jevには「通常進行」「不足情報の照会」「品質担当への確認」「その他」といった、用途に合わせた選択肢で分類してもらう。

出荷を許可する側では、それとは別に、社内手順で必須とされた温度記録、対象ロット、承認権限などを確認する。Jevの分類が「通常進行」でも、必須記録を確認できなければ、そのまま出荷許可には変換しない。

Jevによる連絡内容の分類：通常進行
社内手順上の必須温度記録：一部を確認できない
出荷処理：保留
次の対応：記録の照会、必要に応じて品質担当へ確認

この構成では、Jevは連絡を読み解く役割を果たしている。出荷を保留することは、その分類が間違っていると断定することでも、Jevを利用できなかったことでもない。異なる問いに、異なる仕組みが答えている。

条件がそろった処理は進め、条件が変わった処理は確認し直す

必要な記録と権限が確認でき、Jevの回答もその用途の採用条件を満たせば、事前に許可された範囲の処理を進められる。

ただし、承認後に対象ロットや搬送先が変わった場合、以前の許可が変更後の操作にも適用できるかは別途確認する。ここでは、単にJevへ同じ質問をもう一度送るのではなく、業務上の承認が何を対象にしていたかを照合する。

保留する対象も区別する。この例で出荷を保留することは、温度管理まで停止するという意味ではない。何を止め、何を維持し、誰が次に対応するかまでを業務方針に含める。

「処理を依頼した」と「結果が得られた」を分ける

出荷指示を送っただけで、配送完了の状態へ進めない。配送完了を扱うなら、社内手順で指定した受領記録など、今回の対象に対応する確認が必要になる。

重要なのは、あらゆる処理に重い事後確認を増やすことではない。次の工程が「何が完了した」と受け取ってよいかを、先に決めることである。確認できた状態と未確認の状態が混ざらなければ、その先の自動化も設計しやすくなる。

5．既存の仕組みと、GhostDriftの研究はどう位置付くか

ここまでの構成を、Jevのためにすべて新しく作る必要はない。

OPAは、構造化データとポリシーを使って許可条件を判定する部品になり得る。[3] Shield Synthesisは、指定した性質を守るために実行時の出力を監視・修正する研究であり、ModelPlexは、検証したモデルと実際の実行との適合を実行時に確かめる研究である。いずれも、対象とする仕様や前提の下での保証を扱う。[4][5]

NIST AI RMF PlaybookのMEASURE 2.8も、人間の監督、AI出力後の行動や上書き、方針の例外、責任主体によるgo／no-go判断の記録を推奨する。ただし、特定の接続層や製品の採用を義務付けるものではない。[6]

したがって、既存の仕組みで必要条件を満たせるなら、その構成でよい。GhostDriftの研究は、これらを否定するものではなく、判断の根拠、採用条件、実行、結果の間を、第三者が確かめられる形で接続する方向に位置付く。[7]

関連する公開Lean 4形式化のうち、Physical AI Outcome Assuranceは、前提と証拠に照らして成功・失敗の両方が候補に残る場合、その証拠だけから確実な成功認定はできないという境界を扱う。一方で、事前の保証が対象実行を十分に覆う場合は、追加の実行後証拠が必須ではないことも明示する。[8]

Physical AI Verified Compositionは、明示した接続条件の下で、有限の工程列に局所保証をつなぐための条件を扱う。[9]

これらは抽象モデルの情報構造や保証の成立条件に関する形式化であり、Jevの性能、本稿の接続案、責任OS全体、個別設備の安全性を証明したものではない。実データとの対応、証拠の真正性、実行経路の実装は別途確認が必要である。[8][9]

本稿で参照する意味は、「この製品が唯一必要だ」と主張することではない。Jevを業務につなぐ際に、どの接続を確かめる必要があるかを整理するためである。

6．Jevの接続を試すなら、正答率だけで終わらせない

実際に試す段階では、Jevが連絡を正しく分類できるかに加え、その回答が業務の中でどう扱われたかを評価したい。例えば、上の仮想業務方針なら、次のようなテストが考えられる。

テストする状況	確認したいシステムの動作
Jevの回答も業務条件も採用可能	許可した範囲の処理を、不必要に止めずに実行する
Jevの回答は採用可能だが、必須記録が不足	回答を許可の代用にせず、対象処理を保留する
業務条件はそろっているが、Jevの回答は要確認	定めた確認経路へ回し、自動実行しない
承認後に対象が変更された	変更前の許可を無条件に流用しない
指示への応答や結果の確認が得られない	未確認を成功扱いせず、重複実行を避けながら定めた復旧経路へ回す