「知識の地図」が変えるAI時代のデータ設計──devio2026札幌・オントロジー登壇の全貌

SQLはエラーなく動いた。テーブルの結合条件も正しく書けていた。それなのに、関東の売上が実態より30%も多く集計されており、九州・中部のデータまで紛れ込んでいた──。この「技術的には正しいが、業務的には間違い」という矛盾が、2026年10月9日に札幌で開催されたDevelopersIO 2026 Sapporoで最も印象的な問題提起として投げかけられた。クラスメソッド株式会社クラウド事業統括本部の石川氏が登壇したチョークトーク「知識の地図を描く ─ オントロジーとは何か？」は、AIエージェント活用が本格化する2026年において、エンジニアが避けて通れない「知識表現」の本質に正面から向き合ったセッションだ。

本稿では、公式登壇資料（dev.classmethod.jp、2026年10月10日公開）およびHakky Handbookによる一次情報解説をもとに、セッションの要点を完全再構成する。オントロジーとは何か、なぜ今これほど注目されているのか、ナレッジグラフやデータカタログとどう違うのか──実務エンジニアが知っておくべき全論点を徹底的に掘り下げる。

📌 【この記事の重要ポイントまとめ】

• 要点1：DevelopersIO 2026 Sapporo（2026年10月9日開催）で石川氏が登壇し、「知識の地図」としてのオントロジーの本質と実務活用を具体的なOSS検証結果とともに公開した。
• 要点2：SQLが正確でも売上集計が30%ずれるという実例を通じ、「意味」が機械可読な形で埋め込まれていないことによる業務リスクを明示──オントロジーはこの問題を根本解決する。
• 要点3：AWS Context Ontology Accelerator（COA）やLLM Wikiなど2026年最新OSSの実動検証結果も共有され、エンジニアが今日から始められるオントロジー設計の入口が示された。

---

【devio2026 札幌・登壇の全容】「知識の地図」とは何か──セッション背景と問題意識

DevelopersIO 2026 Sapporoは、クラスメソッドが主催するエンジニア向け技術カンファレンスの札幌版として2026年10月9日に開催された。毎年多数の技術セッションが並ぶ中、今回のチョークトーク枠で石川氏が選んだテーマは「オントロジー」という、聞き慣れない言葉だった。

チョークトークとは、スライドより対話と板書を重視するディスカッション形式のセッションだ。石川氏はその形式を活かし、まず冒頭で参加者に一つの問いを投げかけた。「SQLが正しく動いているのに、なぜ数字がずれるのか？」──公式ブログ（dev.classmethod.jp）によると、登壇の核心は「AIエージェントに業務上正しい判断をさせるには、データと業務用語のあいだにある意味を、機械が読める形で渡す必要がある」という一文に凝縮されている。

Hakky Handbookが公開した一次情報解説によると、問題のシナリオはこうだ。社内ポリシー文書（sales-policy.txt）には「売上とは、ステータスが『shipped』の注文のtotal_amountの合計」と定義されていた。しかしこの定義はテーブルのスキーマにも、SQLクエリにも埋め込まれていなかった。その結果、本来含まれるべきでない九州・中部のデータが関東の集計に混入し、関東売上が実態比30%増の誤値として出力された。エンジニアもBIツールも「正しく動いた」のに、ビジネス判断に使える数字ではなかった。

この問題を「データの品質問題」として処理するのは簡単だ。だが石川氏の視点は違う。「業務定義という知識が、機械が読める形で存在していなかった」という構造的欠陥として捉え直すことで、オントロジー設計の必要性を鮮やかに浮かび上がらせた。#devio2026のSNS上でも「この事例が一番刺さった」「自社でもまったく同じことが起きている」という声が相次いだ。

---

【オントロジーとは何か・わかりやすく解説】「意味の地図」が解決する根本的な問題

オントロジー（ontology）という言葉は、もともと哲学の用語で「存在論」を意味する。エンジニアリングの文脈では、「概念とその関係を機械が読める形で定義した構造化された知識体系」のことを指す。JAPAN AIの解説（japan-ai.co.jp）では「意味の地図」と端的に表現されており、石川氏のセッションタイトル「知識の地図を描く」との呼応は意図的なものだ。

もう少し具体的に言うと、オントロジーとは次の3つの要素から成り立つ。

①クラス（Class）──概念の種類を定義する。たとえば「注文」「顧客」「地域」。
②プロパティ（Property）──クラス間の関係や属性を定義する。たとえば「注文は顧客に属する」「地域は都道府県を含む」。
③インスタンス（Instance）──実際のデータをクラスに当てはめる。「ORDER-0042は、ステータス=shippedの注文インスタンス」。

この構造をOWL（Web Ontology Language）やRDF（Resource Description Framework）という標準フォーマットで記述することで、Webシステム・AIエージェント・データカタログなどあらゆる機械がその「意味」を共通して解釈できるようになる。セマンティックWebの思想的土台であり、W3Cが標準化してから20年以上が経過するが、LLM（大規模言語モデル）の普及によって2024〜2026年にかけて実務適用の機運が急速に高まっている。

石川氏のセッションが明快だったのは、「オントロジー＝難しい理論の話」という先入観を最初に崩したことだ。先述のSQL事例で示したように、「業務定義を機械可読な形で持つ仕組み」という実践的な定義から入ることで、受講者の理解を一気に引き寄せた。

---

【知識グラフ・データカタログとの違い】混同されがちな3概念を徹底比較

オントロジーを語るとき、必ずセットで登場するのが「ナレッジグラフ（知識グラフ）」と「データカタログ」だ。この3つは互いに関連しながらも、明確に役割が異なる。石川氏のセッションはこの違いを具体例で整理することに多くの時間を割いたとされており、devio2026参加者のフィードバックでも「三者の違いがようやくクリアになった」という声が多数寄せられた。

石川氏の整理が特に有益だったのは、「ナレッジグラフはオントロジーの上に構築される」という階層関係を明示した点だ。オントロジーが「『注文』とは何か、どういう状態のものが売上に計上されるか」を定義し、その定義に沿ってナレッジグラフが「具体的なORDER-0042という注文エンティティが、shipped状態で東京リージョンのある顧客に紐づく」という実データの関係を表現する。データカタログはその全体を「どこにどのデータ資産があるか」という視点で管理する──この3層構造を掴むだけで、情報アーキテクチャの設計思考が大きく変わる。

---

【AWS COA・LLM Wiki実動検証】2026年最新OSSでオントロジーを構築する方法

セッションの最大の付加価値は、理論解説にとどまらず、実際に動作させた結果を公開したことにある。石川氏が検証したのは2つのOSSだ。

① AWS Context Ontology Accelerator（COA）──AWSが公開しているオントロジー構築支援ツール。2026年10月9日時点での最新バージョンはv0.3.5だが、石川氏の検証はv0.2.0およびv0.2.2時点のものであり、公式ブログでも明示されている。COAはAWSのサービス群（S3、Glue、Redshiftなど）のコンテキストをオントロジー形式で記述・管理するためのフレームワークで、AWSリソースの意味的な関係を定義しLLMに渡すことで、AIエージェントの業務理解精度を高めることを目的としている。

② LLM Wiki──LLMが参照する知識ベースをWiki形式で構造化するためのツール。自然言語で書かれた業務ドキュメントをオントロジーと連携させ、LLMが「sales-policy.txtの定義」を正確に参照できる状態を作り出すことを目指す。

検証の核心は、前述の「SQL正常・集計誤り」シナリオをCOAで解決できるか、という実験だ。sales-policy.txtの「売上＝shipped状態の注文のtotal_amount合計」という定義をオントロジーに落とし込み、それをLLMエージェントに渡すことで、クエリ生成時に自動的に正しい条件が付与されるかを検証した。石川氏のブログには詳細な検証手順と結果が2本の記事に分けて公開されており、ナレッジグラフ構築の実践手順として2026年時点で最も具体的な日本語一次情報の一つとなっている。

COAのリリースペースが速く（v0.2.0からv0.3.5まで数ヶ月で更新）、検証結果がバージョン依存になる点は注意が必要だ。石川氏がバージョンを明記したのは、再現性と透明性を担保するための誠実な判断であり、オントロジーエンジニアリングの実務における「検証記録の書き方」の模範でもある。

---

【AI活用とオントロジー】なぜ2026年にこれほど注目されるのか──構造的な理由

「なぜ今オントロジーなのか」という問いへの答えは、LLMの普及に求めることができる。2023〜2024年にかけてChatGPTをはじめとするLLMが爆発的に普及し、多くの企業がAIエージェントを業務に組み込もうとした。しかし現場で頻発したのが「技術的には動くが、業務的に間違った答えを返す」という問題──まさに石川氏が提示したSQL事例と同じ構造の失敗だ。

LLMは確率的に「それらしい」回答を生成するが、「御社の業務定義」を知らない。社内規定、業界固有の用語定義、組織間で異なる概念の使い方──これらは自然言語ドキュメントに散らばっており、LLMがアドホックに参照するだけでは整合性が保てない。オントロジーは、この「業務の意味」を機械可読な構造に変換し、AIエージェントに渡す「翻訳装置」として機能する。

JAPAN AIの解説（japan-ai.co.jp）は、この点をさらに広げて「セマンティックレイヤー」という概念とオントロジーの関係を整理している。セマンティックレイヤーはBIツール領域で発達した概念だが、オントロジーとの組み合わせによって、AIエージェントがSQL生成・レポート作成・意思決定支援を行う際の「業務的な正確性」を担保する基盤として進化しつつある。2026年のエンジニアにとって、オントロジーは「知っておくと便利な理論」から「AIを業務投入するための必須インフラ」へと位置が変わったのだ。

ナレッジマネジメントの観点からも注目度は高い。JAPAN AIのメディアでは「社内に散在する暗黙知をオントロジーで形式知化することで、AIが業務知識を継承できる」という評価が増えており、オントロジーはエンジニアリングだけでなく組織設計の議論にも入り始めたのが2026年の特徴だ。

---

【実態検証・誤解の是正】「オントロジーは難しすぎる」というエンジニアの声と真実

devio2026のセッション後、X（旧Twitter）やZennのコメント欄では賛否両論が交わされた。「これを実務で設計できるエンジニアが社内にいない」「OWLを書けるのはセマンティックWeb専門家だけでは？」という懸念の声も少なくなかった。この感覚は正直なものだが、いくつかの誤解を含んでいる。

誤解①「OWLを全部手書きしなければならない」──COAのようなOSSは、AWSサービスに関するオントロジーをテンプレートとして提供する。ゼロから書く必要はなく、既存テンプレートを拡張することから始められる。石川氏の検証もまさにこのアプローチだ。

誤解②「オントロジーの恩恵を受けるには全データを整備しなければならない」──実際には、特定の業務ドメイン（たとえば「売上定義」だけ）に絞ったミニマルなオントロジーから始めることが推奨されている。情報アーキテクチャの設計でも「全体最適の前にドメイン分割」は定石だ。

誤解③「ナレッジグラフを持てる企業だけの技術」──RDF/OWLベースのオントロジーはクラウドサービスと組み合わせることでスモールスタートが可能になっており、Amazon Neptuneなどのマネージドサービスの普及がハードルを下げている。2026年時点では、中規模のSaaS企業でもオントロジー設計をデータ基盤の一部として採用する事例が出始めている。

一方、石川氏が正直に認めたのは「COAはまだv0.3台で、プロダクション投入には設計判断が必要」という現実だ。ツールの成熟度と業務適用の間にはまだギャップがある。「試してみてそのまま使える」段階ではなく、「どの業務課題に適用するか」を慎重に絞ることが実務活用の鍵となる。

【プロの結論】オントロジー設計に向いているチームとそうでないチームの判断基準

向いているチーム・状況：
① AIエージェントに業務固有の判断をさせたいが「ハルシネーション」や「定義違い」で失敗している
② 複数システム・組織間でデータ定義が統一されておらず、集計ミスやレポートの食い違いが頻発している
③ データカタログやBIツールは整備しているが、LLMとの統合で意味的整合性が保てていない
④ 「業務知識の属人化」が組織リスクになっており、形式知化の手段を探している

慎重になるべき状況：
① データ基盤自体（データウェアハウスやデータレイク）がまだ整っていない段階
② オントロジーを設計・維持するドメインエキスパートとエンジニアの両方が社内にいない
③ 「とりあえずAIが動けばよい」という短期的PoCのフェーズ（設計コストが見合わない）
④ ツールのバージョン変化（COAのような高頻度更新OSS）を追いかけるリソースがない

---

【「知識の地図を描く ─ オントロジーとは何か？」DevelopersIO 2026 Sapporo登壇】に関するよくある質問（FAQ）

Q1：devio2026の登壇資料はどこで入手できますか？
A1：クラスメソッド公式ブログ（dev.classmethod.jp）に登壇資料が埋め込み公開されています。スライド本体に加え、AWS COAとLLM Wikiの検証結果を詳述した2本の関連記事へのリンクも掲載されています（2026年10月10日公開）。

Q2：オントロジーとナレッジグラフは何が違うのですか？
A2：オントロジーは「概念と関係の定義（スキーマ）」であり、ナレッジグラフはその定義に従って実際のデータエンティティと関係を格納したもの（インスタンス層）です。地図で例えると、オントロジーが「地図の凡例・縮尺・分類ルール」で、ナレッジグラフが「実際に描かれた地図」にあたります。

Q3：AWS Context Ontology Accelerator（COA）はどのバージョンが安定していますか？
A3：石川氏のセッション時点（2026年10月9日）での最新はv0.3.5ですが、本人の検証はv0.2.0/v0.2.2ベースです。リリース頻度が高く仕様変更も多いため、業務適用前に対象バージョンを固定して評価することを推奨します。公式リポジトリのCHANGELOGを必ず確認してください。

Q4：OWLやRDFを知らないエンジニアがオントロジーを始めるにはどうすればよいですか？
A4：まずProtégéなどのGUIツールでOWLの基礎を体験するのが入門として有効です。その上でCOAのようなAWSサービス向けテンプレートを使い「既存定義の読み解き→部分的な拡張」から実践するアプローチが現実的です。石川氏の検証記事はこのプロセスの良い教材になります。

Q5：オントロジー設計はナレッジマネジメントにどう貢献しますか？
A5：社内の業務定義・ポリシー・用語集をオントロジーとして形式知化することで、「担当者が変わっても業務知識が引き継がれる」状態を作れます。LLMエージェントがその定義を参照することで、属人的な判断をAIが再現できるようになります。2026年においてオントロジーは、ナレッジマネジメントの「機械可読版」として注目されています。

Q6：DevelopersIO 2026 Sapporoの他のセッションはどこで確認できますか？
A6：クラスメソッド公式ブログ（dev.classmethod.jp）でハッシュタグ #devio2026 を検索するか、公式イベントページのセッション一覧をご確認ください。各登壇者がブログ形式で資料・解説を公開するのがDevelopersIOの文化となっています。

---

まとめ：「知識の地図」を描く技術は、AIを業務に根付かせるための基盤だ

DevelopersIO 2026 Sapporoで石川氏が投げかけた問い──「SQLが正しいのに数字がずれる、その原因は何か」──は、多くのエンジニアが日常的に遭遇しながら「データ品質の問題」として流してきた現象だ。しかしオントロジーの視点からは、これは「意味が機械可読な形で存在しない」という構造的問題であり、AIエージェント時代においてはより深刻な業務リスクとなる。

OWL・RDFという技術標準はセマンティックWeb黎明期から存在していたが、LLMと業務AIエージェントの普及が、これらの技術に2026年という現在形を与えた。AWS COAのようなOSSが急速に成熟し、クラウドサービスとの統合が容易になったことで、オントロジー設計は「一部の専門家の領域」から「データエンジニアの標準スキル」へと移行しつつある。

石川氏のセッションが示したのは、理論的な美しさではなく、実際のOSSを動かして検証し、失敗も含めて公開するというエンジニアリングの誠実さだ。COAがv0.2.0とv0.3.5で大きく変わるような高速な技術進化の中で、特定バージョンを明記して記録を残すという姿勢は、オントロジーを実務に根付かせるための「地図の描き方」そのものでもある。

2026年のエンジニアにとって、オントロジーは選択肢ではなく前提になりつつある。知識の地図を描く技術を持つチームだけが、AIエージェントを本当に「業務上正しく」動かせる時代が到来している。今日のうちに、その第一歩を踏み出してほしい。 （出典: 知識の地図を描く オントロジーとは何かというタイトルで developersio 2026 sapporo に登壇しました devio2026 developersio（Yahoo!ニュース））