判断を外に出すAI基盤 — Ontology / DSL / Behavior Tree による Decision-Oriented Signal Platform —

多くのAI基盤は、「モデルをどれだけ賢くするか」に焦点を当てて設計されている。

精度を上げる。
推論を高速化する。
自動化率を高める。

しかし、現実の意思決定環境で本当に重要なのは、別の問いである。

判断はどこにあるのか。

モデルの中か。
コードの中か。
あるいは暗黙の運用ルールの中か。

Decision-Oriented Signal Platform が提示するのは、この問いに対する構造的な答えである。

モデルを中心に置かない。
判断を中心に置く。
そして判断を、モデルの外に出す。

本稿では、そのための三つの中核構造：

オントロジー（Ontology）
ドメイン固有言語（DSL）
ビヘイビアツリー（Behavior Tree）

がどのように連携し、説明可能で監査可能な判断基盤を実現するかを整理する。

1. なぜ「判断の外在化」が必要なのか

従来の機械学習基盤では、判断は次の場所に埋め込まれがちである。

モデルの重み
閾値ロジック
アプリケーションコード
運用ルール

この構造には、いくつかの本質的な問題がある。

① 判断の所在が不明確になる

誰がどの基準で決めたのか追跡できない。

② 説明と責任の分離ができない

Explanation（どう計算したか）は出せても、
Justification（なぜそれで良いのか）が残らない。

③ 変更コストが高騰する

閾値や判断基準の変更がコード修正になる。

Decision-Oriented Signal Platform は、ここに対して明確な方針を取る。

判断は計算の副作用であってはならない。
判断は第一級の構造として管理されなければならない。

このとき必要になるのが、

意味の固定（Ontology）
判断記述の外部化（DSL）
実行構造の明示（Behavior Tree）

である。

2. Ontology — 意味境界を固定する

判断を外に出す第一歩は、世界の切り方を固定することである。

AIが扱う現実のデータは連続的だ。
しかし意思決定は、必ずどこかで「ここから先は別物」という離散的な境界を必要とする。

例えば、小売や施設運営の現場では、次のような判断が日常的に行われている。

どこまでを「来場」とみなすのか
どの行動を「回遊」と呼ぶのか
どの状態になったら「購買意図が高い」と判断するのか
誰を「VIP顧客」と扱うのか
どの変化を「異常」と呼ぶのか
どの水準から「高リスク」と見なすのか

重要なのは、これらはデータの中に自然に存在しているわけではないという点だ。

例：同じデータでも、定義が違えば判断は変わる

例えば「来場」を考えてみよう。

ある組織では：

GPSが施設境界内に入ったら来場

別の組織では：

入場ゲートを通過して初めて来場

さらに別の組織では：

5分以上滞在して初めて来場

どれも技術的には実装可能だが、
どれを採用するかで、全てのKPIと施策が変わる。

つまりこれは単なるデータ処理ではなく、明確な意味の選択＝判断の前提なのである。

オントロジーがやっていること

オントロジーの役割は、この「意味の切り方」を明示的に固定することだ。

Decision-Oriented Signal Platform では、例えば次のように定義される。

例：

Visit（来場）
→ 「施設ジオフェンス内に連続3分以上滞在」
Zone Roaming（回遊）
→ 「異なるゾーンIDを10分以内に2回以上遷移」
Purchase Intent High
→ 「直近24時間の閲覧・カート行動から算出した意図スコア ≥ 0.8」
VIP Tier
→ 「過去90日の累積購買額が上位5%」
Anomaly
→ 「過去8週移動平均からの乖離が3σ以上」
High Risk
→ 「リスクスコア ≥ 0.7 かつネガティブシグナルが連続発生」

ここで重要なのは、これらはモデルの出力ではなく、世界の意味定義だという点である。

なぜこれを先に固定しなければならないのか

オントロジーが曖昧なままシステムを作ると、必ず次が起きる。

Signal の意味がチームごとに揺れる
KPI が後から変わる
モデル更新で意味が変質する
explain はできても justify ができない
監査時に「定義はどこ？」となる

これは単なる実装問題ではない。

判断の座標系が存在していない状態

である。

Decision-Oriented Signal Platform では、オントロジーを次のように位置づける。

オントロジー = 判断世界の座標系

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

DSL による判断契約
Behavior Tree による実行制御
Signal による計測

が安定して機能する。

3. DSL — 判断ロジックをコードから解放する

意味境界（Ontology）が固定された後、次に必ず直面するのが次の問いである。

判断をどこに書くのか。

多くのシステムでは、この問いに対して半ば無意識に同じ答えが選ばれてきた。

判断はアプリケーションコードに書く

典型例：

if score > 0.8:
 trigger_offer()

一見すると合理的に見える。

シンプルで、実装も容易だ。

しかし、Decision-Oriented Signal Platform の視点から見ると、この書き方には構造的な問題がある。

コード埋め込み型判断の本質的な問題

① 判断がコードに埋没する

この1行には、実は複数の意思決定が暗黙に含まれている。

なぜ 0.8 なのか
誰が決めたのか
いつ変更されたのか
別の閾値候補は検討されたのか
この判断はどの業務責任者の管轄か

しかしコード上では、それらはすべて不可視になる。

結果として、判断の所在が追跡不能になる。

② 非エンジニアが関与できない

現実の意思決定では、判断基準の所有者は多くの場合：

事業責任者
マーケ担当
リスク管理部門
現場運用者

である。

にもかかわらず、判断がコードに閉じ込められると、

判断を変更するには開発チケットを切る

という構造が生まれる。

これは単なる不便さではない。
組織の意思決定速度そのものを制限する構造的ボトルネックである。

③ 差分監査が極めて困難

コード変更の diff は取れる。
しかしそこで分かるのは「実装が変わった」という事実だけだ。

本当に知りたいのは：

判断基準がどう変わったのか
リスク許容度が上がったのか
ビジネス戦略が変わったのか
誰の承認で変わったのか

である。

コード中心の設計では、技術差分は見えても、判断差分が見えない。

④ 意図（Justification）が残らない

Explanation（どう計算したか）はコードから追える。

しかし、

なぜこの条件で良いと判断したのか

という Justification は通常どこにも保存されない。

これは、後から見たときに最も大きなリスクになる。

Decision-Oriented Signal Platform の解決方針

この問題に対して、本プラットフォームは明確な設計原則を採用する。

判断はコードに書かない。
判断はDSLとして外部化する。

DSL による判断記述

例：

rule: high_value_user
when:
- signal: purchase_intent
op: ">="
value: 0.8
then:
action: issue_voucher

この形式にすることで、何が起きるか。

DSL がもたらす構造的変化

① 判断の可読性が飛躍的に向上する

コードを読まなくても、

どの Signal を見て
どの条件で
何を実行するのか

が一目で理解できる。

これは単なる「見やすさ」ではない。

判断ロジックが組織の共通言語になる

という意味を持つ。

② 判断差分を直接監査できる

DSLは宣言的であるため、次のような比較が可能になる。

例：

- value: 0.8
+ value: 0.7

この1行の変更は、単なる数値修正ではない。

それは：

リスク許容度の変更
ターゲット拡張
マーケ戦略の転換

を意味する可能性がある。

DSL化により、判断の変化そのものが監査対象になる。

③ 非エンジニアが判断プロセスに参加できる

DSLは意図的にドメイン語彙で書かれる。

これにより：

事業側がレビュー可能
リスク部門が承認可能
プロダクト側が議論可能

になる。

これは単なるUI改善ではない。

判断ガバナンスの再設計

である。

④ fail-closed 設計と相性が良い

Decision-Oriented Signal Platform の重要原則に、

不正な判断定義は実行しない（fail-closed）

がある。

DSLが契約（contract）として扱われることで、

スキーマ検証
バージョン固定
署名管理
実行前検証

が機械的に可能になる。

DSLは単なる設定ファイルではない

ここが最も重要なポイントである。

多くのシステムでも YAML や JSON は使われている。
しかしそれらの多くは単なる「設定値の外出し」に過ぎない。

Decision-Oriented Signal Platform における DSL は違う。

DSL = 判断の契約表現（Decision Contract）

である。

この位置づけにより、DSLは：

監査対象
バージョン管理対象
承認対象
実行前検証対象

として扱われる。

小結

Ontology が「世界の意味境界」を固定し、
DSL が「判断条件」を外在化する。

しかしまだ一つ重要な要素が残っている。

判断はどの順序で評価されるのか。

この問題を解決するのが、次節の Behavior Tree である。

4. Behavior Tree — 判断の実行構造を可視化する

Ontology によって意味境界が固定され、
DSL によって判断条件が外在化された。

ここまで来ると、判断はかなり透明になったように見える。

しかし実運用では、まだ一つ重要な問題が残る。

判断は、どの順序で評価されるのか。

なぜ「評価順序」が問題になるのか

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

例えば顧客施策を考えると、実際の判断は次のような多段構造になる。

VIPかどうか
高購買意図かどうか
リスクが高すぎないか
直近で配布済みでないか
例外条件に該当しないか

このとき重要なのは、どの条件を先に評価するかで結果が変わり得るという点である。

例えば：

VIPチェックが先か
リスク抑制が先か
配布上限チェックが先か

この順序が暗黙のままだと、システムは再びブラックボックス化する。

従来実装で何が起きているか

多くのシステムでは、判断順序は次のどこかに埋め込まれる。

ネストされた if 文
サービス呼び出し順
ワークフローコード
バッチ処理の並び
マイクロサービスの呼び順

結果として：

実行順序がコード依存になる
分岐構造が可視化できない
例外経路が追えない
fail-open が紛れ込む
影響範囲の推定が困難になる

つまり、

判断条件は見えているのに、
判断プロセス全体は見えない

という状態が発生する。

Decision-Oriented Signal Platform の解決方針

この問題に対して、本プラットフォームは明確な設計選択を行う。

判断の実行順序そのものを、第一級の構造として保存する

そのために採用されるのが、

Behavior Tree（BT）

である。

なぜ Behavior Tree なのか

Behavior Tree はゲームAIで発展した技術だが、
本質的には「意思決定フローの宣言的表現」に非常に適している。

BT が優れている理由はシンプルだ。

条件・順序・フォールバックをすべて構造として保持できる

Behavior Tree が解決する五つの問題

① 評価順序の明示

BTでは、ノードの並びそのものが評価順序になる。

つまり：

どの判断が先に行われるか
どこで止まるか
次にどこへ進むか

が、コードを読まずに理解できる。

これは単なる可読性ではない。

判断の優先順位が、設計資産として固定される

という意味を持つ。

② 分岐構造の完全可視化

従来の if ネストでは、全体像を把握するのは困難だった。

BTでは、判断フローがツリーとして表現されるため、

正常経路
代替経路
例外経路
打ち切りポイント

が一目で把握できる。

これは監査・レビュー・障害解析において決定的に重要である。

③ フォールバック（安全退避）の明示

実運用では、すべての条件が成功するとは限らない。

例えば：

高意図ではなかった
データが欠損している
リスク判定が不確実
上限に到達している

BTの Selector / Fallback ノードにより、

条件が満たされなかった場合にどこへ退避するか

を構造として保証できる。

これは fail-open を防ぐ上で極めて重要である。

④ fail-closed 設計との高い親和性

Decision-Oriented Signal Platform の重要原則は：

不確実なときは実行しない

である。

BTでは、各ノードの成功／失敗が明確に伝播するため、

前提未成立 → 即停止
必須Signal欠損 → フェイル
契約違反 → 実行中断

といった fail-closed 振る舞いを構造レベルで保証できる。

これは単なる例外処理とは根本的に異なる。

⑤ 部分再利用と進化的拡張

BTはサブツリー単位で再利用できる。

例えば：

VIP判定サブツリー
リスク抑制サブツリー
配布上限チェックサブツリー

を独立モジュールとして管理できる。

これにより：

判断ロジックの再利用
安全な差し替え
A/B構造比較
段階的高度化

が可能になる。

これは大規模運用で極めて効く特性である。

Behavior Tree による判断フロー例

例：

Selector
 ├─ Check High Intent
 │ └─ Issue Offer
 └─ Check Medium Intent
 └─ Log Only

この短い構造の中に、すでに重要な意思決定情報が含まれている。

高意図を最優先で評価
成功した時点で打ち切り
該当しない場合のみ次へ
最低限のフォールバックを保証

つまりここでは、

判断フローそのものが、実行可能な設計資産として保存されている

のである。

Behavior Tree の位置づけ

Decision-Oriented Signal Platform における役割は明確だ。

Ontology
→ 判断世界の座標系
DSL
→ 判断条件の契約
Behavior Tree
→ 判断の実行トポロジー

小結

判断を本当に外在化するためには、三つすべてが必要になる。

意味が固定され（Ontology）
条件が明示され（DSL）
実行順序が保証される（Behavior Tree）

この三層が揃ったとき、初めてAIシステムは

説明可能で、監査可能で、責任分離された判断基盤

へと進化する。

5. 三層統合 — Decision-Oriented Signal Platform の中核

ここまで見てきたように、Decision-Oriented Signal Platform は単一の技術要素では成立しない。

Ontology だけでは、意味は固定されても判断は動かない。
DSL だけでは、条件は書けても実行順序が保証されない。
Behavior Tree だけでは、流れは見えても判断基準の根拠が曖昧になる。

重要なのは、これらを一体の構造として設計することである。

この三層を統合したとき、初めて判断はシステムの中で「第一級の資産」として扱われるようになる。

三層の役割分担

層	役割
Ontology	世界の意味境界を固定する
DSL	判断条件を契約として記述する
Behavior Tree	判断の実行順序と制御構造を保証する

この役割分担は偶然ではない。
それぞれが、従来AI基盤の異なる盲点を補完している。

三層が揃ったときに初めて可能になること

① 判断の完全外在化

判断が：

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

から切り離され、明示的な設計資産として管理可能になる。

これは単なる可視化ではない。

判断が「変更可能で、監査可能で、所有可能」になる

という構造転換である。

② Explain と Justify の分離

従来のXAIが苦戦してきたのは、この二つを同時に説明しようとした点にある。

Explanation
→ モデルがどう計算したか
Justification
→ なぜその判断を採用したのか

Decision-Oriented Signal Platform では：

Explanation → Signal生成層
Justification → DSL + Behavior Tree

と責任が明確に分離される。

これにより、

「計算の説明」と「判断の正当化」

を異なるレイヤーで管理できるようになる。

③ fail-closed 実行の制度化

多くのAIシステムは、設計意図に反して fail-open に滑りやすい。

データ欠損でも動く
不確実でも出力する
条件未成立でも通過する

三層構造では、

Ontology → 前提の意味検証
DSL → 契約違反検出
Behavior Tree → 実行停止制御

が連動することで、

不確実なときは実行しない

という fail-closed 原則を構造レベルで保証できる。

④ 監査証跡（Auditability）の確立

三層が分離されることで、次がすべて追跡可能になる。

どの定義で世界を切ったか
どの条件で判断したか
どの順序で評価したか
どこで停止したか
誰が変更したか

これは単なるログ強化ではない。

判断プロセスそのものが監査対象になる

という点に本質的な価値がある。

⑤ 安全な自動化の実現

自動化が危険になるのは、判断構造が不透明なときである。

三層統合により、

意味の暴走を防ぎ
条件の逸脱を検出し
実行の暴走を止める

という多層防御が成立する。

その結果、初めて

人間が責任を持てる形での自動化

が可能になる。

6. モデル中心から判断中心へ

従来のAI基盤は、暗黙のうちに次のパイプラインを前提としてきた。

従来型AI

データ → モデル → スコア → 閾値 → 行動

この構造では、最も重要なはずの「判断」が、

モデルの出力
閾値設定
コード分岐

の中に分散して埋め込まれてしまう。

結果として、

システムは動くが、判断の責任所在が曖昧になる

という状態が生まれる。

Decision-Oriented Signal Platform の再構成

本プラットフォームでは、流れは次のように再設計される。

Decision-Oriented Signal Platform

データ → Signal → 判断構造 → 行動

ここで重要なのは、モデルが消えたわけではないという点である。

モデルは依然として重要な役割を担う。
しかし、その位置づけが根本的に変わる。

モデルの役割の再定義

従来：

モデル = 判断主体

新構造：

モデル = Signal生成コンポーネント

つまりモデルは、

世界を観測し
状態を推定し
不確実性を数値化する

ための部品となる。

最終判断は、常に外部の判断構造によって行われる。

これはAIの能力を下げる話ではない。

むしろ逆である。

モデルの能力と、組織の判断責任を切り分ける

という、実運用において極めて重要な設計転換である。

結論 — AIは賢さではなく、判断構造で設計する

AIの進化は長い間、主に三つの軸で語られてきた。

より大きなモデル
より高い精度
より速い推論

これらは確かに重要である。
しかし、実運用の現場で最終的に問われるのは別の能力だ。

その判断は、誰の責任で、どの構造で行われたのか。

Decision-Oriented Signal Platform は、この問いに対して明確な立場を取る。

判断はモデルの中に閉じ込めてはならない。
判断は構造として外に出すべきである。

そのための実装装置が、

Ontology
DSL
Behavior Tree

の三位一体なのである。

思想から実装へ

本稿で述べた「判断の外在化」は、抽象的な理念ではありません。

その構造は、以下のリポジトリとして整理を開始しています。

👉 https://github.com/masao-watanabe-ai/judgment-structure-core

現時点では README に設計思想と構造の概要を記載している段階ですが、
今後、

Ontology 定義
DSL による判断契約
Behavior Tree 実行構造
fail-closed 実装
監査構造

を段階的に公開していく予定です。

判断を第一級の設計資産として扱う基盤は、
思想だけでは成立しません。

本リポジトリは、その実装に向けた公開設計ノートとしての位置づけです。