実装・リファクタ・レビュー・テスト生成・デバッグまで、開発の各工程で使える指示文。ChatGPT・Claude・Cursor・GitHub Copilot にそのまま貼り付けて使えます。全文公開・登録不要で、 コピーボタンから1クリックで持ち出せます。
<context> [PR 差分 / PR 説明 / 関連 Issue] </context> <task> 12 観点でレビューし、合格・要修正・nit を分けて出力する。 </task> <output_format> 観点ごとに 1 行コメント＋分類（✅/⚠️/💡）： 1. 正しさ（仕様充足） 2. テスト（追加・既存破壊） 3. 命名（一貫性・誤読防止） 4. エラー処理（境界条件） 5. パフォーマンス（クエリ・ループ・メモリ） 6. セキュリティ（OWASP Top 10） 7. アクセシビリティ（UI 変更時） 8. 依存性（追加の妥当性） 9. 互換性（API / DB マイグレーション） 10. ログ・観測性 11. ドキュメント 12. PR 説明の十分性 最後に総括（マージ可 / 修正後マージ / Approve しない）。 </output_format>
[要件]に合致する正規表現を生成し、各部分を分解して解説してください。 ・許容例 5 / 拒否例 5 ・Unicode 対応の要否 ・catastrophic backtracking のリスクチェック ・テストコード（言語：[指定]）
次のレイアウト [スクショ／説明] を実装するにあたり、Grid / Flex / どちらでも可 を判定してください。 ・選択理由 ・想定 HTML 構造 ・想定 CSS（疑似コード） ・コンテンツが増減した場合の挙動
次の JSON サンプル [貼付] から TypeScript の型定義を生成してください。 ・必須／任意の判定根拠 ・union 化の妥当性 ・enum 候補 ・命名規則（PascalCase） zod スキーマも併記。
[症状の説明]について、バグレポートを以下のフォーマットで作成してください： ・タイトル（要約 + 影響範囲） ・前提条件 ・再現手順（番号付き） ・期待結果 / 実際の結果 ・環境情報 ・関連ログ／スクショの位置
次の差分 [貼付] から PR 説明を生成してください： ・なぜ（背景） ・何を（変更点 3〜5 行） ・どう確認したか（手動 / 自動） ・スクリーンショット要否 ・破壊的変更の有無 レビュアー向けの読みやすさ重視。
次の TypeScript 型エラーを、初級者にもわかるように解説してください。 ・エラー文言：[貼付] ・該当コード：[貼付] 出力： 1. エラーの意味（日本語で） 2. なぜ発生するか 3. 修正案を 2 つ（型を直す／値を直す） 4. 推奨度と理由
関数 [貼付] に対するテストケースを洗い出してください。 ・正常系（最低 3 つ） ・境界値（空・null・最大・負） ・異常系（型不一致・throw） ・外部依存のモック方針 出力は Jest / Vitest 形式の it() タイトルだけで構いません。
[スタック・想定リポ構成]に対する GitHub Actions のパイプライン設計をしてください： ・ジョブ分割（lint / typecheck / test / build / deploy） ・並列化と依存関係 ・キャッシュ戦略（pnpm/yarn） ・Preview デプロイの扱い ・必要なシークレット一覧
次の Dockerfile [貼付] を以下の観点で改善してください： ・レイヤキャッシュ ・マルチステージ化 ・最終イメージサイズ削減 ・脆弱性（rootless 等） ・再現性（lockfile 利用） ビフォー／アフターと差分の説明。
[エンドポイント要件]を満たす OpenAPI 3.1 のスキーマを生成してください。 ・パス命名は REST 慣例 ・エラーレスポンスは Problem Details 形式 ・ページネーションのカーソル方式 ・認証スキーム ・サンプル値を含める
<context>
[サービス概要・スタック・想定外部依存]
</context>
<task>
エラーの分類と扱いを統一する設計を立てる。ログ／メトリクス／ユーザー通知のどれを使うかをエラー種別ごとに決め、リトライ可否と伝播ルールを明文化する。
</task>
<output_format>
1. エラー分類（ユーザー入力／業務／システム／外部依存）
2. カスタム例外クラス階層と HTTP ステータスのマッピング
3. ログレベル方針（ERROR / WARN / INFO の使い分け）
4. メトリクス（カウンタ / レイテンシ / 失敗率）
5. ユーザー通知（エラーメッセージ・サポート導線）
6. リトライ可否判断（idempotency / 指数バックオフ）
7. 上位層への伝播ルール（どこで握って・どこで投げるか）
</output_format>
<example>
<input>
B2B SaaS API、Express + PostgreSQL + Stripe webhook。外部は Stripe / SendGrid / S3。
</input>
<output>
1. 分類: ValidationError(400) / DomainError(409) / SystemError(500) / DependencyError(502/503)
2. 階層: AppError → 上記4 サブクラス。Stripe 4xx は DomainError、5xx は DependencyError にラップ
3. ログ: Validationは INFO、Domain は WARN、System/Dependency は ERROR + Sentry
4. メトリクス: error_total{kind="validation|domain|system|dep"}、p95 と一緒に
5. 通知: Domain は『この操作はできません』+ サポート ID、System は『時間をおいて再試行』
6. リトライ: 5xx Stripe は 3 回指数バックオフ、4xx は不可、SendGrid は SQS で eventual
7. 伝播: コントローラ層が AppError を catch、それ以外は middleware で 500 に正規化（スタック非露出）
</output>
</example>[サービス概要]の構造化ログ設計をしてください。 ・必須フィールド（trace_id / user_id / 等） ・PII の扱い（マスキング規則） ・ログレベル運用基準 ・サンプリング方針 ・典型クエリ例（Datadog / CloudWatch Insights など）
次の生 SQL [貼付] を [Prisma / Drizzle / SQLAlchemy 等] のクエリに書き換えてください。 ・型安全性を維持 ・N+1 を起こさない構造 ・トランザクション境界 ・パフォーマンス比較メモ
次の HTML/JSX [貼付] に対して以下を行ってください： ・誤った ARIA 使用の指摘 ・冗長な属性の削除提案 ・追加すべき属性 ・スクリーンリーダーで読み上げられる文章のシミュレーション WAI-ARIA Authoring Practices に沿うこと。
[ドメイン]の例外階層を設計してください。 ・基底例外 ・サブクラス（バリデーション／認可／NotFound 等） ・HTTP ステータス対応 ・再試行可否のフラグ ・ログ出力時の付帯情報
[OpenAPI ファイル]からのクライアント生成方針を提案してください： ・ジェネレータ選定（openapi-typescript / orval 等） ・出力先と命名 ・型と関数の使い分け ・ランタイムバリデーション要否 ・CI への組み込み
[サービス・スタック]のデプロイ手順書を作成してください： ・前提条件 ・通常デプロイ手順 ・ロールバック手順 ・障害時のオンコール対応 ・コミュニケーション（誰に何を） ・チェックリストとして使える形式
[機能名]の設計ドキュメントを以下の構成で書いてください： 1. 背景／問題 2. ゴールと非ゴール 3. ユーザーストーリー 4. 提案アーキテクチャ 5. データモデル 6. API 仕様 7. 代替案と却下理由 8. リスクとオープンクエスチョン ADR としても流用可能な形式で。
次の DDL [貼付] を Prisma schema.prisma に変換してください。 ・リレーションの方向と命名 ・@id / @unique / @default の付与 ・enum 化の判断 ・ソフトデリート列の扱い 注意点をコメントで残す。
[現状のクラウド構成と請求書サマリ]から、コスト削減候補を洗い出してください： ・即時削減（ゴミ削除） ・リザーブド／Saving Plans ・ストレージ階層 ・転送料の削減 ・観測コスト それぞれ削減見積りと作業コスト。
次のインシデント記録 [貼付] からブレイムレスなポストモーテムを書いてください： ・タイムライン ・影響範囲（ユーザー数 / 売上 / 機能） ・直接原因と根本原因（5 Whys） ・再発防止アクション（オーナー付き） ・うまくいったこと 学習を促す書き方で。
[API 種別・想定 RPS・課金モデル]に対するレートリミット： ・アルゴリズム（Token Bucket / Leaky Bucket / Sliding Window） ・キーの設計（IP / API Key / User） ・バーストの許容 ・上限到達時のレスポンス（429 / Retry-After） ・分散環境での同期（Redis / 中央 vs ローカル） ・テナント分離（騒がしい隣人問題） ・観測指標
[サービス・チーム数]に対する Feature Flag 運用： ・命名規則とライフサイクル（実験 / 段階公開 / Kill Switch / オペレーション） ・Stale Flag の定期クリーンアップ ・テストとの相互作用 ・SDK コスト（評価レイテンシ） ・監査と権限 ・ロールバック手順
<context> [対象コード貼付／既存テストの有無／関連する呼び出し箇所] </context> <task> 振る舞いを変えずに、段階的にリファクタする計画を立案する。 </task> <output_format> 1. 現状の責務と問題点（5 点以内） 2. テストカバレッジを上げる最短手順（characterization tests も視野に） 3. 段階的リファクタ計画（PR 単位で 3〜5 ステップ） 4. 各ステップで壊れうる箇所と回避策 5. ロールバック方針 </output_format> <constraints> 振る舞いを変えないことを最優先。一度に大きく書き換えないこと。 </constraints> <example> <input> 500 行の checkout.ts。注文計算・在庫確認・決済呼び出し・メール送信が全部入り。テストは 1 件のみ（happy path）。 </input> <output> 1. 責務肥大: 計算/在庫/決済/通知が混在、それぞれ独立に変更されたい 2. テスト最短: 既存挙動を Jest で snapshot 取り、入出力ペア 8 件を characterization tests として固定 3. PR 計画: - PR1: snapshot tests 追加（振る舞い固定） - PR2: 注文計算を pure function calculateTotal として抽出 - PR3: 通知を notifyOnSuccess イベントハンドラへ - PR4: 在庫確認を inventoryService として外出し 4. 壊れうる箇所: 浮動小数点の合計計算順序が変わると差分が出る → 元の順序を保持 5. ロールバック: 各 PR ごとに feature flag は不要、Revert 可能粒度を維持 </output> </example>
<context> パフォーマンス計測結果（APM / プロファイラ / ログ）： [貼付] サービス構成： [フレームワーク / DB / キャッシュ / 想定 RPS] </context> <task> コードを直接触らず、計測結果からボトルネックを推定し調査計画を返す。憶測ではなく数値を根拠にすること。 </task> <output_format> 1. 原因仮説 3 つ（優先度付き、各々の根拠となる数値） 2. 仮説ごとの検証方法（追加計測 / 局所再現 / コード読み） 3. 追加で取得すべき指標（不足している観測ポイント） 4. ローカル再現の手順とハードル 5. 修正の難易度（小／中／大）と影響範囲 </output_format> <constraints> コードに手を入れる前にデータで原因を絞り込むこと。「とりあえず最適化」は禁止。 </constraints> <example> <input> APM: /api/orders で p95 が 800ms→2.5s に悪化（過去 24h）。DB 接続プール使用率 80%。 構成: Rails + PostgreSQL + Redis、想定 50 RPS。 </input> <output> 仮説 1（高）: N+1 クエリ。最近のリリースで AssociationLoader が外れた可能性。根拠: DB 時間 / リクエスト時間比率が 60% → 85% に上昇 仮説 2（中）: Redis キャッシュ TTL 切れ後の Thundering Herd。根拠: p99 が p95 の 3 倍に開く時間帯あり 仮説 3（低）: 接続プール枯渇。根拠: 80% 使用率はまだ余裕、ただしスパイクの可能性 検証: - 1: rack-mini-profiler で代表トレース取得 - 2: Redis MISS rate と同時刻に MISS が集中 - 3: pgbouncer の wait_event 確認 追加指標: クエリ数/req、キャッシュ MISS 時の DB 直撃時間 ローカル再現: production-like fixtures で N+1 を locust 攻撃 難易度: 仮説1 → 小（preload 復旧）、仮説2 → 中（jitter or singleflight） </output> </example>
<context> 対象 SQL： [貼付] EXPLAIN ANALYZE 結果： [貼付] テーブル規模： [行数・主要カラムの分散] </context> <task> EXPLAIN 結果を根拠に、遅い理由を特定し書き換え＋インデックス案を出す。憶測でインデックスを増やさないこと。 </task> <output_format> 1. 遅い理由（Seq Scan / Hash Join / Nested Loop の悪手箇所） 2. 追加すべきインデックス（カラム順・部分インデックス・カバリング） 3. 書き換え案（JOIN 順／サブクエリ→ JOIN ／ EXISTS／ window 関数） 4. 想定される副作用（書込み性能・他クエリへの影響） 5. 検証手順（EXPLAIN 比較・本番風データでの計測） </output_format> <example> <input> SQL: SELECT * FROM orders o JOIN users u ON o.user_id=u.id WHERE o.created_at > NOW() - INTERVAL '7 days' AND u.country='JP' ORDER BY o.created_at DESC LIMIT 100; EXPLAIN: Seq Scan on orders cost=0..200000、Sort 全件 規模: orders 5,000万行、users 100万行（country='JP' は 30%） </input> <output> 1. orders に created_at の B-tree がない → Seq Scan 2. インデックス候補: - orders(created_at DESC)（部分: WHERE created_at > NOW() - 30 day） - 既存の users(country) は使われている 3. 書き換え: - SELECT * を必要列だけに（カバリング化） - LIMIT 100 を活かすため orders → ORDER BY → users JOIN の順を強制（pg_hint_plan） 4. 副作用: - orders への INSERT は微増（〜5%） - 古い created_at だけのクエリは恩恵を受けない（部分インデックスで対応） 5. 検証: 部分インデックス作成後 EXPLAIN ANALYZE 比較、p95 を 24h 観測 </output> </example>
<context> [対象クライアントコンポーネント貼付／使用ブラウザAPI／親子関係] </context> <task> Server Components（RSC）化の是非を判定し、不可なら部分的 Server 化の境界を提示する。 </task> <output_format> 1. Server 化の障害リスト（useState/useEffect/onClick/window/document/localStorage） 2. 残せる Server 部分と Client に切り出すべき部分の境界 3. データ取得の置き場（Server / Route Handler / Client fetch） 4. 段階移行案（PR 単位 3 ステップ程度） 5. 期待効果（バンドルサイズ削減・初期レンダ高速化）と副作用 </output_format> <example> <input> ProductCard コンポーネント。useState で wishlist トグル、価格表示、onClick で API 呼び出し。 </input> <output> 1. 障害: useState / onClick → 不可 2. 境界: ProductCard を Server に、wishlist 部分を <WishlistButton client> に分離 3. データ取得: Server で価格 + 商品情報を fetch、wishlist は Client fetch（ユーザー固有） 4. 段階移行: - PR1: WishlistButton.client.tsx 切り出し - PR2: ProductCard を server 化、props に商品データを渡す - PR3: 親ページから直接 fetch（中間 Client wrapper 削除） 5. 効果: クライアント JS -8KB、LCP -200ms 想定 </output> </example>
<context> [対象テストのコード貼付 / 直近 N 回の成功失敗ログ / 環境（OS / Node バージョン / 並列実行有無）] </context> <task> 推測でリトライ追加に逃げず、原因仮説を切り分ける。 </task> <output_format> 1. 原因仮説（タイミング依存 / 環境依存 / 状態漏れ / 非決定的データ / 外部依存） 2. 各仮説の検証手順（最小再現コード or 計測） 3. 恒久対策と暫定対策の分離 4. 「単に flaky としてリトライする」ことの代償 5. CI で quarantine する判断基準（成功率 / 影響範囲 / 修正期限） </output_format> <example> <input> Jest e2e テスト。並列実行で 1/10 失敗。直近ログ: "user already exists" or タイムアウト。 </input> <output> 1. 仮説: 状態漏れ（テスト間で users テーブル共有）が高 2. 検証: --runInBand で実行 → 100% 成功なら確定 3. 恒久: テストごとに DB schema を分離 or transaction で wrap 4. リトライの代償: 真のバグを覆い隠し、CI 時間 2 倍 5. Quarantine: 直す前に 24h 以上ブロックするなら一時退避、48h 期限で削除復帰 </output> </example>
<context> [対象クラス／関数の貼付 / 既存テストの有無 / 呼び出し側の数] </context> <task> 複数責務を分解し、振る舞いを変えずに段階的にリファクタする。 </task> <output_format> 1. 現状の責務を 3〜5 個に分解（責務名と影響範囲） 2. 新しいクラス／モジュール構成案 3. 呼び出し側の変更箇所と互換性 4. テスト追加方針（既存テストで担保される範囲 / 不足箇所） 5. PR 分割案（3〜5 ステップ）と各 PR で壊れうる箇所 6. ロールバック方針 </output_format> <example> <input> UserService（450 行）。認証 / プロフィール更新 / メール通知 / 支払い連携 が混在。 </input> <output> 1. 責務: AuthService / ProfileService / NotificationService / BillingClient（4 分割） 2. 構成: 各 Service を別ファイル、UserController から DI 3. 呼出側: UserController が 4 つに依存、テストは 既存 mock を分割 4. 既存テストはAuth系のみ、Profile/Notify は characterization 追加 5. PR1: 抽出のみ（呼出 1 箇所） → PR2: ProfileService → PR3: Notification → PR4: Billing → PR5: 旧コード削除 6. 各 PR ごと revert 可能、PR5 のみ依存削除のため非可逆 </output> </example>
<context>
[エンドポイント・想定 RPS／データ更新頻度／許容ステイル時間／既存スタック]
</context>
<task>
レイヤごとのキャッシュ戦略を設計し、TTL／無効化／整合性を整理する。
</task>
<output_format>
1. キャッシュ層（CDN / Edge / アプリメモリ / Redis / DB クエリ）
2. 各層の TTL とタグ／キー設計（衝突回避の命名規則）
3. 無効化トリガ（write-through / write-around / event-driven invalidation）
4. 整合性レベル（強整合 / 結果整合 / monotonic read）の選択
5. キャッシュミス時のフォールバックと Thundering Herd 対策
6. 観測指標（Hit rate / Latency / Stale serve rate）
</output_format>
<example>
<input>
商品一覧 API、5,000 RPS、商品情報は 1 日数回更新、価格は分単位で変動。
</input>
<output>
1. 層: CDN（商品メタ）/ Redis（価格・在庫）/ Postgres（マスタ）
2. TTL: CDN 1h（タグ: product:{id}）, Redis 30s（jitter ±5s）
3. 無効化: 価格更新で Redis pub/sub → タグ purge、CDN は管理画面から手動 + Webhook
4. 整合性: 商品メタは結果整合（5 分以内）、価格は『最大 30 秒のステイル』を許容
5. ミス時: stale-while-revalidate、singleflight で DB 集中防止
6. 指標: Hit rate 90%+ 目標、p99 < 50ms
</output>
</example><context> [処理内容 / 想定件数 / SLA / 各タスクの I/O・CPU 比率 / 失敗時のビジネス影響] </context> <task> 並行処理パターンを比較し、本ケースの推奨を返す。「Promise.all で全部投げる」を避け、失敗時の扱いまで設計する。 </task> <output_format> パターン比較（5 段階で評価）： - 直列ループ - Promise.all 並列 - 並行度制限つき（p-limit / Bottleneck） - キュー＋ワーカー（SQS / Cloud Tasks / BullMQ） - ストリーミング（Backpressure 付き） 各パターンに対し: 1. 失敗時の扱い（部分成功 / 再試行 / DLQ） 2. メモリ／CPU 消費 3. 観測性（進捗 / エラー追跡） 4. 復元性（途中再開） 5. 実装コスト 最後に推奨と段階移行プラン。 </output_format> <example> <input> ユーザー 1 万人にメール送信（外部API呼び出し）、SLA 30 分以内。失敗は 24h 以内に再送必須。 </input> <output> 直列ループ: 失敗ハンドル容易だが 30 分超過リスク高 Promise.all: 高速だが APIレートリミット直撃 / 一部失敗で全体失敗 並行度制限（p-limit 10）: 高速 + レート遵守、失敗は個別保持 キュー＋ワーカー: 復元性最強・観測性高 / 実装コスト中 ストリーミング: 1 万なら overkill 推奨: BullMQ + concurrency 10、24h DLQ。理由: 失敗 24h 再送要件にマッチ、観測も Bull Board で標準 段階: Phase1 p-limit で即対応 → Phase2 BullMQ へ移行 </output> </example>
<context> [症状（OOM/レイテンシ悪化/GC ストール）・スタック・観測中グラフ／本番影響の程度] </context> <task> 推測でコードを触らず、観測 → 仮説 → 再現 → 切り分けの順で進める調査計画を返す。 </task> <output_format> 1. 観測指標（heap used / RSS / GC pause / event loop lag）と取得ツール 2. 再現環境（本番風データの量・並列度） 3. ヒープスナップショット比較手順（時刻 A vs B、Retainer chain） 4. 典型原因の仮説リスト（クロージャ／リスナー解除漏れ／無限増殖キャッシュ／タイマー／DI コンテナ） 5. 仮説ごとの切り分け手順 6. 修正後の検証（24h 観測・OOM が再発しないこと） </output_format> <example> <input> Node.js Express、本番で 6 時間ごとに RSS が +200MB 上昇し OOM。最近の変更: in-memory レート制限を導入。 </input> <output> 1. 指標: heap_used / RSS / event_loop_lag を 1 分粒度。/heapdump エンドポイント追加（debug 鍵） 2. 再現: ローカルで 1 万 ip × 100 req/s をシミュレート、autocannon 3. スナップショット: 0h vs 2h、Retainer で大きな増分オブジェクトを特定 4. 仮説: - 高: レート制限の Map が ip 毎に永続的に積み上がる（クリーンアップなし） - 中: Express の req リスナー解除漏れ - 低: GC が big object 解放を遅延 5. 切り分け: rate-limit Map のサイズを metric 化 → 仮説高を即確認 6. 検証: TTL 付き LRU に置換 → 24h 観測で RSS が水平になること </output> </example>
<context> [サービス概要 / 既存 SLO / 想定ピーク RPS / 主要エンドポイント / 既存観測基盤] </context> <task> 本番に近い負荷で SLO を検証する計画を立てる。「とりあえず k6 で叩く」で終わらせない。 </task> <output_format> 1. ツール選定（k6 / Locust / Gatling / Artillery）と選定理由 2. シナリオ（ベース / ピーク / スパイク / Soak） 3. 計測指標と合格基準（p50/p95/p99、エラー率、リソース使用率） 4. 本番影響を抑える方策（ステージング / シャドウトラフィック / カナリア環境） 5. テストデータ準備（PII マスク・量・分布） 6. 実行プレイブック（事前 / 当日 / 事後） 7. 失敗時の判断基準と次のテスト計画 8. リハーサルとブラックフライデー想定スパイク </output_format> <example> <input> B2B SaaS API、SLO p95 200ms、ピーク 500 RPS。年末セールで 3 倍想定。Datadog 既存。 </input> <output> 1. k6 推奨。スクリプト管理が JS で SCM に乗る。Cloud 不要、自前 EC2 で 2 ノード 2. シナリオ: - ベース 500 RPS 30 分 - ピーク 1,500 RPS 30 分 - スパイク 0 → 2,000 RPS 90 秒 - Soak 800 RPS 6 時間（メモリリーク検出） 3. 合格: p95 < 200ms（ベース）/ < 350ms（ピーク）/ エラー率 < 0.1% / CPU < 75% 4. 本番影響: ステージング + 本番 DB のリードレプリカで実施。失敗時は CDN 前段でロールバック 5. データ: 顧客 ID は擬似 1 万、PII はハッシュ化 6. プレイブック: T-7 リハ / T-1 通知 / T 0 実施 / +1 ポストモーテム 7. 失敗時: スパイクでエラー率 > 1% なら次回オートスケール基準を見直す 8. ブラックフライデー: 11 月中旬に同シナリオを 2 回実施 </output> </example>
<context>
対象コード：
[貼付]
サービスコンテキスト：
[認証方式 / 取り扱いデータ / 外部公開範囲]
</context>
<task>
OWASP Top 10 (2021) に照らして脆弱性を抽出し、簡易 PoC・修正案・回帰テストを返す。誤検知（False Positive）の可能性は必ず明記する。
</task>
<output_format>
各脆弱性候補について：
- 該当 OWASP カテゴリ（A01〜A10）
- 該当箇所（ファイル名 / 行番号）
- 攻撃シナリオ（簡易 PoC、必ず仮想環境前提）
- 修正案（Before / After のコード例）
- 回帰テスト（unit / e2e のどちらで防ぐか）
- False Positive 可能性（5 段階）と判定根拠
</output_format>
<constraints>
PoC は学習目的のみ。実際の攻撃手順を完成形で書かない（緩和策と一緒に提示）。
</constraints>
<example>
<input>
Node.js / Express、ユーザー入力を db.query("SELECT * FROM users WHERE name='" + req.body.name + "'") に直接挿入
</input>
<output>
- カテゴリ: A03 Injection（SQL）
- 箇所: routes/users.js:42
- PoC: name=' OR 1=1-- → 全ユーザー漏洩
- 修正:
Before: db.query("...'" + req.body.name + "'")
After: db.query("...$1", [req.body.name]) // パラメタライズ
- 回帰テスト: e2e で OR 1=1-- を投げて 200 件以上返らないこと
- FP 可能性: 1（明らか）
</output>
</example><context> [現状のリポジトリ数 / 組織サイズ / 言語スタック / リリース頻度 / 共通ライブラリの再利用状況] </context> <task> monorepo 化の是非を評価し、推奨と段階移行プランを返す。「流行だから」ではなく要件で決める。 </task> <output_format> 1. 依存関係の共通化（共通 lib のバージョン整合・型共有） 2. ビルド／キャッシュ（変更検知の効率） 3. コードオーナーシップ（CODEOWNERS / レビュー責務） 4. リリース粒度（独立リリース vs バンドル） 5. ツールチェーン（Turborepo / Nx / Bazel / pnpm workspaces） 6. CI コスト（差分ビルド / リモートキャッシュ） 7. 移行コスト（git 履歴保持 / 段階移行） 8. 推奨と移行ステップ 9. monorepo にしない方が良い兆候 </output_format> <example> <input> スタートアップ、TypeScript で 8 リポ（web / api / shared-types / sdk / docs / admin / cron / e2e）。エンジニア 25 名、共通型のバージョンずれが慢性的。 </input> <output> 1. shared-types のバージョンずれ → モノレポで即解消、共通バリデータも同居 2. Turborepo + remote cache（Vercel）。差分ビルド 90 秒 → 15 秒 3. CODEOWNERS で各 package 責務を明示 4. web/api は独立、sdk は changeset で publish 5. Turborepo 推奨（pnpm workspaces 既存）。Nx は overkill、Bazel は学習コスト高 6. CI: 既存 1 PR 12 分 → 4 分想定 7. git filter-repo で履歴保持マージ、2 週間 8. 段階: 1) shared-types 2) sdk 3) admin 4) web/api/e2e 9. NG兆候: Go と TS が半々などの極端混在 — 該当しない </output> </example>
<context> [既存スキーマ／変更内容（カラム追加・型変更・テーブル分割等）／対象テーブルの行数・QPS] </context> <task> ゼロダウンタイムを目指す段階的マイグレーション計画を作成する。一度に大きく変えないこと。 </task> <output_format> 1. 段階アプローチ（追加 → デュアル書き込み → バックフィル → 切替 → 旧削除） 2. 各段階のリリース粒度（PR/デプロイ単位） 3. ダウンタイム要否と回避策 4. ロールバック方針（各段階で戻せるか） 5. 大量データへのバックフィル戦略（バッチ／スロットル／実行時間見積り） 6. コード側のリリース順序とフラグ運用 7. 観測指標（移行進捗 / エラー率 / レプリケーション遅延） </output_format> <example> <input> users テーブルに country (NOT NULL) を追加。5,000 万行、1,200 QPS、Postgres。 </input> <output> 1. 段階: - PR1: country カラム追加（NULL 許容、デフォルトなし） - PR2: アプリで両方への書き込み開始 - PR3: バックフィル（10万行/分、JP デフォルト + IP 推測） - PR4: NOT NULL 制約付与（CHECK NOT VALID → VALIDATE） - PR5: 旧コード削除 2. ダウンタイム: なし（NOT VALID → VALIDATE で短時間ロック回避） 3. ロールバック: 各 PR ごと revert 可能、PR4 後はロールバック制限 4. バックフィル: 5,000万 ÷ 10万/分 = 500 分。深夜帯に分割 5. リリース順: コード（書き込み）→ バックフィル → コード（読み）→ 制約 6. 観測: pg_stat_progress_create_index, replication_lag, error_total </output> </example>
<context>
[ユースケース・ペイロード概要 / 受信者の規模 / 既存サブスクリプションの有無]
</context>
<task>
公式ドキュメントに掲載できる粒度の Webhook 仕様を設計する。
</task>
<output_format>
1. イベント種別と命名（resource.event 形式の一貫性）
2. ペイロードスキーマ（バージョン管理・後方互換）
3. 署名検証（HMAC / タイムスタンプ・再送攻撃対策）
4. 冪等性キー（event_id）と重複処理ガイドライン
5. 配信保証（at-least-once）の意味と受信側責務
6. 失敗時のリトライ戦略（指数バックオフ・上限・DLQ）
7. 受信側デバッグ支援（Replay UI / Webhook Logs）
8. シークレットローテーションと旧鍵期間
9. レート制限と購読者ごとのスロットリング
</output_format>
<example>
<input>
EC SaaS、注文・配送イベントを商店向けに通知。商店数 10,000、ピーク 100 注文/秒。
</input>
<output>
1. order.created / order.paid / shipment.shipped / shipment.delivered
2. v1 ペイロードに event_id, occurred_at, data{}; v2 で data 形式変更時は X-Event-Version で並行送信
3. X-Signature: HMAC-SHA256(secret, timestamp + "." + body)、5 分以内のみ受理
4. event_id を購読者側で 24h dedup
5. at-least-once: 重複を許容する設計を強く明示
6. リトライ: 1m / 5m / 30m / 2h / 12h 計 5 回、超過で DLQ + 通知
7. Replay UI: 過去 30 日のイベントを管理画面から再送可
8. シークレットローテーション: 旧鍵 30 日重複期間、X-Signature-v2 ヘッダ
9. レート: 商店ごと 100 req/s、超過で 429 + Retry-After
</output>
</example><context> [ドメインモデル / 利用者の役割と組織階層 / リソースの種類 / 想定外の権限要求のパターン] </context> <task> 認可方式を比較し、本ケースに最適な方式と移行ステップを返す。 </task> <output_format> 1. 候補比較 - RBAC（ロール）/ ABAC（属性）/ ReBAC（関係）/ PBAC（ポリシー） - 各方式の本ケースでの適合度（5 段階）と理由 2. ポリシーの保存場所（DB / OPA / Cedar / コード埋め込み） 3. パフォーマンス（N+1 認可、リスト取得時の評価コスト） 4. テスト容易性と CI 組み込み 5. 運用（権限変更の監査ログ・棚卸しサイクル） 6. 実装コストと既存リファクタ規模 7. 将来の組織変更（チーム制 / 階層変更）への耐性 8. 最終推奨と段階移行プラン </output_format> <example> <input> B2B SaaS、ワークスペース → プロジェクト → タスク。所有関係（Owner/Editor/Viewer）と組織横断 Admin。テスト容易性を重視。 </input> <output> 1. ReBAC が最適（5）。RBAC（3）は組織横断 Admin の表現に弱い。ABAC（4）は柔軟だがテストが地獄 2. Google Zanzibar 風の関係グラフ、保存は専用テーブル（あるいは SpiceDB） 3. リスト系 API で N+1 防止のため Lookup API（先に許可リソース ID を引く） 4. テスト: 関係グラフを fixture でロード、各 API ごとに owner/editor/viewer/外部 のマトリクス 5. 運用: 関係変更の audit_logs、四半期で「Editor 以上」のメンバー一覧を棚卸し 6. 実装コスト: 中（既存 RBAC からの移行に 2 ヶ月） 7. 組織変更: グラフを書き換えるだけで対応可 8. 推奨: SpiceDB 採用。Phase1 で読み取り API のみ移行 → Phase2 書き込み → Phase3 旧 RBAC 削除 </output> </example>
<context> [現在の DB サイズと成長率 / 主要クエリ / 既存ボトルネック / 言語スタック] </context> <task> シャーディング是非を診断する。「Postgres でいけるならそれが一番」を真摯に検討する。 </task> <output_format> 1. 垂直分割（テーブル分割・別 DB 化）で十分か 2. 読み書きの偏り（リード偏重ならレプリカ / Hot key 集中ならアプリ層対応） 3. シャードキーの候補（tenant_id / user_id / hash）と各々の偏り評価 4. クロスシャードクエリの頻度と実装コスト 5. トランザクション境界（2PC を避ける設計） 6. 運用コスト（リバランス / バックアップ / マイグレーション） 7. 代替案（リードレプリカ / インデックス見直し / アプリ層キャッシュ / Citus / Aurora） 8. 推奨と段階移行プラン </output_format> <example> <input> B2B SaaS、Postgres 単一インスタンス 800GB、年 +60%、クエリは tenant_id でフィルタ済み 90%、p95 350ms。 </input> <output> 1. 垂直分割: ログイン履歴と監査ログを別 DB に剥がせば 30% 削減可 2. リード偏重: リードレプリカ 2 台で十分対応 3. シャードキー: tenant_id が自然。ただし上位 5% テナントが 60% を占める Hot 偏り 4. クロスシャード: 全社レポートのみ、月 1 回 ETL で対処可 5. トランザクション: tenant_id 内で完結、2PC 不要 6. 運用: Citus は学習コスト中、Aurora I/O 最適化型なら垂直スケールで 2 年は持つ 7. 代替案優先度: Aurora I/O 最適化 > 垂直分割 > リードレプリカ > Citus > 自前シャーディング 8. 推奨: シャーディングは時期尚早。Aurora I/O 最適化 + 垂直分割で 2 年延命、その後再評価 </output> </example>
<context> [サービス構成 / 既存 SLO / 過去のインシデント傾向 / オンコール体制] </context> <task> Chaos Engineering の最初の 3 ヶ月計画を立てる。「とりあえず Chaos Monkey 動かす」を避け、仮説駆動で実施する。 </task> <output_format> 1. 対象シナリオ（ネットワーク遅延 / 依存停止 / ノード障害 / 時刻ずれ / DNS 障害） 2. 仮説と合格基準（"X が落ちても Y は SLO 維持できる"） 3. 本番影響を抑える方策（Game Day / 隔離環境 / Blast Radius 制御） 4. 自動化レベル（手動 → 半自動 → 継続的） 5. 観測指標と中止条件（エラー率閾値・自動 abort） 6. 学びの記録テンプレ（仮説 / 結果 / 改善 / オーナー） 7. ロールアウト順序（Staging → 業務時間外 → 業務時間内） </output_format> <example> <input> EC SaaS、AWS Multi-AZ、依存: RDS / ElastiCache / Stripe / SendGrid。SLO 99.9%。 </input> <output> 1. シナリオ: - 単一 ECS タスク kill / RDS フェイルオーバ / Redis 一時停止 / Stripe 5xx 注入 / 時刻 5 分ずれ 2. 仮説: - "ECS タスク 1/N kill → ALB 検知 → SLO 維持" - "Redis 停止 → DB へフォールバック → p99 < 1s" 3. Game Day 形式、Blast Radius は単一サービスのみ 4. 半自動（AWS FIS で実行・中断は人手） 5. 中止: エラー率 > 1% で 30 秒以内に自動 abort 6. テンプレ: 仮説 / 実施日時 / 結果 / 不一致点 / 改善 PR / オーナー / 期限 7. Staging で 1 ヶ月、業務時間外 1 ヶ月、業務時間内 1 ヶ月 </output> </example>
<context> [組織規模 / 開発者数 / コードベース現状 / 既存ボトルネック / リリース頻度 / インシデント原因傾向] </context> <task> マイクロサービス化の是非を組織と現状ボトルネックで判断する。「マイクロサービスにすればスケールする」幻想を退ける。 </task> <output_format> 1. コンウェイの法則の影響（チームと境界の整合） 2. 現状の本当のボトルネック（コード / コミュニケーション / デプロイ） 3. 運用負荷（観測 / デプロイ / 認証 / 認可共通化） 4. データ整合性の難易度（Saga / 結果整合） 5. パフォーマンス影響（N+1 RPC / レイテンシ） 6. 移行コスト（チーム工数 × 期間） 7. 推奨（モノリス維持 / モジュラーモノリス / 部分マイクロサービス / フル） 8. 段階的アプローチ（境界の見極め → ストラングラー → 切出し） 9. やめ時の閾値（投資回収不能なら巻き戻す勇気） </output_format> <example> <input> 30 名のスタートアップ、Rails モノリス、PR レビュー詰まりが慢性化、デプロイは 1 日 5 回。インシデント原因は半分が DB 競合。 </input> <output> 1. コンウェイ: 4 ドメインチーム（成長 / 課金 / 連携 / 体験）に分割中。サービス境界はそこに沿うのが自然 2. 真のボトルネック: PR レビュー詰まり（コード所有が曖昧）と DB 競合（同じテーブルを多数の機能が叩く） 3. 運用負荷: 認証は OK（既存 IdP）、観測は Datadog 既存で対応可、デプロイは Buildkite で並列化 4. データ整合性: 課金ドメインだけは強整合必須、他は Saga で OK 5. パフォーマンス: 体験ドメインだけ N+1 RPC リスク 6. 移行: フルだと 18 ヶ月、部分だと 6 ヶ月 7. 推奨: モジュラーモノリス → 課金だけ切出し（高ボトルネック） 8. 段階: 1) 境界線見直し 2) Modular Monolith（Packwerk 等） 3) 課金切出し 4) 体験切出し検討 9. 6 ヶ月で課金切出し完了せず → モノリスに戻す勇気 </output> </example>
<context> [ドメイン / ユースケース / 既存システム間連携 / メッセージング基盤（Kafka / SNS-SQS / RabbitMQ）] </context> <task> イベント駆動の境界・スキーマ・運用を設計する。「とりあえず Kafka」を避け、本ケースに合う基盤と粒度を選ぶ。 </task> <output_format> 1. イベント命名（domain.entity.event の一貫性） 2. ペイロードスキーマと進化戦略（後方互換 / Avro / JSON Schema） 3. Saga / Choreography / Orchestration の選択 4. Dead Letter Queue の運用（再処理ポリシー / アラート） 5. 順序保証 vs スケーラビリティのトレードオフ 6. ビジネスイベント（domain）vs 技術イベント（log）の線引き 7. メッセージング基盤の選定（Kafka / SNS-SQS / EventBridge / RabbitMQ） 8. 観測（イベントトレース / event_id 連鎖） 9. 段階移行プラン（Outbox パターン併用） </output_format> <example> <input> EC SaaS、注文 → 在庫 → 配送 → 通知 が現状同期 RPC、注文ピーク時に在庫詰まり。AWS、Kafka 未経験。 </input> <output> 1. order.created / inventory.reserved / shipment.scheduled / notification.sent 2. JSON Schema、event_version フィールド必須、追加カラムのみ後方互換 3. 注文 → 在庫はトランザクション必要なので Orchestration（Step Functions）、その後の通知は Choreography 4. DLQ: 24 時間滞留でアラート、再処理は手動 Replay UI 5. 順序保証: 同一 order_id ハッシュ partition、跨ぎは結果整合 6. ビジネス: order.created（external visible）、技術: db.commit（internal log） 7. 基盤: SNS+SQS 推奨（既存 AWS、Kafka は学習コスト過大） 8. trace_id を全イベントに付与、X-Ray 連携 9. Outbox: 注文 DB に events テーブル、Lambda で SNS Publish。既存同期コードと並行運用 → 段階移行 </output> </example>