🗂️ 技術調査 - Agents Schema

調査対象: Agents Schema (Fivetran / Open Data Infrastructure) — GitHub fivetran/agents_schema
ライセンス: MIT / 調査時点の最新リリース: v0.0.6（2026-04 リポジトリ公開、Development Status: Alpha）/ 対応 destination: Snowflake のみ
調査日: 2026-06-04

概要

Agents Schema は、AI エージェントがウェアハウスデータを正確にクエリするために必要なコンテキストを、ウェアハウス内の標準スキーマ AGENTS として提供する OSS 標準です。Fivetran, Inc. が開発・維持し、Open Data Infrastructure (ODI) イニシアティブのもとで公開されています。

位置づけは「コードリポジトリにおける AGENTS.md のデータ版」です。コードリポジトリに AGENTS.md を置いてエージェントにプロジェクト理解を与えるように、データウェアハウスに AGENTS スキーマを置いてエージェントにデータ理解を与えます。

主な対象は、dbt や Snowflake を運用しつつ、AI エージェントに社内データを触らせ始めたチームです。メトリクス定義やフィルタ条件をエージェントが推測してしまう問題に、ウェアハウス内のメタデータで答えを与えます。

解決する課題

エージェントはテーブルスキーマだけでは不十分なコンテキスト、すなわち「テーブルの用途・管理者・変換元・クエリコスト・他テーブルとの関係」を必要とします。この情報は従来、wiki・Slack スレッド・ダッシュボード・暗黙知として分散していました。エージェントはそれらを収集する手段を持たないため、metric 定義・フィルタ・スキーマを推測して誤クエリを生みます。

Agents Schema はこれらのコンテキストをウェアハウス内に集約し、エージェントがクエリインターフェースから離れずに参照できる単一の標準場所を提供します。

用途

次の用途に特化した consumer-facing な discovery layer です。

• どのキュレーションテーブル・セマンティックオブジェクトが存在するか
• どのシステムがメタデータを提供しているか
• dbt モデル・LookML オブジェクト・OSI セマンティックモデルがどのデータセットを裏づけているか
• ソースが陳腐化していないか、データプロダクトのオーナーは誰か

Agents Schema は専門システム・ソースネイティブ API・開発時ツールの代替ではありません。dbt MCP server のように dbt リポジトリを編集するエージェントは引き続きソースファイル・アーティファクトを直接使います。Agents Schema はウェアハウスを起点として既存データのコンテキストを得る consumer 用途に限定されます。

特徴

• オープン形式・オープンソース・オープンコネクタ: 仕様 (SPEC.md)・CLI・GitHub Actions ワークフローを MIT ライセンスで公開します。
• メタデータのみ、データ移動なし: ビジネスデータはウェアハウスに留まり、メタデータ（モデル定義・カラム説明・依存関係・セマンティック定義）だけを AGENTS スキーマに書き込みます。
• SQL で直接クエリ可能: SELECT 文でアクセスできるため、Cursor・Claude Code・ノートブック・内製エージェントなど、ウェアハウスに接続できるあらゆるツールが追加設定なしで読めます。
• 自己文書化する AGENTS.ROOT: provider registry として機能し、どの provider が何のテーブルを提供しているかを consumer が最初に参照できます。
• ソース別テーブルファミリー: dbt・LookML・OSI を独立したテーブル群として提供し、各 source の ingestion が自分のファミリーだけを管理します。
• CREATE OR REPLACE による冪等な再生成: 各インジェスト実行はテーブルファミリーを丸ごと置き換えるため、再実行で状態が一意に確定します。consumer はこれらを手編集不可の生成メタデータとして扱います。
• クロスソースクエリ: LOOKML_VIEW と DBT_MODEL を結合するなど、複数 provider のテーブルを JOIN して横断的な文脈を得られます。
• GitHub Actions ネイティブ: 既存リポジトリに reusable workflow を数行追加するだけで CI/CD パイプラインとして動作し、プロジェクト変更のたびに AGENTS を自動更新できます。

隣接技術との比較

公式 README は次のように位置づけます。

"It is closest in spirit to information_schema, but extensible across many providers. Compared with MCP servers, Agents Schema is narrower: it publishes context inside the warehouse, while MCP servers can expose tools, actions, and source-specific workflows."

ユースケース別の参照テーブル

エージェント向けの差別化要素は ai_context 列です。LookML / OSI 由来のオブジェクトは description（人間向け説明）に加えて ai_context（エージェント向けの明示的な指示）を保持できます。たとえば「このメトリクスは必ず currency_code でフィルタする」「historical データのため当年ではなく最新年で集計する」といった制約を ai_context に書くと、エージェントは推測せずその指示に従えます。既存のセマンティックレイヤーが無い段階で OSI ファミリーから着手し、既に dbt / LookML を運用していればその provider をそのまま取り込む、という使い分けが自然です。

構造

C4 model の 3 段階で内部アーキテクチャを図解します。次は公式が示す全体フローです。

出典: fivetran/agents_schema リポジトリ README（assets/agents-schema-overview.png）

システムコンテキスト図

要素説明

コンテナ図

UserRepo サブグラフ

AgentsSchemaSystem サブグラフ

Warehouse サブグラフ

コンポーネント図

CLI サブグラフ

destinations.py 内部

データ

概念モデル

AGENTS スキーマ全体の所有関係と参照関係を示します。

概念モデル説明

情報モデル

ROOT と 12 の source テーブル、計 13 テーブルの主要属性を示します。

OSI_METRIC は他エンティティと関係線を持ちません。これは OSI 仕様上 semantic_model.metrics が semantic_model.datasets と並列のトップレベル要素であり、metric が特定 dataset への外部キーを持たない設計を反映したものです。

AGENTS.ROOT（PK: provider + key）

AGENTS.DBT_MODEL（PK: unique_id）

AGENTS.DBT_COLUMN（PK: model_id + column_name）

AGENTS.DBT_DEPENDENCY（PK: upstream_id + downstream_id）

AGENTS.LOOKML_VIEW（PK: name）

AGENTS.LOOKML_DIMENSION（PK: view_name + field_name）

AGENTS.LOOKML_MEASURE（PK: view_name + measure_name）

AGENTS.LOOKML_EXPLORE（PK: name）

AGENTS.OSI_DATASET（PK: name）

AGENTS.OSI_FIELD（PK: dataset_name + field_name）

AGENTS.OSI_METRIC（PK: name）

AGENTS.OSI_RELATIONSHIP（PK: name）

型システムと識別子の重要事実

Python パッケージ内部はテーブル名・カラム名を lowercase で定義します。Snowflake へはクォートなしの unquoted identifier として送出するため、Snowflake は格納時に自動的に UPPERCASE へ変換します。実際のウェアハウスオブジェクトは AGENTS.DBT_MODEL・AGENTS.LOOKML_VIEW・AGENTS.OSI_DATASET のような大文字名として存在します。

NOT NULL 制約は、各テーブルの PK 構成カラムすべてと、DBT_MODEL.name・OSI_DATASET.source_table・OSI_RELATIONSHIP.from_columns/to_columns に付きます。PK カラムは定義上 NOT NULL です。ただし「欠損時は空文字列を挿入する」カラムは、制約上 NOT NULL でも意味的には空になりうる点に注意します。

OSI_FIELD.expression と OSI_METRIC.expression には、OSI YAML の expression.dialects[] のうち先頭エントリの式だけを格納します。複数 dialect が定義されていても残りは取り込まれません。consumer は格納された式が必ずしも Snowflake 方言である保証がない点に注意し、AI_CONTEXT の指示を優先します。

構築方法

前提条件

対応 destination は Snowflake のみです（"more coming soon"）。各メタデータソースに必要なファイルは次のとおりです。

CLI を直接使う場合は Python 3.11 以上が必要です（依存: cryptography / pyyaml / snowflake-connector-python）。

必須パラメータ一覧

CLI サブコマンドの必須引数

WAREHOUSE_CREDENTIALS secret の必須キー

Secret 設定

GitHub リポジトリの Actions secret に WAREHOUSE_CREDENTIALS を 1 つ作成します。形式は YAML または JSON を受け付けます。

type: snowflake
account: abc123
user: AGENTS_SCHEMA_BOT
warehouse: COMPUTE_WH
database: ANALYTICS
role: TRANSFORMER
private_key_pem: |
  -----BEGIN ENCRYPTED PRIVATE KEY-----
  MIIEvQIBADANBgkqh...
  -----END ENCRYPTED PRIVATE KEY-----
private_key_passphrase: your-passphrase

• role は省略可能です。
• 非暗号化キーは -----BEGIN PRIVATE KEY----- / -----END PRIVATE KEY----- マーカーを使い、private_key_passphrase を省略します。暗号化キーは -----BEGIN ENCRYPTED PRIVATE KEY----- マーカーで判別できます。
• account は Snowflake の新方式 orgname-accountname か、旧方式の account locator（locator.region.cloud）のいずれかを使います。接続できない場合はこの形式の取り違えを疑います。

Workflow 配線 — dbt

dbt プロジェクトのリポジトリに次の workflow ファイルを配置します。

name: Agents Schema dbt

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  agents-schema-dbt:
    uses: fivetran/agents_schema/.github/workflows/agents-schema-dbt.yml@v0.0.6
    with:
      dbt-project-dir: dbt_project
    secrets: inherit

workflow は <dbt-project-dir>/target/manifest.json を読み込み、AGENTS.DBT_MODEL / AGENTS.DBT_COLUMN / AGENTS.DBT_DEPENDENCY に書き込みます。

manifest.json が存在しない場合、Composite Action は次の 3 択で対応します。いずれも満たさないとエラーになります。

1. target/manifest.json を事前に commit しておく。
2. managed dbt parse: dbt-profile-name（input）と DBT_PROFILES_YML（secret）の両方を渡す。Action がこの 2 つを揃って検知したときだけ dbt parse を実行する。
3. カスタムコマンド: dbt-parse-command（input）で manifest 生成コマンドを直接指定する。

オプション入力と secret は次のとおりです。

managed dbt parse の内部では、補助コマンド agents-schema-dbt-adapter-package が profiles.yml の選択ターゲットから adapter type を読み取り、対応する dbt アダプターパッケージ名を出力します。現行マッピングは snowflake → dbt-snowflake のみです。Composite Action は uvx でこのアダプターを取り込んでから dbt parse --no-partial-parse を実行し、target/manifest.json を生成します。profiles.yml が複数ターゲットを持つ場合は dbt-target の指定が必要です。

Workflow 配線 — Looker

name: Agents Schema Looker

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  agents-schema-looker:
    uses: fivetran/agents_schema/.github/workflows/agents-schema-looker.yml@v0.0.6
    with:
      lookml-dir: lookml
    secrets: inherit

Workflow 配線 — OSI

name: Agents Schema OSI

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  agents-schema-osi:
    uses: fivetran/agents_schema/.github/workflows/agents-schema-osi.yml@v0.0.6
    with:
      osi-dir: osi
    secrets: inherit

workflow は AGENTS.OSI_DATASET / AGENTS.OSI_FIELD / AGENTS.OSI_METRIC / AGENTS.OSI_RELATIONSHIP を書き込みます。

Workflow 配線 — 複数ソース同時

1 つのリポジトリで dbt + LookML + OSI を同期する場合は、各 job を同一 workflow に並べます。job 間の依存関係は不要です。公式サンプルとして examples/workflows/dbt-looker.yml と examples/workflows/dbt-looker-osi.yml が用意されています。

jobs:
  agents-schema-dbt:
    uses: fivetran/agents_schema/.github/workflows/agents-schema-dbt.yml@v0.0.6
    with:
      dbt-project-dir: dbt_project
    secrets: inherit

  agents-schema-looker:
    uses: fivetran/agents_schema/.github/workflows/agents-schema-looker.yml@v0.0.6
    with:
      lookml-dir: lookml
    secrets: inherit

  agents-schema-osi:
    uses: fivetran/agents_schema/.github/workflows/agents-schema-osi.yml@v0.0.6
    with:
      osi-dir: osi
    secrets: inherit

バージョン pin

リポジトリ全体（reusable workflows・actions・CLI・examples・README・spec）が 1 つの release tag で versioning されます。現行タグは v0.0.6 です。アップグレードは uses: 行のタグを変更するだけです。

CLI 直接呼び出し

GitHub Actions を使わずローカルや任意の CI で直接実行する場合は agents-schema CLI を使います。PyPI に agents-schema として公開されています。

pip install agents-schema
# または
uv pip install agents-schema

インストール後のエントリポイントは agents-schema（agents_schema.cli:main）です。補助コマンド agents-schema-dbt-adapter-package（agents_schema.cli:dbt_adapter_package_main）も提供されます。

export WAREHOUSE_CREDENTIALS="$(cat credentials.yaml)"

agents-schema dbt --project-dir dbt_project
agents-schema looker --lookml-dir lookml
agents-schema osi --osi-dir osi

CLI は環境変数 WAREHOUSE_CREDENTIALS を読み込みます。

利用方法

エージェントは AGENTS.* テーブルを SQL で読んで、ビジネスデータをクエリする前に文脈を得ます。

AGENTS.ROOT 起点の discovery

まずどの provider がメタデータを書き込んでいるかを確認します。存在する provider のテーブルのみを参照します。

SELECT provider, key, content
FROM AGENTS.ROOT
ORDER BY provider, key;

metric 探索

OSI の metric は AGENTS.OSI_METRIC、LookML の measure は AGENTS.LOOKML_MEASURE を検索し、DESCRIPTION / AI_CONTEXT と計算式（OSI は EXPRESSION、LookML は SQL）を読み取ります。

SELECT name, description, ai_context, expression
FROM AGENTS.OSI_METRIC
WHERE LOWER(NAME||' '||COALESCE(DESCRIPTION,'')||' '||COALESCE(AI_CONTEXT,''))
      LIKE '%mrr%';

SELECT view_name, measure_name, type, sql, description, ai_context
FROM AGENTS.LOOKML_MEASURE
WHERE LOWER(MEASURE_NAME||' '||COALESCE(DESCRIPTION,'')||' '||COALESCE(AI_CONTEXT,''))
      LIKE '%revenue%';

physical table 解決

metric の formula を確認したら、参照する物理テーブルとクエリルールを取得します。AI_CONTEXT の指示に厳密に従います。

SELECT name, source_table, primary_key, description, ai_context
FROM AGENTS.OSI_DATASET
WHERE name = '<dataset_name>';

SELECT name, sql_table_name, description, ai_context
FROM AGENTS.LOOKML_VIEW
WHERE name = '<view_name>';

再帰 lineage（dbt dependency）

あるソースに直接・間接的に依存する全モデルは AGENTS.DBT_DEPENDENCY を WITH RECURSIVE で辿って取得します。次は SPEC.md の正準例です。

WITH RECURSIVE lineage AS (
  SELECT downstream_id AS node_id
  FROM AGENTS.DBT_DEPENDENCY
  WHERE upstream_id = 'source.my_project.raw.account'

  UNION ALL

  SELECT d.downstream_id
  FROM AGENTS.DBT_DEPENDENCY d
  JOIN lineage l ON d.upstream_id = l.node_id
)
SELECT DISTINCT m.name, m.schema_name, m.description
FROM lineage
JOIN AGENTS.DBT_MODEL m ON m.unique_id = lineage.node_id;

cross-source join（LookML ↔ dbt）

LookML view の sql_table_name と dbt model の schema_name / name を heuristic で突き合わせ、BI 向けオブジェクトをモデル化された warehouse テーブルへ対応づけます。sql_table_name は自由記述のため、orientation 用途の発見的クエリです。

SELECT
  v.name AS lookml_view,
  v.sql_table_name,
  m.unique_id AS dbt_model_id,
  m.name AS dbt_model,
  m.schema_name,
  m.description AS dbt_description
FROM AGENTS.LOOKML_VIEW v
LEFT JOIN AGENTS.DBT_MODEL m
  ON LOWER(v.sql_table_name) LIKE '%' || LOWER(m.schema_name) || '.' || LOWER(m.name) || '%';

sql_table_name が derived table（インライン SQL）や ${TABLE} テンプレート、database.schema.table の三段修飾を含む場合は、この LIKE 一致が外れます。一致しない view は LOOKML_VIEW.description / ai_context のテキスト検索で補うか、AGENTS.ROOT のカスタム行に view ↔ model の対応関係を明示して解決します。

analyst skill の導入

agents-schema-analyst skill を使うと、AI エージェントが AGENTS.* を自律的に参照してビジネス質問に答えます。事前に snow connection add で Snowflake 接続を設定します。

# Claude Code
curl -fsSL --create-dirs \
  -o ~/.claude/skills/agents-schema-analyst/SKILL.md \
  https://raw.githubusercontent.com/fivetran/agents_schema/v0.0.6/examples/skills/agents-schema-analyst/SKILL.md

# Codex
curl -fsSL --create-dirs \
  -o ~/.codex/skills/agents-schema-analyst/SKILL.md \
  https://raw.githubusercontent.com/fivetran/agents_schema/v0.0.6/examples/skills/agents-schema-analyst/SKILL.md

呼び出しは Claude Code が /agents-schema-analyst "What is our total MRR this month?"、Codex が $agents-schema-analyst "What is our total MRR this month?" です。

working directory に agents.yml を置くと接続名とスキーマ名をカスタマイズできます。

snow_cli_connection: my_connection
agents_schema_name: AGENTS

snow_cli_connection を省略すると snow connection list のデフォルト接続を、agents_schema_name を省略すると AGENTS を使います。skill は snow sql を通じて read-only（SELECT / SHOW のみ）で動作します。

運用

メタデータのリフレッシュ

ワークフローは push (branches:[main]) と workflow_dispatch の 2 トリガーで動きます。dbt manifest や LookML / OSI ファイルを main に push するたびに自動起動します。secret 更新後やリポジトリ変更を伴わないリフレッシュは、Actions タブの "Run workflow"（workflow_dispatch）で手動実行します。

冪等な再生成

各 source ingestion は自分の table family を CREATE OR REPLACE TABLE で丸ごと置換します。AGENTS.ROOT への書き込みは MERGE（upsert）で行い、自分の provider 行だけを更新して他 provider の行には触れません。

実行ごとの動作:
  source table（DBT_MODEL 等）: CREATE OR REPLACE TABLE → 全件置換
  AGENTS.ROOT:                 MERGE ON (provider, key) → 自 provider 行のみ upsert

consumer 側は手編集不可の「generated metadata」として扱う設計です。

状態確認

publish 済み provider は AGENTS.ROOT で確認します。各テーブルの最終更新時刻は Snowflake の INFORMATION_SCHEMA で補完できます。

SELECT provider, key, content FROM AGENTS.ROOT ORDER BY provider, key;

SELECT table_name, last_altered
FROM information_schema.tables
WHERE table_schema = 'AGENTS'
ORDER BY table_name;

バージョン更新

uses: 行のタグを上げるだけでリポジトリ全体（workflows / actions / CLI / examples / spec）が一括更新されます。本記事の調査時点（2026-06-04）の最新タグは v0.0.6 です。

ベストプラクティス

権限分離

SPEC.md「Permissions」に基づく推奨設計です。

• read: AGENTS.ROOT と全 source table は、分析クエリまたはエージェントクエリを実行するすべての Snowflake principal に SELECT を付与します。
• write: AGENTS.* への書き込みは、publish するワークフロー / サービスプリンシパルに限定します。専用ユーザー（例: AGENTS_SCHEMA_BOT）と TRANSFORMER ロールを用意し、key-pair 認証を推奨します。

取り込み経路の選択

SPEC.md「Populating the Tables」が示す 4 経路から、自分のインフラに合うものを選びます。GitHub Actions は 1 実装手段にすぎません。

カスタム provider 拡張

AGENTS.ROOT に独自 provider 行を追加すると、warehouse に任意のコンテキストを置けます。特定テーブルを説明する行は unprefixed table 名に key を合わせます（例: (dbt, model) → AGENTS.DBT_MODEL）。content は LLM consumer 向けに Markdown が自然です。

INSERT INTO AGENTS.ROOT (provider, key, content) VALUES
  ('acme_corp', 'skills/refund_workflow', '# Refund Workflow\nWhen a user asks about refunds, use this procedure...'),
  ('acme_corp', 'costs', '# Query Costs\nUse this before running expensive joins.');

カスタムテーブルを作る場合は (provider, table_name) の命名慣習（例: AGENTS.ACME_ORDERS）に従うと、LLM エージェントが混乱しにくくなります。テーブルのカラム構成に強制はなく、consumer が読める列名と型（自由記述は TEXT、ID やラベルは VARCHAR、JSON は VARIANT）を持てば十分です。最小構成の DDL 例は次のとおりです。

CREATE TABLE IF NOT EXISTS AGENTS.ACME_ORDERS (
  table_name  VARCHAR,
  description TEXT,
  ai_context  TEXT
);

ROOT.key にテーブル名以外の自由キー（例: skills/refund_workflow、costs）を使う場合、それは特定テーブルの文書ではなく自由コンテキストです。consumer は AGENTS.ROOT を全件 SELECT し、provider で絞り込んだうえで content（多くは Markdown）を読んで利用します。テーブル文書化行とは異なり、対応テーブルの存在を前提にしません。

destination の拡張余地

現状の対応 destination は Snowflake のみです（"more coming soon"）。destinations.py は Destination Protocol（replace_table / upsert_rows / insert_rows / close）を定義し、SnowflakeDestination がその実装です。他ウェアハウスへ拡張する際は、この Protocol を満たすクラスを追加し、open_destination() のディスパッチと SUPPORTED_WAREHOUSE_TYPES を拡張する形になります。TableSchema / Column による論理スキーマ定義は destination 非依存のため再利用できます。

適用境界

• dbt リポジトリを編集する dbt MCP server は source files / artifacts を直接使うべきです。Agents Schema はその代替ではありません。
• Semantic Layer の置換でもありません。計算・集計ロジックのランタイム実行は専用システムが担います。
• information_schema のように warehouse 内で自己完結するメタデータ発見レイヤーとして位置づけます。

consumer 側 skill のガードレール

examples/skills/agents-schema-analyst/SKILL.md に示されるガードレールです。

• snow sql の SELECT / SHOW のみ を許可します。INSERT・UPDATE・DROP・CREATE は実行しません。
• SHOW TABLES / GET_DDL による広域スキーマクロールは避け、AGENTS.ROOT を起点に focused SELECT で対象を絞ります。
• ROOT に出ていない provider のテーブルを推測クエリしません。
• AI_CONTEXT / DESCRIPTION の指示を厳守し、定義が無ければ推測せず「定義が見つからない」と返します。

トラブルシューティング

src/destinations.py / src/config.py の ConfigError メッセージを根拠とした主要エラーです。

WAREHOUSE_CREDENTIALS の解析順

destinations.py の _parse_warehouse_credentials は JSON → YAML の順で parse を試み、どちらも失敗すると ConfigError を送出します。認証手段は password / private_key_pem / private_key_path のいずれか 1 つが必須で、private_key_passphrase は暗号化キー使用時のみ指定します。

dbt manifest 不在

dbt compile --project-dir dbt_project
# または dbt run / dbt parse で target/manifest.json を生成
git add dbt_project/target/manifest.json
git commit -m "add dbt manifest"
git push origin main

ROOT が空のまま / provider が追加されない

ワークフローが正常終了しても ROOT が空の場合は、write 権限（TRANSFORMER role 等）が AGENTS スキーマに付与されているかを確認します。

SELECT provider, key FROM AGENTS.ROOT ORDER BY provider, key;

SELECT table_name FROM information_schema.tables
WHERE table_schema = 'AGENTS' ORDER BY table_name;

まとめ

Agents Schema は、AI エージェントがウェアハウスデータを正確にクエリするためのメタデータを、ウェアハウス内の標準 AGENTS スキーマに置く OSS 標準です。dbt / LookML / OSI のメタデータを GitHub Actions + CLI で AGENTS.* テーブルへ正規化し、SQL を実行できるあらゆるエージェントが「推測ではなく定義」に基づいてクエリできるようにします。information_schema に近く provider 横断で拡張でき、ai_context 列でエージェント向けの明示的な制約を与えられる点が特徴です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • Agents Schema — Open Data Infrastructure
  • Open Data Infrastructure
  • Open Semantic Interchange (OSI)
  • PyPI: agents-schema
• GitHub
  • fivetran/agents_schema
  • SPEC.md（スキーマ契約）
  • README.md
  • dbt Setup Guide
  • Looker Setup Guide
  • OSI Setup Guide
  • src/agents_schema/destinations.py
  • src/agents_schema/config.py
  • agents-schema-analyst SKILL.md
• 記事
  • deepwiki: fivetran/agents_schema（二次情報）