Claude Codeの使い方ガイド
ターミナルで動くAIコーディングツール「Claude Code」を、実際に手を動かしながら使えるようになるためのガイドです。インストールや契約プランについてはClaudeの契約とClaude Codeのインストール手順にまとめているので、ここでは導入後の実践的な使い方に絞って説明します。
目次
- 最初にやること
- 動作モードを選ぶ（最初に理解すべき安全設定）
- モデルを選ぶ
- よく使う操作（逆引き）
- CLAUDE.mdを書く・育てる
- 計画を立てて進める（フェーズ・ステップ単位）
- 繰り返す作業を仕組み化する
- コンテキストとコストを管理する
- 既存プロジェクトでの進め方
- GitHubと連携する
- マルチデバイス・プラグインを活用する
- コーディング以外の仕事に使う
- 困った時のチェックリスト
1. 最初にやること
インストールとログインが済んだら、以下の流れで最初の一歩を踏み出す。
- プロジェクトのルートディレクトリで
claudeを起動する -
/initを実行し、CLAUDE.md（プロジェクトの説明書）の雛形を作る - 簡単な指示を1つ出してみる（例:「READMEの内容を要約して」）
- 終了するときは
/exit、またはターミナルを閉じる
覚えておくと安心な操作
| やりたいこと | 操作 |
|---|---|
| 今の応答を中断したい | Esc |
| 直前のセッションから再開したい |
claude -c または claude --continue
|
| 過去のセッション一覧から選んで再開したい |
claude -r または /resume
|
| 会話とコードの変更を巻き戻したい |
Esc を2回、または /rewind
|
| 入力履歴を検索したい | Ctrl + r |
| 対話を終了したい | /exit |
2. 動作モードを選ぶ（最初に理解すべき安全設定）
Claude Codeがファイルを編集したりコマンドを実行したりする前に、どこまで確認を求めるかを「モード」で制御する。Shift + Tab を押すとモードが切り替わる。
| モード | 何を確認なしで実行するか | どんな時に使うか |
|---|---|---|
| Manual（既定） | 読み取りのみ | 使い始め・機密性の高い作業 |
| Plan | 読み取りのみ（編集はしない） | 変更前にコードベースを調査・計画したい時 |
| Accept Edits | 読み取り・ファイル編集・簡単なファイル操作 | レビュー前提でどんどん編集を進めたい時 |
| Auto | ほぼすべて（裏側で安全性チェックが働く） | 長時間の作業で確認疲れを減らしたい時 |
| Bypass Permissions | すべて（チェックなし） | ネット接続のないコンテナ・VM内限定 |
手順:
- 起動直後は Manual モードになっている
- コードベースを調査してから進めたい大きめの変更は、
Shift + Tabで Plan モードに切り替えてから依頼する - Claudeが計画を提示したら内容を確認し、「承認して編集を進める」を選ぶ
- 慣れてきたら、レビュー前提の作業は Accept Edits モードのまま進めると効率が良い
- Bypass Permissions（
--dangerously-skip-permissions）は、ネットワークを遮断したコンテナ等、隔離された環境以外では使わない
最初にこのモードの考え方を理解しておくと、「何が起きるか分からないまま実行される」という不安なく進められる。
3. モデルを選ぶ
Claude Codeでは複数のモデルを用途に応じて使い分けられる。位置づけの目安は以下の通り（モデル名やラインナップは今後変わりうるため、最新情報はclaude.comで確認するとよい）。
| モデル | 位置づけ | 特徴 |
|---|---|---|
| 最上位モデル | 最も難しい・長時間の課題向け | 常時高度な推論を行う |
| 上位モデル | 複雑な推論・自律性の高い作業向け | 推論の深さ（effort）を調整可能 |
| 標準モデル | 速度と知能のバランス | 日常のコーディング・複数エージェントの調整役に最適 |
| 軽量モデル | 最速・低コスト | 反復作業や簡易タスク向け |
手順:
- モデルを切り替えたい →
/modelを実行し、一覧から選ぶ（デフォルトとして保存も可能） - 推論の深さだけ変えたい（モデルは変えない） →
/effortを実行する - 出力を速くしたい（上位モデル利用時） →
/fastでFast modeを切り替える
選び方の目安: 普段の作業は標準モデルから始める。設計判断や複雑な自律作業が必要になったら上位モデルに切り替える。最も難しい一発勝負のタスクには最上位モデルを使う。大量の反復作業や、サブエージェントに任せる軽い作業は軽量モデルでコストを抑える。
4. よく使う操作（逆引き）
| やりたいこと | 操作 |
|---|---|
| 会話をリセットして新しい話題に入りたい | /clear |
| 会話を要約してコンテキストを空けたい |
/compact（例: /compact コードの変更点だけ残して） |
| 今のコンテキスト使用状況を見たい | /context |
| CLAUDE.mdやメモリを編集したい | /memory |
| 使っているトークン量・コストを見たい |
/usage（/costでも同じ） |
| 会話を分岐させて別の方向を試したい | /branch |
| 会話をバックグラウンドで複製して並行作業したい | /fork |
| 参照するディレクトリを追加したい | /add-dir <path> |
PRやIssueへの@claudeメンション連携を設定したい |
/install-github-app |
| PRの差分をレビューしてほしい |
/review または /code-review
|
| セキュリティ上の問題がないか確認したい | /security-review |
| MCPサーバーの接続を管理したい | /mcp |
| 許可ルールを設定・確認したい | /permissions |
| フックの設定を確認したい | /hooks |
| 設定（テーマ・出力スタイルなど）を変えたい | /config |
| Claude Codeの不調を診断・修復したい | /doctor |
| その場でメモリに一言残したい |
# に続けて入力する |
5. CLAUDE.mdを書く・育てる
CLAUDE.mdは、Claudeがそのプロジェクトを理解するための「索引」。詳細な検討経緯まで書き込むと肥大化してコンテキストを圧迫するので、以下の3段階で育てていく。
手順
-
作る: プロジェクトルートで
/initを実行し、雛形を作る - 書く: プロジェクトの概要、よく使う作業、ディレクトリ構成、命名規則など「毎回説明し直したくない前提知識」を書く
-
分割する: CLAUDE.mdが大きくなってきたら、以下のように分割する
- サブディレクトリごとのCLAUDE.md（そのディレクトリのファイルを扱う時だけ読み込まれる）
-
.claude/rules/配下にファイルパターン限定のルールを置く
.claude/
├── CLAUDE.md
└── rules/
├── code-style.md
└── testing.md
.claude/rules/内のファイルは、frontmatterのpathsで適用範囲を絞れる。
---
paths: src/**/*.{ts,tsx}
---
# TypeScript/React向けルール
docs/ディレクトリとの使い分け
「CLAUDE.mdに全部書かず、docs/配下にMarkdown文書を置く」というやり方自体はよく見かける方法だが、docs/という名前自体はClaude Code固有の機能ではなく、単なる普通のフォルダ。Claude Codeは「必要な時にプロジェクトのファイルを読みに行く」ため、docs/配下に何か置いてあり、README等から参照されていれば、CLAUDE.mdに書かなくても自然に読みに行く。
その上で、公式が用意している「CLAUDE.mdを太らせずに詳細を追い出す」仕組みは次の2つ。
| 方法 | 効果 | 使いどころ |
|---|---|---|
@path/to/file インポート |
CLAUDE.md内に書くと、そのファイルの中身がセッション開始時に丸ごと読み込まれる（コンテキスト節約にはならない） | 常に前提として知っておいてほしい詳細を、ファイルとして分けて管理したい時。公式の例も- git workflow @docs/git-instructions.mdのようにdocs/配下のファイルをインポートする形 |
.claude/rules/（paths指定） |
該当するファイルパターンを扱う時だけ読み込まれる（コンテキスト節約になる） | 特定の言語・ディレクトリにだけ関係するルールを持ちたい時 |
使い分けの結論:
- 常にClaudeに前提として知っておいてほしい内容 → CLAUDE.md本体に直接書くか、
@docs/xxx.mdでインポート - 特定のファイル種別・ディレクトリでだけ必要なルール →
.claude/rules/（paths指定） - 一度きりでなく繰り返す「手順」 → Skills化（7章参照）
- 単なる参考資料・詳細ドキュメント（毎回読ませる必要はない） →
docs/のような普通のフォルダに置くだけでよい。Claudeは必要になった時に自分で読みに行く。CLAUDE.md側には「詳しくはdocs/xxx.mdを参照」と一言書いておけば十分
どちらのやり方でも問題はなく、「毎回読ませたい索引（CLAUDE.md）」と「必要な時に読みに行く詳細（フォルダ配下のファイル）」を分離する、という考え方が本質。フォルダ名はdocs/に限らず、specs/（仕様）・notes/（検討経緯）・reports/（進捗）のように目的別に分けても構わない。
docs/の作り方（具体例）
「結局何をどう分ければいいか」で迷った時は、以下の型をそのまま使うとよい。実務でそのまま使いやすい最小構成にしている。
docs/
├── design/ # 設計ドキュメント（なぜその作りにしたか、構成図など）
├── how-to/ # 手順書（セットアップ手順、運用手順など）
├── plans/ # 計画書（フェーズ・ステップとチェックリスト。次章で詳しく扱う）
└── refs/ # 参考情報（外部資料のコピー・要点メモ、参照URLのリストなど）
設計ドキュメントを作らせる例:
ログイン機能の設計をdocs/design/2026-07-22_ログイン設計.mdにまとめてください。
どんな選択肢を検討し、なぜ今の構成にしたかが分かるように書いてください。
手順書を作らせる例:
今回のデプロイ手順をdocs/how-to/デプロイ手順.mdに書き出してください。
次に別の人が読んでもそのまま実行できるように、番号付きの手順にしてください。
CLAUDE.mdには「詳しい設計はdocs/design/、手順はdocs/how-to/を参照」と一言だけ書いておけば、Claudeは必要な時に自分でそのフォルダを読みに行く。
参考情報の渡し方（docs/refs/とURL）
Claude Codeは、起動しているディレクトリ配下のファイルを必要に応じて自分で読みに行く。ディレクトリ配下に存在しないものでも、URLを伝えればそのページを取得しに行く。この2つの性質を理解しておくと、何かを依頼する前の「参考にしてほしい情報の渡し方」で迷わなくなる。
渡し方は主に2通り。
| 渡し方 | 向いている場面 |
|---|---|
| プロンプトに直接書く・貼り付ける | その場限りでよい、量が少ない参考情報 |
docs/refs/にファイルを置く、またはURLを伝える |
繰り返し参照したい、量が多い、次回以降のセッションでも使い回したい参考情報 |
依頼例（ファイルを参照させる場合）:
docs/refs/API仕様書.pdfを参考に、この機能を実装してください。
依頼例（URLを参照させる場合）:
https://example.com/spec を見て、その内容に沿って実装してください。
一時的な質問ならプロンプトに直接貼り付ければ十分だが、何度も参照する資料はdocs/refs/に置いておくと、次回以降は「あのファイルを見て」と指定するだけで済み、参考情報そのものが資産として残る。
格納例:
-
docs/refs/— 使用しているプログラミング言語・フレームワークの公式マニュアルやリファレンスPDFなどを格納する -
docs/design/（またはdocs/inspiration/等） — デザインの参考にしたい・影響を受けた画像やスクリーンショットを格納する
このように、資料の種類ごとにフォルダを分けて置いておけば、「docs/design/の画像を参考に、この画面のUIを考えて」のように、フォルダ名を指定するだけで参照させられる。
指示を確実に伝えるコツ
CLAUDE.mdの内容は「今の作業に関係があると判断された時だけ」重視される。そのため、抽象的な心構えではなく、「〇〇した後は必ず△△する」のように行動とセットで書くと伝わりやすい。
実例: 複数プロジェクトを横断管理する場合
複数プロジェクトや複数の案件を1つのワークスペースで横断管理したい場合は、CLAUDE.mdに以下のような工夫を加えるとよい。
- プロジェクト一覧・会議一覧・案件一覧をそれぞれテーブル化し、状態とフォルダパスをセットで管理する
- 変更履歴を積み上げて、いつ何を変更したか追跡できるようにする
- 定型作業は
.claude/skills/にAgent Skillsとして切り出し、CLAUDE.md本体を太らせない
6. 計画を立てて進める（フェーズ・ステップ単位）
多くの人が一番困るのは「結局、何をどこまで自分で決めて、どこからClaudeに任せていいのか分からない」という点。**「いきなり実装させず、先に計画を作らせてから進める」**という型さえ覚えておけば、迷わず進められる。
2つの計画の立て方
| 方法 | 何をするか | 向いている場面 |
|---|---|---|
Plan モード（Shift + Tab、2章参照） |
その場でClaudeが計画を提示し、承認してから実装に進む。計画は会話の中にだけ残る | 1回のセッションで完結する、比較的小さい作業 |
| 計画をMarkdownファイルに書かせる | フェーズ・ステップ単位でチェックボックス付きの計画書を作らせ、進捗をファイルに残しながら進める | 複数回のセッションにまたがる作業。進捗を後から見返したい・人に共有したい作業 |
まずはファイルに残す方法から始めるとよい。Claude Codeの操作画面を見なくても、ファイルを開くだけで「今どこまで終わったか」が分かる。
計画から再開までの流れ
-
実装させる前に、まず計画だけを作らせる
〇〇機能の実装計画を、フェーズ・ステップ単位でdocs/plans/2026-07-22_〇〇計画.mdに チェックボックス付きで書いてください。実装は始めず、計画の作成だけお願いします。 -
できあがった計画の内容を確認する（この時点では何も実装されていない）
-
問題なければ、計画に沿って進めるよう依頼する
docs/plans/2026-07-22_〇〇計画.mdの計画に沿って、フェーズ1から進めてください。 1つのステップが終わるごとにチェックボックスにチェックを入れてください。 -
Claudeは各ステップが終わるたびに、計画書の該当箇所を
- [ ]から- [x]に書き換えていく -
セッションを終えて後日再開する時は、計画書を指定するだけでよい
docs/plans/2026-07-22_〇〇計画.mdを見て、終わっていないステップから続きをお願いします。
出来上がる計画書のイメージ
# 〇〇機能 実装計画
## フェーズ1: 調査
- [ ] 既存コードの該当箇所を確認する
- [ ] 影響範囲を洗い出す
## フェーズ2: 実装
- [ ] Aを実装する
- [ ] Bを実装する
## フェーズ3: 確認
- [ ] テストを実行する
- [ ] 動作確認する
Planモードとの併用
計画書ができた後、各フェーズの実装に入る前にShift + TabでPlanモードに切り替えると、「そのフェーズで具体的に何をするか」をもう一段階細かく確認してから進められる。大きな計画（ファイル）の中の、小さな一手（Planモード）という組み合わせで考えるとよい。
7. 繰り返す作業を仕組み化する
一度きりの依頼はチャットで済むが、「何度も同じ形で頼む作業」は仕組み化すると効率が上がる。
| 機能 | 使いどころ | 作る手順 |
|---|---|---|
| Agent Skills | 手順が決まっている定型作業 |
.claude/skills/[名前]/SKILL.mdにfrontmatter（name・description）と手順を書く |
| サブエージェント | 専門性の高い役割を本体の会話から分離したい |
.claude/agents/にMDファイルを置くか、Claudeに直接作らせる |
| Hooks | 特定のイベントで必ず何かを実行したい |
/hooksで現在の設定を確認し、settings.jsonにイベント名とコマンドを追加する |
| MCPサーバー | 外部サービス（カレンダー・Slack等）と繋ぎたい |
/mcpでサーバーを追加・管理する |
| プラグイン | Skills・サブエージェント・Hooksをチームで共有したい |
claude plugin init <name> で雛形を作り、内容を書いてマーケットプレイス経由で配布する |
使い分け指針
- 手順があるだけ → Agent Skills
- チームで再利用・共有したい → プラグイン化
- 専門role分離 → サブエージェント
- 必ず自動実行したい処理 → Hooks
- 外部サービス連携 → MCPサーバー
Skillsを作る最短手順
-
.claude/skills/議事録整形/のようなフォルダを作る -
その中に
SKILL.mdを作り、冒頭に以下を書く--- name: 議事録整形 description: 会議の文字起こしを定型フォーマットの議事録に整形する --- （ここに具体的な手順を書く） -
Claude Codeを再起動、または新しいセッションで
/議事録整形と入力して動作確認する
8. コンテキストとコストを管理する
目安
Claude Codeはトークン消費に応じて課金される（サブスクリプションプランの場合はプラン内の使用量として消費）。組織導入時のコスト感は利用実態により大きく変動するため、まずは/usageでこまめに確認しながら実態を把握するとよい。
詰まった時の対処手順
| 状況 | 対処 |
|---|---|
| 会話が長引いて反応が鈍くなってきた |
/compact で要約し、必要なら要約時の重視ポイントを指定する |
| 全く別の作業に移る |
/clear で会話をリセットする（前の会話は/resumeで戻れる） |
| 実装の方向性がズレて手戻りが発生した |
Escを2回、または/rewindで会話とコードを巻き戻す |
| 調査でログや検索結果が大量に出そう | 本体で読まず、サブエージェントに調査を任せて要約だけ受け取る |
| 今何にコンテキストを使っているか知りたい |
/context で確認する |
| 今のセッションのコストを知りたい |
/usage（または/cost）で確認する |
費用を抑える基本
- 単純な作業は標準モデル、複雑な設計判断だけ上位モデルに切り替える（
/model） - 使っていないMCPサーバーは
/mcpで無効化する - CLAUDE.mdは200行程度を目安にし、頻度の低い手順はSkillsに逃がす
- ログ出力やテスト結果など大量のテキストは、Hooksで必要な部分だけ抽出してから渡す
9. 既存プロジェクトでの進め方
規模による使い分け
| 規模 | アプローチ |
|---|---|
| 小規模 | その場で直接依頼する（ワンショット） |
| 中規模 | 仕様を先に固めてからタスクを分割して依頼する |
| 大規模・既存コード | コンテキスト管理・モジュール化・設計原則を徹底する |
既存コードベースを調査する手順
- 実装前に、まず調査専用のサブエージェント（Explore等）に「〇〇の実装箇所を調べて」と依頼する
- 調査結果の要約だけを受け取り、本体の会話にログや大量のコードを流し込まない
- 調査結果をもとに、Plan モード（
Shift + Tab）で実装方針を確認する - 方針に合意したら、Accept Edits モードなどに切り替えて実装を進める
- シンボル定義やコード参照を正確に追いたい場合は、LSP（Language Server Protocol）対応のプラグインを導入すると、grepだけに頼るより正確に構造を把握できる
中〜大規模開発の4つのポイント
- 不確実性を下げる: タスクを適切な粒度に分割し、無関係な話題でコンテキストを混ぜない
- 制御可能にする: Lint/Formatter/テストをHooksで自動実行させ、危険な操作は許可ルールで防ぐ
- モジュール化・定型化する: 依存の少ないテスタブルなコードほど精度が上がる。定型作業はSkills化する
-
可読性を高める:
/configで出力スタイルをExplanatory系にすると「なぜそうしたか」を説明してくれる
10. GitHubと連携する
gh コマンドの基本
brew install gh # インストール
gh auth login # GitHubアカウントと連携
Claude Code GitHub Actionsを導入する手順
- リポジトリの管理者権限で、Claude Codeのターミナルから
/install-github-appを実行する - 案内に従ってGitHub Appをインストールする（Contents / Issues / Pull requestsへの読み書き権限を許可）
- ワークフローファイル（
.github/workflows/）とAPIキー（リポジトリのSecrets）の設定まで対話的に進む - 設定後、PRやIssueのコメントで
@claudeとメンションして動作確認する
使い方の例
@claude このIssueの内容をもとに実装してください
@claude このエンドポイントの認証はどう実装すべきですか
@claude ユーザーダッシュボードのTypeErrorを直してください
自動レビューを常に走らせたい場合は、PR作成・更新時に発火するワークフローを追加し、promptにSkillの呼び出し（例: /code-review:code-review）を渡す設定にする。
コストを抑える設定
- ワークフローの
claude_argsに--max-turnsを指定し、暴走を防ぐ - API利用料とGitHub Actionsの実行時間（分単位課金）の両方がかかる点に注意する
11. マルチデバイス・プラグインを活用する
場所を問わず使う
| 使いたい場面 | 使うもの |
|---|---|
| ブラウザだけでクラウド実行したい | https://claude.ai/code（Claude Code on the Web） |
| ローカルのセッションをクラウドに送りたい | claude --cloud |
| クラウドのセッションをローカル端末に戻したい | /teleport |
| 別デバイスから今のローカルセッションを操作したい | /remote-control |
| デスクトップアプリで続きをしたい | /desktop |
| スマホから確認したい |
/mobile（QRコードが表示される） |
| ブラウザ操作を絡めたい |
/chrome（Claude in Chrome連携） |
プラグインで機能を共有する
個人・プロジェクト限定の設定は.claude/配下に置けば十分だが、チームや複数プロジェクトで同じSkills・サブエージェント・Hooksを使い回したい場合はプラグイン化する。
-
claude plugin init <name>で雛形を作る -
skills/agents/hooks/等に中身を追加する -
/plugin marketplace add <リポジトリ>でマーケットプレイスを登録し、/plugin installで配布する
12. コーディング以外の仕事に使う
Claude Codeは「手順が言語化できる作業」であれば、コーディング以外の業務にもそのまま使える。
進め方
- 繰り返している定型作業を1つ選ぶ（議事録整形・報告書レビュー・要件定義など）
- その作業の手順を言葉にして
.claude/skills/[名前]/SKILL.mdに書く - 実際に使いながら、手順の抜け漏れを直していく
活用例
非エンジニアリングの定型業務でも、以下のようなSkillsを用意しておくと日々の作業を型化できる。
| Skill | 用途 |
|---|---|
| meeting-minutes | 文字起こしを議事録に整形し、定例会議の記録に追記する |
| pyramid-principle | 報告書・仕様書が「結論→根拠」の構成になっているかレビューする |
| requirement-definition | 要件定義書の作成・レビューを型に沿って進める |
コードを書く仕事でなくても、手順が言葉にできる作業であれば、この章の考え方がそのまま使える。
13. 困った時のチェックリスト
- 何が起きるか不安 →
Shift + Tabで Manual モードのまま進める - 動きがおかしい・方向性がズレた →
Escを2回、または/rewind - 反応が鈍い・コンテキストが重い →
/compactまたは/clear - 今何が起きているか知りたい →
/context（コンテキスト） //usage（コスト） - 設定がおかしい →
/doctor - 使い方が分からないコマンドがある →
/help
より詳しい導入手順はClaudeの契約とClaude Codeのインストール手順も参照してください。
元記事（自社サイト）: https://www.bitz.co.jp/notebook/claude-code-usage-guide.html