バグ調査プロンプト【再現条件特定から根本原因まで網羅】

以下のアプリアイデアの要件定義書を作成してください。 アプリ名・概要： ターゲットユーザー： 解決したい課題： 出力してほしい内容： 1. サービス概要（エレベーターピッチ） 2. 主要機能一覧（Must/Should/Could） 3. ユーザーストーリー（5つ） 4. 画面一覧と遷移図（テキスト） 5. 技術スタック提案 6. MVP開発の優先順位

以下のエラーを解析して、原因と解決策を教えてください。 【エラーメッセージ】 （エラー全文を貼り付け） 【関連コード】 （問題箇所のコードを貼り付け） 【環境】 言語/フレームワーク： バージョン： 回答形式： 1. エラーの原因（1〜2文） 2. 修正後のコード 3. 再発防止策 4. 類似バグのチェックポイント

以下のコードをレビューしてください。 【コード】 （レビューしたいコードを貼り付け） 言語・フレームワーク： レビュー観点： 1. バグ・ロジックエラーの可能性 2. セキュリティリスク 3. パフォーマンス問題 4. 可読性・命名規則 5. テスト漏れ 指摘事項は「致命的/要修正/提案」の3段階で分類してください。

# 役割 あなたはGoogle/Metaで10年以上のコードレビュー経験を持つスタッフエンジニアで、技術書「Clean Code」「A Philosophy of Software Design」の原則を実務に適用する専門家です。 # コンテキスト {言語・フレームワーク}で書かれた{プロジェクト概要}のプルリクエストをレビューします。レビュー対象者は{レビュイースキルレベル}で、教育的フィードバックも兼ねます。 # 入力 PRタイトル: {PRタイトル} PR説明: {PR説明} 変更差分: ```{言語} {コード差分} ``` 関連ファイル（参考）: ```{言語} {関連ファイル抜粋} ``` # 思考プロセス 1. PRの目的が説明と一致しているか確認 2. 5観点で網羅的にレビュー: - 可読性: 命名/コメント/関数長/ネスト深さ - 保守性: 単一責任/凝集度/結合度/抽象化レベル - 性能: 計算量/I/O回数/メモリ使用 - セキュリティ: 入力検証/SQLi/XSS/秘密情報/権限 - テスト: カバレッジ/エッジケース/モックの妥当性 3. 各指摘に「重大度（Blocker/Major/Minor/Nit）」を付与 4. 指摘の根拠を原則・パターン名で示す（DRY/SOLID/最小驚き原則 等） 5. 修正コード例を提示 6. 良かった点も最低3つ言及 # 出力フォーマット ## サマリー - LGTM度: ◯/10 - 推奨アクション: [Approve / Request Changes / Comment] - ブロッカー件数: ## 良かった点 - ✓ ... ## 指摘事項 ### [Blocker] [ファイル名:行番号] 指摘タイトル - 問題: - 根拠原則: - 修正例: ```{言語} // Before ... // After ... ``` ### [Major] ... ### [Minor] ... ### [Nit] ... ## テスト観点での提案 ## セキュリティ観点での懸念 ## パフォーマンス観点での懸念 ## 学習リソース推奨 （このPRに関連する書籍/記事リンク） # 制約条件 - 個人攻撃禁止、「このコードは」ではなく「このコードの〜部分」と限定 - スタイル指摘はLinter範囲ならNit扱い - 修正例はコンパイル可能な完全形 - 推測のリファクタ提案には「要議論」マーク

# 役割 あなたはMartin Fowler「Refactoring」を実務に適用する専門家で、レガシー大規模システムのリファクタリングを10年以上手掛けてきたテックリードです。 # コンテキスト {プロジェクト規模}の{言語}コードベースで、技術的負債が蓄積したモジュールをリファクタリングします。テストカバレッジは{カバレッジ}%、本番影響のリスク許容度は{リスク許容度}です。 # 入力 対象コード: ```{言語} {対象コード} ``` 感じている問題: {問題点} 外部依存: {依存モジュール} # 思考プロセス 1. コードスメル検出（重複/長関数/巨大クラス/データの群れ/Feature Envy 等） 2. 検出したスメルに優先順位付け（影響度×改修容易性） 3. リファクタリング前にテストの十分性を判定（不足ならテスト追加から） 4. Fowler流のリファクタリング手法を適用箇所ごとに選定 - メソッド抽出/変数の抽出/クラス抽出 - 条件記述の分解/ガード節への置き換え - ポリモーフィズムによる条件記述の置き換え 5. 各ステップを「コミット1個分の小さな変更」に分解 6. 各ステップ後に必ずテストが通る順序で並べる 7. 危険度マーカーと、ロールバック手順を併記 # 出力フォーマット ## 現状診断 - 検出したコードスメルとその根拠 ## リファクタリングロードマップ ### Phase 0: 安全網の構築 - 追加すべきテストケース一覧 - カバレッジ目標: ### Phase 1: 機械的リファクタリング（低リスク） #### Step 1.1: [手法名] - 対象: - ビフォー → アフターコード: ```{言語} // Before ... // After ... ``` - コミットメッセージ案: - 確認方法: テスト実行 #### Step 1.2: ... ### Phase 2: 構造的リファクタリング（中リスク） ### Phase 3: アーキテクチャレベル改善（高リスク） ## 各Phase後の期待される改善指標 | 指標 | 現状 | Phase1後 | Phase2後 | Phase3後 | | 循環的複雑度 | | | | | | LOC | | | | | | 重複率 | | | | | ## 中止すべきシグナル - これが出たらリファクタリングを止めてレビュー依頼 ## ロールバック手順 # 制約条件 - 1コミット = 1リファクタリング手法に限定 - 機能追加とリファクタリングを混ぜない - 外部API互換性は維持 - パフォーマンス劣化が予想される箇所はベンチマーク必須

# 役割 あなたはStripe・GitHub等で公開APIを設計してきたAPIアーキテクトで、Roy FieldingのRESTful原則とAPI Design Patternsに精通した設計の専門家です。 # コンテキスト {サービス名}の{機能領域}に関するREST APIを設計します。利用者は{API利用者（社内/パートナー/公開）}で、想定リクエスト量は{リクエスト量}です。 # 入力 機能要件: """ {機能要件} """ データモデル: {ERD or データ構造} 認証方式: {認証方式} 既存API: {既存API} # 思考プロセス 1. リソース抽出（名詞ベース、機能ではなく対象を中心に） 2. リソース間の関係（1:1/1:N/N:N）を整理 3. URI設計（階層構造/複数形/ケバブケース/動詞回避） 4. HTTPメソッド選定（GET/POST/PUT/PATCH/DELETE の使い分け） 5. ステータスコード設計（2xx/4xx/5xx の使い分け） 6. リクエスト/レスポンススキーマ設計 7. ページネーション戦略（cursor/offset） 8. フィルタリング・ソート設計 9. エラーレスポンス共通フォーマット 10. バージョニング戦略（URI/Header/Query） 11. レート制限・冪等性・キャッシュ 12. セキュリティ（認証/認可/CORS） # 出力フォーマット ## API設計概要 - ベースURL: - バージョニング戦略: - 認証方式: - データフォーマット: ## リソース一覧 | リソース | URI | 説明 | ## エンドポイント詳細 ### GET /resources - 用途: - クエリパラメータ: | 名前 | 型 | 必須 | 説明 | - レスポンス例: ```json { "data": [...], "pagination": {...} } ``` - ステータスコード: 200/400/401/403/500 ### POST /resources ### GET /resources/{id} ### PATCH /resources/{id} ### DELETE /resources/{id} （各エンドポイント同じ詳細度で） ## 共通エラーフォーマット ```json { "error": { "code": "RESOURCE_NOT_FOUND", "message": "...", "details": [...] } } ``` ## ページネーション仕様 ## フィルタリング仕様（OData風 or 独自） ## レート制限ポリシー ## 冪等性キー仕様（POSTの再送対策） ## Webhookイベント仕様（あれば） ## OpenAPI 3.1 スケルトン ```yaml openapi: 3.1.0 info: ... paths: ... ``` ## 破壊的変更ポリシー ## サンプルcurlコマンド集 # 制約条件 - 動詞をURIに含めない（例: /createUser ではなく POST /users） - リソース名は複数形 - 認証情報をURLに含めない - 内部実装を漏らさない（例: DB列名そのまま使わない）