意味を検索するAIから、意味を根拠に判断できるAIへ ― EvoOntologyに着想を得た、Semantic Decision Runtimeという構想

🎥 YouTubeでも公開しています

意味を根拠に、安全に判断・実行するAIへセマンティック・ディシジョン・ランタイム入門

Books: Semantic Chunk 根拠ある意味単位からつくる: 文書・表・業務データを、説明可能で実行可能な知識へ

生成AIが企業のデータを扱う場面では、しばしば「データに接続できること」と「データを正しく理解できること」が混同される。

AI Agentは、データベースのテーブルを参照できる。CSVを読み込める。社内文書を検索できる。SQLも生成できる。しかし、それだけで「売上」「顧客」「取引」「承認済み」「有効な契約」といった業務上の言葉を正しく理解できるわけではない。

たとえば、売上には受注額、請求額、入金額、取消後の純売上がありうる。顧客には見込み客、契約主体、利用者、請求先が混在する。ある列が存在しても、それがいつから有効か、どの部門の定義か、例外をどう扱うかは、列名だけからは分からない。

この「データはあるが、意味が共有されていない」という隔たりは、AI Agentを業務に接続する際の本質的な課題である。

最近発表されたEvoOntologyは、この課題に対して重要な示唆を与えている。実データの意味をオントロジーとしてMCPサーバーに包み、Agentが実行時に意味を探索・解決できるようにする。そして失敗を分析し、改善版が同条件で旧版を上回った場合にのみ定義を採用する自己進化ループを備える。これは、意味定義を静的な辞書から、評価されながら育つ運用資産へ変える発想である。

Chinobaでは、この発想を出発点としながら、対象をデータ探索だけに限定しない。目指すのは、Semantic Decision Runtime――意味、根拠、方針、権限、判断、実行、結果を接続する基盤である。

オントロジーは「用語集」ではない

従来、オントロジーは用語の定義やデータ項目の対応表として扱われがちだった。それは重要だが、業務AIに必要なのはさらに広い。

「純売上」という概念であれば、必要なのは名前と数式だけではない。

• どの取引を含め、取消・返金をどう控除するのか
• どの規程、データソース、責任部門を根拠とするのか
• 定義はいつから有効か
• 誰が閲覧、集計、外部送信、更新してよいのか
• この数値を用いて、どこまで自動で判断・実行してよいのか

Semantic Decision Runtimeでは、概念を「データへの対応」ではなく、意味と責任を持つ判断可能な単位として保持する。

semantic_object:
  id: metric.net_revenue
  label: 純売上
  definition: 売上から取消・返金を控除した確定額
  sources:
    - table: order_transactions
      columns: [amount, status, refunded_at]
  calculation: "SUM(amount WHERE status='settled') - SUM(refund_amount)"
  owner: finance
  valid_from: 2026-01-01
  evidence:
    - policy: finance_metric_definition_v3
  access_policy: finance_analyst_only
  risk: medium

この形式なら、Agentは「どのSQLを作るか」だけでなく、「なぜそのSQLなのか」「その結果を誰に見せられるのか」を説明できる。

知識、判断、信頼、実行を切り離さずにつなぐ

Chinobaの研究は、Knowledge Flow、Decision Trace Model、Trust Infrastructure、Runtime OSを、それぞれ別の機能としてではなく、一つの判断ループとして扱ってきた。

Semantic Decision Runtimeは、このループにおける意味の接続層となる。

1. Knowledge Flowが、文書、表、API、会話、業務ルールを、概念・関係・制約・指標へ変換する。
2. Semantic Layerが、質問やタスクに含まれる言葉を、実データ、定義、根拠、適用期間へ解決する。
3. Decision Layerが、状況、目的、制約、選択肢、理由を結び、何を判断すべきかを明らかにする。
4. Trust Infrastructureが、知識の根拠、Agentの能力、判断の妥当性、実行の影響を評価する。
5. Runtime OSが、権限、境界、Human Gateに基づいて、実行、確認依頼、停止を選択する。
6. Decision Traceが、意味解決から結果までを記録し、次の改善に戻す。

重要なのは、意味を理解したからといって、直ちに実行できるわけではない点である。

たとえばAIが「顧客の解約リスクが高い」と判断するための定義を解決できても、その顧客に自動で連絡してよいとは限らない。個人情報、契約、ブランド、担当者の責任範囲といった境界を確認し、必要なら人に引き継ぐ必要がある。

意味の解決は、実行の許可ではない。この分離が、安全に自律性を高める前提になる。

Palantir Ontologyを実務ベンチマークとして読む

この構想を考えるうえで、実務上の重要なベンチマークになるのがPalantir FoundryのOntologyである。

PalantirはOntologyを、データセット、仮想テーブル、モデルなどのデジタル資産の上に置く「組織のOperational Layer」と位置付けている。設備や製品のような物理的対象から、受注や金融取引のような業務概念までを、Object、Property、Linkとして実世界に対応付ける。そして、Action、Function、Dynamic Securityを組み合わせ、分析結果を実際の業務ワークフローへ接続する。Palantir Ontology Overview

これは、オントロジーをデータカタログで終わらせず、組織が判断し、行動するための共通モデルとして扱う実装例である。Palantirのアーキテクチャ説明でも、意味を表す「名詞」と、変化を起こす「動詞」を組み合わせ、単純な更新から複数ステップの業務処理までをモデル化するとしている。The Ontology system

Chinobaがここから学ぶべきことは、製品や実装方式をそのまま模倣することではない。次の三点を、比較可能な実務ベンチマークとして受け取ることである。

Palantirの価値は、ダッシュボードで組織を「見る」だけではなく、Ontologyを介して分析と運用を閉ループにする点にある。公式ドキュメントも、Ontologyを人とAgentの活動をまとめて統制する、意思決定中心の組織モデルとして説明している。Why create an Ontology?

一方、Chinobaの焦点は、特定の統合プラットフォームを構築することではない。異なるデータ基盤、MCP、Agent、DSL、ルールエンジン、既存業務システムを横断して、意味と判断の責任を持ち運べるようにすることである。したがって、Semantic Decision Runtimeは、Palantirが実証してきた「Semantic Operational Layer」という到達点を参照しながら、より明示的に根拠の来歴、時間的な状態、信頼評価、Human Gate、Decision Trace、自己改善を中核に置く。

これは優劣の比較ではない。大規模な業務データを、Object・Link・Actionとして統合し、意思決定と運用を結ぶPalantirの実践と、MCP時代のAgentが意味を探索し、根拠を示し、境界の中で協調するためのChinobaの構想は、互いに接続して読める。

根拠を返すMCPへ

Semantic Decision RuntimeのMCPは、単なる検索やSQL生成のためのMCPではない。Agentが意味を扱う過程を、検証可能にするためのインターフェースである。

特にresolve_semanticsは、答えだけを返してはいけない。少なくとも、採用した定義、データソース、根拠、適用条件、曖昧さ、利用上の制限を構造化して返す必要がある。

これは「説明を後から生成する」設計ではない。判断の入力として利用した意味と根拠を、最初から実行経路に含める設計である。

自己進化を、信頼できる改善へ変える

意味定義は、一度作れば終わるものではない。制度は変わり、データ構造は変わり、組織が使う言葉も変わる。Agentの誤答は、モデル能力の限界だけでなく、意味定義の欠落、関係の誤り、古いルール、曖昧な責任範囲からも生まれる。

そこで、失敗を次のように分類する。

• 誤った概念に解決した
• 正しい概念だが、古い定義を参照した
• 根拠はあったが、適用範囲を誤った
• 方針・権限・境界を見落とした
• 結果のフィードバックが定義に戻っていない

改善候補は、直接本番へ反映しない。旧版と新版を同じデータ、同じ質問集合、同じモデル、同じ予算条件で比較する。そして、精度だけでなく次を満たすときだけ採用する。

• 実行結果の正しさが改善、または少なくとも悪化しない
• 根拠の提示漏れが増えない
• 権限・Privacy・Boundary違反がない
• 高リスク領域では人の承認を受ける
• コストと応答時間が許容範囲に収まる
• 差分、評価、承認、リリース理由がTraceとして残る

ここで初めて、自己進化は「よりよく答える」だけではなく、より説明でき、より安全に運用できる知識基盤の成長になる。

Temporal Semantic Twin

さらに重要なのは、意味を時間から切り離さないことである。

組織の状態、契約条件、制度、指標定義、権限は変化する。今日の「顧客区分」と、半年前の「顧客区分」が同じとは限らない。したがって、意味の解決には「何を意味するか」だけでなく、「いつの時点で有効だったか」が必要である。

ChinobaのSemantic Digital Twinは、人を監視する仕組みではない。組織・業務・知識・判断の状態を、時間的な文脈とともに扱うためのモデルである。

これにより、後から次の問いに答えられる。

2026年3月時点で、なぜこのAgentはこの定義を採用し、この提案を行い、人への確認を求めたのか。

AIの行動を再現・検証するには、モデルの出力ログだけでは足りない。当時の意味、方針、権限、データ状態、判断理由を残す必要がある。

最初に実装すべき三つの領域

最初から企業全体のオントロジーを作る必要はない。むしろ、意味と判断の往復が明確な小さな領域から始めるべきである。

第一は、Chinobaの研究資産である。chinoba.org、ブログ、書籍、GitHubのアーキテクチャ、概念、実装例を、Knowledge Flow、Decision Trace、Trust、Runtime OS、Multi-Agent Coordination、Runtime Societyの関係として接続する。これは、研究の知識地図であると同時に、公開された意味基盤の実証にもなる。

第二は、見積・単価協定である。要件、取引先、年度ルール、単価、許容範囲、承認者、交渉結果を意味的に接続する。ここでは、AIが判断候補を出すだけでなく、どのルールと証跡に基づくかを提示し、Act / Ask / Stopを選べることが重要になる。

第三は、Community Intelligence Platformである。Program、Channel、Campaign、Member、Reward、反応、通知を接続し、運営の状態理解を支援する。ただし、個人の監視や自動的な評価へ向かわないよう、目的、同意、データ境界、運用責任をオントロジーとRuntime OSの双方で明示する。

意味の進化は、組織の判断能力を育てる

AI時代の知識基盤は、文書を検索できるだけでは十分ではない。データを参照できるだけでも、Agentが賢くなっただけでも足りない。

必要なのは、AI、人、組織が同じ意味を参照し、その意味に根拠と責任を持たせ、判断と実行を境界の中で行い、結果から定義を改善していく循環である。

Semantic Decision Runtimeは、そのための完成品の名前ではなく、Chinobaが探究する方向を表す構想である。

Knowledge becomes actionable when meaning is traceable.
Intelligence becomes trustworthy when action remains accountable.

意味を検索できるAIから、意味を根拠に判断し、説明し、必要なら人に委ね、結果から学び直せるAIへ。

この転換が、Knowledge FlowをTrust Infrastructureへ、そしてRuntime Societyへ接続する次の基盤になる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance