• Projects
  • Service
  • About
  • branding.bz
  • Podcast
  • Tips
  • FAQ
  • Recruit
  • Download
  • Contact
  • branding.bz(ブランド構築SaaS)
  • DESIGN NOW(デザインメディア)
  • X
  • LinkedIn
  • Spotify
  • Facebook

213-0011 神奈川県川崎市高津区久本3-6-7-303

© 2026 ID INC. All rights reserved

claude-skills/スキル
SKILLOfficialmonitoring

investigate-ai-session

プラグイン
amplitude
ソース
GitHub で見る ↗
説明

AI エージェント(自動意思決定・実行プログラム)のセッション(実行記録)や障害パターンを詳しく分析し、何が問題だったのかを説明します。 ユーザーのプロジェクトに Amplitude Agent Analytics(実行状況の監視ツール)が組み込まれている場合のみ使用できます。 次のような場合に使用: - 特定のセッション ID を調査する - エージェントの障害をデバッグする - 結果の品質が低い理由を理解する - ツールのエラーを追跡する - monitor-ai-quality が検出した問題の根本原因を分析する必要がある

原文を表示

Deep-dives into specific AI agent sessions or failure patterns to explain why something went wrong. Only use when the user has Amplitude Agent Analytics instrumented in their project. Use when investigating a specific session ID, debugging agent failures, understanding why quality is low, tracing tool errors, or when monitor-ai-quality surfaces an issue that needs root cause analysis.

ユースケース
  • 特定のセッション ID を調査する
  • エージェントの障害をデバッグする
  • 結果の品質が低い理由を理解する
  • ツールのエラーを追跡する
  • 検出された問題の根本原因を分析する
本文(日本語訳)

AI セッション調査官

AI エージェント(自動処理プログラム)の特定のセッション(やり取りの記録)や障害パターンを調査して、根本的な原因を特定する役割を担っています。セッションと実行スパン(処理の流れ)のレベルで動作し、会話を読み、実行を追跡し、障害をその発生源に結びつけます。これは /monitor-ai-quality による「何が起きたのか」に続く「なぜ起きたのか」を明らかにするスキルです。

手順

ステップ1:調査の対象範囲を決める

ユーザーが次のいずれかを提供します。選んだ項目に沿って進めてください:

  • 特定のセッション ID → ステップ2に直進
  • 障害パターン(例:「チャートエージェントがタイムアウトする」「昨日のツールエラー」)→ ステップ1bへ
  • ユーザーからの訴え(例:「ユーザーXがエージェントが動作しないと言っている」)→ ステップ1cへ
  • 曖昧な兆候(例:「エージェントの動作がおかしい」)→ まず /monitor-ai-quality にリダイレクトし、具体的な発見が得られたら戻ってくる

ステップ1b:パターンに合致するセッションを探す

まず Amplitude:get_amplitude_agent_analytics_info を view: "schema" で呼び出し、有効なエージェント名、ツール名、評価フィールドを確認します。その後、view: "sessions" と以下のサポートされたフィルターで呼び出します:

  • エージェントの障害: agentNames: ["<エージェント>"], hasTaskFailure: true
  • ツール エラー: toolNames: ["<ツール>"], hasTaskFailure: true
  • 技術的障害: hasTechnicalFailure: true
  • 低い品質: 最近のセッションを取得し、評価の品質スコアが 0.4 以下のものを選別
  • 不満を持つユーザー: hasNegativeFeedback: true、または評価のセンチメント(好意度)スコアが 0.4 以下のものを選別
  • 高コストのセッション: minCostUsd: <閾値>
  • 遅いセッション: minDurationMs: <閾値>
  • 特定のトピック: 最近のセッションを取得し、評価のトピック分類を手作業で照合

responseFormat: "concise"、limit: 20、"-session_start" でソートして最新の例を取得します。深く調査する代表的なセッション 3~5 個を選びます。

ステップ1c:特定ユーザーのセッションを探す

Amplitude:get_amplitude_agent_analytics_info を view: "sessions" とサポートされているユーザー識別子フィルターで呼び出して、そのユーザーのセッションを検索します。訴えで特定の時間帯が示されている場合は、日付フィルターを追加します。訴えに合致するセッションを選びます。

ステップ2:セッションの詳細調査(予算:3~6 回の呼び出し)

調査対象の各セッション(最大 3~5 個)につき、以下を並行実行します:

  1. 完全なセッション詳細。 Amplitude:get_amplitude_agent_analytics_info を view: "sessions"、sessionIds: ["<id>"]、responseFormat: "detailed" で呼び出します。これにより、ルーブリック(評価基準)スコア、障害理由、トピック分類、全体的な結果、品質フラグなどの充実したデータが返されます。

  2. 会話の記録。 Amplitude:get_amplitude_agent_analytics_info を view: "conversation" とセッション ID で呼び出します。ユーザーとエージェント間の完全なやり取りを読み、何が尋ねられたか、エージェントがどう応答したか、どこで問題が生じたかを理解します。

  3. 実行トレース。 Amplitude:get_amplitude_agent_analytics_info を view: "spans" とセッション ID で呼び出します。この情報は、すべての言語モデル呼び出し、ツール呼び出し、埋め込み操作(テキストを数値に変換する処理)を示し、その遅延、ステータス、コスト、順序を表示します。以下の点を確認します:

    • status: "ERROR" のスパン — 直接的な障害
    • 遅延が大きい(10 秒以上)ツール呼び出し — タイムアウトや遅い依存関係
    • 同じツールの複数回の再試行 — エージェントが困っている兆候
    • 異常に多いトークン数の言語モデル呼び出し — プロンプト(指示)の膨張の可能性
    • 操作の順序 — エージェントが適切な流れで進めたか?

ステップ3:根本原因分析

会話、トレース、充実したデータを基に診断を構築します:

  1. 障害タイプを分類する:

    • ツール障害: ツール呼び出しがエラーを返すか、タイムアウトした。スパンのステータスとエラー詳細を確認します。正しいツールを選んだか?エージェントが有効な入力を渡したか?
    • 言語モデル障害: モデルが不正な応答を出した — 架空の情報の生成、拒否、不正な形式、または無限ループ。会話で応答がおかしくなったポイントを確認します。
    • オーケストレーション(処理の流れ)障害: エージェントが誤ったツールを選んだ、誤った順序で呼んだ、または早すぎめに諦めた。スパンの実行順序をトレースします。
    • ユーザーの混乱: ユーザーのリクエストが曖昧または実行不可能だった。エージェントが明確化を求めなかった。最初の 1~2 ターンを確認します。
    • データ・文脈の問題: エージェントが不十分な情報を持っていた — スキーマ(データ構造)の欠落、誤ったプロジェクト、古いデータ。利用可能だった文脈を確認します。
  2. 範囲を判断する: 一度きりか、体系的か?

    • パターン調査(ステップ1b)の場合:すべての障害セッションが同じ障害タイプ、ツール、またはエージェントを共有しているか確認します。Amplitude:get_amplitude_agent_analytics_info を view: "sessions" で呼び出し、サポートされているセッション レベルのフィールドでグループ化し、評価結果からトピックを手作業で集計します。
    • 単一セッションの場合:Amplitude:get_amplitude_agent_analytics_info を view: "sessions" と同じエージェント・時間枠で呼び出し、同様の障害が存在するか確認します。
  3. 引き金を特定する: 何が変わったか?

    • 障害が特定の日付から始まったか確認(新しい展開、モデル変更、設定更新)
    • 障害が特定のトピックやユーザー層と相関しているか確認
    • Amplitude:get_amplitude_agent_analytics_info を view: "tool_reliability" で呼び出し、ツールのエラー率が変わったか確認

ステップ4:関連するパターンを検索(予算:1~2 回の呼び出し)

セッションデータだけでは根本原因が明確でない場合:

  1. 関連セッションを探す。 Amplitude:get_amplitude_agent_analytics_info を view: "sessions" とサポートされているエラーフィルターで呼び出し、評価トピックを手作業で比較して、同じ問題の他のセッションを見つけます。

  2. ツール・モデルの健全性を確認。 Amplitude:get_amplitude_agent_analytics_info を view: "tool_reliability" でツール健全性について、または view: "spans" を関連時間枠でモデルでグループ化して呼び出します。エラー率や遅延が上昇しているツール、障害セッションと相関するものを探します。

ステップ5:調査結果を提示する

根本原因分析として出力を構成します。

必須セクション:

  1. 調査サマリー(2~3 文):何を調査したか、何を発見したか、深刻度。チーム向けのヘッドラインとして記述します。

  2. 調査したセッション: 調査対象セッションのコンパクトな表

| セッション ID | エージェント | 結果 | 品質 | センチメント | 障害タイプ |
|------------|--------|------|------|---------|---------|
| [id] | [名前] | [結果] | [スコア] | [スコア] | [タイプまたは —] |
  1. 根本原因(1 段落):何が問題だったのかの主な説明。具体的に — ツール名、エラー、モデルの動作、またはオーケストレーション問題を挙げます。会話とトレースからの証拠を含めます。

  2. 実行トレースのハイライト(最も説明的なセッション向け):障害経路を示す重要なスパンをウォークスルーします:

    • 「ターン 1:ユーザーが X を尋ねた → エージェントがツール Y を呼び出した(OK、2.1 秒)→ エージェントがツール Z を呼び出した(エラー、30 秒後にタイムアウト)→ エージェントが質問に対応しないフォールバック応答を返した」
    • 障害ポイントとそれに至った経緯に焦点を当てます
  3. 会話の抜粋(明らかな場合):エージェントがユーザーに失敗した場所を示す最も関連する 2~3 ターンを引用します。簡潔に。

  4. 範囲評価: 一度きり vs. 体系的か。影響を受けるセッションは何個か?悪化しているか?

  5. 推奨修正(2~4 項目):具体的なアクション。例:

    • 「query_amplitude_data ツールに指数バックオフ(段階的な待機時間)で再試行を追加する — 15 件中 8 件の障害は一時的なタイムアウト」
    • 「エージェントが get_amplitude_context より前に manage_amp_events を呼び出しており、プロジェクト ID がない状態になっている — エージェントプロンプト内のツール順序を修正」
    • 「リテンション(継続率)について尋ねるユーザーが Funnel Agent ではなく Chart Agent にルーティングされている — ルーティングロジックを更新」
  6. フォローアップ提案: 次のステップを提示 — 「このツールタイムアウトが他のエージェントに影響するか確認、類似のユーザー訴えを検索、この数日間このパターンを監視することをお望みですか?」

例

例 1:特定セッションの調査

ユーザー:「セッション abc-123 で何が起きたのか?」

実行内容:

  1. abc-123 の詳細セッション、会話、スパンデータを取得(3 つの並行呼び出し)
  2. 会話を読んでユーザーが何を望んでいたか理解
  3. スパンをトレースして実行のどこが失敗したか確認
  4. 障害を分類し、それが体系的か確認
  5. トレースハイライトと会話抜粋で根本原因を提示

例 2:パターン調査

ユーザー:「なぜ Chart Agent のセッションが失敗するのか?」

実行内容:

  1. AI スキーマを取得して「Chart Agent」が有効なエージェント名か確認
  2. 最近の Chart Agent 障害をクエリ(hasTaskFailure: true, agentNames: ["Chart Agent"])
  3. 最も代表的な 3 件の障害を詳細調査
  4. 障害を比較 — 同じツール?同じエラー?同じトピック?
  5. スパン集計でツール健全性を確認
  6. パターンと根本原因および範囲評価で提示

例 3:ユーザー訴え

ユーザー:「顧客が昨日、私たちの AI から誤ったデータを受け取ったと言っている」

実行内容:

  1. 顧客のメールアドレスまたはユーザー ID を尋ねる
  2. 昨日のセッションを検索
  3. 関連セッションを詳細調査
  4. 会話を読んで、どのデータが誤っていたか確認
  5. スパンをトレースして、どのツールがデータを提供したか確認
  6. エラーを示す特定の会話抜粋で調査結果を提示

トラブルシューティング

セッション ID が見つからない

セッションが異なるプロジェクトのもの、またはデータ保持ウィンドウ

原文(English)を表示

AI Session Investigator

You investigate specific AI agent sessions or failure patterns to determine root causes. You operate at the session and span level — reading conversations, tracing execution, and connecting failures to their origins. This is the "why" skill that follows the "what" from /monitor-ai-quality.

Instructions

Step 1: Determine Investigation Scope

The user will provide one of:

  • A specific session ID → go directly to Step 2
  • A failure pattern (e.g., "Chart Agent timeouts", "tool errors in the last day") → go to Step 1b
  • A user complaint (e.g., "user X said the agent didn't work") → go to Step 1c
  • A vague signal (e.g., "something's off with the agents") → redirect to /monitor-ai-quality first, then come back with specific findings

Step 1b: Find Sessions Matching a Pattern

Call Amplitude:get_amplitude_agent_analytics_info with view: "schema" to discover valid agent names, tool names, and evaluator fields. Then call it with view: "sessions" and supported filters:

  • Agent failures: agentNames: ["<agent>"], hasTaskFailure: true
  • Tool errors: toolNames: ["<tool>"], hasTaskFailure: true
  • Technical failures: hasTechnicalFailure: true
  • Low quality: fetch recent sessions, then select evaluator quality scores at or below 0.4
  • Frustrated users: hasNegativeFeedback: true, or select evaluator sentiment scores at or below 0.4
  • Expensive sessions: minCostUsd: <threshold>
  • Slow sessions: minDurationMs: <threshold>
  • Specific topic: fetch recent sessions, then select matching evaluator topic classifications locally

Use responseFormat: "concise", limit: 20, and sort by "-session_start" to get recent examples. Select the 3-5 most representative sessions for deep investigation.

Step 1c: Find a Specific User's Sessions

Call Amplitude:get_amplitude_agent_analytics_info with view: "sessions" and the supported user identifier filter to find their sessions. If they reported a specific timeframe, add the date filters. Pick the session(s) that match the complaint.

Step 2: Deep-Dive into Sessions (Budget: 3-6 calls)

For each session being investigated (max 3-5 sessions), run these in parallel per session:

  1. Full session detail. Call Amplitude:get_amplitude_agent_analytics_info with view: "sessions", sessionIds: ["<id>"], and responseFormat: "detailed". This returns enrichment data: rubric scores, failure reasons, topic classifications, overall outcome, and quality flags.

  2. Conversation transcript. Call Amplitude:get_amplitude_agent_analytics_info with view: "conversation" and the session ID. Read the full user-agent exchange to understand what was asked, how the agent responded, and where things broke down.

  3. Execution trace. Call Amplitude:get_amplitude_agent_analytics_info with view: "spans" and the session ID. This shows every LLM call, tool call, and embedding operation — their latency, status, cost, and ordering. Look for:

    • Spans with status: "ERROR" — direct failures
    • Tool calls with high latency (>10s) — timeouts or slow dependencies
    • Multiple retries of the same tool — agent struggling
    • LLM calls with unusually high token counts — potential prompt bloat
    • The sequence of operations — did the agent take a reasonable path?

Step 3: Root Cause Analysis

With conversation + trace + enrichment data, build the diagnosis:

  1. Classify the failure type:

    • Tool failure: A tool call returned an error or timed out. Check the span's status and error details. Was it the right tool? Did the agent pass valid inputs?
    • LLM failure: The model produced a bad response — hallucination, refusal, wrong format, or infinite loop. Check the conversation for where the response diverged.
    • Orchestration failure: The agent chose the wrong tools, called them in the wrong order, or gave up too early. Trace the span sequence.
    • User confusion: The user's request was ambiguous or impossible. The agent failed to clarify. Check the first 1-2 turns.
    • Data/context issue: The agent had insufficient context — missing schema, wrong project, stale data. Check what context was available.
  2. Determine scope: Is this a one-off or systemic?

    • If investigating a pattern (Step 1b), check: Do all failing sessions share the same failure type, tool, or agent? Use Amplitude:get_amplitude_agent_analytics_info with view: "sessions" and group by a supported session-level field; aggregate topics locally from evaluator results.
    • If a single session, call Amplitude:get_amplitude_agent_analytics_info with view: "sessions" and the same agent and time window to check if similar failures exist.
  3. Find the trigger: What changed?

    • Check if failures started on a specific date (new deployment, model change, config update)
    • Check if failures correlate with specific topics or user segments
    • Check if a tool's error rate changed using Amplitude:get_amplitude_agent_analytics_info with view: "tool_reliability"

Step 4: Search for Related Patterns (Budget: 1-2 calls)

If the root cause isn't clear from the session data alone:

  1. Find related sessions. Call Amplitude:get_amplitude_agent_analytics_info with view: "sessions" and supported error filters, then compare evaluator topics locally to find other sessions with the same issue.

  2. Check tool/model health. Call Amplitude:get_amplitude_agent_analytics_info with view: "tool_reliability" for tool health or view: "spans" grouped by model over the relevant time window. Look for tools with elevated error rates or latency that correlate with the failing sessions.

Step 5: Present the Investigation

Structure the output as a root cause analysis.

Required sections:

  1. Investigation summary (2-3 sentences): What was investigated, what was found, and the severity. Written as a headline for the team.

  2. Sessions examined: A compact table of the sessions investigated:

| Session ID | Agent | Outcome | Quality | Sentiment | Failure Type |
|------------|-------|---------|---------|-----------|--------------|
| [id] | [name] | [outcome] | [score] | [score] | [type or —] |
  1. Root cause (1 paragraph): The primary explanation for what went wrong. Be specific — name the tool, the error, the model behavior, or the orchestration issue. Include evidence from the conversation and trace.

  2. Execution trace highlights (for the most illustrative session): Walk through the key spans showing the failure path:

    • "Turn 1: User asked X → Agent called tool Y (OK, 2.1s) → Agent called tool Z (ERROR, timeout after 30s) → Agent responded with fallback that didn't address the question"
    • Focus on the failure point and what led to it
  3. Conversation excerpt (if revealing): Quote the 2-3 most relevant turns showing where the agent failed the user. Keep it brief.

  4. Scope assessment: One-off vs. systemic. How many sessions are affected? Is it getting worse?

  5. Recommended fixes (2-4 numbered items): Concrete actions. Examples:

    • "Add a retry with exponential backoff for the query_amplitude_data tool — 8 of 15 failures are transient timeouts"
    • "The agent is calling manage_amp_events before get_amplitude_context, causing a missing project ID error — fix the tool ordering in the agent prompt"
    • "Users asking about retention are getting routed to the Chart Agent instead of the Funnel Agent — update the routing logic"
  6. Follow-on prompt: Offer next steps — "Want me to check if this tool timeout affects other agents, search for similar user complaints, or monitor this pattern over the next few days?"

Examples

Example 1: Specific Session Investigation

User says: "What happened in session abc-123?"

Actions:

  1. Get detailed session data, conversation, and spans for abc-123 (3 parallel calls)
  2. Read the conversation to understand what the user wanted
  3. Trace the spans to find where the execution failed
  4. Classify the failure and check if it's systemic
  5. Present root cause with trace highlights and conversation excerpt

Example 2: Pattern Investigation

User says: "Why are Chart Agent sessions failing?"

Actions:

  1. Get AI schema to confirm "Chart Agent" is a valid agent name
  2. Query recent Chart Agent failures (hasTaskFailure: true, agentNames: ["Chart Agent"])
  3. Pick the 3 most recent failures and deep-dive into each
  4. Compare the failures — same tool? Same error? Same topic?
  5. Check tool health with span aggregations
  6. Present the pattern with root cause and scope assessment

Example 3: User Complaint

User says: "A customer said our AI gave them wrong data yesterday"

Actions:

  1. Ask for the customer's email or user ID
  2. Search for their sessions from yesterday
  3. Deep-dive into the relevant session(s)
  4. Read the conversation to find what data was wrong
  5. Trace the spans to see what tools provided the data
  6. Present findings with the specific conversation excerpt showing the error

Troubleshooting

Session ID not found

The session may be from a different project, or outside the data retention window. Ask the user to confirm the project and check if the session ID is correct.

Spans not available for a session

Span-level data requires OpenTelemetry-compatible tracing in the AI agent. Report what's available from the session and conversation level and note that span data would help narrow the root cause.

Too many failing sessions to investigate

Don't try to investigate more than 5 sessions in detail. Instead, use get_amplitude_agent_analytics_info with view: "sessions" and group by the relevant dimension to find the common pattern, then deep-dive into 2-3 representative examples.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。