コーディング用の AI プロンプト：動くコードを得るコツ

コーディング用のプロンプトは仕様書です。モデルはあなたのプロジェクトを見たことがなく、どのバージョンの言語を使っているかも知らず、入力が空のときにどうすべきかを尋ねることもできません。プロンプトが省いたことは何でも、学習データで最もよくある選択で埋められ、その選択はたいていあなたのものとは違います。下のプロンプトは、モデルが推測することを減らします。

コードの前に仕様を書く

下のブロックは、小さな Python の関数を頼んでいます。プロンプトの各パートは、頼まなければモデルが代わりに決めてしまう質問に答えています。パートを1つずつオフにして、それがない場合の返答を想像してください。制約がなければサードパーティのライブラリが使われるかもしれません。コンテキストがなければ、何が正しい入力かをモデルが推測しなければなりません。形式がなければ、テストが付いてこないかもしれません。

仕様から関数を書く

EditCopy

Fill inバージョン

PartsRoleTaskContextConstraintsFormat

Role

あなたは、小さくテストされた関数を書く、慎重な Python 開発者です。

Task

時間を表す文字列を秒数に変換する関数 `parse_duration(text)` を書いてください。

Context

正しい入力は "1h30m"、"45m"、"2h"、"90s" のような形です。時間、分、秒はそれぞれ省略可能で、常にこの順番で並びます。"1h30m" は 5400 を返します。空文字列を含め、それ以外はすべて不正な入力です。

Constraints

Python 3.11、標準ライブラリのみ。不正な入力には、入力値をメッセージに含めた ValueError を出してください。"1.5h" のような小数は受け付けないでください。

Format

まず関数を示し、次に上の例すべてと不正な入力3つをカバーする pytest のテストを示してください。説明は1文だけにしてください。

Try it

Example replyReplies vary between models and runs.

この関数は3つの省略可能な部分を順番にマッチさせ、3つとも空のマッチは拒否します。

import re

_PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")

def parse_duration(text: str) -> int:
    match = _PATTERN.fullmatch(text)
    if not match or not any(match.groups()):
        raise ValueError(f"invalid duration: {text!r}")
    hours, minutes, seconds = (int(g) if g else 0 for g in match.groups())
    return hours * 3600 + minutes * 60 + seconds

import pytest
from duration import parse_duration

@pytest.mark.parametrize("text, expected", [
    ("1h30m", 5400), ("45m", 2700), ("2h", 7200), ("90s", 90),
])
def test_valid(text, expected):
    assert parse_duration(text) == expected

@pytest.mark.parametrize("text", ["", "1m1h", "1.5h"])
def test_invalid(text):
    with pytest.raises(ValueError):
        parse_duration(text)

このプロンプトの中で、4つの細部が仕事の大半をしています。

• 答えつきの例。 「"1h30m" は 5400 を返す」は、モデルが自分のコードを照らし合わせられるテストであり、単位についての迷いもなくします。
• 言語のバージョンと使ってよいライブラリ。 これがないと、インストールしていないライブラリや、インタプリタより新しい構文が返ってくるかもしれません。
• 何が不正か、そのときどうすべきか。 エラー処理は、誰も頼まなければモデルが省きやすい部分です。
• 答えの中のテスト。 「正しそう」を実行できるものに変えます。テストが失敗したら、その失敗を貼り付けて返せばよく、「動かない」よりはるかに良いフォローアップになります。

any(match.groups()) のチェックにも注目してください。すべての部分が省略可能なので、パターンだけでは空文字列にもマッチしてしまいます。プロンプトの空文字列についての一文が、このケースをコードとテストに登場させています。

バージョン、技術スタック、すでにあるものを伝える

モデルは、学習データで最もよく使われていた書き方に寄りがちです。JavaScript なら、ES モジュールを使うプロジェクトで CommonJS の require が出てくることがあります。Python なら、その後変わったライブラリの API（Pydantic 1 と 2 はよくある例です）が出てくることがあります。変化の速いフレームワークなら、メジャーバージョン2つ前のパターンが出てくることがあります。たいていは1行で直ります。「Node 22、ES モジュール、TypeScript なし」や「React 19、関数コンポーネント、素の CSS Modules」です。

既存のプロジェクトに追加するときは、新しいコードが触れる部分をモデルに見せる必要があります。呼び出すべき関数のシグネチャ、受け取るデータの形、そして規約がわかる既存のファイルを1つ貼り付けてください。「下のファイルの db.query(sql, params) ヘルパーを使って」と書けば、プロジェクトに合うコードが得られます。それがないと、データベースの接続をゼロから書いたコードが返ってくるかもしれません。変更と関係のないファイルは省いてください。無関係な行の1つ1つが、モデルが再利用しようとするかもしれないものだからです。

一度に1つの小さなステップを頼む

AI に説明してアプリを作る「バイブコーディング」で最もよくある失敗は、アプリ全体を一度に頼むことです。モデルはフレームワーク、データベース、フォルダ構成、十数個の機能を1回の返答で選ばなければならず、1回の返答にそのすべての動くコードが収まることはめったにないので、骨組みだけが返ってくることがよくあります。2つのタブを比べてください。

アプリ全体を一度に小さな1ステップ

EditCopy

ユーザーアカウント、データベース、リマインダー、ダークモードのある ToDo アプリを作ってください。

Try it

Example replyReplies vary between models and runs.

React、Node.js と Express、MongoDB を使ったフルスタックの ToDo アプリです。

プロジェクト構成

todo-app/
  client/   (React front end)
  server/   (Express API, auth, reminders)

server/index.js

const express = require("express");
const mongoose = require("mongoose");
const app = express();
app.use(express.json());
// ... auth routes, todo routes and the reminder scheduler go here

認証には jsonwebtoken で JWT を、リマインダーには node-cron のようなスケジューラーを追加できます。どの部分を埋めてほしいか教えてください。

1つ目の返答は間違ってはいませんが、骨組みです。あなたの代わりに3つの技術を選び、本当の作業はコメントのまま残しています。2つ目の返答は読める短さで、ファイルを開いた瞬間に動き、ステップ2（「リロードしても消えないように、リストを localStorage に保存して」）のための動く土台になります。各ステップが小さいので、何かが壊れたとき、どの変更で壊れたのかがわかります。

これは手作業で行うプロンプトチェーンです。1つの依頼の出力が、次の依頼の出発点になります。新しいステップのたびにファイルの現在の版を貼り付けてください。そうすれば、モデルは自分が書いたと覚えているコードではなく、あなたが実際に持っているコードを編集します。

大きな変更の前には計画を頼む

関数1つより大きなものは、先に計画を、コードはそのあとに頼んでください。「変更するファイルと、それぞれの変更内容を挙げてください。コードはまだ書かないでください」。計画は読むのも直すのも早く済みます。望まない依存関係を追加しようとしていたり、関係するとわかっているファイルが抜けていたりしても、300行のコードの中で見つける代わりに、1文で直せます。

返ってきたものを確認する

生成されたコードには予測できる失敗のパターンがいくつかあり、それぞれを捕まえるプロンプトの習慣があります。

• でっち上げの API。 モデルは、名前がもっともらしいという理由で、存在しない関数を呼んだり存在しないパッケージを import したりすることがあります。見慣れない import はインストールする前に調べてください。なぜこれが起きるのかは AI のハルシネーションで説明しています。
• 黙って見過ごされるエッジケース。 正常系では動くのに、空のリストでクラッシュするコード。プロンプトにエッジケースを並べ、テストを頼むのが、いちばん安上がりな対策です。
• 気づかないうちの変更。 長いファイルの修正を頼むと、モデルが頼んでいない名前の変更やコードの整理までしてしまうことがあります。「必要な部分だけを変更し、行った変更をすべて挙げて」と書き足してください。

コードは動くのにおかしな動きをするなら、デバッグ用のプロンプトに切り替えてください。何を貼り付けるべきかはデバッグのためのプロンプトで扱っています。重要なものをマージする前に、コードレビュー用のプロンプトでもう一度見直せば、コードを書かせたプロンプトが尋ね忘れた問題を捕まえられます。