断絶を記述せよ──オントロジーとDSLによる判断構造の固定化

断絶を記述せよ──オントロジーとDSLによる判断構造の固定化

昨日の記事では、
判断は一つではないという前提に立ち、
断絶を消さずに扱うマルチエージェント設計について述べた。

営業・法務・現場・経営。
役割が違えば、判断軸が違う。
それは調整すべき誤差ではなく、
構造として存在する断絶である。

マルチエージェント設計は、
この断絶を統合しない。
むしろ、割れたまま残す。

では次に問うべきは、こうなる。

その断絶を、どうやってシステムの中に固定するのか。

AIが扱えるのは計算だけであり、
連続的でなめらかな世界の近似においては、ほとんど万能である。

しかし、判断が切り替わる瞬間、
意味が反転する境界、
越えてはいけない線。

こうした 断絶 は、計算だけでは保持できない。

では、それをどうシステムに組み込めばよいのか。

一つの有効な答えが、
オントロジーとDSL（ドメイン固有言語） である。

なぜ「ロジックを外に出す」必要があるのか

多くのAI活用では、
判断基準そのものをモデルの内部に押し込もうとする。

• プロンプトで誘導する

• 重みで学習させる

• スコアに埋め込む

しかしこのやり方には、決定的な弱点がある。

どこで判断が切り替わったのかが、後から分からない。

モデルはなめらかだ。
だから境界は常にぼやける。

結果として、

• 説明できない判断

• 再現できない意思決定

• 責任を引き取れないシステム

が生まれる。

そこで必要になるのが、

判断の構造を、計算の外側に固定すること

だ。

オントロジーとは「意味の地図」である

オントロジーという言葉は難しく聞こえるが、
本質はシンプルだ。

世界を、どんな概念と関係で切り分けるかの合意

である。

• 何が「対象」なのか

• 何が「条件」なのか

• 何が「制約」なのか

• 何が「禁止」で、何が「例外」なのか

これらを 人間が先に決める。

重要なのは、
オントロジーは「推論するため」ではなく、

断絶を明示するために使う

という点だ。

ここまでは連続的に扱ってよい。
ここから先は意味が変わる。

この線引きを、言葉として残す。

DSLは「判断を凍結するための言語」

オントロジーが意味の地図だとすれば、
DSLはその地図の上で 判断を固定する文法 だ。

DSLが果たす役割は明確だ。

• 条件を書く

• 優先順位を書く

• 禁止を書く

• 例外を書く

つまり、

「もし〜なら、必ず〜せよ／してはならない」

を、曖昧さなく書く。

ここで重要なのは、
DSLは賢くなくていいということだ。

むしろ、賢くあってはいけない。

• 解釈しない

• 補完しない

• 忖度しない

ただ、書かれていることだけを守る。

これによって初めて、

AIが勝手に意味を作らない領域

が生まれる。

計算とロジックの健全な分業

ここで、役割分担がはっきりする。

計算（AI）がやること：

• 類似度を見る

• スコアを出す

• 確率を推定する

• 候補を広く集める

ロジック（DSL）がやること：

• 境界を切る

• 優先順位を決める

• 禁止を宣言する

• 人間に戻す条件を定義する

どちらが上でも下でもない。

計算は広げ、ロジックは切る。

この組み合わせによってのみ、
連続な世界と断絶のある世界が共存できる。

マルチエージェントとの自然な接続

ここで、前編の話が戻ってくる。

マルチエージェントは合意しない。
それぞれ異なる判断軸を持つ。

では、その判断軸はどこに書くのか。

答えは明確だ。

各エージェントは、異なるDSLと制約セットを背負う。

• 制約エージェントは「破ってはいけないDSL」を持つ

• 効率エージェントは「最適化してよい範囲のDSL」を持つ

• レビュー要求エージェントは「停止条件のDSL」を持つ

彼らが割れるのは、失敗ではない。

DSL同士が衝突した、という事実が可視化されるだけだ。

小さな結論

AIはなめらかな計算しかできない。
だからこそ、

断絶は、計算の中に入れてはいけない。

オントロジーで意味を切り分け、
DSLで判断を凍結する。

その上で初めて、
AIは「使ってよい部品」になる。

AIは考えない。
だが、考えた結果を裏切らない装置にはできる。

それが、
ロジックを導入する本当の理由だ。

関連する具体設計（設計ノート群）

本稿で述べた
「断絶を計算の外に固定し、判断構造として残す設計」は、
以下のGitHubリポジトリで 具体的な設計原則・構造として整理している。

いずれも完成形ではない。
どこで意味が切り替わり、
どの判断がDSLとして固定され、
どこで人間に戻されるのかを
読める形で残すことを目的とした設計ノートである。

• ai-decision-system-map
  ─ 判断・データ・推論・ロジック・可視化を一つの構造として俯瞰する全体マップ
  （断絶がどこに現れるかを設計上で把握するための起点）

• decision-pipeline-reference
  ─ オントロジーとDSLを契約として固定し、
  判断がなめらかに溶けることを防ぐためのパイプライン設計

• multi-agent-orchestration-design
  ─ エージェントごとに異なる判断軸（DSL）を背負わせ、
  合意しないまま止まることを前提にしたオーケストレーション設計

• time-aware-data-for-ai
  ─ 判断が「いつの時点で有効だったのか」を保持するための
  バイテンポラルデータ設計（断絶の時間軸側の固定）

これらは
「賢いAIを作るための設計」ではない。

判断の境界を消さず、
割れた事実をそのまま残し、
人間が責任を引き取れる状態を保つための設計である。

その前提に立つ限り、
AIは初めて「使ってよい部品」になる。

また具体的なオントロジーを用いた実装に関しては”オントロジー技術“も参照のこと。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance