なぜこう書くのか
コードのパフォーマンス改善プロンプトを「速く直して」から始めると、AIは表面的な書き換えに終始しがちです。ループの内包表記化や変数の整理など細かい修正ばかりが並び、実際に時間を浪費している「ループ内でのDBクエリ（N+1問題など）」が見落とされることがあります。計測なしで着手すると、効果のない修正ばかりが増えてしまいます。
役割を「原因特定を行ってきたエンジニア」に設定することで、回答の質が大きく変わります。コードレビュアーに尋ねると変数名やスタイルの指摘が先に出てきますが、障害原因の調査担当に尋ねれば「どこで時間が消費されているか」に着目します。同じコードでも、誰に尋ねるかで回答の着眼点が変わるためです。
ステップを4つに限定した点がこのプロンプトの肝です。候補を順位付けさせると必ず根拠が必要になり、検証手順まで求めれば「推測」と「事実」を切り離せます。特に3番の検証手順は、AIの修正案を鵜呑みにしてデプロイするのを防ぎ、実際の数値を見て判断する習慣を作ります。
コンテキストとしての2つの変数も重要です。400万行と400行では問題の本質がまったく異なります。制約で「体感差が出ない微細な最適化は省く」としたのはこの規模感を基準にフィルタリングさせるためであり、「見えない情報はリスト化する」ことで、インデックスの有無も知らずにインデックス追加を提案してくるような回答を防ぎます。コードは """ で囲み、コメントなどがプロンプトの指示として誤認されるのを防ぎます。
用語が分からなければAha AIで: chain-of-thought, hallucination
悪い例との比較
このコード遅すぎるから最適化して for order in orders: ... (コード貼り付け)
データ規模がわからないため、AIは一般論しか返せません。リストをセットに変えたりループを内包表記に書き直したりしたコードが返ってきますが、実行時間はほぼ変わりません。ループ内のDBアクセスが真の原因であっても、根拠を求めていないため他の細かい提案に埋もれてしまい、何の効果測定をすべきかも分からないままになります。
バリエーション
コードではなく画面全体の描画が遅い場合
自社サービスで特定の画面の表示が遅いという報告が届きました。実行環境は {{実行環境}}、データ規模は {{データ規模}} です。コードを細かく見る前に、この状況で原因となり得るボトルネックをサーバー・データベース・ネットワーク・ブラウザに分類してリストアップし、それぞれを確認する手順と優先順位を教えてください。確認が容易なものから順に並べてください。
どのレイヤー・どのコードが問題なのか見当もつかないときに使います。切り分けの順序をあらかじめ把握しておくことで、あてもなくコードを探る時間を削減できます。
高速化修正による副作用（デグレーション）を確認したい場合
以下は、パフォーマンス改善を目的に私が修正したコードです。速くなったかどうかではなく、修正によって処理結果や挙動が変わってしまった可能性がないかだけを検証してください。結果の順序、重複の扱い、例外発生時の挙動、同時リクエスト時の挙動をそれぞれ確認し、問題が発生し得る入力パターンの例を挙げてください。
""" {{コード}} """
パフォーマンス目的の修正は、意図せず元の挙動を壊してしまうことがよくあります。速度の検証とロジックの正確性の検証は、分けてプロンプトを投げるほうが確実です。
モデル別の注意
実際にプロファイリングを行って計測した実行時間や数値があれば、一緒に入力してください。数値がない場合、AIはコードの見た目から推測するしかなくなります。
関連プロンプト
最終更新 2026-09-02 · 誤りがありますか？ 知らせる