Claude code installは、Node.jsがすでにインストールされていれば、macOSやLinuxで非常に簡単です。最も迅速なインストール方法はnpmを使用することで、これにより公式パッケージに依存し、サードパーティのスクリプトではなく、更新が保持されるため、より安定します。

結果

この設定を完了すると、端末からClaude Codeを起動し、Anthropicに認証し、プロジェクトディレクトリに接続できます。これにより、エディタープラグインを追加せずに、コードベースに基づくプロンプト、ターゲットエディット、シェル支援のワークフローを開始することができます。

このクイックスタートは、最も信頼性の高い短いパスに焦点を当てています。特定のバージョンや管理されたワークステーションイメージが必要なチームは後で追加できますが、インストール自体は公式パッケージに近い方が良いです。なぜなら、動く部品が少ないほど、オンボーディングの失敗も少なくなるからです。

前提条件

macOSまたはLinuxでサポートされたシェルを使用し、npmが利用可能な最新のNode.jsリリースをPATHにインストールしてください。サインインにはAnthropicアカウントが必要です。現在のClaudeプランの詳細は公式の料金ページで確認してください。

失敗するインストールの多くは、Claude Codeからではなく、シェルの設定から来ています。nodenpm、またはグローバルnpmバイナリがPATHに存在しないと、パッケージは正しくインストールされても、端末からは壊れているように見えることがあります。

要件 重要な理由 確認方法
Node.js + npm 公式のインストールパスはnpmを使用します。 node -vnpm -v
macOSまたはLinuxシェル Claude Codeは端末用に構築されています。 echo $SHELL
Anthropicアカウント CLIがClaudeにアクセスするためにはサインインが必要です。 公式Anthropicサイトでログイン
プロジェクトディレクトリ リポジトリ内で実行することで、ツールに有用なコンテキストを提供します。 pwdをターゲットフォルダ内で実行

ステップ1: Node.jsが欠如している場合はインストール

node -vnpm -vがすでに機能している場合はこのステップをスキップしてください。公式インストーラーまたはバージョンマネージャーからのNodeを使用することが安全です。壊れたnpmパスは、Claude Codeそのものよりも多くのインストール失敗を引き起こします。

macOSでは、多くのチームがHomebrewやnvmを使用しています。Linuxでは、バージョンマネージャーがディストリビューションパッケージよりもクリーンなことが多いです。なぜなら、ディストリビューションのリポジトリは最新のNodeリリースに遅れがちで、npmの動作が分かれてしまうことがあるからです。

確認がインストール方法よりも重要です。node -vがバージョンを返しても、npm -vが失敗した場合は、Claude Codeに触れる前にNodeを修正してください。なぜなら、公式のClaude code installパスはnpmに依存しており、壊れた二重層を同時にデバッグするメリットはありません。

ステップ2: claude code installコマンドを実行

公式パッケージはnpmでインストールされます:

npm install -g @anthropic-ai/claude-code

グローバルインストールはCLIにとって正しいデフォルトです。ローカルプロジェクトインストールはパスの摩擦を追加し、特にチームが非常に厳密にツールのバージョンを固定していない限り、何も解決しません。

ここでは多くの内部文書が過剰になることがあります。ラッパースクリプト、コピーされたバイナリ、シェルエイリアスは余分な失敗ポイントを生み出しますが、直接のnpmコマンドは真実の源を明確にし、更新を予測可能にします。

グローバルインストール中にシェルが権限エラーを投げた場合は、npmのグローバルプレフィックスを修正するか、sudoをワークフローに強制するのではなく、Nodeバージョンマネージャーを使用してください。更新のために権限が必要なCLIは、開発者のマシンでは良いデフォルトではありません。

ステップ3: バイナリがPATH上にあることを確認

次のコマンドを実行してください:

claude --version

シェルがclaudeを見つけられない場合、npmがバイナリをPATHにエクスポートされていないディレクトリにインストールした可能性があります。それはシェルの問題であり、Claudeの問題ではないため、再インストールを試みる前にnpmのグローバルbinパスを修正してください。

バイナリディレクトリがシェルに見えない場合、再インストールはほとんど役に立ちません。npmのプレフィックスとグローバルbin設定を確認し、対応するディレクトリが現在のシェル起動ファイル(.zshrc.bashrc、またはワークステーションイメージで使用されるシェル設定)によって読み込まれていることを確認してください。

新しい端末でテストすることが最も簡単なサニティチェックです。claude --versionが一つのセッションでのみ機能する場合、パスの変更は手動で適用されており、シェル設定に保持されていないことを示します。

ステップ4: 認証してプロジェクトを開く

Claude Codeに検査してほしいリポジトリに移動し、CLIを起動します:

cd /path/to/project
claude

マシンがまだサインインしていない場合、CLIが認証を求めます。ターゲットリポジトリから実行する方が、他の場所から開くよりも良いです。なぜなら、ファイルの認識は現在の作業ディレクトリに依存するからです。

ここは、インストールの品質が実際の有用性と出会う最初の場所です。間違ったディレクトリからの成功した起動は、バイナリが機能することだけを証明しますが、リポジトリ内での起動は、ツールが重要なファイルを認識できることを証明します。

認証はインストールとは別のチェックポイントとして扱うべきです。claudeが開始されてもサインインが失敗した場合、パッケージは正しくインストールされており、次の修正はアカウントアクセス、ネットワークポリシー、またはブラウザベースの認証フローに関連しています。

ステップ5: 限定されたタスクを与える

モジュールのレビュー、失敗したテストの説明、1つのファイルのリファクタリング提案など、狭いプロンプトから始めます。小さなタスクは、広範な要求「このコードベースを改善する」よりも早く権限の問題、リポジトリアクセスの問題、プロンプトの質を明らかにします。

良い最初のプロンプトは:「このリポジトリのアーキテクチャを要約し、新しいAPIエンドポイントを追加する最も安全な場所を特定してください。」これにより、リポジトリの読み取り、コードの理解、実際の出力を一度でテストできます。

限定されたプロンプトは、明確な成功条件を生み出すため、より良いです。回答がエントリーポイントを誤認識したり、テストを無視したり、ファイルを捏造したりした場合、チームはすぐにコンテキストや権限に問題があることを学びます。

広範なプロンプトは、あいまいな出力の背後に悪い設定を隠します。正確なタスクは、CLIにClaude code installが完了しているだけでなく、実際に開発者が使用するリポジトリで有用であることを証明させます。

最初に試すべきこと

Claude Codeに現在のリポジトリを検査させ、ディレクトリ、エントリーポイント、テストコマンドの短いマップを生成させます。これは、最初に編集を求めるよりも良いです。なぜなら、チームはツールが何かを書く前にコンテキストの質を確認できるからです。

例のプロンプト:「このリポジトリを読み、主要なサービス、ローカル開発コマンド、変更する際のリスクが最も高い領域をリストしてください。」

読み取り専用のオリエンテーションタスクは、安全な最初の実行です。CLIが構造、命名、開発者のワークフローをどれだけ理解しているかを明らかにします。要約がリポジトリと一致すれば、環境はパッチ提案、テスト修正、リファクタリングのような高信頼タスクに準備が整います。

これにより、チームはオンボーディングのための基本的なプロンプトを得ることができます。マシン間で同じ最初のタスクを再利用することで、問題がリポジトリ、アカウント、または特定の開発者のシェル設定に起因するかを簡単に特定できます。

よくある間違い

  • Nodeをインストールしたが、npmのグローバルbinディレクトリを公開していない。もしclaude --versionがnpmインストール後に失敗する場合、パッケージを繰り返し再インストールするのではなく、npmプレフィックスとグローバルbinの設定を確認してください。
  • 最初の修正としてsudo npm install -gを使用する。これにより、グローバルパッケージパスにroot所有のファイルが残り、後の更新が元の問題よりも難しくなることがあります。
  • リポジトリの外でClaudeを実行する。CLIは、プロジェクトが現在のディレクトリであるときに最も良く機能します。それ以外の場合、ファイル参照があいまいまたは無用になります。
  • 巨大なタスクから始める。「この全モノリスを監査する」は、設定問題を一般的な出力の背後に隠すため、良い最初のプロンプトではありません。
  • 内部文書に計画の詳細をハードコーディングする。公式のAnthropic料金ページを確認してください: https://www.anthropic.com/pricing

公式パッケージ名、コマンド、文書は変更される可能性があるため、チームのオンボーディングにこれを組み込む前に、Anthropicの文書で現在のClaude code installコマンドを確認してください。ほとんどの開発チームにとって、npmは正しいデフォルトです。なぜなら、シンプルでスクリプタブルであり、カスタムラッパーやコピーされたバイナリよりも監査が容易だからです。