Tips大辞典

公式推奨の型は、探索（planモードで読ませる）→計画→実装→コミットの4段階です。いきなり書かせると「間違った問題」を解きがち、というのが理由。アプローチに迷いがある時・変更が複数ファイルに及ぶ時に使い、diffを一文で説明できる小修正ならスキップして構いません。

いつ使う？アプローチに迷いがある時・変更が複数ファイルに及ぶ時。

テスト・ビルド・スクショ比較など「合否が返る確かめ方」を渡すと、Claudeは自分でミスに気づいて直します。開発者いわく品質2〜3倍の最重要テクニック。席を離れて任せたい時ほど必須です。「できた」と言わせず、テスト出力などの証拠を出させるのがコツです。

いつ使う？席を離れて任せたい時ほど必須。証拠を出させます。

同じ問題を2回直させても直らなければ、文脈は失敗した試行で汚れています。3回目を頼まず/clearし、学んだことを盛り込んだ新しいプロンプトで仕切り直します。「きれいなセッション＋良い初手」は「長いセッション＋修正の山」にほぼ常に勝ちます。

いつ使う？同じ問題が2回直らなかった時。3回目は頼みません。

大きな機能の前に「私にインタビューして、詰め終わったらSPEC.mdに書いて」と頼みます。考えていなかったエッジケースやトレードオフを掘り出してくれます。仕様が固まったら新しいセッションで実装させるのが公式推奨。「何を作るか自分でも曖昧」な時が使いどきです。

いつ使う？「何を作るか自分でも曖昧」な時。

AIは追い込まれると答えをハードコードして「成功！」と言いがちです。先に失敗するテストを書いてコミットし、「テストの削除・改変は禁止」と明記して契約にします。ロジックの実装や長時間の自律作業を任せる時が使いどきです。

いつ使う？ロジックの実装や長時間の自律作業を任せる時。

AIは自分が書いたコードに甘い、が鉄則です。実装が終わったら、別セッションやサブエージェントに差分だけを渡してレビューさせます。作った本人の思考に引きずられないので指摘の質が上がります。シップ前・マージ前が使いどきです。

いつ使う？シップ前・マージ前。作った本人以外に見せます。

PROGRESS.mdやHANDOFF.mdに「目的・終わったこと・効いたこと・次の一手」を書き出し、/clear後の新セッションに読ませます。コンテキストではなくファイルとGitに状態を持たせるのが長期戦の鉄則。数時間を超える作業や日をまたぐ作業で使います。

いつ使う？数時間を超える作業や日をまたぐ作業。

claude --continueで直近を、--resumeで一覧から再開できます。/renameで「oauth-移行」のような名前を付け、作業の流れごとにセッションをブランチのように使い分けます。タスクをまたぐたびに文脈を説明し直している、と気づいた時が使いどきです。

いつ使う？タスクをまたぐたびに文脈を説明し直していると気づいた時。

プロンプトを送るたびにチェックポイントが作られ、Esc2回か/rewindで会話やコードを以前の状態に復元できます。だから「慎重に計画」の代わりに「試してダメなら戻す」戦略が取れます。リスキーなリファクタや大胆な実験の前が使いどきです。Gitの代わりにはなりません。

いつ使う？リスキーなリファクタや大胆な実験の前。

/contextでコンテキスト使用量を可視化できます。実務では5〜6割あたりから精度低下を感じ始めるという報告が多く、満タンまで粘らないのがコツ。長丁場の途中で「最近返答が鈍い」と感じたらまず確認し、埋まっていたら/compactか/clearで整理します。

いつ使う？長丁場で「最近返答が鈍い」と感じたら、まず確認。

難しい設計やバグ調査の計画時、プロンプトにultrathinkと添えるか/effort（low〜max）で推論量を上げられます。深く考えるほど時間とコストは増えるので、通常タスクでの常用は不要。「計画の質が結果を左右する難所」だけに絞るのが判断基準です。

いつ使う？計画の質が結果を左右する難所だけ。常用はしません。