はじめに
本記事は、Claude Codeと他のAIコーディングツールのどちらを使うか迷っている人、これから使い始める人に向けて書いています。
本記事は2026年10月時点のClaude Code v2.1.287で確認した内容をもとにしています。機能追加が速いツールなので、詳細は必ず公式ドキュメントで最新情報を確認してください。
結論
Claude Codeは、ターミナルから使う自律型のコーディングエージェントです。指示を1回投げて回答を待つチャットツールではなく、コードを読み・書き・実行し、その結果を見て自分で次の一手を決めるところが特徴です。バグ修正やテスト作成、リファクタといった複数ステップの作業を、途中経過を都度確認しなくても最後まで任せられます。
つまり、Claude Codeは「どこまで作業を任せられるか」に重心を置いたツールです。
Claude Codeとは
Claude Codeはエディタの補完機能ではなく、ターミナル・IDE拡張・デスクトップアプリ・ブラウザなど複数の環境で動くCLIツールです。プロジェクトのディレクトリで起動すると、コードベース全体を読みながら複数ファイル・複数ツールをまたいで作業します。
インストールと起動
インストールはOSごとにコマンドが用意されています(例: macOS/Linuxはcurl -fsSL https://claude.ai/install.sh | bash)。起動はプロジェクトディレクトリでclaudeと打つだけです。バージョンはclaude --versionで確認できます。
$ claude --version
2.1.287 (Claude Code)
料金プラン
利用には有料プラン(Pro/Max/Team/Enterpriseのいずれか)、またはAnthropic ConsoleでのAPIキー従量課金が必要です。無料プランでは使えません。個人利用でClaude Codeが使える最安プランはPro(月額$20、年払いなら$17/月、2026年10月時点)です。
安全に運用する仕組み(権限モード)
「コードを自動で書き換えるツール」と聞くと、勝手にファイルを変更されたり危険なコマンドを実行されたりしないか気になります。Claude Codeには複数の権限モードがあり、どこまでの操作を確認なしで進めるかを選べます。Shift+Tabでいつでも切り替えられます。よく使う4つは次のとおりです。
| モード | できること | こんな人におすすめ |
|---|---|---|
| Auto(デフォルト) | 確認プロンプトはほとんど出ない。裏でclassifier(危険度を判定する審査役の別モデル)が各操作を審査する | プロンプト疲れを減らし、任せられる範囲を広げたい |
| acceptEdits | ファイル編集と、mkdirやmvなど一般的なファイル操作コマンドは自動承認。それ以外のコマンド実行は都度確認される |
編集は後でdiffをまとめて見たいが、コマンド実行は逐一確認したい |
| Manual | ファイルの読み取りは確認なし。編集・コマンド実行の前には必ず確認される | 最初は挙動を1つずつ確認したい、機密性の高い作業 |
| Plan | ファイルを一切変更せず、調査・計画だけを行う | 実装前にまず設計方針をレビューしたい |
v2.1.283以降、対話型のターミナルとVS Codeのセッションでは、Autoモードが標準の起動モードです。それより前のバージョンでは、Autoモードが標準なのはPro/Max/Teamプランだけでした。古いバージョンから更新した場合は、起動時の挙動の変化に注意してください。公式ドキュメントによると、組織の設定によってはv2.1.283以降でもManualモードで起動します。起動モードは固定できます。例えばManualモードなら、claude --permission-mode defaultのようにフラグで指定するか、設定ファイルのpermissions.defaultModeに書いておきます。
本番デプロイや秘密情報の外部送信のような危険な操作は、classifierの審査によって自動的にブロックされます。ただし、これは安全性を完全に保証する仕組みではありません。公式ドキュメントでも「一般的な方向性を信頼できる作業に使うものであり、機密性の高い操作のレビューの代わりにはならない」と位置づけられています。
編集・実行の確認という観点でもっとも慎重なManualモードでは、ファイルの編集やコマンド実行の前に必ず確認を求められます。例えばファイルを編集しようとすると、次のように変更内容を提示した上で選択肢が表示され、どれかを選ぶまで実行されません。
「Yes, and don't ask again」を選んだ場合の効果は操作の種類によって異なります。コマンド実行はそのリポジトリで恒久的に確認なしになりますが、ファイル編集の許可はそのセッション中だけ有効で、セッションを終えるとまた確認を求められます。いずれにせよ、信頼できる操作だけに絞って許可するのがおすすめです。
なお、確認をすべて省略する--dangerously-skip-permissions(bypassPermissionsモード)もあります。公式ドキュメントでもコンテナやVMなど隔離環境専用と位置づけられています。ローカル環境でそのまま使うのは避けたほうが安全です。
変更を戻す仕組み(Checkpoints)
権限モードは「実行前にどこまで確認するか」の話でしたが、Claude Codeには「実行後に戻す」ための仕組みもあります。プロンプトを送るたびに、その時点のコードの状態がチェックポイントとして自動で記録されます。/rewind(または入力欄が空の状態でEscキーを2回押す)で、コード・会話・その両方を任意の時点まで巻き戻せます。直近100件のチェックポイントがセッションと一緒に保存されるため、セッションを再開した後でも/rewindが使えます。
Bashコマンドによる変更など、Claudeのファイル編集ツールを経由しない変更は記録されない点には注意が必要です。公式ドキュメントによると、後述するSub-agentsが行った編集も、原則として巻き戻しの対象になりません。とはいえ、「操作を確認してから進める」だけでなく「進めた後にいつでも戻せる」という安全網があることは、Autoモードのように確認を減らして任せる際の安心材料になります。
使用量の管理
会話を続けるほど使用量は積み上がっていく点にも注意が必要です。Claude Codeは、直近の質問と関係のない過去のやり取りも含めて会話全体を毎リクエスト送信します。そのため、内容と関係なく使用量を消費し続けます。/usageを実行すると、自分の使用状況を次のように確認できます。
$ claude -p "/usage"
Current session: 67% used · resets Oct 10 at 8:50pm (Asia/Tokyo)
Current week (all models): 11% used · resets Oct 16 at 11am (Asia/Tokyo)
Last 24h · 133 requests · 7 sessions
18% of your usage was while 4+ sessions ran in parallel
(一部省略)
これは実際に手元で/usageを実行した際の出力例です。数値は会話の長さやセッション数によって変わるので、あくまで目安として見てください。
無関係な作業に切り替えるタイミングで/clearを挟むと、以降のリクエストで送る文脈が小さくなり、使用量の消費を抑えられます。
よく使う便利な機能
「チャットで指示を出して終わり」の使い方だと、以下の機能はほとんど使われないまま埋もれてしまいます。実務で使う場面をイメージしやすい6つを紹介します。
| 機能 | できること | こんな場面で使う |
|---|---|---|
| CLAUDE.md / Memory | プロジェクトのルールを明文化し、毎セッション自動で読み込む。Claude自身が会話から学んだ内容を残す仕組み(Auto memory)もある | コーディング規約やレビュー観点を毎回書かずに済ませたい |
| Skills | 決まった手順をパッケージ化し、スラッシュコマンドや自然文で呼び出す | 「PRを出す前に変更を要約する」など定型作業を素早く呼び出したい |
| Sub-agents | 別セッションを起動し、独立した文脈で作業させる | 時間のかかる調査を裏で走らせつつ、自分は別の作業を続けたい |
| Hooks | 決まったタイミングでシェルコマンドを自動実行する | 編集直後にlintやフォーマッタを強制的に走らせたい |
| MCP | 外部ツールやデータソースに接続し、Claude Codeから直接操作できるようにする | 課題管理ツールやDBなど、既存のシステムと連携させたい |
CLIパイプ(claude -p) |
対話モードなしで1回限りの応答を返す | 既存のシェルスクリプトやCIパイプラインに組み込みたい |
CLAUDE.md / Memory
プロジェクトルートに置くCLAUDE.mdは、セッション(claudeを起動してから終了するまでの一連の会話)開始時に毎回読み込まれる指示ファイルです。コーディング規約やアーキテクチャ上の決定、レビューチェックリストなどを書いておくと、毎回同じ指示を繰り返さずに済みます。
ゼロから手で書く必要はありません。/initを実行するとコードベースを解析し、ビルドコマンドやテスト手順、既存の規約を含む叩き台を自動生成してくれます。既にCLAUDE.mdがある場合は上書きせず、改善案を提示する挙動になっています。
以下、断りがない限りコード例はこの記事自体のリポジトリ(Zenn/Qiitaの記事をGit管理し、CIで自動公開する構成)のものです。このリポジトリ自体もCLAUDE.mdを使っており、「公開フラグを自発的にtrueにしない」「自動生成フィールドを手で編集しない」といった禁止事項を明文化しています。実際の記述は次のような形です。
### 公開状態の変更
- `published: false` → `true`(Zenn)、`private: true` → `false`(Qiita)への変更を**自発的に行わない**
- 公開は不可逆。ユーザーが明示的に「公開して」と指示したときのみ変更する
Qiitaの新規記事作成コマンドはprivate: falseをデフォルト出力しますが、CLAUDE.mdにこのルールを書いておけばprivate: trueに修正した上で作成してくれます。
Webアプリ開発のプロジェクトでも同様の使い方ができます。「本番DBへの直接接続を避ける」のような、間違えると被害が大きい操作をCLAUDE.mdに明文化しておくと、AIエージェントに安全にタスクを任せやすくなります。以下はReactプロジェクトを想定した例です。
Reactプロジェクト向けCLAUDE.mdの例
# CLAUDE.md
## 技術スタック
- React 19 / TypeScript / Vite
- 状態管理: 基本はuseState/useReducer。コンポーネントをまたぐ状態が
必要になった時点でZustand導入を検討する(Reduxのボイラープレートを避けるため)
- データ取得: TanStack Queryを使う。useEffect内で直接fetchしない
(キャッシュ・再検証・ローディング状態を自前実装させないため)
- テスト: Vitest + Testing Library
## コーディング規約
- コンポーネントは関数コンポーネントのみ。クラスコンポーネントは書かない
- propsの型は必ず`interface`で定義し、`any`は使わない
- 副作用は`useEffect`に閉じ込め、`document.querySelector`のような
直接DOM操作はしない
- 1ファイル1コンポーネントを基本とする
(複数コンポーネントを1ファイルに詰めると差分レビューが困難になるため)
## ディレクトリ構成
- `src/components`: 汎用UIコンポーネント。ビジネスロジックを持たせない
- `src/features`: 機能単位のコンポーネント・hooks・APIクライアント
- `src/hooks`: 複数featureで共有するカスタムhooks
- 新規ディレクトリを作る前に、既存構成に当てはまらないか確認する
## テストの方針
- 新規コンポーネントには最低1つのレンダリングテストを書く
- APIモックはmswを使う。`fetch`の直接モックはしない
(実際のリクエスト形式に近い状態でテストするため)
- スナップショットテストは追加しない(差分の意味が読み取りにくく形骸化しやすいため)
## 絶対にやってはいけないこと
- package.jsonの依存関係を確認なしに追加・削除しない
- `.env`ファイルやシークレットの値をコードやコミットメッセージに含めない
- mainブランチへの直接pushはしない。必ずPR経由にする
- 既存のutilを確認せずに、似た処理を持つ関数を新規に作らない
## レビュー前チェック
- [ ] eslint / prettierが通るか
- [ ] 新規コンポーネントにテストがあるか
- [ ] any型を使っていないか
- [ ] 不要なconsole.logが残っていないか
ポイントは、ルールを列挙するだけでなく理由を添えることです。「なぜダメか」が分かれば、ルールに直接該当しないケースでもエージェントが同じ意図を汲んで判断できます。技術スタック・規約・ディレクトリ構成・禁止事項・チェックリストをセットで書いておくと、実装から確認までを一貫して任せやすくなります。
CLAUDE.mdが「人間が書く指示」なのに対して、Claude Codeにはもう1つ、Claude自身が会話から学んだ内容を書き残す「Auto memory」という仕組みがあります。会話中に伝えた訂正や好み、コードからは読み取れないプロジェクトの背景などを~/.claude/projects/<プロジェクト名>/memory/配下に保存します。保存した内容は、次回以降のセッションで自動的に読み込まれます。ローカルのセッションではデフォルトで有効になっており、/memoryを実行すると保存内容の確認や無効化ができます。
CLAUDE.mdに書くほど恒久的ではないものの、毎回説明し直すのは面倒な情報を拾ってくれる点が、CLAUDE.mdとの役割分担です。「ルールはCLAUDE.mdに人が書く、経緯や好みはAuto memoryにClaudeが書く」とすみ分けておくと、指示の書き直しを減らせます。
Skills
Skillsは、再利用可能な手順をパッケージ化し、スラッシュコマンド(/skill名)や自然文からの自動判断で呼び出せる仕組みです。.claude/skills/<skill名>/SKILL.mdに配置し、frontmatterのdescriptionをもとに「いつ使うべきSkillか」をClaude自身が判断します。
例えば、コミットされていない変更を要約するSkillは次のように定義します。
---
description: コミットされていない変更を要約し、危険な箇所をフラグします。
---
## 現在の変更
!`git diff HEAD`
## 指示
上記の変更を2〜3行の箇条書きで要約してください。その後、エラーハンドリングの
欠落やハードコードされた値など、気付いた危険な箇所をリストアップしてください。
呼び出し方は2通りあります。/summarize-changesのようなスラッシュコマンド、または「コミットされていない変更を要約して」のような自然文です。後者はdescriptionをもとにClaudeが自動判断します。claude -pは対話モードを使わず1回限りの応答を返すオプションで、詳しくは後述します。
$ claude -p "/summarize-changes"
## 変更の要約
- `public/what-is-claude-code.md`: 記事の導入を「他のAIツールと比較検討中の人向け」に変更し、
インストール/料金/権限モード/使用量管理の節を新設
- 紹介する機能を4つから6つ(Hooks・MCPを追加)に拡張
## 気になる危険な箇所
- Pro/Max/Teamプランでのデフォルトモードに関する記述が、公式ドキュメントで裏取りできているか要確認
(以下略)
反映タイミングには1点だけ注意点があります。.claude/skills/配下の既存ファイルの変更は、再起動なしで同一セッションに反映されます。ただし、それまで存在しなかったトップレベルのskillsディレクトリを新しく作った場合、Claude Codeはそのディレクトリをまだ監視していません。この場合は/reload-skillsを実行してください。このディレクトリはセッション中も自動監視の対象にならないため、変更するたびに/reload-skillsを再実行する必要があります。チームへ新規導入する際に確認しておくとよいでしょう。詳細は公式ドキュメントを参照してください。
「PRを出す前に変更内容を要約してレビュー観点をチェックする」のような、毎回手順が決まっている作業をSkillにしておくと便利です。コマンド名を覚えなくても自然な言葉で呼び出せる点が、単なるチャットでの指示出しとの違いです。
Sub-agents
Sub-agentsは、Claude Codeに内蔵されている「別セッションを起動する機能」です。メインセッションの会話履歴を汚さずに、独立した文脈で調査や作業を任せられます。内部的にはAgentツールと呼ばれています。v2.1.63でTaskツールから改名されたもので、設定ファイルなどでTask(...)という旧名の表記を見かけることがあるのはこのためです。
組み込みのサブエージェントは、定義ファイルを用意しなくても使えます。対話中に「〜をsub-agentに任せて」と自然文で頼むだけです。例えば、次のように依頼できます。
このリポジトリで、記事がQiitaに公開されるまでの流れを調べてください。
.github/workflows、scripts、package.jsonを読んで、どのファイルが
何を担当しているかを報告してください。読むだけで、編集は不要です。
このタスクをsub-agentに任せてください。
依頼するとバックグラウンドで実行され、完了時に結果だけが通知されます。メインの会話をブロックしないので、実行中は別の作業を並行して進められます。
時間のかかる調査を1つ裏で走らせながら自分は別の作業を続けたい場合はもちろん、独立した複数の調査(フロントエンドとバックエンドを別々に調べるなど)を一度に依頼して並行して進めたい場合にも活躍します。
役割を固定したサブエージェントは、自分でも定義できます。.claude/agents/<名前>.md(プロジェクト単位)か~/.claude/agents/<名前>.md(ユーザー単位)にMarkdownファイルを置きます。frontmatterのnameとdescriptionが必須で、本文がそのサブエージェントのシステムプロンプトになります。
例えば、書き上げた記事をレビューする担当は次のように定義します。
---
name: article-reviewer
description: 記事の下書きをCLAUDE.mdの公開前チェックに沿ってレビューします。記事を書き終えたとき、または公開前の確認を頼まれたときに使います。
tools: Read, Grep, Glob
---
あなたは技術記事のレビュー担当です。
執筆の経緯は知らない前提で、初見の読者として記事を読んでください。
指定された記事を読み、CLAUDE.mdの「開示レベル」「文体」「公開前チェック」に照らして問題点を報告します。
- 指摘は重要な順に5件まで。該当箇所の行番号と、そう判断した理由を添える
- 記事は編集しない。修正案は文章で示す
- 問題がなければ「指摘なし」と報告する
レビューをサブエージェントに切り出す理由は2つあります。1つは、執筆中の会話を引き継がないことです。書き手の意図を知らない状態で読むので、説明不足の箇所に気付きやすくなります。もう1つは、toolsで使えるツールを絞れることです。読み取り系のツールだけを許可しておけば、レビュー担当が記事を書き換えることはありません。Webアプリ開発であれば、同じ形でコードレビュー担当を定義できます。
呼び出すときは「article-reviewerサブエージェントを使って、この記事をレビューして」と名指しで頼みます。
公式ドキュメントによると、Skillsと同様にdescriptionをもとにClaudeが自動で委譲する仕組みもあります。ただし手元では、名指ししない依頼はメインセッションでそのまま処理される場合もありました。確実に使わせたい場合は、名指しで頼むのが無難です。
Hooks
Hooksは、ツール実行の前後など決まったタイミングでシェルコマンドを自動実行する仕組みです。設定は.claude/settings.json(チーム共有用)か.claude/settings.local.json(個人用)に書きます。対象ツールはmatcher、実行タイミングはPreToolUseやPostToolUseなどのイベント名で指定します。実行内容はcommandに書きます。
例えば、Markdownファイルを編集した直後に自動でtextlintを走らせ、結果をClaudeに渡す設定は次のようになります。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.file_path' | grep -E '/(articles|public)/.*\\.md$' | xargs -r npx textlint >&2 || exit 2"
}
]
}
]
}
}
PostToolUseはツール実行後に発火するイベントで、matcherで対象ツール(ここではEditとWrite)を絞り込みます。フックコマンドは標準入力でJSONを受け取り、tool_input.file_pathに編集対象のファイルパスが入っているので、jqで取り出してパイプでつなぐだけで動きます。
末尾の>&2 || exit 2は、lint結果をClaudeに届けるための指定です。フックが終了コード2で終わると、標準エラー出力の内容がClaudeに渡されます。PostToolUseはツール実行後のイベントなので、編集そのものは取り消されません。
claude --debug hooksを使うと、フックの実行ログを確認できます。lintエラーを含むMarkdownファイルを書かせると、次のように記録されます(実際のログは1行で、ここでは改行を展開しています)。
Hook PostToolUse:Write (PostToolUse) error: status code 2
stderr:
/path/to/public/_hook-test.md
3:9 error Disallow to use "!" ja-technical-writing/no-exclamation-question-mark
3:10 error Disallow to use "!" ja-technical-writing/no-exclamation-question-mark
3:10 error "!" が連続して2回使われています。 ja-technical-writing/ja-no-successive-word
✖ 3 problems (3 errors, 0 warnings, 0 infos)
このとき、同じ3件のエラーがClaudeにも届いていました。届いた指摘をもとに、Claudeがそのまま修正に進めます。
>&2 || exit 2を付けない場合は注意が必要です。この場合、フックは2以外の終了コードで終わります(手元のmacOSでは1でした)。2以外の失敗は「処理を止めないエラー」として扱われます。lint結果はデバッグログに残るだけで、Claudeには届きません。実際に試すと、Claudeは「フックからのフィードバックは届いていません」と答えました。
反映タイミングについては、Skillsと違って注意点はありません。settings.json・settings.local.jsonへのフック設定の直接編集は、ファイル監視によって自動的に検知され、セッションを再起動しなくても反映されます。詳細は公式ドキュメントを参照してください。
「エージェントが編集した瞬間にlintやフォーマッタを強制的に走らせる」用途で特に効果を発揮します。レビュー段階で気付くより手前で機械的に問題を潰せる点がメリットです。
MCP
MCP(Model Context Protocol)は、Claude Codeを外部ツールやデータソースに接続するためのオープンな標準です。MCPサーバーを追加すると、課題管理ツールやデータベースなど既存のシステムをClaude Codeから直接操作できるようになります。
接続済みのMCPサーバーはclaude mcp listで確認できます。次は手元での実行結果をもとにした出力イメージです(サーバー名はダミー、接続状況は環境によって変わります)。
$ claude mcp list
Checking MCP server health…
notion: https://mcp.notion.com/mcp - ✔ Connected
slack: https://mcp.slack.com/mcp - ! Needs authentication
新しくMCPサーバーを追加する場合はclaude mcp addを使います。公式ドキュメントでは、リモートのHTTPサーバーを次のように追加する例が示されています。
claude mcp add --transport http notion https://mcp.notion.com/mcp
課題管理ツールのチケットを起点に実装からPR作成までを任せたり、監視ツールのデータを踏まえて障害調査をさせたりする用途で使われます。CLAUDE.md・Skills・Sub-agentsはClaude Code自身の振る舞いを整える機能ですが、MCPはClaude Codeの外にある既存のシステムとつなぐ機能という位置づけです。
CLIパイプ(claude -p)
claude -pを使うと、対話モードを使わずに1回限りの質問応答を実行できます。Unixのパイプと組み合わせられるので、既存のシェルスクリプトやCIパイプラインに組み込みやすいのが特徴です。
例えば、gitのコミットログをパイプで渡すだけで要約を得られます。
$ git log --oneline -5 | claude -p "このコミット履歴から、このリポジトリが何を管理しているか一言で要約して"
Zenn と Qiita の技術記事を執筆・管理し、GitHub Actions で自動公開するリポジトリです。
標準入力を渡すだけで動くので、CI上でのPRレビュー自動化やテスト失敗ログの解析など、Web開発の既存の自動化フローに後付けしやすい機能です。
使ってみて感じたこと
6つの機能には、共通する発想があります。
- 文脈を明文化する(CLAUDE.md/Memory)
- 手順をパッケージ化する(Skills)
- 作業を分離・並列化する(Sub-agents)
- 実行を機械的に強制する(Hooks)
- 既存のシステムとつなぐ(MCP)
- 既存のフローに組み込む(CLIパイプ)
どれもチャットで1往復するだけでは出てこない使い方です。単発の指示出しとは、前提にしている使い方そのものが違います。
まとめ
Claude Codeは、コード補完ツールの延長ではなく、ターミナルから複数ステップの作業を任せられる自律型のエージェントです。CLAUDE.md/Memory・Skills・Sub-agents・Hooks・MCP・CLIパイプの6つは、いずれも「チャットで指示するだけ」から一歩進んだ使い方です。Webアプリ開発の実務にもそのまま持ち込めます。まずはCLAUDE.mdでプロジェクトのルールを明文化するところから試してみるのがおすすめです。他のAIコーディングツールと比較検討している場合も、ここで紹介した機能を実際に触った上で比較すると判断しやすくなるはずです。