AIエージェント向けのポータブルなビジネスオントロジー

「オントロジー」という言葉が、いま注目を集めています。なぜでしょうか。エージェントと、それを支えるLLMには、関連するビジネスコンテキストが必要だからです。

オントロジーを導入する前に、ベンダーにこう尋ねてみてください。「オントロジーが自社のビジネスを誤って捉えた場合、どうすれば自社の担当者が修正できますか。また、その際もベンダーに依存し続けるものは何ですか」。その答えから、どのようなビジネスモデルを導入しようとしているのか、多くのことが分かります。また、より大きな課題も見えてきます。ビジネスの変化に合わせてそのモデルを改善し、プラットフォームを変えた場合も、投じた労力を無駄にせず活用し続けられるかどうかです。

オントロジーと知識グラフは重なる部分も多いものの、それぞれを区別して考えると理解しやすくなります。

オントロジー：どのようなものが存在するのか、関係性が何を意味するのか、どのようなルールが適用されるのかを定義します。設備、部品、チーム、役割、プロセスなどが対象です。たとえば、オントロジーでは「設備」という型と、「部品」に対する「含む」という関係を定義できます。すると知識グラフでは、「ポンプ P-101 はシール S-7 を含む」と記述できます。これは、2つの具体的なエンティティと、それらの関係を表しています。

エージェントに、こう頼む場面を想像してみてください。「既存店売上高の成長率を計算してください。全店舗を対象にした比較表と、開業から2年未満の店舗を除外した比較表を並べて表示し、それぞれを国内、海外、合計に分けてください」。

この依頼に応えるには、エージェントが推測できない次のような詳細情報が必要です。

• どの店舗が存在し、それぞれいつ開業したのか
• それぞれの店舗がどこにあるのか
• 「既存店売上高」の社内定義

ポリシーによっては、開業から1年が経過するまで店舗を対象外とする場合があります。今回指定された2年間のグループでは、さらに条件が加わります。それでも、店舗が条件を満たした時点から暦月単位で比較するのか、それとも直前の会計年度を丸々経過してから対象に含めるのかを決める必要があります。

オントロジーでは、店舗と、その計算を規定するポリシーを結び付ける必要があります。関連する事実を見つけることも役立ちますが、正しいルールを適用してこそ、答えが実用的なものになります。

エージェントは、質問に答える前に、グラフ内の関係を利用して関連するコンテキストを取得できます。知識領域は非常に複雑になりやすいため、エージェントが役立つのも当然です。

図1：公開SysMLモデルを統合したグラフ：TMT Thirty Meter Telescope（Open-MBEE/JPL、Apache-2.0）、CubeSat System Reference Model（© 2022 INCOSE SSWG & OMG SDTF、CC BY 4.0）、Architecting Spacecraft with SysML（Friedenthal & Oster、BSD-2-Clause）、および架空のMDCコンステレーションの内容と公開仕様（IS-GPS-200、IS-GPS-705、GSFC-STD-7000B）。Kamiwaza Kaizenでレンダリング。

ただし、抽出によって誤りが生じることもあります。同じエンティティに異なる名前が使われて、重複が発生する場合があります。情報源同士の内容が食い違ったり、古くなったりすることもあります。情報源に問題がなくても、LLMが誤読する可能性があります。こうした誤りを信頼できる情報のように見せても、危険性がなくなるわけではありません。

ビジネスモデルが、そのビジネスに対して実際に作用するシステムになると、こうしたリスクはさらに大きくなります。誤った関係性が、誤答を生むだけでなく、誤ったアクションを引き起こすおそれがあるからです。

オントロジー製品に潜むリスク

まず、柔軟性に欠けるモデルには注意が必要です。「必要な機能が最初からそろっている」ことをうたう一方で、ベンダーが自社のエンティティを優先的に扱い、ユーザー独自のエンティティにできることを制限する場合があります。独自の型を追加できても、検索、検証、アクションの機能が使えなくなるのであれば、カスタマイズできるだけでは不十分です。

次に、発見からガバナンスへと進める手段があるかを確認しましょう。LLMが認識した情報からグラフの初期版を構築し、それを明示的な制約に照らして検証できるツールが望まれます。例外を担当者にエスカレーションでき、探索段階の知識を、承認済みの業務データとして扱うことなく保持できる必要もあります。

最大のリスクは、離脱できないプラットフォームにビジネスプロセスを結び付けてしまうことです。オントロジーは、自社の知識、プロセス、関係性を表すものです。情報の整理やビジネスロジックに投じた労力は、ツールを変えても活用し続けられるべきです。なぜ、それをベンダーの管理下に置かれなければならないのでしょうか。

グラフ埋め込みが役立つ場面

ナレッジグラフが非常に大規模になるにつれ、グラフ埋め込みに対応したツールやベンダーを選ぶ価値が出てくることがあります。グラフ埋め込みは、多くのRAGアプリケーションを支える意味埋め込みに近い手法です。検討に値する利点は2つあります。

まず、密につながったグラフを数段たどるだけで、処理しきれないほど多くのエンティティに行き着くことがあります。埋め込み表現は、エンティティと関係性を数値で表すことで、グラフ内の関連箇所を見つける別の方法を提供します。タスクによっては、グラフをたどるより効率的です。

次に、埋め込みモデルを使って、欠けている可能性のある関係性の候補に順位を付けられます。同じ学習によって、あるエンティティ型に典型的な属性や関係性のパターンを見つけることもでき、より完全なグラフの構築に役立ちます。

段階的な改善が重要な理由

自社の進む道を自ら決め、ベンダーロックインを避け、ベンダーの都合で作られた歪んだビジネス像ではなく、実際の自社ビジネスをモデル化するには、大規模な現地常駐エンジニアチームなしで、どう始めればよいのでしょうか。発見から検証へ進む道筋をツールが支えてくれるなら、現代のAIはここで力を発揮すると私は考えています。

まず、自動化された探索と抽出を活用します。業務文書、社内規定、メール、Slackのメッセージから、ある領域の初期像を構築できます。重要なのは、検証が済むまでは、その内容が正確だと信頼してはならないことです。

次の段階は検証です。ツールには、抽出された候補から、情報源に裏付けられた主張へ、さらに責任者または権威あるシステムによって検証された知識へと、円滑に進める手段が必要です。個々の主張について、その情報源を保持してください。

情報を最新の状態に保つには、継続的な取り組みが必要です。トラブルチケットへの対応手順も、「ニュージャージー州には店舗がいくつあるか」という問いへの答えも、3年前と今日とでは異なるかもしれません。しかし、今日の知識を更新しても、昨日の現実を消し去ってはなりません。事実が記録された時点と、その事実が当てはまる時点は異なる場合があります。有用なオントロジーは、現在の問いへの回答と、正確な過去の状況の両方を支えられる必要があります。その知識を最新の状態に保つ作業は、今も誰かが担わなければなりません。

対象範囲は非常に広大になり得ます。まずは小規模なコーパスから始め、有用な領域をモデル化し、その過程で価値を生み出しながら、包括的な全体像の構築を目指しましょう。

カスタマーサポートは、有用な対象領域の一つです。そこには、受信した電話やメール、チケット管理システム、自動解決、顧客に対応できるサポートチーム、そして実際のバグをエンジニアリング部門にエスカレーションする手段が含まれます。知識とアクションを結び付け、管理しやすい領域の中で、同じリスクとメリットを明らかにします。

ServiceNowのCommon Service Data Modelは、この制約を示す一例です。CSDM 5の白書では、「指定されたテーブルにこのデータがなければ、ServiceNow AI Platformの価値を十分に得られない可能性があります」と警告しています。この警告そのものが、設計と運用上の制約を生みます。ベンダーのモデルに合わせるか、リスクを受け入れるかです。それが、自分の丸い杭を相手の四角い穴に無理やり押し込むことを意味するとしたら、どうでしょうか。

さらに、オントロジープラットフォームがデータの取り込み、変換、アクション、ビジネスルールも提供するとします。エンティティ、属性、関係性はエクスポートできるかもしれません。しかし、データベースを変更し、Webhookを呼び出し、その他の副作用を引き起こす変換処理やアクションパイプラインも、別の環境に移行できるでしょうか。統合が緊密に結び付いていると、ビジネスそのものまで特定のプラットフォームに縛られかねません。

今、柔軟性が重要な理由

ソフトウェアが世界を飲み込み、AIがソフトウェアを飲み込んでいます。チームがAIを使ってソフトウェアを開発し、さらにソフトウェアを動かすようになるにつれて、より多くのビジネスロジックがこうしたプラットフォームに結び付く可能性があります。便利な自動化も一つ増えるごとに、移行時の依存関係が増えることになり得ます。ベンダーが自社の俊敏性を妨げる存在になるのは危険です。

結論

今は、生きていることが素晴らしい時代です！人々がエージェントにコンテキストを与えるため、オントロジーに注目しているのも不思議ではありません。そのコンテキストをプロセスや統合にまで広げれば、真の価値を生み出せます。冒頭の問いに立ち返ってみましょう。人々による修正を反映することで、モデルは自社の実態をより正確に映し出すものになるはずです。積み重ねてきた知見は、プラットフォームを変更したときに失われるには、あまりにも価値があります。また、身動きの取れない状況に追い込まれるには、あまりにもひどい時代です。