先に断っておくと、この手の「頼み方のコツ」は、すでにたくさん書かれています。期待結果を添える、一度に頼まない、段階を踏む。どれも新しい話ではありません。

それでも書くのは、10個のうち5個が、自分が実際に事故ってから変えたものだからです。どの失敗で何を変えたかは、自分の記録にしかありません。

残り5個は、読んで納得して取り入れたものです。どちらなのかを、それぞれに書きます。

なお「これで何倍速くなる」といった数字は出せません。往復が減った感覚はありますが、測っていないので書きません。

1. 「直して」だけで投げない

（失敗からではなく、取り入れたもの）

「直して」だけだと、何を直すかを推測で埋められます。期待する結果と制約を一緒に渡すと、一発で返ってきます。

このエラーを直して。
期待する動作: 〇〇したときに△△になる
触っていい範囲: このファイルだけ
変えたくない: 既存のpublic関数のシグネチャ

2. 全部いっぺんに頼まない

（取り入れたもの）

「ログイン機能を全部作って」は失敗のもとです。1依頼1タスクに割ると、各ステップを確認しながら進められます。大きい仕事ほど、先に手順だけ出してもらいます。

まず実装はせず、手順だけ箇条書きで出して。
そのあと、1ステップずつ進めよう。

（失敗から）

良かれと思って大量に書いた結果、**いちばん守ってほしかったルールが埋もれて、プラグインが審査でリジェクトされました。**書いてあったのに効いていなかった、という形です。

そこから、常駐させるのは「プロジェクトの間ずっと変わらないもの」だけに絞りました。特定の作業でだけ必要な指示は、そのときの依頼文で渡します。

迷ったら、書いた行を半分に減らしてみてください。増やすほど効く、ではありませんでした。

（失敗から。2回）

1回目は、配布用の zip に開発専用のツールが混ざりかけました。unzip -l を眺めていて、たまたま目に入って止まりました。

2回目は、LLM の返答をそのまま innerHTML に入れていました。入力は疑っていたのに、出力を疑っていませんでした。

AI の出力は、信頼できる味方ではなく確認すべき外部入力です。diff は自分の目で読みます。動いたから正しい、ではありませんでした。

（失敗から）

ファイルを全部貼っていました。応答が雑になったので、MCP のせいだと思って疑っていたのですが、/context で測ったら、単に窓が埋まっていただけでした。

/context

**測ってから減らすと、応答が戻ります。**疑う前に測る、というだけの話でした。

（取り入れたもの）

同じ前提を毎回打ち込んでいるなら、CLAUDE.md か skill に逃がせます。ただし3番のとおり、CLAUDE.md に入れるのは常に必要なものだけです。

作業ごとの手順は、skill にして呼び出すほうが軽く済みました。

（失敗から）

一度ヒヤッとしてから、settings.json に deny を書きました。**順番が逆でした。**先に書いておけば済む話です。

{
  "permissions": {
    "deny": ["Bash(rm -rf*)", "Bash(git push --force*)"]
  }
}

取り返しのつく操作と、つかない操作を分けて、後者だけ止めます。全部を確認制にすると、確認が形骸化しました。

（取り入れたもの）

「良く」は人によって違うので、伝わりません。基準を渡すと、狙ったほうに動きます。

読みやすさ優先で。具体的には:
- 関数は20行以内
- ネストは2段まで
- 変数名は略さない

数字で書けるものは数字で書く、というのは CLAUDE.md でも同じでした。

（失敗から）

エラー文だけ貼って、返ってきた修正をそのまま入れたことがあります。そのときはエラーメッセージの文字列で分岐する実装になって、後日、相手側の文言が変わる前提で作り直しました。

状況を渡していれば、最初から違う設計になっていたはずです。

エラー: （貼り付け）
再現手順: 1) 〇〇 2) △△
期待: □□になるはず
試したこと: ××は確認済み

（取り入れたもの）

いきなり完成形を求めると、ズレた実装が返ってきます。まず方針、次に実装、と段階を踏むほうが、結局は速く終わりました。

いきなり書かず、まず設計方針を3案出して。
選んだら実装に入ろう。

全部いっぺんに変える必要はありません。

**失敗から学んだ5個（3・4・5・7・9）は、どれも事故ってから直したものでした。**やらなくても当面は動きます。動いているうちに入れておくと、自分のように痛い目を見ずに済みます。

**取り入れた5個（1・2・6・8・10）は、明日から効きます。**いちばん軽いのは1番で、期待結果と触っていい範囲を1行ずつ足すだけです。

書きながら気づいたのですが、失敗から学んだ5個は全部、**「確かめる工程が抜けていた」**という同じ形でした。diff を読まない、測らずに疑う、事前に止めない、状況を渡さない。頼み方の問題というより、確かめ方の問題だったのかもしれません。

ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。