SKILLKnowledge Workautomation

call-review

プラグイン: Synthflow
ソース: GitHub で見る ↗

説明

エージェント（自動応答システム）の直近100件のやり取りを確認し、問題点を洗い出します。 **次のような場合に使用:** - やり取りの品質監査を実施したい - 最近のやり取りを品質保証の観点から確認したい - 「このエージェントで何が問題になっているのか」を調べたい - 失敗、未解決、切断された、またはその他の問題のあるやり取りを見つけたい **主なトリガー表現:** 「やり取りを確認してほしい」「やり取りで何が悪いのか」「直近100件の品質を確認してほしい」「問題のあるやり取りを探して」「最近のやり取りを監査してほしい」など

原文を表示

Review the last 100 calls for an agent and surface problems. Use this whenever the user wants a call-quality audit, a QA pass over recent calls, a "what's going wrong with this agent" review, or to find failed, unresolved, dropped, or otherwise problematic calls. Trigger on phrases like "review my calls", "what's wrong with the calls", "QA the last 100 calls", "find bad calls", or "audit recent calls".

ユースケース

やり取りの品質監査を実施したい
エージェントの問題点を調べたい
失敗・未解決のやり取りを見つけたい
直近100件を品質保証観点から確認したい

本文（日本語訳）

コールレビュー

目的

1 人のエージェント（AI担当者）の最近のコール記録をまとめて取得し、検査して問題点を浮き彫りにします。これにより、顧客との通話中に問題が起きるのではなく、事前のレビューの段階で問題を見つけられます。デフォルトでは、直近 100 件のコール を対象とします。

このプレイブック（自動実行手順）は、Synthflow MCP ツールの上で動作します。プラグイン同梱のサーバーからでも、公式の Synthflow コネクタからでも利用できます。外部の API やスクリプトは不要です。

使用するツール

list_calls — エージェントの最近のコール記録をまとめて取得します。
get_call_details — 特定のコールの文字起こし、結果、通話時間、メタデータ（付加情報）を取得します。
get_call_analytics — コール全体の集計されたメトリクス（数値指標）を取得します。
list_agents — ユーザーがエージェント名を指定していない場合に、該当するエージェントを特定します。

MCP 経由では音声ファイルを再生できません。コール詳細に録音 URL が含まれている場合は、それをユーザーと共有して聞いてもらってください。文字起こしだけを頼りに音声の内容について判断を下してはいけません（ルールを参照）。

開始前に確認すること

以下の 3 つを確認してください。ユーザーがすでに情報を提供している場合は、改めて質問しないで先に進んでください。

対象となるエージェント。 名前が指定されていない場合は list_agents を使い、ユーザーに選んでもらいます。推測は絶対にしません。
コール数の範囲と期間。 デフォルト：直近 100 件、日付フィルターなし。ユーザーが「直近 50 件」「昨日」「今週」などと指定した場合はそれに従います。
カスタム失敗リスト（任意）。 このエージェントに特定の失敗パターンがあるか、ユーザーに尋ねます。あれば、それをエージェント固有のチェックリストとして使用します（下の「エージェント固有の失敗」を参照）。なければ、汎用のチェックのみを実行します。

自分が仮定したことは明記してください。何度も質問を繰り返さないようにしましょう。

ステップ 1 — コール記録を取得

選んだエージェントに対して list_calls を使い、指定されたコール数（デフォルト 100 件）に限定して取得します。各コールについて、コール ID、日時、通話時間、方向（受信 / 発信）、結果 / ステータスをメモします。

以下のようなコール記録は除外し、個別に数えます：実際の会話ではないもの（相手不在、ボイスメール、5 秒未満など）。除外したコール数と除外理由を報告してください。その分を問題発生率に含めてはいけません。

list_calls の結果が要求数より少ない場合は、存在するデータだけをレビューしてそう伝えてください。

ステップ 2 — まず全体像をつかむ

個別のコールを詳しく見る前に、get_call_analytics を使ってバッチ全体の状況を把握します。結果 / 解決率、通話時間の平均と最長、組み込みのセンチメント（感情）スコアや成功指標などを確認します。この情報を使って、ステップ 3 で検査するコールに優先順位をつけます。100 件すべてを細かく読む必要はなく、分析データが既に問題箇所を指し示している場合はそこに焦点を当てます。

ステップ 3 — コールを検査して問題にフラグを立てる

優先順位の高いコールに対して get_call_details を実行し、文字起こしとメタデータを取得します。

汎用の問題チェックリストと、与えられた場合はエージェント固有のリストに照らして、すべてのコールを確認します。

汎用問題チェックリスト

以下の兆候があるコールにフラグを立てます：

未解決 / 失敗した結果 — 発信者の目的が達成されなかった、または通話が解決せずに終わった。
反復 / 重複質問 — エージェントが既に発信者が述べた情報をもう一度聞く。
早すぎる割り込み / 途中割り込み — エージェントが発信者の話を遮る。特に、発信者がゆっくり話している場合や数字 / 住所などをまとめて述べている場合。
通話途中での応答停止 — エージェントが返答をやめたり、会話の途中で沈黙する。
応答時間の長さ — エージェントが返答するまでに長い間隔がある（音声ファイルのみ；録音で確認するようユーザーに指示）。
発信者の不満 / 混乱 — 口調が激しくなる、何度も「え？」と聞き返す、「そう言ったんじゃない」と言う、諦めて通話を切ろうとする。
誤った情報 / 造られた回答 — エージェントが事実、価格、結果として、根拠のない、または間違った情報を述べる。
誤った発音 — TTS（音声合成）が名前、専門用語、数字を正しく発音できていない（音声ファイルのみ；ユーザーに確認を求めてください）。
応答の喪失 / 早期切断 — 発信者が目的を達成する前に通話を切ってしまう。
コンプライアンス / 過度な情報開示 — エージェントが身元確認前に情報を共有したり、本来は収集すべきでないデータを集めている。これらは特に目立つようにフラグを立ててください。頻度に関わらず、最も重大度の高い発見です。
逸脱行動 / 暴走 — エージェントが役割から外れた行動をする、ループして同じ内容を繰り返す、矛盾したことを言う。

エージェント固有の失敗

ユーザーがカスタムリストを提供した場合は、各コールをそれに照らしても確認します。（例：ドイツ語の請求書エージェント「Pia」の場合、請求書番号の取得エラー、6 桁後のスラッシュの位置ずれ、既に言われた情報の再質問、早すぎる割り込み、文の途中での応答停止など。）これらを汎用チェックと同じ厳密さで扱い、独立したカテゴリとして報告してください。

ステップ 4 — 報告

表を最初に、その後に要約文を書きます。スキャンしやすくしてください。

フラグが立ったコールごとに 1 行という形式で、マークダウン表を作成します：

コール ID	日時	通話時間	問題	重大度	根拠

重大度：
- Critical（最高） — コンプライアンス / 情報過開示、重要な手続きでの誤った結果、エージェントの暴走。
- High（高） — 未解決の目的、応答停止、割り込みの繰り返し。
- Medium（中） — 応答時間の長さ、反復質問、軽い混乱。
- Low（低） — 誤った発音、軽い改善点。
根拠： 文字起こしの引用か、タイムスタンプ付き録音リンク。言い換えではなく、確認できる内容を記載してください。

その後、短い書き言葉の要約をまとめます：

レビュー対象バッチ：N 件のコール（X 件を相手不在 / ボイスメール / 短すぎるとして除外）。
問題発生率：実際の会話のうち、少なくとも 1 つの問題にフラグが立ったコールの件数。
頻度が高い上位 3 つの問題タイプ（各々の件数付き）。
Critical レベルの発見がある場合は、名前を挙げて最初に強調表示します。
最も一般的または最も深刻な問題に結びついた、具体的な改善提案 1～2 件（プロンプト変更、アクション変更、音声変更、ルーティング変更など）。

ルール

主張ではなく根拠を。 フラグが立ったすべての問題は、文字起こしからの引用か録音リンクで裏付けられます。根拠を示せなければ、フラグを立ててはいけません。
メトリクスを発明しない。 get_call_analytics に存在しないメトリクス（例：応答時間）については、推測するのではなく、そう言ってください。
音声ファイルのみの問題は録音へのリンクが必須。 応答時間、割り込み、応答停止、誤った発音は文字起こしからは判断できません。録音は MCP では再生できないので、これらを「疑わしい」として報告し、録音へのリンクを貼り、ユーザーに確認してもらった上で確定させてください。
コンプライアンス問題を最初に。 頻度に関わらず、コンプライアンスの問題を最初に取り上げます。
自動修正はしない。 このプレイブックはレビューと報告に専念します。報告の後、ユーザーに、トップの問題について修正を手伝うか（プロンプト編集、アクション変更など）、または何かを変える前に特定の失敗を再現するシミュレーションを実行するかどうか尋ねてください。
バッチの範囲に留める。 100 件のコールから「このエージェントはいつも…」と一般化しないでください。このバッチが示していることだけを報告してください。

報告の後

ユーザーに、トップ 1～2 つの問題に対する修正案を作成するのを手伝うか（prompt-review スキルでプロンプト変更を参照）、または何かを変える前に特定の失敗を再現するシミュレーションを実行するかどうか尋ねてください。

原文（English）を表示

Call Review

Purpose

Pull a batch of recent calls for one agent, inspect them, and surface the problems — so issues are caught in review instead of live on customer calls. Default batch size is the last 100 calls.

This playbook runs on the Synthflow MCP tools, whether they come from the plugin's bundled server or the official Synthflow connector. It does not require any external API or script.

Tools this uses

list_calls — get the batch of recent calls for the agent.
get_call_details — pull transcript, outcome, duration, and metadata for a specific call.
get_call_analytics — pull aggregate metrics across the batch.
list_agents — identify the agent when the user hasn't named one.

Recordings can't be played over MCP. When call details include a recording URL, share it so the user can listen — don't assert audio-only findings from the transcript (see Rules).

Before starting

Confirm three things. If the user already gave them, don't re-ask — proceed.

Which agent. If not named, use list_agents and ask the user to pick. Never guess.
Batch size and window. Default: last 100 calls, no date filter. Honor any override ("last 50", "yesterday", "this week").
Custom failure list (optional). Ask whether this agent has known failure types to check specifically. If yes, take them as the agent-specific checklist (see "Agent-specific failures" below). If none, run generic checks only.

State any assumption you make rather than asking a second clarifying round.

Step 1 — Pull the batch

Use list_calls for the chosen agent, limited to the batch size (default 100). For each call, note: call ID, timestamp, duration, direction, and outcome/status if available.

Drop and count separately any calls that are not real conversations: no-connects, voicemail, and calls under ~5 seconds. Report how many were excluded and why — don't let them dilute the problem rates.

If list_calls returns fewer than requested, review what exists and say so.

Step 2 — Triage cheaply first

Before inspecting individual calls, use get_call_analytics for the batch to get the lay of the land: outcome/resolution rates, average and tail durations, and any built-in sentiment or success metric. Use this to prioritize which calls to open in Step 3 — don't read all 100 in full when the analytics already point at the failing slice.

Step 3 — Inspect calls and flag problems

Pull get_call_details (transcript + metadata) for the prioritized calls.

Check every call against the generic problem checklist, plus the agent-specific list if one was given.

Generic problem checklist

Flag any call exhibiting:

Unresolved / failed outcome — the caller's goal was not met, or the call ended without resolution.
Repetition — agent re-asks for information the caller already gave.
Premature interruption / barge-in — agent cuts the caller off, especially during slow or grouped delivery (numbers, addresses).
Mid-call dropout — agent stops responding or goes silent mid-conversation.
High latency — long gaps before the agent responds (audio-only; flag for the user to verify against recordings).
Caller frustration or confusion — escalating tone, repeated "what?", "that's not what I said", caller giving up.
Wrong or hallucinated output — agent states a fact, price, or outcome that is incorrect or unsupported.
Mispronunciation — names, domain terms, numbers read wrong by TTS (audio-only; flag for user verification).
Disengagement / early hangup — caller drops before the goal is reached.
Compliance / over-disclosure — agent shares information before verifying identity, or collects data it shouldn't. Flag these prominently — they are the highest-severity finding regardless of frequency.
Off-the-rails behavior — agent goes outside its role, loops, or contradicts itself.

Agent-specific failures

If the user provided a custom list, check each call against it as well. (Example, for a German invoice agent like "Pia": invoice-number capture errors, separator/Schrägstrich placement after the 6th digit, re-asking for already-provided info, premature interruption, mid-sentence dropout.) Treat these with the same rigor as the generic checks and report them as their own category.

Step 4 — Report

Lead with the table, then the summary. Keep it scannable.

Render a markdown table with one row per flagged call:

Call ID	Time	Duration	Problem(s)	Severity	Evidence

Severity: Critical (compliance/over-disclosure, wrong outcome on a consequential action, agent off the rails) · High (unresolved goal, dropout, repeated interruption) · Medium (latency, repetition, mild confusion) · Low (mispronunciation, minor polish).
Evidence: a short transcript quote or a recording link with timestamp — not a paraphrase. Make it checkable.

Then a short written summary:

Batch reviewed: N calls (X excluded as no-connect/voicemail/too-short).
Problem rate: how many of the real calls had at least one flagged issue.
Top 3 problem types by frequency, each with a count.
Any Critical findings, called out first by name.
One or two concrete recommendations (prompt, action, voice, or routing changes) tied to the most common or most severe issues.

Rules

Evidence over assertion. Every flagged problem cites a transcript quote or a recording link. If you can't point to evidence, don't flag it.
Don't invent metrics. If get_call_analytics doesn't expose a metric (e.g. latency), say so rather than estimating.
Audio-only issues need the recording. Latency, interruption, dropout, and mispronunciation can't be judged from a transcript, and recordings can't be played over MCP — report transcript-level signals as "suspected", link the recordings, and ask the user to spot-check before treating them as confirmed.
Surface compliance issues first even if they appear once.
Don't auto-fix. This playbook reviews and reports. After the report, ask the user whether they want help fixing the top issues (prompt edit, action change, etc.).
Keep it to the batch. Don't generalize to "the agent always…" from 100 calls — report what this batch shows.

After the report

Ask the user whether they want you to draft fixes for the top one or two issues (see the prompt-review skill for prompt changes), or run a simulation to reproduce a specific failure before changing anything.

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