協業小売DX事業における データマネジメント 河中 祥吾 CA Data Night #3 | 2024/3/14 

2 河中 祥吾 所属 AI事業本部 > 協業リテールメディアDiv > アプリ運用カンパニー 略歴 2021年4月~ : 新卒入社。DataOne事業部 においてオフライン 　　　　　　 購買情報を用いた広告配信向け のDMPやDSP 　　　　　　 配信メニューの開発に従事。 2022年6月~：アプリ運用カンパニーにおいてアプリグロース 　　　　　　 に向けたデータ分析 や 分析基盤構築など 　　　　　　 データエンジニアリング業務にも従事。 自己紹介 @shltn @shltn1128 

目次 ● DX事業・協業リテールメディア事業について ● データマネジメントに取り掛かった経緯と課題 ● 課題解決に向けた取り組み・得られた効果 ● まとめと今後の展望 3 

の事業 https://speakerdeck.com/cyberagent_recruit/cypitch?slide=20 4 

AI事業本部：AI技術をDX領域で活用 5 第４の柱 

なぜ小売か？ 新たに注力している リテールメディア事業 ● 小売企業のEC・アプリ・店舗を広告媒体（メディア）とする広告事業 ● 米国では Amazon や Walmart が代表例。近年日本でも市場が広がりつつある 6 オウンドアプリでの広告配信 店内サイネージの広告配信 オンライン（EC, アプリ等） オフライン（サイネージ, ビーコン等） お客様に選ばれる”企業”、使われる”アプリ”を実現する テック企業 × 小売企業の パートナーシップ | CyberAgent Way サイバーエージェント公式オウンドメディア Walmart Sponsored Search 

7 パートナー企業様と協業でアプリ開発から運用・グロースまで一気通貫で実施 協業Div | アプリ運用カンパニー 

アプリ運用カンパニー 8 A社 - アプリ開発/運用 - B社 - 広告運用 - C社 - 分析提案 - D社 - 新規提案 - データ サイエンティスト エンジニア （ネイティブ/バックエンド/Web..） デザイナー データ サイエンティスト エンジニア デザイナー プロジェクト/プロダクト マネージャー データ アナリスト セールス プロジェクト/プロダクト マネージャー プロジェクト/プロダクト マネージャー QA アプリ運用カンパニー ×10以上 ● 多様な小売企業と協業して様々な事業フェーズのプロジェクトが存在 

アプリ運用カンパニー 9 アプリ運用カンパニー A社 - アプリ開発/運用 - B社 - 広告運用 - C社 - 分析提案 - D社 - 新規提案 - ×10以上 データ サイエンティスト エンジニア （ネイティブ/バックエンド/Web..） デザイナー データ サイエンティスト エンジニア デザイナー プロジェクト/プロダクト マネージャー データ アナリスト セールス プロジェクト/プロダクト マネージャー プロジェクト/プロダクト マネージャー QA ● 多様な小売企業と協業して様々な事業フェーズのプロジェクトが存在 担当プロジェクト アプリ開発・運用・データ分析により アプリ効果売上をグロースさせる施策 検証 をCAが担当 

10 アプリグロースに向けたこれまでのトライ CA BASE NEXT 2022 小売マーケティングにおけるクーポン 配信最適化に向けた取り組み | 兵頭 亮介 CA Developer Conference 2023 協業DXにおける「斜め上の需要」に乗る データサイエンスとその先 | 藤田 光明 ターゲティングクーポンの効果検証PoC や 施策をPoCで終わらせずスケールさせるための 取り組みを行ってきた。 

本日の発表内容 サイバーエージェントにおいて第４の柱として注力している協業DX事業におい て、事業成長に伴い変化するデータ活用のニーズに合わせて必要となったデータ マネジメントについて経緯から得られた結果を時系列的にお話をいたします。 11 発表タイトル 協業小売DX事業におけるデータマネジメント 

事業フェーズの変化 12 アプリ開発/運用の開始 アプリグロースに向けたチーム 内での分析環境の構築 データ基盤利用者の拡大 事業拡大に伴い社内他部署やクライ アントを含めたデータ共有の需要 施策運用のシステム化 より発展的な分析から施策 運用管理のシステム化 データマネジメント着手 のキッカケ ・無人化したデータ基盤の復興 ・取り扱うデータの多様化 

事業フェーズの変化 13 アプリ開発/運用の開始 アプリグロースに向けたチーム 内での分析環境の構築 データ基盤利用者の拡大 事業拡大に伴い社内他部署やクライ アントを含めたデータ共有の需要 データマネジメント着手 のキッカケ ・無人化したデータ基盤の復興 ・取り扱うデータの多様化 施策運用のシステム化 より発展的な分析から施策 運用管理のシステム化 このあたりの お話をします 

目次 ● 協業リテールメディア事業・DX事業について ● データマネジメントに取り掛かった経緯と課題 ● 課題解決に向けた取り組み・得られた効果 ● まとめと今後の展望 14 

データマネジメントに取り掛かった経緯と課題 15 1. 既存データ基盤の無人化によるデータ信頼性の低下 2. 事業拡大に伴うデータソースとデータ利用者の多様化 

無人化：属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること 16 ※「無人化システム」を駆逐する組織マネジメントとエンジニアリング｜tmknom URL : https://zenn.dev/tmknom/articles/93f227ad5e55aa データサイエンティスト データエンジニア(兼務) ● データインフラ・ パイプラインの整備 ● データ運用管理 ● DWHのデータを元に分析・ 施策提案 データマネジメントに取り掛かった経緯と課題1 既存データ基盤の無人化※によるデータ信頼性の低下 メンテナンス 分析 

無人化：属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること 17 ※「無人化システム」を駆逐する組織マネジメントとエンジニアリング｜tmknom URL : https://zenn.dev/tmknom/articles/93f227ad5e55aa データサイエンティスト データエンジニア(兼務) ● データインフラ・ パイプラインの整備 ● データ運用管理 ● DWHのデータを元に分析・ 施策提案 退 職 データ基盤が 無人化😭 DSが運用フローの概要 引き継いだものの... データマネジメントに取り掛かった経緯と課題1 既存データ基盤の無人化※によるデータ信頼性の低下 

1. データ品質の低下・管理コストの増大 18 データマネジメントに取り掛かった経緯と課題1 2. 分析コストの増大 • 前処理クエリの属人化 ➔ 同じ目的の分析でも分析者間で結果が異なる可能性 • 分析コスト・クエリミスの増大 • データ処理によるエラーに分析結果から気づく • コード管理が煩雑で原因調査・対応に時間を要する ※「無人化システム」を駆逐する組織マネジメントとエンジニアリング｜tmknom URL : https://zenn.dev/tmknom/articles/93f227ad5e55aa 既存データ基盤の無人化※によるデータ信頼性の低下 

19 データの信頼性がクライアントとの信頼性に直結 • 不正確なデータを元に分析を行い、過小/過大評価した結果で 間違った意思決定をしてしまう。 • クライアントがデータの不備に気づく。 など 企業の信頼損失により契約打ち切りもありうる データマネジメントに取り掛かった経緯と課題1 ※「無人化システム」を駆逐する組織マネジメントとエンジニアリング｜tmknom URL : https://zenn.dev/tmknom/articles/93f227ad5e55aa 既存データ基盤の無人化※によるデータ信頼性の低下 

● データ処理フローのレビュー体制がない ○ Github上でのレビュー体制やクエリのバージョン管理がない ○ ドキュメントの手動管理による実態との乖離 ● 継続的なデータ品質モニタリングの不足 ○ カラムの制約やテスト等がない ○ データ処理過程でのエラー検知項目の不足 当時の開発体制的な課題 20 データマネジメントに取り掛かった経緯と課題1 

事業拡大に伴うデータソースとデータ利用者の多様化 21 ※ 「実践的データ基盤への処方箋」を参考に筆者作成 データマネジメントに取り掛かった経緯と課題2 初期 フェーズ 社外 社内 データ ソース ②データ基盤 ③データ組織 ①データ ソース ④データ 利用者 利用者 社外 社内 アプリ データ 購買 データ 会員 データ 購買 データ ネイティブ アプリ利用者 データ レイク DWH データ マート メタデータ データの 所有者 データ サイエンティスト クライアント 意思決定者 データ エンジニア データ スチュワート データ組織の 組織長 データガバナンス・データマネジメント データ収集 　　システム構築・運用・監視 　　　　ストレージ・リソース管理 データ整備 　　サービス品質担保 　　　　利用推進・サポート データ 収集 ・分析 ・BI ・データ 　アプリ ユースケース 

事業拡大に伴うデータソースとデータ利用者の多様化 22 ※ 「実践的データ基盤への処方箋」を参考に筆者作成 データマネジメントに取り掛かった経緯と課題2 初期 フェーズ 社外 社内 データ ソース ②データ基盤 ③データ組織 ①データ ソース ④データ 利用者 利用者 社外 社内 アプリ データ 購買 データ 会員 データ 購買 データ ネイティブ アプリ利用者 データ レイク DWH データ マート メタデータ データの 所有者 データ サイエンティスト クライアント 意思決定者 データ エンジニア データ スチュワート データ組織の 組織長 データガバナンス・データマネジメント データ収集 　　システム構築・運用・監視 　　　　ストレージ・リソース管理 データ整備 　　サービス品質担保 　　　　利用推進・サポート 基本的なアプリログ と購買データのみ チーム内での 分析目的が中心 データ 収集 ・分析 ・BI ・データ 　アプリ ユースケース 

事業拡大に伴うデータソースとデータ利用者の多様化 23 ※ 「実践的データ基盤への処方箋」を参考に筆者作成 データマネジメントに取り掛かった経緯と課題2 社外 社内 データ ソース ②データ基盤 ③データ組織 ①データ ソース ④データ 利用者 利用者 社外 社内 アプリ データ 購買 データ 会員 データ 購買 データ ネイティブ アプリ利用者 データ レイク データ マート メタデータ データの 所有者 データ サイエンティスト 意思決定者 データ エンジニア データ スチュワート データ組織の 組織長 データガバナンス・データマネジメント データ収集 　　システム構築・運用・監視 　　　　ストレージ・リソース管理 データ整備 　　サービス品質担保 　　　　利用推進・サポート 他チャネル 利用者 他チャネル データ 部買付外部 データ ︙ 在庫 買付外部 データ クライアント 連携データ データ 収集 ・分析 ・BI ・データ 　アプリ ユースケース 事業拡大 フェーズ MA/CRM 機械学習 エンジニア 意思決定者 他事業部 クライアント 社外 DWH 

事業拡大に伴うデータソースとデータ利用者の多様化 24 ※ 「実践的データ基盤への処方箋」を参考に筆者作成 データマネジメントに取り掛かった経緯と課題2 社外 社内 データ ソース ②データ基盤 ③データ組織 ①データ ソース ④データ 利用者 利用者 社外 社内 アプリ データ 購買 データ 会員 データ 購買 データ ネイティブ アプリ利用者 データ レイク データ マート メタデータ データの 所有者 データ サイエンティスト クライアント 意思決定者 データ エンジニア データ スチュワート データ組織の 組織長 データガバナンス・データマネジメント データ収集 　　システム構築・運用・監視 　　　　ストレージ・リソース管理 データ整備 　　サービス品質担保 　　　　利用推進・サポート 他チャネル 利用者 他チャネル データ 部買付外部 データ ︙ 在庫 買付外部 データ クライアント 連携データ データ 収集 ・分析 ・BI ・データ 　アプリ ユースケース 事業拡大 フェーズ 機械学習 エンジニア 意思決定者 ● 外部システムへの接続 ● 社内他部署での利用 シーンの拡大 ● 機密性：高 ● 連携頻度：高 ● データ所有者：多 なデータを今後連携予定 MA/CRM 他事業部 体制強化の必要性 DWH 

データマネジメントに取り掛かった経緯と課題 25 2. 事業拡大に伴うデータソースとデータ利用者の多様化 ○ 日常的な業務で観測できる範囲外でのデータ利用 ➔ 利用目的外のデータ利用・漏洩リスクが増大 ○ SQLなど分析スキルの習熟度の差が大きい ➔ 問合せやスポット分析依頼で業務時間を圧迫 1. 既存データ基盤の無人化によるデータ信頼性の低下 ○ 根本原因としては開発の属人化やデータ品質モニタリングの不足 ○ ビジネス的にはクライアントとの信頼性の低下に直結する可能性 

2. 事業拡大に伴うデータソースとデータ利用者の多様化 ● データセキュリティの向上 ○ 利用用途に合わせたロールやスキーマの設計 ● ドキュメント化とオリエンテーション ○ データ基盤の管理・運用の標準化 および 分析できる環境づくり 課題を元に満たしたい要件 1. 既存データ基盤の無人化によるデータ信頼性の低下 ● Github上でのクエリ管理：レビュー体制やバージョン管理 ● 継続的なデータ品質の担保 ○ 主に 一意性 / 完全性 / 鮮度 ● データ処理フローのジョブスケジュール管理 ● データ仕様やメタデータのドキュメント管理 26 

目次 ● 協業リテールメディア事業・DX事業について ● データマネジメントに取り掛かった経緯と課題 ● 課題解決に向けた取り組み・得られた効果 ● まとめと今後の展望 27 

当初のデータフローの外観 28 ※ かなり簡略化した図となっております Snowflake内でほぼすべての データ処理が実行されていた。 （かつ処理クエリが煩雑） 

1. dbtの導入 と dbt Cloudによるジョブスケジュール管理 29 課題解決に向けた取り組み 2-1. データセキュリティの向上に向けたスキーマの設計 2-2. ドキュメント化とオリエンテーション 課題２：事業拡大に伴うデータソースとデータ利用者が多様化 課題1：既存データ基盤の無人化によるデータ信頼性の低下 

1. dbtの導入 と dbt Cloudによるジョブスケジュール管理 30 課題解決に向けた取り組み 2-1. データセキュリティの向上に向けたスキーマの設計 2-2. ドキュメント化とオリエンテーション 課題２：事業拡大に伴うデータソースとデータ利用者が多様化 課題1：既存データ基盤の無人化によるデータ信頼性の低下 

やらなかったこと 31 ● インフラのIaC化（Terraformの導入） ※ 特にロール周りは導入したほうが良い気はしているが、途中から導入するリスクとコストを踏まえて見送り。 ● ワークフローエンジンの導入 ○ 定期実行には dbt cloud環境を利用 ● 大規模な分析環境のリプレイス（全体のアーキテクチャの見直し） ベースは既存リソースを活用しつつ課題の解決に専念 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 

dbt とは？ ● 比較的学習コストが低い ● Gitリポジトリと連携したCI/CD機能 ● データ品質テスト および テストエラーの通知が可能 ● DAGやドキュメントの自動生成 ● スケジューラによるジョブの定期実行(Cloud版のみ) 32 ● （ほぼ）SQLのみでデータを変換しDWH、データマートを構築可能なツール ● ELTデータパイプラインのアプローチにおける「T」層の部分を担う 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 ■ 概要 ■ 特徴 

● （ほぼ）SQLのSelect文のみでパイプラインが構築できる。 ● ref関数により他のモデルを参照することでDAGを考慮した上で実行される。 33 dbtの導入：モデルの作成 dbtで始めるデータパイプライン構築〜入門から実践〜 : https://zenn.dev/dbt_tokyo/books/537de43829f3a0/viewer/what_dbt -- orders.sql select orders.id, orders.status, sum(case when payments.payment_method = 'bank_transfer' then payments.amount else 0 end) as bank_transfer_amount, sum(case when payments.payment_method = 'credit_card' then payments.amount else 0 end) as credit_card_amount, sum(case when payments.payment_method = 'gift_card' then payments.amount else 0 end) as gift_card_amount, sum(amount) as total_amount from {{ ref('base_orders') }} as orders left join {{ ref('base_payments') }} as payments on payments.order_id = orders.id 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 

-- schema.yaml models: - name: orders description: Joined table order and payments columns: - name: order_id description: Primary key tests: - unique - not_null – raw.yaml sources: - name: raw schema: raw tables: - name: base_orders loaded_at_field: insert_timestamp freshness: error_after: {count: 23, period: hour} ● yaml 形式でテストとメタデータの定義が可能。 ○ テスト機能の拡張や効率的なメタデータ管理に便利なパッケージもある。 ● データソースの鮮度テストや実行結果に対するテストも可能。 ● テストエラー時にはSlackなどへエラー通知を送ることも可能。 34 dbtの導入：テストとメタデータ管理 例 ) データソースの鮮度テスト 例 ) テストとメタデータの付与 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 

● 1コマンドでhtml形式でのドキュメントの自動生成が可能。 ● 設定次第では Github Pages でホスティングして社内限定公開等も可能。 35 dbtの導入：ドキュメントの自動生成 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 

dbt Cloudの概要：ジョブスケジューラ 36 dbt Cloud API 101 | https://www.phdata.io/blog/dbt-cloud-api-101-trigger-and-polling-jobs/ cronで表現できる粒度で スケジュール管理が可能 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 

満たしたい要件とdbtの機能の対応関係 37 満たしたい要件 dbtの機能 Github上でのクエリ管理 （レビュー/バージョニング） Gitリポジトリと連携したCI/CD機能 持続的なデータ品質担保 定期ジョブ実行時のテスト実行とエラー発生時の通知機能 └ データソースの鮮度確認 / 結果のカラムユニーク制約 etc ドキュメント管理 リネージグラフ（DAG）の自動生成 ドキュメントの自動生成 メタデータ管理 dbt osmosisなどメタデータ管理サポートパッケージ データ処理フローの ジョブスケジュール管理 Job Scheduler機能（dbt Cloudのみ） 課題解決に向けた取り組み1:dbtの導入とdbt Cloudによるジョブスケジュール管理 

1. dbtの導入 と dbt Cloudによるジョブスケジュール管理 38 課題解決に向けた取り組み と 得られた結果 課題1：既存データ基盤の無人化によるデータ信頼性の低下 ● dbtを用いたデータモデリングにより、Github上のクエリと実態に差分 がなく、クエリレビューもでき、属人化が起こりづらい環境に。 ● dbt testにより日次実行されたデータに対してもデータ品質チェックが できており、データ品質およびデータ信頼性が向上！ 得られた結果： 

1. dbtの導入 と dbt Cloudによるジョブスケジュール管理 39 課題解決に向けた取り組み 2-1. データセキュリティの向上に向けたスキーマの設計 2-2. ドキュメント化とオリエンテーション 課題２：事業拡大に伴うデータソースとデータ利用者が多様化 課題1：既存データ基盤の無人化によるデータ信頼性の低下 

事業拡大に伴うデータソースとデータ利用者の多様化 40 ※ 「実践的データ基盤への処方箋」を参考に筆者作成 データマネジメントに取り掛かった経緯と課題2 社外 社内 データ ソース ②データ基盤 ③データ組織 ①データ ソース ④データ 利用者 利用者 社外 社内 アプリ データ 購買 データ 会員 データ 購買 データ ネイティブ アプリ利用者 データ レイク データ マート メタデータ データの 所有者 データ サイエンティスト クライアント 意思決定者 データ エンジニア データ スチュワート データ組織の 組織長 データガバナンス・データマネジメント データ収集 　　システム構築・運用・監視 　　　　ストレージ・リソース管理 データ整備 　　サービス品質担保 　　　　利用推進・サポート 他チャネル 利用者 他チャネル データ 部買付外部 データ ︙ 在庫 買付外部 データ クライアント 連携データ データ 収集 ・分析 ・BI ・データ 　アプリ ユースケース 事業拡大 フェーズ 機械学習 エンジニア 意思決定者 ● 外部システムへの接続 ● 社内他部署での利用 シーンの拡大 ● 機密性：高 ● 連携頻度：高 ● データ所有者：多 なデータを今後連携予定 MA/CRM 他事業部 体制強化の必要性 DWH 

機密性の高い情報を含むデータに利用者が増える上での課題 41 具体的にどう言った課題があったのか ● どのようにデータを共有するか？ ○ 社内でもデータを共有する方法は何パターンかある 例）データシェアリング、ユーザアカウントの発行 etc... ● 各データ利用者で需要が異なる 機密性が高いとは？具体的にどう言ったもの ● 例：顧客の個人情報 (メールアドレス等 ) , 粗利益 etc.. 課題解決に向けた取り組み2-1: データセキュリティの向上に向けたスキーマの設計 

42 共有先が多様化する上での管理の難しさ このデータAを使 いたいのですが.. このデータBを 使いたいのですが.. 共有先1 共有先n ● クライアントのデータを扱ってる上でデータに対する機密性の担保は必須 ● 設計次第では共有先毎にロールやオブジェクトを都度開発する工数が発生 課題解決に向けた取り組み2-1: データセキュリティの向上に向けたスキーマの設計 

対応方針：機密性の高いカラムを落とした共有用スキーマの作成 43 課題解決に向けた取り組み2-1: データセキュリティの向上に向けたスキーマの設計 DataLake 生のデータ Staging キャスト 命名統一 DWH 1次集約 Marts 2次集約 SHARE_DWH 1次集約 他部署用 クライアントには基本全共有 ● 共有先が増えるたびに共有用オブジェクトを作成する開発コストを削減。 ● 同時に機密性の高いデータの漏洩リスクを低下。 

■ dbt管理のドキュメント化 ● githubレポジトリのReadmeで管理。 ● DS自身で必要なモデルを自分で作成し、自分 でデプロイ出来るようにオリエンテーション を実施。 ■ dbt docsをgithub pagesで社内限定公開 ● 前処理方法 や カラムの定義・テスト内容など が確認可能。 データサイエンティスト・エンジニア向け 44 課題解決に向けた取り組み2-2 : ドキュメント化とオリエンテーション 

45 SQLに詳しくない方向け ■ 使い方レクチャとテンプレートの作成 ● まずはデータ基盤を触られるにオリエン テーションを実施。 ● 頻繁に発生する集計したいパターンをテン プレート化して、修正する箇所を説明。 ● 分析の幅を広げたい場合には支援。 課題解決に向けた取り組み2-2 : ドキュメント化とオリエンテーション 

46 課題解決に向けた取り組み と 得られた結果 2-1. データセキュリティの向上に向けたスキーマの設計 2-2. ドキュメント化とオリエンテーション 課題２：事業拡大に伴うデータソースとデータ利用者が多様化 ● データの機密性を考慮しつつ低コストでデータ共有が可能に！ ● 権限委譲と初期サポートを充実させ、スポット分析依頼は実施 0 に！ ● チーム内のDS誰もが必要に応じてdbtを用いたデータモデリングが出来 るように！ 得られた結果： 

現在のデータフローの外観 47 ① dbtの導入 ② データ利用者の拡大 ② データ利用者の拡大 社内共有用環境の切り離し 

● 分析する上でほしいカラムがついていて 分析効率がいいんです！ ● このMARTで集計している指標 社内でも使わせていただきますね！ （この指標を集計する上で参照するべきカラムはこれだったんですね..！） クライアントへのデータ共有後に得られた反応 48 

ビジネス的に得られた恩恵 ● クライアント社内BI環境でCA管理のビジネス指標が利用されている！ （導入コンサルやSlerだとある種当たり前かもしれませんが） ○ データモデリングやデータ品質管理自体が難しいことも少なくない ● 共通指標を追える状態を作ることで施策や開発優先度が明確化。 ● MAツールの導入も含めて携わり施策や提案の幅が広がった。 49 データの信頼性がクライアントとの信頼性に直結 (ポジティブな意味で) 

まとめ ● 既存リソースを活用しつつ dbt導入やスキーマの再設計によりできるだけ 低コストでデータ需要に合わせたデータマネジメントを行ってきた。 ● ビジネス的な恩恵として指標の共通化が図れる事で事業に対する目線が揃い やすくなった = データ信頼性がクライアントとの信頼性につながった！ ● 反省：データマネジメント推進におけるKPIの設定をしていなかった。 ○ DMBOK成熟度アセスメントの活用 など 50 ビジネス目標を共有、「失敗しない」データマネジメント組織の設計とは :https://xtech.nikkei.com/atcl/nxt/column/18/02358/031400004/ 
 

発展的なデータ活用に向けた展望 ● LLMエージェントを活用した自然言語によるクエリ自動生成ツールの作成 （社内のエンジニアが開発したLLMエージェントを転用させていただく） ○ SQLに関する知識が浅い利用者でも集計結果を得られる ○ RAGで参照するためのメタデータ管理の見直し 51 入力：施策Aによる指標Bに 　　　対する効果を分析したい 出力：集計に利用したクエリと 　　　実行した結果はこちら 正確なメタデータを付与・管理 利用者が増える中でのニーズに合わせて...