COPY & PASTE PROMPTS

実践プロンプト集

コピーしてすぐ使える「頼み方」の実例集です。ハーネス（単独）・サブエージェント・エージェントチームなど場合ごとに整理しました。各ブロックの copy を押してそのまま貼り付け、〔…〕の部分を自分の内容に差し替えるだけ。頼み方の理屈は ✍️プロンプト術 に、考え方は 🏆組み立て方 にあります。

コピペOK場合別実務ベース
🧰
使い方：① 右上の copy でプロンプトをコピー → ② Claude Code に貼り付け → ③ 〔…〕（プレースホルダ）を自分のファイル名・症状・条件に置き換えて送信。各ブロックの見出し帯（グレーの帯）に「▶ いつ使う」を書いてあります。帯はコピーに含まれないので、プロンプトはきれいなまま貼れます。
🧭
場合別ジャンプ： A 基本（毎回の土台） ／ B ハーネス（単独で上手に回す） ／ C サブエージェント（調査・レビューを分担） ／ D エージェントチーム（複数で協調） ／ E 自動化・ヘッドレス ／ F 仕上げ・運用

A基本（毎回の土台）

どの場合でも効く「型」。まずはこの4つを手に馴染ませましょう。

▶ 計画してから実行（Explore→Plan→Code→Commit）
〔やりたいこと〕を実装したい。まずは計画モードで、関係するファイルを読んで
現状を理解し、変更が必要なファイルと手順の計画を出して。
私がOKしてから実装に入って。実装後はテストを実行して、緑になるまで直して。
▶ 具体的に頼む（範囲・お手本・制約つき）
〔@path/to/file〕に〔何〕を追加して。〔@path/to/手本ファイル〕が良いお手本なので、
そのパターンに倣って。新しいライブラリは増やさず、既存の作りに合わせて。
できたら〔確認方法（例：npm test）〕で動作を確かめて報告して。
▶ 検証つきで頼む（証拠を出させる）
実装したら「できました」で終わらせず、〔npm test〕の実行結果をそのまま貼って、
通っていることを証拠で示して。失敗していたら根本原因を直してから報告して。
▶ 詰まったときの仕切り直し（2回ダメなら）
いったん今のアプローチは忘れて。これまで分かったのは〔分かったこと〕、
うまくいかなかったのは〔失敗したこと〕。この前提を踏まえて、
別の方針を2つ挙げて、それぞれの長所短所を比べてから、おすすめを提案して。
✅
合言葉：場所（@）・症状・ゴール・確かめ方をセットで。同じ作業でもこれだけで結果が激変します。2回直しても直らなければ /clear して、学んだことを入れた新しいプロンプトで仕切り直すのが速いです。

Bハーネスの場合（単独で上手に回す）

1人の Claude を、計画・検証・記録の足場で上手に走らせる型。実装の詳細は 🔧ハーネス実装 に。

▶ 仕様を先に固める（インタビュー→SPEC.md→新セッション）
〔作りたいもの〕を作りたい。いきなり実装せず、まず私に1問ずつ質問して、
仕様を一緒に詰めて。十分に固まったら、その内容を SPEC.md に
「対象ファイル・やること・やらないこと・完成の確認手順」を含めて書き出して。
（※このあと /clear して、新しいセッションで SPEC.md を読ませて実装させます）
▶ テスト駆動（TDD：失敗テスト先→実装→緑まで）
これはTDDで進めたい。まず〔機能〕の仕様を満たす「失敗するテスト」を書いて、
実際に失敗することを見せて。テストはこの後変更しないこと。
次に、そのテストが通る最小限の実装を書いて、緑になるまで自分で直して。
テストを消したり骨抜きにして通すのは禁止。落ちたら実装側を直して。
▶ バグ修正（再現テストを先に）
〔症状：例 ログイン後にセッションが切れる〕という不具合がある。
〔@src/auth/〕あたりが怪しい。まず問題を再現する失敗テストを書いて、
原因を特定し、根本から直して。エラーを握りつぶさず原因に対処すること。
最後にテストが通ることを実行結果で示して。
▶ 安全なリファクタ（振る舞いを変えない）
〔@path〕をリファクタしたい。外から見た振る舞いは一切変えないこと。
まず現状のテストが通ることを確認し、足りなければ先に特性テストを足して。
そのうえで小さな単位で整理し、各ステップでテストを実行して緑を保って。
1つの論理変更ごとにコミットして、何を変えたかを説明して。
▶ 大きめの機能（計画→小さく実装→こまめにコミット）
〔機能〕を追加したい。一度に全部作らず、独立して動かせる小さな単位に分けて、
最初の1単位だけ実装して。各単位ごとにテストを書いて実行し、緑になったら
日本語の分かりやすいメッセージでコミット。1単位できたら次に進む前に私に確認させて。
▶ コンテキスト引き継ぎ（長丁場：HANDOFF.md）
そろそろ会話が長いので引き継ぎ資料を作って。HANDOFF.md に
「目的／今どこまで進んだか／効いたこと／効かなかったこと／次の一手」を簡潔に書いて。
（※このあと /clear して、新セッションで HANDOFF.md を読ませて続きを進めます）
▶ 行き詰まったとき（症状＋全文＋場所＋試したこと）
うまくいかない。状況を全部渡すので一緒に切り分けて。
・やりたいこと：〔目的〕
・症状：〔何が起きるか〕
・エラー全文：〔貼り付け〕
・関係ファイル：〔@path〕
・試したこと：〔試した手順〕
まず原因の仮説を3つ挙げて、確認方法と一緒に示して。

Cサブエージェントの場合（調査・レビューを分担）

重い調査やレビューを子分に逃がして、本流のコンテキストを汚さない型。結果（要点）だけ受け取れます。詳しくは 🔧ハーネス§5。

▶ 重い調査を子分に逃がす（本流を汚さない）
サブエージェントを使って〔調べたいこと〕を調査して。関係するファイルを広く読み、
私の会話を圧迫しないように、結論と根拠（ファイルと該当箇所）を
要点だけ箇条書きで返して。細かい読み込みは子分側で完結させて。
▶ コードベースの仕組みを理解する
サブエージェントで〔機能：例 認証〕の流れを追って。フロントの入口から
バックエンド、DBまで、どのファイルでどう処理されるかを順番に説明して。
登場するファイルのパスと、各ステップ1〜2行の要約で、全体像を地図にして。
▶ 敵対的レビュー（差分だけ・正しさだけ）
今の変更を、新しいサブエージェントに「差分だけ」を渡してレビューさせて。
作った経緯は伝えず、変更内容と次の基準だけで批判的に点検して：
バグ・抜けたエラー処理・境界ケース・既存パターンとの不一致・セキュリティ。
好みの問題ではなく、正しさや要件に関わる指摘だけを挙げて。
▶ 大規模な置き換え・移行の下調べ
〔置き換え：例 ライブラリAをBに移行〕を計画したい。サブエージェントで、
影響を受けるファイルを全部洗い出して一覧にして（パスと変更の種類）。
まだ書き換えはしないで。難所・注意点・推奨する作業順だけ先に出して。
▶ 安いモデルで分担してコスト削減
この調査は深い推論はいらないので、サブエージェントは安いモデル（Haiku/Sonnet）で
動かして。〔調べること〕を手分けして調べ、結果だけ私に集約して。
✅
コツ：サブエージェントは「読む仕事（調査・レビュー・理解）」に最適。レビューは「差分だけ・作った経緯は渡さない」と、自分のコードに甘くならず指摘が鋭くなります。

Dエージェントチームの場合（複数で協調）

メンバー同士が議論・調整しながら並列で進める型。実験的機能でコストも高め（約7倍）。しくみと有効化は 👥エージェントチーム入門 を先に。役割を分け、相互チェックまで指示するのがコツです。

▶ 観点別の並列レビュー＋相互チェック
〔@src/payment/〕をチームでレビューしたい。3人のメンバーを立てて役割を分けて：
- セキュリティ（認証・入力検証・インジェクション）
- パフォーマンス（無駄なクエリ・キャッシュ・計算量）
- テスト網羅（重要経路・境界ケースが試されているか）
各自が所見を出したら、お互いの結果を相互チェックし、
意見が割れたら議論して合意してから、まとめて報告して。
▶ 競合する仮説でデバッグ（思い込み防止）
〔不具合：例 メッセージ5件目で接続が切れる〕の原因を、チームで競わせて突き止めたい。
メンバーを立てて、それぞれ別の仮説を担当して検証して：
- 1人：〔仮説A〕
- 1人：〔仮説B〕
- 1人：〔仮説C〕
- 1人：他3つの仮説を反証しにいく役
各自テストで検証し、結果を共有して議論。どれが正しかったかを根拠つきで結論して。
▶ レイヤー分担で実装（先に契約を合意）
〔機能：例 OAuth2ログイン〕を、衝突しないように層で分けて実装したい。
メンバーを立てて担当を分け、編集するファイルを重ねないこと：
- バックエンド：トークン発行・付与フロー
- バックエンド：検証ミドルウェア
- フロントエンド：ログイン画面と遷移
実装の前に、トークン形式とAPIの取り決め（契約）をメンバー間で合意して。
各自は自分の担当を単体で動かして確認し、最後に統合する。
▶ チームの操舵（待たせる・再フォーカス）
あなた（リーダー）は自分で実装を始めず、メンバーの作業が終わるまで待って。
〔メンバー名/役割〕には、いま〔別の重点：例 イベントループのメモリリーク〕に
集中し直すよう伝えて。完了したタスクは板で完了に更新するよう促して。
⚠️
注意：「書く（実装）」チームは同じファイルを複数人が触ると上書き衝突します。必ず担当ファイル/レイヤーを分け、先に契約（インターフェース）を合意させて。読む（調査・レビュー・デバッグ）仕事のほうが断然安全に並列化できます。基本は単独＋検証で足り、チームは高価値な仕事に絞るのが鉄則です。

E自動化・ヘッドレスの場合

人が見ていなくても回す型。ターミナルやCIに claude -p を組み込みます。安全装置（予算上限・道具の限定）を忘れずに。

▶ AIを「誤字・指摘 linter」にする（差分を渡すだけ）
$ git diff main | claude -p "あなたは誤字・不自然な表現のlinterです。差分の中の問題だけを箇条書きで指摘して。問題なければ『指摘なし』とだけ返して"
▶ ログから集計してJSONで受け取る（安全装置つき）
$ claude -p --output-format json --max-budget-usd 0.50 \
  --allowedTools "Read,Bash(grep *)" \
  "〔ログの場所〕からエラーの種類別件数を数えて、JSONで返して"
▶ 「CIを直して」を一気通貫で（専用worktree推奨）
main のCIが落ちている。原因を調べて直し、変更をコミットしてpushし、
そのあとCIが緑になったかを確認するところまでやって。
直し方が複数あるなら、いちばん影響の小さい方法を選んで。
▶ GitHubのIssueから自動でPR（@claude）
@claude このIssueの内容を実装して。ブランチを作り、テストを追加・実行し、
通ったらPRを開いて。変更点の要約と、確認方法をPR本文に書いて。
⚠️
自動化の安全装置：必ず --max-budget-usd（費用上限）と --allowedTools（使える道具の限定）を付ける。人が見ていない場で全権限を渡さない。--dangerously-skip-permissions は使い捨てのコンテナ/VM内だけに。

F仕上げ・運用

コミット・PR・公開前点検・ドキュメント化など、仕上げの定番。

▶ 意味のある単位でコミット
今の変更を確認して、もし複数の論理変更が混ざっていたら、意味のある単位に分けて
それぞれコミットして。各コミットは「何を・なぜ」が分かる日本語メッセージにして。
コミット前に消し忘れのログや直書きの値が残っていないか点検して。
▶ プルリクエスト（PR）を作る
この変更のPRを作って。本文には「目的・主な変更点・テスト結果・確認方法・
レビューで見てほしい点」を簡潔にまとめて。関連Issueがあれば紐付けて。
▶ 公開前のセキュリティ点検
公開前に脆弱性を点検したい。/security-review を実行して。
特に、秘密の値の直書き・入力検証・認証/権限まわり・依存の既知の脆弱性を重点的に。
見つかった問題は深刻度つきで一覧にし、修正案も添えて。
▶ 使い方ドキュメントを生成
〔@path または 機能〕の使い方を README に追記して。前提・セットアップ手順・
最小の使用例・よくあるエラーと対処を、初めての人にも分かる言葉で。
実際にコマンドを動かして、例が本当に動くことを確認してから書いて。
🎉
この6カテゴリを手元に置けば、たいていの場面で「うまい頼み方」のスタートが切れます。慣れたら自分用にアレンジして、あなただけの最強テンプレを育てましょう。関連：✍️プロンプト術・🔧ハーネス実装・👥エージェントチーム・🏆組み立て方。