第1章 分裂と摩擦 ― なぜ語彙は揃わないのか

1.1 モデルは解釈だ、オントロジーはその一段手前にある

モデルは解釈だ。何を捨てて何を残すかを決めた瞬間に、そこには規範が入り込む。ER図を引くにせよドメインモデルを設計するにせよ、設計者は必ず「どちらか一方の意味に決める」という判断をしている。その判断自体が悪いわけではない。ただし、判断であるという自覚を欠いたまま「これが正しい姿だ」として扱うと、現実との齟齬が後から必ず戻ってくる。

オントロジーは、その一段手前にある。解釈を最小化した記述だ。業務資料を広くサンプリングし、そこに現れる語彙を機械的に抽出する。この抽出の過程にも選択は起きる——何を読み込み、何を候補として残すかという選択だ。しかし、そこに「統一する」という判断は含まれていない。できあがった記述に異議があれば申し出てもらえばいい。訂正を受け付けることが、この設計の原則そのものだ。

だからオントロジーは、単語帳でも静的なスキーマでもない。構造を持ち、変化を内在させた語彙としてドメインを記述したものだ。この位置づけ——モデルの一段手前に、解釈を最小化した記述層を置くという発想——が、AI時代のシステム開発にもエージェント利用にも、これまで欠けていた。

この対比は、Core 第6章「統合の倫理」が構造（S）と関係（R）を分けて定式化していることと同じ形をしている。モデルが選び取るのは構造（S）——何を境界として固定し、何を秩序として確定するかという判断だ。オントロジーが記述するのは関係（R）——語彙同士のつながりと流通のありようであり、まだ一つに収束させていない状態そのものだ。モデルが構造を選ぶ営みなら、オントロジーは関係を記述する営みだ、と言い換えてもいい。

1.2 現実をモデルに合わせてきた代償

DDD（ドメイン駆動設計）も、それ以前からの一般的なシステム開発も、力の掛け方は一貫していた。現実をモデルに合わせる側に力をかけてきたのだ。bounded context で領域を分割しても、context の内側では統一が強制される。ER図もスキーマも、実装するためには一つの定義に決め切らなければならない。

しかし現実はそう単純ではない。同じ語が部門によって違う意味で使われている——これは日常的に起きていることだ。「顧客」が営業部門では法人を指し、カスタマーサポートでは担当者個人を指す。この分裂は、これまで「解決すべき問題」として設計の外に押し出されてきた。設計の外に出された問題は消えるわけではなく、人間がそのギャップを埋め続けることになる。

このギャップを埋めるコストが、摩擦だ。語彙の意味のずれは、要件定義のやり直しを生み、仕様解釈の対立を生み、リリース後の例外処理を生む。モデルが現実に追いつかないたびに、誰かがその差分を手作業で埋めている。この摩擦は偶発的なバグではない。現実をモデルに合わせるという設計方針そのものが構造的に生み出している摩擦だ。

向きを変えればいい。現実をモデルに合わせるのではなく、現実の語彙を先に記述しておく。設計はその記述の上に乗る。語彙が先にあれば、ミスコミュニケーションの根はヒアリングが始まる前に抜いておける。

もう一つ、見落とされがちな点がある。世の中のシステムの多くは静的なデータしか扱わない。変化は「システム更改」という形で外部から注入されるものであり、概念モデルの内側には変化そのものが組み込まれていない。しかし業務の現実には、変わらないものと変わるものが常に混在している。この区別を語彙の中にあらかじめ持たせておくかどうかが、静的なスキーマとオントロジーを分ける本質的な違いだ。

1.3 業務資料から語彙を抽出する

このオントロジーは、どこから来るのか。答えは業務そのものからだ。

規程、マニュアル、帳票、議事録、メールといった過去の業務資料をサンプリングし、AIに読み込ませる。最初の仕事は共通語彙の抽出だ。ひとつの文書にしか登場しない語彙は、共有語彙とは呼べない。複数の文書、複数の部門にまたがって繰り返し使われている語彙だけが、そのドメインの共通語彙の候補になる。抽出した後は人間がレビューして語彙を圧縮する。ここで調整するのはサイズではなく、定義の粒度だ。

全量を読み込む必要はない。サンプリングが十分に横断的であれば、変わらないもの、変わるもの、そして実際に存在する業務のパターンは浮かび上がってくる。

業務資料をサンプリングし、AIが抽出し、オントロジーができる。このオントロジーが、以降のすべての開発とエージェント利用の起点になる。

ここで確認しておきたいのは、このフェーズがシステム開発ではないということだ。成果物はコードではない。お客さん自身が「自分たちの業務はこういう構造になっている」と確認できる、語彙の地図だ。

1.4 分裂を保持するという設計原則

ここが、この章でいちばん強く言いたいことだ。分裂は統一しない。保持する。

「顧客」という語が部門によって違う意味を持つとき、それをどちらかに統一するのは業務側の判断であって、システム側の判断ではない。システム側がやるべきことは、現実をそのまま受け入れることだ。オントロジーは語彙の地図と、その語彙を使う人の位置を両方持っている。だから「統一か分裂か」という問いの立て方自体が、実はずれている。本当の対立軸は「現実の記述か、規範の押し付けか」だ。

DDD の bounded context が実践の場でしばしば機能不全に陥るのは、設計が規範的になった瞬間に現実と乖離するからだ。境界を引いた瞬間、その境界は「あるべき姿」になり、現実の分裂を覆い隠してしまう。オントロジーが業務資料から導出される限り、それは観察した事実の記述にとどまる。事実の記述である限り、分裂は分裂のまま残せる。

この設計判断は、Core 第3章「粒子性と波動性」の核心命題そのものだ。存在には、境界を持ち形を定める粒子性と、つながりながら流れる波動性という、相補的な二つの相位がある。片方だけを取って固定しようとすると、必ず無理が出る。統一しようとする力が強すぎれば、現実との摩擦が硬直化し、業務の実態を締め出す制度になる。逆に何も決めずに拡散させれば、共有できる語彙すら残らない。オントロジーが目指しているのは、この二つの相位を同時に生かしたまま——分裂という個々の事実を保ちながら、それでも横断的に参照できる構造を与える——という、動的な均衡そのものだ。分裂の保持は妥協ではなく、第3章が「対立ではなく相補的な相位」と呼んだ均衡を、語彙の設計に持ち込むという選択だ。

1.5 要件定義とデータエージェントは、同じ問題を抱えている

要件定義のヒアリングで起きていることと、データエージェントが自然言語の問いをSQLに変換するときに起きていることは、実は同じ形をしている。どちらも、自然言語という曖昧な入力を、何らかの形式的な構造に写像する作業だ。

要件定義では、この写像を人間のヒアリングが担ってきた。属人的で、担当者の経験と勘に依存する。データエージェントでは、この写像をLLMが担うことになる。ここで問題になるのが温度だ。何も定義せずにLLMの推論に任せれば、揺れが大きすぎて再現性がなくなる。逆にすべてを固定的なルールで縛れば、現実の分裂に対応できなくなる。

オントロジーは、この写像作業の適温を作るための装置だ。変わらないものと変わるものを語彙の中で区別しておくことで、固定してよい部分と、揺らぎを許容すべき部分を先に切り分けておける。要件定義のヒアリングも、データエージェントの語彙選択も、この切り分けの上に乗ることで、初めて安定した写像になる。

Core 第6章はシステム価値を V = f(S, R, T) と定式化し、構造（S）が固定されたまま関係（R）の熱だけが下がる状態を冷却崩壊、逆に関係（R）が構造（S）を追い越して暴走する状態を過熱崩壊と呼んでいる。要件定義もデータエージェントも、この式のカオスの淵——固定すべきところは固定し、揺らいでよいところは揺らがせる適温——を語彙のレベルで実装する作業だ、と言い換えられる。

1.6 業務エンジニアが暗黙にやってきたことを、どうエージェント化するか

ここまでの話を、「結局、業務エンジニアが頭の中でやっていたことをAIにやらせるだけだ」とまとめてしまうと、当たり前の話に聞こえてしまう。だが、実際に何をエージェント化しようとしているのかを分解すると、当たり前ではない部分が見えてくる。

当たり前に聞こえる版と、実際に主張している版は、次の一点で違う。当たり前に聞こえる版は「熟練者の勘をAIに真似させる」という話で、これは模倣の精度の話でしかなく、常識の確認に留まる。実際に主張しているのは、その勘の中身が優位性と訂正リスクという、業務資料と業務プロセスの構造から機械的に取り出せる二つの量に分解できる、という話だ。勘は模倣する対象ではなく、分解して取り出す対象になる。この分解が成立するのは、オントロジーが語彙の流通量と訂正可否という事実だけを扱い、「どちらが正しいか」という規範判断を扱わないという、1.1〜1.4で述べた記述と解釈の区別があるからだ。この区別なしに「暗黙知をエージェント化する」と言っても、それは結局LLMに丸投げする話に戻ってしまう。非自明さは、勘という主観的なものを、規範を持ち込まずに量として取り出せる、という具体的な導出経路の側にある。

熟練した業務エンジニアは、質問者がどの部門の、どの立場の人間かを見た瞬間に、その人がどの語彙で話しているかを推測し、デフォルトの解釈を選んでいる。この推測は、これまで言語化されず、その人個人の暗黙知として蓄積されてきた。エージェント化するというのは、この推測を「なんとなくの勘」としてLLMに丸投げすることではない。推測の根拠になっている量を、名指しできる形で取り出すことだ。

具体的には二つの量がある。一つは優位性——どちらの定義がこの文脈で支配的かという量で、資料の中での流通量、つまりどの部門のどの帳票でどれだけ使われているかから取れる。これは規範的な「正しさ」の判定ではなく、事実としての流通量なので、記述の立場を崩さずに扱える。もう一つは訂正リスク——間違った定義を選んだときに何が起きるかという量で、訂正が効く場所(画面上の数字)と効かない場所(承認済みで外部に出た数字)の違いから読み取れる。これも評価ではなく、業務プロセスの構造から読める事実だ。

非自明なのはここだ。熟練者の勘を「まるごと模倣する」のではなく、勘の中身を優位性と訂正リスクという二つの量に分解し、それを実行時にLLMへ判断させるのではなく、オントロジー側の定義にあらかじめ封じ込めておく。これによって、デフォルトの選択は都度の即興ではなく、記述から導出される結果になる。業務エンジニアが無意識にやっていた判断を、意識の外から意識の中に引きずり出す作業——それがここでのエージェント化の実質だ。

明示すべき理由も、統一のためではない。人間同士の業務では、文脈が違えば話す相手も違うので、他部門の定義の数字がそもそも手元に来ない。ところがエージェントは誰にでも同じように答えてしまうので、この自然な隔離が外れる。定義を添えるのは、利用者が「どちらの定義で出した答えなのか」を認識できるようにするためだ。認識できなければ、訂正を受け付けるという設計の原則そのものが名目だけのものになる。

1.7 次章への接続

ここまでで、オントロジーがモデルの一段手前にある記述であること、分裂を統一せずに保持すべきものであること、そして業務エンジニアの暗黙知をどう分解してエージェント側に渡せるかを見てきた。

次章では、この語彙の記述の上に、AI駆動の開発がどう乗るのかを見ていく。ヒアリングの前に仮説を持てるということが、設計プロセスのどこをどう変えるのか。そしてその後の章では、この同じ語彙が、自然言語をSQLに変換するデータエージェントの中でどう働くのかを見ていく。

まだ答えの出ていない問いも残っている。定義のずれをどこまで明示し、どこから黙っていいのかという閾値の問題。訂正の仕組みが機能する条件——利用者が差異を認識できることそのものが前提になっているという事実。そして、ドメインの変化とともに語彙自体が育っていくとき、その世話を誰が続けるのかという問題。これらは今の時点で結論を出すべきものではなく、実践の中で答えが出てくるものだと見ている。