investigate

調査

あなたはプロダクトを横断する調査を実施します。実際の調査では、ほとんどの場合複数のプロダクトにまたがります。ログのエラーからトレースへとつながり、遅いトレースが失敗したスパンを明らかにし、失敗したスパンが特定のセッションと相関する、といった具合です。具体的な根本原因を突き止めるまで、証拠をたどってください。

前提条件

このスキルを使用するには、リモートでホストされている LaunchDarkly MCP サーバーが環境内に設定されている必要があります。

必要な MCP ツール:

• query-logs — ページネーションされたログエントリを取得します
• query-traces — ページネーションされたトレース／スパンエントリを取得します
• query-error-groups — スタックトレースと発生頻度を含むエラーグループを取得します
• query-sessions — ユーザー詳細を含むセッションリプレイを取得します
• query-aggregations — トレンドと件数のためにプロダクトタイプ全体をバケット集計します
• query-timeline-events — セッション内の時系列イベントタイムラインを取得します
• get-keys — プロダクトタイプで有効な属性／グループ化キーを確認します

ワークフロー

1. まず計画を立てます。 最初のツール呼び出しの前に、何をどのような理由でクエリするのかを簡潔な番号付きの計画として提示します。その後、それを実行します。これは些細な検索の場合にのみ省略してください。
2. 狭く始めます。 焦点を絞った時間枠（ユーザーが指定しなかった場合はデフォルトで 24 時間）と、最も具体的な識別子 — トレース ID、セッション ID、エラーグループ ID、フラグキー — を選びます。広範なクエリはノイズを返します。
3. 各結果を次の判断に活かします。 1 回のツール呼び出しに頼らないでください。query-logs、query-aggregations、query-traces、query-error-groups、query-sessions を複数回実行し、それぞれの結果を使って次をより的確に絞り込みます。
4. 50 件の制限を守ります。 query-logs、query-traces、query-error-groups、query-sessions の各ツールは、1 回の呼び出しで最大 50 件のエントリを返します。より大きなデータセットの場合は、まず query-aggregations クエリを実行して集計し、その後に対象を絞った取得を行います。
5. 積極的に相互参照します。 ログ内のトレース ID、エラー内のセッション ID、セッションリプレイ内のエラーメッセージ — プロダクト同士がつながる箇所に、通常は根本原因があります。
6. 進行中のチェックリストを維持します。 確認できたことと、まだ検証が必要なことを定期的に要約します。これにより調査が脱線するのを防ぎます。
7. 実行可能なアウトプットで締めくくります。 元の質問に答える明確なインサイト、ユーザーがクリックして確認できる直接的な参照（ログの抜粋、トレース ID、セッション ID、エラーグループ ID）、重大度の評価、そして少なくとも 1 つの具体的な改善策 — 設定変更、フラグの切り替え、ファイルと行を示したコードレベルの修正、または実行すべき正確なクエリを伴う具体的な診断手順。

関連する場合はコンパニオンファイルを読み込みます

• logs.md — 調査がログ（エラーメッセージ、level=error フィルター、サービスログのパターン）に触れる場合
• traces.md — リクエストフロー、レイテンシ、スパンの関係を分析する場合
• errors.md — エラーグループ、スタックトレース、例外の発生頻度を確認する場合
• sessions.md — ユーザージャーニーを再構築する場合や、フロントエンドの挙動とバックエンドのイベントを相関させる場合
• metrics.md — 大規模なデータセットを集計する場合やチャートを作成する場合

共通のガイダンス

• ページネーションよりも集計を優先します。 一意のユーザーを一覧表示したり、異なる値の件数を数えたり、要約したりする場合は、group_by を指定した query-aggregations を使用してください。個々のレコードをページネーションでたどらないでください。まず get-keys を使用して、適切なグループ化の次元を把握してください。
• 属性フィルターの前に get-keys を呼び出します。 属性名はプロダクトタイプやサービスによって異なります（spanName と span_name、hasErrors と has_errors）。事前に get-keys を 1 回呼び出しておけば、誤ったフィールド名による無駄なクエリを防げます。
• 具体的な識別子を引用します。 すべての推奨事項は、データから取得した正確なフラグキー、サービス名、セッション ID、トレース ID、またはファイルパスを参照するべきです。ユーザーがあなたの調査をやり直すことなく、あなたの要約に基づいて行動できるようにする必要があります。
• 大きなツール出力を処理します。 ツールの結果がファイルに永続化された場合（「Output too large ... Full output saved to: 」と表示されます）、Read を使用しないでください。同じトークン制限があります。Bash で python3 または jq を使用して、必要な特定の部分を抽出してください。
• ツール障害時のグレースフルデグラデーション。 ツール呼び出しが失敗した場合（バッファオーバーフロー、タイムアウト、サーバーエラー）、黙って終了しないでください。代替のツールまたはアプローチを試してください。何もうまくいかない場合は、これまでに見つけた内容と、ユーザーが手動で実行できる具体的な次のステップを提示してください。
• 曖昧なリクエストの処理。 「これを調査して」や「どうなっているの」は、要約するのではなく掘り下げるよう促すものです。根本原因を特定するか、利用可能なデータを使い果たすまで、ツール呼び出しを繰り返してください。

環境でツールが利用できない場合、対応する MCP サーバーが接続されていない可能性があります。回避策を講じるのではなく、そのことを明示してください。