前章まででタスクの組み立て方を見てきた。本章では、その中で送る一つひとつのプロンプトをより鋭くするテクニックを扱う。基礎で扱った「状況・目的・成功基準を伝える」に加えて、実戦の場で効果が高い手をいくつか紹介する。

既存のパターンを示す

コードベースには既に「このプロジェクトはこう書く」という暗黙の流儀がある。Claude にそれを推測させるより、手本にすべきファイルを直接指す方が、結果が揃いやすい。

❌ カレンダーウィジェットを追加して

✅ ホームページの既存ウィジェットを見て、HotDogWidget.php のパターンに合わせて、月を選んで前後に年をページネーションできるカレンダーウィジェットを追加して

「ゼロから設計するな、既にあるものに合わせろ」と暗に指示していることになる。プロジェクトの一貫性を保つには、この一手が一番効く。

新しい機能を作る時、まずお手本になりそうな既存ファイルを一つ思い浮かべる癖をつけると、プロンプトの精度がぐっと上がる。

ソースを指し示す

「なぜこういう設計になっているのか」を聞きたい時、Claude が現在のコードだけ見ても答えが出ないことがある。git の履歴という別のソースを指し示すと、答えが鋭くなる。

❌ ExecutionFactory がこんなに奇妙な API を持っているのはなぜ?

✅ ExecutionFactory の git 履歴を調べて、その API がどうやって今の形になったかを要約して

過去のコミット、PR、コメントには「なぜそうなったか」の文脈が残っている。Claude はそれを読んで設計の経緯を辿れる。

git 以外にも、ソースを指す手はいろいろある。

  • 公式ドキュメントの URL ─ Claude が web を取りに行く
  • 別リポジトリのコード片を貼る ─ 「これに沿って実装して」と指示
  • ログファイルをパイプする ─ cat error.log | claude

「現在のコードベース内」に答えがあるとは限らない。ありかを示すのもプロンプトの仕事である。

制約と非目標を明示する

「やってほしいこと」だけ伝えると、Claude は親切のつもりで意図せぬ方向に手を広げる。「やらないでほしいこと」を併記すると、収束が早い。

✅ レート制限を実装して。新しいライブラリは追加しないこと。Express の標準機能だけで作って。

✅ このリファクタリングを進めて。utils.ts には触らないこと。あのファイルは別の PR でレビュー中。

「制約」と「非目標」は厳密には別物だが、効果は似ている。

  • 制約 ─ 「これに従ってほしい」 (言語・スタイル・既存パターン)
  • 非目標 ─ 「これはやらないでほしい」 (触ってほしくない箇所、追加してほしくない依存)

特に非目標は、Claude が「ついでに」と勝手に範囲を広げるのを防ぐのに効く。スコープが固定されているタスクほど、この一文を加える価値がある。

Claude にインタビューさせる

仕様は頭の中にあるが、それを過不足なく言葉に落とすのが面倒な時 ─ Claude に質問させる手がある。

[新規機能のラフな説明] を作りたい。
AskUserQuestion ツールを使って、私に詳しくインタビューしてほしい。
技術的な実装、UI/UX、エッジケース、トレードオフについて聞いて。
明白な質問は飛ばして、私が考えていなかった難しい部分を掘って。
全部カバーできたら、完成した仕様を SPEC.md に書いて。

Claude は技術選択、エッジケース、トレードオフなど、こちらが見落としていた論点を質問してくる。それに答えていくうちに、頭の中の漠然としたものが具体的な仕様に変わる。

仕様ができたら、/clear で別セッションを開いて @SPEC.md を読ませて実装に入る。仕様を作ったセッションと、実装するセッションを分けるのが、前章で扱ったパターンの応用例である。

このやり方の良い点は、自分の頭の整理をアウトソースできること。「何を作りたいか」が漠然としているうちに実装に入ると後で詰まる。先に Claude に質問させて土台を固めてから、実装フェーズに入る。

ここまでプロンプトを尖らせる手段を見てきた。次章では、そうして作った Claude のアウトプットをClaude 自身に検証させる仕組みの話に入る。

参考情報