ハクソク

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

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

355日前原文(addyo.substack.com)

概要

  • 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にプロジェクトのコードをたくさん書かせると、進めたり進化させたり、自信を持って次に進むのが難しくなるってことも伝えたい（考えずに書いたコードは記憶に残りにくいから）。

└

今日は、CLAUDE.mdで大きな詳細なプロンプトを使ってコードレビューをしてたんだけど、そのファイルがまだないブランチで実行したら、逆に良い結果が出たんだよね。

└

いつからこれが法律用語でのプログラミングになるんだろう？

└

探さなきゃいけないけど、専門家の語彙を使うのと素人の語彙を使うのでは、結果が良くなるって証拠があるよ。普通に話す場所では間違ってることが多いし、専門用語を使う場所では正しいことが多いからね。トレーニングもその空間で関連付けられるし。

プロンプトを書くのに「エンジニアリング」って言葉を使うのは、ちょっと真剣味がない感じがする。

└

本当にそうだね。プロンプトを編集するのは、エンジニアリングとは全然似てないし、正確さや精度もない。ベンチマークがあって、それに対して改善しようとしてるとき、プロンプトの変更がベンチマークを上げるのか、下げるのか？ なんで？ 予測できる？ いや、全然科学じゃないよ。ただ、壁に色々なものや例を投げつけて、うまくいくことを願ってるだけ。

└

これって、ソフトウェアエンジニアリング全般についていつも出てくる議論と基本的に同じじゃない？

└

数年前にプロンプト「エンジニアリング」が流行ってた頃に、面白い例えを見かけたことがある。 > 誰かをプロンプトエンジニアと呼ぶのは、サンドイッチアーティストって書いてあるシャツを着たサブウェイの人をアーティストと呼ぶようなものだ。冗談はさておき、肩書きにこだわる必要はないと思うよ。エンジニアという言葉は、意味が薄れてしまってるから。 https://jobs.mysubwaycareer.eu/careers/sandwich-artist.htm

└

あなたの想像力が、面白い猫の写真を求めるチャットインターフェースで止まってしまったからだよ。APIや自動化されたワークフローで使うプロンプトもあるし、もっと色々あるんだ。

└

ITって、言葉とその意味が死ぬ場所だよね。言葉って、本当に意味が必要だったのかな？ :p

なんか、過剰な（プロンプト）エンジニアリングって感じ。私は生のコードやエラーを貼り付けて、シンプルな質問をするだけでうまくやってるよ。モデルは自分で解決できるくらい賢いから。

ずいぶん前に、修士課程でプログラミングの科学の授業を受けたんだ。その検証の方法が、データエンジニアリングの仕事をする時にプロンプトを作るのに役立ってる。基本的には、入力（…）と前提条件（…）を与えて、ポスト条件（…）を満たすスパークコードを書いてくれって感じ。入力、前提条件、ポスト条件を正式に指定できれば、だいたい良いコードが得られるよ。1. プログラミングの科学、デイビッド・グリーズ 2. 同時および逐次システムの検証

「プロンプトエンジニアリング」…痛いな。私は「常識」って言いたいけど、ソフトウェアエンジニアリングの問題は、SWEのインフレが起きてることだと思う。報酬レベルのために応募する人が多すぎて、実際に得意で好きな人が少なくなってる。そのせいで、こういうクランチが必要な悪いソフトウェアエンジニアがたくさん出てきちゃった。

└

「常識」なんて存在しないよ。それは、実際に何を意味しているのか説明できない時に使う言葉だね。

└

市場は、必要なところに人を移動させるために給与を価格シグナルとして使ってるんだよね。世界が必要とするソフトウェアを作るためのソフトウェアエンジニアが足りてないんだ。

└

その「プロンプトエンジニアリング」のことをビジネスパーソンに教えるといいと思う。常識が欠けてるみたいだから。明確な要件を書くこととか。

僕の経験では、真のプロンプトエンジニアリング技術は実質的に3つだけだと思う。 - コンテキスト学習（例を提供すること、いわゆるワンショットやフューショット対ゼロショット） - チェーンオブソート（段階的に考えるように指示すること） - 構造化出力（指定されたフォーマットで出力を生成するように指示すること） この記事で言うロールプロンプティングを追加してもいいかもね。それとRAGは、基本的に提供したコンテキストを要約させるだけのものだよ。でも、他のことは結局、やりたいことを明確な言葉で伝えるだけに尽きると思う。

└

同じプロンプトの中で構造化出力を作りながら、推論させるのは難しかった？

└

ロールプロンプティングも、個人的には全然役に立たないと思う。GPT-3の時は有効だったかもしれないけど、ほとんどのLLMは自分が「専門プログラマー」だってことをもう知ってるよ。多くの人が「プロンプトエンジニアリング」で自分を騙してるだけだと思う。要件を明確にしよう。必要なら例を追加して、出力をチェックして（推論モデルを使っているなら推論のトレースも）、もし求めているものと違ったら調整して繰り返そう。数回試してもまだうまくいかないなら、AIをあきらめて、自分の頭の中の推論モデルを使った方がいいよ。

└

ポイント3についてだけど、同僚と私は科学のユースケースのためにこれを研究したよ。https://doi.org/10.1038/s41467-024-45563-x

└

明確に言うと、私たちはプロンプトエンジニアリングよりもファインチューニングを多く使ったんだ。少ないショットのプロンプトエンジニアリングは私たちのユースケースには合わなかったからね。

「プロンプトエンジニアリング」なんて存在しないよ。いつから適切で意味のある文章を書く能力がエンジニアリングになったんだ？これは「ソフトウェアエンジニアリング」よりもひどい。残念なことに、こういう仕事の募集が出るだろうし、文章を書く特別な能力を持ってる人たちが自分をプロンプトエンジニアって呼ぶんだろうね。

└

自分が経験したことがないからって、不可能だと思うのはやめた方がいいよ。プロンプトエンジニアリングは、複雑な問題を解決するためにLLMから高い効果を引き出すためには必要だけど、十分ではないんだ。これがないと、解決策にたどり着く可能性は低い。あれば、解決策の90%には到達できる可能性が高まるけど、最後の調整が必要になることはまだ保証されてない。もしかしたら「プロンプトエンジニアリング」って言葉は良くないかもね。「プロンプトクラフティング」って呼んだ方がいいかも。というのも、普遍的に適用できる持続可能で再現可能な原則よりも、技術やセンス、判断力の要素が強いから。

自分の経験では、もし問題がLLMで解決できないなら、どんなにプロンプト「エンジニアリング」をしても本当に助けにはならないよ。解決する唯一の方法は、部分的に解決すること（サブタスクや例に分けること）で、それを走らせることだと思う。でも、間違ってたら嬉しいな。もし誰か違う経験があったら教えてほしい。

└

LLMを使うスキルの一部は、問題を効果的に分解する感覚をつかむことだと思うし、いつ分解するべきか、いつしないべきかの感覚も必要だよね。記事でもこのことに触れてるし。コードを再構築したり、整理したり、コメントをつけたりしてLLMとのインタラクションを改善する方法も見えてくると思う。そして、LLMがこれをうまくやるようになって、プログラマーが苦戦している問題を分解する方法を提案してくれるかもしれないね。

└

プロンプトエンジニアリングの目的は、より良い解決策を早く、希望する形式で得ることだと思う。でも理想を言えば、モデルがただ「知ってる」状態になって、質問を工夫しなくても済むようになるといいよね。