高優先度のプラクティス
検証手段を提供する
Section titled “検証手段を提供する”Claude の性能を最も向上させる方法は、作業を検証する手段を提供することです。
なぜ検証が重要か
Section titled “なぜ検証が重要か”Claude は自分の出力を確認できると、以下のメリットがあります：
- エラーを自己修正できる
- 期待通りの結果か確認できる
- 反復的に改善できる
検証手段の種類
Section titled “検証手段の種類”| 検証方法 | 用途 | 例 |
|---|---|---|
| テスト | コードの正確性 | npm test, pytest |
| スクリーンショット | UI変更の確認 | Chrome拡張機能 |
| 期待出力 | 特定の結果確認 | ログ、エラーメッセージ |
| 型チェック | 型安全性 | tsc, mypy |
| リンター | コード品質 | eslint, ruff |
探索→計画→実装→コミット
Section titled “探索→計画→実装→コミット”大きな変更には、4フェーズのワークフローが効果的です。
1. 探索フェーズ
Section titled “1. 探索フェーズ”「まずコードベースを探索して、認証システムがどう実装されているか理解して」このフェーズでは：
- コードを読む
- パターンを理解する
- 依存関係を把握する
変更は加えないことが重要です。
2. 計画フェーズ
Section titled “2. 計画フェーズ”「/plan を使って、OAuth認証を追加する計画を立てて」計画モード（Plan Mode）では：
- 実装方針を策定
- 影響範囲を特定
- リスクを評価
Claude が計画を提示し、あなたがレビュー・承認します。
3. 実装フェーズ
Section titled “3. 実装フェーズ”計画が承認されたら、実際にコードを書きます：
「計画に沿って実装を開始して」4. コミットフェーズ
Section titled “4. コミットフェーズ”「変更をコミットして」Claude は適切なコミットメッセージを生成し、変更をコミットします。
計画をスキップしてよい場合
Section titled “計画をスキップしてよい場合”すべてのタスクに計画が必要なわけではありません。
スキップしてよい場合
Section titled “スキップしてよい場合”- ✅ スコープが明確で小さな修正
- ✅ 単一ファイルの変更
- ✅ 既知のパターンの適用
計画が必要な場合
Section titled “計画が必要な場合”- ❌ 複数ファイルにまたがる変更
- ❌ アプローチが不確実
- ❌ コードベースに不慣れ
- ❌ アーキテクチャの変更
- 検証手段を提供することで Claude の性能が大幅に向上
- 大きな変更は探索→計画→実装→コミットの流れで
- 小さな修正は計画をスキップしても OK
- 判断に迷ったら計画を立てる
Q1. Claudeの性能を最も向上させる方法は？
Q2. 探索→計画→実装のワークフローで正しいのは？
Q3. 計画をスキップしてよいのはどんな場合？