llm-obs-experiment-analyzer

バックエンド

検出 — 各呼び出しの開始時に、何らかの操作を行う前に、使用するバックエンドを決定します。

1. ユーザーが呼び出しのどこかで --backend pup を指定した場合 → MCP ツールの有無にかかわらず、直ちに pup モードを使用します。手順 2〜4 は省略します。
2. アクティブなツールリストに MCP ツールがあるか確認します。正式な判定基準は、利用可能なツールに get_llmobs_experiment_summary（mcp__datadog-llmo-mcp__ のプレフィックス付き、またはプレフィックスなし）という名前のツールが含まれているかどうかです。
3. MCP ツールがある場合 → 最初から最後まで MCP モードを使用します。ツール名のバインド： アクティブなツールリストで get_llmobs_experiment_summary が表示されている正確な名前を確認し、この呼び出しでの MCP ツール呼び出しにはすべて、その正確な名前（プレフィックス付き、またはプレフィックスなし）を使用します。ほかのすべての実験ツールにも同じ命名規則を適用します。
4. MCP ツールがない場合 → pup --version を Bash 経由で実行し、pup が実行可能か確認します。"version" を含む JSON レスポンスが返れば、pup を利用できます。
5. pup が応答する場合 → 最初から最後まで pup モードを使用します。このファイルの末尾にあるツールリファレンスの付録に従って、すべての MCP ツール呼び出しを同等の pup コマンドに置き換えます。
6. どちらも利用できない場合 → 停止し、ユーザーに次のように伝えます。

   "Datadog MCP サーバーも pup CLI も利用できません。MCP サーバーを接続する（claude mcp add --scope user --transport http datadog-llmo-mcp 'https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=llmobs'）か、pup をインストールしてください。"

--backend pup は呼び出し引数のどこにあっても指定できます。スキルの処理ロジックに残りの引数を渡す前に取り除かれます。

pup の呼び出し規則：

• Bash 経由で呼び出します：pup llm-obs <subcommand> [flags]
• pup は常に JSON を出力します。MCP の結果が [{"type": "text", "text": "<json>"}] のように JSON をラップする場合とは異なり、ラップ解除せずに直接解析します。
• pup が認証エラーを返した場合は、pup auth login を実行するようユーザーに伝え、停止します。
• 並列実行：1 回のメッセージで複数の Bash ツール呼び出しを行います（各呼び出しにつき pup コマンドを 1 つ）。

呼び出し ID： 各呼び出しの開始時に、MCP ツールを呼び出す前に、8 文字の 16 進数の呼び出し ID（例：3a9f1c2b）を生成します。呼び出し全体を通じて同じ ID を使用します。

インテントのタグ付け： MCP ツールを呼び出すたびに、telemetry.intent の先頭に skill:llm-obs-experiment-analyzer[<inv_id>] — を付け、その後にツールを呼び出す理由を記述します。最初の MCP ツール呼び出しのみ、代わりに skill:llm-obs-experiment-analyzer:start[<inv_id>] — を使用します（:start サフィックスを付けます）。最初の呼び出しの例：skill:llm-obs-experiment-analyzer:start[3a9f1c2b] — Phase 1: get experiment summary to orient analysis

統合実験アナライザー

1 つまたは 2 つの LLM 実験を分析します。入力に応じて、次の 4 つのモードをサポートします。

入力	モード
ID 2 つ、質問なし	比較探索
ID 2 つ＋質問	比較 Q&A
ID 1 つ、質問なし	単一探索
ID 1 つ＋質問	単一 Q&A

使用方法

/llm-obs-experiment-analyzer <experiment_id_1> [experiment_id_2] [question text] [--output agent|file|notebook]

引数：$ARGUMENTS

利用可能なツール

注： 以下のツール名には、例として mcp__<server>__ プレフィックスが付いています。実際のプレフィックスは環境と MCP サーバー名によって異なり、まったく付かない場合もあります。必ず、現在のツール一覧に表示されている正確な名前でツールを呼び出してください（バックエンドの検出ステップ 3 を参照）。

ツール	用途
mcp__datadog-llmo-mcp__get_llmobs_experiment_summary	イベントの合計数、エラー数、メトリクスの統計、利用可能なディメンションを取得します
mcp__datadog-llmo-mcp__list_llmobs_experiment_events	フィルター、並べ替え、ページネーションを指定してイベントをクエリします
mcp__datadog-llmo-mcp__get_llmobs_experiment_event	イベントの詳細（入力、出力、expected_output、メトリクス）をすべて取得します
mcp__datadog-llmo-mcp__get_llmobs_experiment_metric_values	全体およびディメンション別にメトリクスの統計を取得します。セグメント化には segment_dimension ではなく segment_by_dimension を使用します。特定の値に絞り込む場合は、必要に応じて segment_dimension_value を指定します。
mcp__datadog-llmo-mcp__get_llmobs_experiment_dimension_values	ディメンションの一意な値を件数とともに一覧表示します
mcp__datadog-mcp-core__create_datadog_notebook	レポートを Datadog ノートブックとしてエクスポートします

---

フェーズ 0 — モードと出力先の決定

$ARGUMENTS を解析します：

1. UUID 形式の文字列を 1 つまたは 2 つ抽出し、実験 ID とします（1 つ目はベースライン／プライマリ、2 つ目は候補です）。
2. --output agent|file|notebook フラグがあれば抽出します。
3. ID とフラグを除いた残りのテキストを、質問（ある場合）とします。

モードの決定：

• ID が 2 つ、質問あり → 比較 Q&A
• ID が 2 つ、質問なし → 比較探索
• ID が 1 つ、質問あり → 単一 Q&A
• ID が 1 つ、質問なし → 単一探索

出力モードの決定：

引数に --output が指定されている場合は、そのモードを使用し、確認を求めません。

それ以外の場合は、処理を進める前に AskUserQuestion を個別に 2 回続けて呼び出します。1 回にまとめてはいけません。

1. 分析の種類：引数に質問文が含まれていない場合、探索的分析を希望するか、具体的な質問があるかを尋ねます。ID と一緒に質問を入力するなど、ユーザーの意図が文脈からすでに明らかな場合に限り、この呼び出しを省略します。
2. 出力先：--output が指定されていない場合、レポートの出力先（チャット、ファイル、Datadog ノートブック）を尋ねます。必ず独立した呼び出しとして尋ねます。

出力モード：

1. エージェント（デフォルト）： 会話にレポート全体を表示します。
2. ファイル： 開始前に次のパスを提案します： evals/reports/YYYY-MM-DD-<experiment-slug>-analysis.md このパスをユーザーに提示し、確認または変更をしてもらってから処理を進めます。
3. ノートブック： 最後に mcp__datadog-mcp-core__create_datadog_notebook を使用します。pup モードでは、代わりに pup notebooks create --title "TITLE" --file /tmp/nb_cells.json を使用します（ツールリファレンスを参照）。MCP も pup も利用できない場合は、失敗として終了するのではなく、次のセットアップ手順を出力します：

   To enable Datadog notebook export, add the MCP server:
     claude mcp add --transport http datadog-mcp https://mcp.datadoghq.com/api/unstable/mcp-server
   See: https://docs.datadoghq.com/bits_ai/mcp_server/setup/
   

   その後、次のように尋ねます：「代わりにファイルまたはエージェントの出力に切り替えますか？」 ノートブック呼び出しの詳細については、フェーズ 5 を参照してください。

モードと出力先を決定したら、フェーズ 1 に進みます。詳細な分析を開始する前に、フェーズ 1.5 で追加の AskUserQuestion によるやり取りが 1 回あります。

---

フェーズ 1 — 状況把握

比較： 両方の実験に対して get_llmobs_experiment_summary を呼び出します。左右に並べて比較します。

• 規模：それぞれの総サンプル数とエラー数
• メトリクス：それぞれに存在するメトリクス、および共通するメトリクス
• ディメンション：それぞれに存在するディメンション、および共通するディメンション
• すぐに確認すべき問題点（エラーの有無、メトリクスの欠落、データの少なさ）
• サマリーから明らかな改善点や悪化点

error_count > 0 の場合は、get_llmobs_experiment_dimension_values を error_type に対して呼び出し、例外クラスごとの内訳を報告します（例：「2 件のエラー：asyncio.exceptions.cancellederror」）。エラーは、エグゼキューターが未処理例外をスローしたことを意味します。該当サンプルの評価スコアは生成されていません。割合は報告せず、件数とタイプを報告してください。

単一： 該当する実験に対して get_llmobs_experiment_summary を呼び出します。次の項目を確認します。

• 総サンプル数とエラー数（0 以外の場合は error_type の内訳も含めます）
• サマリーで返された metric_type（score、boolean、categorical）ごとに分類した、利用可能なメトリクス。ラベル名や接頭辞のパターンから、意味上のグループやカテゴリを推測しないでください。ラベル文字列は、メトリクスが何を測定するかを示す信頼できる手がかりではありません。
• サマリーですでに返されている統計値（平均、最小値、最大値）を使って、各メトリクスを分類します。ラベル名や接頭辞からメトリクスの意味を推測しないでください。レポート全体でメトリクスに言及する際は、フェーズ 1.5 で定義される分類を使用してください。
• セグメンテーションに利用できるディメンション
• すぐに確認すべき問題点

フェーズ 1.5 — メトリクスの選択

フェーズ 1 の完了後、AskUserQuestion を実行する前に、以下の 3 つのステップを実行してください。

ステップ 1 — すべてのメトリクスを分類する（追加のツール呼び出しは行わず、要約統計のみを使用します）。

クラス	条件	意味
always_zero	max == 0	機能が無効または未実装 — シグナルなし
perfect	min == 1	常に合格 — 診断シグナルなし
saturated	mean ≥ 0.99 and min < 1	失敗することはまれ — 診断価値が低い
struggling	mean < 0.70	意味のある失敗率 — 診断価値が最も高い
interesting	0.70 ≤ mean < 0.99 and min < max	部分的な失敗 — 診断価値は中程度

ステップ 2 — 質問する前に、メトリクスの表全体をチャットに表示する。 これにより、オプション数の制限で省略されることなく、ユーザーがすべてを確認できます。形式：

Found N metrics. Full breakdown:

| Metric | Mean | Class |
|--------|------|-------|
| <label> | <mean> | ⚠️ Struggling |
| <label> | <mean> | Interesting |
| <label> | <mean> | Saturated |
| <label> | 1.000 | Perfect (no signal) |
| <label> | 0.000 | Always zero (disabled?) |

always_zero のメトリクスには注記を付けてください。例：「N 個のメトリクスは常に 0 点で、無効な機能と思われるため、提案するグループから除外されます。」

ステップ 3 — 算出されたクラスだけを使って、AskUserQuestion のオプションを作成する：

実際のデータに含まれる内容に基づいて、オプションを動的に生成します。ラベルの接頭辞からオプション名を作り出してはいけません。

• 「苦戦しているメトリクス（N 件）— 推奨」：N ≥ 1 の場合のみ表示します。説明には、各メトリクスのラベルと平均値を明記します（例：open_answer 0.33、c_permanence 0.68）。これはラベル名ではなく、観測された合格率に基づく、根拠のある提案です。苦戦しているメトリクスがない場合は、このオプションを 「パフォーマンスが最も低いメトリクス（N 件）」 に置き換え、平均値が低い順に N 件を対象とします。
• 「興味深いメトリクスと苦戦しているメトリクス（N 件）」：苦戦しているメトリクスに加えて、interesting クラスのメトリクスがある場合のみ表示します。説明には、各メトリクスと平均値を記載します。
• 「すべてのメトリクス（N 件）」：常に表示します。説明には、常に 0 点のメトリクスと常に合格するメトリクスはノイズになりますが、含まれることを明記します。
• 「特定のメトリクス」：常に表示します。説明には次のように記載します：「上に表示された表から 1 つ選択してください。」

ユーザーが「特定のメトリクス」を選んだ場合、平均値が最も低い 4 つのメトリクスをラベル付きオプションとして表示する 2 つ目の AskUserQuestion を行います（ラベル = メトリクス名、説明 = mean: X.XX — class）。質問文には、次の内容を明記します：「または、上の表にある任意のメトリクス名を「その他」に入力してください。」 always_zero と perfect のメトリクスには診断価値がないため、4 つのオプションに含めてはいけません。struggling と interesting のクラスだけを対象にします。ユーザーが 1 つ選んだら、フェーズ 2〜4 の分析はすべてそのメトリクス 1 つだけに限定します。

対象範囲の適用：

• ユーザーが「すべて」を選んだ場合は、定数のメトリクスもすべて含めて処理を進めます。ただし、それらのシグナル値が低いことを注記してください。
• ユーザーがグループまたは特定のメトリクスを選んだ場合、フェーズ 2〜4 の分析はすべて、その選択範囲に厳密に限定します。選択範囲外のメトリクスについて get_llmobs_experiment_metric_values を呼び出してはいけません。

フェーズ 2 — シグナルの発見＋UI リンク

比較モード： フェーズ 1.5 で選択したメトリクス（共通メトリクスとの積集合）と共通ディメンションのみを使用して、以下を特定します。

• 候補がベースラインを上回るセグメント
• 候補の成績が低下するセグメント
• 一方には存在するが、もう一方ではまれなエラータイプ
• 分布の変化やカバレッジの不足
• トレードオフ（例：再現率の向上、適合率の低下）

Datadog の比較 UI リンクを生成します。

• ベース URL：https://app.datadoghq.com/llm/experiment-comparison
• 必須パラメーター：baselineExperimentId、experimentIds（candidate%2Cbaseline）、tableView=all
• 任意（特定できる場合に含める）：project、compareDatasetId、selectedEvaluation
• selectedEvaluation の優先順位：overall/overall_score/rubric メトリクス → プライマリメトリクス → 最初の共通メトリクス
• 2～4 個のリンクを生成します：主要な比較、回帰ビュー、キャリブレーションビュー（該当する場合）、最悪のセグメントのビュー（対応している場合のみ。フィルターを決して捏造しないでください）

単一モード： フェーズ 1.5 で選択したメトリクスのみを対象に、すべてのディメンションにわたるメトリクスごとのパフォーマンスを測定します。以下を特定します。

• 最もパフォーマンスの低いセグメント（メトリクス × ディメンション別）
• 合格率が予想外のセグメント
• 全体の合格率と分散

Datadog の実験 UI リンクを生成します。

• https://app.datadoghq.com/llm/experiments/{experiment_id}

---

フェーズ 3 — 詳細分析

必要な詳細分析をすべて自動的に実施します。承認を求めたり、処理を一時停止したりしないでください。すべての詳細分析の対象をフェーズ 1.5 で選択したメトリクスのみに厳密に限定し、選択範囲外のメトリクスについて get_llmobs_experiment_metric_values を呼び出さないでください。

Q&A モード： 質問に直接答えるために必要な内容に絞って詳細分析を行います。特定のサンプルを取得し、関連するディメンションごとにセグメント化して、例を確認します。

探索モード： 最も興味深いシグナルを幅広く調査します。

• セグメントごと、クラスごとの変化分析（比較モード）、または合格率分析（単一モード）
• エラーの重複と固有の失敗モードの分析
• 代表的な失敗例のサンプリングと定性的な確認（問題ごとに 2～5 件）
• エラーのテーマをクラスタリングして分析

ルール：

• まず、低コストでシグナルの強い分析を優先し、早期に終了しないでください。
• すべての出力で PII をマスクまたは編集してください。
• 破壊的な操作は避けてください。

サンプリングした各イベントについて、スパンへの直接リンクを生成します。 https://app.datadoghq.com/llm/experiments/{experiment_id}?selectedTab=overview&sp=[{"p":{"experimentId":"{experiment_id}","spanId":"{span_id}"},"i":"experiment-details"}]&spanId={span_id} sp クエリパラメーターの値は、表示する前にパーセントエンコードする必要があります（例：[ → %5B、{ → %7B、" → %22、} → %7D、] → %5D）。

各詳細分析セグメントについて、（候補の）実験で該当サンプルを表示するための直接リンクを生成します。 https://app.datadoghq.com/llm/experiments/{experiment_id}?selectedTab=overview&filter[{dimension}]={value} そのディメンションでこのフィルター URL 形式が機能する確信がない場合は、フィルターパラメーターを省略して、実験のルートにリンクしてください。フィルター URL を決して捏造しないでください。

フェーズ 4 — 統合

比較探索型：

• 候補がベースラインを改善している点での明確な優位性
• 候補がもたらす明確な後退やリスク
• 中立的または変化のない領域
• 根本原因に関する仮説（1～4 件）。根拠と関連付けてください
• 優先順位を付けた推奨事項：そのままリリース／ブロック／セグメントごとに条件を設定／挙動を組み合わせる

比較 Q&A：

• 明確な判定を添えた質問への直接的な回答
• 根拠となる情報（メトリクス、割合、イベントの例）
• 関連する背景情報（注意点、データの制約など）

単一探索型：

• 全体的なパフォーマンス評価
• パフォーマンスが最も低いセグメントと根本原因
• 失敗が発生する理由に関する仮説
• 推奨する次の実験

単一 Q&A：

• 明確な判定を添えた質問への直接的な回答
• 実験データに基づく根拠

すべてのモードで、詳細な調査結果の前に、問題の種類ごとの件数を 1 行で示してください。例：「エージェントの問題 3 件、評価者／データセットの問題 1 件、曖昧な問題 1 件」。可能な限り、差分や割合を定量化してください。PII は伏せてください。

実験の複雑さ、メトリクスの数、回答が明らかになるまでの速さにかかわらず、必ず ## Summary & Recommendations と ## Synthesis の両セクションを出力してください。 調査結果が単純または明白だからといって、Summary を省略しないでください。Deep Dives ですでに調査結果を説明したからといって、Synthesis を省略しないでください。この 2 つのセクションは、分析結果の中で最も再利用しやすい部分です。読者が最初と最後に目にする内容です。

---

フェーズ 5 — 出力の提供

エージェント： 以下のレポート形式で、完全なレポートを会話内に提示してください。

ファイル： 事前に確認したパスにレポートを保存してください。次のように確認してください：「レポートを <path> に保存しました。」

ノートブック： 次のパラメーターを指定して mcp__datadog-mcp-core__create_datadog_notebook を呼び出してください。

• name（モード別）：

  モード	名前
  比較探索型	Experiment Analysis: {baseline_short} (Baseline) vs {candidate_short} (Candidate) — YYYY-MM-DD
  比較 Q&A	Experiment Q&A: {baseline_short} vs {candidate_short} — YYYY-MM-DD
  単一探索型	Experiment Analysis: {experiment_short} — YYYY-MM-DD
  単一 Q&A	Experiment Q&A: {experiment_short} — YYYY-MM-DD
  ここで short は UUID の先頭 8 文字です。

• cells：レポートのセクションごとに 1 つのセルを作成してください。レポート全体を 1 つのセルに入れないでください。構成：

  • セル 1 — Summary & Recommendations。次の 3 つの ### サブヘッダーを含めてください：Experiment（リンク＋エグゼクティブサマリー）、Key Findings（箇条書き）、Recommendations（番号付きリスト）。必ず含め、必ず最初に配置し、実験の複雑さにかかわらず省略しないでください
  • セル 2 — 概要テーブル
  • セル 3 — 変更点（比較モードのみ。単一モードでは省略）
  • セル 4 — シグナル／質問への回答
  • セル 5～N — 詳細な調査結果ごとに 1 つのセル
  • セル N+1 — Synthesis（問題の件数、全体的なパフォーマンス評価、パフォーマンスが最も低いセグメント、根本原因の仮説、推奨する次の実験）。必ず含め、必ず最後から 2 番目に配置してください
  • セル N+2 — UI リンク

  # Experiment Analysis Report のトップレベル見出しは、ノートブックのタイトルとして表示されるため、すべてのセルから省略してください。

• time：{ "live_span": "1h" }

ノートブックの作成後、チャットに URL を出力してください：「レポートをノートブックにエクスポートしました：」

ツールを利用できない場合は、フェーズ 0 のフォールバック手順に従ってください。

---

フェーズ 6 — 会話形式でのフォローアップ

レポートを提供した後、次のフォローアップセクションを追加してください。

---
## Want to explore further?

Here are a few directions based on the findings:

1. [Specific question derived from actual findings — e.g., "Want me to dig deeper into why the SQL scenarios regressed in the candidate?"]
2. [Another specific follow-up — e.g., "Should I compare error patterns between the two failing clusters?"]
3. [A third option if relevant]
4. [If failures or regressions were found: "To investigate production failures driving these results, run `/llm-obs-trace-rca` on the same ml_app."]

Do you have any other questions about this analysis?

レポートの提供後も対応を続けてください。同じ MCP ツールを使い、すでに収集した調査結果を参照してフォローアップの質問に回答してください。新しい質問への回答に必要な場合を除き、実施済みの分析を再実行しないでください。

---

レポート形式

リンクのルール：

• 実験 ID：完全な実験 UUID が記載されている箇所では、https://app.datadoghq.com/llm/experiments/{full_uuid} への Markdown リンクとして表示してください。
• 比較テーブルの列見出し：Orientation テーブルおよび、それ以降の Baseline／Candidate 列があるすべてのテーブルでは、短い ID だけでなく、列見出し全体をリンクにしてください。形式：[Baseline \{short_id}`]({baseline_url})およびCandidate `{short_id}``。これにより、ID 部分だけでなく、列見出しのセル全体をクリックできるようになります。

# Experiment Analysis Report

> **Question:** {original question text}
> _(Q&A modes only — omit for Exploratory modes)_

## Summary & Recommendations

### Experiment

[Comparative: [`{baseline_short}`]({baseline_url}) (Baseline) vs [`{candidate_short}`]({candidate_url}) (Candidate) — [Compare]({compare_url}) — Single: [`{experiment_short}`]({experiment_url})]

[2–3 sentence executive summary. Open with "This is a **{Mode}** analysis..." where {Mode} is one of: Comparative Exploratory, Comparative Q&A, Single Exploratory, Single Q&A. Include experiment(s) purpose, scale, and the headline finding with specific numbers.]

[If the report uses opaque dimension values (e.g. category labels like b1/b2/b3/bx), add a `#### Dataset Categories` sub-subsection here — one bullet per value with name bolded and a brief description. Omit if all dimension values are self-explanatory.]

### Key Findings

- **{Finding 1}**: one-line description with numbers (e.g. "+4.2pp on `tool_accuracy` across all segments")
- **{Finding 2}**: one-line description
- **{Finding 3}** (if present): one-line description
[For Q&A modes: one-line verdict bullet + one-line rationale bullet]

### Recommendations

1. **{Recommendation 1}**: specific, actionable next step tied to a finding
2. **{Recommendation 2}**: specific, actionable next step
3. **{Recommendation 3}** (if present): specific, actionable next step
[Omit this subsection for Q&A modes unless a clear action follows from the answer.]

## Orientation

[Side-by-side table for comparative; summary table for single. Include: samples, errors (count + `error_type` breakdown if non-zero, otherwise "none"), metrics, dimensions. Experiment IDs in column headers must be Markdown links.]


## What Changed

[Comparative modes only. Table of differences between baseline and candidate: model, toolset/skill profile,
dataset, evaluator schema, and any other metadata differences detectable from the summary data.
If no differences are detectable, write: "No configuration differences detected between experiments."]

## [Signals | Answer to Question]

[For exploratory: ranked table of signals/segments with metric deltas and impact counts.]
[For Q&A: direct answer with verdict, then supporting evidence.]

## Deep Dive Findings

### [Issue/Finding Title]

**Segment**: `[dimension=value]` | **Impact**: N samples | **Severity**: metric pass rate = X% | [View samples](https://app.datadoghq.com/llm/experiments/{experiment_id}?selectedTab=overview&filter[{dimension}]={value})

**Issue type**: `Agent` — the evaluator is sound; the agent output is the problem. | `Evaluator/Dataset` — the agent output may be correct; the rubric, ground truth labels, or scoring logic is suspect. | `Ambiguous` — cannot determine from available evidence whether the agent or evaluator is at fault; flag for manual inspection.

**What's happening**: [1–2 sentences: key observation and metric impact only]

**Representative examples**:
- [Span link]: [input → output → expected, what went wrong]

**Root cause hypothesis**: [Category]: [Explanation tied to evidence]

**Recommendation**: [Specific, actionable next step]

---
[Repeat for each major issue]

## Synthesis

[Required in all modes. Comes after all Deep Dive Findings, before UI Links.]

**Issue tally**: [N agent issues, N evaluator/dataset issues, N ambiguous]

### Overall Performance Assessment
[2–4 sentences on overall quality: what the experiment shows, whether the app/model is production-ready on this task, key numbers.]

### Worst-Performing Segments
[Bullet list: which dimension values or conditions most reliably predict failure. Include metric values.]

### Root Cause Hypothesis
[The single most likely root cause across all findings. If multiple independent root causes, list them ranked by impact. Each hypothesis must be tied to specific evidence, not to label names or general reasoning.]

### Recommended Next Experiments
[2–4 concrete, specific follow-up experiments. Each should be actionable: e.g. "Re-run with `max_turns=40` to test whether turn exhaustion is the primary driver, not model quality" not "Investigate turn limits further."]

## UI Links

[All generated Datadog UI links with labels]

---

運用ルール

• 実験について（モデル、タスク、メトリクス、スキーマ、ディメンション）何も決めつけないでください。データを調べてすべて推測してください。
• すべての結論を具体的な根拠（イベント ID、件数、割合）に基づかせてください。
• 定性的な主張だけでなく、件数と割合を示して計算過程を明らかにしてください。
• 観測された根拠に裏付けられていない、推測的な説明は避けてください。
• ユーザーに表示するすべての出力で、PII をマスキングまたは削除してください。

---

ツールリファレンス

この付録は pup モードでのみ適用されます。MCP モードでは、ワークフローの各セクションに記載されているツール名を直接使用してください。

実験

MCP ツール	pup コマンド
get_llmobs_experiment_summary(experiment_id)	pup llm-obs experiments summary EXPERIMENT_ID
list_llmobs_experiment_events(experiment_id, ...)	pup llm-obs experiments events list EXPERIMENT_ID [--filter-metric-label L] [--sort-by-metric M] [--sort-direction asc|desc] [--limit N] — 使用前に pup llm-obs experiments events list --help でフィルター／ソートのフラグ名を確認してください
get_llmobs_experiment_event(experiment_id, event_id)	pup llm-obs experiments events get EXPERIMENT_ID EVENT_ID
get_llmobs_experiment_metric_values(experiment_id, metric_label, ...)	pup llm-obs experiments metric-values EXPERIMENT_ID --metric-label L [--segment-by-dimension D] [--segment-dimension-value V]
get_llmobs_experiment_dimension_values(experiment_id, dimension_key)	pup llm-obs experiments dimension-values EXPERIMENT_ID --dimension-key K

ノートブック

MCP ツール	pup コマンド
create_datadog_notebook(name, cells, ...)	pup notebooks create --title "TITLE" --file /tmp/nb_cells.json — 正確なフラグを pup notebooks create --help で確認してください

セルファイルは、セルオブジェクトの JSON 配列です。

[{"attributes": {"definition": {"type": "markdown", "text": "## Section\n\nContent."}}, "type": "notebook_cells"}]

• 内部ツールの呼び出し、スキーマ、実装の詳細をユーザーに表示しないでください。