$125M調達のBraintrust、AI評価をPRDへ変える品質ループ

内製evalを二度作った創業者

Ankur Goyalは、ImpiraとFigmaでevaluation用の内製ツールを作る難しさを経験し、「自分が二度同じ問題を扱ったなら、他社にもある」と考えてBraintrustを始めたと振り返る。出典

その出発点は、AIアプリの品質がコードだけでは決まらないという現実だった。

同じpromptでも出力が揺れ、一般benchmarkでは個別プロダクトの失敗を捉えにくい。

Braintrustはtrace、評価、実験を一つの作業場に置く方向を選んだ。出典

seedで検証した評価の需要

2023年12月、Braintrustは$5.1Mのseedを発表し、累計資金調達は$8.3Mとした。

Ankur Goyalは評価を「AI softwareのdevelopment loopのessential component」と位置付け、Zapier、Coda、Airtable、Instacartとの取り組みを紹介した。出典

ここで売ったのはmodelそのものではない。

評価器、dataset、experimentをチームが繰り返し使えるようにし、変更の良し悪しを事後の印象論から外すことだった。出典

Series AでコードとUIを接続する

2024年10月、a16z主導の$36M Series Aを発表し、累計は$45Mとなった。

公式は平均利用チームが1日に10件超のexperimentを実行すると述べ、継続実験がプロダクトの中心ユースケースであることを示した。出典

同時にFunctionsを投入し、prompt、tool、scorerをcodebaseからpushしてUIとAPIで使う導線を作った。

Ankur Goyalは、開発環境と評価UIを行き来できることを、AI開発の速度を上げる条件として扱っている。出典

大きなtraceを扱う基盤へ

agentのtraceが長く複雑になると、browserでの集計は限界に達する。

2025年6月、BraintrustはBrainstoreを使い、experimentが数十件から数十万件へ増えた状況に対応したと説明した。出典

2026年2月にはICONIQ主導で$80M Series Bを発表した。

Ankur Goyalは、AIが実運用へ移るほどobservabilityをcore infrastructureとして扱うべきだと書く。出典

Braintrustの道筋は、evalを一度だけ走らせるチェックリストから、本番の失敗を次の改善材料に変える運用へ広げる試みだと言える。

LLMアプリを本番で運用するチームは、通常のunit testだけでは非決定的な出力の品質を説明できない。

Braintrustはtrace、dataset、experiment、scorerを同じ開発ループに置き、何が悪化したかを具体例まで辿れるようにする。出典

特にPM・デザイナー・エンジニアが同じ評価結果を見て、期待値を更新できる点が価値になる。

公式は平均利用チームが1日に10件超のexperimentを実行すると述べており、単発のモデル比較ではなく継続改善へ用途を寄せている。出典

Braintrustの防御力は、traceを集めるだけでなく、production failureからdataset、evaluation、改善へ戻す作業履歴にある。

顧客ごとのscorer・annotation・experiment比較は導入後に蓄積する。出典

一方でOpenTelemetryやSDKは相互運用を広げるため、ロックインはデータ形式ではなく日常の品質運用に置かれる。

Brainstoreは大規模で半構造化したAI traceへの技術的差別化を補強する。出典

直接の二面市場型network effectは強くない。

顧客間でtraceや評価データを共有する設計ではないためだ。

ただしSDK、autoevals、MCP、フレームワーク統合が増えるほど導入摩擦は下がり、コミュニティで評価手法が標準化する間接効果はある。出典 出典

主対象は、RAG、support agent、code agentなどを本番に出し、変更ごとの品質回帰を説明したいAI product team。

エンジニアだけでなく、評価基準やannotationを担うPM・デザイナー・domain expertも利用者に含まれる。出典

単発デモだけを作る個人より、実データを継続的に集め、CI/CDまたはproduction monitoringに品質gateを組み込みたい組織に適する。出典

第一に、評価を単独機能でなくtraceとproduction logのフィードバックループとして売った。

公式の三本柱はtraces、evals、annotationであり、失敗例をdatasetへ戻す導線を明示している。出典

第二に、SDK・CLI・MCPを複数言語へ広げ、既存の開発環境に入れる選択をした。

SDK公開とFunctionsのpushフローは、評価を別SaaSの画面に閉じないための配布戦略だと考えられる。出典 出典

評価の価値は、顧客が何を良い出力と定義し、実例をdatasetへ継続投入できるかに依存する。

公式も一般benchmarkだけではアプリ固有の品質を測れず、評価器は人間の判断に合わせて検証する必要があると説明している。出典 出典

またtraceはPIIを含み得る大容量データで、保持期間、処理量、score数が価格に直結する。

料金表ではStarterの保持期間は14日、Proは30日であり、データ主権・コスト・導入設計がenterprise採用の障害になり得る。出典

初期はAI開発チームの評価課題を、技術コンテンツ、SDK、無料Starterでセルフサーブ導入させる。

Starterは$0で1GBの処理量、10K score、無制限ユーザー・project・dataset・experimentを含む。出典

その後、観測量・保持期間・RBAC・hybrid deploymentを要する組織へProとEnterpriseを販売する。

Series A後にFunctions、Series B後にBrainstoreと本番observabilityを前面に出しており、eval専用から運用基盤へ拡張する筋が見える。出典 出典

主要チャネル: developer_relations, open_source, content, enterprise_sales, partner_ecosystem

AI機能の要件を文章だけで固定しようとすると、モデル更新や実ユーザー入力の変化に追いつけない。

PMは「良い」の定義を小さな評価ケースとscorerへ落とし、失敗した本番例を次のdatasetへ戻す運用を設計する必要がある。出典

ただしscoreを最適化対象そのものにするとGoodhart化する。

公式もscoreをtask completion、satisfaction、retentionのような実成果と結び付ける必要を指摘している。出典

日本でAI supportや業務agentを導入する企業には、model選定の前に「どの失敗を許容しないか」を現場と定義するevaluation workshopが有効だと考えられる。

FAQ、社内規程、顧客対応の実例を匿名化して評価セットにし、変更をCIで比較する。

個人情報・機密文書を扱う場合は、保持期間、S3 export、hybrid deploymentの選択を法務・securityと先に詰めるべきである。

Braintrustが掲げるデータ保持とhybrid deploymentの選択肢は、この導入順序の重要性を示す。出典 出典