Arize AIはどのようにAI observabilityを評価基盤へ広げたか

失敗を説明できないAIから始める

Jason LopateckiとAparna Dhinakaranは、AI/MLモデルがproductionでどう振る舞うかを開発チームが理解しにくい問題に向き合い、Arize AIを創業した。

公式のAboutページは、モデルのreasoning、data drift、hallucinationを見えにくい課題として挙げている。出典

「AIを信頼できる形で動かすには、何が起きたかを見えるようにしなければならない」という方向性が、二人の出発点だったと読める。これは逐語的なインタビュー引用ではなく、公式説明からの要約である。

traceからevaluationへ

初期のobservabilityは、モデルやアプリケーションの挙動を追うことが中心だった。

しかしLLM applicationでは、traceを見ても回答のcorrectnessやgroundednessを測れなければ、変更の良し悪しを判断できない。

ArizeはAXでtrace・evaluation・改善を一続きのworkflowとして提示した。出典

OSSを標準の入口にする

PhoenixはAI observabilityのOSSとして、開発者が自分の環境でtracingやevaluationを試す入口になった。

さらにOpenInferenceを通じて、特定のSaaSだけに閉じないinstrumentationとopen standardsを打ち出した。出典 出典

SaaSとOSSを併走させる

Arizeの現在の設計は、AXのmanaged platformとPhoenixのOSSを対立させない。

Free tierから始めるチーム、enterprise運用を必要とするチーム、self-hostingを選ぶチームに異なる導入経路を用意する。出典

今のArize AI

公式サイトは月500万downloadsを掲げ、ArizeはAI applicationsの観測・評価・改善を一つの課題として扱っている。出典

数字の定義とas-ofは要確認だが、同社が単なる監視dashboardではなく、AI品質のdevelopment loopを狙っていることは読み取れる。

AI applicationの開発チームは、modelの精度だけでなく、prompt・retrieval・tool callのどこで失敗したかを説明できなければ改善できない。

Arize AXはtrace、evaluation、監視を一つのworkflowにまとめる。出典

PhoenixはOSSとopen standardsを入口にできるため、特定vendorへ全面依存せずに導入したいチームにも合う。

観測をdebugだけで終わらせず、変更前後の品質比較へつなげる点がPMFの核だと考えられる。出典

最大のmoatは、OpenInferenceによるinstrumentation、PhoenixのOSS利用、AXの商用workflowが作る実装知の蓄積だ。

単独のdashboardではなく、データ収集から評価までの接続面に蓄積が生まれる。出典

ネットワーク効果は中程度。

利用企業が増えるほど評価の実践知やintegrationは増えるが、同じデータを共有するmarketplace型ではない。

open standardの採用拡大が間接的な正の外部性になる。出典

AI/MLを本番運用するengineer、evaluationを設計するApplied AI team、品質と安全性を説明したいenterpriseのPlatform teamが中心。

単純なchatbot analyticsだけを求め、traceや評価データを持たないチームには導入負荷が高い。出典

第一に、AI observabilityをtraceだけでなくevaluationまで広げたこと。

第二に、OpenInferenceとPhoenixでinstrumentationの入口を広くしたことだ。出典

\n\nSaaSのAXとOSSのPhoenixを併走させることで、個人開発からenterpriseまで異なる導入段階を受け止められる。

これは機能追加よりも、採用後の拡張経路を設計した成功要因だと考えられる。出典

AI observabilityは競争が激しく、cloud vendorやmodel providerが同等機能を内製するリスクがある。

また、traceを集めても評価データの設計が弱ければ改善には届かない。出典

PhoenixのOSS利用者を有料AXへ転換できるか、また複数の標準・frameworkを長期に維持できるかは公開情報だけでは要確認だ。

開発者にはPhoenixとGitHub、導入企業にはAXのFree tier・customer stories・documentationで接点を作る。

Freeは月10 issues、25k trace spans、1GB ingestion、Proは月50ドルと明示されている。出典

OSSの広がりとSaaSのenterprise販売を両立する戦略だが、無料利用が有料化へ進む条件は顧客規模や契約状況に依存するため要確認である。

主要チャネル: developer_community, documentation, github, content_marketing, customer_stories

AI productでは「精度が低い」という結果だけでは、次の開発判断につながらない。

prompt、model、retrieval、tool、orchestrationを同じtraceで比較し、評価をリリースworkflowへ組み込む必要がある。出典

またOSSとSaaSを別々の製品ではなく、導入段階の異なる入口として設計する発想は、開発者向けB2Bにも応用できる。

日本では生成AI導入のPoCから本番移行で、品質・安全性・説明責任が壁になりやすい。

Arize型のtraceとevaluationを、金融・製造・コンタクトセンターの業務指標や日本語評価セットに接続できれば価値が出る。出典

一方、個人情報や社内データを外部SaaSへ送る境界設計は必須で、Phoenixのself-hostingを含む選択肢が重要になる。