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

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

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

• オントロジー
• 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. 統合戦略 ― ボトムアップで構築する

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

順序：

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

徐々に成長させる。

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

---

5. 核となる原則

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

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

---

結論

問うべきは：

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

ではない。

問うべきは：

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

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

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

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

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

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

---

もし、

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

などがあれば、

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

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