AWSはAtScaleのSMLで次元や指標を定義する構成を公開しました。Redshift上の共通モデルを、MCPのエージェントと分析ツールから問い合わせます。 AIと既存分析の数値を同じ定義へ揃える設計です。定義の変更管理に加え、データ複製の鮮度、集計の粒度、権限の対応を確認する必要があります。 指標の定義をコードとして管理する AWSは10月20日、AtScaleとBedrock AgentCoreを使う意味層の構成を紹介しました。SMLというYAMLベースの仕様で、データセット、次元、階層、指標などを表し、Gitで版を管理します。同じモデルをSQL、XMLA、MCPの入口へ提供し、エージェントと既存の分析ツールが共通の定義を使います。原文では、Auroraを業務の元システムとし、分析用のコピーをRedshiftにまとめる例を示しています。複数の元データをその場で自由に結ぶのではなく、一つの分析基盤へ寄せた後に意味層を設計する方法です。既存製品を使った技術解説として、別方式との違いを読むことができます。 分析用の複製と利用者の権限が前提になる 影響を受けるのは、データウェアハウスの管理者、分析担当者、AIアプリの開発者です。エージェントは業務指標を使って質問しますが、元の表との関係や集計は意味層が担います。利用者の識別情報はAgentCoreの経路を通じてAtScaleへ渡し、役割や行単位の制御へ結び付けます。業務データの更新は複製の経路に依存するため、同じ指標でも現時点の元システムと時差が出る可能性があります。売上や顧客数などを回答する際、その数字の対象期間と反映時刻を説明できることが論点です。自動集計の仕組みは高頻度の問い合わせを速める狙いがありますが、集計単位が質問の意味と一致するかは別に確認する必要があります。共通のモデルを持つだけでデータ品質の問題が解消するわけではありません。利用者ごとに見える次元の違いも比較対象です。同じ言葉の質問でも、権限が異なる結果を返すことを、利用者が理解できる説明へつなげる必要があります。 版の差分を業務上の数値の変化と結び付ける 実務では、Gitで変更を追えることを、業務指標のレビューへつなげる体制が論点です。定義の変更が集計結果や見える範囲をどう変えるかを、担当部門が判断できる必要があります。エージェントの問いが自由になるほど、従来の画面では使われなかった組み合わせが増える可能性があります。費用にはモデルの呼び出しに加え、Redshiftの処理、分析用コピーの維持、集計用データの保存も含まれます。原文は特定の版に基づく手順であり、運用中の環境へそのまま適用できるとは限りません。次の判断点は、代表的な質問を同じデータで試し、従来の分析結果と整合するかです。定義、権限、鮮度を一緒に記録できれば、回答が変わった理由を追い、モデル自体の誤りと基盤の変更を区別しやすくなると考えられます。分析用の複製に遅れがある時は、その状態を回答へ伝えられるかも検討点です。