SKILLOfficialautomation

call-review

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

説明

エージェント（自動処理を実行する仕組み）の直近100件の呼び出しをレビューし、問題点を浮き出させます。 **次のような場合に使用:** - ユーザーが通話品質の監査を希望している - 最近の通話について品質保証チェック（QA）を求めている - 「このエージェントで何が問題になっているのか」という確認が必要 - 失敗した、未解決、切断された、またはその他問題のある通話を見つけたい **トリガーとなる表現:** 「通話をレビューしてほしい」「通話の何が悪いのか」「直近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".

ユースケース

通話品質の監査を希望しているとき
エージェントの問題点を確認したいとき
失敗・未解決・切断された通話を見つけたいとき
最近の通話について品質保証チェック（QA）を求めるとき

本文（日本語訳）

通話レビュー

目的

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行の markdown テーブルを作成してください：

通話ID	時刻	通話時間	問題	重大度	証拠

重大度： 重大（コンプライアンス違反・不適切な情報開示、重要な処理での誤った結果、エージェントの逸脱行動）· 高（目的未解決、通話中の無応答、割り込みが繰り返される）· 中（応答遅延、情報の繰り返し、軽度の混乱）· 低（発音の誤り、軽微な改善点）。
証拠： トランスクリプトの短い引用句か、タイムスタンプ付きの録音URL。言い換えではなく、ユーザーが検証できるものを。

その後、短い文字による要約を記載してください：

レビュー対象：N件の通話（X件を接続失敗・ボイスメール・時間不足として除外）。
問題発生率：実際の通話のうち、少なくとも1つの問題がフラグされた割合。
発生頻度が高い上位3つの問題タイプ、各々の件数。
重大判定の指摘があれば、最初に名前を出して強調。
最も一般的または最も深刻な問題に紐づけた、具体的な改善提案1～2点（プロンプト編集、アクション変更、音声設定、ルーティング変更など）。

ルール

判断には証拠を。 指摘する問題には、トランスクリプトの引用または録音リンクを必ず添えてください。証拠を示せない場合、指摘しないでください。
数値を捏造しない。 get_call_analytics が提供していないメトリクス（例：応答遅延）は、推測や見積もりではなく「計測できない」と述べてください。
音声固有の問題には録音リンクを。 応答遅延、割り込み、無応答、発音の誤りはトランスクリプトからは判断できません。MCP では録音再生ができないので、トランスクリプトの手がかりは「疑わしい」と記し、録音へのリンクを付け、変更前にユーザーが手動で確認することをお願いしてください。
コンプライアンス問題を最優先。 1件の発生でも、最初に掘り出して指摘してください。
自動修正はしない。 このプレイブックは確認と報告を行います。報告後、ユーザーに上位1～2の問題を修正するのを手伝うか聞いてください（プロンプト編集、アクション変更など）。
スコープは今回の一括データ内。 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 による自動翻訳です。