動くコードが返ってきました。貼り付けたら、動きました。
3日後、別の機能を足そうとして開いたら、自分が何を頼んだのか思い出せませんでした。変数の名前も、ファイルの分け方も、自分の書き方と違う。動いているのに、触れない。
頼み方が雑だったからです。「◯◯する機能を作って」とだけ書いて、あとは全部AIに決めさせていました。決めさせた部分は、当然こちらの好みとは違う形で返ってきます。
この記事は、その反省から固まった型です。プロンプトの書き方そのものは前に書いたので、こちらはコードを書かせる場合に絞っています。
エラーを直させる側は、こちらです。
検証環境：【使っているAIとバージョン、確認日を入れる】
まず覚える型
4つです。これだけで、返ってくるものがかなり変わります。
【言語とバージョン】PHP 8.2 / WordPress 6.8
【やりたいこと】投稿一覧に「読了時間」の列を足したい
【制約】既存のファイルは変えない。新しいファイル1つに収める
【出力】コードだけ。説明は後回しでいい
順番に補足します。
言語とバージョン
いちばん効きます。**書かないと、AIは自分が知っているいちばん一般的な書き方を選びます。**それが古い書き方だったり、新しすぎて動かない書き方だったりする。
バージョンまで書くのが要点です。「PHP」だけだと 5系の書き方が混ざることがあります。「PHP 8.2」と書けば、そこに合わせてくれます。
フレームワークやライブラリを使っているなら、それも。「React」ではなく「React 19」、「WordPress」ではなく「WordPress 6.8」。
やりたいこと
ここは、作りたいものではなく何が起きてほしいかを書きます。
「キャッシュ機能を作って」だと、AIは一般的なキャッシュ機能を作ります。「同じページへの2回目のアクセスで、データベースを引かずに返したい」と書くと、目的に沿ったものが返ってきます。
自分の場合、手段を指定してしまうことが多くて失敗しました。**手段はこちらが決めなくていい部分です。**目的を書いて、手段はAIに出させて、それから選ぶ。
制約
冒頭の失敗は、ここを書かなかったせいでした。
書くことは、だいたい決まっています。既存のファイルを変えていいか。新しいファイルを作っていいか。使っていいライブラリはあるか。何行くらいに収めたいか。
【制約】
- 既存のファイルは変更しない
- 外部ライブラリは追加しない
- 1ファイル・100行以内に収める
- 関数名は snake_case
命名規則を1行入れておくと、あとで読めるコードが返ってきます。書かないと、AIの好みで決まります。
出力の形
説明が長くて、コードを探すのに時間がかかることがあります。「コードだけ」と書けば、コードだけ返ってきます。
逆に、理解したいときは「1行ずつコメントを付けて」と書きます。目的によって変えてください。
ファイルを分けてほしいときは、そう書きます。「ファイルごとに、ファイル名を見出しにして出して」で伝わります。
そのまま使える例文
コピーして、中身を差し替えて使ってください。
新しく作らせる
【言語とバージョン】<言語とバージョンを書く>
【やりたいこと】<何が起きてほしいかを1文で>
【入力】<どんなデータが来るか。例を1つ貼る>
【出力】<どんな結果がほしいか。例を1つ貼る>
【制約】
- 既存のファイルは変更しない
- 外部ライブラリは追加しない
- <命名規則やファイル構成があれば書く>
【形式】コードだけ。説明は不要
入力と出力の例を1つずつ貼るのが効きます。言葉で説明するより、実物を1つ見せるほうが早い。
既存のコードを直させる
以下のコードを直してください。
【言語とバージョン】<言語とバージョンを書く>
【いまの動き】<実際にどうなっているか>
【こうしたい】<どうなってほしいか>
【変えてほしくないところ】<関数名、引数、外から見た振る舞いなど>
<コードを貼る>
「変えてほしくないところ」が要点です。書かないと、頼んでいない部分まできれいに書き直されて、差分が読めなくなります。
読ませて説明させる
以下のコードが何をしているか、説明してください。
【前提】<自分がどこまで分かっているか>
【知りたいこと】<どこが分からないか>
<コードを貼る>
前提を書くと、説明の高さが合います。「プログラミングは分かるがこの言語は初めて」「この関数の3行目だけ分からない」など。
レビューさせる
以下のコードをレビューしてください。
【言語とバージョン】<言語とバージョンを書く>
【気にしていること】セキュリティ / 読みやすさ / 速度（該当するものを書く）
【使う場所】<個人の趣味 / 業務 / 公開して配布する>
<コードを貼る>
使う場所を書くと、指摘の厳しさが変わります。配布すると書けば、入力の検証まで見てくれます。
返ってきたあとにやること
ここが、いちばん書きたかったところです。
動いたことと、正しいことは別
貼って動いたら、そこで終わりにしていました。動くことは、いちばん低い基準です。
とくにテストのコードを書かせたときが危ないです。テストが通ったから正しい、と思ってしまう。実際には、実装ではなくテストのほうが緩められていることがあります。この話は別に書きました。
説明させて、答え合わせをする
コードを受け取ったら、その場でもう1つ投げます。
このコードで、想定外の入力が来たときに何が起きますか。
壊れる可能性がある箇所を、順番に挙げてください。
これで出てくるものが、だいたい自分の見落としと一致します。
3日後の自分に向けて、理由を残す
冒頭の失敗の直接の対処です。返ってきたコードに、なぜそうしたのかを書き足させます。
このコードで、迷いそうな判断をした箇所に、
「なぜそうしたか」をコメントで足してください。
何をしているかの説明は要りません。
**何をしているかは、コードを読めば分かります。**分からないのは、なぜそうしたかのほうです。
まとめ
- 言語とバージョンを書く。書かないとAIの好みで決まる
- 作りたいものではなく、何が起きてほしいかを書く。手段は出させてから選ぶ
- 制約を書く。とくに「変えていいファイル」と「命名規則」
- 入出力は言葉で説明せず、例を1つ貼る
- 直させるときは「変えてほしくないところ」を書く
- 動いたことと正しいことは別。受け取ったら壊れる箇所を挙げさせる
- なぜそうしたかをコメントで残させる。何をしているかは要らない
ここまで書いて、自分でも思うのですが、この型は人に頼むときと同じことを書いているだけです。何を、どういう条件で、どんな形で。
だとすると、人に頼むときは自然に書けている条件を、なぜAIには書かずに済むと思っていたんでしょうか。そこがまだ、自分でもよく分かっていません。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。