AIの判断はどのように記述されるべきなのか — Decision Trace Model が前提とする判断記述の構造 —

これまでの記事では、AIシステムを

判断を量産する工場

として捉えてきた。

AIは単なるソフトウェアではない。
Event を受け取り、Signal を生成し、Decision を行い、Boundary によって品質を管理する。

その構造は製造業の生産ラインに近い。

さらに、AIの品質を安定させるためには

AI品質工学

が必要であり、
そのためには

Decision Trace

すなわち

「どのような判断が行われたのか」

という履歴を保存する必要があることも説明した。

そして、その履歴を保証する仕組みが

Ledger（改ざんできない履歴）

である。

しかしここで、一つ重要な問いが残る。

そもそも、その「判断」はどのように記述されるべきなのか。

Decision Trace Model が成立するためには、

Event
Signal
Decision
Boundary
Human

という判断の流れが

明示的に表現できる構造

になっていなければならない。

もし判断が

モデルの重み
アプリケーションコード
暗黙の運用ルール

の中に埋め込まれていると、

Decision Trace を正確に記録することはできない。

つまり

Decision Trace Model の前提条件は
「判断が記述可能であること」

なのである。

そこで必要になるのが

判断を明示的に記述するための三つの構造である。

Ontology
DSL
Behavior Tree

この三層構造により、AIシステムの判断は

意味
条件
実行構造

として表現できるようになる。

本稿では、Decision Trace Model を成立させるための

判断記述アーキテクチャ

について整理する。

Decision Trace Model

Decision Trace Model は、

AIシステムにおける判断の履歴構造

を定義するモデルである。

AIシステムでは、次のような流れが常に発生している。

Event
↓
Signal
↓
Decision
↓
Boundary
↓
Human

例えば不正検知AIであれば、

Event
→ 取引が発生した

Signal
→ fraud_probability = 0.82

Decision
→ 口座凍結

Boundary
→ threshold = 0.8

Human
→ manual review

という一連の判断プロセスが存在する。

Decision Trace Model の目的は、この流れを

履歴として保存可能な構造

として定義することである。

ここで重要なのは、

AIの本質は予測ではなく
判断履歴

であるという点だ。

AIはSignalを出す。

しかし社会で重要なのは

そのSignalが
どの判断に使われたのか

である。

この判断履歴を保存するために
Ledger が必要になる。

しかしここで重要な問題がある。

それは

判断が構造として存在していない

場合、Decision Trace を正確に保存できないということである。

判断が記述されていないAI

多くのAIシステムでは、判断は次のような形で存在する。

モデルの重み
コードの分岐
設定ファイル
運用ルール

例えば

if score > 0.8:
 freeze_account()

この1行には

・閾値
・リスク許容度
・業務判断

が含まれている。

しかし

誰が決めたのか
なぜ0.8なのか
いつ変わったのか

はコードから分からない。

つまりここでは

判断が計算の副作用として存在している

のである。

この構造では、

Decision Trace Model を構築することはできない。

なぜなら

判断の構造が存在しない

からである。

そこで必要になるのが

判断記述アーキテクチャ

である。

Decision Trace Model では
判断は次の三層で記述される。

Ontology
DSL
Behavior Tree

である。

Ontology — 意味境界

判断を記述するための第一の要素は

意味の定義

である。

AIが扱うデータは基本的に

連続的な数値

である。

例えば不正検知AIでは

transaction_amount
location_distance
transaction_frequency
fraud_probability

などの数値が扱われる。

しかし意思決定は

離散的な意味境界

を必要とする。

例えば不正検知では

正常取引
疑わしい取引
不正取引

という区分が必要になる。

しかし重要なのは、

これらの概念は

データの中に自然に存在しているわけではない

という点である。

例えば「不正取引」という概念でも

fraud_probability ≥ 0.9
fraud_probability ≥ 0.8
fraud_probability ≥ 0.7

など複数の定義があり得る。

ある金融機関では

fraud_probability ≥ 0.9 → freeze_account

かもしれない。

別の金融機関では

fraud_probability ≥ 0.8 → freeze_account

かもしれない。

さらに別の組織では

fraud_probability ≥ 0.8 → manual_review
fraud_probability ≥ 0.95 → freeze_account

かもしれない。

つまり

どこからが「不正」なのか

という境界は、

データから自動的に決まるものではない。

それは

組織のリスク判断

なのである。

この境界が変わると

不正検知率
誤検知率
顧客体験
運用コスト

すべてが変わる。

つまりここで行われているのは

データ処理ではなく

意味の選択

である。

Ontology は

この意味境界を定義する。

Decision Trace Model において
Ontology は

判断世界の座標系

として機能する。

どの状態を「不正」と呼ぶのか
どの状態を「疑わしい」と呼ぶのか
どの状態を「正常」と呼ぶのか

この座標系が定義されて初めて、

Signal
Decision
Boundary

という判断構造が意味を持つのである。

DSL — 判断条件

意味境界（Ontology）が定義された後、

次に必要になるのが

判断条件の記述

である。

例えば前節では、

fraud_probability ≥ 0.8

のような境界によって

「不正取引」

という意味が定義されることを見た。

しかし意味が定義されただけでは、

AIはまだ何も行動できない。

次に必要になるのは

その意味境界を使って

どのような判断を行うのか

という条件である。

多くのシステムでは、この判断条件は

アプリケーションコード

の中に書かれる。

例えば典型的には次のような形になる。

if fraud_probability >= 0.8:
 freeze_account()

この書き方は一見シンプルに見える。

しかしここには重要な問題がある。

この1行には

・リスク許容度
・業務判断
・運用ポリシー

が埋め込まれている。

しかしコードからは

誰が決めたのか
なぜ0.8なのか
いつ変更されたのか

を読み取ることは難しい。

つまりここでは

判断がコードの中に埋没している

のである。

この構造では

可視化
監査
変更

が困難になる。

そこで Decision Trace Model では、

判断条件は

DSL（Domain Specific Language）

で記述される。

例えば不正検知の判断条件は、

次のように記述される。

rule: freeze_suspected_fraud

when:
 signal: fraud_probability
 op: ">="
 value: 0.8

then:
 action: freeze_account

この形式にすることで、

判断条件は

Decision Contract

として扱われる。

つまり、

どのSignalを使い
どの条件で
どの行動を行うのか

が

明示的な構造

として記述される。

DSLによって

・判断ロジックの可読性
・判断条件の差分監査
・非エンジニアによるレビュー

が可能になる。

例えば閾値が

value: 0.8

から

value: 0.85

に変更された場合、

それは単なる数値変更ではない。

それは

リスク許容度の変更

を意味する。

DSLにすることで、

こうした判断の変化を

組織として管理できる

ようになる。

つまりDSLは

単なる設定ファイルではなく、

判断契約（Decision Contract）

として機能する。

そしてこの構造によって、

AIシステムの判断は

組織の資産として管理可能になる

のである。

Behavior Tree — 判断フロー

しかし判断条件（DSL）が記述されても、
まだ一つ重要な問題が残る。

それは

判断の順序

である。

現実の意思決定は、単一条件では終わらない。

例えば不正検知では、

fraud_probability が高いか
取引金額が異常に大きいか
過去の取引履歴に不審なパターンがあるか
顧客がVIPであるか

など複数の条件が組み合わされる。

このとき重要になるのは

どの条件を先に評価するか

である。

例えば

不正確率が極めて高い場合
→ 即座に口座凍結

不正確率が中程度の場合
→ 人間レビュー

という判断フローが存在する。

しかし多くのシステムでは、この順序は

アプリケーションコード
サービス呼び出し
ワークフロー

の中に埋め込まれている。

その結果、

判断の全体構造が見えない
例外経路が分からない
フォールバック条件が追跡できない

という問題が発生する。

つまり

判断条件は見えていても
判断プロセスは見えない

のである。

そこで使われるのが

Behavior Tree

である。

例えば不正検知の判断フローは
次のように表現できる。

Selector
 ├ HighFraudProbability
 │ └ FreezeAccount
 └ MediumFraudProbability
 └ ManualReview

この構造は次の意味を持つ。

fraud_probability が極めて高い
→ 口座凍結

それ以外で
fraud_probability が高い
→ 人間レビュー

どちらにも該当しない
→ 正常取引として処理

このように Behavior Tree は

条件
順序
フォールバック

を構造として表現する技術である。

その結果、

判断の評価順序
例外経路
フォールバック処理

を設計資産として保存できるようになる。

つまり Behavior Tree は

判断フローの構造

を明示する仕組みなのである。

三層構造

Decision Trace Model では
判断は次の三層で表現される。

Ontology
→ 意味境界

DSL
→ 判断条件

Behavior Tree
→ 実行構造

この三層により
AIシステムの判断は

意味
条件
実行構造

として明示的に表現される。

しかし重要なのは、これらが単なる設計概念ではなく、

実際のシステムの中に組み込まれる構造

であるという点である。

AIシステムの判断パイプラインは
通常次のようになる。

Event
↓
Signal
↓
Decision
↓
Action

Decision Trace Model では

この中に

判断エンジン（Judgment Engine）

が挿入される。

Event
↓
Signal
↓
Judgment Engine
↓
Decision
↓
Action

そしてこの Judgment Engine の内部で

三層構造が使われる。

Ontology
↓
DSL
↓
Behavior Tree

それぞれの役割は次の通りである。

Ontology
→ Signal の意味を判定する

DSL
→ どの条件で判断するかを判定する

Behavior Tree
→ どの順序で判断するかを判定する

つまり判断エンジンは

Signal を入力として受け取り、

Ontology によって意味を解釈し、
DSL によって条件を評価し、
Behavior Tree によって実行順序を制御する。

そして最終的に

Decision
Boundary
Human override

などの結果を生成する。

この一連のプロセスが

Decision Trace

として記録される。

Event
Signal
Decision
Boundary
Human

この履歴が Ledger に保存されることで、

AIシステムの判断は

追跡可能
説明可能
監査可能

になる。

つまり

Decision Trace Model を成立させるためには、

判断が

Ontology
DSL
Behavior Tree

という三層構造で記述されている必要がある。

AIの未来は

より賢いモデルではなく

より透明な判断構造

によって作られるのである。

結論

AIの進化は長い間

モデルサイズ
精度
推論速度

で語られてきた。

しかし実社会で重要なのは

判断構造

である。

Decision Trace Model は

AIシステムを

判断履歴システム

として再定義する。

その前提となるのが

Ontology
DSL
Behavior Tree

による

判断記述アーキテクチャ

なのである。