Claude Codeは、ターミナル上で「このリポジトリを直して」「テストが落ちた理由を見て修正案を出して」と頼めるコーディング用AIです。うまくいく人は“全部自動でやらせる”より先に、変更範囲と確認点を切って使っています。この記事では、最短で動かす手順と、失敗しにくい指示の出し方をまとめます。
- Claude Codeでできること（現実的に任せられる範囲）がわかる
- インストールからプロジェクトに入るまでの手順がわかる
- 修正依頼に使えるプロンプト（指示テンプレ）が手に入る
- 勝手に大改造されるのを防ぐ“ガードレール”がわかる
- チームで使うときの注意点（ログと機密）がわかる
目次
Claude Codeとは（ターミナルで使うコーディングAI）
Claude Codeは、CLI（コマンドライン）からコードベースを読み、修正案の作成、実装、テストの実行までを支援するツールです。チャット画面でコード断片を貼るのと違い、手元のリポジトリ構造や既存の規約を前提に会話できます。
ただし、放っておくと「ついでに」変更が広がりがちです。個人的には、最初は新機能追加よりもバグ修正と小さなリファクタから入るのが一番失敗しにくいと感じます。差分も追いやすいからです。
できること（任せやすい順）
- テストが落ちた原因の切り分けと、候補修正案の提示
- 小さめのバグ修正（再現手順があるもの）
- 既存コードのリファクタ（関数分割、命名、重複除去）
- READMEや開発手順の更新
逆に、認証まわりの設計変更や大規模移行は、指示と確認点を細かくしないと事故ります。ここは人間側の設計判断が必要です。
Claude Codeの使い方：最短セットアップ手順
環境によって手順は少し変わりますが、流れは同じです。公式の案内に従うのが確実なので、料金や要件も含めて必ず公式ページで確認してください。
手順1：プロジェクトを「安全に触れる状態」にする
Claude Codeに触らせる前に、ここだけ整えると失敗が減ります。
- Gitでコミットできる状態にする（未コミットの変更を減らす）
- テストコマンドを決める（例：
npm test/pytest/go test ./...） - フォーマッタがあるなら確定（例：Prettier、Black、gofmt）
「どのテストを回すべきか」から迷うと、AIの試行も人間の確認も遅れます。
手順2：Claude Codeをインストールしてログインする
インストール方法はOSや配布形態で変わるため、ここは公式ドキュメントに寄せます。ポイントは、プロジェクト単位で使うことと、権限やキーの扱いを雑にしないことです。
- 公式の手順でインストール
- 認証（ログイン、APIキー設定など）
- 対象リポジトリに移動して起動
手順3：最初の一言は「制約つき」で出す
いきなり「全部直して」ではなく、変更範囲と確認点を渡します。ここで“枠”を作ると、後がラクです。
このリポジトリで、まずは現状把握だけして。
- 変更は一切しない
- 重要そうなエントリポイント（起動点）と主要ディレクトリの役割を短く説明
- テストの実行方法と、実行に必要な前提があれば列挙
出力は箇条書きで。「変更しない」を明記するだけで、探索フェーズがきれいになります。
プロンプト例：よくある作業を“短い指示”で通すテンプレ
Claude Codeは会話できますが、現場では指示文を定型化した方が安定します。以下はそのままコピペして、角括弧だけ埋めてください。
例1：テストが落ちた原因を切り分けて最小修正にする
[テストコマンド] を実行して、失敗内容を整理して。
- 失敗しているテスト名と、期待値/実際値を短くまとめる
- 原因候補を2〜3個に絞る（根拠として該当ファイルと行を示す）
- 修正は「最小差分」で。不要なリファクタは禁止
- 修正後に再度 [テストコマンド] を実行
最後に、変更点をGit差分の要約で出して。ポイントは「不要なリファクタ禁止」です。AIは善意で整理したがるので、まず止めます。
例2：1ファイルだけをリファクタ（変更範囲を固定）
対象は [path/to/file] だけ。
目的は可読性の改善（命名、関数分割、重複除去）。
- 外部仕様（入出力、公開API、HTTPレスポンス形式）は変えない
- 振る舞いが変わる可能性がある箇所は、先に「懸念」として列挙して確認を取る
- 既存テストがあるなら必ず通す
変更した理由を、レビューコメント風に説明して。ファイルを固定すると、想定外の改修が減ります。レビューもしやすいです。
例3：READMEの「手順だけ」直す（文章の盛りすぎ防止）
READMEを更新したい。
- 変更対象は「開発環境のセットアップ」と「テスト実行」セクションのみ
- 事実ベースで（推測で書かない）
- コマンド例はコピペで動く形に
- 追記した前提条件（Nodeのバージョン等）があるなら明記
差分を出して、どこをどう直したか説明して。注意点：Claude Codeで事故りやすいポイントと防ぎ方
変更が広がる（ついでリファクタ問題）
症状は「関係ないファイルまで整形された」「命名が全体に波及した」です。防ぐには、指示に変更範囲の上限を書きます。
変更してよいのは最大で3ファイルまで。
対象外のファイルは触らない。触る必要が出たら、作業を止めて理由を説明して。“動いた風”の修正で、再現条件が消える
AIがログの一部だけ見て推測修正すると、たまたま通って根が残ることがあります。再現手順を固定し、実行ログを残します。
- 失敗を再現するコマンドを1つに決める
- 修正前後で同じコマンドを回す
- 出力（エラー全文）を会話に貼る
機密情報・社内コードの取り扱い
会社のリポジトリを扱う場合、規約や契約によってはAIツールにコードを送れないことがあります。ここは技術の問題というより運用の問題です。
- 入力してよい情報／ダメな情報をチームで決める
- 秘密鍵、トークン、顧客データが混ざるログは貼らない
- 利用条件やデータ取り扱いは、必ず公式の説明を確認する（料金も含めて変わることがあります）
Claude Codeが向いている人（逆に、やめた方がいい場面）
向いている人
日常的にGitを使い、差分レビューを前提に開発している人に向きます。全部を任せるというより、自分の手を動かす回数を減らす道具として効きます。たとえば「テスト失敗の原因候補を先に並べてもらう」だけで、着手が早くなります。
やめた方がいい場面
プロジェクトがまだ整っていない（テストがない、フォーマッタがない、規約が曖昧）状態で大きい変更を頼むと、成果物が評価できません。先に最低限の土台を整えるのが近道です。
まとめ：最初の勝ち筋は「小さい修正＋確認ルール」
Claude Codeの使い方で一番効くのは、プロンプトの技巧より変更範囲と確認手順です。探索は「変更しない」、修正は「最小差分」、そして必ずテストを回す。この3つを守るだけで、ターミナルの相棒としてかなり頼れるようになります。
参考リンク
Photo by James Harrison on Unsplash
