世界を動かす技術を、日本語で。

プログラマーのためのプロンプトエンジニアリングプレイブック

概要

  • AIコーディングアシスタント の利用が開発現場で増加
  • プロンプトエンジニアリング の重要性が高まる傾向
  • 良いプロンプトと悪いプロンプトの比較と解説
  • 具体的なプロンプト作成法 とデバッグ例の紹介
  • 再現性の高いフレームワーク と実践的なヒントを解説

AIコーディングアシスタント活用のためのプロンプト設計術

  • AIアシスタント は、関数の自動補完、バグ修正、モジュール生成など多岐に活用可能
  • 出力品質 はプロンプトの質に大きく依存
  • プロンプトエンジニアリング が必須スキル化
  • 曖昧な指示 では一般的・的外れな回答になりやすい
  • 具体的・詳細なプロンプト で創造的かつ正確なコード生成

基本原則

  • 十分な文脈提供

    • 言語、フレームワーク、ライブラリ、該当関数やエラー内容を明記
    • 例:「Node.jsのExpressとMongooseを使った関数でTypeErrorが発生。コードとエラーは以下…」
    • 情報量が多いほど正確な出力
  • 目的や質問の明確化

    • 「なぜ動かない?」ではなく「このJavaScript関数がundefinedを返す理由と修正方法は?」のように具体化
    • 期待動作・現状・入力例を明記するプロンプトフォーマット推奨
    • 具体性がAIの焦点を定める
  • 複雑なタスクは分割

    • 一度に全体を依頼せず、段階的に小さなタスクで依頼
    • 例:「まずReactのコンポーネントスケルトンを生成、次に状態管理、最後にAPI連携」
    • 段階的なアプローチで精度向上
  • 入力・出力例や期待動作の提示

    • 例:「[3,1,4]を渡したら[1,3,4]を返すべき」
    • テストケース提示で意図を明確化(few-shot prompting)
  • ロール・ペルソナの活用

    • 例:「シニアReact開発者としてコードレビューして」「JavaScriptパフォーマンスエキスパートとして最適化」
    • 役割指定で専門的な視点・深い指摘を誘導
  • 対話的な反復と修正

    • 初回回答後に「再帰を使わずに実装して」「変数名とコメントを改善して」等の追加指示
    • AIを“コーチ可能なパートナー”として活用
  • コードの明瞭性・一貫性維持

    • きれいな命名・整ったフォーマット・コメントでAIにも人にも分かりやすく
    • AIはコードやコメントの“手がかり”を重視

デバッグ時のプロンプト実践例

  • 問題と症状の明確な説明

    • 例:「JavaScript関数で配列の合計値を返すはずがNaNになる。コードは以下。期待出力は数値だが、NaNが返る。原因は?」
    • コード+エラー+期待結果+試した内容 のセットで依頼
  • ステップバイステップまたは行ごとの解析依頼

    • 例:「この関数を1行ずつ追い、totalの値を追跡。どこでロジックが崩れるか?」
    • AIに“ラバーダックデバッグ”を依頼
  • 最小再現例の提示

    • 問題を再現する最小限のコードを抽出しAIに提示
    • 例:「この短いコードでエラーが再現。なぜ?」
    • ノイズ除去でAIの分析効率向上
  • フォーカスした質問とフォローアップ

    • 例:「この問題の原因と修正方法は?」「修正版コードを提示して」「なぜその修正で直るのか説明して」
    • 対話型のやりとりで理解深化

良いプロンプトと悪いプロンプトの比較例

  • バグのあるNode.js関数例
    • 目的:ユーザー配列をIDでマッピングするオブジェクトへ変換
    • バグ:forループでi <= users.lengthとしており、最後のループでundefined参照エラー
  • 悪いプロンプト例
    • 「この関数が動かない。なぜ?」
    • AIは一般的な推測しかできず、具体的な指摘が得られにくい
  • 良いプロンプト例
    • 「Node.jsでユーザー配列をIDでマッピングする関数。forループのi <= users.lengthでTypeErrorが発生。コードは以下。期待動作は…エラーは…原因は?」
    • エラー状況・期待・コードが明確で、AIが正確にバグ箇所を特定可能

まとめ・実践のコツ

  • AIアシスタントは“非常に素直なコラボレーター” として扱う
  • プロジェクト固有の情報・明確な目的・例示・段階的依頼 が有効
  • プロンプトエンジニアリングは反復練習が重要
  • AIの出力を人間のレビューと同等に検証・活用

AIコーディングアシスタントを最大限に活かすには、 質の高いプロンプト設計力 が不可欠。上記の原則と例を参考に、日々の開発フローに組み込むことが推奨される。

Hackerたちの意見

あんなことするくらいなら、自分でコード書いた方がマシだな。

あなたの上司(またはCEO)は、多分そう思わないだろうね。

コードを書くことで、さっき読んだことよりも時間を節約できるよね。

うん、よくわからない。欲しいものを得るためにプロンプトを書き終える頃には、何度も修正して、キャラクターが画面に出るのを待ってる間に、自分で欲しいものを書けたんじゃないかと思う。LLMは、基本的なリファクタリングやテンプレート作成のためのクイックドキュメント検索として使う方が役立つと思う。

今、プロンプトガイドがめっちゃ多いよね。個人的には、あんまり必要ないと思う。これらのツールを使って、使い方に慣れる時間を取れば、どんなプロンプトを使うべきかはすぐにわかるようになるよ。

これを聞くと、Googleが人気になったときの盛り上がりやFOMOを思い出すな。関連の本がたくさん出てて、買わないと近い未来には原始人になっちゃうみたいな雰囲気だった。でも実際には、誰でも一日で全部学べちゃって、それで終わり。あのツールを知らなかったら何かを逃すかどうかなんて議論する必要もなかったんだよね。

プロンプトガイドを読んだり、経験豊富なユーザーを見たりすることがすごく価値のある人もいると思う。ただ、多くの人は自分で上達しようと意識的に考えないんだよね。中にはそのトピックについて何かを読んだり見たりする人もいるけど。私は他の人がこれらのツールを使うのを見たり、仲間と話したりすることで、いくつかの役立つヒントを得たことを素直に認めるよ。これって、自分だけでツールを使ってるだけでは達成できない改善だと思う。

他の人がこれらのツールを使って生産的になっている様子を見るのは、少なくとも役に立つよね。自分がすでにやっていることを改善するための賢いアイデアを見つけることもあるし。この分野の現状をドキュメント化するのも大事だと思う。1年前に何かを試みて、今でもダメだと思ってしまうのは簡単だから。自分で試行錯誤して車輪を再発明する前に、まずはその分野をリサーチする方が好きだし。自分の時間を使って発見を共有してくれる人には感謝してる。若い頃のように、自由に探求する時間があるわけじゃないからね。

時々、すごく長くて複雑なプロンプトを作ると、モデルの認知パフォーマンスが落ちる気がする。コントロール感やちゃんとしたエンジニアリングを感じられるかもしれないけど、果たしてそれが得になるのかは疑問。自分は、すごくシンプルでミニマリスティックなプロンプトを作って、数回のイテレーションの後にちょっと調整するスタイルに落ち着いてる。

別のタスクでは、同僚がすごく冗長なプロンプトを書いてた。自分がそれを統合しなきゃいけなかったから、プロンプト用のCRUD操作を追加した。テストとして、すごく短いプロンプト、「これを『』として分析して」みたいなのを作ったんだけど、出力はほぼ同じだった。ただ、長いプロンプトの出力にはそのプロンプトの具体的な部分への(かなりの)言及が含まれてた。無意味ではなかったけど、そのモデル(ちなみにgemini 2.5)は、プロンプトから抽出したタスクに対する基本的な応答を持っていて、余計な部分を合体させているようだった。この特定のタスクに関しては、モデルが「違う」考え方をするのは(簡単には)できないみたい。

同じ感じだね。比較的具体的なニーズから始めて、最初から強制するんじゃなくて、ロードマップを頭に入れておく。自分が知らない技術が関わるときは、「コピペ」する前に、特定のことが何を意味するのか理解するために質問もするよ。もっと高度なプロンプトを使うと、生成されたコードがコンパイルに失敗することがあって、問題を遡って追う方が、クリーンに始めるよりも時間がかかることがある。

自分もまさにそんな感じで使い始めたよ。1. ちょうどいいコンテキストを与えて、前提と目標を伝える。2. 答えを見直して、最初のプロンプトを改善する。これが一番経済的な使い方だと思う。エージェントを使って痛い目にあったことが何度もあるから(ずっと回り続けて、1つのプロンプトに30ドルも使って、コードベースをめちゃくちゃにしたり、前に書いたコードに収束したりする)。AIにプロジェクトのコードをたくさん書かせると、進めたり進化させたり、自信を持って次に進むのが難しくなるってことも伝えたい(考えずに書いたコードは記憶に残りにくいから)。

Hacker Newsで議論の続きを見る