デバッグ、リファクタリング、アーキテクチャレビューのためのClaudeコーディングプロンプト集

以下のすべてのプロンプトを機能させる4つの制約

プロンプト本体の前に、すべてに共通するルールを示します。どのコーディングプロンプトにもこれらを加えるほうが、モデルを変えるよりも出力を改善します。

バージョンを明記する。 学習データは、最も多くの記事があるメジャーバージョンに偏りがちで、それはしばしば実際に使っているバージョンとは違います。使用しているのは[フレームワーク][バージョン]、[言語][バージョン]ですと伝えれば、古い回答の大半を防げます。

差分を制限する。 修正を頼むと、しばしばリファクタリングが返ってきます。変更は最小限にとどめ、既存の構造と命名を保ち、変更した行をすべて一行の理由付きで列挙してくださいは、この文書の中で最も役に立つ一文です。

解決策の前に仮説を求める。 何が問題かと聞かれたモデルは、推測を結論として提示します。順位付けした原因と安価な確認方法を求められたモデルは、デバッグ計画を返します。

起こりうる不具合を求める。 これは何を壊す可能性があり、原因を直しているのか症状を直しているだけなのかという問いが、AI支援の中で最もコストの高い失敗、つまり欠陥は残ったまま症状だけを消す変更を見つけ出します。

デバッグ

1. 順位付けした仮説

エラーと関連コード、そしてすでに除外した内容を示します。まだ修正案は出さないでください。可能性の高い順に4つの原因を挙げ、それぞれについて、それを裏付けるか除外できる最も安価な確認方法を1つ挙げてください。エラー: [貼り付け]。コード: [貼り付け]。すでに除外したもの: [リスト]。スタック: [言語、フレームワーク、バージョン]。

2. 間欠的なバグ

これはおよそ[頻度]の頻度で、[条件]の下で間欠的に失敗します。この特定の症状を引き起こしうる間欠的な失敗のカテゴリを列挙してください。タイミング、順序、リソース枯渇、外部依存、実行間で漏れる状態、時計やタイムゾーン、キャッシュです。それぞれについて、コードのどこがそれを裏付けるか、あるいは矛盾するかを述べ、区別するために何を正確にログすべきかを教えてください。コード: [貼り付け]。

3. ローカルでは動く

これはローカルでは動作しますが、[環境]では失敗します。この特定の症状を引き起こしうる環境差異のカテゴリをすべて列挙してください。設定、環境変数、バージョン、ファイルシステムと大文字小文字の区別、タイムゾーンとロケール、ネットワークとDNS、権限、リソース制限、ビルドやバンドルの違いです。症状から見た可能性の高さで順位付けし、それぞれの診断コマンドを教えてください。

4. 適用する前に修正内容を説明させる

この修正がなぜ機能するのか、何を修正しないのか、そして何を壊す可能性があるのかを説明してください。本当の原因が別の場所にあり、これが症状へのパッチにすぎない場合は、そのことをはっきり伝えてください。

コードレビュー

5. 差分をレビューする

この差分を、要求水準の高いレビュアーとしてレビューしてください。優先順位は、正確性のバグ、セキュリティの問題、未処理の失敗モード、競合状態、そしてスタイルの順です。それぞれの指摘について、深刻度、該当する行、そして一般論ではなくこのコードベースでなぜ重要なのかを示してください。フォーマットについてはコメントしないでください。差分に問題がなければ、指摘を捻り出さずにそう伝えてください。コーディング規約: [説明]。差分: [貼り付け]。

6. セキュリティチェック

このコードをセキュリティの観点で具体的にレビューしてください。インジェクション、認証と認可の抜け、安全でないデシリアライズ、コードやログに含まれる秘密情報、検証されていない入力が機微な処理に到達すること、依存関係のリスクです。それぞれについて、カテゴリ名を挙げるだけでなく、具体的な攻撃経路を示してください。[デプロイ環境、認証層、データの機微性]を見なければ評価できない点は、はっきりそう述べてください。

7. 失敗モードの監査

このコード内の外部呼び出しそれぞれについて、遅い場合、失敗した場合、予期しないデータを返した場合、そして部分的にしか成功しなかった場合に何が起こるかを述べてください。そのうちどれが現在未処理で、どれが黙って通過するでしょうか。

最後のこの一つが、一般的なレビューよりも実際の本番問題を多く見つけます。誰もテストを書かなかった経路について尋ねているからです。

リファクタリングとアーキテクチャ

8. リファクタリング計画

[説明]をリファクタリングするための、順序立った計画を提案してください。制約: [x]の公開APIは変更できません。継続的にデプロイしているため、各ステップは単独でリリース可能でなければならず、各ステップ後にテストが通る必要があります。各ステップについて、変更内容、リスク、検証方法、ロールバック方法を示してください。リスクの低い順に並べてください。まだコードは書かないでください。

9. 反対側を主張させる

[文脈と制約]のもとで、[アプローチB]ではなく[アプローチA]を選ぼうとしています。Bについて最も強い主張をしてください。Bが正しいと言えるためには、私たちの制約についてどんなことが成り立っている必要があり、そのいずれかがここで実際に成り立っていますか。両方とも妥当だという結論で終わらせないでください。

10. 引き継いだコードを理解する

これが主要なソースファイルです。以下を作成してください。エントリーポイント、リクエストからレスポンスまでのデータフロー、共有されている状態とそれが変更される場所、外部依存とそれぞれが利用できない場合に何が起こるか、そして複雑さと結合度から見てバグを含む可能性が最も高い3つの領域です。提供した内容から判断できない点は、明示的に述べてください。

この最後の指示が重要です。モデルは、貼り付けていないファイルの挙動を、名前から推測して説明してしまいます。不明点を明示的にリストさせることで、次に何を読めばよいかがわかります。

テスト

11. 自分では書かなかったであろうテスト

この関数のテストケースを、おそらく私が考慮していないであろう入力に焦点を当てて書いてください。境界値、空とnull、unicode、非常に大きな値、並行呼び出し、そして実装内にある暗黙の前提です。各テストについて、それが検証している前提を述べてください。関数: [貼り付け]。

12. テストスイート自体をテストする

これが関数と既存のテストです。カバーされていない挙動は何ですか。具体的には、エラー経路、境界値、パラメータ間の相互作用、そしてどのテストも検証していない実装の振る舞いです。既存のテストは書き換えないでください。

後者のほうが価値の高いプロンプトですが、実行されることはめったにありません。カバレッジ率が示すのは、どの行が実行されたかであって、どの挙動が実際に固定されているかではありません。その両者のずれこそが、リグレッションの生まれる場所です。

セカンドオピニオンのパターン

このプロンプト集全体の中で最もレバレッジの高い習慣であり、複数のモデルを必要とする唯一のものです。

まず1つのモデルから回答を得ます。次にモデルを切り替えて、それを渡します。

別のエンジニアが、この問題に対してこの解決策を提案しました。何が問題かを見つけてください。エッジケースでの正確性、並行性、エラー処理、[規模]でのパフォーマンス、あるいは見落とされたよりシンプルなアプローチです。もし本当に問題がなければ、異議を捻り出さずにはっきりそう伝えてください。問題: [貼り付け]。提案された解決策: [貼り付け]。

結果は2通りで、どちらも有用です。2番目のモデルが本物の欠陥を見つければ、マージする前にそれを知ることができます。あるいは、反対するよう促されたにもかかわらず同意するなら、それは意味のある確認になります。同じモデルで繰り返しても、どちらも得られません。モデルは自分自身の出力をレビューすると、たいてい自分に同意してしまうからです。

間違えるとコストの高い判断に使いましょう。スキーマ変更、並行処理の修正、認証やお金に関わるものです。日常的な作業には使いません。ワークフロー全体を一箇所でまとめて確認するには、モデルを並べて比較する、会話の途中でモデルを切り替える、複数のモデルでコードを書きデバッグするを参照してください。

注意すべき点

存在しないAPIの創作。 自信満々に示されるメソッド名、パラメータ、設定キーが実際には存在しないことがあります。特に最近変更されたライブラリで起こりやすいです。シグネチャは正しく見えます。不慣れなものの上に構築する前に、実際のドキュメントを確認してください。

確信度の合図がない。 正しい修正と微妙に間違った修正が、まったく同じ確信度で返ってきます。口調からは何もわかりません。

気づかないうちに範囲が広がる。 これが2つ目の制約が存在する理由です。

セキュリティの見せかけ。 コード内の脆弱性のカテゴリを挙げることは、最初の一歩として有用です。ただしそれは監査ではなく、モデルはあなたの脅威モデルもデプロイ環境もデータの機微性も知りません。

毎週使うプロンプトは、すぐに貼り付けられる場所に保存しておきましょう。そして、常に適用したい制約はプロジェクトの指示に入れておけば、そのプロジェクト内のすべてのチャットに自動的に適用されます。