pattern-detection

パターン検出

このスキルを使用する場面

• 主な作業が、パターンを完全に説明または修正することではなく、繰り返し現れる形や疑わしい不規則性を見つけることである場合。
• コード、ログ／イベント、テレメトリ、メトリクステーブルを対象に、再利用可能なスキャン、候補のショートリスト、グループ化した候補セット、異常のトリアージが必要な場合。
• 「どのようなパターンが繰り返し現れていますか？」「何かおかしい点はありますか？」「何を最初に調べるべきですか？」という質問が、たとえ「パターン検出」という言葉を使っていなくても、実質的な依頼である場合。
• 生の検出結果を大量に並べるのではなく、信頼度に関する注記、誤検知のリスク、最も早い検証手順が必要な場合。
• パターン、異常値、外れ値、繰り返し発生する障害、不審な急増、奇妙なコホート、ルールパック、シグネチャ、コードのにおい、アンチパターン、不正の兆候、繰り返し発生する問題の種類についての依頼である場合。

次の場合は、このスキルを主要なワークフローとして使用しないでください。

• ログやトレースからインシデントの根本原因を再構成することが本来の作業である場合 → log-analysis
• 意思決定に使えるKPIの説明、実験分析、またはステークホルダー向けの報告が本来の作業である場合 → data-analysis
• リポジトリの追跡、所有者の検索、またはメトリクス定義の検索が本来の作業である場合 → codebase-search
• セキュリティ対策、ポリシー設計、または脆弱性の強化が本来の作業である場合 → security-best-practices または code-review
• アラートの調整、テレメトリのカバレッジ、またはインシデント運用が本来の作業である場合 → monitoring-observability

基本的な考え方

pattern-detection は、正規表現を大量に詰め込んだツールではなく、検出パケットのルーターとして機能する必要があります。

1. プロンプトを主要な検出パケット1つに正規化します。
2. 信頼できる候補を見つけられる、最も低コストなエビデンスモードを選びます。
3. 信頼度と誤検知に関する注記を添えて、グループ化した検出結果を返します。
4. 最も早く実施できる検証手順を1つ提示します。
5. ボトルネックが診断、説明、修正、または運用に移ったら、速やかに別のスキルへ引き継ぎます。

パケットを選ぶ前に、以下のサポートドキュメントを読んでください。

• references/intake-packets-and-route-outs.md
• references/detection-modes.md
• references/confidence-and-false-positive-checklist.md

手順

ステップ1：依頼を正規化する

まず、プロンプトを次の受付形式に変換します。

pattern_detection_packet:
  primary_packet: text-prefilter | structural-code-rule | log-event-pattern | metric-anomaly
  evidence_shape: code | configs | logs | events | telemetry | tables | time-series | mixed | unknown
  detection_goal: repeated-shape | risky-structure | noisy-family | suspicious-spike | drift | outlier | rule-draft | shortlist
  grouping_key: file-path | symbol-shape | error-family | event-name | build-version | environment | browser-device | cohort | metric-segment | unknown
  trust_risk: broad-match | parser-drift | instrumentation-change | denominator-gap | seasonality | sample-size | none | mixed | unknown
  route_after: stay-here | log-analysis | data-analysis | codebase-search | security-best-practices | monitoring-observability | code-review

実行する主要なパケットを1つ選びます。候補が2つある場合は、不確実性を最も早く減らせる方を選びます。

ステップ2：パケットを選ぶ

パケット	使用する場面	特に適した対象	典型的な出力
text-prefilter	大きな対象範囲を絞り込むため、低コストで最初の確認を行いたい場合	TODO/FIXMEのまとまり、繰り返し現れる文字列、疑わしい設定値、広範なエラーの種類	候補となるファイル／行、件数、次に推奨するパケット
structural-code-rule	単純なテキストよりも構文や呼び出し形式が重要な場合	リスクの高いAPI使用、重複する分岐／エラーの形式、移行候補、ルール案	グループ化された一致パターン、除外項目、再利用可能なルールの案
log-event-pattern	ログやイベントレコードに繰り返し現れる兆候がある場合	過剰なリトライ、ブラウザー／ビルドの分割、繰り返し発生するエラー、疑わしいイベントの種類	グループ化されたクラスター、広がり／件数のコンテキスト、分割に使えそうなキー
metric-anomaly	集計値や時間枠にパターンが現れる場合	KPIの急増／急落、リテンションやファネルの異常、支出またはテレメトリの疑わしい変化	疑わしいセグメント／時間枠、ベースラインに関する注記、信頼度と注意事項

パケットの選択ルール：

• 検索範囲を低コストで絞り込むことが最も早い成果につながる場合は、text-prefilter を優先します。
• 単純なテキストマッチングではノイズが多すぎる、またはコードの実際の構造を捉えられない場合は、structural-code-rule を優先します。
• 1行ずつ読むことより、量、広がり、パーサーの品質、またはコホートのグループ化が重要な場合は、log-event-pattern を優先します。
• ユーザーが急増、ドリフト、コホート、または時間枠の不規則性を重視している場合は、metric-anomaly を優先します。

Step 3: パターンを主張する前に、証拠を絞り込む

結果を解釈する前に、少なくとも1つの絞り込みを行います。

• ファイル／パス／言語の範囲を限定する
• 時間枠、デプロイ期間、または実験期間を限定する
• 安定したキーでグループ化する：メッセージファミリー、イベント名、例外クラス、ブラウザー／デバイス、ビルド、コホート、指標セグメント
• ノイズの多い1つのソースを、広範な複数ソースの分布から切り分ける
• 疑わしい期間をベースライン期間と比較する
• パーサー、スキーマ、または計測の変化がシグナルを支配している可能性があるかを確認する

パケット別の便利なヒューリスティック：

• text-prefilter → 詳細な主張をする前に、件数と代表的な例を確認する
• structural-code-rule → ルールを作成する前に、形状を言葉で説明する
• log-event-pattern → 発生量と分布を分け、コホート／環境の違いを切り分ける
• metric-anomaly → 異常と判断する前に、分母、ベースライン、セグメントのコンテキストを含める

Step 4: 生のヒット一覧ではなく、グループ化した候補を提示する

次の順序で提示します。

1. 候補ファミリー — どのような繰り返しの形状や異常があるか？
2. 重要な理由 — 正確性、信頼性、セキュリティ、コスト、UX、またはプレイヤー／製品への影響
3. 確信度 — 高／中／低
4. 誤検出のリスク — 何が誤解を招く可能性があるか？
5. 次の確認事項 — 最も迅速な検証方法、または次に振り分ける先

検出結果を、完全な診断、コードの書き換え、ダッシュボード向けメモ、またはアラート展開へと、暗黙のうちに変えてはいけません。

Step 5: パケット固有のヒューリスティックを使う

text-prefilter の場合

• 手軽な絞り込みにのみ使用します。
• すべてのヒットではなく、件数と代表的な例を記録します。
• プレーンテキストだけでは構文／コンテキストが重要すぎる場合は、明示します。
• マッチの品質にノイズが多すぎる場合は、structural-code-rule または log-event-pattern にエスカレーションします。

structural-code-rule の場合

• ツールに頼る前に、コードの形状を言葉で説明します。
• ファイル順ではなく、ファミリーごとにマッチをグループ化します。
• 可能性の高い除外項目と誤検出を指摘します。
• ファミリーが特定できたら、実際の修正やセキュリティ強化は別の担当へ振り分けます。

log-event-pattern の場合

• まず、グループ化の単位を1つ正規化します：エラーファミリー、イベント名、例外クラス、ブラウザー、ビルド、リージョン、機能フラグ、テナント。
• 繰り返し発生している二次的な影響と、原因と考えられる主要ファミリーを分けます。
• パーサーや計測の変化があれば、明示します。
• ユーザーが実際のインシデントの経緯を求めている場合は、根本原因の再構成を log-analysis に振り分けます。

metric-anomaly の場合

• ベースライン期間と比較期間を明記します。
• 分母のコンテキストを踏まえて、絶対変化と相対変化を比較します。
• 異常が広範囲にわたるのか、特定のセグメントに集中しているのかを確認します。
• ビジネス上の意味を示唆する前に、季節性、サンプルサイズの小ささ、計測の変更がないかを確認します。
• より深い説明、推奨事項、または実験の解説は data-analysis に振り分けます。

Step 6: 簡潔な検出ブリーフを1つ返す

デフォルトの回答形式：

## Detection brief
- Packet: text-prefilter | structural-code-rule | log-event-pattern | metric-anomaly
- Scope: [files / logs / rows / metrics / time window]
- Grouping key: [file family / symbol shape / error family / cohort / segment]
- Trust level: high | medium | low

## Candidate findings
1. [pattern family or anomaly]
   - Why it matters: ...
   - Confidence: high | medium | low
   - False-positive risk: ...
   - Next check: ...
2. ...

## Route-out
- stay here | log-analysis | data-analysis | codebase-search | security-best-practices | monitoring-observability | code-review

簡潔にまとめます。目的は、巨大な実装メモではなく、信頼できる最小限の候補リストをユーザーに提示することです。

Step 7: 積極的に別の担当へ振り分ける

次の作業が初期検出の範囲を超えたら、切り替えます。

• 根本原因の調査、インシデントや障害の再構成 → log-analysis
• KPI の説明、実験結果の読み解き、ビジネス向けの説明 → data-analysis
• リポジトリの調査、担当者の特定、指標定義の検索 → codebase-search
• セキュリティ修正や強化設計 → security-best-practices
• 判断が重視されるパッチ／PR レビュー → code-review
• アラートの振り分け、テレメトリーの網羅性、インシデント運用、監視ポリシー → monitoring-observability

証拠が不十分な場合：

1. 確信度を低とします
2. 必要な場合に限り、最小限の不足情報を求めます：範囲、時間枠、グループ化キー、またはベースライン
3. ノイズの多い抜粋1つや少ないサンプルだけを根拠に、確実だと装ってはいけません

例

例 1：繰り返し現れるリスクの高いコードパターン

プロンプト：

このリポジトリで、繰り返し現れるリスクの高いエラーハンドリングパターンをスキャンし、まず何を調べるべきか教えてください。

望ましい回答の形式：

• text-prefilter または structural-code-rule を選択する
• 一致した項目をパターンの種類ごとにまとめる
• 確信度と誤検知に関する注意点を含める
• すべてをその場で修正するのではなく、修正対応をレビュー／リファクタリング／セキュリティのスキルに割り当てる

例 2：KPI の急増のトリアージ

プロンプト：

CSV エクスポートで KPI が急増しています。これはパターン検出ですか、それともデータ分析ですか？

望ましい回答の形式：

• 最初の検出には metric-anomaly を選択する
• ベースライン、分母、信頼性の確認項目を挙げる
• 説明と推奨事項は data-analysis に割り当てる

例 3：ゲームプレイのテレメトリの外れ値

プロンプト：

昨日のアップデート後に、疑わしいゲームプレイのテレメトリの外れ値がないか調べてください。

望ましい回答の形式：

• log-event-pattern または metric-anomaly を選択する
• ビルド、コホート、地域、アイテム／クラスごとに分類する
• 計測に関する注意点を含める
• 完全なバランス調整を約束するのではなく、検出にとどめる

例 4：アラートか異常か？

プロンプト：

ある指標でノイズの多い異常アラートが繰り返し発生しています。しきい値をデバッグするべきか、パターンを調べるべきか、それともダッシュボードの要約を書くべきですか？

望ましい回答の形式：

• まず metric-anomaly を使い、実際に疑わしい期間があるのか、単にアラートのノイズなのかを分類する
• 季節性／履歴データの不足／分母に関するリスクを指摘する
• アラートの調整は monitoring-observability に、KPI の説明は data-analysis に割り当てる

ベストプラクティス

1. ツール名ではなく、証拠の単位とグルーピングキーから始めます。
2. エスカレーションする前に、信頼できる最小限のパケットを使用します。
3. 常に確信度、誤検知のリスク、次に確認すべきことを 1 つ含めます。
4. 生の検出結果の一覧ではなく、候補パターンのグループにまとめます。
5. 検出と診断、修正、説明、アラート運用を区別します。
6. パーサー、計測、季節性、分母の問題を重要な注意点として扱います。
7. 同じパターンが再発しそうな場合は、再利用できるルールの作成を優先します。

参考資料

• ripgrep ガイド
• ast-grep 入門
• Semgrep のパターン構文
• CodeQL の概要
• Datadog の正規表現／grok パースガイド
• OpenSearch の異常検知ダッシュボード
• scikit-learn の外れ値検出