Claude に「オントロジー」を持たせたらコスト半分・3倍速 — LLMに渡す知識の構造化が2026年のホットトピックになった理由
はじめに
2026年6月末、技術系のはてなブックマークやZennのトレンドを見ていると、ある共通の問いが急に存在感を増していることに気づきます。それは「LLMに渡す知識を、どう構造化して、どう運用するか」というテーマです。
口火を切ったのは「Claudeに『オントロジー』を持たせたら、コスト半分・3倍速になるかも」という記事で、はてなブックマークが242件と同日トップの拡散を見せました。そして同じ日に「知識グラフとオントロジーの再定義」「RAGを作るのではなく検索される知識を運用する」という記事が並んで伸びています。これは偶然ではなく、いまLLM活用の現場が同じ壁にぶつかっている証拠です。この記事では、その実測データと背景の技術論を掘り下げ、エンジニアが明日から何を考えればいいのかを整理します。
「ファイルを並べるだけ」の限界と、オントロジーという答え
きっかけの記事が指摘するのは、極めて素朴な問題です。プロジェクトの知識を Markdown ファイルやフォルダで並べても、ファイル同士の「関係」は表現されない、ということです。
「このモジュールはあのサービスを呼び出す」「この設定はあの制約に依存する」——こうした関係が明示されていないと、LLM は読み込んだ複数のファイルから関係を推測で補完するしかありません。著者の言葉を借りれば、「その推測のブレが幻覚（ハルシネーション）と精度低下を招く」。
そこで登場するのがオントロジーです。哲学用語のように聞こえますが、エンジニアリングの文脈では「概念と、その間の関係を型付きで定義した構造」と捉えればよく、構成要素は5つに整理できます。
- クラス（概念の型、例: サービス、モジュール）
- インスタンス（具体例、例: AuthService）
- プロパティ（属性）
- 関係（「呼び出す」「依存する」といった型付きのつながり）
- 制約（成り立つべき条件）
タグやフォルダとの決定的な違いは「関係」です。フォルダは入れ子の階層しか表せませんが、オントロジーは「A が B を呼び出す」という方向と意味を持った線を引けます。モデルは推測でつなぐのではなく、すでに引かれた確定的な線を辿るだけで済むようになります。
実測値: コスト $1.26→$0.62、応答 2分7秒→44秒
この記事が説得力を持ったのは、抽象論で終わらず自分のリポジトリで実測値を出した点にあります。著者は MCP（Model Context Protocol）の公式メモリサーバを使い、知識をグラフとして永続化しました。具体的には create_entities（ノード作成）・create_relations（関係定義）・add_observations（メタデータ付与）を JSON で記録し、memory.jsonl に保存する、という構成です。
そして「このプロジェクトのアーキテクチャを説明して」という同じ問いを、グラフあり・なしで比較します。
| 指標 | グラフなし | グラフあり |
|---|---|---|
| コスト | $1.26 | $0.62（約半分） |
| 応答時間 | 2分7秒 | 44秒（約3倍速） |
| キャッシュ読取トークン | 764.7k | 118.1k |
差が生まれる理屈はシンプルです。グラフなしでは、関係を把握するために関連ファイルを軒並み読み込み、足りない関係を推測で補い、結果として大量のトークンを消費します。グラフありでは search_nodes や read_graph でグラフを直接参照し、必要なファイルだけを最小限読む。読み取りトークンが 764.7k から 118.1k へ激減したのは、この「読むべき範囲が確定している」効果です。
ここで強調したいのは、これが単なる節約術ではないことです。トークンを減らすこと自体が目的ではなく、モデルに推測させる余地を消すことで、コストと速度と精度が同時に改善するという構造になっている点が本質です。
背景: オントロジーは「推論」から「契約」へ再定義されている
なぜこのテーマが「いま」盛り上がっているのか。背景には、オントロジーという概念そのものの役割の転換があります。同日に伸びた「知識グラフとオントロジーの再定義」は、これを「推論から契約へ」と表現しました。
かつてのセマンティックWeb時代、オントロジーの夢は OWL 推論エンジンが未知の事実を自動導出することでした。「全世界の意味を記述すれば機械が賢く推論してくれる」という理想です。しかし現代のデータエンジニアリングの現場では、その役割が現実的な方向へ作り替えられています。
オントロジー＝データ品質を担保するスキーマと検証の契約
この再定義が生まれた背景には、2つの実務的な痛みがあります。1つはスキーマレスなグラフ（LPG）で起きる型ドリフト——データの型が知らぬ間にずれ、探索の信頼性が崩れること。もう1つは、データが正しくても LLM の要約段階でハルシネーションが起きること。
この記事の著者は、これらを推論エンジン一発で解こうとせず、L0〜L4 の段階的な検証層と、ツール出力と自然言語回答の一致を動的にチェックする「Grounding 層」を設計しました。特徴的なのは、OWL 推論をあえて採用せず、クローズドワールド仮説（契約外のデータは fail-fast で弾く）を採ったこと。オントロジーは「賢く推論する装置」ではなく「品質保証と回答検証の契約」へと機能を集約したわけです。
最初の実測記事が「関係を明示すれば推測が消える」と語ったのと、この記事が「契約で逸脱を弾く」と語るのは、実は同じコインの裏表です。どちらも LLM に推測の余地を与えないことで信頼性を担保しようとしています。
エンジニアへの影響: 「RAGを作る」から「知識を運用する」へ
3本目の「RAGを作るのではなく、検索される知識を運用する」は、この潮流を実務のワークフローに落とし込みます。著者の主張は明快です。RAG の本当の課題は初期構築ではなく、検索対象データの継続的な管理と精度維持にある。
自前で RAG を組むと、チャンク分割・embedding・検索・回答生成の各層が絡み合い、精度が落ちたときに「どの層が原因か分からない」状態に陥ります。そこで著者は、検索基盤そのものはマネージドな Agent Search に委譲し、自分は「何を検索対象に入れるか・どう更新するか・どう監視するか」に集中する設計へ切り替えました。
実装は「XML sitemap 取得 → URL フィルタ → テキスト抽出 → SHA256 で差分検知 → Cloud Storage 保存 → Agent Search 同期 → Slack 通知」というパイプライン。検索アルゴリズムの細かい制御は手放しますが、代わりに観測性と再現性を得る——精度改善が「手作業チューニング」から「データ供給と評価の自動化」へ移るトレードオフです。
3本を貫く実務的な示唆はこうまとめられます。
- 知識は資産ではなく運用対象: 一度作って終わりではなく、関係の整合性や鮮度を保ち続けるものとして扱う。
- 構造化の投資対効果は測れる: オントロジー化の効果はコスト・速度・トークンで定量化できる。「なんとなく良さそう」で止めず、手元のリポジトリで before/after を測ってみる価値がある。
- MCP メモリサーバは試しやすい入口: いきなり大掛かりな知識グラフ基盤を組まなくても、既存の MCP メモリサーバでノードと関係を記録するだけで効果を体感できる。
まとめ
2026年6月末に同時多発したこれらの記事は、LLM 活用が「とりあえずファイルを全部渡す」フェーズを卒業しつつあることを示しています。要点は3つです。
- 知識を**型付きの関係（オントロジー）**で与えると、推測の余地が消え、コスト・速度・精度が同時に改善する（実測でコスト半分・約3倍速）。
- オントロジーの役割は「自動推論」から「品質と回答を保証する契約」へ再定義されつつある。
- RAG は「作るもの」から「検索される知識を運用するもの」へと重心が移っている。
共通するのは、LLM に推測させない仕組み作りこそが信頼性とコスト効率の鍵だという認識です。手元のプロジェクトで、まずは MCP メモリサーバに主要な概念と関係を数十ノード記録し、同じ質問の before/after を測ってみる——この小さな実験が、次のLLM活用の質を大きく変えるかもしれません。
今日のその他のニュース
- Firebase が Imagen モデルを全廃止、Gemini CLI は Antigravity へ移行: 6/24 で Firebase の Imagen が廃止され Gemini Image へ移行推奨、Firebase 拡張の Gemini CLI も 6/18 で停止。画像生成や Gemini CLI を使っている場合は移行対応が必要です。
- 「あなたの .env は Docker イメージに焼き込まれ、誰でも抜き出せる」:
COPY .envやビルド引数経由で秘密情報がイメージレイヤに残りdocker historyで抽出可能、という事故と対策（multi-stage / BuildKit secret mount /.dockerignore）。実務で踏みやすい定番事故です。 - 自己改善型OSSコーディングモデル Ornith-1.0 が話題: Claude Opus 4.7 同等性能を謳う自己改善型 OSS モデルが HN・GIGAZINE 両方で注目。ローカル開発向けの Qwen 3.6 27B も支持を集め、OSS/ローカルのコーディングモデルの選択肢が一段厚くなりました。