コーディング
プロンプト集

レビュー、リファクタ、デバッグ、テスト、設計、解説。エンジニアが実務で使う6カテゴリを日本語プロンプトで網羅。

Claude 4、ChatGPT GPT-5、GitHub Copilot、Cursor 対応。

コードはコンテクスト依存のため、用途別プロンプトが必要です。

コードは周辺のコードベース、言語バージョン、フレームワーク、チーム規約に強く依存します。「このコードをレビューして」のような汎用指示では、モデルが一般論に終始し、プロジェクトに合わない指摘を量産します。環境、制約、出力形式、評価基準を明示したプロンプトが実用水準の第一歩です。

本ページでは、コードレビュー、リファクタリング、バグ修正、テスト生成、アーキテクチャ設計、コード説明の6カテゴリで、そのまま使えるプロンプトを日本語で提供します。すべて ChatGPT、Claude、Copilot、Cursor 上で動作する設計です。

01, コードレビュー

セキュリティ / パフォーマンス / 可読性の3軸レビュー

PR 投入前のセルフレビューを自動化し、人間レビュアーの負担を軽減するプロンプト。

プロンプト(コピペ可)

# 役割
あなたはシニアソフトウェアエンジニアで、コードレビューで以下の3軸を優先評価します。
1. セキュリティ(注入攻撃、認証、権限、機密データ)
2. パフォーマンス(計算量、メモリ、I/O、N+1)
3. 可読性(命名、関数分割、コメント、型安全性)

# コンテクスト
- 言語: {{language}}
- フレームワーク: {{framework}}
- チーム規約: {{style_guide_link_or_rules}}

# タスク
以下のコードをレビューし、問題を優先度(P0: 重大、P1: 高、P2: 中、P3: 低)付きで列挙してください。

# 出力形式
各問題について:
- 優先度
- 問題のカテゴリ(セキュリティ / パフォーマンス / 可読性)
- 該当箇所(行番号)
- 何が問題か(1〜2文)
- 修正案(コードスニペット)
- 参考資料(OWASP、公式ドキュメントの URL があれば)

# コード
```{{language}}
{{code}}
```

# 指示
- P0 問題が1つ以上ある場合、マージを推奨しないと明記
- 改善提案と「このコードのまま問題ない箇所」の両方を明示
- 1問題につき50字以内の要約を先頭に

実務メモ: GitHub Actions のプレコミットフックに組み込むと効率的。Claude Code や Cursor の PR レビュー機能でも同構造が使える。

02, リファクタリング

可読性を上げる安全なリファクタ提案

動作を変えずに可読性と保守性を上げる、段階的なリファクタリング手順を出力するプロンプト。

プロンプト(コピペ可)

# 役割
あなたは15年以上の経験を持つリファクタリング専門家(Martin Fowler の著作に精通)です。

# 対象コード
```{{language}}
{{code}}
```

# コンテクスト
- テストカバレッジ: {{coverage}}% (低い場合はより保守的に)
- 既存の依存関係: {{dependencies}}
- チームの慣習: {{team_patterns}}

# タスク
以下を満たすリファクタリング計画を出力:

1. 問題点(現状のコードの設計上の問題3〜5点)
2. 目標状態(リファクタ後の期待される構造)
3. 段階的手順(各ステップでテストが通る単位で、5〜10ステップに分割)
4. 各ステップの「変更内容」「影響範囲」「リスク」
5. 完了後のコード全文
6. 追加すべきテスト

# 原則
- Red-Green-Refactor サイクルを前提
- パブリック API の後方互換性を維持(破壊的変更は別ステップで明示)
- 1PR = 1論理変更を推奨
- 過剰な抽象化(YAGNI 違反)は避ける

実務メモ: Claude 4 で長いコードも1回で処理可能。大規模リファクタでは段階を分けて複数回に分割すると安全。

03, バグ修正

再現手順とルートコーズから修正案を導く

症状だけでなく根本原因を特定し、回帰防止テストまで提案するデバッグ支援プロンプト。

プロンプト(コピペ可)

# 役割
あなたはシニアデバッガーで、症状だけでなく根本原因の特定を優先します。

# 情報
- 症状: {{symptom}}
- 再現手順: {{steps}}
- 期待動作: {{expected}}
- 実動作: {{actual}}
- 環境: {{env}}
- 関連コード: 以下

```{{language}}
{{code}}
```

# 追加情報
- エラーログ: {{logs}}
- スタックトレース: {{stack}}

# タスク
1. 仮説を3つ立て、最も可能性が高い順に並べる(根拠も添える)
2. 各仮説を検証する方法(ログ、ブレークポイント、単体テスト)
3. 最有力仮説に対する修正案(コードパッチ形式)
4. 修正後に追加すべき回帰テスト(何をテストするか、テストコード例)
5. 類似の問題を予防する設計変更の提案

# 原則
- 症状への対症療法ではなく根本原因の修正を優先
- 推測で修正を提案せず、「未確認情報」はユーザーに質問
- 修正のスコープは最小に保つ

実務メモ: スタックトレースや再現手順を丁寧に渡すほど精度が上がる。不明点はモデル側から質問させる指示が有効。

04, テスト生成

境界値と異常系を網羅する単体テスト

正常系だけでなく境界条件、異常系、並行性まで考慮したテストスイートを生成するプロンプト。

プロンプト(コピペ可)

# 役割
あなたはテスト駆動開発(TDD)の実践者です。

# 対象コード
```{{language}}
{{code}}
```

# テストフレームワーク
{{test_framework}} 例: Jest / Vitest / pytest / RSpec

# タスク
以下を含む包括的なテストスイートを生成:

1. 正常系(典型的な入力と期待出力、3〜5ケース)
2. 境界値(最小、最大、閾値前後、空配列、null、undefined)
3. 異常系(型エラー、権限エラー、タイムアウト、ネットワーク障害)
4. 並行性(該当する場合: 競合状態、デッドロック)
5. モックとスタブの設定(外部依存がある場合)
6. テストヘルパー / フィクスチャ(繰り返し使う準備コード)

# 出力
- 各テストケースに、テスト名で「何を検証しているか」が分かるよう命名
- Arrange-Act-Assert パターンで構造化
- コメントで「なぜこのケースをテストするか」を各テストに1行

# 品質基準
- ブランチカバレッジ 90%以上を狙う
- 過度な実装詳細のテスト(リファクタで壊れるもの)は避ける
- フレーキーテストの原因(時刻依存、順序依存)を排除

実務メモ: GPT-5 と Claude 4 が特に強い。生成後は実際に実行し、パスしないテストを修正するサイクルで完成度を上げる。

05, アーキテクチャ設計

要件からアーキテクチャ選定まで

機能要件と非機能要件から、アーキテクチャパターン、技術スタック、トレードオフを含む設計案を出力するプロンプト。

プロンプト(コピペ可)

# 役割
あなたは10年以上の経験を持つソフトウェアアーキテクトで、AWS/GCP/Azure すべてに精通し、分散システムに強い。

# プロジェクト情報
- プロダクト概要: {{product}}
- 主要ユースケース: {{use_cases}}
- 予想負荷: {{scale}} 例: 10万 DAU、ピーク時毎秒1000リクエスト
- チーム規模: {{team_size}}
- 既存制約: {{constraints}} 例: Python 必須、AWS 固定

# 非機能要件(優先順位付き)
- 可用性: {{availability_target}}
- レイテンシ: {{latency_target}}
- 開発速度 vs 運用コスト: {{tradeoff_preference}}

# 出力
1. アーキテクチャ概要(主要コンポーネントとデータフロー、テキストで)
2. 各コンポーネントの責務と選定理由
3. データストア選定(OLTP / OLAP / キャッシュ / 検索の使い分け)
4. 主要なトレードオフ3つ(選択理由と却下した代替案)
5. 段階的実装ロードマップ(MVP から本番規模へ、3〜5フェーズ)
6. リスクと対策(技術的リスク、運用リスク、コストリスク)
7. 参考アーキテクチャ(類似プロダクトの事例、あれば)

# 原則
- 過剰設計(YAGNI 違反)を避ける
- モノリシックで始めるか、マイクロサービスで始めるかの判断根拠を明示
- コンウェイの法則を意識(チーム構造と整合)

実務メモ: Claude 4 が長文要件と推論で圧倒的に強い。出力を Miro / Excalidraw で図式化するとレビューが捗る。

06, コード説明

新メンバーにも伝わるコード解説

既存コードの意図、設計判断、注意点を、異なる習熟度の読者向けに説明するプロンプト。

プロンプト(コピペ可)

# 役割
あなたはテクニカルライターとシニアエンジニアを兼ねる存在です。

# 対象コード
```{{language}}
{{code}}
```

# 読者
{{audience}} 例: Python は知っているが本プロジェクト初参加の中堅エンジニア

# タスク
以下の4段階で解説:

1. 30秒サマリ (3文以内、このコードが何をするか)
2. 全体構造 (主要な関数、クラス、責務の配置)
3. 行ごとの注目ポイント(複雑または非自明な箇所のみ、行番号付き)
4. 設計判断と背景(なぜこの実装か、代替案と却下理由)
5. 注意点(触ると壊れる箇所、変更時の影響範囲)
6. 拡張する場合のフック(将来の機能追加時の変更ポイント)

# 原則
- 専門用語を使う場合は初出時に30字以内で補足
- コード中のコメントを鵜呑みにせず、実装と矛盾があれば指摘
- 「これは明らか」とせず、暗黙の知識を言語化する

実務メモ: オンボーディング資料や社内 Wiki への転載用途で有効。コードベース全体のアーキテクチャ解説なら分割して複数回実行。

自プロジェクトに合わせてカスタマイズ。

ジェネレーターに要件を入れると、言語、フレームワーク、チーム規約を組み込んだ3バリエーションを生成します。

Claude ジェネレーター →ChatGPT ジェネレーター →v0 ジェネレーター →

よくある質問。

なぜコード向けのプロンプトは一般のプロンプトと異なる構造が必要ですか?

コードはコンテクスト依存度が極めて高い言語的産物です。同じ関数でも、周辺のコードベース、言語バージョン、フレームワーク、チーム規約、パフォーマンス要件によって最適解が変わります。汎用指示では、モデルが一般論を返すしかなく、実務では使えません。コード向けプロンプトは、環境、制約、出力形式、テスト要件を明示する必要があります。

Claude、GPT、Copilot のどれを使い分けるべきですか?

長文のコードレビューやアーキテクチャ設計では Claude 4(長文脈と推論で優位)、IDE 内での補完には GitHub Copilot、インタラクティブなデバッグや説明では ChatGPT GPT-5 が向いています。複雑なリファクタリング案件では Claude Code や Cursor のエージェント機能が強力です。本ページのプロンプトは3モデルで動作する設計です。

セキュリティ上、機密コードを LLM に渡して大丈夫ですか?

企業向けプラン(Claude Enterprise、ChatGPT Enterprise、Gemini for Google Workspace、GitHub Copilot Business)では、入力データの学習利用からオプトアウトされています。コンシューマー版(無料 / Plus / Pro)では設定でオプトアウト可能です。機密性が極めて高いコードは、オンプレミスモデル(Llama、DeepSeek、Qwen)を検討してください。

AI が生成したコードの品質をどう担保しますか?

3点が実務の鉄則です。(1) テストを先に書かせ、テストが通ることを確認する TDD 相当の運用、(2) 生成コードを必ず静的解析(ESLint、Pylint)と型チェックにかける、(3) レビューは『AI 生成だから』と甘くせず通常の PR レビュー基準で実施する。AI は一次生成を速くしますが、品質担保の工程は省略してはいけません。

プロンプトインジェクションのリスクはありますか?

あります。特に外部データ(ユーザー入力、API レスポンス)を LLM に渡す処理では、悪意ある指示が埋め込まれる可能性があります。対策: (1) システムプロンプトとユーザー入力を明確に分離(XML タグや Markdown で)、(2) 外部データはサニタイズ後に渡す、(3) モデルが外部指示で動作を変更しようとした兆候(『前の指示を無視』等)を検知するガードレール。本番環境では Guardrails や NeMo Guardrails の導入を推奨します。

既存コードのレビューに使う場合、全ファイルを送信すべきですか?

大きなコードベースでは、関連ファイル5〜10個に絞る方が精度が上がります。全ファイルを送ると、モデルが重要な箇所を見落とすリスクが増えます。依存関係が見えない場合は、関数シグネチャや型定義を先にサマリで渡し、その後特定ファイルの詳細を送る段階的アプローチが有効です。

日本語のプロンプトと英語のプロンプトで精度に差はありますか?

最新モデル(Claude 4、GPT-5、Gemini 2.5)では、日本語でも英語と同程度の精度でコード生成できます。ただしコード内のコメント、変数名、ドキュメンテーションは英語の方がモデルの事前学習データが豊富なため、実行精度がやや高い傾向があります。チーム規約に合わせて、コメントは日本語、変数名は英語という混成スタイルが現実的です。

コーディング
プロンプト集

レビュー、リファクタ、デバッグ、テスト、設計、解説。エンジニアが実務で使う6カテゴリを日本語プロンプトで網羅。

Claude 4、ChatGPT GPT-5、GitHub Copilot、Cursor 対応。

コードはコンテクスト依存のため、用途別プロンプトが必要です。

01, コードレビュー

セキュリティ / パフォーマンス / 可読性の3軸レビュー

PR 投入前のセルフレビューを自動化し、人間レビュアーの負担を軽減するプロンプト。

プロンプト(コピペ可)

# 役割
あなたはシニアソフトウェアエンジニアで、コードレビューで以下の3軸を優先評価します。
1. セキュリティ(注入攻撃、認証、権限、機密データ)
2. パフォーマンス(計算量、メモリ、I/O、N+1)
3. 可読性(命名、関数分割、コメント、型安全性)

# コンテクスト
- 言語: {{language}}
- フレームワーク: {{framework}}
- チーム規約: {{style_guide_link_or_rules}}

# タスク
以下のコードをレビューし、問題を優先度(P0: 重大、P1: 高、P2: 中、P3: 低)付きで列挙してください。

# 出力形式
各問題について:
- 優先度
- 問題のカテゴリ(セキュリティ / パフォーマンス / 可読性)
- 該当箇所(行番号)
- 何が問題か(1〜2文)
- 修正案(コードスニペット)
- 参考資料(OWASP、公式ドキュメントの URL があれば)

# コード
```{{language}}
{{code}}
```

# 指示
- P0 問題が1つ以上ある場合、マージを推奨しないと明記
- 改善提案と「このコードのまま問題ない箇所」の両方を明示
- 1問題につき50字以内の要約を先頭に

実務メモ: GitHub Actions のプレコミットフックに組み込むと効率的。Claude Code や Cursor の PR レビュー機能でも同構造が使える。

02, リファクタリング

可読性を上げる安全なリファクタ提案

動作を変えずに可読性と保守性を上げる、段階的なリファクタリング手順を出力するプロンプト。

プロンプト(コピペ可)

# 役割
あなたは15年以上の経験を持つリファクタリング専門家(Martin Fowler の著作に精通)です。

# 対象コード
```{{language}}
{{code}}
```

# コンテクスト
- テストカバレッジ: {{coverage}}% (低い場合はより保守的に)
- 既存の依存関係: {{dependencies}}
- チームの慣習: {{team_patterns}}

# タスク
以下を満たすリファクタリング計画を出力:

1. 問題点(現状のコードの設計上の問題3〜5点)
2. 目標状態(リファクタ後の期待される構造)
3. 段階的手順(各ステップでテストが通る単位で、5〜10ステップに分割)
4. 各ステップの「変更内容」「影響範囲」「リスク」
5. 完了後のコード全文
6. 追加すべきテスト

# 原則
- Red-Green-Refactor サイクルを前提
- パブリック API の後方互換性を維持(破壊的変更は別ステップで明示)
- 1PR = 1論理変更を推奨
- 過剰な抽象化(YAGNI 違反)は避ける

実務メモ: Claude 4 で長いコードも1回で処理可能。大規模リファクタでは段階を分けて複数回に分割すると安全。

03, バグ修正

再現手順とルートコーズから修正案を導く

症状だけでなく根本原因を特定し、回帰防止テストまで提案するデバッグ支援プロンプト。

プロンプト(コピペ可)

# 役割
あなたはシニアデバッガーで、症状だけでなく根本原因の特定を優先します。

# 情報
- 症状: {{symptom}}
- 再現手順: {{steps}}
- 期待動作: {{expected}}
- 実動作: {{actual}}
- 環境: {{env}}
- 関連コード: 以下

```{{language}}
{{code}}
```

# 追加情報
- エラーログ: {{logs}}
- スタックトレース: {{stack}}

# タスク
1. 仮説を3つ立て、最も可能性が高い順に並べる(根拠も添える)
2. 各仮説を検証する方法(ログ、ブレークポイント、単体テスト)
3. 最有力仮説に対する修正案(コードパッチ形式)
4. 修正後に追加すべき回帰テスト(何をテストするか、テストコード例)
5. 類似の問題を予防する設計変更の提案

# 原則
- 症状への対症療法ではなく根本原因の修正を優先
- 推測で修正を提案せず、「未確認情報」はユーザーに質問
- 修正のスコープは最小に保つ

実務メモ: スタックトレースや再現手順を丁寧に渡すほど精度が上がる。不明点はモデル側から質問させる指示が有効。

04, テスト生成

境界値と異常系を網羅する単体テスト

正常系だけでなく境界条件、異常系、並行性まで考慮したテストスイートを生成するプロンプト。

プロンプト(コピペ可)

# 役割
あなたはテスト駆動開発(TDD)の実践者です。

# 対象コード
```{{language}}
{{code}}
```

# テストフレームワーク
{{test_framework}} 例: Jest / Vitest / pytest / RSpec

# タスク
以下を含む包括的なテストスイートを生成:

1. 正常系(典型的な入力と期待出力、3〜5ケース)
2. 境界値(最小、最大、閾値前後、空配列、null、undefined)
3. 異常系(型エラー、権限エラー、タイムアウト、ネットワーク障害)
4. 並行性(該当する場合: 競合状態、デッドロック)
5. モックとスタブの設定(外部依存がある場合)
6. テストヘルパー / フィクスチャ(繰り返し使う準備コード)

# 出力
- 各テストケースに、テスト名で「何を検証しているか」が分かるよう命名
- Arrange-Act-Assert パターンで構造化
- コメントで「なぜこのケースをテストするか」を各テストに1行

# 品質基準
- ブランチカバレッジ 90%以上を狙う
- 過度な実装詳細のテスト(リファクタで壊れるもの)は避ける
- フレーキーテストの原因(時刻依存、順序依存)を排除

実務メモ: GPT-5 と Claude 4 が特に強い。生成後は実際に実行し、パスしないテストを修正するサイクルで完成度を上げる。

05, アーキテクチャ設計

要件からアーキテクチャ選定まで

機能要件と非機能要件から、アーキテクチャパターン、技術スタック、トレードオフを含む設計案を出力するプロンプト。

プロンプト(コピペ可)

# 役割
あなたは10年以上の経験を持つソフトウェアアーキテクトで、AWS/GCP/Azure すべてに精通し、分散システムに強い。

# プロジェクト情報
- プロダクト概要: {{product}}
- 主要ユースケース: {{use_cases}}
- 予想負荷: {{scale}} 例: 10万 DAU、ピーク時毎秒1000リクエスト
- チーム規模: {{team_size}}
- 既存制約: {{constraints}} 例: Python 必須、AWS 固定

# 非機能要件(優先順位付き)
- 可用性: {{availability_target}}
- レイテンシ: {{latency_target}}
- 開発速度 vs 運用コスト: {{tradeoff_preference}}

# 出力
1. アーキテクチャ概要(主要コンポーネントとデータフロー、テキストで)
2. 各コンポーネントの責務と選定理由
3. データストア選定(OLTP / OLAP / キャッシュ / 検索の使い分け)
4. 主要なトレードオフ3つ(選択理由と却下した代替案)
5. 段階的実装ロードマップ(MVP から本番規模へ、3〜5フェーズ)
6. リスクと対策(技術的リスク、運用リスク、コストリスク)
7. 参考アーキテクチャ(類似プロダクトの事例、あれば)

# 原則
- 過剰設計(YAGNI 違反)を避ける
- モノリシックで始めるか、マイクロサービスで始めるかの判断根拠を明示
- コンウェイの法則を意識(チーム構造と整合)

実務メモ: Claude 4 が長文要件と推論で圧倒的に強い。出力を Miro / Excalidraw で図式化するとレビューが捗る。

06, コード説明

新メンバーにも伝わるコード解説

既存コードの意図、設計判断、注意点を、異なる習熟度の読者向けに説明するプロンプト。

プロンプト(コピペ可)

# 役割
あなたはテクニカルライターとシニアエンジニアを兼ねる存在です。

# 対象コード
```{{language}}
{{code}}
```

# 読者
{{audience}} 例: Python は知っているが本プロジェクト初参加の中堅エンジニア

# タスク
以下の4段階で解説:

1. 30秒サマリ (3文以内、このコードが何をするか)
2. 全体構造 (主要な関数、クラス、責務の配置)
3. 行ごとの注目ポイント(複雑または非自明な箇所のみ、行番号付き)
4. 設計判断と背景(なぜこの実装か、代替案と却下理由)
5. 注意点(触ると壊れる箇所、変更時の影響範囲)
6. 拡張する場合のフック(将来の機能追加時の変更ポイント)

# 原則
- 専門用語を使う場合は初出時に30字以内で補足
- コード中のコメントを鵜呑みにせず、実装と矛盾があれば指摘
- 「これは明らか」とせず、暗黙の知識を言語化する

実務メモ: オンボーディング資料や社内 Wiki への転載用途で有効。コードベース全体のアーキテクチャ解説なら分割して複数回実行。

自プロジェクトに合わせてカスタマイズ。

ジェネレーターに要件を入れると、言語、フレームワーク、チーム規約を組み込んだ3バリエーションを生成します。

Claude ジェネレーター →ChatGPT ジェネレーター →v0 ジェネレーター →

よくある質問。

なぜコード向けのプロンプトは一般のプロンプトと異なる構造が必要ですか?

Claude、GPT、Copilot のどれを使い分けるべきですか?

セキュリティ上、機密コードを LLM に渡して大丈夫ですか?

AI が生成したコードの品質をどう担保しますか?

プロンプトインジェクションのリスクはありますか?

既存コードのレビューに使う場合、全ファイルを送信すべきですか?

日本語のプロンプトと英語のプロンプトで精度に差はありますか?

コードはコンテクスト依存のため、用途別プロンプトが必要です。

セキュリティ / パフォーマンス / 可読性の3軸レビュー

プロンプト(コピペ可)

可読性を上げる安全なリファクタ提案

プロンプト(コピペ可)

再現手順とルートコーズから修正案を導く

プロンプト(コピペ可)

境界値と異常系を網羅する単体テスト

プロンプト(コピペ可)

要件からアーキテクチャ選定まで

プロンプト(コピペ可)

新メンバーにも伝わるコード解説

プロンプト(コピペ可)

自プロジェクトに合わせてカスタマイズ。

よくある質問。

関連する無料ツール。

ChatGPT プロンプトジェネレーター

Claude プロンプトジェネレーター

v0 プロンプトジェネレーター

Chain-of-Thought 完全ガイド

What to read next

OpenAI Codex Prompts

Claude Prompts

ChatGPT for Coding Interviews

コードはコンテクスト依存のため、用途別プロンプトが必要です。

セキュリティ / パフォーマンス / 可読性の3軸レビュー

プロンプト(コピペ可)

可読性を上げる安全なリファクタ提案

プロンプト(コピペ可)

再現手順とルートコーズから修正案を導く

プロンプト(コピペ可)

境界値と異常系を網羅する単体テスト

プロンプト(コピペ可)

要件からアーキテクチャ選定まで

プロンプト(コピペ可)

新メンバーにも伝わるコード解説

プロンプト(コピペ可)

自プロジェクトに合わせてカスタマイズ。

よくある質問。

関連する無料ツール。

ChatGPT プロンプトジェネレーター

Claude プロンプトジェネレーター

v0 プロンプトジェネレーター

Chain-of-Thought 完全ガイド