Claude Codeが動かないときに確認したいポイント

Claude Codeが動かないときは、再インストールから始めず、「コマンドが起動するか」「認証が通るか」「モデルへの依頼が通るか」を分けます。止まった段階が分かれば、PATH、インストール方式、アカウント権限、ネットワークのどこを見るべきかが絞れます。まず表示されたエラー全文と直前に変えた設定を控え、下の順番で一つずつ確認してください。

まず症状を3段階に分ける

表は横にスクロールできます

症状	最初に確認するもの	いったん避けること
claude が見つからない	新しいterminal、PATH、installer	何度もinstallを重ねる
起動するがloginできない	browser callback、account、環境変数	API keyとsubscription loginを混在させる
login後にrequestが失敗	model access、provider、network、利用枠	エラーだけを見て再installする

この表は診断の入口です。同じエラー文でもOS、shell、直接利用かクラウドprovider経由かで原因は変わります。エラー全文、OS、shell、Claude Codeのversion、install方式、接続経路を一緒に記録すると、次の切り分けに使えます。API keyやtokenを含む出力を共有する場合は、必ず値を伏せてください。

コマンドが見つからないとき

「command not found」「認識されません」と出るなら、installが完了したかと、実行ファイルの場所がshellのPATHに含まれるかを分けます。install直後ならterminalを一度閉じて新しく開き、claude --versionを試します。バージョンが表示されれば起動経路は通っています。表示されない場合は、現在のshellがzsh、bash、PowerShellのどれかを確認し、そのshellが読む設定ファイルにinstall先が追加されているかを調べます。

native installerは現在、公式が推奨する方法です。macOS/Linuxではユーザー領域へlauncherを配置するため、別ユーザーで開いたterminalやサービス実行環境からは同じPATHにならないことがあります。GUIから起動したIDEとterminalで結果が違う場合、両方の環境変数を比べてください。古いnpm global installや別の手動symlinkが残ると、意図しない実行ファイルが先に選ばれることもあります。which claude（WindowsではGet-Command claude）で解決先を確認し、複数のinstallがあるなら一つずつ整理します。

install方式とNode.jsの条件

npm版を選ぶ場合、現在の公式要件はNode.js 22以上です。以前の案内にある「18以上」をそのまま使わないでください。native installerでは同じNode.js依存を前提にしないため、Node管理に慣れていない人やNodeの更新を避けたい人には選びやすい方法です。すでにnpm運用を統一しているチームは、node -v、npm prefix -g、実際に起動したclaudeの場所を一緒に確認してください。

npmでEACCESやpermission deniedが出ても、sudoを付けて押し切るのは避けます。global packageの所有者やnpm prefixを確認し、user権限で利用できる構成に直すか、native installerへ切り替えます。sudoで作られたファイルが混在すると、後のupdateだけが失敗したり、別のユーザーでは起動できなくなったりします。まずエラーの対象pathを記録し、所有権を変更する場合はそのpathだけを対象にしてください。

認証で止まるとき

browser login後にterminalへ戻っても待機が続くなら、localhost callbackが通っているかを確認します。remote SSH、container、会社のfirewallでは、browserとClaude Codeを動かす環境が別でcallbackを受け取れないことがあります。画面にmanual code flowが示される場合は、その公式手順を使い、別のWebページへ認証codeを貼らないでください。

ANTHROPIC_API_KEYを使う構成では、起動した同じshellに変数が渡っているか、keyの利用先がClaude Codeの設定と一致しているかを確認します。subscription accountのbrowser loginとAPI billingは別の経路です。両方のcredentialが存在すると、どちらで認証されたかが分かりにくくなるので、診断中は使う経路を一つに絞ります。組織のSSOやmanaged settingsで許可されていない認証方法を選んでいる場合は、利用者側で設定を回避せず管理者へ確認します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Claude Code

  公式サイトを見るTool詳細を見る比較を見る

起動後に403・model unavailable・利用失敗が出るとき

ここまで通っているなら、installし直す前にアカウントとmodel accessを確認します。Claude.aiのFree planはClaude Code accessを含みません。対象となる有料plan、Console、またはBedrock、Google CloudのAgent Platform、Microsoft Foundryなどの対応providerを使っているかを確認してください。会社契約ではseatが割り当てられているか、provider経由ではproject、region、modelの利用許可がそろっているかが別々の確認点です。

403やmodel not availableは「Claude Codeが壊れている」とは限りません。管理者が特定modelを無効にしている、provider側のregionで対象modelが使えない、選択中のmodelへの権限がない、といったケースがあります。別modelで一時的に通るか試す場合も、障害の切り分けとして行い、組織の利用ルールを迂回する目的にしないでください。429やquota表示なら、認証やPATHではなく利用枠・rate limit・billingを確認します。

会社ネットワークだけで失敗する場合

自宅回線では動き、会社ネットワークではinstallやrequestが止まるなら、proxy、TLS inspection、DNS、許可ドメインを疑います。エラーが証明書検証なら、検証を無効化する設定を入れず、組織のCA証明書を正しく配布する手順を管理者へ確認します。HTTPS_PROXYが必要な環境では、terminal、IDE、shell scriptのどこに設定が必要かも分けて確認します。

ネットワーク障害を切り分けるときは、同じ端末、同じproject、同じaccountで、回線だけを変えた結果を記録すると判断しやすくなります。会社のsecurity policyに反するVPN回避やproxy解除はしないでください。個人回線で通ったという結果は原因候補を狭めますが、会社環境で許可された接続方法を確定するものではありません。

Bedrockなど第三者provider経由

AWS BedrockやGoogle Cloud経由の場合、Claude Codeの認証に加えてprovider側credentialを確認します。AWSなら利用profileとregion、権限が現在のshellに読み込まれているかを確認し、必要ならaws sts get-caller-identityでidentityだけを確かめます。Vertex AI等ではproject、region、application default credentials、model accessを順に見ます。認証情報そのものを記事やsupportへ貼り付けないでください。

この経路では、Anthropic direct accountの契約状態だけを見ても原因が分からないことがあります。Claude Codeの設定、provider accountの権限、cloud billing、network policyを別の層として扱います。チーム管理の環境なら、個人が変更してよい設定と管理者承認が必要な設定を区別してください。

安全な診断の進め方

1. エラー全文、発生時刻、OS、shell、version、install方式、接続providerを記録する。

2. claude --versionとclaude doctorでinstall状態を確認する。

3. PATHと複数installの有無を確認し、一度に変更する項目を一つにする。

4. 認証経路をsubscription、Console/API、第三者providerのいずれかに特定する。

5. login後の失敗ならmodel権限、利用枠、provider region、networkの順に確認する。

6. 変更した項目と結果を記録し、直らなければ元に戻せる範囲で一つ前の状態へ戻す。

claude doctorはinstallや設定ファイルの状態を確認する読み取り中心の診断コマンドです。出力を共有するときは個人path、account情報、環境変数などが含まれないか確認します。再インストールは、診断でinstall破損が示された場合に限り、既存のinstall方式とversionを確認してから行う方が安全です。

AIものさしの判断

早く直す近道は、再installを繰り返すことではなく、失敗した層を一つ特定することです。起動前ならPATHとinstall、loginならcallbackとcredential、login後ならaccount/model/provider/networkを見ます。会社環境の証明書や権限が原因なら、利用者が設定を回避せず管理者へ渡せる診断情報を整えるのが次の行動です。個別version固有の不具合は変わるため、最後に公式troubleshootingとrelease情報を照合してください。