動くコードが返ってきました。貼り付けたら、動きました。

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まわりのことを書いています。