これまでの記事では、
なぜ判断を外在化する必要があるのかを説明してきました。

その中核となる三つの構造要素は：

オントロジー
DSL（判断契約）
ビヘイビアツリー

しかし、当然次の問いが生まれます。

それらを実際にどう構築するのか？

設計を誤れば、

硬直化しすぎる
あるいは柔軟すぎて曖昧になる

本稿では、
オントロジー・DSL・ビヘイビアツリーを
効率的かつ正確、そして持続可能に構築する方法を整理します。

1. オントロジー ― 分類ではなく「摩擦」から始める

オントロジー設計でよくある誤りは、

「すべてを分類しようとする」ことです。

その結果、

抽象的すぎる分類
哲学的議論
終わらない命名論争
実務価値の欠如

が起こります。

オントロジーは理論から始めるべきではありません。

判断の摩擦から始めるべきです。

Step 1：繰り返し発生する判断衝突を特定する

次の問いを投げてください。

どこで議論が繰り返し止まるか？
KPI定義はどこでずれているか？
「それはケースによる」が頻出するのはどこか？
事後説明が食い違うのはどこか？

オントロジーは、こうした不安定領域を固定するためのものです。

「来場」の定義で揉めるなら、それはオントロジー問題です。
「VIP」の意味が部署ごとに違うなら、それはオントロジードリフトです。

オントロジーは、その境界を凍結する作業です。

Step 2：境界を運用契約として定義する

悪い定義：

来場とは、施設に入ること。

良い定義：

来場 = ジオフェンス内に3分以上連続滞在すること。

良いオントロジーの条件：

測定可能
検証可能
監査可能
バージョン管理可能
モデル出力に依存しない

オントロジーは意味の美しさではありません。

境界の精度です。

Step 3：すべてをバージョン管理する

意味は変化します。

上書きしてはいけません。
バージョンを付けます。

例：

visit.v1
visit.v2（滞在時間条件を追加）

バージョンがなければ、
過去の判断を再現できません。

再現性は監査可能性の基盤です。

2. DSL ― 表現力ではなく「変更耐性」で設計する

DSLはプログラミング言語ではありません。

それは判断契約言語です。

目的は高度な表現ではなく、

明確性
監査可能性

です。

Step 1：最小の演算子から始める

最初から

ネストされた論理
複雑な量化
任意関数

を入れてはいけません。

まずは：

比較演算子
AND / OR
明示的なSignal参照

から始めます。

例：

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

柔軟性を早く入れすぎない。

柔軟性は曖昧さを生み、
曖昧さは責任を破壊します。

Step 2：SignalとRuleを分離する

DSL内でSignalを計算してはいけません。

誤り：

if purchase_intent_score(user) > 0.8:

正解：

signal: purchase_intent

Signalはモデルの出力。
DSLはSignalを参照する。

この分離により：

モデル更新は独立
判断ロジックは安定

が実現します。

Step 3：Diffで判断変更が見える設計にする

0.8 → 0.7 の変更がGitで明確に見えなければ、
それは失敗したDSLです。

良いDSLの条件：

行単位で変更が見える
閾値変更が明確
所有者メタデータを付与可能
バージョン管理可能

次の問いに答えられる必要があります。

誰が変更したか？
なぜ変更したか？
誰の承認か？

答えられないなら、それは契約ではありません。

3. ビヘイビアツリー ― ロジックではなくリスクから設計する

多くのチームはロジックの流れから木を設計します。

それは誤りです。

リスク封じ込めから設計する。

Step 1：停止すべき場所を先に決める

問い：

どこで実行を止めるべきか？
何がFail-Closedであるべきか？
どの分岐が優先か？
どこでフォールバック可能か？
どこでフォールバックは危険か？

ビヘイビアツリーは単なるフローチャートではありません。

安全意味論を持つ実行トポロジーです。

Step 2：Fail-Closedを標準にする

不確実な場合：

続行するか？
フォールバックするか？
停止するか？

判断基盤は原則停止。

Fail-openは利便性を最適化します。
Fail-closedは責任を最適化します。

Step 3：ツリーは浅く保つ

深いツリーは可読性を破壊します。

深くなるなら、
オントロジーかDSLが過負荷です。

良いBT設計：

2〜4層
明確な優先順位
明示的なフォールバック
再帰の隠蔽なし

複雑さはSignal層に置く。

実行構造は単純に保つ。

4. 統合戦略 ― ボトムアップで構築する

一度に全体を作ろうとしない。

順序：

重要なオントロジー概念を3〜5定義
最小DSLルールを2〜3作成
1つの判断経路の浅いBTを構築
監査シミュレーション実施
境界修正

徐々に成長させる。

構造は摩擦とともに進化する。

5. 核となる原則

オントロジーは意味を定義する。
DSLは許容判断を定義する。
ビヘイビアツリーは実行責任を定義する。

効率は制約から生まれる。
正確さは境界の明確さから生まれる。
持続可能性はバージョン管理から生まれる。

結論

問うべきは：

「どうすればより賢いモデルを作れるか？」

ではない。

問うべきは：

どうすればより明確な判断構造を設計できるか？

モデルは時間とともに進化します。

しかし、
誤って設計された判断構造は
制度的リスクになります。

責任あるAIを構築するなら、
判断は：

定義され
外在化され
バージョン管理され
監査可能で
Fail-Closedでなければならない

それが、
オントロジー・DSL・ビヘイビアツリーを
効率的かつ正しく構築する方法です。

もし、

自社の判断基盤を外在化したい
DSL設計のレビューをしてほしい
既存AI基盤を監査可能構造に再設計したい
段階的信用スコアやFail-Closed設計を導入したい

などがあれば、

詳細はぜひ直接お問い合わせください。

実装レベル・組織設計レベルの両面から具体的にご相談可能です。

オントロジー・DSL・BTはどうやって効率的かつ正確に作るのか ― 判断構造を設計する実践的方法 ―