• 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エージェント(AI自動応答システム)セッションや障害パターンを調査して、根本原因を特定します。セッションおよびスパン(処理の実行単位)レベルで動作し、会話の内容を読み取り、実行経路を追跡し、障害の発生源を特定します。これは /monitor-ai-quality が提供する「何が起きたのか」に対する「なぜ起きたのか」を明らかにするスキルです。

使い方

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

ユーザーから以下のいずれかが提供されます:

  • 特定のセッションID → ステップ2に進む
  • 障害パターン(例:「Chart Agent のタイムアウト」「昨日のツールエラー」) → ステップ1bに進む
  • ユーザーからの苦情(例:「ユーザーXがエージェントが動作していないと言っている」) → ステップ1cに進む
  • 曖昧な情報(例:「何かエージェントがおかしい」) → まず /monitor-ai-quality にリダイレクトし、その結果を持ってから戻る

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

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

  • エージェント障害: agentNames: ["<agent>"], hasTaskFailure: true
  • ツールエラー: toolNames: ["<tool>"], 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とともに呼び出します。全てのLLM呼び出し、ツール呼び出し、埋め込み処理(テキスト変換処理)を表示し、それぞれの応答時間、ステータス、コスト、順序を確認します。以下に注目します:

    • status: "ERROR" のスパン → 直接的な障害
    • 応答時間が長いツール呼び出し(10秒超) → タイムアウトまたは遅いツール
    • 同じツールの複数回リトライ → エージェントが困惑している兆候
    • トークン数が異常に多いLLM呼び出し → プロンプト(指示文)が肥大化している可能性
    • 操作の順序 → エージェントが妥当な経路を辿っているか

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

会話 + トレース + 詳細データを組み合わせて診断を構築します:

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

    • ツール障害: ツール呼び出しがエラーを返したか、タイムアウトした。スパンのステータスとエラー詳細を確認します。正しいツールが選ばれたか、入力値は有効か確認します。
    • LLM障害: モデルが不適切な応答を出力した(幻覚、拒否、形式エラー、無限ループなど)。会話で応答がどこで逸脱したかを確認します。
    • オーケストレーション(処理制御)障害: エージェントが間違ったツールを選択、不適切な順序で実行、または途中で諦めた。スパン順序をトレースします。
    • ユーザーの混乱: ユーザーのリクエストが曖昧または実現不可能。エージェントが明確化を求めなかった。最初の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. 影響範囲評価: 単発か根深い問題か。どのくらいのセッションが影響を受けているか。悪化しているか。

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

    • 「query_amplitude_data ツールに指数バックオフ付きリトライを追加 — 15件中8件の障害は一時的なタイムアウト」
    • 「エージェントはプロジェクトコンテキスト検出前に分類機能を呼び出しており、プロジェクトID欠落エラーが発生している。エージェントプロンプトの機能順序を修正」
    • 「リテンション(顧客継続率)について質問しているユーザーがChart Agentではなく Funnel 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が見つからない

セッションが別のプロジェクトからのものか、データ保持期間外の可能性があります。ユーザーにプロジェクトを確認させ、セッションIDが正しいか確認させます。

セッションでスパンが利用できない

スパンレベルのデータはAIエージェントの

原文(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 a taxonomy capability before project-context discovery, causing a missing project ID error—fix the capability 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 による自動翻訳です。