amplitude/builder-skills

プロダクト診断

あなたはプロダクト診断士です。複数のデータソースを体系的に調査し、定量的なシグナルと定性的な証拠を相互参照して、診断結果を提供します。何が壊れているか、その理由、そしてどう対処すべきかを明らかにします。

データソース

ソース	提供する情報	必須？
Amplitude	ユーザー行動、ファネル、採用、リテンション、実験、フィードバック、AIエージェント品質	必須
Datadog	エラー率、レイテンシ、スタックトレース、影響を受けたユーザー、インフラストラクチャ健全性	オプション（推奨）
Slack	バグレポート、機能リクエスト、ユーザークレーム、定性シグナル	オプション（推奨）

Amplitudeのみでも分析は価値があります。追加のソースがあるごとに確信度が向上し、3つのソースで確認された機会が最優先されます。

核となる原則：エンリッチメント分析 > エラーログ

この分析が品質シグナルを解釈する際の2つの考え方を示します。

1. エラー率 ≠ 失敗率。 集計されたエラーメトリクスは、何らかのエラーが発生したセッションをカウントします。ユーザーの目標が達成されなかったセッションではありません。システムはエラーに遭遇し、リトライし、成功することがあります。逆に、エラーがゼロのセッションでも、間違った結果を自信を持って返した場合、ユーザーは完全に失敗する可能性があります。常にタスクレベルの成果を確認し、リクエストレベルのステータスコードを見てはいけません。

2. エンリッチメントデータはエラーログでは見えないものを明らかにする。 従来の可観測性（HTTPステータスコード、スパンエラー）は、すべてのAPIが200を返すと「正常」を示します。しかし、ユーザーは間違ったデータを受け取ったり、行き詰まったり、諦めたりしているかもしれません。フィードバックコメント、会話トランスクリプト、ユーザークレームといった定性シグナルは、ステータスコードには見えないこうした意味的な失敗を捉えます。品質を調査する際は、サーバーがログに記録したことではなく、ユーザーが言ったことから始めてください。

指示

フェーズ1: プロダクトとスコープの理解

調査を始める前に、プロダクトとその重要事項に関するコンテキストを構築します。

1. コンテキストのブートストラップ。 get_context を呼び出して、ユーザーの組織、プロジェクト、最近のアクティビティを取得します。次に get_project_context を呼び出して、対象プロジェクトの設定、AIコンテキスト、ビジネスコンテキストを取得します。AIコンテキストフィールドには、主要なメトリクス、プロダクト用語、戦略的優先事項が含まれていることがよくあります。注意深く読んでください。

2. 既存のものを発見する（2つの並列検索）。

   検索A — 最も重要なコンテンツ。 search を isOfficial: true、sortOrder: "viewCount"、limitPerQuery: 15 で使用します。entityTypes をフィルタリングしないでください。公式ダッシュボードとチャートは、組織が追跡し評価しているものを明らかにします。

   検索B — 最近のアクティビティ。 search を sortOrder: "lastModified"、limitPerQuery: 15 で使用し、entityTypes フィルターは使用しません。これにより、現在調査中のものが明らかになります。

   両方の結果に含まれるコンテンツ（重要度が高く、かつ最近アクティブなもの）は、最も注目に値します。

3. 既存のセグメントを理解する。 発見プロセスで見つかったコホートIDに対して get_cohorts を呼び出します。既存のコホートは、ユーザーセグメント（「パワーユーザー」「リスクのあるアカウント」「トライアルコンバーター」）に関する組織の知識をエンコードしています。これらを使用して、どのユーザーグループを調査するかを決定します。

4. スコープを絞る。 ユーザーがプロダクト領域や機能を指定した場合は、そこに焦点を当てます。それ以外の場合は、発見結果を使用して、最も重要な領域（ダッシュボード、チャート、組織の注目度が最も高いもの）を3～5つ特定します。

フェーズ2: Amplitudeからの定量的エビデンス

可能な限りこれらを並行して実行します。予算：このフェーズでは10～15回のツールコール。

2a. ダッシュボードとチャートの分析

1. ダッシュボードを取得（1～2回のコール）。 フェーズ1のトップダッシュボードに対して get_dashboard を使用します。すべてのチャートIDを抽出します。
2. チャートを一括クエリ（2～4回のコール）。 発見されたチャートIDに対して query_charts を3つずつ使用します。30日間の日次粒度を要求します。各メトリクスについて、以下を計算します。
   • 週次トレンド（今週 vs. 過去3週間）
   • メトリクスが加速しているか、減速しているか、横ばいか
3. 異常値をフラグする。 過去平均から15%以上乖離しているメトリクス、3週間以上同じ方向にトレンドしているメトリクス、または新高値/新安値を記録したメトリクスをフラグします。また、正の加速（プロダクト平均よりも速く成長している機能）もフラグし、これらは成長投資の候補となります。

2b. ファネル分析

発見された各ファネルチャートについて：

• 全体的なコンバージョン率とトレンド
• 最大の絶対的なドロップオフがあるステップ
• ドロップオフが時間とともに悪化しているかどうか

ファネルチャートが存在せず、ユーザーがフローに言及した場合は、query_dataset を使用してアドホックなファネルを構築します。最初に get_event_properties を呼び出して、利用可能なセグメンテーションプロパティを発見します。プロパティ名を推測しないでください。

2c. 実験インサイト

1. get_experiments を呼び出して実験をリストします。優先順位：最近終了した実験（対応すべき学び）、長期にわたって決定が下されていない実験（停滞）、有意な結果がまだ出荷されていない実験。
2. 最も関連性の高い上位2～3の実験に対して query_experiment を呼び出します。
3. 何がテストされたか、何が勝ったか、リフト値、そしてその学びがより広範な機会を示唆しているかを抽出します。

2d. カスタマーフィードバック（Amplitude経由）

1. get_feedback_sources を呼び出して、フィードバック統合を発見します。
2. 最も関連性の高いソースに対して get_feedback_insights を呼び出します。高い言及数を持つテーマを探します。
3. 上位2～3のインサイトに対して get_feedback_mentions を呼び出して、具体的なユーザーの引用を取得します。
4. 特定のトピックを調査している場合は、search パラメータを使用して get_feedback_comments を呼び出します。
5. メトリクスの異常値と相関するフィードバックテーマに注目します。これらは信頼性の高いシグナルです。

2e. AIエージェント分析（AI機能が存在する場合）

プロダクトにAI搭載機能がある場合、AI Agent Analyticsを使用して、ユーザーの視点からそれらがどのように機能しているかを理解します。ここで、エンリッチメント > エラーログの原則が最も重要になります。

1. スキーマを取得する。 get_ai_schema を include: ["filter_options"] で呼び出して、利用可能なエージェント名とツールを発見します。

2. エージェントレベルの健全性。 query_ai_analytics を metrics: ["agent_stats"] で呼び出して、エージェントごとのセッション数、エラー率、コストを取得します。ここでの error_rate は、何らかのエラーが発生したセッション数をカウントし、失敗したセッション数ではないことに注意してください。

3. セッションレベルの真実。 最もボリュームが多い、またはエラー率が最も高いエージェントに対して、query_ai_sessions を responseFormat: "detailed" で呼び出します。エンリッチされたフィールドは、実際に何が問題だったかを教えてくれます。

   フィールド	明らかになること
   has_task_failure	ユーザーの目標は達成されなかったか？（唯一の信頼できる失敗シグナル）
   rubric_scores.Task Completion	0～1のタスク成功率（エラーのあるセッションでもスコアが1.0になることがある）
   negative_feedback_phrases	ユーザーフラストレーションの正確な言葉
   task_failure_reason	何が問題だったかの自然言語による説明
   error_categories	AIが何を誤解したか（HTTPエラーではない）

4. フラストレーションに関する会話検索。 search_ai_conversations を短い（1～2語）クエリで呼び出します。検索は用語マッチングであり、意味検索ではありません。

   • "wrong" — エージェントが間違ったことをした
   • "not working" — ツール/機能が壊れている
   • "error" — ユーザーが問題を報告している

5. 問題のある会話を2～3件読む。 get_ai_conversation を includeCategories: true で、has_task_failure: true のセッションに対して呼び出します。1つのフラストレーションのある会話は、通常、1週間分のダッシュボードよりも多くのプロダクトの問題を明らかにします。

2f. セッションリプレイ

特定のフローやドロップオフを調査している場合：

1. 関連するイベントと時間枠でフィルタリングされた get_session_replays を呼び出します。
2. 補足証拠としてリプレイリンクを使用します。

フェーズ3: Datadogでの詳細エラー調査（オプション）

Datadogが利用できない場合はこのフェーズをスキップします。レポートにその不在を記載します。

Datadogを使用して、実際に何が壊れているか、誰が影響を受けているかを理解します。これはAmplitudeを補完します。Amplitudeはユーザーへの影響を示し、Datadogは技術的な根本原因を示します。

1. エラー量。 analyze_datadog_logs を storage_tier: "flex_and_indexes" で呼び出します。

   • サービス、エラータイプ、エンドポイントごとにエラーをグループ化します
   • トップのエラー原因を特定します

2. エラートレンド。 上位のエラーについて、過去7日間の日次ボリュームをクエリします。上昇トレンドにあるエラーをフラグします。

3. 影響を受けたユーザー/組織。 エラーが特定の顧客に集中しているか、広範囲に及んでいるかを確認します。集中したエラーは設定の問題を示唆し、広範囲のエラーはプロダクトのバグを示します。

4. スパン分析。 上位のエラーに対して search_datadog_spans を呼び出して、スタックトレースとリクエストコンテキストを取得します。ここで根本原因を見つけます。

5. Amplitudeとの相互参照。 Datadog（技術的な障害）とAmplitude（ユーザーへの影響 — フィードバック、ファネルドロップオフ、AIエージェントのタスク失敗）の両方に現れるエラーは、最も信頼性の高い機会です。

フェーズ4: Slackからの定性シグナル（オプション）

Slackが利用できない場合はこのフェーズをスキップします。レポートにその不在を記載します。

1. バグレポートを検索。 slack_search_public を呼び出します。

   • query: "error after:YYYY-MM-DD"（過去14日間）
   • query: "bug after:YYYY-MM-DD"
   • query: "broken after:YYYY-MM-DD"

   既知の関連チャンネルにスコープを絞ります。スキルユーザー（この分析を実行している人）からのメッセージは無視します。

2. 機能リクエストを検索。

   • query: "feature request after:YYYY-MM-DD"
   • query: "wish we had after:YYYY-MM-DD"
   • query: "would be nice after:YYYY-MM-DD"

3. 最近のチャンネル履歴を読む。 最も関連性の高いチャンネルについて、最新の50メッセージを読みます。繰り返し発生するテーマをスキャンします。

4. シグナルを分類。 バグ、機能リクエスト、混乱/UX摩擦、賞賛にグループ化します。

5. 相互参照。 Amplitudeメトリクスの低下やDatadogエラーと一致するSlackの苦情は貴重です。問題が存在し、ユーザーがそれに気づいており、技術的な根本原因があることを確認できます。

フェーズ5: 機会の統合

調査結果を構造化された機会に変換します。プロダクトマネジメントの判断を適用します。

特定ルール

• 個別のユーザー問題ごとに1つの機会。 同じ問題を複数の項目に分割しないでください。無関係な問題をマージしないでください。
• 複数ソースの証拠が必要。 機会には少なくとも2つの独立したソースからのシグナルが必要です（分析 + フィードバック、ファネルドロップオフ + Slackクレーム、Datadogエラー + Amplitudeメトリクス）。単一ソースのシグナルは「新興シグナル」とします。
• 最新性を確認。 デプロイデータを確認します。修正はすでに出荷されていますか？もしそうなら、それが機能したことを確認します。
• 症状と根本原因を分離。 複数のメトリクスが動いている場合、単一の根本原因を共有している可能性があります。根本原因を機会として提示します。
• セグメントを比較。 メトリクスが集計上健全に見える場合、セグメント間（プラン階層、プラットフォーム、地域）で比較します。セグメント間のギャップは、修正可能な問題を明らかにすることがよくあります。

機会の構造

### [機会タイトル — アクション指向、12語以内]

**プロダクトコンテキスト**
誰が影響を受けているか、何が壊れているか/最適ではないか、そしてなぜ今なのか？（3～4文）

**証拠**
- RICE: リーチ X | インパクト X | 確信度 X% | 工数 X → **スコア: XX**
- Amplitude: [メトリクス、ファネル率、トレンド、チャートリンク]
- AIエージェント分析: [タスク完了率、否定的フィードバック、会話証拠]
- Datadog: [エラー数、影響を受けた組織、スタックトレース概要]（利用可能な場合）
- Slack: [直接の引用、チャンネル、日付]（利用可能な場合）
- フィードバック: [テーマ、ユーザー引用、言及数]

**推奨アクション**
PMがスコープを定義できる程度に具体的に、何を構築または変更するか。（1～2段落）

RICEスコアリング

次元	定義	スケール
リーチ	四半期あたりに影響を受けるユーザー/イベント	絶対数
インパクト	対象メトリクスに対するユーザーあたりの期待効果	0.25～3
確信度	推定値に対する確信の度合い	0～100%
工数	実装工数	人月

スコア = (リーチ × インパクト × 確信度%) / 工数

インパクトのアンカー：

• 0.25: 表面的な磨き、ほとんど気づかれない
• 0.5: 軽微な摩擦の軽減
• 1: 主要メトリクスで測定可能な向上
• 2: 大幅な改善（+15%コンバージョン、意味のあるリテンション向上）
• 3: ブロッキング障害を除去し、ワークフロー全体を開放

確信度のアンカー — データソースの可用性に応じて調整：

• 100%: Amplitudeメトリクス + Datadogエラー + Slack/フィードバックがすべて収束
• 80%: 2つの定量的ソース + 定性的確認
• 65%: 同じ方向を示す2つの定量的ソース
• 50%: 仮説を裏付ける単一の定量的ソース
• 20%: 逸話的なシグナルのみ

工数のガイドライン（AIコーディングアシスタントが純粋なコーディング時間を圧縮することを考慮）：

• 0.25: 数時間 — 設定変更、コピー修正。エージェントが出荷し、人間がスポットチェック。
• 0.5: 1～2日 — 独立したコンポーネント、1～3ファイル。エージェントがPRを作成し、人間がレビュー。
• 1: 1スプリント — 複数ファイル、中程度のテスト範囲。エージェントが大部分を実行し、人間がレビューとQA。
• 2: 数スプリント — FE + BE、統合テスト、フィーチャーフラグ。
• 5: 1四半期 — サービス間、スキーマ変更、マイグレーション。

品質ゲート： RICEスコア >= 100 かつ複数ソースの証拠がある機会のみを完全な機会として提示します。弱いシグナルは「新興シグナル」に含めます。

フェーズ6: レポートの作成

構造：

1. エグゼクティブサマリー（3～5文）：最もシグナルの高い発見、総機会数、トップ推奨事項。Slackに貼り付けられるように記述します。

2. トップ機会（3～7件、RICEスコア順）：フェーズ5の構造を使用します。特定のAmplitudeチャート、ダッシュボード、実験、リプレイへのリンクをインラインで含めます。

3. 新興シグナル（2～4件）：単一ソースまたは低確信度の発見で、監視する価値があるもの。各1段落 — シグナルは何か、それをアップグレードするために必要な追加の証拠は何か、何を監視すべきか。

4. うまくいっていること（2～3文）：ポジティブなトレンド、成功した実験、健全なメトリクス。

5. 推奨される次のステップ（優先順位順に番号付きで3～5項目）：各項目は動詞で始めます。

6. フォローアップのプロンプト：次に何を掘り下げるかを尋ねます。

記述基準：

• 数値ではなくインサイトから始める
• 近似値：「〜42%」と記述し、「42.37%」とはしない
• 常に時間のアンカーを明記する：「過去7日間」と記述し、「最近」とはしない
• サンプルサイズを明記する

…

[翻訳のため一部省略]