firebirdテックトーク

パソコ

パソコだよ！今日も一緒に学んでいこう！

「データウェアハウスに AGENTS.md ファイルがあったらどうでしょう？」

dbt Labs が2026年8月に公開したニュースレターに、この一文がある。書いたのは同社の Alex Noonan 氏だ。読んだ瞬間に、ここ数年ずっと引っかかっていたものの正体がはっきりした。

AIエージェントにデータを触らせると、SQL は書ける。テーブルも見つけられる。それでも答えが合わない。理由は毎回同じで、「売上」に返品が含まれるのかどうかをエージェントが知らないからだ。その定義は Wiki にあるかもしれないし、3年前の Slack スレッドにあるかもしれないし、誰かの頭の中にしかないかもしれない。どれもクエリインターフェースからは見えない。

2026年8月から9月にかけて、この「文脈をどう渡すか」という問題に対して、まったく違うレイヤーから3つの答えが出てきた。ついでに、そもそも良いデータモデルとは何かという問いを扱った勉強会もあった。まとめて確認したので整理しておく。

そもそもエージェントが失敗するのはモデルのせいではない

エージェントの性能は、渡すコンテキストの質で決まる。これは最近あちこちで言われていることだが、実務で見ていると本当にそのとおりだ。

text-to-SQL のアプリケーションが実用に届かない理由は、たいていモデルの推論能力ではない。次のような情報が、クエリできる場所に一切存在しないからだ。

• 指標の定義（MRR に解約分は含むのか、税抜きか税込みか）
• そのテーブルが今も使われているのか、半年前に置き換わったのか
• 誰がそのロジックのオーナーなのか
• 上流のどのモデルから派生していて、どのテストが通っているのか

人間のアナリストはこれを、隣の席の人に聞いて解決している。エージェントには隣の席がない。だから推測する。そして間違える。

1. dbt Agents Schema：文脈をウェアハウスの中に置く

dbt Labs が出した答えは、身も蓋もないほどシンプルだ。メタデータを、データと同じウェアハウスの中に、ただの SQL テーブルとして置く。

GitHub の一次情報で仕様を確認した内容が以下になる。

エージェントは「今月の MRR はいくらか」を処理するとき、いきなり業務テーブルを触りに行かない。先に AGENTS を読んで、実際の定義・その裏にあるモデル・ロジックのオーナーを特定する。そのうえで本体のクエリを組み立てる。

手書きしなくていいのが本質

この手の「メタデータを一箇所に集めよう」という取り組みが過去に何度も失敗してきたのは、集めた先が腐るからだ。初回は気合で埋まる。半年後には現実と乖離している。

Agents Schema はここを GitHub Actions に寄せた。呼び出し側のワークフローはこれだけだ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

name: Agents Schema dbt

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  agents-schema-dbt:
    uses: dbt-labs/agents_schema/.github/workflows/agents-schema-dbt.yml@v0.0.10
    with:
      dbt-project-dir: dbt_project
    secrets:
      WAREHOUSE_CREDENTIALS: ${{ secrets.WAREHOUSE_CREDENTIALS }}

main に push されるたびに同期が走る。プロジェクトが変われば AGENTS も変わる。メタデータの更新を人間の善意ではなく CI に紐づけたという一点が、この設計でいちばん効いている部分だ。

新しいインフラを1つも増やさない

もう一つの利点は、増えるものがテーブルだけという点だ。

• 既存のセキュリティポリシー・ガバナンスポリシーがそのまま効く（スキーマに対する権限管理の話に落ちる）
• SQL が話せるエージェントなら何でも読める
• 特定のベンダーに縛られない
• 専用のカタログ製品もベクトルDBも立てない

「コンテキスト管理」という名前で新しいミドルウェアを1つ増やす解法が多いなかで、すでにあるデータストアに半構造化テキストを放り込むというのは、抵抗がいちばん少ない道だ。車輪を作り直したがる空気のなかで、タイヤ交換で済ませている。

冷静に見ておくべき限界

もちろん万能ではない。触ってみるかどうかを判断するなら、次の3点は先に見ておいたほうがいい。

1. バージョンが v0.0.11 である。仕様が固まったとは言いがたく、破壊的変更は普通に起こりうる段階だ。だからこそタグ固定が推奨されている
2. 読む側が対応していないと価値が出ない。AGENTS を先に読むという行動をエージェント側に仕込まない限り、ただのテーブルが増えただけになる
3. dbt や BI ツールでカバーされない領域は Markdown の手書きになる。結局そこは人間が書くので、腐りやすさの問題が完全に消えるわけではない

MCP 側も同じ方向に動いている

同じニュースレターには、dbt MCP サーバーの更新も載っていた。型ごとに分かれていた検出用ツール群が、get_node_details という統一されたリソース検出エンドポイントに置き換わっている（2026年7月22日）。6月の get_related_models や get_dimension_values と同じパターンだ。

単体では小さな変更だが、方向ははっきりしている。機能を増やすのではなく、エージェントにとって扱いやすいツール面に寄せていくという流れだ。あわせて、アナリストの読み取り権限セットにカタログ閲覧のためのプロジェクト・アカウント読み取りアクセスが追加された。過剰な権限を与えずに読み取り専用でカタログを引かせたい、という需要にそのまま対応している。

2. Snowflake Gateway：エージェントが使うモデルを本番トラフィックで比べる

文脈を渡す先のモデルを、どう選ぶのか。Snowflake は2026年8月に Gateway Monitoring と A/B Testing を一般提供にした。

仕組みはロードバランサに近い。複数のモデルバージョンに対して、割合でトラフィックを分配するエンドポイントを作る。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

CREATE GATEWAY my_gateway FROM SPECIFICATION $$
spec:
  type: traffic_split
  split_type: custom
  targets:
  - type: endpoint
    value: SERVICE_V1!inference
    weight: 70
  - type: endpoint
    value: SERVICE_V2!inference
    weight: 30
$$;

これで既存モデル（baseline）と新モデル（challenger）を、実際のユーザーリクエストで比較できる。推論ログは Auto Capture で自動収集され、ドリフト・性能指標・統計指標が定期的に集計される。Snowsight のダッシュボードでは信頼区間まで表示される。

オフラインの評価データセットでの比較と違って、本番の入力分布そのもので比べられるのが価値だ。評価用データでは勝っていたモデルが本番で負ける、という話はいくらでもある。

踏みやすい落とし穴が1つある

検証記事で最大の詰まりどころとして挙げられていたのが、正解データとの突合だ。

リクエストの extra_columns のキー名と、モニター定義の ID_COLUMNS の値が、大文字小文字まで完全に一致していないと突合に失敗する。キー名は SQL 識別子ではなく単なる文字列として扱われるためで、大文字で統一しておくのが安全ということになる。

静かに失敗して「なぜか性能指標が出ない」という形で出てくるので、知らないと相当な時間を溶かすはずだ。

制約も押さえておきたい。

後者がとくに重い。デプロイ時に決め打ちしておく必要があるので、「あとで A/B したくなったら考える」が通用しない。

3. NVIDIA PAIR：文脈を処理する計算資源を分散する

3つ目はレイヤーがかなり違う。NVIDIA が2026年9月3日にベータ公開した PAIR（Personal AI Router） は、余っている PC のリソースを AI 推論に回すための仕組みだ。オープンソースで公開されている。

家に複数台マシンがある人にとっては、手元のGPUを遊ばせずに済むという話になる。特別なプロトコルを発明せず mDNS と相互TLS で組んでいるあたりも扱いやすそうだ。

ただし記事では制約もはっきり書かれていた。

• 各システムのリソース不足そのものは解決しない（非力なマシンを束ねても大きくはならない）
• 大規模モデルの実行には未対応
• 複数システムにまたがるサブエージェントの分割はできない
• 常時稼働させる分だけ電力消費が増える

「分散すればなんとかなる」という話ではなく、遊休リソースの回収として理解するのが正しい。

4. そもそも「良いデータモデル」はどこから生まれるのか

ここまでは仕組みの話だが、根っこにある問いを扱ったイベントもあった。2026年7月22日にオンライン開催された **Data Engineering Study #36「“良いデータモデル"は、どこから生まれるのか」**だ。Forkwell と primeNumber の共催で、参加申込は417人。YouTube にアーカイブが残っている。

並べてみると示唆的だ。実装は自動化されていくが、何をモデルとして切り出すかという判断は自動化されない。1本目の「ビジネスプロセスから始める」という視点は、まさに Agents Schema が AGENTS.DBT_MODEL に書き込もうとしている中身そのものである。定義が曖昧なものを機械可読にしても、曖昧なまま速く間違えるだけだ。

4つの動きを1枚に並べる

レイヤーで整理すると、それぞれが別の層を埋めていることがわかる。

ここから読み取れること

3つの実装を並べてみて、共通しているのは「エージェントを賢くしよう」という発想がどこにもないことだ。

やっているのは全部、エージェントの周りを整える作業である。定義の置き場所を決める。モデルの良し悪しを本番トラフィックで測る。計算資源を融通する。モデル自体の推論能力は、もはやボトルネックとして扱われていない。

そしてもう一つ。ある分析では、AIとデータ関連の成果物を世に出すうえでの真のボトルネックは技術ではなく、チームで何を作るべきかの合意形成にあると指摘されている。Agents Schema に書き込む「売上の定義」を決められないチームは、テーブルを用意しても埋められない。これは技術の問題ではない。

つまり、順番はこうなる。

1. チームで定義を決める（いちばん難しい）
2. 決めた定義を機械可読な場所に置く（Agents Schema）
3. エージェントがそこを見に行くようにする（MCP）
4. どのモデルに処理させるか測る（Gateway）

1を飛ばして2から始めると、やはり腐る。今回いちばん納得したのはそこだった。

まとめ

• 2026年8月、dbt Labs が Agents Schema を MIT ライセンスで OSS 公開した。AGENTS スキーマにメタデータを SQL テーブルとして置く標準で、Snowflake / Databricks / BigQuery に対応する
• 同期は GitHub Actions の再利用ワークフローで行い、push のたびに走る。メタデータの鮮度を CI に紐づけたのが設計の核心
• 新しいインフラを増やさないため、既存のセキュリティ・ガバナンスがそのまま効く。一方で v0.0.11 と若く、読む側の対応がなければ価値は出ない
• Snowflake は Gateway でトラフィック分割による A/B テストを一般提供にした。落とし穴は Ground Truth 突合のキー名の大文字小文字、そして Auto Capture を後から有効化できない点
• NVIDIA PAIR は遊休 PC リソースへの推論分散。各機の非力さそのものは解決しない
• 共通しているのは、モデルではなくその周辺を整えるという方向性。そして最終的なボトルネックは技術ではなく、定義に対するチームの合意形成である

まずは手元のプロジェクトで AGENTS スキーマを1つ作って、自分のエージェントに「テーブルを触る前にここを読め」と言ってみるところから試してみてほしい。

関連書籍

PR: 本セクションにはアフィリエイトリンクが含まれています。

データモデリングの設計思想そのものを腰を据えて学びたい場合は、ディメンショナルモデリングやドメイン駆動設計の定番書に一度あたっておくと、こうした新しい仕組みが「何を機械可読にしようとしているのか」が一段わかりやすくなる。