お問い合わせ
← ブログに戻る

GPT-5でコーディング支援を最大化するベストプラクティス

公開日: 2025年08月24日

核心ポイント

  • あいまい・矛盾指示は厳禁
  • 推論レベルを明示（low / medium / high）
  • ルールはXML風に分節化
  • “徹底的に”など過剰強制は逆効果
  • 実装前の自己評価プロンプトを必ず入れる
  • ツール予算や並列度を指示して暴走防止

10秒まとめ

  • 曖昧さゼロ
  • 推論レベルを指定
  • XMLで出力契約を固定
  • 強命令語を避ける
  • 自己点検を前置
  • ツール回数と並列度に上限

すぐ使えるプロンプト雛形

<code_editing_rules>
<guiding_principles>
- 変更範囲は最小限。副作用を列挙。
- モジュール化と再利用性を優先。
- 型安全を最優先（TypeScript strict）。
</guiding_principles>
<stack_defaults>
- Styling: Tailwind CSS
- Framework: Next.js App Router
- Tests: Vitest + Testing Library
</stack_defaults>
<output_contract>
- 変更ファイル一覧
- 差分(パッチ)と要約
- テストコードと実行コマンド
</output_contract>
</code_editing_rules>
<reasoning_effort level="medium"/> <!-- trivial=low, hard=high -->
<self_reflection>
- 実装前に5項目のチェックリストを自作し採点せよ。
- 採点が満点でなければ設計を再提案してから実装せよ。
</self_reflection>
<persistence>
- 仮定は黙って進め、最後に「前提と代替案」を列挙。
- ツール予算: 6回以内。並列探索は最大2本。
- 無関係な探索や依存インストールは禁止。
</persistence>

目的別ミニスニペット

バグ修正（小）

<task intent="fix-bug" severity="minor">
  - 再現手順を最初に文章化。
  - 原因仮説を3つ列挙→最有力1つを検証。
  - 変更は関数単位。公開APIは不変。
</task>
<reasoning_effort level="low"/>

リファクタリング（中）

<task intent="refactor" scope="module">
  - 循環依存の解消と凝集度↑、結合度↓を数値で評価。
  - 既存テストを温存。スナップショット更新は要説明。
</task>
<reasoning_effort level="medium"/>

ゼロイチ実装（大）

<task intent="greenfield">
  - ユースケース/境界/エラー時のUXを列挙。
  - API契約を最初に固定。I/O型を提示。
</task>
<reasoning_effort level="high"/>

失敗しがちな指示 → 改善例

  • 悪例:「情報を完全に集めてから答えて」「徹底的に」
    改善:「ツール呼び出しは最大4回。優先順に上から試行。中間結果を要約してから実装」
  • 悪例:「最適な方法で」
    改善:「レイテンシ<300ms、メモリ<200MB、変更ファイル3つ以下を優先」

IDE/エージェント統合の運用ルール

  • .cursor/rules やAGENTS.md に上記XMLブロックを保存
  • リポジトリ固有の禁止事項を明記（依存追加、ファイル削除、公開API破壊）
  • ツール予算と並列度のデフォルトを設定
  • PRテンプレに自己点検チェックを組み込み

評価チェックリスト

  • 指示の一意性: あいまい語の除去率
  • 推論レベル適合: タスク難度との一致
  • 変更最小性: 触った行数/ファイル数
  • 回帰安全性: 追加テスト数とカバレッジ変動
  • 可観測性: ログとエラー処理の一貫性
  • 再現性: セットアップと実行手順の明記

活用事例

  • Next.js App Router移行方針のドラフト→自己点検→差分PR
  • 型付けの弱いユーティリティ群の段階的リファクタ
  • 既存APIの互換維持を前提にキャッシュ層を追加

思考プロセス（推奨）

  1. タスク難度を3段階で判定 → 推論レベル決定
  2. 出力契約を先に固定（差分、テスト、手順）
  3. ツール予算と並列度で探索コストを制約
  4. 実装前に自己点検。やり直し条件を満たすか確認
  5. 最小変更で実装 → 回帰テスト → 前提と代替案を記録