プログラマーのためのプロンプトエンジニアリング・プレイブック
(addyo.substack.com)1. はじめに: プロンプトが開発生産性を左右する
- AIコーディング支援ツールの性能は、プロンプトの品質に左右される。明確な依頼は精緻なコードを、曖昧な質問は役に立たない出力を生む。
- プロンプト作成は今や開発者にとって必須のスキルであり、これは開発パートナーを訓練する作業に近い。
- この記事では実践的な例と比較を通じて、「良い質問」がどのように「良いコード」を生み出すのかを示す。
2. 効果的なプロンプトの7つの原則
① 文脈を与える
- AIはユーザーのプロジェクト背景を知らないため、言語、フレームワーク、ライブラリ、エラーメッセージ、目的などを明示する必要がある。
- 例: 「Node.js + Express + Mongoose環境でuser fetch中にTypeErrorが発生」のように技術的背景を含める。
② 目標を明確にする
- 「コードが動きません」では役に立たない。「期待結果は○○なのに実際は△△です。なぜですか？」という形で正確に尋ねよう。
③ 複雑な作業を分割する
- 機能全体を一度に尋ねるより、段階ごとに依頼するほうが効果的だ。例: コンポーネント > 状態管理 > API統合。
④ 入出力の例を含める
- 望む出力例を示すと、AIの意図把握能力が高まる。 (e.g.
[3,1,4]→[1,3,4])
⑤ 役割を与える
- 「シニアReact開発者のようにコードをレビューして」のような役割設定は、応答の深さと品質を向上させる。
⑥ 対話的に繰り返し改善する
- 最初の応答が完璧である必要はない。フィードバックを与えれば、AIはその流れを引き継いで徐々に精緻な結果を出す。
⑦ コードの一貫性を保つ
- 関数名、フォーマット、コメントなど、コード自体が一貫して書かれていれば、AIもその流れを維持して品質が高まる。
3. デバッグのためのプロンプト戦略
① エラーの明示と期待動作との比較
- エラーメッセージ、問題の症状、期待結果、入力値を一緒に提示すれば、AIは正確に診断できる。
② 行単位の追跡を依頼する
- 「この変数の値がどこでおかしくなったのかを段階的に追跡して」のような依頼は、複雑なロジックバグに効果的だ。
③ 最小再現コードを提供する
- 全体のコードではなく、問題が発生する核心部分だけを渡せば、AIはより正確に原因を分析できる。
④ 明確な追加質問をする
- 「なぜこういう結果になるのですか？」より、「この部分ではどの条件が間違っているのでしょうか？」のような直接的な質問がよい。
⑤ 比較例: 悪い質問 vs. 良い質問
- 単に「コードが動かない」と言うだけでは推測ベースの回答しか出てこないが、エラーメッセージとコードを一緒に渡せば正確な解決策を得られる。
4. リファクタリングと最適化のためのプロンプト戦略
① リファクタリングの目標を明確にする
- 単に「リファクタリングして」ではなく、「可読性向上、性能改善、APIの最新化」など具体的な改善目標を示すべきだ。
- 目標が曖昧だと、AIは無作為な改善を試みたり、望まない方向へ変えてしまうことがある。
② 言語・環境の文脈を与える
- 「Reactのクラスコンポーネント → 関数コンポーネントへの変換」、「Node.js 14環境」など、プロジェクトのスタイルや技術的制約を知らせれば、適切な変換が可能になる。
③ 説明もあわせて求める
- リファクタリング後のコードと一緒に「なぜこう変えたのか」の説明を求めれば、コード品質のレビューと学習効果の両方を得られる。
④ 役割ベースの依頼で水準を高める
- 「シニアTypeScript開発者のようにリファクタリングして」のような依頼は、よりモダンで深みのある改善案を引き出す。
5. 新機能実装のためのプロンプト戦略
① 機能を段階に分けて依頼する
- 複雑な機能でも「機能構造の設計 → UI作成 → ロジック接続」の順に分けて依頼すれば、より安定した結果を得られる。
② 既存コードのスタイルを示す
- 類似コンポーネントや内部規約を提示すれば、プロジェクトの一貫性に合ったコードが生成される。例: 「UserListをベースにProductListを生成」
③ コメント/TODOで意図を伝える
- IDEで「// TODO: リクエストのバリデーションを実装」のように自然言語コメントを付けると、Copilotがそれに合ったコードブロックを自動生成する。
④ 入出力の例を提示する
- 入力値と期待出力の例を含めると、AIはそれを満たそうとし、精度が高まる。
⑤ フィードバックベースで繰り返し改善する
- 最初の結果が期待に届かなくても、「filterではなくmapを使ってください」のようにフィードバックすれば、AIはすぐに反映して進化する。
6. 失敗するプロンプトの7つのパターン (Anti-patterns)
① 曖昧な依頼
- 「このコード、なぜ動かないのですか？」のような質問は、意味のない一般論的な回答しか引き出さない。エラーメッセージ、コード、期待結果を含めよう。
② 要求過多
- 「アプリ全体を生成 + 認証機能追加 + デプロイスクリプト込み」などの複合依頼は、漏れや混乱を招くため、段階的な分離が必要だ。
③ 質問がない
- コードだけを投げて依頼がないと、AIは要約をしたり無関係な結果を出しやすいので、質問の目的を明確にすべきだ。
④ 成功基準が不明確
- 「速くして」「もっと良くして」は基準が曖昧だ。例: 「O(n)の時間計算量に改善」のように、測定可能な基準を示す必要がある。
⑤ AIの質問を無視する
- AIが「これは関数型ですか、クラス型ですか？」と尋ねたなら、それに答えてこそ最適化された出力を得られる。
⑥ 一貫性不足
- スタイル、文法、用語が次々に変わると、AIも混乱する。ひとつのスタイルを維持してこそ応答品質が向上する。
⑦ 「上のコード」のような曖昧な参照
- 会話が長くなるほど「上のコード」は不明確になる。できるだけコードを再提示するか、明示的に関数名へ言及しよう。
7. 結論: AIとの協業は反復的な対話だ
- プロンプトエンジニアリングは今や開発者の中核的なコミュニケーションスキルだ。文脈の提示、明確な目標、反復的な改善が基本である。
- AIはコーディング支援ツールではなく、協業者であり学習パートナーでもある。これをうまく活用すれば、生産性だけでなく開発力そのものも向上する。
- 実験、フィードバック、役割設定など多様な戦略を活用すれば、AIを実戦のチームメンバーのように扱える。
- 最終目標はより速く正確なコード生成だが、同時により良い開発者になるための学習ツールとしても積極的に活用すべきだ。
良いプロンプト vs 悪いプロンプト 比較表
| 区分 | デバッグ | リファクタリング | 機能実装 |
|---|---|---|---|
| 良いプロンプト | TypeErrorが発生する箇所はここです。期待値は○○ですがNaNが出ます。原因の特定をお願いします。 |
この関数の重複を取り除いて性能を改善してください。fetch部分はhelperに分離し、エラーメッセージは維持してください。 |
検索ボックス付きのProductListコンポーネントを作成してください。/api/productsからJSONを受け取り、一覧をフィルタリングし、エラー・ローディング状態も含めてください。 |
| 悪いプロンプト | なぜ私の関数は動かないのですか？ |
リファクタリングしてください。 |
検索機能を作ってください。 |
5件のコメント
人間のプログラマーを相手にするのと変わりませんね。
プログラマーのためのプロンプトエンジニアリング・プレイブック
GN+要約ボットが要約したバージョンもあわせて参考にしてください。Hacker News の要約コメントも読む価値があります。
先に投稿されていたんですね..
ありがとうございます。
頼むから頼むからこうするなと言っても、10回に1回はそうするやつらなんだよ -_-
人間が何を知ってるっていうんだ！