ワンクリックで
problem-solving
データ不整合・バグ・障害の問題解決ガイドライン。根本原因分析の手順、上流修正優先の原則、ハルシネーション防止チェック、データとコードの整合性検証、多層防御の考え方を扱う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
データ不整合・バグ・障害の問題解決ガイドライン。根本原因分析の手順、上流修正優先の原則、ハルシネーション防止チェック、データとコードの整合性検証、多層防御の考え方を扱う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
修正を複数ブランチに適用する際のブランチ戦略。featureブランチへの先行commitとcherry-pickによる短命branchへの適用手順。環境別branch(qa/staging/epsilon等)への修正適用時に参照する。
DeepWiki (Devin MCP) のドキュメント内容を対象リポジトリの Markdown ファイルとして転載する。セクション構成維持・番号付きファイル分割・GFM 準拠補正・日本語翻訳 (オプション) まで自動処理。
PRのレビューコメントを確認し、優先度に応じてコード修正を実行する。サブエージェント (general-purpose) 起動にも対応。--defer-nit / --severity-min で対応範囲を制御。
実装プランファイル作成・更新の手順。実装開始時およびPR作成時にissues/配下の実装プランの有無を確認し、なければ会話履歴・git log・git diffから生成する。複数ファイル変更・新規機能追加・DBマイグレーション伴う変更が対象。
調査レポート作成のルール。否定的結論のエビデンス要件、残課題の記載フォーマット、ハルシネーション防止のための裏取り原則を扱う。DB調査に限らずコードベース調査・仕様調査一般に適用。
ログを追加・修正する際のガイドライン。ログレベルの選択基準、ループ内ログの制御、エラー蓄積パターン、機密情報の扱いを扱う。言語/FW非依存の原則。
| name | problem-solving |
| description | データ不整合・バグ・障害の問題解決ガイドライン。根本原因分析の手順、上流修正優先の原則、ハルシネーション防止チェック、データとコードの整合性検証、多層防御の考え方を扱う。 |
| when_to_use | データ不整合 / バグ / 障害対応時に自動参照。「つじつま合わせ」を避けて上流で直す判断が必要なとき。Triggers: 'バグ修正', 'データ不整合', '障害対応', '根本原因', 'root cause analysis', 'data inconsistency', 'incident', '上流で直す', 'patch vs fix' |
データ不整合、バグ、障害対応における問題解決の原則と手順。
問題はデータフローの最も上流で修正する。下流でのパッチ(migrationによるデータ修正、SQL直接更新、出力時の辻褄合わせ)は最終手段。
❌ 悪いパターン
DBに異常データがある → migrationで論理削除 → バッチ再実行
✅ 良いパターン
DBに異常データがある → なぜ入ったか調査 → 取り込みロジックにバリデーション追加
→ 異常データを論理削除 → バッチ再実行
1. 症状を確認(どのデータ・どの機能が、どう間違っているか)
2. データフロー/呼び出しチェーンを遡る(結果 → 計算 → 素材 → 取り込み → 外部ソース)
3. 最初に異常が発生した地点を特定
4. その地点のコードを修正
5. 下流にも防御的チェックを追加(多層防御)
6. 修正後にデータ修復(パイプライン再実行)
| 症状 | 表層の「原因」 | 真の根本原因 |
|---|---|---|
| 料金が異常値 | 計算ロジックのバグ | 上流の取り込み時に異常値が混入、バリデーション欠如 |
| レコードの2WD/4WD逆転 | 割当ロジックの不具合 | ORM(Eloquent等)のリレーション型不一致(VARCHAR↔INT)でEager Loadマッチングずれ |
| 一部ユーザーで通知が届かない | 通知送信ロジックの問題 | 論理削除フラグの扱いが delete() と forceDelete() で異なる |
コードリーディングだけで判断せず、以下を必ず実行する。
| チェック項目 | 方法 |
|---|---|
| カラム/フィールドが存在するか | SHOW COLUMNS / スキーマ定義ファイル確認(コード読みだけで判断しない) |
| データが存在するか | SELECT COUNT(*) FROM table WHERE ... / サンプル取得 |
| 型が一致するか | DB定義(INT/VARCHAR等)とコード側($casts, dataclass 等)の両方を確認 |
| 外部キー/制約が存在するか | マイグレーション履歴を追跡(追加→削除→再追加の変遷を確認) |
| 論理削除ポリシーは何か | SoftDeletes / deleted_at の有無を確認(delete() と forceDelete() の挙動が異なる) |
| 環境差異がないか | dev/staging/prod で同じクエリを実行して比較 |
delete() を使うORMリレーションで以下の組み合わせは危険:
| ローカルキー型 | 外部キー型 | リスク |
|---|---|---|
| VARCHAR | INT | Eager Load マッチングでずれる可能性 |
| INT | VARCHAR | 同上 |
| string | integer | strict comparison で不一致 |
対策: 型キャストで揃えるか、リレーション定義時に明示的に型変換する。
仮説: 「処理Aが項目Xを逆に割り当てている」
→ コード確認: 処理AのJOIN/代入ロジックを読む
→ データ確認: 上流テーブルの値と処理A結果の値を並べて比較
→ 結論: 上流データは正常、処理A結果が逆転 → 処理Aの問題
-- Step 1: 元データ(上流)を確認
SELECT * FROM source_table WHERE conditions ORDER BY updated_at DESC;
-- Step 2: 中間データを確認
SELECT * FROM intermediate_table WHERE conditions;
-- Step 3: 最終データ(下流)を確認
SELECT * FROM result_table WHERE conditions;
-- Step 4: 上流と下流を突合
-- 値が一致するか、変換ロジックが正しいか確認
Layer 1: 取り込み時バリデーション(異常値を入れない)
Layer 2: 型整合性(正しくマッチングする)
Layer 3: 処理時の防御条件(異常値があっても除外する)
Layer 4: 出力時検証(結果の妥当性チェック)
単一レイヤーだけだと、将来別の経路で同じ問題が再発する可能性が残る。
cherry-pick-pr 方式で作成し、mainブランチを汚染しない(詳細は branch-fix-strategy スキル参照)**エビデンス(staging DB)**:
| key | value | updated_at | 状態 |
|---|---|---|---|
| A100 | 103,081 | 2026-04-01 10:49 | 異常(最新) |
| A100 | 44,390 | 2026-03-11 13:42 | 正常 |
SQLクエリ結果をそのまま貼り、「コードを読んだ推測」と「DBで確認した事実」を明確に区別する。
/ndf:investigation-rules — 調査レポート作成時のエビデンス主義/ndf:branch-fix-strategy — 複数ブランチへの修正適用戦略/ndf:logging-guidelines — ログ設計(原因特定を容易にする)