第3章 配るのではなく導出する ― データエージェントとオントロジー
3.1 オントロジーを「配る」だけでは足りない
前章までで見てきたオントロジーは、要件定義のヒアリングの前に立つ仮説として使えることを見た。この同じ語彙は、自然言語をSQLに変換するデータエージェントの中でも働く。ただし、そこでの使い方は「共有コンテキストとして配る」というだけでは足りない。
データエージェントが「顧客の売上を教えて」と聞かれたとき、その「顧客」がどちらの定義を指すかを決めなければ、クエリは書けない。オントロジーをエージェントに渡すという構図は、この決定をエージェント自身の判断に委ねる前提に立っている。しかしオントロジーは、共有コンテキストであるだけでなく、エージェントが分裂した現実の上でどう振る舞うべきかを、記述そのものから導く基盤になりうる。配るものから、導出する土台へ。この転換が、この章の主題だ。
要件定義のヒアリングでは、語彙の分裂を埋める仕事を担当者の説明と担当者への確認が引き受けてきた。データエージェントには、その役目を引き受ける担当者がいない。エージェントは、質問されたその場で、分裂したどちらかの定義を選ぶか、確認を挟むかを決めなければならない。この決定を都度エージェントの内部判断に委ねるのか、あらかじめ記述側に持たせておくのかで、答えの安定性はまったく変わる。
3.2 質問者の位置がデフォルトを決める
エージェントの利用者は、必ず組織のどこかに属している。その人の帰属先、参照するレポート、担当する組織階層——こうした文脈は、オントロジーの中にすでに記述されている。だとすれば、デフォルトの定義をどちらにするかという選択は、エージェントごとに追加設定すべき項目ではない。質問者の位置から導出できる値になる。
営業部門の担当者が「顧客」と言えば、法人を指している可能性が高い。カスタマーサポートの担当者が同じ語を使えば、担当者個人を指している可能性が高い。熟練した業務エンジニアは、この推測を意識せずにやっている。エージェント化するというのは、この推測を都度の勘としてLLMに委ねることではない。推測の根拠になっている量を、質問者の位置から取り出せる形にしておくことだ。
3.3 二つの量を、実行時の判断から定義側へ
第1章1.6で、熟練者の勘は優位性と訂正リスクという二つの量に分解できると述べた。優位性は、資料の中でのその定義の流通量——どの部門のどの帳票でどれだけ使われているかという事実。訂正リスクは、間違った定義を選んだときに訂正が効く場所と効かない場所の違いという事実。どちらも規範的な「正しさ」の判定ではなく、業務資料と業務プロセスの構造から読み取れる、記述の側の量だ。
ここで問われるのは、この二つの量をどこで使うかだ。データエージェントが実行時に「たぶんこちらだろう」と推測して答えるなら、この二つの量はエージェント個体の内部判断に埋もれてしまう。同じ質問でも、モデルが変われば答えが変わりかねない。そうではなく、優位性と訂正リスクをオントロジー側の定義にあらかじめ封じ込めておけば、デフォルトの選択は都度の即興ではなく、記述から導出される結果になる。指標の定義に計算条件を封じ込めるのと同型の手が、ここでも効く。
3.4 具体例:「顧客の売上」という問い
抽象的な話を、一つの例に落としてみる。営業部門の担当者が、社内のデータエージェントに「今月の顧客の売上を教えて」と聞いたとする。オントロジーがなければ、エージェントはどちらかの「顧客」定義を無根拠に選ぶか、あるいは毎回「法人ですか、担当者個人ですか」と聞き返すかのどちらかになる。前者は間違った答えを黙って返すリスクを抱え、後者は同じ確認を延々と繰り返す。
オントロジーがあれば、この二択にならない。質問者が営業部門に属しているという文脈と、「顧客=法人」という定義が営業部門の帳票で優位に流通しているという事実から、エージェントは法人としての売上を返してよいと導出できる。同時に、この定義には訂正リスクが伴うという情報も付随している——月次決算で株主・監督官庁向けに外部提出される数字なら訂正が効きにくく、社内ダッシュボード上の速報値なら訂正が効きやすい。訂正リスクが高い場合は、答えに「法人としての売上」という定義を明示し、低い場合は黙って答えてよい。この判断はエージェントがその場で発明するものではなく、オントロジーの記述からそのつど導出される。
3.5 統一するかどうかは業務側が決める
分裂とは、同じ語が文脈によって異なる意味で使われている状態のことだ。「顧客」が営業部門では法人を指し、カスタマーサポートでは担当者個人を指す。これは解決すべき問題ではなく、記録すべき現実だ。
この分裂を見て「統一したほうがいいか」を判断するのは、業務側の仕事であって、システム側の仕事ではない。システム側は現実を受け入れるだけだ。オントロジーは語彙の地図と、その語彙を使う人の位置を両方持っているから、「この人はおそらくこの語彙で動いている」という推測はできる。ただしそれは確定ではなく推測であり、外れれば訂正される。統一の判断は、この推測のどこにも含まれていない。
「統一か分裂か」という問いの立て方自体が、実はずれている。本当の対立軸は、第1章で述べた通り「現実の記述か、規範の押し付けか」だ。データエージェントの文脈でこの原則を守るということは、エージェントが答えを出す瞬間に、業務側の判断を勝手に代行しないということだ。
3.6 仮置きと訂正可逆性
デフォルトを置くこと自体は問題ではない。問題は、それを訂正可能な形で置いていないことだった。優位な定義を前提として答えを出し、違っていれば直せと言う——これは統一しているわけではない。仮に置いているだけで、定義の分裂は保持されたままだ。
「デフォルトを置いて後から訂正させる」か「先に確認を取ってから答える」かの判断を、実行時にLLMにさせる必要はない。この判断もまた、オントロジー側に持たせられる。優位性が高く訂正リスクが低い語彙については仮置きで即答してよく、優位性が拮抗しているか訂正リスクが高い語彙については、答える前に確認を挟む。この閾値の置き方自体が、記述から導出される設計対象になる。
3.7 明示の目的は統一ではない
人間同士の業務では、文脈が違えば話す相手も違う。だから他部門の定義の数字は、そもそも手元に来ない。この自然な隔離が、ミスコミュニケーションの発生を無意識に抑えていた面がある。ところがデータエージェントは、誰から聞かれても同じように答えてしまう。この隔離が外れる。
だからこそ、答えに定義を添える必要がある。それは語彙を統一するためではない。利用者が「どちらの定義で出した答えなのか」を認識できるようにするためだ。認識できなければ、分裂を保持したまま訂正を受け付けるという、この設計全体の原則が名目だけのものになる。優位性が高い定義で黙って答え、ずれているときだけ定義を添える、という運用は導出できる。ただしどれだけずれたら添えるべきかという閾値は、現場で試さなければ決められない領域だと見ている。
3.8 収束点 ― 振る舞いは記述から導出される
ここまでの流れを一つにまとめると、こうなる。あらゆるデータエージェントのコンテキスト記述の方式を、オントロジーという一つの形式に集約する。オントロジーは配布インフラであるだけでなく、エージェントの振る舞いを記述から導出する基盤そのものになる。
これはCore第6章のV = f(S, R, T)で言えば、構造(S)を固定しすぎれば冷却崩壊、関係(R)の揺らぎに任せすぎれば過熱崩壊になる、というあの適温の議論の延長線上にある。データエージェントの答えを完全に固定ルールで縛れば、部門ごとの語彙の違いに対応できなくなる。逆にすべてを実行時のLLM判断に委ねれば、同じ質問への答えが揺れて再現性を失う。優位性と訂正リスクという二つの量をオントロジー側の定義に封じ込めることは、この適温を実行時の判断としてではなく、記述の設計として作り込む作業にほかならない。
3.9 まだ残る問い
この設計が機能するのは、利用者が定義の差異を認識できる場合に限られる。認識できなければ、仮置きは訂正されないまま残る。分裂を許容できるかどうかの実質的な条件は、ここにある。
もう一つ、ドメインの変化とともに語彙自体が育っていくとき、その世話を続けるのは誰かという問いも残っている。業務資料を継続的にサンプリングし直すのか、訂正の蓄積そのものが語彙を更新していくのか。これも今の時点で結論を出すべき問いではなく、実践の中で答えが出てくるものだと見ている。
この態度は、第1章で触れたCore第3章「粒子性と波動性」の均衡とも重なる。データエージェントの答えを一つの定義に固定してしまえば、粒子性だけを取って波動性を切り捨てることになる。逆にすべてを実行時の揺らぎに任せれば、答えとしての形を持たなくなる。優位性と訂正リスクを記述側に持たせるという設計は、分裂という個々の事実を保ちながら、それでも一つの答えとして立ち上がる構造を与える試みだ。
第1章で述べた分裂の保持という原則、第2章で述べたヒアリングの仮説化、そして本章で述べた振る舞いの導出——この三つは、同じ一つの態度の異なる現れ方にすぎない。オントロジーを、解釈を最小化した記述として扱い続けること。それが要件定義であれ、データエージェントであれ、変わることはない。