執筆者：CSO 石川 雅也
第2回：AIエージェントにスキーマを渡すだけでは、足りない
── 人間が経験で補ってきたものの正体 ──
この連載について
データを使うには、そのデータが何を意味しているのかが分かっている必要があります。当たり前のことですが、多くの現場でこの一点だけが空白のまま残されています。
メタデータを整えるためにデータカタログを入れ、それでも足りずにオントロジーやセマンティックレイヤーへ向かう。そしてAIエージェントの登場によって、この空白がついに「精度」への影響という具体的な数字になって表に出てきました。
この連載では全4回かけて、この「データに意味を与える」という長年の宿題を追いかけます。カタログはなぜ荒れるのか。AIには何が補えないのか。オントロジーは3度目の挑戦で何が違うのか。そして、技術で解いたあとに何が残るのか。
技術の優劣を比べる連載ではありません。意味を決めるのは誰の仕事なのか、という話です。
- データカタログは、なぜ3年で荒れ地になるか
- AIエージェントにスキーマを渡すだけでは、足りない
- 3度目の来襲は、何を捨てて動いているか
- オントロジーを入れても、「売上」の定義は統一されない？
ここまでのあらすじ
第1回では、データカタログが3年で荒れ地になる過程を追いました。起点は「更新されない」ことで、そこから「見つからない」「信用されない」へと連鎖します。商用製品を入れてもExcelの台帳でも、同じ場所で止まりました。足りなかったのは情報ではなく、意味でした。そしてその意味は、これまで人が無償で埋めてきたのです。
第2回へのコメント
「AIに聞けば済む」とよく言われます。実際、AIはSQLを書けます。この回で扱うのは、書けたのに間違えた一件です。
生成されたSQLを最初に見たとき、よくできていると思いました。
テーブルの結合も、期間の絞り込みも、集計の単位も、自分で書くのとほとんど変わりません。実行すると、数字が返ってきました。
その数字が違っていました。
構文の誤りではありません。何を「売上」と呼ぶか、の誤りでした。構文エラーなら画面が赤くなって止まりますが、意味の誤りは正常終了します。AIは、黙って間違えるのです。
1. AIは「売上」を、キャンセル込みで集計した
sales というテーブルに、gross_amount と net_amount という2つのカラムがありました。前者はキャンセルや返品を含んだ総額、後者はそれを除いた純額です。メタデータには、どちらにも説明が付いていませんでした。
「先月の売上を出して」と頼むと、AIは gross_amount を選びました。
ところが、この会社で「売上」と言えば Net でした*¹。営業も経理も経営会議も、Net の数字で話していました。
返ってきたのは、キャンセル分まで積み上がった数字です。実績より大きい。とはいえ、ひと目で異常と分かるほどの差ではありませんでした。だから、気づくまでに時間がかかりました。
1-1．命名が悪かったのではありません
カラム名が悪かったのだろう、と思われるかもしれません。
ですが gross_amount と net_amount は、英語としては十分に自己説明的です。AIのほうも「売上といえば総額だろう」と、辞書の意味はきちんと取ったうえで選んでいます。
欠けていたのは、「この会社で売上と言えば Net だ」という合意の記述でした。スキーマにもコメントにもカタログにも、それは書かれていません。あったのは、人の頭の中だけです。
命名が悪い現場なら、AIはもっと外すでしょう*²。けれども、それは程度の差でしかありません。カラム名を全部きれいな英語に直しても、この誤答は消えません。
1-2．新人も、同じ間違いをします
同じことは人間もやります。配属されたばかりの人に同じ依頼をすれば、やはり Gross を選ぶかもしれません。
違いが出るのは、その次です。新人は手を止めて、隣の席に聞きます。「売上って、キャンセル込みですか」と。
AIは聞きません。候補が2つ並んでいて、選ぶ根拠がなくても、どちらかを選びます。理由を尋ねれば、もっともらしい説明まで付いてきます。
第1回で書いた、人が無償で埋めていた空白が、ここにもあります。人間はそれを「聞く」ことで埋めてきました。AIには、その手段がありません。
2. AIが間違える、3つの層
この一件を分解すると、欠けていたものは3つの層に分かれます。そのうち2つは、第1回で書いた荒れ地化の3段階と同じ形をしています。
2-1．語彙 ── 現場の呼び方が、スキーマ側に無い
「売上」という言葉は、スキーマのどこにもありません。あるのは gross_amount と net_amount だけです。
第1回の第2段階「だから、見つからない」と同じ構造です。現場の言葉で検索して何も出てこないことと、AIが「売上」を解決できないことは、同じ欠落の裏と表になっています。
意味で検索できる仕組み、つまりベクトル検索や意味検索と呼ばれるものを入れれば埋まるのでは、という声もあるでしょう。
途中までは、その通りです。「売上」という問いから net_amount を候補として引いてくるところまでは、実際に働きます。
問題は、その先です。候補が2つ返ってきたとき、どちらが正しいかは、類似度のどこにも書かれていません。 gross_amount と net_amount は、意味の近さで測ればほぼ同じ距離に並びます。
近いことは、正しいことの根拠にはならないのです。
そのうえ日本の業務システムの命名は、この種の検索がいちばん苦手とする形をしています*³。
2-2． 粒度と境界 ── どこまでを含むのか
キャンセルを含むのか。いつの時点で立てるのか。返品はどの月に付けるのか。
gross と net の違いは、まさにこの層の話でした。
2-3．選択 ── 2つ並んでいて、選ぶ根拠が無い
第1回で、「顧客」という名前のテーブルが3つある例を挙げ、カタログは「どれを使うべきかは教えてくれません」と書きました。カラムが2つ並んでいても、事情は変わりません。第1回の第3段階「だから、信用されない」と同じ形です。
2-4．この3つは、どう表に出るか
同じ欠落でも、人間が相手なら検索の失敗として、AIが相手なら誤った答えとして現れます。
人間が探せなかったときは、何も起きません。第1回で書いたように、その困りごとは起票されないからです。
AIが選び間違えたときは、数字が出ます。間違った数字が、正しい書式で。
私が見た1件だけの話でもなさそうです。企業の実データウェアハウスから作られた BEAVER というベンチマークでは、エージェントを組んでも正答率は1割台にとどまり、各作業に正解のヒントを与えると3倍近くまで上がります*⁴。足りないのはモデルの能力というより、渡されていない文脈だと読めます。
Gartner も2026年5月に、セマンティクスの欠如がAIエージェントの精度低下と無駄な支出を招く、というプレスリリースを出しました。
従来のスキーマベースのデータモデルだけでは、agentic AI にはもはや十分ではない。ビジネスの文脈とデータの意味が欠けているからだ*⁵。
参照されているレポートの題名は、直訳すると「セマンティックおよび構造的なデータモデリングなしに、agentic AI の取り組みは失敗する」。本文は読めていませんが、題名がそのまま主張になっています。
3. 「では何を渡せばよいのか」の現在地
3-1．書かれていれば、渡せる
いちばん直接的な答えは、指標の定義を書いて渡すことです。「売上とは net_amount である」と1行あれば、この誤答は起きません。
そのための機能は、主要な基盤にすでに用意されています。Snowflake の Semantic Views、Databricks の Unity Catalog business semantics、dbt の Semantic Layer。呼び方はそれぞれですが、業務の語彙と物理的なカラムのあいだに一枚の層を挟む、という発想は同じです。
Oracle は、少し違う場所に書きます。表や列そのものに「アノテーション」と呼ぶ名前と値の組を付けておき、自然言語からSQLを作る Select AI が、それをコメントや制約と一緒に読み込みます*⁶。層を挟むのではなく、テーブル定義の側に書き込むわけです。書くための画面も用意されましたが、書くのは人です。
サンプルデータや値の分布を読ませる方法もあります。分布を見れば、gross_amount が net_amount より大きいことは分かります。けれども、どちらを「売上」と呼ぶかまでは分かりません。分布は大小を教えてくれても、呼び名は教えてくれないのです。
どの方法も効きます。ただ、効くのは、どこかに書かれていることに対してだけです。
3-2．では、その1行をAIに書かせればよいのか
説明文をAIが自動生成してくれるなら、書く手間の問題そのものが消えるのではないか。そう考えるのは自然です。
機能としては、すでにあります。Databricks の Unity Catalog にはAIがコメントを生成する機能があり*⁷、Snowflake には SQL から呼べるプロシージャがあります*⁸。
自動収集そのものは、本物の進歩です。テーブルとカラムの一覧、リネージュ、更新日時。技術メタデータの鮮度の問題は、クローラが普及したことで実際に片付きました。
とはいえ、限界もはっきりしています。生成に使われる入力は、テーブルスキーマとカラム名です。Databricks の公式ドキュメントにも、そう書かれています。Snowflake はオプションでサンプルデータも読みますが、基本は同じです*⁹。
では、KBN_CD というカラム名から、AIは何を書けるでしょうか。
「区分コード」までです。それは翻訳であって、意味ではありません。
何の区分なのか。値の 1 と 2 が、業務の上でそれぞれ何を指すのか。スキーマのどこにも書かれていない以上、生成のしようがありません。実装が未熟だからではなく、入力の限界です。
もう一つあります。ベンダー自身が、人間のレビューを必須にしていることです。
Databricks は「コメントは保存前にレビューされなければならない」と書いたうえで、個人情報を含む列の検出のような分類作業には頼るべきでないと、用途の線引きまで明記しています。自分で限界を書いているわけで、誠実な姿勢だと思います。
自動化されたのは下書きで、承認ではない、ということです。
第1回の第1段階の問題は、誰も手入れをしないことでした。レビューの責任が人に残るかぎり、この問題も残ります。むしろ、自動生成された分だけ、レビューする量は増えていきます。
3-3．運ぶ標準は、意味を運ばない
渡し方の標準化も進んでいます。MCP のようなツール接続の仕様です。
MCP の Resources の仕様は冒頭で、サーバはファイルやデータベーススキーマなどのコンテキストを共有できる、と書いています。DBスキーマを運ぶことは、はじめから想定されているわけです。
運ぶ仕組みとしては、よくできていると思います。ただ、運べるのは仕様が用意した枠に収まるものだけです。
Tool の定義に並んでいるのは、名前、説明、入出力の型定義（JSON Schema）、注記といったフィールドです。指標の定義、単位、粒度、集計ルール、有効期間を入れるための、規定されたフィールドはありません。あるのは自由記述の説明欄だけです*10。
仕様が「意味は扱わない」と宣言しているわけではありません。表現する場所が、まだ用意されていない。いまは、そういう段階です。
4. 渡せないもの
ここまでは「書けば解ける」話でした。書く場所も、運ぶ仕組みも、揃いつつあります。
では、書けないものはあるのか。
第1章の例は、合意はあったのに書かれていなかったケースです。誰かが1行書けば、それで解けます。
ところが、その1行がどうしても書けない場面があります。
営業は受注の時点で売上と呼び、経理は検収と計上の時点で売上と呼ぶ。どちらも業務上は正当です。ここで「全社の売上」を1つに決めようとすると、話は技術の外に出ていきます。
セマンティックレイヤーもオントロジーも、両方の定義を並べて持つことはできます。しかし、どちらを「売上」と呼ぶかは決めてくれません。
書かれていないから渡せない。第1章はそこまででした。その奥に、決まっていないから書けない、という層があります。ここは最終回で扱います。
おわりに
人間は、曖昧さを許容できました。「売上」がどちらを指すのか曖昧でも、迷ったら聞けば済みました。だから空白は長く先送りできたのです。
AIは許容しません。 曖昧なまま、選びます。
これは悪いことばかりではない、と私は考えています。これまで誰にも請求されてこなかったコストが、はじめて数字になって表に出てくるからです。
「カタログが更新されていないせいで2日失った」と書く欄は、どこにもありませんでした。それがいま、間違った売上の数字という形で現れ始めています。
危機がなければガバナンスは動かない、という話を第1回でしました。
危機が、来たのかもしれません。
だとすれば、次に問うべきことは決まっています。意味を書き留めて、機械が読める形にする技術はあるのか。次回は、その話です。
脚注・参考
*¹gross と net のどちらを「売上」と呼ぶかは、会社ごと、業種ごとに違います。返品率の高い業態なら Net が自然で、市場の大きさを見たい場面なら Gross に意味が出ます。どちらかが正しいという話ではありません。
*²日本の業務システムに残る命名の癖。カラム名が8文字前後なのは、識別子の長さに制限があった時代の名残で、そこにローマ字略記（KBN＝区分）と和製英語が混じりました。当時は紙のテーブル定義書が横にあったので、それで足りていたのです。
*³意味の近さで探す検索は、型番・略語・コードのような正確一致が要る語に弱く、キーワード検索と併用するハイブリッド検索が実務の標準になりました。Weaviate（オランダ発のOSSベクトルデータベース。急成長中）公式の Hybrid search は、これを “combines the results of a vector search and a keyword (BM25F) search by fusing the two result sets” と定義し、alpha で両者の重みを変えると説明しています。併用が標準になったこと自体が、意味の近さだけでは足りないという業界側の答えでしょう。
*⁴Text-to-SQL のベンチマークについて。自然言語の質問からSQLを生成させ、実行結果で採点する共通の試験問題です。BIRD（NeurIPS 2023）は、2026年10月時点の最高が 83.40% で、人間のベースラインが 92.96%。この BIRD は、スキーマの外の業務知識を使わせる問題を、設計として含めています。スキーマだけでは足りないことを、ベンチマーク自身が認めているわけです。本文の BEAVER は MIT ほかによるベンチマーク（2026年5月の改訂版）。ただし数字は慎重に扱うべきで、2026年1月にはBIRD と Spider 2.0 の正解ラベルに5〜6割の誤りがあるという監査も出ました。順位や絶対値の根拠には使えません。
*⁵Gartner のプレスリリース（2026年5月11日）。参照レポートは Agentic AI Efforts Will Fail Without Semantic and Structural Data Modeling で、本文はクライアント限定のため読めておらず、題名だけを引いています。引用の原文は “Traditional schema-based data models alone no longer suffice for agentic AI because they lack business context and data meaning.”。
*⁶Oracle のスキーマ・アノテーションは 23ai から（19c は RU 19.28 から）。Select AI での使い方は Oracle 公式ブログ（2026年7月1日）。
*⁷Databricks, AI-generated comments ── 原文は “comments must be reviewed prior to saving”。
*⁸Snowflake, AI_GENERATE_TABLE_DESC ── 入力はオブジェクトの構造と、オプションでサンプルデータです。
*⁹仕様書や設計書を読ませれば、もっと書けるのではないか。私もそう考えて探しましたが、説明文を作るために仕様書を取り込める機能は、主要な製品には見当たりませんでした。確認したのは、Snowflake（AI_GENERATE_TABLE_DESC、Semantic View Autopilot）、Databricks（AI-generated comments、Genie）、Google Knowledge Catalog（説明文の生成元はクエリ履歴）、Collibra（説明文の推奨。Unstructured AI は非構造データそのものの分類）、Atlan（リネージュ、SQLの使われ方、既存の定義から生成）、dbt（プロジェクトのコードから生成）などです。文書を読む仕組み自体はあります（仕様書や設計書を読み込む Krugle など）。ただしそれは質問に答えるときに文書を参照するもので、読んだ中身をカラムの説明として残すものではありません。
*10MCP が標準化している範囲。仕様バージョンは 2026-07-28。Tool のフィールドは name / description / inputSchema / outputSchema など。ここに書いたのは、該当する枠が無いという確認です。
