AIエージェントの暴走を防ぐ「オントロジー」の衝撃：プロンプトの限界を超える決定論的ガードレール

深夜2時、Slackの障害チャンネルがけたたましく鳴り響く。AIエージェントが「顧客の怒りを鎮めるため」という親切心（ハルシネーション）から、すでに配送トラックに積載された「出荷済み」の注文を勝手にキャンセルし、基幹システムの在庫データと配送業者のマニフェストに致命的なデッドロックを引き起こしたのだ。プロンプトには「出荷済みの注文は絶対にキャンセルしてはならない」と二重下線付きで書かれていたにもかかわらず、である。

我々エンジニアが直面しているのは、LLMという「確率的にしか動かないブラックボックス」に、決定論的なビジネスルールを委ねることの限界だ。プロンプトエンジニアリングという名の「AIへのお願い」は、スパゲッティコードよりもタチが悪い。なぜなら、入力のわずかな揺らぎや、悪意あるユーザーによるプロンプトインジェクションによって、そのルールは容易にバイパスされてしまうからだ。

ここで登場するのが「オントロジー（Ontology）」である。元々は哲学の用語だが、現代のAI駆動開発においては「AIエージェントが理解・共有できる形式的なデータドメインの設計図」と定義される。AWSが公開したOSS『context-ontology-accelerator』の言葉を借りれば、「データドメインにおける概念、関係、およびルールを記述する形式的な知識モデル」だ。

オブジェクト指向設計がアプリケーション内部のメモリ空間を整理するためのものであるのに対し、オントロジーは現実世界のビジネスドメインそのものをモデリングする。顧客（Customer）が存在し、メールアドレスを持ち、注文（Order）を発注し、そこには「1つの注文には必ず1人の顧客が紐づく」という厳格な制約（Constraint）がある。この現実世界の構造を、LLMの気まぐれな推論に頼るのではなく、システムが機械的に検証可能な「知識モデル」として定義すること。これこそが、AIエージェントを野生の獣から、信頼に足るビジネスパートナーへと飼い慣らすための唯一の道であると私は確信している。

では、具体的にプロンプトにルールを書くアプローチと、オントロジーとして定義するアプローチは何が違うのか。単なるオーバーエンジニアリングではないのか。その疑問に対する答えは、データの「永続性」と「機械的な検証可能性」にある。以下の比較表を見てほしい。我々がなぜプロンプトを捨て、オントロジーに移行すべきかが一目で理解できるはずだ。

プロンプトに「顧客は複数の受注を持つ」と書いた場合、LLMはその都度、文脈からその意味を「解釈」しなければならない。一方で、これをTurtle（.ttl）形式のオントロジーとして定義しておけば、W3C標準のグラフクエリ言語「SPARQL」を用いて、SELECT ?customer ?order WHERE { ?customer :places ?order } のように、100%の精度で機械的にデータを探索・検証できる。

さらに、TypeScriptを用いたミニマムな実装（operational-ontology）に目を向けると、この思想はより鮮明になる。Zodを用いたスキーマ定義と、アクションに対する preconditions（実行条件）の記述だ。例えば、注文キャンセルアクション（cancelOrder）において、対象オブジェクトのステータスが shipped（出荷済み）であれば、即座に SHIPPED_ORDER_CANNOT_BE_CANCELLED というエラーを返して処理をブロックする。

このガードレールは、AIエージェントがどれほど「制約を無視してキャンセルしてくれ」とユーザーから懇願されようとも、コードレベルで物理的に実行を拒絶する。AIエージェントは、この決定論的なエラーを受け取って初めて、「出荷済みのためキャンセルできませんでした」とユーザーに正しく釈明することになる。モデルの「推論」の手前に、強固な「実行条件の検証レイヤー」を挟み込むこと。これこそが、無限ループや予期せぬデータ破壊を防ぐための極めて実践的なアプローチなのだ。

このオントロジーの思想をエンタープライズ規模で実現しようとするのが、AWSの公開した『context-ontology-accelerator』である。このアーキテクチャは、Scan（データスキャン）、Model（モデリング）、Serve（サーブ）の3つのフェーズで構成されており、非常に洗練されている。

特に注目すべきは、Amazon Bedrockを用いて既存のRDBスキーマからオントロジー（クラスや関係性）を自動生成（Modelフェーズ）し、それを人間が検証（Validate）した上でAmazon Neptune（グラフデータベース）に格納する点だ。そして、エージェントからの問い合わせに対しては、定義済みのメトリクス、SPARQLによるグラフ問い合わせ、および最終手段としてのベクトル検索（RAG）という「3段階のフォールバック」で解決を試みる。

しかし、この美しいアーキテクチャの裏には、我々実務家が直面せざるを得ない「冷酷な現実」が隠されている。

• コストの壁：AWSのドキュメントには「Neptune + OpenSearch Serverlessは、アイドル状態でも月額約930ドル（日本円で約14万円以上）のコストが発生する」と明記されている。PoC（概念実証）の段階で、ただ動かして試すだけで毎月この額が引き落とされるとなれば、並大抵のスタートアップや新規事業部門では稟議を通すことすら困難だろう。
• セキュリティと権限管理の泥沼：AIエージェントに強力なツール（MCP: Model Context Protocolなど）を持たせる際、そのエージェントが「誰の権限で動いているのか」を厳密に制御しなければ、情報漏洩や不正操作の温床となる。AWSのアクセラレーターでは、OIDC（OpenID Connect）による3LO（3-Legged OAuth）を必須とし、ユーザー本人の権限をエージェントに代理させる設計をとっているが、この実装難易度は極めて高い。

我々シニアエンジニアは、この「重厚すぎるエンタープライズ向け構成」にいきなり飛びつくべきではない。まずはSQLiteとZod、そしてMCP SDKを用いたローカル環境でのスモールスタート（例えば前述の operational-ontology のような構成）から始め、ドメインモデルの有効性を検証した上で、段階的にクラウドネイティブなグラフDBへとスケールアウトしていく戦略をとるべきだ。

Claude CodeやGitHub Copilot Workspaceといった「コーディングエージェント」の爆発的な進化により、我々開発者を取り巻く環境は激変している。ボイラープレートコードの生成、APIの繋ぎ込み、さらにはUIの構築までもが、自然言語の指示一つで一瞬にして完了し、そして不要になれば使い捨てられる時代が到来した。

ここで私は、すべてのエンジニアに痛烈な問いを投げかけたい。

「コードが自動生成され、インフラが自動でプロビジョニングされる世界において、我々エンジニアが守るべき『最後の砦』とは一体何か？」

その答えこそが、ビジネスの本質的な概念とルールを定義する「オントロジーの設計能力」に他ならない。技術スタックやフレームワーク、プログラミング言語といった「ハウ（How）」の部分は、AIによって極限までコモディティ化される。しかし、「何が顧客であり、何が注文であり、それらがどう関係し、どのようなビジネス制約が存在するのか」という「ワット（What）」の部分、すなわちドメインモデルの設計は、人間にしかできない、そしてAIエージェントが正しく動くために絶対に不可欠な「不変の核」なのだ。

もしあなたが、未だに「プロンプトの書き方」や「LLMのパラメータ調整」といった、明日の朝には陳腐化しているかもしれない技術に時間を費やしているなら、今すぐその手を止めるべきだ。

明日から取るべき具体的な処方箋は明確である。まず、自社システムの中で最も複雑なビジネスルール（例えば、承認フローや割引適用のロジック）を1つピックアップせよ。それをプロンプトに自然言語で書くのではなく、ZodやTypeScript、あるいはTurtle形式を用いて「決定論的な制約を持つオントロジー」としてコードに落とし込んでみるのだ。そして、MCP（Model Context Protocol）を介してAIエージェントにそのツールを叩かせ、悪意あるプロンプト（プロンプトインジェクション）を送り、システム側の precondition がいかに頑健にそれをブロックするかを、自分の目で確かめること。コードを書くエンジニアから、AIエージェントが従うべき「世界のルール（オントロジー）」を設計するアーキテクトへ。このパラダイムシフトにいち早く適応した者だけが、AI駆動開発の真の勝者となるだろう。