セマンティックレイヤー × AI

Enterprise AIで自然言語→SQLを許す場合、物理schemaだけでは「売上」「アクティブ顧客」「粗利」等の業務定義、正しいjoin path、粒度、集計式、アクセス制御を十分に表せない。semantic layerはLLMの能力を上げる機構ではなく、AIが推測すべき業務意味を減らし、metrics/dimensions/relationships/access policyをgoverned interfaceとして提供する実装層になり得る。EA-068では「semantic layerを通せば正しい」という製品保証ではなく、raw schema直結より統制可能な分析面を作る設計原則として扱う。

Enterprise AI Core / Data / governance / implementation / interoperability / benchmark / provider mapping。EA-066 Identity-aware ACL-aware RAGとはaccess enforcement、EA-067 Knowledge Freshness Engineeringとはsemantic definition freshness、EA-015監査証跡とはgenerated query・semantic version・actorのprovenanceで接続する。

Q1. AI分析をraw DB/schemaへ直接接続する代わりにsemantic layerを介在させると、business metric・join・dimension・access ruleを明示的に統制できるか。 Q2. current productsはsemantic model/viewをAI agent / natural-language analyticsの実行面として実装しているか。 Q3. semantic layerはtext-to-SQLの正確性を保証するか。それともerror surfaceを縮小するだけか。 Q4. semantic modelのversion、権限、freshness、bypass経路をどう監査すべきか。

• source class: official product documentation exact title: Cortex Analyst | Snowflake Documentation org: Snowflake canonical URL: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst publication/update: current documentation; access 2026-09-15 version/release: current as-of access; Semantic Views recommended, legacy staged YAML supported for backward compatibility supporting locator: Understanding Semantic Views / Why use Semantic Views / Access control requirements / Security and governance label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + limit finding: Semantic Views define logical tables, dimensions, facts, metrics and relationships; Cortex Analyst uses them for NL→SQL. Generated SQL executes in Snowflake and underlying table SELECT privileges/RBAC apply. Semantic view/model metadata aids SQL generation; semantic views are recommended for new implementations.

• source class: official product documentation exact title: Overview of semantic views org: Snowflake canonical URL: https://docs.snowflake.com/en/user-guide/views-semantic/overview publication/update: current documentation; access 2026-09-15 version/release: current as-of access supporting locator: Interfaces for working with Semantic Views / getting started label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + implementation finding: Semantic Views are schema-level objects containing business metrics, entities and relationships; usable by Cortex Agents, Cortex Analyst REST API and direct SQL SELECT, and shareable through Snowflake mechanisms.

• source class: official product documentation exact title: Routing Mode for Cortex Analyst org: Snowflake canonical URL: https://docs.snowflake.com/en/en/user-guide/snowflake-cortex/cortex-analyst/cortex-analyst-routing-mode publication/update: current documentation; access 2026-09-15 version/release: Preview Feature — Open; PRODUCT_VOLATILE supporting locator: Routing Mode overview / permissions note label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + limit finding: routing mode uses semantic views so metrics, joins and filters follow governed definitions; documentation explicitly states routing mode does not change permissions, which remain standard Snowflake privileges.

• source class: author-maintained product/OSS documentation exact title: Introduction - Cube Documentation org: Cube canonical URL: https://docs.cube.dev/docs/introduction publication/update: current documentation; access 2026-09-15 version/release: current docs; Cube Core open-source semantic layer supporting locator: Semantic SQL / semantic layer architecture / access control / APIs label: OSS_PRACTICE + SOURCE_REPORT + PRODUCT_VOLATILE relation: support + implementation finding: AI agents query Cube semantic layer through Semantic SQL rather than warehouse directly; runtime validates against data model and applies access policies before warehouse execution. Metrics, joins, access rules and caching are centralized; APIs include SQL/REST/GraphQL/MCP-related paths.

• source class: author-maintained product documentation exact title: Workbooks - Cube Documentation / Source SQL Tabs org: Cube canonical URL: https://docs.cube.dev/docs/explore-analyze/workbooks/index ; https://docs.cube.dev/docs/explore-analyze/workbooks/source-sql-tabs publication/update: current documentation; access 2026-09-15 version/release: current as-of access supporting locator: Semantic Query vs Source SQL Query label: SOURCE_REPORT + PRODUCT_VOLATILE relation: counter + limit finding: Cube itself exposes both semantic-query paths and Source SQL Query paths that bypass the semantic layer. Therefore product adoption alone does not prove semantic enforcement; bypass surface must be separately governed.

• source class: open specification / industry working group exact title: Open Semantic Interchange (OSI) org: Open Semantic Interchange community canonical URL: https://open-semantic-interchange.org/ publication/update: specification effort current; site update includes 2026-06-04 activity; access 2026-09-15 version/release: current specification site; Apache 2.0; YAML; exact spec version must be rechecked at update time supporting locator: Core Classes / AI Ready Semantic Context / Working Groups label: SOURCE_REPORT + PRODUCT_VOLATILE relation: interoperability + context finding: OSI is an active vendor-neutral effort to exchange semantic metadata across analytics/AI/BI, with semantic model, datasets, fields, metrics, dimensions and relationships. It supports the direction of portable semantics but does not yet establish universal cross-vendor semantic equivalence.

• source class: primary research / benchmark exact title: Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows org/authors: Fangyu Lei et al. canonical URL: https://arxiv.org/abs/2411.07763 publication: 2024-11-12; access 2026-09-15 version: arXiv 2411.07763; benchmark 632 enterprise workflow problems supporting locator: abstract / benchmark description / reported baseline label: RESEARCH relation: counter + context finding: real enterprise text-to-SQL involves large schemas, dialect docs, metadata and project code; reported agent success is far below simpler Spider/BIRD settings. This is evidence against treating raw-schema text-to-SQL as solved, but it does not directly prove semantic-layer superiority.

• source class: author-maintained reproducible benchmark exact title: LLM Semantic Layer Benchmark org: dbt Labs canonical URL: https://dbt-labs.github.io/dbt-llm-sl-bench/ publication/update: current benchmark site; access 2026-09-15 version: current site; 11 insurance-domain questions; repeated/model comparison runs available supporting locator: benchmark description / note on modeling label: RESEARCH + SOURCE_REPORT relation: support + counter + limit finding: benchmark explicitly compares Semantic Layer (MetricFlow) with raw SQL. Importantly, 3/11 questions are documented as “too many hops” when the semantic model cannot express required joins; adding models can make them answerable. This supports semantic modeling as a controllable interface while demonstrating that model coverage is itself a failure boundary.

F1 VERIFIED_SPEC/OSS_PRACTICE: semantic layer can encode business concepts above physical schema: metrics, dimensions, entities/relationships/join paths and, depending on implementation, access policy. Current Snowflake and Cube implementations expose these semantics directly to AI/NL analytics. F2 INFERENCE: the architectural value is not “LLM becomes correct” but “business meaning becomes an explicit, versionable, reviewable dependency rather than an implicit LLM inference.” This is the safe Core abstraction. F3 VERIFIED_SPEC: Snowflake semantic views are native schema-level governed objects; generated SQL still executes under database privileges. Semantic guidance and authorization are separate controls. F4 SOURCE_REPORT/OSS_PRACTICE: Cube demonstrates a semantic runtime where AI queries are validated and access policy is applied before warehouse execution; however Cube also documents raw Source SQL paths that bypass the layer. Therefore enforcement must be architectural, not assumed from product presence. F5 RESEARCH: Spider 2.0 establishes that enterprise text-to-SQL over complex raw data remains difficult. dbt Labs' semantic-layer benchmark provides direct comparative evidence but is small/domain-specific and also documents expressiveness failures (“too many hops”). F6 SOURCE_REPORT: OSI shows active movement toward vendor-neutral semantic interchange, but interoperability is not yet evidence that metric semantics, security, dialect behavior or execution results are identical across implementations.

• Semantic layer can encode a wrong metric, stale business rule, incorrect relationship, unsafe access rule, or incomplete domain. It can make an error consistently repeatable rather than correct it.
• Coverage gap: if a required measure/join/domain is absent, the agent may fail, refuse, or seek a bypass. dbt benchmark explicitly documents unexpressible “too many hops” cases before extra modeling.
• Bypass gap: raw SQL, direct warehouse credentials, alternate tools/MCP servers, notebooks, exports, cached extracts or shadow semantic models can evade the governed layer.
• Authorization gap: semantic definitions and database privileges are distinct. A semantically valid query can still be unauthorized; conversely a technically authorized raw-table query may violate intended business abstraction.
• Freshness gap: warehouse data freshness and semantic-definition freshness are separate. Metric definition changes require version/provenance and regression testing.
• LLM gap: correct semantic metadata does not guarantee correct question interpretation, filter choice, time window, query generation, execution or narrative explanation.
• Interoperability gap: OSI portability is an active specification effort; do not claim universal vendor-neutral equivalence without versioned converter/conformance evidence.

Snowflake: account/region/model availability, required CORTEX roles, semantic-view privileges and underlying table SELECT; preview features must be rechecked as-of publication update. Cube: Cube/Core/Cloud feature split, deployment configuration, API/MCP availability, JWT/security context and access-policy setup. dbt benchmark/MetricFlow: product/version and model coverage must be pinned before product claims. OSI: specification version and participating implementations/converters must be revalidated.

MATURE PATTERN / PRODUCT-SPECIFIC IMPLEMENTATIONS EXIST. Snowflake has native Semantic Views integrated with Cortex Analyst/Agents and SQL; Cube has an open-source semantic-layer foundation and AI-facing query surfaces. Cross-vendor portable semantic interchange is EMERGING rather than closed. A universal Enterprise AI semantic contract remains PROPOSAL.

Use three distinct evaluation layers: A) semantic correctness: metric formula, grain, join path, dimension/filter/time semantics; B) execution correctness: generated query result equals golden result under authorized principal; C) answer correctness: final narrative/number/citation faithfully represents result. Required paired fixture: same 30-100 business questions against (1) raw schema path and (2) semantic path, same model/version/temperature where possible. Include ambiguous synonyms, metric-definition conflicts, multi-hop joins, row-level security, unsupported questions, stale metric version, and attempted bypass. Track execution accuracy, metric-selection accuracy, unauthorized-result rate, abstention quality, latency/cost, semantic-model coverage and regression after semantic changes. Spider 2.0 is external context, not a product guarantee. dbt LLM Semantic Layer Benchmark is useful comparative evidence but too small to generalize alone.

enforce warehouse least privilege plus semantic-layer policy; prohibit or separately authorize raw-SQL bypass. Semantic metadata itself can reveal sensitive table/metric names and business logic. AUDIT: record principal, question, model/version, semantic-model/view ID+version/hash, generated query, executed query, referenced metrics/dimensions, policy decision, result/error and final answer provenance.

semantic modeling adds authoring/review/CI maintenance but may reduce repeated prompt/schema context and wrong-query rework; product-specific caching/preaggregation can change warehouse cost. No generic ROI claim established.

treat semantic definitions as code/config with owner, version control, review, tests, deployment environment, deprecation and rollback. Couple EA-067 freshness SLO to semantic definition rollout, not only source data refresh.

「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設定、raw SQL等のbypass経路、LLMの質問解釈・query生成誤りは別途評価する必要がある。」

• Coreへ「Semantic Contract」を追加候補: metric/dimension/entity/relationship/grain/filter/time semantics/access policy/owner/version/effective_at/deprecated_at/source lineage。
• provider mappingはSnowflake Semantic Views+Cortex、Cube Semantic Layer/AI、dbt Semantic Layer/MetricFlowをversioned comparisonし、Microsoft Fabric/Power BI semantic model、Looker/LookML等は追加採集候補として別bounded unitで照合する。
• OSIはinteroperability節へ置き、publication時のspec version、converter実装、conformance/test statusを再採集する。
• paired benchmarkをTEST_PROFILEとして実施し、raw schema vs semantic pathを同一fixtureで比較する。
• raw SQL / alternate tool / notebook / exportのbypass inventoryを必須化し、「semantic layer adopted」と「semantic layer enforced」を分離する。

provider横断で同一metric definitionが同一結果を保証するconformance水準。OSIのpublication時点spec/version/converter coverage。semantic-layer変更からAI回答へのpropagation latency。semantic metadataへのprompt injection/poisoning耐性。複雑なnon-additive/semi-additive metric、temporal semantics、multi-hop relationshipの各製品限界。

EA-068の更新準備として、(a) current implementationが複数系統で存在、(b) raw-schema text-to-SQLの限界、(c) semantic-layer自身のcoverage/bypass/freshness/authorization failure envelope、(d) interoperabilityの現状、(e)後続paired TEST_PROFILEが揃ったため本RUNをbounded completeとする。UNKNOWNは推測で閉じず後続Workへ渡す。

---