はじめに
前回、なぜ今「オントロジー」が AI データ基盤において重要なのか、その概念について書きました。
「概念はわかった。で、どう実装して、どんなアウトプットになるの？」と思ったので、今回は Python を使って、Palantir Foundry のような 「 Supply Chain Control Tower 」 のミニマム版を実際に作ってみました。
「データを見る → AI が文脈を理解する → 意思決定してアクションする」という一連の流れを、手元のコードで体験できます！
作るもの：Supply Chain Control Tower
今回作成したデモアプリの完成形はこんな感じです。
主な機能：
- Ontology Explorer : 製品・工場・サプライヤーなどの「オブジェクト」を管理。
- Semantic Graph : オブジェクト間のつながり（関係性）を可視化。異常箇所は赤く警告。
- Chaos Engineering : 意図的に「サプライヤー停止」などのトラブルを発生させる。
- AI & Action : AI がトラブルを検知し、代替案を提案。人間がボタン一つで発注（Write-back）を実行。
ソースコードは全て GitHub にアップロードしています！
実装のポイント：オントロジーをコードに落とし込む
このデモアプリは、複雑なオントロジー基盤のメンタルモデルを、以下の3つの要素で Python 上に再現しています。
1. Schema is Semantic（定義こそが意味）
従来の DB テーブル定義（SQL）は「データの持ち方」を定義しますが、オントロジーでは Pydantic を使って「ビジネス上の意味（型）」を定義します。
# ビジネスの実体（モノ）を定義
class Product(BaseModel):
id: str
name: str
stock: int
# リンク（関係性）の定義
factory_id: str
material_required_id: str
class Factory(BaseModel):
id: str
name: str
# 状態定義（ビジネスロジックの源泉）
status: str = "Normal" # Normal, Maintenance, Critical
このように定義を行うことで、後述する AI が「 Factory の status が Critical ということは、製造が止まっているんだな」というビジネスロジックをプログラムの構造から理解できるようになります。
2. Graph is Context（つながりが文脈）
RAG（検索拡張生成）などで AI にデータを渡す際、単一のテーブルだけでは不十分です。
従来の RDB では複雑な SQL を書かなければなりませんが、オントロジーではオブジェクト間のリンクを辿るだけで、AI が判断に必要な「現場の文脈」を抽出できます。
def get_full_context(product_id: str):
"""
製品IDを起点に、サプライチェーンの上流（Supplier）から下流（Order）まで
全ての関係性を横断して文脈を取得する
"""
product = db["products"][product_id]
# リンクを辿って「関係性」を自動で紐解く
factory = db["factories"][product.factory_id]
material = db["materials"][product.material_required_id]
supplier = db["suppliers"][material.supplier_id]
# AIに渡すためのリッチな情報セットを返す
return {
"product": product,
"factory": factory, # 工場の稼働状況も含まれる
"supplier": supplier, # サプライヤーの健全性も含まれる
"metrics": { ... }
}
ここで生成した dict（リッチな情報セット）をそのまま LLM へのプロンプト（System Prompt や User Context）として渡します。
# AIへの入力イメージ
製品Aの在庫が不足しています。
関連する工場Bのステータス：🔴停止中
サプライヤーCのステータス：🔴供給断絶
この状況を踏まえ、最適な代替案を提案してください。
これにより、AI はデータベースの ID だけでは分からない『現場の状況』を把握できるようになります。AI は「在庫が減っている」という事実だけでなく、「在庫が減っているが、工場の操業停止により生産できず、サプライチェーンも寸断されている」 という複合的な文脈を理解できます。
3. Human-in-the-loop Actions（人とAIの協働）
そして一番の肝が Action（行動） です。
分析して終わりではなく、その場でシステムに 書き込み（Write-back：分析結果をソースシステムやDBへ反映させること） を行います。
今回のデモでは、「AI が検索・提案 → 人間が選択 → システムが実行」 というワークフローを実装しました。
# 1. AIが状況を見てアクションを提案（ボタン表示）
if ctx['supplier'].status == "Disrupted":
st.button("代替サプライヤーを検索")
# 2. 人間が候補リストから選択して実行
if st.button("発注"):
execute_procurement(candidate) # DB更新処理
st.success("発注完了レポートを表示")
補足：AI の実装について
- 今回配布するデモコードでは、API キーなしで誰でも動かせるようにするため、AI の判断部分をルールベース（if文）でシミュレーションしています。
- 実務で実装する場合は、この simulate_ai_analysis 関数の部分を OpenAI API などの呼び出しに置き換えてください。
- オントロジーで作った ctx（文脈データ）をプロンプトとして LLM に渡すことで、複雑な状況でも「あ、これはVIP対応が必要ですね」とAI が自律的に判断できるようになります。
実際に動かしてみよう（デモシナリオ）
GitHub からコードを落としたら、ぜひ以下のシナリオを試してみてください。Palantir のようなシステムがなぜ現場で強いのか、体感できるはずです。
シナリオ：半導体サプライヤーの突然の供給停止
- サイドバーの Ontology Explorer を開きます。
- Supplier Object で「株式会社グローバル・チップ」を選択します。
-
Status Change で
Normalから🔴 停止 (Disrupted)に変更します。- → これが現実世界で起きたトラブルのシミュレーションです。
すると、画面上で何が起きるか？
- 可視化: Semantic Graphの「Supplier」ノードが真っ赤になります。影響範囲が一目瞭然です。
- AI検知: AI Assistantが即座に「🚨 サプライヤートラブル」を警告します。
- 提案: 「🔍 代替サプライヤーを検索」というアクションボタンが出現します。
- 実行: ボタンを押すと、候補企業（テック・マテリアルズなど）が提示されます。納期やコストを見て、実際に 「発注」 ボタンを押してください。
- 解決: 緑色の「発注完了レポート」が表示され、グラフ上のデータが更新されます。
おわりに
このデモアプリを通じて 「データと業務をどうモデル化するか」という設計思想 は大事になるなと感じました。
- データを「テーブル」ではなく「オブジェクト」として捉える。
- 「見る画面」と「やる画面」を分断させず、統合する。
- AIには「データ」ではなく「文脈（グラフ）」を渡す。
これらを意識してデータ基盤を構築できるエンジニアこそが、これからの AI 時代、そして DX の現場で真に価値を発揮できると思ったので、業務理解についてはドメインエキスパート並みに深めたいところ...！
ぜひ、GitHub のコードを clone して、自分なりの「オントロジー」に改造してみてください！