テストを超える自律性へ Decision Lawでつくる、検証可能なAI Runtime

🎥 The YouTube version is also available:

AI社会を支えるTrust Infrastructureとは？｜人・AI・組織が安心して協調するための新しい基盤

Books: Trust Infrastructure実践ガイド: Decision Trace・Knowledge Flow・Trust EngineによるAI時代の信頼基盤設計

AIエージェントが書いたコードを、どこまで人が読めばよいのか。

この問いは、コーディング支援の普及とともに、急に現実的になった。コード生成が速くなればなるほど、レビューする人の時間は希少になる。生成量が十倍になっても、読む速度が十倍になるわけではない。

だから、論点は「AIのコードは良いか」から、「人間が読まなくても信頼できる変更を、どのように作るか」へ移っている。

この流れの中で、Bend 2が示した発想は重要である。AIにコードだけでなく正しさの証明も書かせ、証明を機械が確認できなければ変更を通さない。テストのサンプルに頼らず、定めた性質がすべての実行で保たれることを確認する。

しかし、この話をプログラミング言語だけに閉じてしまうのは惜しい。AIが社会や組織の中で判断し、行動する時代に必要なのは、コードの正しさだけではないからである。

必要なのは、検証可能な自律性である。

自律性の問題は、コードの外側にある

たとえば、製造業の保全支援AIを考えてみよう。

AIは、設備のセンサーデータ、保全記録、部品の在庫、過去の故障履歴、作業員の資格情報を読み、点検計画を提案する。さらに、軽微な点検であれば自動で作業指示を起票し、部品を引き当て、現場へ通知する。

ここで「ソフトウェアがバグなく動く」ことは必要だが、十分ではない。

本当に問われるのは、次のようなことである。

• 安全上の重要度が高い設備について、AIだけで運転継続を判断してよいのか。
• センサー値が欠損している時、推定値で作業を指示してよいのか。
• 在庫を引き当てる権限は、どの工場、どの予算、どの緊急度まで許されるのか。
• 法定点検や停止判断に必要な根拠がそろっていない時、AIは停止、エスカレーション、追加調査のどれを選ぶべきか。
• 後から事故や品質問題が起きた時、その判断に使ったデータ、規則、責任者、例外処理を再現できるか。

これらは、コードの仕様というより、組織の意図、責任、境界の仕様である。

Decision Lawという考え方

ここで提案したいのが、**Decision Law（判断法則）**である。

Decision Lawは、単なる業務ルールではない。AIが自律的に行動してよい条件と、そうでない時に人へ尋ねる条件、実行を止める条件を、機械で確認できる形にしたものである。

保全支援AIなら、例えば次のように表現できる。

• 安全重要設備の運転継続判断は、資格を持つ人間の承認なしに確定してはならない。
• 必須センサー値または直近点検記録が欠ける場合、自動の「安全」判定を出してはならない。
• 交換部品の自動発注は、承認済み予算、調達先、金額上限のすべてを満たす場合に限る。
• 設備停止を回避する提案には、代替案、リスク評価、根拠データへの参照を必ず含めなければならない。
• 判断の入力、適用規則、根拠、実行者、結果をTraceに残せない時は、実行してはならない。

重要なのは、AIが「もっともらしい判断理由」を文章で述べることではない。実行の前に、必要な根拠、権限、境界が満たされているかを検証器が確認することである。

Act / Ask / Stopを検証する

Runtime OSの観点から見ると、自律性は二値ではない。

AIに完全自動か、完全手動かを迫るのではなく、各判断を三つに分ける。

• Act：Decision Lawを満たしており、自動実行してよい。
• Ask：根拠、権限、リスク、例外のどれかが人間の確認を必要とする。
• Stop：境界違反、必要証拠の欠落、あるいは許されない不確実性があり、実行してはならない。

この分類を、モデルの自信度だけで決めてはいけない。自信の高い誤答はあり得る。重要なのは、判断があらかじめ定めた法則を満たしているかである。

つまり、自律性はAIに一括で与える権限ではない。

自律性は、意図、根拠、権限、境界、検証をRuntimeで結び直した時にだけ成立する。

証明できることと、証明できないこと

ここには、形式手法が昔から抱える限界もある。

検証器は、書かれた法則を正確に確認できる。しかし、書かれていない法則を発見することはできない。「安全重要設備は人が承認する」という法則を定義しなければ、検証器はその欠落を問題にしない。

これは失敗ではなく、設計上の責任の所在を明らかにする。

バグは、実装から消えるのではない。実装の誤り、仕様の誤り、仕様の欠落へと分解される。そのうち機械が直接捕まえられるのは、定義済みの法則に対する違反だけである。

だからこそ、Decision Lawは固定された規程集で終わってはならない。

現場で起きた例外、Human Gateでの差し戻し、事故未遂、監査指摘、結果の悪い判断をTraceとして蓄積する。そして「どの法則が足りなかったか」「どの境界の定義が粗すぎたか」を見直していく。ここで初めて、Decision TraceとKnowledge Flowが自律性の設計に接続する。

知識から法則へ、法則から証跡へ

組織に散在する保全記録、品質異常報告、手順書、設計変更、監査記録には、判断法則の断片が残っている。

Semantic ChunkとEvidence-Grounded Ontologyは、それらを設備、部品、工程、異常、対処、責任、結果といった意味の単位に整理し、原文へ戻れる根拠を保つ。その上で、繰り返し現れる条件や例外をDecision Lawの候補として抽出できる。

ただし、AIが抽出した候補をそのまま法則にしてはならない。候補はレビューされ、責任者、適用範囲、有効期間、例外、検証方法を伴って承認される必要がある。

この流れは、次のように表せる。

Raw Data → Semantic Chunk → Ontology / Policy Candidate → Human Review → Decision Law → Runtime Verification → Decision Trace → Law Revision

知識は検索のためだけに存在するのではない。判断できる境界を定義し、実行を検証し、後から法則を改善するために存在する。

まずは「最初の法則」を書く

すべての業務を形式化する必要はない。むしろ、最も重要で、誤ると取り返しのつかない一点から始めるべきである。

製造現場なら、たとえばこうである。

安全重要設備について、必要な観測値・点検記録・権限確認のいずれかが欠ける場合、AIは運転継続を自律的に確定してはならない。

この一文は、実装、データ設計、権限設計、画面、監査ログ、Human Gateのすべてに影響する。だからこそ価値がある。

AI時代の成熟した自律性は、「AIが何でもできる」状態ではない。自律的にしてよい範囲が明確であり、その範囲を越えないことを、実行のたびに確認できる状態である。

テストを増やすことも、人間レビューを改善することも重要である。しかし、エージェントが本格的に組織の実行へ入るなら、それだけでは足りない。

これから必要になるのは、AIの能力を競うことだけではない。

何を守るべきかをDecision Lawとして記述し、守られたことをTraceとして残す。

そのための基盤こそが、Autonomy Assurance Runtimeである。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance