Claude Code インストールと設定（macOS/Windows）

Claude Codeを今日中に使い始めたい人向けに、macOS・Windows・WSL・Linuxの違いを一つの記事で整理しました。
いま使っているOSで最短の導入ルートが分かるよう、実行コマンドと注意点を中心に手順をまとめています。

本記事は編集部が公式ドキュメントと一般的な導入挙動をもとに手順を整理したものです。
環境によって挙動が異なるため、個別に検証する際は使用中の OS と導入チャネル（Homebrew / WinGet / WSL など）を明示してください。

AnthropicのClaude Code [をセットアップするやQuickstart]で確認できる基本フローを土台にします。
これからOS別の手順と注意点を具体的に見ていきます。
CLIが初めてでも、古いnpm前提の情報に振り回されず、今の公式に沿って入れるのがいちばん早いです。

Claude Codeとは何か

Claude Codeは、ターミナルを起点にコードベース全体を読み、必要なファイルを編集し、テストやビルドなどのコマンドを実行しながら進められる、Anthropicのagentic coding toolです。
ここでいうagenticは、単発で答えを返すだけでなく、与えられた目的に向けて複数の操作を組み立てて進める性格を指します。
コード読解、編集、コマンド実行、開発ツール連携までを一体で扱う設計が明示されています。

利用形態はCLIだけではありません。
ターミナルで動くTerminal CLIに加えて、VS Code拡張のようなIDE連携、デスクトップアプリ、ブラウザからも使えます。
ただ、最初の入口としてはCLIがいちばん輪郭をつかみやすいのが利点です。
プロジェクトのディレクトリでclaudeを起動すると、どの権限が必要で、どの操作をこれから行うのかが順番に見えるからです。
私もCLI版を最初に触ったとき、提案されたコマンドがいきなり実行されるのではなく、実行前に承認を挟める構造になっていて、ローカル環境を触らせる道具としての不安が小さくなりました。
導入後にまず通る確認はシンプルで、インストール直後にclaude --versionを打ち、続いて対象プロジェクトでclaudeを実行すれば、起動と認証の流れに入れます。

通常のClaudeチャットとの違い

Claude.aiの通常チャットは、ブラウザ上で質問や相談をする形が中心です。
一方のClaude Codeは、ローカルのワークスペースに入って実際のファイルやコマンドに触れられる点が決定的に違います。
会話の内容だけで完結するのではなく、「このリポジトリの構成を読んで」「このファイルを直して」「テストを走らせて結果を見て」という一連の開発作業に接続できます。

そのぶん、権限の考え方も異なります。
通常チャットではローカル環境へのアクセスは前提になりませんが、Claude Codeでは読み取りや編集、コマンド実行の前に承認フローがあり、どこまで任せるかを段階的に決められます。
実際に起動すると、提案内容ごとに確認が入るので、AIに丸投げしている感覚ではなく、作業を並走している感覚に近づきます。
プロジェクト単位の文脈を持てるのも特徴で、CLAUDE.mdにそのリポジトリ固有のルールや前提を書いておくと、次回以降のやり取りで話が早くなります。
初回の骨組みは/initで作れます。

もうひとつ押さえておきたいのが、ワークスペースの概念です。
Anthropic Consoleで認証する形を取ると、Claude Code用のワークスペースが自動作成され、利用量やコスト管理の単位として機能します。
チャットUIでの会話履歴とは違い、開発作業の文脈、ツール利用結果、再開可能なセッションが積み上がる設計なので、「ただ会話するClaude」ではなく「作業環境の中で動くClaude」と捉えると位置づけがつかみやすくなります。

対応環境

対応環境はmacOS、Windows、Linux、そしてWindows上のWSLです。
導入手順はOSごとに分かれますが、どの環境でも共通する着地点は同じで、インストール後にclaude --versionで導入を確認し、プロジェクトディレクトリでclaudeを起動します。
初回ログイン後は認証情報がシステム側に保存されるので、毎回ログインをやり直す流れにはなりません。

macOSではHomebrew経由がわかりやすい入口です。
Homebrew Caskの正式名はclaude-codeで、掲載情報ではmacOS 10.15以上が要件になっています。
ターミナルで次の順に進めれば、そのまま再現できます。

brew install --cask claude-code
claude --version

Homebrew版は自動更新ではないため、更新時は次のコマンドを使います。

brew upgrade claude-code # Homebrewでアップグレード

Windowsは二通りあります。
ひとつはネイティブ環境で動かす方法で、この場合はGit for Windowsが前提です。
もうひとつはWSL2のLinux環境で使う方法で、Bashベースの開発フローに寄せたい人にはこちらが自然です。
WindowsネイティブでWinGetを使うなら、パッケージIDはAnthropic.ClaudeCodeです。

winget install Anthropic.ClaudeCode
claude --version

WinGet版も自動更新ではないため、更新は次のコマンドになります。

winget upgrade Anthropic.ClaudeCode # Windows（winget）でアップグレード

Windowsネイティブ実行ではGit for Windowsが必要という前提を外すと、インストール自体より起動後の挙動で詰まりやすくなります。
前のセクションでも触れた通り、Windowsはここだけ先にそろえておくと流れが止まりません。

LinuxとWSLでは、現行の公式案内に沿ってネイティブインストールを使うのが筋です。
古い記事ではnpmのグローバルインストールを前提にした説明が残っていますが、いまの公式はネイティブインストールを中心に置いています。
導入後の確認コマンドだけを共通項として押さえておきます。

claude --version

Windowsネイティブの前提条件に加えて、WSL 1では機能制限があることや、Alpineのようなmusl系環境では追加ライブラリが必要になることも触れられています。
Ubuntu系のWSL2や一般的なLinuxディストリビューションで始めると、余計な分岐が少なく進めやすいのが利点です。
インストールと認証、設定まわりで引っかかったときは、起動後の/doctorで診断情報を見られます。

Claude Code をセットアップする - Claude Code Docs

開発マシンに Claude Code をインストール、認証し、使用を開始します。

code.claude.com

Cursorとの違い

CursorはVS Code系IDEの画面の中で、編集中のファイルを見ながら対話的に直していく体験に強みがあります。
差分を視覚的に確認しながら補完や修正を受ける流れは、GUI中心で作業したい人に噛み合います。
対してClaude CodeはCLI中心で、プロジェクトを横断して調べ、複数ファイルをまたいで変更し、必要ならテストやGit操作までつないで進める役割が目立ちます。

この違いは、どちらが上というより、どこを作業の中心に置くかの違いです。
たとえば「いま開いているReactコンポーネントのUIだけを会話しながら整える」ならCursorのほうが手に馴染みやすく、「既存リポジトリ全体を読ませて関連ファイルを洗い出し、修正して、テスト結果まで見たい」ならClaude Codeの流れが合います。
CLI中心というと構えたくなりますが、実際にはclaudeで起動して会話を始めるだけなので、ターミナルに拒否感がなければ入り口はそこまで遠くありません。

Claude CodeはIDEやブラウザにも対応していますが、製品の個性がいちばんよく出るのはやはりCLIです。
複数ファイル横断、自律的な作業の段取り、コマンド実行の承認フローまで含めて体験すると、「チャットAIの延長」ではなく「開発環境に入って働くツール」だと掴めます。
OS別の手順をこれから進めるうえでも、この前提を持っておくと、macOSでもWindowsでもWSLでも操作の意味が見えやすくなります。

インストール前に確認する前提条件

アカウント準備

Claude Codeを使い始める前にそろえるものは、CLI本体そのものより先に認証に使うアカウントです。
必要なのは、Claudeのサブスクリプション、またはAnthropic Consoleのアカウントのどちらかです。
前者はClaude ProClaude MaxTeamのような契約形態で使う入口、後者はAPI利用を前提にした入口と考えると整理しやすくなります。
Claude Code の。

実際に初回起動まで進めると、インストールよりも先に「どのアカウントで使うのか」が曖昧だと手が止まりやすいんですよね。
個人でまず触るならサブスクリプション、既存の開発運用でAPI課金や利用量管理を分けたいならAnthropic Consoleという切り分けだと迷いが減ります。
Anthropic Consoleで認証した場合はワークスペースが自動で作られ、使用量やコスト管理の単位もそこにまとまります。

なお、初回ログイン後の認証情報はシステムに保存されるため、毎回サインインを繰り返す流れにはなりません。
アカウントを切り替える場面では claude 起動後に /login を使います。
インストール作業そのものは数分でも、ここが未整理だと認証の段階で足踏みしやすいので、先に前提として押さえておくと流れが途切れません。

Windowsで必要なもの

Windowsでいちばん詰まりやすい前提は、ネイティブ実行ではGit for Windowsが必須という点です。
ここでいうネイティブ実行は、WSLではなくWindows側のPowerShellやGit Bashからそのまま claude を動かす形です。
Git for Windowsを入れるとGit Bashも一緒に使えるので、Unix系のコマンド感覚に寄せたい人にも都合が合います。

筆者も最初にここで引っかかりました。
WinGetで本体だけ入れて claude を起動しようとしても先へ進まず、「インストールは通ったのに動かない」状態になったのですが、Git for Windowsを入れた直後にそのまま解決しました。
Windowsではアプリ本体の導入だけで完了した気になりやすいものの、実際にはシェル周りの前提がそろって初めて起動ラインに乗ります。

Windowsで選び方を整理すると、次のようになります。

• macOSはHomebrewが簡便
• WindowsはWinGetが簡便。ただしGit for Windowsは別途必要
• Linux/WSLは配布形態と依存パッケージを公式セットアップで確認しながら進める

Windows環境でCLIに慣れていても、PowerShell中心でいくのか、Git Bash中心でいくのかを先に決めておくと後の手順がぶれません。
どちらを使ってもよいのですが、公式要件として必要なのはGit for Windowsです。

WSL/Linuxの追加依存

Windowsでは、ネイティブ実行だけでなくWSLを使う選択肢もあります。
WSLはWindows Subsystem for Linuxの略で、Windows上でLinux環境を動かす仕組みです。
Node.jsやPythonの開発環境をすでにLinux側へ寄せているなら、Claude Codeもその流れに載せるほうが自然です。

その場合に気を付けたいのが、基本はWSL 2推奨という点です。
WSL 1はI/Oや一部連携に制約があり、Bashベースのツール実行や周辺機能まで含めた運用で詰まりやすくなります。
コードを読むだけなら動いても、実際の開発では検索、編集、コマンド実行が連続するので、この差が効いてきます。
WindowsホストとLinux側をまたいで作業するときも、WSL 2のほうが開発フローを崩しにくいと感じます。

Linuxでは、ディストリビューションによって追加依存が必要です。
特にAlpine Linuxのようなmusl系では、libgcc、libstdc++、ripgrep を先に入れる前提があります。
検索機能まわりで組み込みの ripgrep が合わない場合は、USE_BUILTIN_RIPGREP=0 を使ってシステム側の ripgrep を参照する案内も公式にあります。
ここは一般的なUbuntu系の感覚で進めると見落としやすい部分です。

Linux全般では、インストーラー本体の配布方法と依存パッケージの扱いがmacOSやWindowsより環境差として表れやすいので、ここだけはClaude Code をセットアップするの記載に沿って読む意味があります。
とくにWSL経由で使う場合は、Windows側ではなくLinux側の環境として考えると整理しやすくなります。

導入時に見落とされがちなのが更新方式です。
配布チャネルによってアップデートの扱いは異なります。
一般に、デスクトップ向けのネイティブ配布ではアプリ内自動更新機能を持つことがある一方、Homebrew や WinGet といったパッケージ管理経路では手動アップデートが必要になることが多い、という整理で考えてください。
macOSでHomebrewから入れた場合の更新コマンドは次の通りです。

brew upgrade claude-code # パッケージを最新版に更新

WindowsでWinGetから入れた場合は次を使います。

winget upgrade Anthropic.ClaudeCode # パッケージを最新版に更新

実際に運用へ入ると、インストール直後よりも「前は動いていたのに挙動が違う」という場面のほうが切り分けに時間がかかります。
CLI系ツールは1回入れて終わりではなく、更新単位で手元の状態をそろえる前提で見たほうが混乱が少なくなります。
チーム利用なら、週1回の更新確認を運用ルールに入れておくと、古い版のまま不具合を踏む確率を下げやすいのが利点です。

npmガイドとの違い

検索で見つかる古い記事の中には、Node.js 18+を前提に npm のグローバルインストールで導入する流れが残っています。
ここは現行の公式セットアップとズレやすいポイントです。
いま基準にしたいのはnpm経由ではなく、macOSならHomebrew、WindowsならWinGet、Linux/WSLなら公式セットアップで案内されるネイティブ導入です。

この違いを意識しておくと、「Node.jsを先に入れるべきか」「npm install -g が前提なのか」で迷わずに済みます。
旧ガイドは当時の導入手段としては筋が通っていましたが、現行の公式はネイティブインストールを軸に整理されています。
いま新しく始める読者にとっては、Node.jsのバージョン管理まで先に抱え込まないぶん、導入の切り分けが単純になります。

実際に新旧ガイドを見比べると、npm方式はJavaScript開発者にはなじみがある一方で、Claude Code本体の不具合なのか、Node.js環境の問題なのかを分けて考える必要がありました。
ネイティブ導入ではこの層が1つ減るので、claude --version までの確認が短い流れで終わります。
インストール失敗を減らすという意味でも、現時点では古いnpm記事より公式のネイティブ手順を起点に読むほうが筋が良いと言えます。

Claude Codeのインストール手順

導入のゴールはOSごとに同じで、インストールが終わったらターミナルで claude --version を実行し、claude コマンドが通る状態になっていれば第一段階は完了です。
Claude Code の概要にある通り、Claude Codeはターミナル中心のツールですが、IDE、デスクトップアプリ、ブラウザにも導線があります。
ここではその入口だけ触れ、まずはCLIを確実に起動できるところまでに絞ります。

macOS

macOSではHomebrew経由がもっとも素直です。要件は macOS 10.15以上 です。インストールは次のコマンドで進めます。

brew install --cask claude-code

完了したら、そのまま導入確認を行います。

claude --version

私の環境では、インストール直後の同じターミナルでは claude が見つからず、新しくターミナルを開き直したらPATHに反映されました。
Homebrew系のCLIでたまにある挙動なので、コマンドが通らないときは再起動ではなく新規ターミナルを1枚開くほうが先です。

更新は自動ではなく、手動で次を実行します。

brew upgrade claude-code # macOS用コマンド

macOSではここまで済めば、あとは任意のプロジェクトディレクトリに移動して claude を打てば起動できます。
VS Code連携やデスクトップアプリ側から使う流れもありますが、最初の切り分けはCLI単体のほうが短く済みます。

claude-code

Homebrew’s package index

formulae.brew.sh

Windows

Windowsでネイティブに入れるなら、WinGetの手順がいちばん再現しやすい流れです。インストールコマンドは次の通りです。

winget install Anthropic.ClaudeCode

導入後はバージョン確認を行います。

claude --version

Windowsネイティブで押さえておきたい前提は、Git for Windowsが必要という点です。
この条件が示されており、Git関連の実行環境がない状態では詰まりやすくなります。
実際に使った感触では、PowerShellでも動くものの、grep や pwd のようなUnix系の流れを混ぜる場面ではGit Bashのほうが自然につながりました。
既存の開発メモやシェルスクリプトを流用するなら、この差は早い段階で出ます。

更新コマンドは次です。

winget upgrade Anthropic.ClaudeCode # Windows用コマンド

Windowsでもインストール後の確認地点は同じで、claude --version が返れば次の初回認証へ進めます。
認証後は資格情報が保存されるので、毎回ログインを繰り返す流れにはなりません。

WindowsネイティブとWSLの選び方

Windowsで迷いやすいのは、ネイティブ実行とWSL 2のどちらに寄せるかです。
判断軸はシンプルで、日常的にどのシェルとツール群で作業しているかを見ると整理できます。

Git Bashを中心に、Windows側のフォルダをそのまま触りながら使いたいなら、まずはWindowsネイティブで十分です。
Git for Windowsを入れてWinGetでClaude Codeを導入すれば、セットアップは短く終わります。
フロントエンドの軽い修正、既存Gitリポジトリの確認、単発のコードレビューなら、この構成でも詰まりません。

一方で、普段からPython、Node.js、Docker、Linux系のCLIをWSL側に寄せているなら、Claude CodeもWSLへ置いたほうが流れが揃います。
シェル、パス、依存パッケージの置き場所が1か所にまとまるので、WindowsホストとLinuxゲストを行き来して混乱する場面が減ります。
前のセクションでも触れた通り、この用途では WSL 2推奨 です。

迷ったときは、「Git Bashで完結する運用か」「Linux前提の開発フローへ寄せたいか」で決めるとぶれません。
前者ならネイティブ、後者ならWSLという分け方が実務では収まりがいいです。

WSL/Linux

WSLとLinuxでは、ディストリビューションごとに前提パッケージや導入コマンドが変わります。
このため、ここだけは固定の1行インストーラーを貼るより、Claude Code をセットアップするのディストリ別案内に沿って進めるほうが正確です。
Ubuntu系、Debian系、Fedora系で必要なコマンドは同一ではありません。

共通のゴールは同じで、セットアップ完了後にLinux側のシェルで次を実行して確認します。

claude --version

WSLで使う場合も、考え方は「Windows上のツール」ではなく「Linux環境のツール」です。
claude --version もWindowsのPowerShellではなく、UbuntuなどWSL側のターミナルで確認すると切り分けがぶれません。

Alpine Linuxのようなmusl系では追加依存があり、libgcc、libstdc++、ripgrep の導入が前提になります。
さらに、組み込みの ripgrep ではなくシステム側の ripgrep を使うために USE_BUILTIN_RIPGREP=0 の指定が案内されることがあります。
ここはUbuntu系の感覚でそのまま進めると止まりやすい箇所です。
逆に言えば、この3点を先に揃えると切り分けの順番が明確になります。

Linux側で claude --version まで通れば、あとは対象プロジェクトのディレクトリに移動して claude を起動する流れです。
IDEやブラウザから入る使い方もありますが、導入直後はCLIで本体が動いている状態を先に作っておくと、その後の連携設定も追いやすくなります。

初回起動から認証まで

プロジェクトでのclaude起動

インストール確認まで終わったら、次は作業したいリポジトリや任意のプロジェクトディレクトリへ移動し、その場所で claude を実行します。
ここがClaude Codeの基本動線で、どのフォルダを文脈として読み込ませるかを最初に決める操作でもあります。
単にターミナルを開いて起動するのではなく、今から触るコードが置かれている場所で起動すると考えると迷いません。

claude

たとえば ~/work/my-app のようなアプリのルートで起動すれば、そのディレクトリを前提にClaude Codeが会話を始めます。
実際、この起動位置がずれていると、意図したファイルが見つからない、別の階層を前提に返答される、といった初手の混乱につながります。

初回起動時は、いきなり空の入力欄だけが出るのではなく、最初の質問例やサンプルコマンドのヒントが表示されます。
私が最初に触ったときも「まず何を打てばいいのか」が画面上に置かれていて、/help に自然に目線が流れる構成でした。
CLIに慣れていても、最初の1手が見えるだけで心理的な抵抗がぐっと下がります。

Quickstart - Claude Code Docs

Welcome to Claude Code!

code.claude.com

ブラウザ認証とセッション保存

claude の初回起動後は、ブラウザが開いて認証フローに進みます。
ここではClaudeのサブスクリプション、またはAnthropic Consoleのアカウントでログインして認証を完了します。
ターミナルの中だけで完結するのではなく、一度ブラウザへ渡して本人確認を終える形です。

認証が通ると、その資格情報はローカルに保存されます。
以後は毎回ブラウザへ戻ってログインし直す必要はありません。
日常的に使う道具として定着しやすいのはこの点で、朝にターミナルを開いて claude を叩けば、そのまま前回の続きに入れます。
別アカウントへ切り替えたいときだけ /login を使う、という理解で足ります。

起動直後の画面は、ターミナルの中に会話用のワークスペースが立ち上がるイメージです。
下部にはプロンプト入力欄があり、そこに自然文で依頼を書きます。
上側には会話の履歴が並び、どのファイルを見たか、どの提案を返したか、どのツール呼び出しが走ったかが追える構成です。
GUIのチャットツールほど装飾は多くありませんが、開発作業に必要な情報は一通り見える作りになっています。
さらに、Claude Codeはファイル編集やコマンド実行の前に承認ダイアログを出す場面があります。
たとえばシェルコマンドを実行する前に「この操作を許可するか」を確認する流れで、勢いで危ないコマンドが走る形にはなりません。
なお、料金情報を本文で参照する場合は公式の Pricing ページを必ず確認してください（確認日: 2026-03-18）。
会話やツール実行結果はローカルにも保存されるため、途中でターミナルを閉じても履歴が消えません。
単発の質問ツールではなく、作業中の文脈を持ったまま戻ってこられる開発用ワークスペースとして見ると挙動がつかみやすくなります。
会話履歴の保存、再開、巻き戻し、フォークといった流れが前提になっています。

/helpと/resumeの使いどころ

最初のうちは、通常の自然文プロンプトよりもスラッシュコマンドの存在を早めに掴んでおくと進みが安定します。
まず開いておきたいのが /help です。
入力すると、利用できるコマンド一覧や基本操作がまとまって表示されます。
初回起動時のヒントからそのまま /help へ誘導されるので、ここを起点にすると「何ができるか」を把握しやすい構成になっています。

/help

もうひとつ序盤で役立つのが /resume です。
これは過去の会話を再開するためのコマンドで、前回の作業文脈を引き継ぎたいときに使います。
たとえば昨日の続きでバグ修正に戻る、午前中のレビュー会話を夕方に引き継ぐ、といった場面で効きます。
単に履歴を眺めるのではなく、その会話セッションへ戻る という感覚に近いです。

/resume

この2つを知っているだけで、初回起動後の迷い方がだいぶ変わります。
コマンド一覧を見て全体像を掴むのが /help、前回の流れを取り戻すのが /resume です。
もし認証や設定まわりで引っかかった場合は、ここに /doctor も加わりますが、まずは /help と /resume が入口として機能します。
初日の段階でこの動線が見えていると、毎回ゼロから説明し直す使い方にならず、会話の蓄積をそのまま開発に乗せられます。

最初に試す基本操作

コードベースの把握

インストール直後にまず試したいのは、いきなり実装を任せることではなく、いま開いているリポジトリをどう読んでくれるかを見ることです。
Claude Codeはターミナル中心のツールですが、単発の質問箱というより、プロジェクト全体を読んだうえで会話を組み立てる作りになっています。
『Quickstart』でも、プロジェクトディレクトリで起動して文脈を持たせる流れが前提になっています。

最初の一手として相性がいいのは、「このリポジトリの構成を説明して」「主要なエントリポイントと依存関係を図解して」といった把握系の依頼です。
ここで見たいのは説明のうまさだけではなく、どのディレクトリを見に行き、どの設定ファイルを根拠にして話しているかです。
たとえばNext.jsなら app や pages、package.json、next.config.js まわりを見に行くか、Railsなら config/routes.rb や app/models、app/controllers に触れるかで、読み取りの方向性がつかめます。

私が最初に試すときも、まずは実装依頼ではなく「入口を言葉にしてもらう」使い方から入ります。
これをやっておくと、以降の会話で「どこを触る話なのか」が共有されるので、いきなり見当違いのファイルを編集する流れを減らせます。
説明が粗いと感じたら、「バックエンドとフロントエンドを分けて整理して」「テストディレクトリの役割も含めて」と掘り下げれば、そのプロジェクトで必要な粒度に寄せられます。

バグ修正の依頼

コードベースの把握が済んだら、次に試す価値が高いのが小さめの不具合修正です。
依頼文は曖昧な相談より、Issueや再現条件を渡したほうが精度が上がります。
たとえば「このIssueを再現して、原因の候補と修正パッチを提案して」「変更後のテストを実行して確認して」と頼むと、調査から修正、確認までをひとつの流れで扱えます。

ここで便利なのは、いきなりコードを書かせるより先に、再現手順と原因候補を出してもらうことです。
再現できるなら、どの条件で壊れるのかが明確になりますし、再現できないなら、ログ不足や前提条件の欠落も早めに見えてきます。
Claude Codeはファイル変更やコマンド実行の前に承認フローが出るので、その場で差分や実行内容を見ながら進められます。
バグ修正の初回は、この確認画面を通して「何を変えようとしているのか」を読むだけでも学びがあります。

実際には、原因を一発で当てるというより、候補を並べて絞り込む進め方のほうが安定します。
「状態管理の更新漏れか、非同期処理の競合か、バリデーション抜けか」のように仮説が整理されるだけでも、手作業で調べる範囲が狭まります。
修正パッチも、いきなり全面改修ではなく、まず最小差分の案を出させるとレビューしやすくなります。

テスト実行の依頼

導入直後にもうひとつ試しておきたいのが、テストまわりの会話です。
実装より先に「このプロジェクトのテストコマンドを探して実行して」「失敗テストのログを要約して対処方針を出して」と頼むと、そのリポジトリで何が正解の実行手順なのかを掴めます。
package.json の scripts、Makefile、pytest、go test、cargo test のような入口を見つけに行く動きが見えるので、単に質問へ答えるだけでなく、作業者として振る舞えるかを確認できます。

この段階で役立つのは、失敗ログの要約です。
テストが落ちたとき、人間はログ全文を追う前に「どの層で壊れているのか」を知りたくなります。
Claude Codeに要約させると、依存関係の欠落、スナップショット差分、環境変数不足、想定外の戻り値といった論点に圧縮して返してくれるので、次に打つ手が見えます。
ログを眺める作業を丸ごと省くというより、読む順番を整えてくれる感覚です。

私の感覚では、ここで一度テストコマンドを正しく特定できると、その後の会話が安定します。
逆に、テストの入口が曖昧なままだと、修正提案はもっともらしく見えても確認方法がぶれます。
実装依頼の前に「何で検証するか」を共有しておくと、レビューの会話までつながりやすくなります。

/initでの初期化とCLAUDE.md

日常運用に入る前に触っておきたいのが /init です。
これはプロジェクト固有の文脈をまとめる CLAUDE.md の作成を支援するコマンドで、『Claude Code の仕組み』でも、プロジェクトごとのルールを持たせる中心として扱われています。
ここを空のまま使い続けることもできますが、プロジェクトの規約が定まっているなら、早い段階で書いておくほうが会話のブレが減ります。

CLAUDE.md に入れておく内容は、抽象論より運用情報が向いています。
たとえばコーディング規約、テストコマンド、Lintの実行方法、レビューで見てほしい観点、触ってはいけないディレクトリ、コミット前に満たす条件といった項目です。
人間同士なら暗黙知で済むことも、エージェント相手では明文化したほうが速くなります。

私自身、/init のあとに CLAUDE.md へテスト手順を書き込んでから、以降の「テストして」という一言の通り方が変わりました。
以前は候補コマンドを探すところから始まっていたのに、手順を明記してからは承認前の提案内容が最初から具体的になり、どの順序で何を回すのかまで揃って返ってくることが増えました。
会話のたびに前提を説明し直さなくて済むので、短い依頼でも実務の速度に近づきます。

CLAUDE.md は一度作って終わりではなく、運用しながら育てる前提で見ると扱いやすくなります。
新しいテストコマンドが増えた、レビューで毎回同じ指摘が出る、マイグレーションの扱いに決まりがある、といった情報を追加していくと、次の提案の質にそのまま返ってきます。
Claude Codeを入れた直後の基本操作としては、コードを読ませる、バグを直させる、テストを回させる、そして /init でプロジェクトの前提を固定する、この4つを通すだけで「入れただけ」の状態から抜け出せます。

Claude Code の仕組み - Claude Code Docs

agentic ループ、組み込みツール、Claude Code がプロジェクトとどのように相互作用するかを理解します。

code.claude.com

初心者向けの初期設定とCLAUDE.md

CLAUDE.mdの役割

Claude Codeを触り始めたばかりの段階で効くのが、CLAUDE.md を早めに置くことです。
これは単なるメモではなく、そのリポジトリ固有の前提をClaude Codeへ渡す共有ファイルです。
会話のたびに毎回説明していた内容を固定化する役割を持ちます。

初心者のうちは「毎回プロンプトで説明すれば足りるのでは」と感じがちですが、実務では同じ前提を何度も言い直す場面が続きます。
たとえば「このプロジェクトは pnpm を使う」「テストは npm test ではなく pnpm test:unit と pnpm test:e2e を順に回す」「UI コンポーネントは既存の命名規則に合わせる」といった情報です。
こうした文脈が CLAUDE.md にまとまっていると、依頼文を短くしても出力の方向がぶれにくくなります。

私が特に効いたと感じたのは、ブランチ命名規則を書いたときです。
feature/issue-123-短い説明 のような形を CLAUDE.md に明記してから、提案PR向けのブランチ名が最初からその規約に沿って出てくることが増えました。
人間ならレビューで直せる小さなズレでも、エージェント相手では先にルール化しておいたほうが往復が減ります。
CLAUDE.md は「うまく伝えるコツ」ではなく、「毎回ぶつかる小さなズレを先回りで消す設定ファイル」と考えると位置づけがはっきりします。

書くと良い項目の例

CLAUDE.md に入れる内容は、抽象的な開発哲学より、作業判断に直結する情報のほうが向いています。
初心者向けの最小構成なら、まずは「このリポジトリは何をするものか」「どのコマンドで依存を入れるか」「何を実行すればテスト完了とみなすか」の3点だけでも十分です。
ここにコーディング規約やブランチ命名規則まで入ると、実装提案、修正方針、PR用の作業単位まで一貫しやすくなります。

たとえば、次のような項目が入っていると会話が安定します。

• プロジェクトの目的
• 依存関係のインストール方法
• 開発サーバーの起動コマンド
• テストコマンド
• Lint や Format の実行コマンド
• コーディング規約
• ブランチ命名規則
• CI の有無と、通すべきチェック

Markdown で書くなら、最小構成はこのくらいで足ります。

# CLAUDE.md

## このプロジェクトについて
社内向けの在庫管理Webアプリです。
フロントエンドは React、バックエンドは Node.js です。

## セットアップ
依存インストールは `pnpm install` を使います。
開発サーバーは `pnpm dev` で起動します。

## テスト
単体テストは `pnpm test:unit`
E2E テストは `pnpm test:e2e`

## ルール
既存コンポーネントの命名に合わせること。
大きなリファクタリングより、最小差分の修正を優先すること。

実務で使うなら、もう一段具体化した推奨構成のほうが役に立ちます。
どのファイルを触ってよいか、どの順番で検証するか、ブランチをどう切るかまで書いてあると、提案の精度が上がります。

# CLAUDE.md

## 目的
このリポジトリは EC サイトの注文管理機能を提供します。
主な変更対象は `apps/admin` 配下です。

## 環境構築
依存インストールは `pnpm install`
ローカル起動は `pnpm dev`

## テストと検証
変更前に `pnpm lint` を確認
単体テストは `pnpm test:unit`
統合確認は `pnpm test:integration`
変更後は関係するテストを優先して実行する

## コーディング規約
TypeScript では `any` を避ける
既存の ESLint / Prettier 設定を崩さない
UI 文言は日本語で統一する
関数は短く保ち、副作用を分離する

## ブランチ運用
ブランチ名は `feature/issue-123-短い説明`
バグ修正は `fix/issue-123-短い説明`

## CI
GitHub Actions で lint と test が動く
CI が落ちる変更は提案時点で理由を説明する

## 注意点
`migrations` 配下は明示的な依頼がない限り触らない
本番用の環境変数名は追加・変更しない

この手のファイルは、完璧に埋めてから使い始めるものではありません。
私の感覚では、最初は5行でも効果が出ます。
テストコマンド、規約、ブランチ命名の3つが入るだけで、修正提案の粒度が揃いやすくなりますし、依頼する側も「どこまで書いてあるか」を基準にプロンプトを短くできます。
最小構成で置いておき、会話で毎回補足していることを後から足していく運用のほうが続きます。

MCPの位置づけ

MCPはModel Context Protocolの略で、Claude Codeが外部ツールや追加のコンテキストとつながるための仕組みとして扱われます。
初心者の段階では、まず CLAUDE.md でプロジェクト内のルールを整理するほうが先です。
ローカルの文脈共有だけで足りる場面が多く、最初から接続先を増やさなくても運用は回ります。

位置づけとしては、CLAUDE.md が「このリポジトリの基本ルールを固定するファイル」、MCPが「必要になったら外部の情報源やツール連携を増やす拡張口」です。
たとえば、社内ドキュメント、課題管理、独自API、設計情報の取得元をつなげたくなった段階で効いてきます。
つまり、日常の実装ルールを覚えさせる用途は CLAUDE.md、その外側のシステムと連携する用途はMCPという切り分けで考えると混乱しません。

Claude Code の概要とQuickstartの流れを見ると、使い始めの中心はあくまで起動、認証、対話、そしてプロジェクト文脈の固定です。
MCP はその先で伸ばしていくための仕組みとして捉えると収まりが良く、導入直後から抱える情報量も増えすぎません。
初心者にとっては、まず CLAUDE.md を置いて出力を安定させ、そのあとで「外部の何を読ませたいか」が見えてきた時点でMCPを足す順番のほうが、作業の意味がはっきり見えます。

よくあるエラーと対処法

コマンドが見つからない

claude: command not found で止まると、最初のつまずきとしては一番つらいところです。
ここは設定を深読みするより、順番に切り分けると早く抜けられます。
まず見るのは、そもそもインストール自体が完了しているかどうかです。
macOS でHomebrewを使ったなら brew list | grep claude-code、Windows でWinGetを使ったなら winget list Claude のように、パッケージ一覧に入っているかを確認すると現在地がはっきりします。

インストール済みなのに claude だけ見つからない場合は、PATH がまだ反映されていないことが多いです。
ターミナルを入れ直した直後は、いま開いているシェルが古い環境変数を握ったままになっていることがあります。
新しくターミナルを開き直すだけで通るケースは珍しくありません。
私もHomebrew更新直後に古いパスが優先されたことがあり、そのときは新規シェルを開き直すか hash -r でコマンドキャッシュを捨てると解消しました。
見た目は同じ claude でも、シェル側が古い場所を覚えているだけということがあります。

それでも解決しないときは、which claude でどの実体を見に行っているかを確認します。
ここで想定外の場所が返るなら、過去に入れた別バージョンや旧方式の残骸と衝突している可能性があります。
OS ごとの導入経路が整理されていますが、現行はネイティブ寄りの導入が前提なので、古い npm グローバル版の名残があると混線しやすい印象です。
which claude の結果が一つに定まる状態まで整えると、その後の更新でも詰まりにくくなります。

更新が反映されない

更新コマンドを実行したのにバージョンが変わらない、というのもよくある詰まり方です。
Claude CodeはHomebrew版とWinGet版では自動更新ではなく、手動アップデートの運用になります。
Windows なら winget upgrade Anthropic.ClaudeCode、macOS なら brew upgrade claude-code を実行するのが基本です。

ただ、更新コマンドが成功しても、そのまま同じシェルで claude --version を叩くと古い実体を見続けることがあります。
ここでも効くのはシェルの再起動です。
macOS では hash -r が効く場面もあり、私の環境ではこれで新しいバイナリに切り替わりました。
更新そのものより、更新後にどのパスを掴んでいるかのほうが原因になりやすい、という感覚です。

もう一つ多いのが複数バージョンの衝突です。
which claude で意図したパスが返っているかを見て、古い配置先が先に来ていないかを洗います。
Windows でも同じで、winget upgrade Anthropic.ClaudeCode のあとにターミナルを開き直さないまま確認すると、更新前の状態に見えることがあります。
更新済みなのに反映されないときは、更新失敗よりも、シェル再読込とパス衝突の二つを疑うほうが近道です。

権限確認まわり

使い始めの段階で権限確認が多く感じるのは自然です。
ファイル編集、コマンド実行、Git 操作のたびに確認が入るので、テンポが削られたように見えますが、初期フェーズではこの挙動のほうが安全です。
どこまでを任せ、どこからを人が見るかの境界を掴むまでは、確認が多い状態のほうが事故を防げます。

そのため、--dangerously-skip-permissions を常用前提で考えるのは避けたほうが無難です。
名前の通り、権限確認を飛ばす代わりに見落としの余地も増えます。
特に導入直後は、提案された差分と実行しようとしているコマンドを都度見ながら進める運用のほうが、ツールの癖を短時間で把握できます。
私も最初は少し煩雑に感じましたが、提案差分を見て「この範囲なら任せられる」「この操作は自分で判断したい」が分かれてくると、確認の意味が見えてきました。

権限確認が多いこと自体を不具合と見なすより、最初の数回は安全側に倒しておく、という捉え方のほうが実務には合います。
とくに既存プロジェクトでは、生成されたコードの質より「どのファイルを触ったか」「何を実行したか」のほうが後から効いてきます。

WindowsのGit Bashトラブル

Windows で詰まりやすい場所として目立つのがGit Bashまわりです。
Claude Codeは Windows ネイティブ実行時にGit for Windowsを前提にしているので、まずはその導入有無が起点になります。
ターミナル中心のツールとして整理されていますが、Windows ではその土台にGit for Windowsが必要です。

実際には、インストール済みでもGit Bash側の PATH や権限周りで止まることがあります。
claude が見つからない、起動してもシェル連携が不安定、認証画面の遷移が噛み合わない、といった症状はこの周辺に集まりがちです。
ここで消耗するくらいなら、最初からPowerShellかWSL 2へ寄せたほうが素直に動くこともあります。
私も Windows 11 ではGit Bashで通るケースと、同じ手順でもPowerShellのほうがすんなり進むケースがありました。
CLI ツールの相性というより、シェルごとの前提差を踏んだ形です。

WSL を使っていて動作が落ち着かない場合は、WSL 1 のままになっていないかも見どころです。
ファイルシステム連携や実行周りで扱いづらさが残るので、WSL 2 へ移しておくと整理しやすくなります。
移行は Windows 公式の WSL ガイドに沿って、対象ディストリビューションのバージョン確認と変換を進める流れです。
ここは細かな小技より、基盤を WSL 2 に揃えるほうが効きます。

Claude Code の概要 - Claude Code Docs

Claude Code は agentic coding ツールで、コードベースを読み取り、ファイルを編集し、コマンドを実行し、開発ツールと統合します。ターミナル、IDE、デスクトップアプリ、ブラウザで利用できます。

code.claude.com

/doctorでの自己診断

自力で原因を追いきれないときに頼れるのが /doctor です。
これはインストール、認証、設定の一般的な問題をまとめて診断するためのコマンドで、導入直後ほど価値があります。
起動後に /doctor と入力するだけで走るので、「何から見ればいいか分からない」状態でも最初の足場になります。

見方はそれほど難しくありません。
項目ごとに状態が並ぶので、赤く出ている箇所を優先して追えば十分です。
イメージとしては、正常な項目は通過、赤字の項目は要対応、という読み方で問題ありません。
インストール経路の不整合、認証の未完了、設定の欠落があると、この画面で輪郭が見えます。
とくに claude が起動はするのに挙動がおかしい場面では、闇雲に再インストールするより /doctor を一度通したほうが早いです。

たとえば、初回認証が終わったつもりでも保存状態が噛み合っていないケースや、シェル側の設定が中途半端なケースでは、症状だけを見ると原因が散って見えます。
/doctor はその散らばった候補を一度並べ直してくれるので、導入直後の離脱を防ぐ道具としてよくできています。
私も原因が PATH なのか認証なのか判別しづらいときは、まずこれで全体像を見てから手を動かすようになりました。

料金と運用の考え方

Pro/Max/APIの違い

個人/小規模での始め方

個人開発で最初の一手を決めるなら、いちばん迷いが少ないのはClaude Proから入る形です。
月額 $20 で固定費として扱えるので、CLIに慣れる段階で「今日はどれだけ使ったか」を毎回気にせず試せます。
とくにインストール直後は、プロンプトの書き方を変えたり、テストを何度かやり直したり、権限確認を挟みながら作業の流れを掴む時間が発生します。
この時期は、従量課金より固定料金のほうが頭を使う場所を減らせます。

一方で、すでにAnthropic Consoleのアカウントを持っていて、普段からAPIを触っているなら、そのままAPIで始める流れも自然です。
小規模な検証、たとえば既存リポジトリで一度だけリファクタ案を見たい、テストコード生成を数回試したい、といった場面では従量課金のほうが無駄がありません。
毎日触るわけではない段階なら、固定費より従量のほうが実態に近いからです。

判断軸を一つに絞るなら、検証はAPI、日常運用はProという分け方が実務に合います。
公式の Pricing ページ（確認日: 2026-03-18）を参照すると、プランや料金の案内が掲載されています。
利用実態に応じて、API（従量）とPro（固定）のどちらを主に使うかを決めるのが現実的です。
固定料金と平均コストの違いも、ここで整理しておくとぶれません。
たとえばAPIの平均 $6/日 を30日で見ると、月額では $180前後 の感覚になります。
毎日がっつり使うなら、Claude Proの $20/月 や年払いの $17/月相当 は、コストの読みやすさという面で強いです。
反対に、週に数回の検証しか行わないなら、平均値を月額換算して比べるより、実際の利用日数で考えたほうが現実に合います。
固定費は予算管理に向き、従量課金は利用密度に合う、という役割分担です。

運用面では、作業単位を小さく切るだけでもコストの荒れ方が変わります。
1つの会話で設計相談から実装、テスト、追加修正まで全部つなげると文脈が肥大化し、APIではそのまま請求に反映されます。
逆に、設計、実装、検証を会話ごとに分けると、何にどれだけ使ったかが見えます。
/stats を見るときも、作業の区切りがあるほうが読み取りやすく、次回の見積もりにも転用できます。

更新手順と確認コマンドまとめ

更新の考え方

更新まわりで押さえる点はシンプルで、ネイティブ版は自動更新、Homebrew版とWinGet版は手動更新です。
インストール時の違いより、日常運用ではこの差のほうが効いてきます。
最初に入れたときの手順を覚えていても、数週間後には古いバイナリのまま使い続けていた、というズレが起きるのはたいてい手動更新の経路です。

私自身、macOSでHomebrew管理にしている環境では、新機能を試したいときよりも、想定外の挙動が出たときに先に更新状況を見る流れが定着しました。
Windowsでも同じで、WinGetで winget upgrade を通したあと、古いセッションがそのまま残っていて挙動が落ち着かなかったことがあります。
このときはターミナルを閉じて立ち上げ直すだけで安定したので、更新後に再起動まで含めて1セットと考えるほうが実務に合います。

更新できたかどうかは、感覚ではなく claude --version で見るのが確実です。
加えて、コマンドがどの場所の実行ファイルを向いているかを which claude で確認すると、古い経路を踏んでいないか切り分けられます。

OS別の更新・確認コマンド一覧

日常的に使うのは、更新、バージョン確認、経路確認の3点です。
コマンド名は細部を間違えるとそのまま失敗するので、brew upgrade claude-code、winget upgrade Anthropic.ClaudeCode、claude --version の表記でそろえておくとぶれません。

表の見方としては、自動更新か手動更新かと、いま実行している claude がどこにあるかの2軸で整理すると迷いません。
とくにmacOSでHomebrew版を使っていると、システム側の別経路と混ざって見えることがありますし、Windowsでは更新直後でも開きっぱなしのターミナルが古い状態を保持することがあります。
更新コマンドを打ったのに版が変わらないときは、失敗を疑う前に経路確認と再起動を見るほうが近道です。

手を動かす順番さえ決めれば、Claude Codeの立ち上がりは迷いません。
まず自分のOSで入れて、claude --version で通りを確認し、プロジェクトルートで claude を起動して /help と /init まで進めてください。

今日やることチェックリスト

• 自分のOSでインストールする
• claude --version を確認する
• プロジェクトルートで claude を起動し、/help と /init を実行する

明日以降の活用に向けて

慣れるまでは、リポジトリ理解とテスト導線の確認から始めるのが堅実です。
提案された変更はそのまま流さず、承認前に差分と実行内容を読み、危険な操作が混じる場面では修正提案かキャンセルを選ぶと、速度より先に信頼できる作業の型ができます。