LayerX エンジニアブログ

LayerX の エンジニアブログです。

AI Agentのビジネス価値を計るバックテスト基盤の構築

AI Agent Snowflake MLOps LLM Python Go

こちらはLayerX AI Agentブログリレー36日目の記事です。

LayerX バクラク事業部で AI/MLOpsエンジニアをしている中村(@po3rin)です。今回はAI Agentのビジネス価値を計るバックテスト基盤を構築した話と、そこから学んだAI Agent開発のプラクティスを紹介します。

目次

AI Agent機能の評価の重要性

AI Agent機能をサービスに導入するボトルネックの一つは「評価」です。工数をたっぷりかけて作ったAI Agent機能は、あなたのサービスのユーザーを満足させているでしょうか？AI Agentは期待通りのビジネス価値を出しているでしょうか？

Bessemer Venture Partnersが出している「The State of AI 2025」でも、「Evals and data lineage will become a critical catalyst for AI product development」のセクションで評価の重要性について語られています。

www.bvp.com

基礎モデルのパフォーマンスが収束するにつれ、真の差別化要因は単なる精度ではなく、モデルが環境内でどのように、いつ、そしてなぜ機能するかを正確に把握することになるでしょう。評価をスケーラブルで説明可能、そしてエンタープライズ対応にできるスタートアップこそが、AI導入の次の波を切り開き、インフラの新たなフロンティアを定義するでしょう。

LayerXでもAI Agent機能の評価基盤はビジネスを成功させる重要な基盤と捉えており、その開発に邁進しております。

AI Agent機能のバックテスト

AI Agent機能の評価方法の中でもバックテストは重要な基盤です。バックテストとは過去のデータでシステムを検証することを指します。バックテストとは数理ファイナンスでよく使われる言葉です。

バックテストとは、モデリングにおいて、予測モデルを過去のデータを用いて検証することを指す用語です。バックテストは、過去の期間に適用されるクロスバリデーションの一種であり、遡及分析の一種です。定量金融において、バックテストは、アルゴリズム戦略を実際の市場で展開する前の重要なステップです。

AI Agentのバックテストがステークホルダーにとってどのように有用かを紹介していきます。

1: 開発者

バックテストは実験に利用でき、AI Agentの精度向上を進めることができます。例えば、「LLMモデルを変えた場合、お客様にどのような影響が出る？」というような評価が可能になります。また、新規開発の際にも、ユーザーに影響を与えることなく、ユーザーの過去のデータで実験をすることが可能になります。

2: 営業

お客様への提案に使える情報を取得できます。例えば、申請の内容をチェックするAI Agentの場合、「この機能を導入するとN件の差し戻しが減ります。」と言ったビジネス価値に近い提案が可能になります。

特に我々のようなB2B SaaSですでに契約済みのお客様に新機能として提案する場合はこのようなバックテストができると価値を感じてもらいやすいです。

例えばLayerXのサービス「バクラク」のAI申請レビュー機能があります。

bakuraku.jp

AI申請レビューの場合は次のようなお客様のビジネス的な価値に沿ったメリットを提供できます。

  • この機能で、過去半年で発生した差し戻しをいくつ減らせるか
  • この機能で、差し戻しから承認までに削減できる時間的工数

3: カスタマーサクセス

顧客の分析にも利用できます。B2B SaaSの場合であれば、その分析により顧客を成功に導く機能開発や、設定の提案が行えるようになります。例えば、「このようなAI Agentの設定はいかがでしょうか？この設定で差し戻しが何件減ります」という提案ができるようになります。

4: サービスユーザー

自分で作った設定で、自分でAI Agentの機能を確認できるようになります。実際にカスタマーサービス向けAIサービスのFinでは、ユーザーが自分たちの過去データをアップロードして、AI Agentを評価、改善する機能があります。Finのユーザーが回せるテスト機能に関しては後で詳しく紹介します。

fin.ai

このようにAI Agentのカスタマイズをサービスに組み込む場合は、ユーザが自分たちの過去のデータに対して評価を回せるようにしておくことが有用です。

5: AI Agent

AI Agentが自分で評価を行い、自己修復を回せるようになります。例えば申請の内容をチェックするAI Agentであれば、ユーザーの過去の申請に対して、評価を回すパイプラインを作ることでAI Agentが自ら修正したプロンプトを自信を持って採用することができるようになります。

このようにバックテストは各ステークホルダーにとって多くのメリットがあります。

バックテスト基盤開発の難しさ

バックテスト基盤の開発には多くの壁があります。特にAI Agentが既存サービスのAPIを利用している際には非常に困難になります。

例えばLayerXのAI申請レビュー機能では次のようにAI Agentが複数の既存サービスAPIに依存しています。既存サービスAPIを叩くことで、AI Agentが使うコンテキストを取得しています(AI申請レビューの例だと申請データや組織データなどを取得する)。しかし、APIではユーザーの最新のデータしか持っていないので、このままでは過去データを使ったAI Agentのバックテストが出来ません。

最初に思い浮かぶ解決策は、次のようにSnowflakeにあるSnapshotデータに直でアクセスする手法でAPIを置き換えることです。しかし、この手法ではAPI内部のデータの処理ロジックが再現できません。

SnowflakeへのクエリでAPI内で行なっているデータの前処理、後処理も含めて再現するのは困難です。API内ではパラメータによってQuery Builderが複数に分岐しており、それらをまとめて挙動をSnowflakeへのクエリで再現するのはかなりの工数がかかります。

それではAPIを通してSnowflakeにアクセスするのはどうでしょうか？この場合はAPIのロジックも再現でき、SnowflakeのSnapshotデータにもアクセスができます。

上の問題は既存APIに大きな変更が発生する点です。

  • APIのQuery Builder実装に大きな変更が入る
  • 過去データの日時指定パラメータをAPIの中で伝搬していく変更が入る

コードに対する変更に関しては、力でなんとかなりますが、依存しているAPIが多い場合、変更が広範囲にわたります。弊社のAI申請レビューAgentでは既存の3サービスを跨いで合計10本以上のエンドポイントを叩いていたので、影響範囲も大きいです。これではバックテスト機能をリリースできるのは数ヶ月後になってしまうでしょう。

このような問題があるため、既存サービスのAPIに依存したAI Agentのバックテスト基盤の構築は非常に難しいことが分かります。

バックテスト基盤を実現する技術

ではどのようにバックテスト基盤を構築すると良いでしょうか？今回は私がこの難題に立ち向かう際に採用した技術や考え方を紹介します。

全体構成

Pythonで実装されているAI申請レビューは依存API(Goで作られたサービスで、gormというORマッパー使ってRDBにアクセスしている)の内部を「❄️Firn」という社内GORM Pluginでデータ取得処理をスナップショット取得処理に置き換えています。このFirnについては後に詳しく紹介しますが、渡すgorm.DB構造体を変更するだけで、APIの実装を一切変更せずにSnowflakeのSnapshot切り替えを実現する優れものです(ちなみにWrite系は未サポートです)。

そして今回の実装ではAPI内のGORMのバージョンがv1とv2で混ざっていましたのも課題でした。そこでgormgoldenというOSSを作成し、SQLベースでのgolden testを行い、GORM v1からv2への移行を行いました。

それでは一つ一つの技術について解説します。

SnowflakeへのSnapshotデータアクセス

LayerXではデータ基盤としてSnowflakeを採用しています。SnapshotデータにアクセスするためにはアプリケーションDBにアクセスしていたクエリを少し変えるだけです。例えば、2025/10/21 9時時点のSnapshotデータにアクセスする場合は次のようになります。

# 通常クエリ
SELECT * FROM SAMPLE_TABLE;

#Snapshotクエリ
SELECT * FROM TABLE(SAMPLE_TABLE('2025-10-21 09:00:00.000 +0900'::timestamp_tz));

テーブル名と同じ関数定義をしており、内部でSnapshotデータへのアクセスをしています。その結果をTABLE関数で変換しています。

この内部の仕組みの詳細に関しては明日のAI Agentブログリレーで紹介します。

LLM Native GORM Plugin「Firn」

今回のバックテスト実装にあたり、Firnという社内OSSを作成しました。Firnには次の機能があります。

  • 🤖 LLM（Azure OpenAI）を使用したSQL自動変換
  • 📅 特定日付時点のSnapshotデータへの透過的なアクセス
  • 🔌 GORMプラグインとしてのシームレスな統合
  • 🛡️ クエリガード機能によるセキュリティ保護

ちなみにFirnという単語は次のような意味があります。

Firn（フィルン）とは、積もった雪が長期間経っても溶けずに残った、雪と氷の中間段階の積雪層です。雪の結晶同士の隙間（空隙）が完全には閉じていない状態を指し、国立極地研究所の研究では極地の氷床形成過程で重要な役割を果たすほか、過去の大気組成を復元するための情報源としても活用されています。

Firn内部ではLLMを使ってMySQLへのクエリを指定日付含めたSnowflake Snapshot用のクエリに書き換え、向き先をSnowfakeに変換します。

変換前:

SELECT * FROM XXX LIMIT 10

変換後:

SELECT * FROM table(XXX('2025-10-21 02:12:39.123 +0900'::timestamp_tz)) LIMIT 10

Firnがすごいのはgorm.DBを変えるだけで、他のコードに触ることなく、処理を丸々切り替えれることです。SQLを生成するコードをif文で差し替えることなく、更に日付指定を引数やコンテキストとして引き回す修正をAPIに加えることなく、その日付時点で返すデータをAPI丸ごと再現できます。

Firnは次のように利用します。*gorm.DB.Useメソッドでプラグインを登録し、クエリ実行前にクエリをLLMでSnapshot用クエリに変換します。

package main

import (
    "time"
    "github.com/XXXXX/firn" // 社内OSS
    "github.com/snowflakedb/gosnowflake"
)

func main() {
    // Snowflake DBの作成
    db, _ := firn.SnowflakeDB(gosnowflake.Config{...})

    // LLM設定
    llmConfig := firn.LLMConfig{...}

    //Snapshot日付の指定
    targetDate := time.Date(2025, 3, 29, 0, 0, 0, 0, time.UTC)

    //Snapshotプラグインを適用
    db, _ = firn.NewSnapshotDB(db, llmConfig, targetDate)

    // 通常のGORMクエリを自動的にSnapshotクエリに変換
    var result []map[string]interface{}
    err = db.Table("your_table").Limit(10).Find(&result).Error
    // ...
}

なぜLLMで書き換えるのか

最初はSQLパーサーでクエリを決定論的に書き換える方法を試しましたが、地味に実装が難しいかつ非常に複雑なロジックになってしまったので、LLMベースの書き換えに方向転換しました。

特に難しかったのは次の点です。

  • MySQLの方言をSnowflakeにきっちり変換しなくてはいけない
  • メインのポイントのTable関数、プロシージャが上手くパースできない
  • テーブル名が他のところで参照されている場合、AS句でテーブルエイリアスを別途追加しなくてはいけない。

頑張ればいけないこともなさそうですが、「ここまで来たらLLMに任せた方が実装もシンプルになるし良いのでは？」と考え、LLMを使うことにしました。

LLMを使う最大のネックはパフォーマンスですが、この機能はバッチテスト前提であり、即座にレスポンスが欲しいものではありません。そもそもバックテストのボトルネックはクエリ変換ではなく、SnowflakeへのSnapshot取得部分なので早くするならまずはSnapshot取得部分です。そのためいま今ではLLMのパフォーマンスが大きな問題ではないため、LLMを採用しています。

GORM Pluginの作り方

GORM Pluginの作り方も簡単に紹介しておきます。GROMにはプラグイン機構があり、簡単に独自プラグインを差し込めます。次はFirnの内部処理をシンプルにした例です。

type SnapshotPlugin struct {
    targetDate time.Time
    llmClient     *SQLTransformer
}

// NewSnapshotLLMPlugin creates a new SnapshotLLMPlugin with the specified target date
func NewSnapshotPlugin(llmClient *SQLTransformer, targetDate time.Time) (*SnapshotPlugin, error) {
    return &SnapshotPlugin{targetDate: targetDate, llmClient: llmClient}, nil
}

func (p *SnapshotPlugin) Name() string {
    return "SnapshotPlugin"
}

func (p *SnapshotPlugin) Initialize(db *gorm.DB) error {
    // Use Replace instead of Before to handle the full query transformation
    return db.Callback().Query().Replace("gorm:query", p.queryWithSnapshotTransform); err != nil {
        return fmt.Errorf("failed to replace query callback: %w", err)
    }
}

// queryWithSnapshotTransform - Queryコールバックの置き換え処理
func (p *SnapshotPlugin) queryWithSnapshotTransform(db *gorm.DB) {
    if db.Error == nil {
        // SQLをビルド
        callbacks.BuildQuerySQL(db)

        // Snapshot変換を適用
        if err := p.llmClient.Transform(db); err != nil {
            db.AddError(err)
            return
        }

        // クエリ実行
        sql := db.ToSQL(func(tx *gorm.DB) *gorm.DB {
            return tx
        })

        rows, _ := db.Statement.ConnPool.QueryContext(db.Statement.Context, sql)
        defer func() {
            db.AddError(rows.Close())
        }()
        gorm.Scan(rows, db, 0)
     
    }
}

ちなみに任意のGORM Pluginを作るのに必要なインターフェースのメソッドは二つだけです。なんて美しいのでしょうか。

type Plugin interface {
    Name() string
    Initialize(*DB) error
}

Initialize内でコールバックを設定できます。上の例ではquery時にp.queryWithSnapshotTransformが発火するようになっています。その中でLLMによるクエリの書き換えを行います。

このプラグイン構造体をgorm.DB.Useメソッドに渡せばGORMの処理全てにコールバックを挟むことができます。

// dbの型は*gorm.DB

snapshotPlugin, _= NewSnapshotPlugin(llmClient, targetDate)
db.Use(snapshotPlugin)

これだけで、向先をSnowflakeに変更した上でSnapshotデータの所得クエリに変換できます。

LLMによるクエリ書き換え部分

LLMによるSQL生成は日頃研究が進んでいるタスクであり、特に自然言語からSQLを生成するText2SQLはホットな話題です。例えばSnowflake AI Researchが出してるArctic-Text2SQL-R1はGRPO+シンプルな報酬モデルで7BでGPT-4oを超える結果を出しています。非常に面白い論文です。

arxiv.org

しかし、今回はSQLのシンプルな書き換えです。少しのルールを与えたプロンプト+小さなLLMで十分です。Azure OpenAIのGPT-4o miniを使った実験でも十分な精度(手元で用意したサンプルスイートで100%の精度)であることを確認しています。

実際に使用しているプロンプトはこのようになっています。

You are a SQL transformation expert. Transform MySQL queries to use Snowflake snapshot table procedures.

## About Snowflake Snapshot Table Procedures:
You can use the following procedures to access the snapshot table:
- table(table_a('2025-01-01'::timestamp_tz))

## IMPORTANT:
- Leave the original table name in AS, as there may be other places that refer to this table name.
- Remove ALL backticks from the SQL. Backticks cause errors in Snowflake 
- Return ONLY the transformed SQL without any backticks or markdown formatting
- Do not make any other changes.

## Example:
Original SQL:
SELECT * FROM table_a
Transformed SQL:
SELECT * FROM table(table_a('2025-10-21 02:12:39.123 +0900'::timestamp_tz)) AS table_a

30個のサンプルスイートでの検証では精度100%です。シンプルなSQL2SQLであれば小さなLLMでも十分であることが分かりました。ここまで簡単なタスクだと、SLMも検討に入ってきます。実際に筆者は「deepseek-coder-1.3b-base」のファインチューニング(学習データサイズ300)で、同等の性能が出ることを確認しています。そうすることで、CPU上で学習し、CPU上で動かせるSQL Snapshot変換LLMができました。CPU上で動くので非常に安価に呼び出せます。この話は別日でブログとして出せたらと思います。

LLMのクエリ書き換えガードレール

LLMは確率的な挙動をするため、絶対に書き換えて欲しくない部分をSQL Parserでチェックします。Firnでは任意のガードレール処理を組み込める設計になっています。

guards = [...]
db, _ = firn.NewSnapshotDB(db, llmConfig, targetDate, guards)

例えば、僕が公開しているfilterguardはwhere句にあるカラムがあることをsqlparserを使ってチェックします。決定論的に処理で事故を防ぐことができます。

github.com

SQL BASE Golden Testing Package「gormgolden」

FirnをAPIの実装に組み込んでいく際に壁となったのはGORM v1/v2の混合問題です。LayerXではGORM v2移行が絶賛進行中であり、GORM v1とv2の実装が混ざり合っているのが問題でした。GORM v1/v2は破壊的変更のある大きな変更であり、パッケージのバージョンを上げただけだと、生成されるSQLが変わることが多々あります。そのため結構な工数がかかるため、v2移行が進まず、ボールが落ちている状態でした。

FirnをGORM v1に対応させることもできたのですが、それではGORM v2移行がより進めづらくなります。

一方でLayerXでは「自分のボールを落とさず、落ちているボールを積極的に拾う」という行動指針があります。

https://speakerdeck.com/layerx/compass_202209

LayerX羅針盤「自分のボールを落とさず、落ちているボールを積極的に拾う」

そこで今回は意を決して、AI申請レビューのバックテストに必要な依存APIをGORM v2へ移行することにしました。

GORM v2移行で問題になるのは、SQLが変わっていないか？です。そこでFirnでGORM Plugin実装で得た知見を生かして、SQLベースのgolden testを実装できるgormgoldenというOSSを作成しました。

github.com

gormgoldenはテストに数行挟むだけで、SQLベースのgolden testができます。

package main

import (
    "testing"
    "github.com/po3rin/gormgolden/gormgoldenv2"
)

func TestDatabase(t *testing.T) {
    var db *gorm.DB
    db = setupTestDB() // Your test database setup
    
    // Initialize plugin with golden file path
    plugin := gormgoldenv2.New("testdata/queries.golden.sql")
    db.Use(plugin)
    
    // Run your database operations
    db.Create(&User{Name: "John", Age: 30})
    db.Where("age > ?", 25).Find(&[]User{})
    
    // Assert queries match golden file
    plugin.AssertGolden(t)
}

これでGORMバージョン更新時にクエリが変化していないかなどを確認できるようになります。実際にgormgoldenは社内のGORM v1 -> v2移行で利用しました。このようにGORMプラグインには無限の可能性があります。

gormgoldenでGORMv2に移行し、FirnでAPIの実装をほとんど変更せずにアプリケーションDBへのアクセスをSnowflake Snapshotへ変更することができました。

今回のバックテスト基盤開発のまとめ

ここでもう1度全体像をおさらいしておきましょう。

  • LLM Native GORM Plugin「Firn」により既存API実装を全く変えずに、API内部のロジックも含めたSnapshotデータ取得を達成
  • 「gormgolden」でSQLベースgoleden testを実装を簡易化し、依存APIのGORM v1 -> v2を安全に移行

今回はこのような対応になりました。しかし、これがAI Agent開発をゼロから進める際に目指すべきベストなアーキテクチャなのでしょうか？次の節からは、今回のバックテスト基盤開発を通して学んだAI Agent開発のプラクティスをお伝えします。

バックテスト基盤開発を通して学んだAI Agent基盤のプラクティス

今回のバックテスト基盤開発が難しかったのは、評価する対象が既存APIに依存するAI Agentだったからです。本来はこのような苦労をしなくても良い設計にすべきです。そこで、今回の実装で学んだバックテスト基盤を開発しやすいものにするためのTipsをお伝えします。

筆者が学んだプラクティスは次の2つです。

  • 一回の呼び出しで全てのコンテキストを取得できるようなworkflow tool
  • 最初からツールが過去のデータにアクセスできる設計にしておく

さらにユーザーが評価を行う機能がメインの場合に利用できるプラクティスも紹介します。

  • データセットをユーザー側でDBにロードできるようにしておく

一つずつ説明していきます。

AI Agentに渡すAPI Toolは既存のサービスAPIを気軽に流用しない

既存のAPIをAI Agentのツールとしてそのまま渡す設計は間違っていることがあります。

今回AI申請レビューAgentで依存している参照系APIはリソース指向の設計となっており、フロントエンドアプリケーションが柔軟にリソースをフェッチできる仕組みになっています。しかし、この形のAPIを使うと、段階的な複数回のAPI呼び出しを行うことになります。そうなるとAI Agentのコンテキストを集めるために、多くのAPIに依存することになります。

このような課題があるので、理想としては、必要なコンテキストを揃えるためのtoolをリソース志向APIではなく、一回の呼び出しで全てのコンテキストを取得できるような workflow tool として用意すべきです。

Anthropic の記事 Writing effective tools for agents — with agents でも次のように述べられています。

We recommend building a few thoughtful tools targeting specific high-impact workflows, which match your evaluation tasks and scaling up from there.

評価タスクに適した、影響の大きい特定のワークフローを対象とした、思慮深いツールをいくつか構築し、そこからスケールアップしていくことをお勧めします。

そして既存のAPIがユーザー認証で守られている実装の場合、最初の章で紹介したようなステークホルダーに提供しにくくなります。そのため、AI Agent用に認証を組んだ最適なAPIを用意することが望ましいでしょう。

AI Agent用の認証認可に関しては非常に難しい問題であり、次の記事で弊社の@convtoが考察した内容が記事になっているのでぜひご覧ください。

tech.layerx.co.jp

まとめると、既存サービスAPIを気軽に流用するのではなく、AI Agentに最適な形でAPIを提供できるように設計をすべきです。

最初からツールが過去のデータにアクセスできる設計にしておく

今回の実装が難しかった要因の一つはアプリケーションDBが最新のデータしか持っていないという点でした。また、バックテスト機能をユーザーに提供する場合、本番アプリケーションがデータ基盤に依存することになりリバースETLによるデータの同期管理の複雑さが発生します。

そのため、このような問題を回避するために取れる設計として、CDC(Change Data Capture)により、任意の時点のデータを再現するようなテーブルをアプリケーションDBに持ちツールでアクセスできるように最初からしておく方法もあります。

もし、開発初期の段階でバックテスト機能をユーザーに提供することが見えている場合は、このように最初からDBを持つことが検討されるでしょう。アプリケーションDBに過去データを保存し、ユーザーに早くデータを返せるような構造でデータを持ち、バックテストのレスポンス速度をあげることも重要です。

AI時代が到達する以前、特にB2B SaaSでは過去のデータにアクセスできることは重要な機能ではありませんでした(一体誰が過去の差し戻された時点の申請をもう一度見たいと思うでしょうか？)。しかしAI時代の到来によりこの当たり前は大きく変わりました。今ではユーザー自身が過去のデータを使い、ユーザーが設定したAI Agentを評価する時代です(後述するFinのBatch Test機能が良い例です)。また、AIが過去のデータを使いタスクを実行するために、ツールは過去データへのアクセス機構をしっかり持つべきです。

ここまでのAI Agent基盤のプラクティスまとめ

ここまでをまとめると、本来は次のようにAI Agent専用のworkflow Toolを実装し、アプリケーションが保存するCDCデータから過去の状態のデータを再現できるようなものにできると良いでしょう。

この設計であれば、バックテストも容易でAPI依存も最小限となります。ただこれだと、CDCデータの保存に膨大なコストがかかり、workflow toolの実装に時間がかかります。

ビジネスに要求される速度とのトレードオフを考え、サービスにとって最適なバランスをとりましょう。

今回の私の実装では、すでにAI Agentに各サービスのAPIが深く依存する設計になっており、作り替える場合、大工事になることがわかっていました。AI Agentのバックテスト機能の有用性を探るためにも速度のある開発を行いたかったため、Firnによる既存APIのSnapshot化を決行しました。

データセットをユーザー側でDBにロードできるようにしておく

一方で全てのデータをアプリケーションDB側に保持しなくても、評価に必要なデータだけをアプリケーションDBに移しておくという方法もあります。これはユーザーにAgentを評価する機能を提供したい場合に有用なパターンです。

例えば、ユーザーからの評価用データロードのリクエストをフックとして、AI Agentの評価に必要なデータだけをデータ基盤からアプリケーションDBにロードするという方法があります。

この方式をとっているのが、カスタマーサービス向けAIサービスのFinであり、Finでは最大50件のデータをデータセットとして読み込み、評価に利用できる機能をユーザーに提供しています。このデータはカテゴリごとに読み込むこともできます。次はFinのデータセットを読み込み、データごとに評価を行う機能ページの画像です。(https://fin.ai/help/en/articles/10672042-batch-testing より引用)

https://fin.ai/help/en/articles/10672042-batch-testing より引用

このような評価に必要なデータだけ事前に取り込んでおくパターンはQ&Aエージェントのような、一つ一つのデータセットを目で見て確認することが重要なドメインでは便利です。

これをデータ基盤と、評価用過去データのロードを使って実現すると、次のようなアーキテクチャが考えれられます。

これであればCDCで全ての過去データを保存するコストを抑えた上で、評価に必要なデータだけを利用できるというバランスの取れた構成になります。

デメリットとして、開発者がAI Agentを大きなデータで評価したい場合は依然として、毎回必要なデータをアプリケーションDBに読み込むのは避けたいので、別途評価基盤が必要になります。

また、一つ一つのデータセットを目で見て確認することが重要な場合は上の手法が有用ですが、我々の申請レビューAgentにおいては、Agentの設定が過去1ヶ月に渡って、どれだけ差し戻しを検知できるかなどの統計値としてチェックしたいので、より多くのデータセットを格納する必要があります。そのため、バックテストの用途では一部のデータをDBにロードするのではなく、データ基盤に直接アクセスする方式を選択しています。やりたい評価の仕方によっては、この方法を採用すると良いでしょう。

まとめ

今回はAI Agentのビジネス価値を計るためのバックテストの威力と、それをどのように実装したかを紹介しました。

この記事はLayerX AI Agentブログリレーの36日目の記事です。毎日AI Agentに関する知見をお届けします！！LayerXテック公式Xか僕のX(@po3rin)を是非フォローして見逃さないようにお願いします！

AI Agent時代はLLMを使って終わりではなく、それを支える基盤を根本から変えていくパワーが必要です。一緒にAI Agent時代をソフトウェアエンジニアリング力で突き進むソフトウェアエンジニア、プラットフォームエンジニア、AI/MLOpsエンジニアを絶賛募集中です！！是非カジュアルにお話ししましょう。

ここから僕につながります！ jobs.layerx.co.jp