最初の5分で行うこと
プロジェクトのルートでclaudeを実行し、/initを入力します。生成されたCLAUDE.mdを読み、誤ったコマンドや古い規約がないか直してから、変更として扱います。
AIの変更は小さく、テスト結果と差分を確認してから残す
AIコーディングでは、最初から大きな機能を任せず、小さな変更をテスト付きで実行する方がレビューしやすくなります。コミット前に差分、テスト結果、機密情報の混入を確認する作業は必須です。
推奨する最初の作業単位
1. 状況を読むCLAUDE.md、README、既存テスト、Git差分を確認する。
2. 小さく変えるボタン追加、限定的な不具合修正、テスト追加などに絞る。
3. 検証して残すテストを実行し、差分をレビューしてからコミットする。
コミット前の確認
GitHub CLIでコミット・プッシュを依頼する前に、git diff、テスト結果、生成物、秘密情報を確認します。自動承認の操作は便利ですが、変更範囲が理解できる小さなタスクでだけ使うのが安全です。
/initが作るCLAUDE.mdは、プロジェクトを完全に理解した証明ではありません。ビルドコマンド・環境変数・デプロイ手順は、既存の公式ドキュメントと照合してください。
なぜ「小さく区切る」が結果的に速いのか
まとめて頼んだほうが早く終わりそうに見えますが、実際には逆になることが多いです。理由は、問題が起きた時に切り分ける手間が、変更量の増加より速く膨らむためです。
| まとめて頼む | 小さく区切る | |
|---|---|---|
| 1回あたりの待ち時間 | 長い | 短い |
| うまくいった時 | 速い | やや手間 |
| 問題が起きた時 | どの変更が原因か特定できない | 直前の変更が原因と分かる |
| 戻す時 | 正しい変更まで巻き戻る | 問題の分だけ戻せる |
| レビューのしやすさ | 差分が大きく読み切れない | 読める量に収まる |
一度でうまくいく前提なら、まとめて頼むほうが速いのは事実です。しかし一度でうまくいく確率は、変更範囲が広がるほど下がります。期待値で見ると、小さく区切るほうが安定します。
最初のコミットに含めないもの
初期設定の段階で、うっかり入れてしまうと後から取り除くのが面倒なものがあります。最初のコミットの前に確認してください。
- 認証情報・APIキー。
.envや設定ファイルに書いた鍵は、一度コミットすると履歴に残ります。後から削除しても履歴からは消えません。先に無視設定へ入れてください。 - 依存パッケージのフォルダ。
node_modulesのような自動生成物は、容量が大きく差分も読めなくなります。 - ログ・キャッシュ・一時ファイル。作業のたびに変わるため、毎回の差分に混ざって邪魔になります。
- 個人の作業メモ。共有する予定がないものは、リポジトリの外に置くほうが安全です。
1つ目が最も重要です。鍵を含んだままコミットしてしまったら、ファイルを消すだけでは対処になりません。その鍵は無効化して発行し直してください。
区切りの目安
「小さく」の具体的な線引きに迷ったら、次のどれかに当てはまったら区切る、と決めておくと運用できます。
- 1つの目的が達成された時。「表示の崩れを直す」が終わったら、次の目的に進む前に区切ります。
- 差分が自分で読み切れなくなった時。目で追えない量になったら、それ以上進めても確認できません。
- 動作確認ができる状態になった時。動く状態を残しておけば、そこまでは安全に戻れます。
- 作業を中断する時。翌日の自分は、今日の途中経過を覚えていません。