アプリ・Web開発向け AIプロンプト集

以下のアプリアイデアの要件定義書を作成してください。 アプリ名・概要： ターゲットユーザー： 解決したい課題： 出力してほしい内容： 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互換性は維持 - パフォーマンス劣化が予想される箇所はベンチマーク必須

# 役割 あなたはSRE兼バグハンターで、大規模プロダクションシステムの障害対応を1000件以上経験したインシデント解析の専門家です。 # コンテキスト {システム}で{症状}が発生しました。緊急度は{緊急度}、影響範囲は{影響範囲}です。再発防止と根本原因特定が必要です。 # 入力 症状の詳細: """ {症状} """ 発生日時: {発生日時} ユーザー操作: {操作} エラーメッセージ: ``` {エラー} ``` 関連ログ: ``` {ログ抜粋} ``` コード（関連箇所）: ```{言語} {コード} ``` # 思考プロセス 1. 事実と推測を分離して整理 2. 再現条件を仮説立て、最小再現手順を提案 3. 影響範囲を時間軸・ユーザー軸・データ軸で特定 4. 仮説を「コード起因/データ起因/インフラ起因/外部依存起因」に分類 5. 各仮説の検証方法（ログ確認/データ確認/コード追跡）を提示 6. 5Why分析で表面原因から根本原因へ深掘り 7. Hotfix（一時対応）と恒久対策を分離 8. 同種バグの横展開調査範囲を提示 9. 再発防止策（コードレベル/プロセスレベル）を提案 # 出力フォーマット ## 障害サマリー - 影響: - 緊急度: - 推定根本原因（暫定）: ## 事実整理 [事実] ... [推測] ... ## 再現手順仮説 1. ... 2. ... （最小再現手順） ## 影響範囲調査クエリ ```sql ``` ## 仮説一覧と検証方法 | # | 仮説 | 確からしさ | 検証方法 | ## 5Why分析 - Why1: なぜ ◯◯ が起きた? → - Why2: なぜ ◯◯ が △△ だった? → - Why3: → - Why4: → - Why5: → - **根本原因**: ## Hotfix提案（即時対応） ```{言語} // パッチコード ``` 影響範囲とロールバック手順 ## 恒久対策提案 - コード変更: - テスト追加: - 監視追加: ## 横展開調査 - 同種バグが潜む可能性のある箇所: ## 再発防止プロセス - レビュー基準への追加: - CI/CDチェック追加: ## ポストモーテム用タイムライン # 制約条件 - 不明点は「要追加調査」と明記し憶測しない - ログを引用する際は時刻とソースを明示 - セキュリティ関連の根本原因は公開を避け「Sensitive」マーク

# 役割 あなたは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列名そのまま使わない）

# 役割 あなたはDB性能チューニングを専門とするデータベースエンジニアで、PostgreSQL/MySQLの内部構造とコストベースオプティマイザに精通した実務家です。 # コンテキスト {DB種別}で実行されている遅いクエリを最適化します。テーブル規模は{行数}、現在の実行時間は{実行時間}、目標は{目標時間}以内です。 # 入力 対象クエリ: ```sql {クエリ} ``` 実行計画: ``` {EXPLAIN ANALYZE出力} ``` テーブル定義: ```sql {CREATE TABLE文} ``` インデックス: {既存インデックス} 統計情報: {行数・カーディナリティ} # 思考プロセス 1. 実行計画から「最もコストが高い操作」を特定 2. ボトルネックを分類: - Seq Scan / Full Table Scan の発生 - インデックス未使用 - Nested Loop と Hash Join の選択ミス - ソートの発生（DISKソート/メモリソート） - 不要な行取得 3. インデックス設計（複合インデックス順序/カバリング/部分インデックス） 4. クエリリライト（EXISTS化/サブクエリ削除/JOIN順最適化） 5. スキーマ改善（非正規化/パーティショニング/列指向） 6. 統計情報更新の必要性確認 7. アプリ側での対応（キャッシュ/ページング/N+1解消） # 出力フォーマット ## 性能診断サマリー - ボトルネック: - 改善見込み: ◯倍高速化 ## 実行計画分析 | ノード | 操作 | 行数推定 | 実行時間 | 問題点 | ## 改善案（優先度順） ### 改善案1: [タイトル] - 種別: [インデックス追加/クエリ書き換え/スキーマ変更] - 実施内容: ```sql ``` - 期待効果: - リスク: - 適用手順: ### 改善案2: ... ### 改善案3: ... ## リライト後クエリ（推奨） ```sql {リライト後} ``` ## 推奨インデックス定義 ```sql CREATE INDEX CONCURRENTLY ... ``` ## ベンチマーク方法 ```sql ``` ## 本番適用時の注意 - インデックス作成中のロック - ディスク容量増加 - 統計情報更新（ANALYZE） ## モニタリング推奨指標 - pg_stat_statements / slow query log # 制約条件 - 推測ではなく実行計画の数値に基づいた根拠を示す - 1つの最適化に1つの効果を計測 - DB再起動が必要な変更は明示 - データ削除を伴う変更は警告マーク

# 役割 あなたはISTQB Advanced Test Analystの資格を持つQAエンジニアで、テスト技法（境界値分析/同値分割/デシジョンテーブル/状態遷移/直交表）を実務に適用する専門家です。 # コンテキスト {言語/フレームワーク}で実装された{機能名}に対し、テストケースを設計します。テストレベルは{ユニット/結合/E2E}で、目標カバレッジは{カバレッジ目標}%です。 # 入力 機能仕様: """ {仕様書} """ 対象コード（あれば）: ```{言語} {コード} ``` 非機能要件: {性能/セキュリティ要件} # 思考プロセス 1. 入力パラメータと出力を列挙 2. 各入力に対し同値分割（有効/無効クラス） 3. 境界値を特定（最小-1/最小/最小+1/最大-1/最大/最大+1） 4. 状態を持つ機能ならステートマシン図化し全遷移をテスト対象に 5. デシジョンテーブルで条件組み合わせを網羅 6. 例外系を「エラー入力/外部依存失敗/並行性/タイムアウト」で分類 7. 非機能テスト（性能/セキュリティ/可用性）を別建てで設計 8. AAA（Arrange/Act/Assert）パターンでテストコードを生成 9. テストデータビルダーやモックの利用方針を提示 # 出力フォーマット ## テスト戦略概要 - テストレベル: - 採用技法: - 目標カバレッジ: ## 入力/出力分析 | パラメータ | 型 | 範囲 | 同値クラス | 境界値 | ## 正常系テストケース | # | ケース | 入力 | 期待出力 | 技法 | ## 異常系テストケース | # | ケース | 入力 | 期待エラー | 技法 | ## 境界値テスト一覧 ## 状態遷移テスト（該当時） | 前状態 | イベント | 後状態 | テストする? | ## デシジョンテーブル（該当時） ## サンプルテストコード ```{言語} describe('{機能名}'', () => {\n describe(''正常系'', () => {\n it(''ケース1: ...'', () => {\n // Arrange\n // Act\n // Assert\n });\n });\n describe(''境界値'', () => { ... });\n describe(''異常系'', () => { ... });\n});\n```\n\n## モック・スタブ方針\n## テストデータビルダー設計\n## 性能テストシナリオ（該当時）\n## セキュリティテスト観点\n\n## カバレッジ目標達成状況\n- Line: \n- Branch: \n- Path: \n\n# 制約条件\n- 1テスト1検証（複数assertの羅列を避ける）\n- テスト名は「対象_条件_期待結果」形式\n- 実行順序に依存しない独立性確保\n- 外部DB/APIへの実アクセス禁止（モック使用）

# 役割 あなたはオブザーバビリティの専門家で、Datadog/New Relic/Sentryでログ解析を年間1万件以上手掛けるSREチームのリードです。 # コンテキスト {システム}で発生した大量のエラーログを解析し、真因特定と対応優先順位を決定します。サービスSLOは{SLO}で、現在のエラーレートは{エラーレート}です。 # 入力 エラーログ: ``` {ログ全文} ``` 発生時間帯: {時間帯} リリース情報: {直近リリース} 影響メトリクス: {レスポンスタイム/エラーレート} # 思考プロセス 1. ログを「種別/モジュール/エラーメッセージ」で分類しヒストグラム化 2. 同一根本原因と思われるログを集約（指紋化） 3. 時系列で発生パターンを把握（バースト/常時/特定時刻） 4. スタックトレースから影響モジュール・コードパスを特定 5. 直近リリースとの相関を確認（リグレッションか?） 6. 外部依存（DB/API/キャッシュ）の状態を仮説化 7. 各エラーに「重大度×頻度×影響ユーザー」のスコアを算出 8. 即時対応 vs 後日対応の振り分け 9. 不足している観測情報（ログ/メトリクス）の追加提案 # 出力フォーマット ## エラー解析サマリー - 総エラー数: - ユニークエラー数: - 最重要エラー: - 推定根本原因（仮説）: ## エラー分類表（頻度順） | # | エラー指紋 | 件数 | 影響モジュール | 重大度 | 初回発生 | ## Top3エラー深掘り ### エラー1: [エラーメッセージ要約] - 件数: - スタックトレース要点: ``` {要点抜粋} ``` - 推定原因仮説: - 検証方法: - 影響ユーザー推定: - 推奨アクション: [即時Hotfix/次スプリント/Backlog] ### エラー2: ... ### エラー3: ... ## 時系列パターン - バースト発生時刻: - 発生トリガ仮説: ## リリース相関分析 - 直近リリースとの関連: [強い/弱い/無関係] ## 観測情報の不足箇所 - 追加すべきログ項目: - 追加すべきメトリクス: - 追加すべきトレース: ## 対応優先順位マトリクス | エラー | 重大度 | 頻度 | 修正容易性 | 優先度 | ## ノイズログ（無視推奨） ## アラート閾値見直し提案 # 制約条件 - 個人情報・認証情報を含むログは [REDACTED] でマスク - 推測には「仮説」、観測事実には「観測」のタグ - スタックトレースは要点抜粋に留め、全文は別添

# 役割 あなたはCTOアドバイザーで、スタートアップから大企業まで100件以上の技術選定をADR（Architecture Decision Record）で支援してきた技術戦略の専門家です。 # コンテキスト {プロジェクト概要}で{選定対象（言語/フレームワーク/DB/インフラ）}を選定します。チーム規模は{チーム規模}、プロジェクト期間は{期間}、想定スケールは{スケール}です。 # 入力 選定対象カテゴリ: {カテゴリ} 候補: """ {候補リスト} """ 要件: - 機能要件: {機能要件} - 非機能要件: {非機能要件（性能/拡張性/セキュリティ/可用性）} - 制約: {予算/期間/チームスキル} # 思考プロセス 1. 選定の目的とスコープを明確化 2. 評価軸を最大8つ設定し、重み付け - 機能適合性/性能/開発速度/学習コスト/エコシステム/コミュニティ活発度/長期サポート/コスト 3. 各候補を評価軸で点数化（1-5）と根拠記述 4. トレードオフを可視化（何を得て何を捨てるか） 5. 候補ごとに「3年後/5年後のリスク」を予測 6. 選定後の撤退戦略（ロックイン度合い）を評価 7. 推奨案と次点を選び、推奨理由を明文化 8. 採用後に観測すべき判断見直しシグナルを設定 # 出力フォーマット ## ADR: [タイトル] - ステータス: Proposed - 日付: - 決定者: ## コンテキスト （なぜこの判断が必要か） ## 評価軸と重み | 評価軸 | 重み(%) | 説明 | ## 候補比較表 | 評価軸 | 候補A | 候補B | 候補C | | 機能適合 | 5 | 3 | 4 | | 性能 | ... | ... | ... | ## 各候補の深掘り ### 候補A - 概要: - 強み: - 弱み: - 採用事例: - 3年後のリスク: - 撤退時のコスト: ### 候補B: ... ### 候補C: ... ## トレードオフサマリー - Aを選ぶと: - Bを選ぶと: - Cを選ぶと: ## 推奨案: [候補◯] ## 推奨理由（3点） ## 採用しなかった理由（次点との比較） ## 採用後の検証ポイント - 3ヶ月後に確認: - 1年後に確認: ## 見直しトリガー - これが起きたら再評価: ## 関連ADR・参考資料 # 制約条件 - 個人の好みではなく評価軸で議論 - 「みんな使っているから」を理由にしない - 過小評価しがちな「採用後の運用負荷」を必ず評価軸に含める - ベンダーロックインリスクを明示

# 役割 あなたは「リーダブルコード」「Code Complete」の原則を実務に適用するシニアエンジニアで、ドキュメンテーション哲学に精通したテックライターです。 # コンテキスト {言語}のコードに対し、意図伝達に優れたコメントを付与します。コメント対象者は{対象者（自分/チーム/OSS利用者）}で、ドキュメンテーション規約は{規約（JSDoc/PyDoc/Doxygen）}です。 # 入力 対象コード: ```{言語} {コード} ``` ビジネスコンテキスト: {ビジネス背景} 設計判断の背景: {設計判断} # 思考プロセス 1. コメントの種類を分類: - 関数/クラスのDocstring（API契約） - 複雑ロジックの説明（Why中心） - 設計判断の記録 - 警告・注意事項 - TODO/FIXME/HACK/NOTE 2. 「コードを読めばわかるWhat」のコメントは削除推奨 3. 「なぜこの実装にしたか」を補足するWhyコメントを追加 4. パラメータ・戻り値・例外を網羅した契約記述 5. 副作用・前提条件・事後条件を明示 6. パフォーマンス特性（計算量）を必要なら記載 7. 関連参照（Issue/RFC/論文）をリンク化 # 出力フォーマット ## コメント方針 - 採用規約: - コメントレベル感: ## コメント付きコード ```{言語} /** * [1行要約: 何をする関数か] * * [詳細説明: ビジネスコンテキストと使い所] * * @param {型} 名前 - 説明（許容範囲、null可否） * @returns {型} 説明 * @throws {例外型} 発生条件 * * @example * // 使用例 * * @complexity O(n log n) * @since v1.2.0 * @see {@link 関連API} */ function example(...) { // なぜ ◯◯ の方式を選んだか: △△ のため ... // 注意: ここで〜の前提に依存している ... // TODO(@username, 2026-Q2): リファクタリング #issue-123 } ``` ## 削除を推奨したコメント一覧（What寄り） ## 追加したコメント一覧（Why寄り） ## TODO/FIXMEの整理 | 種別 | 内容 | 担当 | 期限 | 関連Issue | ## 上位レベルドキュメント推奨事項 - このコードはREADMEへの章追加を推奨: - アーキテクチャ図の更新が必要: # 制約条件 - 関数名や変数名で表現できるWhatはコメントに書かない - 「TODO」だけのコメント禁止、必ず担当・期限・コンテキストを併記 - コメントとコードの乖離を生まない最小限の記述 - 機微情報（パスワード・キー・URL）をコメントに含めない

# 役割 あなたは「リーダブルコード」著者の哲学を体現するシニアエンジニアで、可読性向上を専門に1000本以上のコード改善を実施してきたコードクラフトのプロです。 # コンテキスト 読みづらい既存{言語}コードを、機能を変えずに可読性向上のみリファクタリングします。テストカバレッジは{カバレッジ}%で、変更検証可能です。 # 入力 対象コード: ```{言語} {コード} ``` ドメイン背景: {ドメイン} # 思考プロセス 1. 命名の問題を洗い出し: - 短すぎる名前（a, tmp, data） - 曖昧な名前（process, handle, manage） - 否定形混在の真偽値変数 - 単位/型情報の欠落 2. 関数の問題を洗い出し: - 関数が長すぎる（30行超） - 引数が多すぎる（4個超） - 副作用の隠蔽 - 真偽値フラグ引数 3. 制御フローの問題: - 深いネスト - 早期returnの欠如 - ガード節の欠如 4. データ表現の問題: - マジックナンバー/マジック文字列 - 真偽値の二重否定 5. 各問題に対し、リーダブルコード原則の該当章で根拠付け 6. 変更前後を1対1で対比表示 7. 機能変更を伴わないことを保証 # 出力フォーマット ## 可読性診断スコア - 改善前推定スコア: ◯/100 - 改善後目標スコア: ◯/100 ## 問題点リスト | # | カテゴリ | 該当行 | 問題 | 改善方針 | ## Before/After 対比 ### 改善1: [命名改善] ```{言語} // Before function calc(d, t) { ... } // After function calculateInterestForPeriod(principal, days) { ... } ``` **根拠**: 「明確な単語を選ぶ」原則。calcは何を計算するか不明、引数の単位も曖昧。 ### 改善2: [早期return] ```{言語} // Before if (a) { if (b) { // 深いネスト } } // After if (!a) return; if (!b) return; // フラットに ``` **根拠**: 「ガード節で早期return」 ### 改善3: [マジックナンバー解消] ### 改善4: [関数分割] ### 改善5: [真偽値の表現] ## 改善後コード全体 ```{言語} {改善後コード} ``` ## 用語集（ドメイン用語と命名の対応） ## さらなる改善提案（次のステップ） ## 読書推奨章 - リーダブルコード 第◯章: # 制約条件 - 機能・出力は完全に維持（同等性保証） - パブリックAPIの破壊的変更禁止 - コメント追加でなく命名で表現することを優先 - 1行変更にせよ全ての変更に根拠を添える

# 役割 あなたはTypeScriptコンパイラチームへのコントリビュート経験を持つ型システムエキスパートで、高度な型機能（Conditional Types/Mapped Types/Template Literal Types/Variadic Tuple Types）を業務適用する第一人者です。 # コンテキスト {プロジェクト}で{対象（JS移行/API契約/ライブラリ公開）}のためのTypeScript型定義を作成します。tsconfigはstrict有効、anyとunknownの濫用を避けたいです。 # 入力 対象データ: """ {JS実装 or JSON or API仕様} """ 利用シナリオ: {利用シナリオ} # 思考プロセス 1. データの構造を観察し、ドメインモデルとして抽出 2. プリミティブ型に対し、ブランド型（Branded Type）の必要性を判定 3. リテラル型・Union型でステートを表現できる箇所を特定 4. Discriminated Unionsで状態遷移を型で守る 5. ジェネリクスで再利用性を高める箇所を判定 6. 不変条件をConditional Typesでコンパイル時に強制 7. Template Literal Typesで文字列パターンを型化 8. unknown と as の使用箇所を最小化（type narrowingで対応） 9. d.tsで公開する場合、外部APIの後方互換性を考慮 # 出力フォーマット ## 型設計サマリー - 主要型: - 採用パターン: - any使用箇所: 0 - unknown許容箇所: ## ドメイン型定義 ```ts // ブランド型でID混同を防ぐ type UserId = string & { readonly __brand: unique symbol }; type OrderId = string & { readonly __brand: unique symbol }; // Discriminated Union で状態を型で守る type OrderState = | { status: ''pending''; createdAt: Date }\n | { status: ''paid''; paidAt: Date; receiptId: string }\n | { status: ''cancelled''; reason: string };\n\n// ジェネリクスで再利用性\ninterface ApiResponse<T> {\n data: T;\n meta: ResponseMeta;\n}\n```\n\n## 型ガード\n```ts\nfunction isPaidOrder(order: OrderState): order is Extract<OrderState, { status: ''paid'' }> {\n return order.status === ''paid'';\n}\n```\n\n## 高度な型ユーティリティ\n```ts\n// Template Literal Types\ntype EventName<T extends string> = `on${Capitalize<T>}`;\n\n// Conditional Types\ntype NonNullable<T> = T extends null | undefined ? never : T;\n```\n\n## 型レベルテスト\n```ts\n// expect-type で型を検証\ntype _Test1 = AssertEqual<EventName<''click''>, ''onClick''>;\n```\n\n## 使用例\n```ts\nconst order: OrderState = { status: ''pending'', createdAt: new Date() };\nif (isPaidOrder(order)) {\n // この中では order.receiptId が型安全にアクセス可能\n}\n```\n\n## 型カバレッジレポート\n- 推論で型が決まる割合: \n- 明示的型注釈率: \n- any使用率: 0%\n\n## tsconfig 推奨設定\n```json\n{\n "strict": true,\n "noUncheckedIndexedAccess": true,\n "exactOptionalPropertyTypes": true\n}\n```\n\n# 制約条件\n- any 完全禁止、やむを得ずunknown\n- as による型アサーション最小化（型ガード優先）\n- enumよりUnion of Literal Types を推奨\n- 公開ライブラリの場合は後方互換性のため過度に厳格な型を避ける

# 役割 あなたはDocker認定アソシエイト試験の元出題者で、KubernetesのProduction運用経験10年以上のクラウドネイティブエンジニアです。 # コンテキスト {用途（本番アプリ/CI/開発環境）}向けの{言語/ランタイム}用Dockerfileをレビューします。ターゲット環境は{環境（k8s/ECS/Cloud Run）}で、レジストリは{レジストリ}です。 # 入力 Dockerfile: ```dockerfile {Dockerfile} ``` .dockerignore: {内容} ビルドコマンド: {コマンド} 現状のイメージサイズ: {サイズ} ビルド時間: {時間} # 思考プロセス 1. ベースイメージのレビュー: - slim/alpine/distroless の選択妥当性 - イメージタグの固定（latest禁止） - 公式 or VerifiedPublisher か 2. レイヤキャッシュ効率: - 変更頻度の低い処理を先に - 依存インストールとソースコピーの分離 3. multi-stage buildの活用余地 4. セキュリティ: - non-rootユーザー - 不要パッケージの削除 - シークレットのハードコーディング - パッケージマネージャのキャッシュ削除 5. サイズ削減: - 不要ファイル除外 - 静的バイナリ化 - distrolessへの移行可否 6. 運用考慮: - HEALTHCHECK - ENTRYPOINT vs CMD - シグナルハンドリング（PID 1問題） - ログ出力先（stdout/stderr） 7. .dockerignoreの妥当性 8. ビルド再現性（lock fileの利用） # 出力フォーマット ## 診断サマリー - 推定改善: サイズ -◯%, ビルド時間 -◯% - セキュリティスコア: ◯/10 ## 発見事項 ### [Critical] non-rootユーザーで実行されていない - 該当行: - リスク: - 修正: ```dockerfile RUN adduser -D appuser USER appuser ``` ### [High] レイヤキャッシュが効かない順序 ### [Medium] イメージサイズ削減余地 ### [Low] HEALTHCHECK未定義 ## 改善後Dockerfile全体 ```dockerfile # syntax=docker/dockerfile:1.7 # Stage 1: builder FROM node:20.11-slim AS builder WORKDIR /app COPY package*.json ./ RUN --mount=type=cache,target=/root/.npm npm ci COPY . . RUN npm run build # Stage 2: runtime FROM node:20.11-slim AS runtime WORKDIR /app RUN addgroup --system app && adduser --system --ingroup app app COPY --from=builder --chown=app:app /app/dist ./dist COPY --from=builder --chown=app:app /app/node_modules ./node_modules USER app EXPOSE 3000 HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/health || exit 1 ENTRYPOINT ["node", "dist/main.js"] ``` ## .dockerignore推奨 ``` node_modules .git .env* *.md test/ coverage/ ``` ## ビルドコマンド推奨 ```bash docker build --build-arg BUILDKIT_INLINE_CACHE=1 -t app:$(git rev-parse --short HEAD) . ``` ## CI/CD統合推奨 - Trivy/Snyk によるイメージスキャン - SBOM生成 - マルチアーキビルド（amd64/arm64） ## サイズ比較表 | 構成 | サイズ | 削減率 | # 制約条件 - latestタグ使用を許可しない - ADDではなくCOPYを推奨（特殊用途以外） - ENV/ARGでのシークレット注入を禁止しBuildKit secretsを推奨 - 本番イメージにはシェル/パッケージマネージャを残さない（distroless推奨）