arize-evaluator

Arize 評価器スキル

SPACE — --space フラグには、スペースの名前（例：my-workspace）または base64 形式のスペースID（例：U3BhY2U6...）を指定します。ax spaces list で確認できます。

このスキルでは、Arize での評価器の設計、作成、実行について説明します。対象となるのは、**LLM-as-judge（テンプレート）**評価器と、コード評価器（決定論的で、LLM は不要）の両方です。評価器は判定方法を定義し、タスクは実際のデータに対して評価器を実行する方法です。

---

前提条件

タスクに直接取りかかり、必要な ax コマンドを実行してください。事前にバージョン、環境変数、プロファイルを確認しないでください。

ax コマンドが失敗した場合は、エラーに応じてトラブルシューティングしてください。

• command not found またはバージョンエラー → references/ax-setup.md を参照してください
• 401 Unauthorized / API キーがない → ax profiles show を実行し、現在のプロファイルを確認してください。プロファイルがない、または API キーが間違っている場合は、references/ax-profiles.md に従って作成または更新してください。ユーザーがキーを持っていない場合は、https://app.arize.com/admin > API Keys に案内してください
• スペースが不明 → Space を参照してください
• LLM プロバイダーの呼び出しが失敗する（プロバイダーの認証情報がない）→ ax ai-integrations list --space SPACE を実行し、プラットフォーム管理の認証情報があるか確認してください。存在しない場合は、arize-ai-provider-integration スキルを使用してください。プロバイダーキーをチャットに貼り付けるようユーザーに求めてはいけません。
• セキュリティ： .env ファイルを読み取ったり、ファイルシステム内で認証情報を検索したりしてはいけません。例外として、秘密情報ではない ARIZE_SPACE_ID の行は確認できます（references/ax-profiles.md を参照）。Arize の認証情報には ax profiles を、LLM プロバイダーキーには ax ai-integrations を使用してください。秘密情報をチャットに貼り付けるようユーザーに求めてはいけません。認証情報がない場合は、references/ax-profiles.md を参照してください。
• 重要 — 評価結果を決して捏造しないでください： 評価タスクが失敗、中止、またはスコアを生成しなかった場合は、失敗したことを明確に報告し、何が問題だったのかを説明してください。「手動評価」を実行したり、品質スコアを作り出したり、割合を推定したり、エージェントが生成した分析を Arize の評価システムによる結果であるかのように提示したりしてはいけません。代わりに、次の方法を提案してください：（1）特定された問題を修正して再試行する、（2）Arize UI から実行してみる、（3）ax ai-integrations list で連携の認証情報を確認する、（4）https://arize.com/contact/ からサポートに問い合わせる

---

概念

評価器とは？

評価器は、LLM を判定役として使う定義です。次の内容が含まれます。

フィールド	説明
テンプレート	判定用プロンプトです。タスクの列マッピングを通じて実行時に値が設定される {variable} プレースホルダー（例：{input}、{output}、{context}）を使用します。
分類の選択肢	出力として許可されるラベルのセットです（例：factual / hallucinated）。デフォルトかつ最も一般的なのは二値分類です。各選択肢には、任意で数値スコアを設定できます。
AI インテグレーション	評価器が判定モデルを呼び出す際に使用する、保存済みの LLM プロバイダー認証情報（OpenAI、Anthropic、Bedrock など）です。
モデル	判定に使用する特定のモデルです（例：gpt-4o、claude-sonnet-4-5）。
呼び出しパラメーター	{"temperature": 0} のようなモデル設定を指定する任意の JSON です。再現性を高めるため、低い温度が推奨されます。
最適化の方向	スコアが高いほど良い（MAXIMIZE）か、悪い（MINIMIZE）かを指定します。UI での傾向の表示方法を設定します。
データ粒度	評価器を スパン、トレース、セッション のどのレベルで実行するかを指定します。ほとんどの評価器はスパンレベルで実行されます。

評価器にはバージョン管理が適用されます。プロンプトまたはモデルを変更するたびに、新しい不変のバージョンが作成されます。最新バージョンが有効になります。

コード評価器は、決定論的な代替手段です。AI インテグレーションやモデルは不要で、Python のみを使用します。単独の関数ではなく、CodeEvaluator をサブクラス化したクラスとして実行され、インポートパスと evaluate() のシグネチャにはそれぞれ厳密な要件があります。どちらかが間違っていると、実行は 0/0/0 のまま、通知なくキャンセルされます。作成する前に、references/cli-reference.md の「カスタム Python コード評価器」を参照してください。

リモート評価器は、顧客がホストする HTTP エンドポイントを呼び出します。ax evaluators create-evaluator remote で作成でき、このコマンドには評価器インテグレーション ID が必要です。使用できるフラグを確認するには、ax evaluators create-evaluator remote --help を実行してください。

タスクとは？

タスクは、実データに対して1つ以上の評価器を実行する方法です。タスクは、プロジェクト（ライブのトレース／スパン）またはデータセット（実験の実行）に関連付けられます。タスクには次の内容が含まれます。

フィールド	説明
評価器	実行する評価器のリストです。1つのタスクで複数の評価器を実行できます。
列マッピング	各評価器のテンプレート変数を、スパンまたは実験の実行における実際のフィールドパスに対応付けます（例："input" → "attributes.input.value"）。これにより、評価器をプロジェクトや実験間で移植できます。
クエリフィルター	評価するスパン／実行を選択する SQL 形式の式です（例："attributes.openinference.span.kind = 'LLM'"）。タスクレベルの --query-filter で設定します。任意ですが、精度を高めるうえで重要です。
継続実行	プロジェクトのタスクの場合、新しいスパンが到着したときに自動でスコアを付けるかどうかを指定します。
サンプリングレート	継続実行するプロジェクトのタスクの場合、評価対象とする新しいスパンの割合です（0～1）。

---

データ粒度

評価器を作成するときに、タスクではなく --data-granularity を設定します（ax evaluators create-evaluator template / create-evaluator code）。これは、プロジェクトタスクに対して評価器を実行するたびに、どの単位のデータをスコアリングするかを制御します（データセット／実験タスクでは、実験の実行を直接評価します）。デフォルトは span です。

レベル	評価対象	用途	結果列のプレフィックス
span（デフォルト）	個々のスパン	Q&A の正確性、ハルシネーション、関連性	eval.{name}.label / .score / .explanation
trace	context.trace_id でグループ化された、トレース内のすべてのスパン	エージェントの軌跡、タスクの正確性など、呼び出しチェーン全体を必要とするもの	trace_eval.{name}.label / .score / .explanation
session	attributes.session.id でグループ化され、開始時刻順に並べられた、セッション内のすべてのトレース	複数ターンの一貫性、全体的なトーン、会話の品質	session_eval.{name}.label / .score / .explanation

トレースとセッションの集約方法

トレース粒度では、同じcontext.trace_idを共有するスパンがまとめられます。評価テンプレートで使用される列の値は、ジャッジモデルに渡す前にカンマ区切りで連結され、単一の文字列になります（各値は100K文字に切り詰められます）。

セッション粒度では、まず同じトレース単位のグループ化が行われ、その後、トレースがstart_time順に並べられ、attributes.session.idでグループ化されます。セッション単位の値は合計100K文字までに制限されます。

{conversation}テンプレート変数

セッション粒度では、{conversation}は特別なテンプレート変数です。セッション内のすべてのトレースから、attributes.input.value／attributes.llm.input_messages（入力側）とattributes.output.value／attributes.llm.output_messages（出力側）を使って構築された、{input, output}ターンのJSON配列として展開されます。

スパンまたはトレース粒度では、{conversation}は通常のテンプレート変数として扱われ、ほかの変数と同様に列マッピングで解決されます。

注: {conversation}を機能させるには、スパンにattributes.session.idが含まれている必要があります。アプリケーションコードからsession.idを出力する方法（Jupyterノートブックや短時間で終了するスクリプトで必要なforce_flush()パターンを含む）については、arize-instrumentationスキルを参照してください。

複数評価器のタスク

タスクには、異なる粒度の評価器を含めることができます。実行時にシステムは、データ取得に最も高い粒度（セッション > トレース > スパン）を使用し、評価器ごとに子ランを自動的に1つずつ作成します。タスク内のすべての評価器に適用されるタスクレベルの--query-filterで絞り込みます。

---

基本的なCRUD

AI連携、評価器（テンプレートおよびコード）、タスクの全コマンドリファレンス（すべてのフラグと例を含む）は、references/cli-reference.mdにあります。以下のワークフローでは、必要なコマンドをその場に記載しています。

---

ワークフローA：プロジェクト用の評価器を作成する

ユーザーが「Playground Tracesプロジェクト用の評価器を作成して」のように依頼した場合に使用します。

ステップ1：プロジェクト名を確認する

ax spans exportは--space SPACEでプロジェクト名を受け付けるため、IDの検索は不要です。既知の名前を確認するか、base64形式の"id"を取得するには（名前で検証エラーが発生した場合はidを使用します）、プロジェクトを直接取得します。

ax projects get PROJECT --space SPACE -o json

プロジェクト名が不明な場合は、ax projects list --space SPACE -o jsonでプロジェクト一覧を表示します。該当する"name"をPROJECTとして使用します。

ステップ2：評価対象を把握する

ユーザーが評価器の種類（幻覚、正確性、関連性など）を指定した場合 → ステップ3に進みます。

指定されていない場合は、最近のスパンをサンプル取得し、実際のデータに基づいて評価器を設計します。

ax spans export PROJECT --space SPACE -l 10 --days 30 --stdout

attributes.input、attributes.output、スパンの種類、既存のアノテーションを確認します。失敗のパターン（例：事実の捏造、話題から外れた回答、コンテキストの不足）を特定し、具体的な評価器の案を1～3件提示します。ユーザーに選んでもらいます。

各案には、評価器名（太字）、何を判定するかを説明する1文、括弧内の二値ラベルのペアを含めます。それぞれ次の形式にします。

1. 名前 — 判定対象の説明。(label_a / label_b)

例：

1. Response Correctness — エージェントの応答は、ユーザーの金融に関する質問に正しく答えていますか？(correct / incorrect)
2. Hallucination — 応答は、取得したコンテキストに根拠のない事実を捏造していますか？(factual / hallucinated)

ステップ3：AI連携を確認または作成する

ax ai-integrations list --space SPACE -o json

適切な連携が存在する場合は、そのIDを記録します。存在しない場合は、arize-ai-provider-integrationスキルを使って作成します。ジャッジに使用するプロバイダーとモデルをユーザーに確認します。

ステップ4：評価器を作成する

以下のテンプレート設計のベストプラクティスを使用します。評価器の名前と変数は汎用的なものにします。プロジェクト固有の設定は、ステップ6のタスクでcolumn_mappingsを使って行います。

ax evaluators create-evaluator template \
  --name "Hallucination" \
  --space SPACE \
  --template-name "hallucination" \
  --commit-message "Initial version" \
  --ai-integration-id INT_ID \
  --model-name "gpt-4o" \
  --include-explanations \
  --use-function-calling \
  --classification-choices '{"factual": 1, "hallucinated": 0}' \
  --template 'You are an evaluator. Given the user question and the model response, decide if the response is factual or contains unsupported claims.

User question: {input}

Model response: {output}

Respond with exactly one of these labels: hallucinated, factual'

ステップ 5：バックフィル、継続実行、または両方を確認する

推奨されるアプローチ： 継続的なモニタリングを開始する前に、必ず少量のバックフィル（過去のスパン約100件）を実行して、評価器を検証してください。これにより、本番環境の今後すべてのスパンを評価する前に、既知のデータでカラムのマッピングミス、誤ったスパンの種類、テンプレートの問題を見つけられます。バックフィルで正しく評価されることを確認してから、継続実行を有効にしてください。

タスクを作成する前に、次のように確認してください。

「次のどれを行いますか？ (a) 過去のスパンに対してバックフィルを実行する（一度のみ）。 (b) 今後の新しいスパンに対する継続的な評価を設定する。 (c)両方を行う — まずバックフィルで検証し、その後、新しいスパンを自動的に評価し続ける。（推奨）」

ステップ 6：実際のスパンデータからカラムのマッピングを特定する

パスを推測しないでください。サンプルを取得して、実際にどのフィールドが存在するかを確認してください。

ax spans export PROJECT --space SPACE -l 5 --days 7 --stdout

各テンプレート変数（{input}、{output}、{context}）に対応する JSON パスを見つけてください。よく使われる開始位置は次のとおりですが、使用前に必ず実際のデータで検証してください。

テンプレート変数	LLM スパン	CHAIN スパン
input	attributes.input.value	attributes.input.value
output	attributes.llm.output_messages.0.message.content	attributes.output.value
context	attributes.retrieval.documents.contents	—
tool_output	attributes.input.value（フォールバック）	attributes.output.value

スパンの種類の整合性を検証してください： 評価プロンプトが LLM の最終テキストを前提としている一方で、タスクが CHAIN スパンを対象にしている（またはその逆）場合、実行がキャンセルされたり、誤ったテキストが評価されたりすることがあります。タスクの query_filter が、マッピングしたスパンの種類と一致していることを確認してください。

フィルターは eval インデックスに対して実行されます： スパンの種類は attributes.openinference.span.kind です。span_kind はカラムではないため、何も一致しないままになります。attributes.metadata.* などのカスタム属性もインデックス化されていない場合があります。データが存在するにもかかわらずフィルターの結果が0件の場合は、対象期間にデータがあることを確認するため、フィルターを削除してください。

--evaluators の JSON の完全な例：

[
  {
    "evaluator_id": "EVAL_ID",
    "column_mappings": {
      "input": "attributes.input.value",
      "output": "attributes.llm.output_messages.0.message.content",
      "context": "attributes.retrieval.documents.contents"
    }
  }
]

テンプレートで参照されるすべての変数にマッピングを含めてください。1つでも省略すると、実行時に有効なスコアが生成されません。

ステップ 7：タスクを作成する

バックフィルのみ（a）：

ax tasks create-evaluation \
  --name "Hallucination Backfill" \
  --task-type TEMPLATE_EVALUATION \
  --project PROJECT --space SPACE \
  --evaluators '[{"evaluator_id": "EVAL_ID", "column_mappings": {"input": "attributes.input.value", "output": "attributes.output.value"}}]' \
  --query-filter "attributes.openinference.span.kind = 'LLM'" \
  --no-continuous

継続実行のみ（b）：

ax tasks create-evaluation \
  --name "Hallucination Monitor" \
  --task-type TEMPLATE_EVALUATION \
  --project PROJECT --space SPACE \
  --evaluators '[{"evaluator_id": "EVAL_ID", "column_mappings": {"input": "attributes.input.value", "output": "attributes.output.value"}}]' \
  --query-filter "attributes.openinference.span.kind = 'LLM'" \
  --is-continuous \
  --sampling-rate 0.1

両方（c）： 作成時に --is-continuous を使用し、続いてステップ 8 でバックフィル実行も開始してください。

ステップ 8：バックフィル実行を開始する（必要な場合）

Eval インデックスの遅延： eval インデックスはプライマリのトレースストアから非同期で構築されるため、1～2時間遅れることがあります。初回のテスト実行では、終了時刻を少なくとも2時間前に設定してください。直近1時間以内に取り込まれたスパンに対して --data-end-time を「now」に設定すると、実行は正常に完了しますが、評価されるスパンは0件になります。

まず、データが存在する時間範囲を確認します。

ax spans export PROJECT --space SPACE -l 100 --days 1 --stdout   # try last 24h first
ax spans export PROJECT --space SPACE -l 100 --days 7 --stdout   # widen if empty

実際のスパンの start_time / end_time フィールドを使って、対象期間を設定してください。初回の検証実行では、すばやく結果を得るために --max-spans を約100に制限してください。

ax tasks trigger-run TASK_ID \
  --data-start-time "2026-03-20T00:00:00" \
  --data-end-time "2026-03-21T23:59:59" \
  --max-spans 100 \
  --wait

バックフィルの全範囲に拡大したり、継続実行を有効にしたりする前に、スコアと説明を確認してください。

---

ワークフロー B：実験用の評価器を作成する

ユーザーが「自分の実験用に評価器を作成して」や「データセットの実行を評価して」のように依頼した場合に使用します。

ユーザーが「データセット」と言っているものの、実験を持っていない場合： タスクは単独のデータセットではなく、実験を対象とする必要があります。次のように確認してください。

「評価タスクはデータセットに直接ではなく、実験の実行に対して行います。まず、そのデータセットの実験を作成しましょうか？」

はいの場合は、arize-experiment スキルを使って実験を作成してから、ここに戻ってください。

ステップ 1：データセット名と実験名を確認する

ax datasets list --space SPACE
ax experiments list --dataset DATASET_NAME --space SPACE -o json

評価するデータセット名と実験名を確認してください。以降のコマンドでは、名前または ID を指定できます。名前の使用を推奨します。

ステップ 2：評価内容を把握する

ユーザーが評価者の種類を指定した場合 → ステップ 3 に進みます。

指定がない場合は、直近の実験実行を調べ、実際のデータに基づいて評価者を設計します。

ax experiments export EXPERIMENT_NAME --dataset DATASET_NAME --space SPACE --stdout | python3 -c "import sys,json; runs=json.load(sys.stdin); print(json.dumps(runs[0], indent=2))"

output、input、evaluations、metadata の各フィールドを確認します。ギャップ（ユーザーが重視しているものの、まだ存在しない指標）を特定し、評価者のアイデアを 1～3 件提案します。各提案には、評価者の名前（太字）、1 文での説明、括弧内の二値ラベルのペアを含めます。形式はワークフロー A のステップ 2 と同じです。

ステップ 3：AI 統合を確認または作成する

ワークフロー A のステップ 3 と同じです。

ステップ 4：評価者を作成する

ワークフロー A のステップ 4 と同じです。変数は汎用的なものにしてください。

ステップ 5：実際の実行データから列のマッピングを特定する

実行データの構造はスパンデータとは異なります。次を確認します。

ax experiments export EXPERIMENT_NAME --dataset DATASET_NAME --space SPACE --stdout | python3 -c "import sys,json; runs=json.load(sys.stdin); print(json.dumps(runs[0], indent=2))"

実験実行でよく使われるマッピング：

• output → "output"（各実行のトップレベルフィールド）
• input → 実行データにあるか、リンクされたデータセットの例に埋め込まれているかを確認します

実行データの JSON に input がない場合は、データセットの例をエクスポートしてパスを確認します。

ax datasets export DATASET_NAME --space SPACE --stdout | python3 -c "import sys,json; ex=json.load(sys.stdin); print(json.dumps(ex[0], indent=2))"

ステップ 6：タスクを作成する

--experiment-ids には、ax experiments list --space SPACE -o json で取得した base64 ID を指定します。

ax tasks create-evaluation \
  --name "Experiment Correctness" \
  --task-type TEMPLATE_EVALUATION \
  --dataset DATASET_NAME --space SPACE \
  --experiment-ids "EXP_ID" \
  --evaluators '[{"evaluator_id": "EVAL_ID", "column_mappings": {"output": "output"}}]' \
  --no-continuous

ステップ 7：実行を開始して監視する

ax tasks trigger-run TASK_ID \
  --experiment-ids "EXP_ID" \
  --wait

ax tasks list-runs TASK_ID
ax tasks get-run RUN_ID

---

テンプレート設計のベストプラクティス

1. 汎用的で移植可能な変数名を使う

{attributes_input_value} のような特定のプロジェクトやスパン属性に結び付いた名前ではなく、{input}、{output}、{context} を使います。評価者自体は抽象的なままにし、特定のプロジェクトや実験の実際のフィールドへの紐付けは、タスクの column_mappings で行います。これにより、同じ評価者を変更せずに複数のプロジェクトや実験で実行できます。

2. 二値ラベルをデフォルトにする

明確な文字列ラベルを必ず 2 つ使います（例：hallucinated / factual、correct / incorrect、pass / fail）。二値ラベルには次の利点があります。

• 判定モデルが一貫して出力しやすい
• 業界で最も一般的
• ダッシュボードで最も解釈しやすい

ユーザーが 2 つを超える選択肢を希望する場合は、それでも問題ありません。ただし、まずは二値ラベルを推奨し、トレードオフ（ラベルが増える → 曖昧さが増す → 評価者間の一致度が下がる）を説明します。

3. モデルが何を返すべきかを明確にする

テンプレートでは、判定モデルにラベル文字列のみを返し、それ以外は何も返さないよう指示する必要があります。ラベルの出力には --classification-choices を設定し、プロンプト内のラベル文字列は、そのキーと完全に一致させます（綴りも大文字・小文字も同じにします）。自由形式（非分類）の出力の場合に限り、--classification-choices を省略します。

適切な例：

Respond with exactly one of these labels: hallucinated, factual

不適切な例（自由度が高すぎます）：

Is this hallucinated? Answer yes or no.

4. 温度を低く保つ

再現性のあるスコアリングのため、--invocation-params '{"temperature": 0}' を渡します。温度を高くすると、評価結果にノイズが生じます。

5. デバッグには --include-explanations を使う

初期設定中は常に説明を含め、ラベルを大規模に信頼して使う前に、判定モデルが正しく推論していることを確認できるようにします。

6. bash ではテンプレートをシングルクォートで渡す

シングルクォートを使うと、シェルによる {variable} プレースホルダーの展開を防げます。ダブルクォートでは問題が起こります。

# Correct
--template 'Judge this: {input} → {output}'

# Wrong — shell may interpret { } or fail
--template "Judge this: {input} → {output}"

---

トラブルシューティング

問題	解決方法
ax: command not found	references/ax-setup.md を参照してください
401 Unauthorized	API キーにこのスペースへのアクセス権がない可能性があります。https://app.arize.com/admin > API Keys で確認してください
Evaluator not found	ax evaluators get NAME_OR_ID --space SPACE（ax evaluators list --space SPACE は人間が閲覧するためのコマンドです）
Integration not found	ax ai-integrations get NAME_OR_ID --space SPACE（list は人間が閲覧するためのコマンドです）
Task not found	ax tasks get TASK_ID（ax tasks list --space SPACE は人間が閲覧するためのコマンドです）
project and dataset-id are mutually exclusive	タスクの作成時にはどちらか一方だけを使用してください
experiment-ids required for dataset tasks	create と trigger-run に --experiment-ids を追加してください
sampling-rate only valid for project tasks	データセットタスクから --sampling-rate を削除してください
project '...' not found または ax spans export の検証エラー	--space SPACE を追加してください。それでも解決しない場合は、ax projects get PROJECT --space SPACE -o json で base64 のプロジェクト ID を調べ、代わりに id フィールドを使用してください
テンプレートの検証エラー	bash では --template '...' のようにシングルクォートを使用してください。中括弧は二重ではなく、単一の {var} を使用してください
実行が pending のまま停止する	ax tasks get-run RUN_ID を実行し、その後 ax tasks cancel-run RUN_ID を実行してください
実行が completed で、スパンが 0 件	時間範囲を広げてください。評価インデックスに古いデータが含まれていない可能性があります
スコアがおかしい	--include-explanations を追加し、いくつかのサンプルについて判定の推論を確認してください
trigger-run の時刻形式エラー	2026-03-21T09:00:00 を使用してください。末尾に Z は付けません
実行失敗：「missing rails and classification choices」	ax evaluators create-evaluator template（新規）または create-evaluator-version template（既存）に --classification-choices '{"label_a": 1, "label_b": 0}' を追加してください。ラベルはテンプレートと一致する必要があります
実行が completed で、すべてのスパンがスキップされる	クエリフィルターに一致するスパンはありますが、列のマッピングが誤っているか、テンプレート変数を解決できていません。サンプルのスパンをエクスポートしてパスを確認してください
query_filter が設定されているのにスコアが付いたスパンが 0 件、または No data found	span_kind ではなく attributes.openinference.span.kind を使用してください。カスタム属性はインデックス化されていない場合があります。時間範囲内にスパンが存在することを確認するため、フィルターを削除してください
種類の異なるスパンにスコアが付く	スパンの種類のフィルターは、評価器ごとの query_filter ではなく、タスクの --query-filter に設定してください
カスタムの code 評価器の実行が約 3 秒でキャンセルされ、0/0/0（成功／エラー／スキップ）となる	インポートパスまたは evaluate() のシグネチャが誤っています。references/cli-reference.md の Custom Python code evaluators にある「CRITICAL」の注意書きを参照してください。arize.experiments ではなく arize.experimental.datasets.experiments.evaluators.base からインポートし、**kwargs だけではなく、名前付きの evaluate() パラメーターを宣言する必要があります。

キャンセルされた実行の診断

キャンセルされた実行（約 1 秒または約 3 分）、誤ったスパンの種類、列マッピングの不一致については、references/troubleshooting.md に記載された順序付きチェックリスト（認証情報 → モデル名 → 列マッピング／パスの確認 → 時間範囲 → スパンの種類 → 変数の解決）に沿って確認してください。

---

関連スキル

• arize-ai-provider-integration：LLM プロバイダー連携の全 CRUD 操作（認証情報の作成、更新、削除）
• arize-trace：スパンをエクスポートして列のパスと時間範囲を特定
• arize-experiment：実験を作成し、実験の列マッピング用に実行をエクスポート
• arize-dataset：データセットの例をエクスポートして、実行に含まれない入力フィールドを特定
• arize-prompts：Prompt Hub でプロンプトテンプレートを管理。バージョン管理されたプロンプトを評価するには、評価器と併用
• arize-link：Arize UI の評価器やタスクへのディープリンク

---

認証情報を保存して今後使用する

references/ax-profiles.md の § 認証情報を保存して今後使用する を参照してください。