2026.10.31 AI

Arize Phoenixとは？LLMのトレースと評価をローカルで回す手順・v21の認証変更・導入判断【2026年版】

Arize Phoenixは、LLMを組み込んだアプリの呼び出しをOpenTelemetryで記録し、その記録をLLM-as-a-Judgeで採点できる、Arize AI製の可観測性ツールです。2026年10月31日時点の最新版は21.0.0で、pip install1行で手元に立ち上がり、Docker 1コンテナでも動きます。この記事では、検証環境の起動、21.0.0で既定になった認証とAPIキーの設定、register()によるトレース送信、トレースを取り出して採点し書き戻す流れ、LangfuseやArize AXとの違い、そしてElastic License 2.0のもとで採用を見送る条件までを、コピーして動かせる設定例とあわせて整理します。

まとめ：Arize Phoenixで最初に組む構成と、採用を決める2つの条件

最初に組むのは、手元のphoenix serveと、アプリ側のregister(auto_instrument=True)の2点です。これだけでOpenAIやLangChainの呼び出しがスパン単位で画面に並びます。採点はその後で、画面に溜まったトレースをデータフレームとして取り出し、評価器にかけて結果を同じスパンへ注釈として戻します。

採用を決める条件は2つ。トレースと評価を自社のネットワーク内に置きたいこと、そしてPostgreSQL 1台で賄える規模であることです。両方に当てはまるなら、Phoenixは構成要素が少なく、立ち上げの手間に対して得るものが大きいツールです。

見送るのは、Phoenix自体を自社の顧客へホスティングして提供する計画がある場合です。ライセンスがこれを禁じています。

Arize Phoenixの機能範囲と21.0系の版数・ライセンスの制約

トレース・評価・データセット・プロンプト管理を1画面で扱う範囲

GitHubのPhoenixリポジトリのREADMEは、機能としてトレース、評価、データセット、実験、プレイグラウンド、プロンプト管理を挙げています。中心はトレースです。LLM呼び出し、検索、ツール実行を1本のトレースの中のスパンとして記録し、そのスパンに評価結果を「注釈（annotation）」として貼り付けて同じ画面で見比べます。

計装には、Arizeが保守するOpenInferenceを使います。OpenTelemetryの上にLLM向けの属性を定めた仕様と、OpenAI・Anthropic・LangChain・LlamaIndexなど向けの計装ライブラリの集合です。LLMOps全体の中でトレースと評価がどこに位置するかはLLMOpsで整理したトレース・評価・コスト管理の実装にまとめており、本記事はPhoenix固有の設定に絞ります。

21.0.0の版数と、Elastic License 2.0が禁じる提供形態の範囲

PyPIのarize-phoenixは2026年10月30日に21.0.0が公開され、対応PythonはPython 3.11以上3.16未満です。周辺パッケージは版が独立しており、トレース送信用のarize-phoenix-otelが0.17系、評価用のarize-phoenix-evalsが3.9系、APIクライアントのarize-phoenix-clientが3.6系でした（いずれも同日時点）。arize-phoenix-otelは3.15未満までの対応なので、Pythonは3.11〜3.14で揃えるのが無難です。

ライセンスは本体と評価ライブラリがElastic License 2.0（ELv2）、otelとclientがApache 2.0です。第三者の紹介記事にはApache 2.0と書かれたものもあるので注意してください。LICENSEの本文は、ソフトウェアの機能の主要部分を第三者にホスティング型・マネージド型のサービスとして提供することを禁じています。自社内の開発・運用に使う分には無料で、機能制限もありません。

phoenix serveとDockerで検証環境を立ち上げる手順と、v21で変わった認証

ここから手を動かします。Pythonが入ったPCなら5分ほどで画面が開きます。

pipとphoenix serveで手元に起動し、6006番ポートでUIを開く手順

最短経路では、仮想環境に本体を入れてphoenix serveを実行します。設定の仕様では、6006番がUIとOTLP（HTTP）の受け口、4317番がOTLP（gRPC）の受け口です。保存先を指定しなければ一時的なSQLiteで動き、作業ディレクトリの既定は~/.phoenix/です。

python3.12 -m venv .venv
source .venv/bin/activate
pip install "arize-phoenix==21.0.0"
phoenix serve
# ブラウザで http://localhost:6006 を開く

21.0.0からは待ち受けアドレスの既定が127.0.0.1になり、この状態では認証がかかりません。社内の別マシンから見せたいときはPHOENIX_HOST=0.0.0.0を付けて起動します。従来のphoenix serve --hostは21.0.0で廃止されたので、古い手順書のコマンドはそのままでは動きません。

Docker版は21.0.0から認証必須、APIキーを発行してから送る設定

MIGRATION.mdのv20からv21への移行手順によると、DockerイメージはPHOENIX_HOST=::で起動するため、21.0.0以降は既定で認証が有効です。APIキーを持たない送信はHTTP 401で拒否されます。v20までの感覚でdocker runしてトレースが1件も届かない場合、まず疑うのはここです。

初期管理者はadmin@localhostで、パスワードを指定しなければadminのまま起動し、初回ログインで変更を求められます。下の構成はPostgreSQLで永続化し、初期パスワードを外から与える形です。Dockerでの配置手順はPostgreSQL 14以上を対象としています。

# compose.yaml
services:
  phoenix:
    image: arizephoenix/phoenix:version-21.0.0
    depends_on: [db]
    ports:
      - "6006:6006"
      - "4317:4317"
    environment:
      - PHOENIX_SQL_DATABASE_URL=postgresql://postgres:postgres@db:5432/postgres
      - PHOENIX_DEFAULT_ADMIN_INITIAL_PASSWORD=${PHOENIX_ADMIN_PASSWORD}
      - PHOENIX_SECRET=${PHOENIX_SECRET}
      - PHOENIX_DEFAULT_RETENTION_POLICY_DAYS=30
  db:
    image: postgres:17
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    volumes:
      - database_data:/var/lib/postgresql/data
volumes:
  database_data:

起動後、管理画面の設定からシステムキーを発行し、アプリ側の環境変数PHOENIX_API_KEYに入れます。認証の仕様では、キーはAuthorization: Bearerヘッダーで送られ、ロールはadmin・member・viewerの3種です。PHOENIX_SECRETは21.0.0で任意になりましたが、未設定だとデータベースの複製から保存済みのAPIキー類を復号できてしまうため、必ず入れてください。なお、この認証ページの一部には「既定は無効」という旧来の記述が残っており、21.0.0の挙動とは合いません。判断はMIGRATION.mdを正としてください。

register()とOpenInferenceでLLMをトレースする設定

サーバーが立ったら、アプリ側にphoenix.otelの送信設定を入れます。書く量は数行です。

register()の既定値と、本番相当でbatch=Trueに切り替える理由

phoenix.otelの仕様では、register()の既定は送信先がhttp://localhost:6006、プロジェクト名がdefault、batch=False、auto_instrument=Falseです。トレースの導入手順に沿い、OpenAIの呼び出しを計装する最小構成は次のとおりです。

pip install "arize-phoenix-otel==0.17.2" openai openinference-instrumentation-openai
export PHOENIX_COLLECTOR_ENDPOINT=http://localhost:6006
export PHOENIX_API_KEY=発行したシステムキー   # 認証が有効なサーバーでは必須

from openai import OpenAI
from phoenix.otel import register

tracer_provider = register(
    project_name="support-rag-staging",
    protocol="http/protobuf",
    batch=True,            # BatchSpanProcessorでまとめて送る
    auto_instrument=True,  # 導入済みのOpenInference計装を自動で有効化
)

client = OpenAI()
client.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": "請求額が先月から変わった理由を教えてください"}],
)
tracer_provider.force_flush()  # 短いスクリプトは終了前に送り切る

batch=Falseのままだとスパン1件ごとに同期送信され、応答時間に送信の待ちが乗ります。検証のスクリプトでは既定のままで構いませんが、Webアプリに入れるときはbatch=Trueにしてください。プロジェクト名は環境ごとに分けると、ステージングの試行が本番の集計に混ざりません。スパンの親子関係をどう切るかはエージェントトレーシングでのスパン木の設計で扱っています。

OpenInferenceの自動計装と、入力・出力を隠すマスキング環境変数

OpenInferenceが付ける属性はllm.input_messagesやllm.output_messagesのような独自の名前空間です。OpenTelemetry本家が定めるgen_ai.*属性とは別物なので、Datadogなど既存のAPMにも同じスパンを流す計画なら、属性の対応を先に確かめます。違いの整理はGenAIセマンティック規約のgen_ai属性と移行判断が参考になります。

顧客の問い合わせ文をそのままトレースに残せない現場では、スパン属性のマスキング仕様にある環境変数を使います。OPENINFERENCE_HIDE_INPUTS=trueで入力を、OPENINFERENCE_HIDE_OUTPUTS=trueで出力を隠す設定です。既定はどちらもfalseで、コード側のTraceConfigが環境変数より優先されます。入力を隠すと後段の評価で中身を読めなくなるため、隠すのは本番だけにし、評価はステージングの擬似データで回す分担が現実的です。

トレースを取り出してLLM-as-a-Judgeで採点し、注釈で書き戻す流れ

トレースが溜まったら採点に移ります。Phoenixの評価は「取り出す→採点する→スパンに戻す」の3段です。

トレースをデータフレームに取り出し、分類評価器で採点するコード例

トレースに評価をかける手順では、Client().spans.get_spans_dataframe()でスパンをpandasのデータフレームに取り出し、ClassificationEvaluatorで分類させ、log_span_annotations_dataframe()で結果を戻します。下はJupyterでの実行を想定した例です。

from phoenix.client import Client
from phoenix.evals import ClassificationEvaluator, async_evaluate_dataframe
from phoenix.evals.llm import LLM
from phoenix.evals.utils import to_annotation_dataframe

spans_df = Client().spans.get_spans_dataframe(project_name="support-rag-staging")
eval_df = spans_df[["context.span_id", "attributes.llm.output_messages"]].copy()
eval_df.set_index("context.span_id", inplace=True)
eval_df["answer"] = eval_df["attributes.llm.output_messages"].apply(
    lambda m: m[0]["message.content"]
)

tone = ClassificationEvaluator(
    name="tone",
    llm=LLM(provider="openai", model="gpt-4o-mini"),
    prompt_template="次の回答が顧客対応として丁寧かを判定してください。\n\n回答: {answer}",
    choices=["polite", "rude"],
)

results_df = await async_evaluate_dataframe(eval_df, evaluators=[tone])
Client().spans.log_span_annotations_dataframe(
    dataframe=to_annotation_dataframe(results_df)
)

スパンIDをインデックスにしておくことで、採点結果が元のスパンに結び付きます。awaitをそのまま書けるのはノートブックだけなので、通常のスクリプトではasyncio.run()で包んでください。採点用のモデルを評価対象と同じにすると自己採点の偏りが出るため、別系統のモデルを選びます。採点器を信用してよい条件はLLM-as-a-Judgeの評価プロンプトとバイアス対策で扱っています。

RAGでは検索スパンと生成スパンを分け、採点の対象を絞る考え方

RAGアプリのトレースには、ベクトル検索のRETRIEVERスパンと、回答を作るLLMスパンが並びます。回答の誤りが検索の取りこぼしか、生成の読み違いかを切り分けるには、検索側は「取ってきた文書が質問に関係するか」、生成側は「回答が文書に書かれた内容から外れていないか」を別々の評価器で測ります。

全スパンを毎回採点すると、採点モデルの利用料がトレース数に比例して増えます。まずは利用者が低評価を付けた会話か、無作為に抜いた数%に絞るのが費用と精度の釣り合う始め方です。指標の選び方は検索と生成を分けて測るRAG評価の指標にまとめています。

LangfuseやLangSmith、Arize AXとの違いと、選ぶ基準になる運用条件

Langfuse・LangSmithと比べたセルフホスト構成と計装方式の差

3つとも「トレースを溜めて評価を貼る」という骨格は同じです。差が出るのは、自社で運用するときの部品の数と、計装の作法です。

比較観点	Arize Phoenix	Langfuse	LangSmith
自社運用に要る部品	本体1コンテナとPostgreSQL	Web・Workerと保存系4種	自社運用は上位契約が前提
計装の作法	OpenInference中心	独自SDKとOpenTelemetry	LangChain系SDKが中心
本体のライセンス	Elastic License 2.0	OSS版はMIT系	商用サービス

表のLangfuseの部品は、Web・Worker・PostgreSQL・ClickHouse・Redis・S3です。保存系4種の内訳は、PostgreSQL・ClickHouse・Redis・S3です。Langfuseのセルフホスト構成は、観測データをClickHouseに、生イベントをS3互換ストレージに置く設計で、大量のトレースを長く保持する用途に向きます。PhoenixはPostgreSQL 1台で始められる代わりに、スパン数が増えたときの拡張は自分で設計する必要があります。その設計も自社運用の担当範囲です。Langfuseの機能と使い方はLangfuseの機能とLangSmithとの違い、LangSmithの送信設定と料金はLangSmithのトレース送信と料金・リージョンで確認できます。

Arize AXへ移る目安は、運用の手間・保持期間・監査要件の3点

PhoenixとArize AXの違いによれば、両者は同じOpenTelemetryとOpenInferenceの上に作られており、計装を変えずに送信先だけを切り替えられます。AXはArizeが運用するSaaSで、組織管理と監査、ダッシュボード、HIPAAやSOC 2への対応が加わります。

料金ページでは、AX Freeが月25,000スパン・保持15日、AX Proが月50ドルで50,000スパン・保持30日、Enterpriseは個別見積です（2026年10月31日時点）。AXのFreeとProは保持が15〜30日で区切られるため、トレースを数か月単位で残したいならEnterpriseかPhoenixの自社運用になります。サーバーの面倒を見る人がいない、監査証跡を外部認証つきで出したい、のどちらかに当たればAXへ。それ以外はPhoenixで始め、計装はそのまま持ち越せます。

Arize Phoenixを採用する条件と見送る場面、RAG開発を委託するときの指定

ここからは判断を言い切ります。

採用してよい条件と、保持期間0日（無期限）のまま運用しない理由

次の3つがそろうなら採用してください。トレースを社外のSaaSに出せない、または出したくないこと。計装をOpenTelemetry系の標準に寄せ、将来の乗り換え余地を残したいこと。日々のスパン数がPostgreSQL 1台で扱える範囲に収まること。この条件なら、本体1コンテナで評価まで一通り回ります。

運用に入る前に1つだけ必ず設定します。データ保持の仕様では、PHOENIX_DEFAULT_RETENTION_POLICY_DAYSの既定は0、つまり無期限保持です。プロンプトと回答の全文が溜まり続けるため、ディスクが埋まるより先に個人情報の保管期間の規程に触れます。30日など社内規程に合わせた日数を入れ、評価に残したいトレースはデータセットへ移してから消える運用にしてください。

Phoenixを見送る場面：顧客向けの再提供と、既存APMへの集約方針

見送るべき場面は2つです。1つは、自社のSaaSの機能としてPhoenixの画面やAPIを顧客に使わせる計画がある場合。ELv2が禁じる「ホスティング型での第三者提供」に当たりうるため、Arizeとの商用契約を先に相談するか、別の基盤を選びます。

もう1つは、監視をDatadogなど既存のAPMに一本化する方針が決まっている場合です。LLMのスパンだけ別の画面に分けると、障害時に2つの画面を行き来することになります。リリース前の回帰検査が主目的なら、トレース基盤を持たないpromptfooのYAML設定とCI組み込みを関門に置き、本番の監視はAPM側に任せる組み合わせのほうが運用が軽く済みます。

RAG開発を外部に任せるとき、トレース設計と評価コードを成果物に含める理由

RAGを組み込んだ業務システムを委託するなら、納品物にregister()を含む計装コード、プロジェクト名と保持日数の設定、評価器の定義と採点プロンプトの3点を含めるよう見積段階で指定してください。これがあれば、受け入れ時に自社のPhoenixで同じ採点を再実行でき、「回答が文書から外れた率」のような数字で検収できます。報告書だけの納品では、検索の設定を変えた後に何を測り直せばよいか分からなくなります。

検索の設計から評価の仕組みまで含めてRAGの構築を相談したい場合は、RAG構築支援で要件の整理から引き受けています。依頼前に、正しく答えてほしい質問と正解の組を10件ほど書き出しておくと、評価用データセットの初版がすぐ作れます。

よくある質問

Arize Phoenixの導入時によく出る疑問を5つ取り上げ、設定と判断の基準とあわせて回答します。

Arize Phoenixは無料で使えますか？

使えます。自社のPCやサーバー、自社のクラウドアカウントで動かす限り、利用料はかからず機能の制限もありません。ただし採点に使うLLMのAPI利用料と、PostgreSQLなどのインフラ費用は自社持ちです。Arizeが運用するSaaS版のArize AXには、月25,000スパンまでのFreeプランと月50ドルのProプランがあります。

Arize PhoenixとArize AXは何が違いますか？

Phoenixは自社で運用する版、AXはArizeが運用するSaaSです。トレースと評価の作法は共通で、OpenInferenceの計装を変えずに送信先だけを切り替えられます。AXには組織管理と監査、自動スケール、専任サポートとSLA、HIPAAやSOC 2への対応が加わります。運用担当を置けるかどうかで選ぶと迷いません。

Docker版のPhoenixにトレースが届かないのはなぜですか？

21.0.0以降のDockerイメージは既定で認証が有効なため、APIキーを持たない送信はHTTP 401で拒否されます。管理画面でシステムキーを発行し、アプリ側のPHOENIX_API_KEYに設定してください。社内の検証用に認証を切りたい場合はPHOENIX_ENABLE_AUTH=falseで起動できますが、社外から届くネットワークには置かないことが前提です。

LangChainやLlamaIndexのアプリもトレースできますか？

はい、トレースの対象です。OpenInferenceにはLangChain、LlamaIndex、DSPy、CrewAI、各社のLLM SDK向けの計装パッケージがあり、該当パッケージを入れてregister(auto_instrument=True)を呼べば自動で有効になります。対応していない処理は、OpenInferenceのデコレーターや手動のスパン作成で補えます。

PhoenixとLangfuseはどちらを選べばよいですか？

PostgreSQL 1台の小さな構成で早く始めたい、計装をOpenTelemetry系で揃えたいならPhoenix、大量のトレースを長期保持して分析したい、またはMIT系ライセンスのOSSである点を重視するならLangfuseが合います。Phoenixは本体1コンテナ、LangfuseはClickHouseやRedisを含む複数部品の運用になる点が、体制を決める分かれ目です。