注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
構造レビューでは、オントロジーが意味的に一貫しており、技術的に正しいことを確認します。しかし、誰もがそれを使えるかどうかは確認できません。タスクベースの検証は、この隔たりを埋めます。オントロジーを利用する人やエージェントとともに、モデルが支えるべき意思決定や調査に照らしてモデルをテストします。
Palantir では、社内の分析演習を通じて、オントロジーの設計と使いこなす能力の両方をテストしています。チームには、単純な件数の確認から複数のステップからなる調査まで、事前に見たことのない業務上の問いが与えられます。参加者は汎用的な分析アプリケーションを使い、チームがそのタスク用に構築したワークフローやダッシュボードは使いません。この制約によって、アプリケーション固有の補助機能ではなく、オントロジーそのものをテストします。
ここで説明する検証方法は、これらの演習から得た知見に基づいています。企業のオントロジー設計を評価するために、これらの演習を状況に合わせて取り入れることを推奨します。オントロジーは、ソースシステムの生データをそのまま書き込んだものではありません。人やエージェントが企業を理解し、状況の変化を調査し、意思決定を行うためのインターフェースです。
これらの演習から得られた5つの教訓が、以降のガイダンスの基礎となっています。
| 教訓 | 説明箇所 |
|---|---|
| 構造的な正しさは、業務での使いやすさを保証しない | 構造レビューの限界 |
| 実際の業務上の問いが最適な受け入れテストになる | 実際の業務上の問いを集める |
| 新しいユーザーから重要な根拠が得られる | 演習設計上の判断 |
| 回答までの時間は設計を評価する手がかりになる | 結果を読み解く |
| 人とエージェントでは異なる弱点が明らかになる | 人とエージェントを比較する |
構造に関するガイダンスでは、オブジェクトタイプが一貫したエンティティを表しているか、リンクのカーディナリティに意味があるか、複数のタイプがインターフェースを共有すべきかを判断できます。こうしたレビューは不可欠です。モデルの内部的な整合性を評価し、後から変更する際に大きなコストがかかる設計上の選択を防ぎます。一方、業務上の問いだけを手がかりにオントロジーを使い始める体験は評価できません。
その体験は、スキーマ図から始まるのではありません。生産量の低下、出荷の到着遅延、在庫の紛失、予定された作業を危険にさらす遅延といった、業務上の状況から始まります。そこからユーザーは、状況をオントロジーの用語に置き換え、出発点として役立つオブジェクトタイプを見つけ、組織に対する自身の理解に合ったリンクをたどる必要があります。
これらのステップのそれぞれで、モデルがコンテキストを担うか、その負担をユーザーに戻すかが決まります。曖昧なオブジェクトタイプは、ユーザーに推測を強います。エイリアスがなければ、使い慣れた名前でオブジェクトタイプを見つけることができません。実際の関係ではなく、ソースシステムの結合を反映したリンクは、調査を中断させます。2つの概念が重複して表現されている場合、どちらの表現が正式なものかをユーザーがすでに知っている必要があります。
構築者は、こうした弱点があっても自身の記憶を頼りに進められることがよくありますが、構築者だけでは設計を検証できません。たどるべき経路を明確にするコンテキストは、オントロジーではなく構築者自身に由来するからです。
問いについても、同じ限界があります。構築者が既存のオントロジーを調べ、それで何に答えられるかを考えると、すでに網羅しているとわかっている範囲を検証することになります。このアプローチでは、そもそも設計に組み込まれなかった概念や関係が系統的に除外されます。
代わりに、組織の日常的な業務の流れから問いを導き出します。
最も有効な問いは、頻繁に生じ、かつ重大な意味を持つものです。そうした問いは、組織が実際の制約のもとで繰り返し行い、遅延や誤りに相応のコストが伴う意思決定を反映しています。
リーダーや現場担当者が重要な状況を認識する段階から始め、その状況を説明するオブジェクトや関係へと進みます。有用な流れには、一般に次の3種類の作業が含まれます。
オントロジーで重要な問いを自然に表現できない場合は、別の問いに置き換えるのではなく、その問いを保持してください。答えられないこと自体を結果として扱い、必要なドメイン概念、関係、または業務ロジックが設計にないかを確認します。そのうえで、演習の進め方によって、これらの問いからどれだけのことが明らかになるかが決まります。
演習でどれだけのことが明らかになるかは、参加者が使えるツール、参加者の選定、個人で取り組むかチームで取り組むかという3つの判断によって決まります。
特定の目的のために作られたアプリケーションは、正しい出発点、経路、フィルター、計算をあらかじめ組み込むことで、オントロジー設計の弱点を補えます。適切に構築された Workshop アプリケーションは、優れたワークフローを提供できても、その基盤となるモデルが単独で発見可能であり、必要なことを表現できるかどうかについては、何の情報ももたらさない場合があります。こうしたアプリケーションは演習から除外します。
誰が参加するかによって、結果の意味が決まります。経験豊富な構築者は、実装を完全に把握している状態で何ができるかを示します。オントロジーの構築に携わっていないドメイン専門家は、名前、説明、関係だけで意味が伝わるかどうかについて、より強い根拠をもたらします。経験の浅いユーザーは、モデルが組織内に蓄積された知識に依存せず、オンボーディングを支えられるかどうかをテストします。
チーム形式と個人形式では、異なる特性が明らかになります。チーム演習では、チーム全体で使いこなす能力をテストし、ユーザー同士がモデルをどう説明するかを確認できます。個人演習では、オントロジーに不慣れな人にとっての使いやすさを切り分けて評価します。チーム形式を使う場合は、最初につまずいた箇所がチーム全体の専門知識によって隠されないよう、助言を認める前に、支援なしで取り組むことから始めます。
演習は、オントロジーが参加者に代わってどれだけの作業を担うかを測定します。そのため、記録した観測は、収集した回答と同じくらい価値があります。
正確さは最低限の要件です。業務上の価値は、ユーザーがどれだけ迅速に答えを特定し、そこに至る経路を説明し、確信を持って行動できるかにも左右されます。
質問ごとに、参加者が正しい答えにたどり着いたかどうかと、調査にかかった時間を記録します。参加者がどこで迷い、どの検索語を使い、どのオブジェクトタイプやリンクを試し、支援を必要としたかを記録します。手動でのエクスポートや結合は、特に重要な手がかりになります。多くの場合、業務には意味のある関係が存在するものの、オントロジーには表現されていないことを示しているためです。
答えに至る経路は、最終的な答えよりも多くの情報をもたらすことがあります。参加者が混乱したときは、何が見つかると期待していたのかを尋ねます。参加者の言葉から、必要なエイリアスがないこと、不明瞭な説明、あるいはその業務領域では直感的でありながらモデルには存在しない関係を特定できます。想定外の経路から、有用な代替経路が見つかることもあれば、結果の不一致を生む曖昧さが明らかになることもあります。
観察した行動をもとに、症状と、その原因として最も可能性が高いものを区別します。
| 観察されること | 見直す対象 |
|---|---|
| ユーザーが起点となるオブジェクトタイプを特定できない | 不明瞭な名前、不十分なエイリアス、表示されるタイプの多さ、または説明の不足（不適切な命名） |
| ユーザーが同じ概念に対して異なるオブジェクトタイプを選ぶ | 重複、重なり、または区別が不十分な概念（部門のサイロ化） |
| ユーザーが関連していると考える概念間を移動できない | リンクがない、不適切な名前が付いている、方向が誤っている、または利用できない（リンク設計） |
| ユーザーがデータをエクスポートしたり、手動で結合を作成したりする | オントロジーに表現されていない、意味のある関係や再利用可能な分析上の概念（リンク設計） |
| 妥当な経路をたどっても異なる答えになる | 注文と注文明細やシップメントの違いなど、詳細度の不明瞭さ、または属性、単位、日付、集計ロジックの曖昧さ（命名規則） |
| 構築担当者や高度な技術知識を持つユーザーしか成功しない | ソースシステム固有の用語、明示されていない慣例、または不十分なドキュメント（システムのサイロ化） |
| 妥当な経路でも常に時間がかかる | クエリ、インデックス化、データ量、またはモデリングに起因するパフォーマンス上の制約（正規化と派生プロパティ） |
| 質問に答えられる妥当な経路がない | 必要なデータの不足、業務領域のカバレッジの不足、またはサポートされていない分析操作 |
難しいタスクすべてにオントロジーの変更が必要なわけではありません。まず、制約がモデル、基盤となるデータ、権限、分析アプリケーション、ユーザートレーニングのどこにあるかを判断します。1回の失敗はエッジケースの可能性があるものとして扱い、同じオブジェクトタイプや関係について繰り返し混乱が生じる場合は、設計全体に関わる問題の証拠として扱います。モデルの問題と知識の問題を切り分けるには、人間の参加者なしで同じ質問を再度実行します。
オントロジーには、人と AI エージェントという2種類の利用者がいます。それぞれが異なる能力を調査に活かします。人は、業務領域での経験、組織のコンテキスト、暗黙知を活かします。エージェントは大量のデータを検索・加工し、複数の経路を試すことができ、人と同じように視覚的な階層構造に依存せずに動作できます。
人を対象とした演習を終えたら、AIP Analyst または AI FDE で同じ質問を実行します。質問と必要なオントロジーへのアクセスは与えますが、人間の参加者がたどった経路は与えません。
この比較によって、オントロジーがどのような知識を明示しているかが明らかになります。
| 結果 | 調査する対象 |
|---|---|
| 人も AI も成功する | この質問に対して、モデルが発見可能で、必要な内容を表現できる経路を提供していることを確認します |
| AI は成功するが、人は苦戦する | 人向けの名前、エイリアス、説明、デフォルトの表示、視覚的な階層構造を見直します。また、そのタスクが本質的に大規模な自動分析に向いているかどうかも検討します |
| 人は成功するが、AI は苦戦する | 参加者が経験から補ったものの、オントロジーには明示されていないビジネスロジックや業務領域の知識を特定します |
| 人も AI も苦戦する | 必要なデータ、リンク、意味情報、または再利用可能なビジネスロジックが不足していないかを調べます |
AI のみでの実行は、人を対象としたテストの代わりにはなりません。評価する性質が異なり、チームの暗黙知に頼らずにエージェントが推論できるだけのコンテキストがオントロジーに含まれているかを評価します。これは、構築担当者が記憶を頼りに補っているのと同じ不足を、組織全体の規模で捉えるものです。人が成功するのが、すでに業務を知っているからにすぎない場合、その知識は依然として自動化が難しく、新しく加わる人に伝えることも困難です。
相互に補完する2つの演習を使用します。クイズ形式のゲームでは、互いに独立した多数の質問で幅広さを検証し、オントロジーに不慣れな人にとっての発見可能性をテストします。時間制限付きのドリルダウンでは深さを検証し、組織レベルの質問から詳細な業務情報まで、一続きの調査をチームが継続できるかをテストします。
最初の演習は、チーム間の競争として構成します。時間的なプレッシャーによって、参加者は調査経路を決め、その経路を見える形で示す必要があります。質問は事前に知らされないため、どのチームも質問に対応するワークフローをすでに作成した状態で参加することはできません。この形式は、参加者を引き込み、双方向のやり取りを促すものでもあります。
ゲームの実施には、次のガイドラインを使用します。
一続きの分析経路における深さ、連続性、速さをテストするため、2つ目の演習を推奨します。チームは大局的な質問から始め、決められた順序で質問をたどり、その背後にある業務の詳細へと進みます。
ドリルダウンの実施には、次のガイドラインを使用します。
どちらの形式でも、競争は任意です。その価値は順位そのものではなく、競争によって生まれる切迫感と集中にあります。
以下の各質問群は、状況を把握し、要因をたどり、影響を評価するという、大局から詳細へ進む同じ流れに沿っています。組織で使われる言葉、意思決定、責任に合わせて調整してください。
1回の設計サイクルでオントロジーが完成することはありません。ドメインは進化し、運用条件は変化し、新しい意思決定によってモデルに新たな要求が生じます。そのため、プロセスを継続してください。テストを繰り返すことで、オントロジーが引き続き、人とエージェントが使える形で組織を表現しているかを確認できます。
最初の演習に必要なのは、重要な意味を持つ少数の質問、モデルの作成に携わっていない代表的な参加者、汎用の分析アプリケーションだけです。進行役は、正確さ、所要時間、混乱、支援を記録します。演習後は、複数の質問に影響する変更や、価値の高いワークフローを妨げる問題への対応を優先します。いくつかの質問を繰り返して改善を測定し、その後、未見の質問を導入して、その改善がほかの質問にも当てはまるかを判断します。
時間の経過とともに、質問群はオントロジーの評価スイートになります。この評価スイートを使い、モデルが支える必要のある意思決定に照らして、新しいオブジェクトタイプ、リンク、データソース、業務ロジックを評価します。各演習から得た教訓が積み重なることで、意味がより明確になり、組織のコンテキストがより完全になり、調査がより速くなります。
望ましいオブジェクトタイプがすべてそろっていることも、最終的に回答を組み立てられる専門家がいることも、オントロジーの妥当性を証明するものではありません。人とエージェントが、組織の実際の運営を反映した経路を通じて、重要な意味を持つ質問から信頼できる回答へと繰り返したどり着ける必要があります。