log-analysis

ログ分析

使用する場面

• 構造化ログや非構造化ログからイベントを再構成し、異常を検出して、検証可能な因果関係の仮説を立てる必要がある場合に、このスキルを使用します。
• 既存の計画、結果、証拠一式をレビューし、実行可能な改善策を作成する場合に使用します。
• コンテキストが不完全でも、範囲を限定した初回分析に価値がある場合に使用します。

出力形式の選択肢

• レビュー、実行、段階的な改善には、既定で Markdown を使用します。
• ユーザーが表、CSV、JSON、チケットのフィールドを要求する場合は、リスク、証拠、優先度、境界に関する情報を保持します。
• 機械処理される出力では、まずスキーマ、列挙値、必須フィールドを確認します。

使用方法

1. 入力要件、実行ルール、最低限の網羅範囲、出力順序を含め、prompts/log-analysis.md を読み、その指示に従います。
2. 判断に影響するコンテキストのみを追加します。対象範囲、環境、バージョン、制約、証拠、成功基準を含めます。
3. 入力を監査したうえで、確認済みの事実、作業上の仮定、未解決の疑問を分けます。
4. リスクと証拠の強さに基づいて優先順位を付け、そのまま実行またはレビューできる成果物を作成します。
5. 情報が不足している場合は、範囲を限定した初回分析を行い、どの結論が裏付けられていないかを明示します。

参照ファイル

• このスキルの完全な実行仕様である prompts/log-analysis.md を必ず読みます。
• 評価またはリグレッションを行う場合は、evals/eval.yaml と evals/cases/ 内の関連ケースを読みます。
• references/、examples/、scripts/、output-formats.md は、該当ディレクトリが存在し、タスクで必要な場合にのみ読み込みます。

主な制約

• ログの1行を根本原因とみなさないでください。
• 機密データをマスキングしてください。
• タイムゾーン、サンプリング、ログ欠落による制約を明記してください。
• 証拠にないシステムの挙動、フィールド、データ、メトリクス、根本原因を決して捏造しないでください。
• 重要な結論は証拠に関連付けてください。裏付けのない結論は仮説として示し、検証方法を記載してください。
• ビジネスへの影響、発生可能性、または検出可能性に基づいて優先度を説明してください。

提出前チェックリスト

• タイムライン、エラーのクラスタリング、コンテキストの相関、頻度の変化、機密データ、ログの欠落、サービス間の一貫性、変更との相関を網羅しました。
• 事実、仮定、欠落、推奨事項を分けました。
• リスクの高い項目に優先度、証拠の根拠、担当者または次のアクションを示しました。
• 一般論ではなく、検証可能な判断基準を定義しました。
• 許可されていない本番環境への書き込みや破壊的操作を行いませんでした。

よくある落とし穴

• 前提条件、期待される結果、証拠を示さずに確認事項を列挙する。
• 何もかも高優先度とし、トレードオフを避ける。
• ドメインに即した推論の代わりに、ツール名や一般論を用いる。
• 不完全な入力を理由に分析を拒む、または不完全な証拠で確実な結論が得られるかのように装う。

ベストプラクティス

• ビジネス損失、安全上の問題、リリースの阻害につながる可能性が最も高い経路から着手します。
• 検証可能な最小限の実験で不確実性を減らし、再現条件を記録します。
• 別のエンジニアが実行でき、独立してレビューできる成果物を作成します。