先に断っておくと、この手の「頼み方のコツ」は、すでにたくさん書かれています。期待結果を添える、一度に頼まない、段階を踏む。どれも新しい話ではありません。
それでも書くのは、10個のうち5個が、自分が実際に事故ってから変えたものだからです。どの失敗で何を変えたかは、自分の記録にしかありません。
残り5個は、読んで納得して取り入れたものです。どちらなのかを、それぞれに書きます。
なお「これで何倍速くなる」といった数字は出せません。往復が減った感覚はありますが、測っていないので書きません。
1. 「直して」だけで投げない
（失敗からではなく、取り入れたもの）
「直して」だけだと、何を直すかを推測で埋められます。期待する結果と制約を一緒に渡すと、一発で返ってきます。
このエラーを直して。
期待する動作: 〇〇したときに△△になる
触っていい範囲: このファイルだけ
変えたくない: 既存のpublic関数のシグネチャ
2. 全部いっぺんに頼まない
（取り入れたもの）
「ログイン機能を全部作って」は失敗のもとです。1依頼1タスクに割ると、各ステップを確認しながら進められます。大きい仕事ほど、先に手順だけ出してもらいます。
まず実装はせず、手順だけ箇条書きで出して。
そのあと、1ステップずつ進めよう。
3. CLAUDE.md に書きすぎない
（失敗から）
良かれと思って大量に書いた結果、**いちばん守ってほしかったルールが埋もれて、プラグインが審査でリジェクトされました。**書いてあったのに効いていなかった、という形です。
そこから、常駐させるのは「プロジェクトの間ずっと変わらないもの」だけに絞りました。特定の作業でだけ必要な指示は、そのときの依頼文で渡します。
迷ったら、書いた行を半分に減らしてみてください。増やすほど効く、ではありませんでした。
4. 出力を読まずにコミットしない
（失敗から。2回）
1回目は、配布用の zip に開発専用のツールが混ざりかけました。unzip -l を眺めていて、たまたま目に入って止まりました。
2回目は、LLM の返答をそのまま innerHTML に入れていました。入力は疑っていたのに、出力を疑っていませんでした。
AI の出力は、信頼できる味方ではなく確認すべき外部入力です。diff は自分の目で読みます。動いたから正しい、ではありませんでした。
5. コンテキストを盛りすぎない
（失敗から）
ファイルを全部貼っていました。応答が雑になったので、MCP のせいだと思って疑っていたのですが、/context で測ったら、単に窓が埋まっていただけでした。
/context
**測ってから減らすと、応答が戻ります。**疑う前に測る、というだけの話でした。
6. 毎回ゼロから説明しない
（取り入れたもの）
同じ前提を毎回打ち込んでいるなら、CLAUDE.md か skill に逃がせます。ただし3番のとおり、CLAUDE.md に入れるのは常に必要なものだけです。
作業ごとの手順は、skill にして呼び出すほうが軽く済みました。
7. 危険なコマンドを無防備に許可しない
（失敗から）
一度ヒヤッとしてから、settings.json に deny を書きました。**順番が逆でした。**先に書いておけば済む話です。
{
"permissions": {
"deny": ["Bash(rm -rf*)", "Bash(git push --force*)"]
}
}
取り返しのつく操作と、つかない操作を分けて、後者だけ止めます。全部を確認制にすると、確認が形骸化しました。
8. 「もっと良くして」と言わない
（取り入れたもの）
「良く」は人によって違うので、伝わりません。基準を渡すと、狙ったほうに動きます。
読みやすさ優先で。具体的には:
- 関数は20行以内
- ネストは2段まで
- 変数名は略さない
数字で書けるものは数字で書く、というのは CLAUDE.md でも同じでした。
9. エラーを丸ごと貼って「直して」で終わらない
（失敗から）
エラー文だけ貼って、返ってきた修正をそのまま入れたことがあります。そのときはエラーメッセージの文字列で分岐する実装になって、後日、相手側の文言が変わる前提で作り直しました。
状況を渡していれば、最初から違う設計になっていたはずです。
エラー: （貼り付け）
再現手順: 1) 〇〇 2) △△
期待: □□になるはず
試したこと: ××は確認済み
10. 答えだけを急かさない
（取り入れたもの）
いきなり完成形を求めると、ズレた実装が返ってきます。まず方針、次に実装、と段階を踏むほうが、結局は速く終わりました。
いきなり書かず、まず設計方針を3案出して。
選んだら実装に入ろう。
どれから試すか
全部いっぺんに変える必要はありません。
**失敗から学んだ5個（3・4・5・7・9）は、どれも事故ってから直したものでした。**やらなくても当面は動きます。動いているうちに入れておくと、自分のように痛い目を見ずに済みます。
**取り入れた5個（1・2・6・8・10）は、明日から効きます。**いちばん軽いのは1番で、期待結果と触っていい範囲を1行ずつ足すだけです。
書きながら気づいたのですが、失敗から学んだ5個は全部、**「確かめる工程が抜けていた」**という同じ形でした。diff を読まない、測らずに疑う、事前に止めない、状況を渡さない。頼み方の問題というより、確かめ方の問題だったのかもしれません。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。