チューニング（早期アクセス）

チューニングはプロダクト領域の設定から始まります。プロダクト領域は、Amplitudeが何を探索し、どのように品質を判断するかを決定する目標、範囲、ソース、対照、メトリクス、手順を定義します。生成されたオポチュニティがずれていると感じられる場合、最初に調整すべき場所はプロダクト領域です。

フィードバックはそのプロダクト領域内で蓄積されます。直接のコメント、高評価/低評価レビュー、ステータス変更、却下、編集、トリアージ（優先順位付け）の決定などはすべて、Amplitudeが同じプロダクト領域における将来の推奨事項を改善するのに役立ちます。

チューニングできるもの

プロダクト領域でオポチュニティが生成されている場合、そのオポチュニティが一致していない、繰り返し行われている、小さすぎる、または広すぎる場合に、これらの設定を調整してください。実際には、チームはプロダクト領域を一連の小さな次元（範囲と除外項目、目標タグ、ターゲットメトリクス、成功基準、インサイトソース、機会ミックス、および3つの指示レーン（計画、調査、コーディングエージェント））に沿って変化させます。

重点領域を明確に設定する

強力なフォーカス領域は、システムに明確な検索空間を提供します。 ユーザーのジャーニーやプロダクトの領域に名前を付けて、どのような結果が重要かを説明する必要があります。

重点分野として適切:

• AI フィードバック: ソース接続、取り込みの品質、テーマの生成、インサイトのレビュー、フィードバックのトリアージ、チームでの繰り返しの使用など、ソースからインサイトまでのループ全体をカバーしています。 フィードバック ワークフローに直接影響を与えるものでない限り、関連のないコア アナリティクス ファネルは除外します。
• ダッシュボード: 最初のダッシュボード作成、経時的なチャート編集、ダッシュボードのリテンション、共有、エクスポート、繰り返し発生するレポート作成ワークフローについて説明します。ダッシュボードの作成や継続的なダッシュボードの使用を直接ブロックしない限り、ディープチャートクエリ作成は除外されます。
• チェックアウト: カートから支払いまでの完了状況、支払いエラー、リカバリフロー、購入確認、レイテンシーなどのガードレールのメトリクスなどを対象としています。マーケティングランディングページと購入後のリテンションは、チェックアウト完了に直接影響を与える場合を除き、除外されます。
• サポートのためのセッションリプレイ: リプレイの検出、サポート主導のデバッグ、リプレイの共有、問題の再現、およびフォローアップ分析をカバーしています。 サポートワークフローを直接サポートしていない限り、一般的なリプレイ探索は除外されます。

弱い領域：

• グロース。
• ダッシュボード。
• UXを向上させます。
• AIに関連するすべてです。

フォーカス領域が広いと感じられる場合は、それを分割してください。 たとえば、「オンボーディング」用に1つのプロダクトエリアではなく、「最初のデータ接続」、「最初のチャート作成」、「チームメイトの招待」用の別のエリアを作成します。

コントラスト領域を追加

コントラストとは、意図的に範囲外に置かれた近隣領域のことです。 これらはシステムが有益な機会と注意をそらす機会を区別するのに役立ちます。

プロダクト領域が別のチーム、ワークフロー、またはメトリックと接している場合にコントラストを使用します。

例：

• チェックアウトには、支払い送信、エラーの回復、購入確認が含まれます。 マーケティングランディングページと購入後のリテンションは除外します。
• チャートビルダーの場合、チャート作成、保存フロー、クエリの遅延、および最初の有用なビジュアライゼーションが含まれます。ダッシュボードのレイアウトと共有は、チャート作成を直接ブロックしない限り除外します。
• AI Feedbackの場合、ソースの接続、取り込みの信頼性、インサイトの質、チームでの繰り返しの使用状況などを含めます。関連性のないコアアナリティクスファネルを除外します。

機会の組み合わせを調整する

機会はさまざまな種類の仕事を表すことができます。 プロダクト領域のガイダンスとトリアージのフィードバックを使用して、希望する組み合わせを決定できます。

プロダクトの成熟度に合わせて組み合わせる

初期のプロダクトの場合、より多くの機能とワイルドカードのオポチュニティを許可してください。初期のチームは、より広範な探索とより大きなスイングから利益を得ます。

成熟した大量のサーフェスについては、迅速な成功を重視し、バグ修正、実験、および慎重なロールアウト計画を実施してください。成熟したチームは通常、より小さく、より安全で、より測定可能な変更を必要とします。

中堅期の製品については、ワークフローの改善、バグの修正、そしてより大きな賭けのいくつかをバランスよく組み合わせてください。

適切なソースを選択する

ソースはシステムが何を学習できるかを決定します。アナリティクスのみを使用するプロダクト分野では、メトリックの動きは検出できるものの、その背後にあるユーザー体験は見逃される可能性があります。フィードバックのみのプロダクト分野では、センチメントは把握できても、規模を見落とす場合があります。

このガイダンスを使用してください。

• ボリューム、コンバージョン、リテンション、セグメントレベルの影響に関するアナリティクス。
• セッションリプレイにより、問題が実際のユーザーの動作にどのように現れるかを確認できます。
• 苦情、機能のリクエスト、および定性的なテーマに関する AI フィードバック。
• カスタムのインストルメンテーションが不完全な場合に、プロダクトのインタラクションシグナルをオートキャプチャします。
• チームがすでに試みたことや、メトリクスを動かしたことについての実験。
• 継続的にドメイン固有の概要を作成する専門エージェント。
• 技術的なパフォーマンスおよびページ体験シグナル向けのウェブバイタル。
• AIベースのプロダクトの使用状況、品質、パフォーマンスに関するエージェントトレース。
• 市場を意識したアイデアと同等のワークフローに関する競合他社のコンテキスト。
• MCP に接続された内部データソース、独自仕様のシステム、およびワークフロー用のカスタムエージェント（近日提供予定）。
• 実際の実装場所を指す実行計画用のコードリポジトリ。
• 調査が必要な新たなメトリック変更に関する異常（近日公開予定）。
• ユーザーの直接的な意図と満足度のシグナルに関するサーベイ。
• コードレビュー活動によってデリバリーのフリクションや実装リスクが明らかになる場合のPRレビュー（近日公開予定）。

信頼性の高いオポチュニティについては、少なくとも2つの独立したソースを確認します。たとえば、ファネルの離脱率とセッションリプレイのエビデンスを組み合わせたり、フィードバックテーマとそれを裏付ける使用傾向を組み合わせたりできます。

メトリクスと達成基準を方向性をアライメントのアンカーとして使用する

ターゲット指標は、Amplitudeがどのように機会をスコアリングし、フレームアップするかを示します。 各プロダクト領域には以下が含まれている必要があります。

• 成功を定義する主要な指標。
• プライマリメトリクスが変動する理由を診断するのに役立つセカンダリメトリクス。
• 後退を阻止するガードレールのメトリクス。

メトリクスと簡単な達成基準の記述を組み合わせることで、エージェントはチャートの数値だけでなく、お客様が重視する成果に基づいて最適化できます。例：「チェックアウトの放棄を増やすことなく、有料サブスクリプションのコンバージョンとサブスクライバーのリターンを増やす。」

1 つのメトリックのみを使用することは避けてください。 単一のコンバージョンメトリックによって、品質、レイテンシ、サポート負担、またはダウンストリームのリテンションを無視した狭い推奨事項が生成される場合があります。

耐久性のある指示を書く

プロダクトエリアには、3つの指示レーンとオプションのカスタム指示があります。一時的な作業ではなく、安定した誘導で各レーンを満たしてください。 一時的なリクエストは、重視する検出の実行、グローバルチャット、または特定のオポチュニティに関するコメントに属します。

計画の手順

計画手順をプロダクト領域の憲章として使用してください。強力な計画文書は通常、以下のことをカバーしています：

• プロダクトの表面がどのようなものか、そしてどのような持続可能な結果が重要であるか。
• 現在のベースラインまたは成熟度コンテキスト（これにより品質バーが変更される場合）。
• 厳しい境界線と他の場所に属する周辺エリア。
• 機会の枠組み設定、サイズ設定、展開方法に関する設定。

良いプランの手順：

• ペイウォールへの露出から購入完了と加入者の復帰まで、有料サブスクリプションのライフサイクルをカバーします。 コンテンツの繰り返し消費は、リテンションについて直接説明されていない限り、別のプロダクト分野として扱います。
• 複雑な介入を行う前に、手間のかからない回復可能な変更を優先します。 成熟した大量のフローに対する実験計画またはロールアウト計画を含めること。
• 計装のみの作業はお勧めしません。証拠がそれを裏付ける場合、野心的なプロダクトの変更を優先します。

調査指示

調査指示を使用して、エージェントがどこに注目し、何を比較するかを誘導します。優れた調査テキストは通常、以下の内容を網羅しています。

• 分析すべき主要なジャーニーまたはファネル。
• 比較に値するシグナル、セグメント、プラットフォーム。
• 次回のディスカバリー実行で回答すべき質問。
• 測定ギャップまたは既知の交絡要因をプロダクトのフリクションから分離する必要があります。

適切な調査手順：

• 対象となる読者が購読者になれない場合や、新規購読者が購入後に復帰できない場合についてご覧ください。 プラットフォーム、ペイウォールの状態、コンテンツの種類、新規獲得ソース、およびライフサイクルの段階を比較してください。
• 毎日のタスクのループ全体に焦点を当ててください。セッションの開始、タスクの作成、編集と削除のフロー、およびすべてのタスクが完了した瞬間です。 「すべてのデータをリセット」の急増をフラストレーションのガードレールとして捉えてます。
• UIライフサイクル、エージェントのツールコール品質、およびチャットやMCPなどのマルチサーフェスのエントリポイントにわたる構造調査を実施します。隣接する製品がこの領域をブロックしていない限り、スコープ外に置いてください。

コーディングエージェントの指示

リポジトリを接続し、実装の引き渡しをきれいに完了させたい場合は、コーディングエージェントの指示を使用してください。 強力なコーディングエージェントテキストは通常、次のことをカバーします：

• どのリポジトリ、パッケージ、またはサービスがサーフェスを所有しているか。
• 動作上の問題を特定のコードパスまで追跡する方法。
• 推奨される変更スタイル: 最小限の修正、ロールバック手順、デプロイ後のメトリックチェック。
• 作業完了と判断する前の検証基準。

優れたコーディングエージェントの指示:

• フロントエンドはapps/vocおよびpackages/voc-uiにあります。バックエンドはserver/packages/klassyにあります。広範なリファクタリングよりもターゲットを絞った修正を好む。
• エージェント実行の失敗を修正する場合、修正を記述する前に、失敗したツール呼び出しとその入力または出力結果をトレースしてください。 エージェントの成功率と却下率を検証します。
• ロールバック手順と導入後のメトリック監視を常に含めるようにしてください。 作業を完了させる前に、予測されるメトリックへの影響と照らして変更を検証してください。

カスタム手順

証拠ルールや所有権制約など、3つのレーンにきちんと適合しない永続的な設定には、カスタム指示を使用してください：

• 少なくとも2つの独立した情報源から得られた証拠に基づいて機会に優先順位を付けます。
• チェックアウトチーム外の変更が必要な機会は、チェックアウト完了を直接妨げている場合を除いて避けてください。

次のような指示は避けてください：

• 先週の火曜日からの減少を調査してください。
• 最新のリリースに焦点を当ててください。
• 今週は5つのバグを見つけよう。

焦点を絞ったディスカバリーの実行

プロダクト領域の設定は永続的ですが、すべての調査で設定を変更する必要があるわけではありません。 Opportunity Managerに特定の包括的な問題、ユーザーフロー、ページ、またはシグナルのカテゴリを1回の実行で調査させたい場合は、焦点を絞った検出実行を使用します。

焦点を絞ったディスカバリーは、次のような場合に役立ちます。

• オンボーディングの設定、チェックアウト、ダッシュボードのエクスポートなど、特定のページやフローに関連する機会を探します。
• アクティベーションのフリクションやパフォーマンスの問題など、幅広い問題領域にエージェントを誘導します。
• フィードバックテーマ、再生時のフリクション、ウェブバイタル、実験による学習など、シグナルのカテゴリを調査します。
• プロダクト領域の永続的な範囲、指標、または指示を変更することなく、その領域をより深く掘り下げることができます。

焦点を絞ったディスカバリーは、手動のオポチュニティのアイデア提出とは異なります。エージェントに範囲を調査させ、可能性のあるオポチュニティを一括生成してもらいたい場合は、フォーカス・ディスカバリを使用してください。 すでに特定のアイデアがあり、Amplitudeに証拠、スコアリング、計画を具体化してもらいたい場合は、手動のオポチュニティアイデアを使用してください。

フィードバックはチューニングループです

フィードバックとは、プロダクト領域内で継続的に調整を行うメカニズムです。Amplitudeは、明示的なフィードバックとワークフローの動作の両方を使用して、そのプロダクト分野の将来のオポチュニティの調整を改善します。

サムズアップとサムズダウン

オポチュニティが有用で、範囲が明確で、もっと詳しく見る価値がある場合は、サムズアップを使用してください。シグナルが間違っている場合、計画が不十分な場合、またはオポチュニティがプロダクト領域と一致しない場合は、サムズダウンを使用してください。

ラベル付きの入力はすべて、そのプロダクト分野に対するチームの好みに関するコンテキストをAmplitudeに提供します。 この信号は、次の発見サイクルでプロダクト分野の目標に合致する機会をランク付けし、作成するのに役立ちます。

直接的なフィードバック

オポチュニティが間違っていたり、弱かったり、重複していたり、範囲が広すぎたり、重要な文脈が欠けていたりする場合にコメントを残してください。 良好なフィードバックは、決定だけでなく、その理由を説明します。

例：

• 「これはチェックアウトの範囲外です。 これはアカウントの請求設定に属しています」
• 「エビデンスはリプレイに偏りすぎています。 優先順位付けを行う前に、グラフに基づいたボリュームが必要です。」
• 「これは良いクイックウィンですが、提案されている修正では決済プロバイダーの変更を避けるべきです」
• 「すでに進行中の支払い再試行作業の重複です。」

トリアージに関するフィードバック

トリアージの選択内容もシステムに次のことを教えます：

• 「計画済み」は、オポチュニティがプロダクト領域と品質バーに一致したことを示します。
• 「進行中」は、仕様が作業を開始するのに十分な実用性を有していることを示します。
• 「却下済み」は、オポチュニティが範囲に合致しなかった、エビデンスが不十分だった、既存の作業と重複していた、または取り組む価値がなかったことを示します。
• 「レビュー待ち」、「出荷済み」、「測定済み」は、レコメンデーションから結果までのループを完結させます。

ステータスは正直に使用してください。質の低いオポチュニティや関連性のないオポチュニティをいつまでも「新規」に残さないでください。それらを却下したりコメントしたりすることは、システムにそれらを無視するよりも強いシグナルを与えることになります。

レビューの頻度

最良の結果を得るには：

1. ディスカバリーを実行するたびに新しいオポチュニティを確認してください。
2. 無関係または脆弱な機会をそのまま放置するのではなく、却下してください。
3. 将来の検出のためにその理由が重要な場合は、コメントを追加してください。
4. 作業の進行に合わせて、ライフサイクル全体を通して実用的な機会を移動できます。
5. 複数のオポチュニティで同じ種類の不一致が見られる場合は、プロダクトエリアの設定を再確認してください。

チューニングは一度きりのセットアップステップではありません。 プロダクトエリアの設定をプロダクト戦略と同じように扱います。目標と境界線が明確であればあるほど、フィードバックが正直であればあるほど、推奨事項はより有用になります。