嗚呼、当時の本番環境の状態で AI Agentを再評価したいなぁ... / / Ah, I wish I could re-evaluate the AI ​​Agent in the production environment it was in back then...

第16回 Data-Centric AI勉強会 https://dcai-jp.connpass.com/event/372441/ の登壇資料です。

@po3rin との共同発表で、同じ資料を @po3rin のアカウントでアップロードしています。
シェアする場合、こちらのリンクを使用してください。
https://speakerdeck.com/po3rin/wu-hu-dang-shi-noben-fan-huan-jing-nozhuang-tai-de-ai-agentwozai-ping-jia-sitainaa-dot-dot-dot

Transcript

1. 嗚呼、当時の本番環境の状態で AI Agentを再評価したいなぁ ... 第16回 Data-Centric AI勉強会
3. © LayerX Inc. 3 バクラク事業部 BizOps部 データグループ TechLead 兼 Platform Engineering部 SRE Snowflake Squad 2025 Snowflake九州ユーザー会 主宰 SNS 𝕏 civitaspo civitaspo その他 画像を⼊れてね civitaspo （ｷﾋﾞﾀｽﾎﾟ/ きびちゃん） ⾃⼰紹介
4. 会社紹介
5. © LayerX Inc. 5 会社紹介 すべての経済活動を、 デジタル化する。 Mission ⼈類の未来をより良くする。 そのために私たちは、テクノロジーの可能性を探求し、 経済活動における複雑で⼤きな課題に挑む。 仕事や暮らしの中にある摩擦が解消され、 それぞれの創造⼒が発揮されている。 そんな希望あふれる優しいデジタル社会を、 未来に残していくために。
6. © LayerX Inc. 6 会社紹介 出典: シリーズBで150億円を調達。エンジニアの採⽤を強化し、AIエージェント事業をさらに加速 / ニュース / 株式会社LayerX
7. © LayerX Inc. 7 会社紹介 ⾦融基盤AI-DX エンタープライズ向け AIプラットフォーム コーポレートAI-SaaS Fintech事業 Ai Workforce事業 バクラク事業
8. バクラクの⽬指す世界と、信念
9. © LayerX Inc.　 9 バクラクの事業領域 Coming Soon AIエージェント HCM領域 稟議・ワークフロー 領域 BSM / ARM領域 Payment 領域 Coming Soon
12. ☀ Bassemer Venture Partners曰く 基礎モデルのパフォーマンスが収束するにつれ、真の差別化要因は単なる精度で はなく、モデルが環境内でどのように、いつ、そしてなぜ機能するかを正確に把握す ることになるでしょう。評価をスケーラブルで説明可能、そしてエンタープライズ対応 にできるスタートアップこそが、AI導入の次の波を切り開き、インフラの新たなフロン ティアを定義するでしょう。 https://www.bvp.com/atlas/the-state-of-ai-2025
13. AI申請レビューの過去データを使った評価
14. 🙌 AI Agentの過去データを使ったバックテスト基盤が欲しい 🛠 Dev: AI Agent機能の実験/評価がはかどる 👔 Sales: 提案に使える(この機能を導入すると一ヶ月で差し戻しがN件減ります) 󰠀 User: 自分で設定したAI Agent機能の効果をチェックできる 🤖 Agent: 自分で作ったレビュールールをチェックし、自己修復を回せるようになる。 Data-CentricにAI Agentの精度を改善し、ビジネスも改善していく基盤が欲しい！
15. 😭 過去データなんてない！！ AI時代が到達する以前、特にB2B SaaSでは過去のデータにアクセスできることは重要な機能 ではありませんでした(一体誰が過去の差し戻された時点の申請をもう一度見たいと思うでしょ うか？)。
16. しかしAI時代の到来によりこの当たり前は大きく変わりました。 今ではユーザー自身が過去のデータを使い、ユーザーが設定した AI Agentを 評価する時代です。
17. 😭 過去データにアクセスできる状態にしなくては！！！
18. Snowflakeで 過去のデータベースの状態へ アクセスする
19. © LayerX Inc. 19 通常のテーブルアクセス スナップショット機能のインターフェース mysql_sample_dbデータベースのsample_tableテーブルをSnowflakeに格納したと仮定
20. © LayerX Inc. 20 スナップショット取得アクセス スナップショット機能のインターフェース 通常のテーブルアクセスに、取得したい時点の情報を与えて呼び出す。
21. © LayerX Inc. 21 • UDFの⼀種で、表形式のデータを返却できる機能 • BigQueryやDatabricksではTable Functions、またはTable-valued function (TVF) と呼ばれる。 補⾜: Tabular SQL UDFs (UDTFs) スナップショット機能のインターフェース 出典: Tabular SQL UDFs (UDTFs) | Snowflake Documentation 出典: Table functions | BigQuery | Google Cloud Documentation 出典: Table-valued function (TVF) invocation | Databricks on AWS
22. おことわり
23. © LayerX Inc. 23 • ここからcivitaspoのパートでは、スナップショット取得機能のみにフォーカスしてお話します。 Data-Centric AIというかデータ基盤な話になるのをご容赦ください。 • DWHソリューションとしてSnowflakeを利⽤している前提で書いています。BigQueryなど他のソ リューション向けにも補⾜をしますが、⾜りなければ質問してください。 • 『AI Agentのビジネス価値を計るバックテスト基盤の構築』を⽀えるSnowflake上での任意時点の スナップショット取得を実現するデータパイプライン - LayerX エンジニアブログ にて弊社の事例を 書きましたが、本スライドでは理解を促すために⼀部簡略化して説明しています。 おことわり
24. スナップショット取得機能で使⽤する データソース
25. © LayerX Inc. 25 • MySQLのテーブルを定期的にフルダンプしたデータ • MySQLのChange Data Capture 2種類のデータソースを使⽤する スナップショット取得機能で使⽤するデータソース
26. © LayerX Inc. 26 • Aurora Cluster ExportでS3にParquetとして定期的にフルダンプ • S3上のParquetファイルをSnowflakeからExternal Tableとして参照 MySQLのテーブルを定期的にフルダンプしたデータ スナップショット取得機能で使⽤するデータソース 参考: Aurora Cluster Exportで出⼒したデータをdbtを使ってSnowflakeへImportする - LayerX エンジニアブログ
27. © LayerX Inc. 27 • AWSのAuroraが持つ機能。 • データベースに負荷をかけることなくS3へ全データをフルダンプできる。 • Aurora MySQLだけでなく、Aurora PostgreSQLでも出⼒可能。 • 出⼒されるデータはParquetに変換される。 ◦ 型マッピング: Considerations for DB cluster snapshot exports - Amazon Aurora 補⾜: Aurora Cluster Export スナップショット取得機能で使⽤するデータソース 参考: Exporting DB cluster data to Amazon S3 - Amazon Aurora
28. © LayerX Inc. 28 • Debeziumを使って、MySQLのbinlogからCDCを取得 • 取得したCDCはManaged Streaming for Apache Kafkaを経由してSnowflakeへ • 平均約1分程度の遅延でSnowflakeに格納される MySQLのChange Data Capture（CDC） スナップショット取得機能で使⽤するデータソース 参考: 『AI Agentのビジネス価値を計るバックテスト基盤の構築』を⽀えるSnowflake上での任意時点のスナップショット取得を実現するデータパイプライン - LayerX エンジニアブログ
29. © LayerX Inc. 29 • 様々なデータベースからCDCを取得するOSS ◦ MySQLの場合は binlog から ◦ PostgreSQLの場合は WAL から • Kafka Connectを使⽤している場合は Exactly-Once Semantics で動作させることが 可能なため、重複や⽋損なくデータを Kafka に吸い出せる。 • 内部的には、binlog のファイル名とpos/row をKafka Connectのメモリ上で管理し、毎回確 認することで重複‧⽋損を防いでいる。 補⾜: Debezium スナップショット取得機能で使⽤するデータソース 参考: Debezium
30. © LayerX Inc. 30 • SnowflakeでStreaming Data Ingestionを実現する機能 • 2025/09/23にV2がGAし、テーブルあたり10GB/sのスループットが出る • 書き込みから読み出せるようになるまで5~10秒程度 補⾜: Snowpipe Streaming V2 スナップショット取得機能で使⽤するデータソース 参考: https://docs.snowflake.com/en/user-guide/snowpipe-streaming/snowpipe-streaming-high-performance-overview
31. スナップショット取得機能における データ処理の仕組み
32. © LayerX Inc. 32 おさらい: スナップショット取得時は取得したい時間が与えられる スナップショット取得機能におけるデータ処理の仕組み
33. © LayerX Inc. 33 取得したい時間 スナップショット取得機能におけるデータ処理の仕組み 2025-11-12 18:54:11
34. © LayerX Inc. 34 取得したい時刻に最も近い過去のフルダンプを取得 スナップショット取得機能におけるデータ処理の仕組み 2025-11-12 03:00:00 2025-11-13 03:00:00 2025-11-12 18:54:11
35. © LayerX Inc. 35 • 条件に合致する⼀番近しいレコードとJOINするための構⽂ • 今回の例では単⼀の時点を与えられる想定だが、複数の時点を与えられ、それぞれの時点に最も近 い過去のスナップショットを取得するっと⾔った要件だった場合、ASOF JOINでの取得が効率良い 補⾜: ASOF JOIN スナップショット取得機能におけるデータ処理の仕組み 参考: ASOF JOIN | Snowflake Documentation
36. © LayerX Inc. 36 フルダンプを取得した時間から取得したい時間までのCDCを取得 スナップショット取得機能におけるデータ処理の仕組み 2025-11-12 18:54:11 {"op" :"c", "updated_at": "2025-11-12 03:11:00", "record": {"id": 5, "name": "taro", ...}} {"op" :"u", "updated_at": "2025-11-12 04:11:00", "record": {"id": 2, "name": "jiro-x", ...}} {"op" :"c", "updated_at": "2025-11-12 04:11:00", "record": {"id": 6, "name": "saburo", ...}} {"op" :"u", "updated_at": "2025-11-12 05:11:00", "record": {"id": 6, "name": "saburo-x", ...}} {"op" :"u", "updated_at": "2025-11-12 06:11:00", "record": {"id": 1, "name": "shiro-x", ...}} {"op" :"d", "updated_at": "2025-11-12 07:11:00", "record": {"id": 1, "name": "shiro-x", ...}} {"op" :"c", "updated_at": "2025-11-12 08:11:00", "record": {"id": 7, "name": "goro", ...}} {"op" :"d", "updated_at": "2025-11-12 09:11:00", "record": {"id": 7, "name": "goro", ...}} {"op" :"c", "updated_at": "2025-11-12 10:11:00", "record": {"id": 8, "name": "rokuro", ...}} {"op" :"u", "updated_at": "2025-11-12 11:11:00", "record": {"id": 8, "name": "rokuro-x", ...}} {"op" :"d", "updated_at": "2025-11-12 12:11:00", "record": {"id": 8, "name": "rokuro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 13:11:00", "record": {"id": 3, "name": "nanakuro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 14:11:00", "record": {"id": 3, "name": "nanakuro", ...}}
37. © LayerX Inc. 37 CDCデータをプライマリーキーに対して最新のレコードだけ取得 スナップショット取得機能におけるデータ処理の仕組み 2025-11-12 18:54:11 {"op" :"c", "updated_at": "2025-11-12 03:11:00", "record": {"id": 5, "name": "taro", ...}} {"op" :"u", "updated_at": "2025-11-12 04:11:00", "record": {"id": 2, "name": "jiro-x", ...}} {"op" :"c", "updated_at": "2025-11-12 04:11:00", "record": {"id": 6, "name": "saburo", ...}} {"op" :"u", "updated_at": "2025-11-12 05:11:00", "record": {"id": 6, "name": "saburo-x", ...}} {"op" :"u", "updated_at": "2025-11-12 06:11:00", "record": {"id": 1, "name": "shiro-x", ...}} {"op" :"d", "updated_at": "2025-11-12 07:11:00", "record": {"id": 1, "name": "shiro-x", ...}} {"op" :"c", "updated_at": "2025-11-12 08:11:00", "record": {"id": 7, "name": "goro", ...}} {"op" :"d", "updated_at": "2025-11-12 09:11:00", "record": {"id": 7, "name": "goro", ...}} {"op" :"c", "updated_at": "2025-11-12 10:11:00", "record": {"id": 8, "name": "rokuro", ...}} {"op" :"u", "updated_at": "2025-11-12 11:11:00", "record": {"id": 8, "name": "rokuro-x", ...}} {"op" :"d", "updated_at": "2025-11-12 12:11:00", "record": {"id": 8, "name": "rokuro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 13:11:00", "record": {"id": 3, "name": "nanakuro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 14:11:00", "record": {"id": 3, "name": "nanakuro", ...}}
38. © LayerX Inc. 38 • Window関数を条件にフィルタリングすると きにQUALIFY句を使⽤する。 • 重複排除の⽂脈でrow_number() と⽤いられ ることが多い。 補⾜: QUALIFY 1 = ROW_NUMBER() OVER ( PARTITION BY pk ORDER BY updated_at DESC ) スナップショット取得機能におけるデータ処理の仕組み 参考: QUALIFY | Snowflake Documentation
39. © LayerX Inc. 39 CDCデータを作成‧更新‧削除に分解 スナップショット取得機能におけるデータ処理の仕組み 2025-11-12 18:54:11 {"op" :"c", "updated_at": "2025-11-12 03:11:00", "record": {"id": 5, "name": "taro", ...}} {"op" :"u", "updated_at": "2025-11-12 04:11:00", "record": {"id": 2, "name": "jiro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 05:11:00", "record": {"id": 6, "name": "saburo-x", ...}} {"op" :"d", "updated_at": "2025-11-12 07:11:00", "record": {"id": 1, "name": "shiro-x", ...}} {"op" :"d", "updated_at": "2025-11-12 09:11:00", "record": {"id": 7, "name": "goro", ...}} {"op" :"d", "updated_at": "2025-11-12 12:11:00", "record": {"id": 8, "name": "rokuro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 14:11:00", "record": {"id": 3, "name": "nanakuro", ...}}
40. © LayerX Inc. 40 フルダンプデータから更新‧削除レコードをanti-join スナップショット取得機能におけるデータ処理の仕組み {"op" :"u", "updated_at": "2025-11-12 04:11:00", "record": {"id": 2, "name": "jiro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 05:11:00", "record": {"id": 6, "name": "saburo-x", ...}} {"op" :"d", "updated_at": "2025-11-12 07:11:00", "record": {"id": 1, "name": "shiro-x", ...}} {"op" :"d", "updated_at": "2025-11-12 09:11:00", "record": {"id": 7, "name": "goro", ...}} {"op" :"d", "updated_at": "2025-11-12 12:11:00", "record": {"id": 8, "name": "rokuro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 14:11:00", "record": {"id": 3, "name": "nanakuro", ...}} 2025-11-12 03:00:00
41. © LayerX Inc. 41 • JOIN対象と紐づかなかったデータ集合を取得する⼿法。様々な記法がある。 補⾜: ANTI-JOIN スナップショット取得機能におけるデータ処理の仕組み
42. © LayerX Inc. 42 残ったデータに作成‧更新レコードをunion スナップショット取得機能におけるデータ処理の仕組み 2025-11-12 03:00:00 {"op" :"c", "updated_at": "2025-11-12 03:11:00", "record": {"id": 5, "name": "taro", ...}} {"op" :"u", "updated_at": "2025-11-12 04:11:00", "record": {"id": 2, "name": "jiro-x", ...}} {"op" :"u", "updated_at": "2025-11-12 05:11:00", "record": {"id": 6, "name": "saburo-x", ...}} {"op" :"u", "updated_at": "2025-11-12 14:11:00", "record": {"id": 3, "name": "nanakuro", ...}}
43. 完成形
44. © LayerX Inc. 44 ⻑くて貼れない... 完成形
45. © LayerX Inc. 45 完成形はWebで読んでください☺ 完成形 参考: 『AI Agentのビジネス価値を計るバックテスト基盤の構築』を⽀えるSnowflake上での任意時点のスナップショット取得を実現するデータパイプライン - LayerX エンジニアブログ
46. AI Agent評価基盤の構築
47. 🙌 過去データにアクセスできるようになったぞ！！ しかし、データがあるだけでは。。。
48. AI申請レビューは内部でサービスのAPIに依存している。APIを叩いた先に は最新データしか入ってない。 申請管理API テナント管理API AI申請レビューAgent アプリケーションDB(最新データのみ) 😭 AI Agentバックテストの難しさ
49. 😭 AI Agentバックテストの難しさ 依存データ取得先をSnowflakeで丸々入れ替えると、APIでやっていたデー タの前後処理を丸々Agent側に移植しないといけない AI申請レビューAgent APIでやっていたデータの前後処理を 全てSnowflakeのクエリで再現していくの？ データが一致しているかをどうテストするの？ 🤔
50. 😭 AI Agentバックテストの難しさ API経由ならデータ処理も含めることができる。けど、サービスAPIにSnowflake 切り替え機構を入れるの？クエリビルダーから変更になるひとに、Snapshot日 付指定パラメータを伝搬させる処理も必要がある。結構大きな工事だなぁ。。。 申請管理API テナント管理API AI申請レビューAgent
51. 🤔APIの実装をほとんど変えずに API内部処理に Snowflake切り替え&日付指定を 差し込めないか？
52. 🛠 自作GORM Plugin！！
53. *gorm.DB.Callbackでクエリ前に処理を差し込める。
54. ❄ Firn Firn（フィルン）とは、積もった雪が長期間経っても溶けずに残った、雪と氷の中間段階の積雪層です。雪の結晶同士の隙間（空隙）が完全には閉じて いない状態を指し、国立極地研究所の研究では極地の氷床形成過程で重要な役割を果たすほか、過去の大気組成を復元するための情報源としても 活用されています。 社内GORM Pluginパッケージ「Firn」を作った！ 🤖 LLMを使用したSQL自動変換 📅 特定日付時点のスナップショットデータへの透過的なアクセス 🔌 GORMプラグインとしてのシームレスな統合 🛡 クエリガード機能によるセキュリティ保護
55. ❄ Firn これだけで、LLMが内部で対象日付を使って SQLをSnapshotクエリに書き換える。 DBクライアント初期化にこれをかますだけで、 APIの他のコード変更は一切不要。
56. なぜLLMでSQLを書き換えるのか * 最初はSQLパーサーでクエリを決定論的に書き換える方法を試した。 * 実装が難しいかつ非常に複雑なロジックになってしまった。 * LLMを使う最大のネックはパフォーマンスですが、この機能はバッチテスト前提であり、即座にレ スポンスが欲しいものではない。 * そのためLLMベースの書き換えに方向転換。
57. Firnでgorm.DB差し替え gorm.DBを差し替えるだけで、アプリケーションDBとSnowflakeの向き先を差し 替え、LLMで初期化時に渡した対象日付でクエリを書き換える 申請管理API テナント管理API AI申請レビューAgent Snapshot アプリケーションDB(最新データのみ) ❄ Firnで切り替え
58. バックテストできたよ！！
59. 🤔今回の実装は既存 AI Agentを評価するための 基盤作りで非常に苦労した 最初から評価を入れやすい=AI Agentを改善しやすいシステムとして開発すべ き。ではどういう設計ならよかったのか...
60. どういう設計が理想だったか
61. 🐤 AI Agentに渡すAPI Toolは既存のサービス APIを気軽に流用しない 普通に作ると、APIはリソース指向の設計になり、フロントエンドが柔軟にリソースをフェッチで きる仕組みになっています。 しかし、まとまったデータを得るためには段階的な複数回のAPI呼び出しを行うことになりま す。そうなるとAI Agentがコンテキストを集めるために、多くのAPIに依存することになります。
62. 🐓 Workflow Toolとして実装する 理想としては、必要なコンテキストを揃えるた めのtoolをリソース志向APIではなく、一回の 呼び出しで全てのコンテキストを取得できるよ うな Workflow Tool として用意すべきです。 https://www.anthropic.com/engineering/writing-tools-for-agents > 評価タスクに適した、影響の大きい特定のワークフ ローを対象とした、思慮深いツールをいくつか構築し、 そこからスケールアップしていくことをお勧めします。 by Anthropic
63. 🐓 最初からツールが過去のデータにアクセスできる設計にしておく 案 • 今回の実装が難しかった要因の一つはアプリケーションDBが最新のデータしか持ってい ないという点でした。 • 評価機能をユーザーに提供する場合、本番アプリケーションがデータ基盤に依存すること になりリバースETLによるデータの同期管理の複雑さが発生します。 • このような問題を回避するために取れる設計として、任意の時点のデータを再現するよう なテーブルをアプリケーションDBに持ち、ツールでアクセスできるように最初からしておく 方法も検討できます。
64. 🐓 まとめると • Workflow Toolを実装し、アプリケーションが保存するCDCデータから過去の状態のデータを再 現できるようなものにできると良いでしょう。ただこれだと、CDCデータの保存に膨大なコストが かかり、Workflow Toolの実装に時間がかかります。 • ビジネスに要求される速度とのトレードオフを考え、サービスにとって最適なバランスをとりま しょう。
65. 🐓 データセットをユーザー側で DBにロードできるようにしておく (1) 一方で全てのデータをアプリケーション DB側に保持しなくても、評価に必要なデータだけをアプリ ケーション DBに移しておくという方法 もあります。これはユーザーにAgentを評価する機能を提供した い場合に有用なパターンです。
66. 🐓 データセットをユーザー側で DBにロードできるようにしておく (2) この方式をとっているのが、カスタマー サービス向けAIサービスのFinであり、 Finではデータセットという単位で最大 50件のデータを読み込み、評価に利 用できる機能をユーザーに提供してい ます。 https://fin.ai/
67. 🐓 データセットをユーザー側で DBにロードできるようにしておく (3) • これであればCDCで全ての過去 データを保存するコストを抑えた上 で、評価に必要なデータだけを利 用できるというバランスの取れた構 成になります。 • デメリットとして、開発者がAI Agent を大きなデータで評価したい場合 は毎回必要なデータをDBに読み 込む
68. ☀ まとめ • AI Agentを育てるための、評価基盤構築は難しいよ！ • 過去データを取れるように基盤作りをしよう！ • 評価を回せるようなアーキテクチャの上に AI Agentを載せよう！
69. ブログでも今回の話を紹介してます！ https://tech.layerx.co.jp/entry/2025/10/30/085410 https://tech.layerx.co.jp/entry/snowflake-user-defined-timetravel-udtf-with-cdc-pipeline AI Agentブログリレーやってます！！今42日目！！
70. LayerXではBet AIするデータエンジニア、 MLエンジニア、 AIエ ンジニアを超絶募集中！！
71. © LayerX Inc. 71 • LayerXでは、⼀緒にデータ基盤、AI Agent基盤、ML基盤を作る仲間を⼤募集しています！！！ • 興味を持たれた⽅は是⾮ jobs.layerx.co.jp へアクセスしてください！！！ We are hiring!!! おわりに 【バクラク】データエンジニア 【バクラク】ソフトウェアエンジニア_AI-UX 【バクラク】MLOpsエンジニア 【バクラク】エンジニアリングマネージャー_AI‧機械学習領域
72. 技術書典で本出します！
73. A嗚呼、当時の本番環境の状態で AI Agentを再評価したいなぁ ... golang.tokyo #41 / pon