Claude Code Getting Started
Claude Codeの使い方：導入から最初の安全な実行まで
最初から本番コードを大きく変更させる必要はありません。公式手順で導入し、対象フォルダを限定し、説明・調査・小さな修正・テストの順で始めると、結果を確認しながら使えます。
結論：小さく読み、差分を確認してから任せる
Claude Codeを安全に使い始める最短ルートは、検証用ブランチで対象ディレクトリを限定し、最初に構成説明を依頼し、次に一つの小さな変更とテストを実行することです。最初から本番デプロイや広い自動修正を任せず、読み取り、提案、編集、実行の順で権限を広げます。
Claude Codeとは
Claude Codeは、コードベースを読み、質問への回答、変更案の作成、ファイル編集、コマンド実行などを支援するコーディングエージェントです。利用できる機能や認証方法は更新されるため、導入時は公式ドキュメントを正本にします。
導入前に準備すること
- Gitなどで変更前の状態へ戻せるようにする。
- APIキー、顧客情報、秘密鍵を作業フォルダから分離する。
- 実行してよいコマンドと、確認が必要な操作を決める。
- 本番ではなく検証用ブランチまたは複製環境で始める。
最初の安全な進め方
- 公式手順でインストール：OSや契約に合う最新手順を確認します。
- 対象リポジトリを開く：別案件や秘密情報を含む親ディレクトリから起動しません。
- まず質問する：構成、主要ファイル、テスト方法を説明させ、理解のずれを確認します。
- 小さな変更を依頼：文言修正や一つのテスト追加など、差分を人間が読める範囲にします。
- 差分とテストを確認：変更理由、影響範囲、テスト結果を読み、承認後に次へ進みます。
最初に避けること
本番デプロイ、権限変更、データ削除、請求に関わる操作、秘密情報の表示を一度に任せないでください。コマンドの意味が分からない時は実行前に説明を求めます。生成されたコードも、既存テスト、lint、実画面確認を通すまでは完成ではありません。
チーム運用の最小ルール
- 作業目的、対象範囲、完了条件を一つの依頼に書く。
- 変更前に既存ルールとテストを読む。
- 破壊的操作、外部送信、本番変更は人間承認にする。
- 失敗理由と修正内容をREADMEや判断ログへ戻す。
- 担当者以外が再現できる手順を残す。
依頼文に入れる6つの情報
「直して」だけでは、対象範囲と完了条件が曖昧です。最初の依頼には、目的、対象ファイル、変更してよい範囲、変更してはいけない範囲、実行する確認、完了時の報告形式を入れます。例えば「問い合わせフォームの文言だけを変更し、送信処理とCSSは変更せず、既存テストと画面確認の結果を報告する」のように書きます。
- 目的：利用者の何を改善するのか。
- 対象：読む・変更するディレクトリやファイル。
- 禁止範囲：認証、課金、本番設定、別機能など。
- 受入条件：どの表示・テスト・出力で完了とするか。
- 承認点：外部送信や破壊的操作の前に止める条件。
- 報告：変更点、未確認点、テスト結果、残るリスク。
初回セッションの具体的な手順
- 作業状態を確認する：現在のブランチ、未保存差分、テスト手順、環境変数の扱いを確認します。
- 読み取りだけを依頼する：ディレクトリ構成、起点ファイル、データの流れ、既存ルールを説明させます。
- 変更計画を出させる：編集前に、触るファイル、想定差分、テスト、リスクを短く提示させます。
- 一つだけ変更する：文言、型、単体テストなど、レビュー可能な大きさに限定します。
- 差分を読む：意図しないファイル、秘密情報、大量整形、依存関係変更がないか確認します。
- テストする：自動テストだけでなく、必要に応じて実画面や生成物も確認します。
- 判断を記録する：採用した修正、戻した修正、次回の注意点を残します。
権限を広げる判断基準
読み取りから編集へ進むのは、対象構成の説明が正しく、変更計画が受入条件と一致した後です。コマンド実行は、目的、影響範囲、外部通信、削除や上書きの有無を説明できる時だけ許可します。本番変更、権限変更、課金、公開、メール送信、データ削除は、通常の編集とは別の承認点に分けます。
権限ルールはdeny・ask・allowの設計ガイド、インストールと認証はOS別インストール手順で整理しています。複数人へ展開する場合は企業導入チェックリストに沿って管理設定と停止手順を固定してください。
失敗しやすい初期パターン
親ディレクトリから起動する
複数案件や秘密ファイルを含む広い場所から起動すると、読む必要のない情報まで作業範囲へ入り得ます。対象リポジトリのルートを明示し、追加ディレクトリは必要時だけ許可します。
大きな依頼を一度に渡す
機能追加、依存関係更新、データ移行、デプロイを一つにまとめると、失敗箇所と戻し方が分かりにくくなります。計画、最小差分、テスト、公開を分離してください。
テスト成功だけで完成にする
テストが不足していれば、成功しても利用者の期待を満たすとは限りません。変更内容に応じて、lint、型検査、単体・結合テスト、画面、ログを組み合わせます。
チームで再利用する初回チェックリスト
- 検証ブランチと復元方法がある。
- 作業ディレクトリに不要な秘密情報がない。
- 目的、対象、禁止範囲、受入条件を記載した。
- 変更前に計画と対象ファイルを確認した。
- 意図しない差分がないことを人間が読んだ。
- 必要な自動テストと実物確認を行った。
- 外部送信、本番、削除、課金は別承認にした。
- 失敗と採用判断を次回用の記録へ残した。
初回タスクの例
最初のタスクには、READMEの誤字修正、既存関数の説明、失敗中テストの原因候補整理、単体テスト一件の追加などが向いています。変更前後を短い差分で比較でき、失敗しても本番やデータへ影響しないものを選びます。逆に、認証方式の全面変更、データベース移行、依存関係の一括更新、公開操作は初回タスクに向きません。
完了時には、変更ファイル、変更理由、実行したテスト、実行できなかった確認、残るリスクを報告させます。人間は説明と実際の差分を照合し、意図しない変更がないことを確認します。
導入後の振り返り
セッション終了後に、依頼が曖昧だった点、不要な確認が増えた点、権限で止まった点、テスト不足を短く記録します。次回の依頼テンプレートやプロジェクトルールへ反映すれば、同じ説明と修正を繰り返すコストを減らせます。
安全な完了報告の読み方
「完了しました」という結論だけで受け取らず、変更したファイル、差分の要約、実行した確認、未実施の確認、残るリスクを照合します。テストが通っていても、対象外ファイルの変更や外部通信があれば確認が必要です。画面を変えた場合はスクリーンショット、データ処理を変えた場合は入力と期待出力、設定を変えた場合は差分と戻し方を確認します。
問題が見つかった時は、全文を書き直させる前に、受入条件のどこを満たさなかったかを一つずつ返します。依頼テンプレートへ不足条件を追加すれば、次回の生成前に同じ失敗を止められます。
よくある質問
非エンジニアでも使えますか？
説明や小さな変更の補助には使えますが、コマンド、権限、差分、テストを理解できない操作は詳しい担当者の確認を入れてください。
既存の大きなリポジトリで始めてもよいですか？
可能ですが、最初は読み取り中心にし、対象ディレクトリと変更範囲を限定します。復元手段とテストがない状態では編集へ進めません。
公式情報
次の一歩
導入前に業務と確認線を整理したい場合は、Miraigentの無料診断をご利用ください。