claude code 動かない｜「完了しました」を信じるな——環境系と生成系の対処【2026】

「完了しました」——Claude Codeがそう返してきたとき、あなたはブラウザを開いて実際に確認しているだろうか。

claude 動かないという状態には、大きく2種類の起源がある。一方はエラーメッセージが出る環境系（起動しない・PATHが外れている・認証が通らない）、もう一方はエラーメッセージが出ない生成系（「完了した」と報告したのに実際には404が返る・同じミスを繰り返す・一箇所直すと別が壊れる）だ。

競合記事のほとんどは環境系しか扱っていない。しかし実際の運用で問題の発見が遅れ、被害が積み重なるのは後者だ。ログに何も出ないまま、完了報告だけが積み重なっていく。

本記事では両系統を切り分け、環境系には公式ドキュメントに基づく定型の対処を、生成系には実運用で確立した検証の型を具体的な手順で示す。

---

claude 動かないの第一診断——まず /doctor を叩く

環境系か生成系かを判断する前に、Claude Code自体が起動できる状態かを確認する。公式の診断コマンドは1つだ。

# Claude Code起動中なら
/doctor

# 起動すらしない場合はシェルから
claude doctor

/doctor は認証・接続・依存関係・実行環境をまとめてチェックし、問題があれば原因と修正方針を返す。まずここから始め、その出力内容で環境系か生成系かを切り分ける。それでも解決しない場合は /feedback またはGitHub Issuesへエスカレーションする。

---

環境系でclaude 動かない——PATH・認証・Linux固有の公式対処

環境系トラブルはエラーメッセージが手がかりになる。以下は公式ドキュメント（code.claude.com）に基づく対処を症状別に整理したものだ。

command not found: claude（PATHが外れている）

ネイティブ版Claude Codeは実行ファイルを ~/.local/bin/claude に配置する。シェル設定の更新などでこのディレクトリがPATHから外れると、bash: claude: command not found が出る。Linux環境ではシェル設定の更新を契機にこのトラブルが繰り返し発生しやすい。

# PATHに含まれているか確認
echo $PATH | tr ':' '\n' | grep -Fx "$HOME/.local/bin"

# 含まれていない場合——Bashなら
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# Zshなら ~/.zshrc に同様に追記

# 確認
claude --version

重複インストールが疑われる場合は which -a claude で全パスを確認し、旧npmインストール（~/.claude/local）が残っていれば整理する。権限の問題には sudo chown -R $(whoami) ~/.local で対処する。共有ライブラリ不足（Linux）は ldd "$(command -v claude)" | grep "not found" で確認できる。

認証エラー・ログインできない

# 再認証の手順
/logout
# 再起動後に claude を実行
# ブラウザが開かない場合は「c」でOAuth URLをコピー

403 Forbidden が出る場合、Proプランなら claude.ai/settings で購読が有効かを確認する。「organization disabled」と出るのに購読が有効な場合は、古い ANTHROPIC_API_KEY 環境変数が認証を上書きしている可能性が高い。

unset ANTHROPIC_API_KEY
# ~/.bashrc 等からも該当行を削除
/status  # 認証方式を確認

WSL2・SSH・コンテナ環境でOAuthのブラウザが別ホストで開く場合は、表示されるコードを端末に貼り付ける。export BROWSER=... でWindowsブラウザを指定することもできる。

Linux固有のトラブル

インストール中に Killed が出る場合はOOM（メモリ不足）だ。Claude Codeは最低4GB RAMを必要とする（公式ドキュメントより）。スワップで対処できる。

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Illegal instruction はCPUがAVX非対応の機器（概ね2013年以前や一部VM）で起きる。grep -m1 -ow avx /proc/cpuinfo が空ならAVXがない。WSL1の Exec format error はWSL2へ移行する（wsl --set-version <Distro> 2）。

起動後に高CPU・メモリが継続する場合は /compact を実行し、大タスク間で再起動する。ハング時はCtrl+C、それでも止まらなければ端末を閉じて再起動し、同じディレクトリで claude --resume で復帰できる。

環境系の詳細な手順は Claude Codeインストール完全ガイド、基本操作全般は Claude Codeスタートガイド を参照されたい。

---

生成系でclaude 動かない——「完了しました」が偽陽性になる仕組みと見抜き方

環境系をクリアしているのにclaude 動かない、あるいは「完了した」のに実際には動いていない——この状態は、AIの生成・報告プロセスそのものに起因する。ログにエラーが出ないため発見が遅れ、対処コストが積み重なる点で厄介度が高い。

Claude Codeが「修正を適用しました。動作を確認しました」と返すとき、その「確認」は自分が生成したコードやコマンドの出力テキストを読んで判断しているにすぎない。実際にHTTPリクエストを送ってステータスコードを検証したわけでも、実画面をレンダリングして目視したわけでもない。E2Eテストが正常終了していても、そのテストが変更箇所をカバーしていなければ結果は「偽陽性」だ。

実運用で繰り返し現れるパターンは5つに収束する。

1. 「完了しました」と報告されたがブラウザで開くと404
2. E2Eテストが正常終了しているが実画面・実データを未確認の偽陽性
3. AIが自己生成したコマンドのクォート崩れ・存在しないフラグの幻覚
4. 何度指摘しても同じ失敗を繰り返す（セッションをまたぐと記憶がリセット）
5. 一箇所修正すると別の箇所が壊れる（デグレ）

証拠なしのOKは採用しない——完了の定義を変える

claude 動かないの生成系に対して実運用で機能した対処はシンプルだ。Claude Codeが「完了しました」と言ったとき、証拠を提示できなければその完了報告は保留とする。

証拠として認めるのは次のいずれかだ。

• 実際のHTTPレスポンスコード（curl -I https://... の出力）
• 変更ファイルのdiff（git diff の実出力）
• 関連テストの実行結果（変更箇所をカバーしていることの確認付き）
• APIレスポンスの実値またはDBクエリ結果

これをCLAUDE.mdに宣言しておく。

# CLAUDE.md——完了の定義
タスク完了時は以下を必ず提示する：
1. curl -I [該当URL] の実行結果（HTTPステータスコードを含む）
2. 変更したファイルの差分サマリ（git diff --stat）
3. 関連テストの実行結果
証拠を提示できない場合は「確認できていない」と明記する。

偽陽性が起きやすい典型的な場面を把握しておくと対処が早い。

• ルーティング変更後：テストは旧パスを叩いており新パスは未テスト
• ビルド未反映：コードは修正したがビルドを再実行していないため本番は旧バイナリ
• 環境変数の取り違え：ローカルでは動くがCI/CDの環境変数が異なる
• キャッシュ汚染：CDNやブラウザキャッシュが残存し修正が反映されていない（または逆）

コマンドの文法ミス・幻覚——実行前dry-runで防ぐ

Claude Codeが自分でコマンドを生成して実行するとき、そのコマンド自体に問題が混入することがある。実運用で遭遇した具体的なパターンを示す。

• クォート崩れ：シェルのクォートが閉じられていない、またはネストが壊れている
• 存在しないフラグの幻覚：--dry-run や --verbose を指定したが実際のコマンドに存在しない
• 変数名衝突：既存スクリプト内の変数名と生成コードの変数名が重複し意図しない上書きが起きる
• パスの相対・絶対混在：実行ディレクトリの前提が違い想定外のパスを操作する

Anthropic公式「Troubleshooting tool use」（platform.claude.com）でも、AIが存在しないパラメータを生成する問題への対策として、スキーマへの strict: true 設定や input_examples の追加が案内されている。自前のエージェント設計に組み込む際は参照する価値がある。

対処の基本はdry-runの習慣化だ。コマンドを生成させたら即座に実行させず、内容を確認してから実行する。

# 指示の定型文
実行する前に生成したコマンドを一行ずつ表示してください。
私がOKと言ってから実行してください。
不可逆な操作（削除・上書き・本番環境への書き込み）は必ずy/n確認を求めてください。

# ツール側のdry-run
rsync --dry-run -av /source/ /dest/
terraform plan

# dry-runがないツールはechoで代替確認
grep -r "削除対象の文字列" . --include="*.js"

---

実データで見る、Claude Codeのエラー全35パターン（セッションログ実測）

ここまでは環境系・生成系という2つの切り口で見てきたが、実際にどんなエラーがどれだけ発生するのかを、自社の実運用セッションログ（2,596ファイル・約708MB・Bash実行13,832回）を解析して集計した。想像や公式ドキュメントの引き写しではなく、現場で本当に出たエラーの一覧である。

結論：Claude Code のエラーは「4系統」に分けられる

実データを分類すると、エラーは次の4系統に収束します。この分類を頭に入れておくと、対処の当たりが一瞬でつきます。

以下、系統ごとに全パターンを解説します。

① API・アカウント系エラー（計189件）

Claude Code 本体が API と通信できなかったケースです。コード側では直せません。

1. The model's tool call could not be parsed (retry also failed).

発生89件（最多）。 モデルが出力したツール呼び出しの JSON が壊れており、リトライしても復旧しなかったケース。

• 原因：長大なプロンプト／複雑なスキーマ／マルチエージェントの並列実行時に、モデルの出力が破綻する。
• 対処：ツールに渡す入力を小さく分割する。特に巨大な JSON スキーマを持つツール（後述の StructuredOutput）と併発しやすい。
• 傾向：大規模なサブエージェント並列実行を行った期間に集中して発生した。エージェントを一度に大量並列させると再現しやすい。

2. API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited

発生69件。 サーバー側の一時的なレート制限です。

• 重要：メッセージにある通り、これは「あなたの利用上限」ではありません。 混同して利用状況を確認しに行っても意味がありません。
• 対処：数十秒〜数分待って再試行。頻発するなら、並列エージェント数を減らす。

3. You've hit your monthly spend limit.

発生10件。 月次の支出上限に到達。

• 対処：/usage-credits で上限を引き上げるか、より軽量なモデルへ切り替える。

4. You've hit your weekly limit · resets ...

発生2件。 週次の利用上限。リセット時刻まで待つか、プランを見直します。

5. Not logged in · Please run /login

発生10件。 認証トークンが失効した状態。

• 対処：/login を実行。CI やヘッドレス実行中に出た場合は、認証情報の永続化（~/.claude/.credentials.json）が壊れていないか確認します。

6. API Error: 529 Overloaded.

発生6件。 サーバー過負荷。時間を置くしかありません。ステータスページで障害有無を確認します。

7. API Error: 500 Internal server error.

発生2件。 サーバー内部エラー。こちらも一時的なもので、再試行で通ります。

8. API Error: Unable to connect to API (ConnectionRefused)

発生1件。 ネットワーク到達不能。プロキシ設定、VPN、社内ファイアウォールを疑います。

② ツール入力系エラー（AIの書き方ミス）

ここが最も件数が多く、かつ最も「防げる」領域です。

9. Output does not match required schema — StructuredOutput のスキーマ不一致

発生346件／全559回中（失敗率62%）。 全ツール中、圧倒的に失敗率が高いのがこれです。

しかも内訳を見ると 1日で316件が同一エラー。must have required property 'feature' を延々と繰り返していました。

• 原因：ワークフローで定義した JSON スキーマと、サブエージェントへの指示文が噛み合っていない。サブエージェントは「何を返せばいいか」を指示文からしか知らないため、スキーマに必須プロパティを足しても、指示文を直さなければ永遠に失敗し続ける。
• 対処：

1. スキーマの必須プロパティ名を、指示文にそのまま列挙する。

2. additionalProperties: false は慎重に。「余計なプロパティを返すな」というエラーも8件発生している。

3. 同じスキーマエラーが3回続いたら、リトライを止めてスキーマ側を疑う。 316回のリトライは純粋な浪費。

10. File has not been read yet. Read it first before writing to it.

発生77件（Edit 59件＋Write 18件）。 読まずに書こうとした。

• 対処：Edit/Write の直前に必ず Read。これはハーネスの仕様であり、回避策はありません。

11. File content has changed since it was last read. / File has been modified since read

発生30件。 読んだ後にファイルが書き換わった。

• 原因：Bash 経由で linter / formatter / ビルドが走り、ファイルを上書きした。あるいは別セッション・ユーザーが編集した。
• 対処：Read → （Bashを挟まず）→ Edit の順で行う。Bash を挟んだら Read しなおす。

12. String to replace not found in file.

発生12件。 置換対象の文字列が見つからない。

• 原因：日本語を含むファイルで多発。エスケープ表記（\uXXXX）と実文字の差、全角スペース、行末の空白が原因。
• 対処：Read した内容からコピーした文字列をそのまま使う。手打ちしない。

13. InputValidationError: The required parameter ... is missing

発生10件以上（AskUserQuestion 5件、Monitor 2件、Read 2件ほか）。 必須パラメータの入れ忘れ。

14. InputValidationError: ... could not be parsed as JSON

発生5件以上。 ツール入力の JSON が壊れている。長い日本語テキストや改行を含む引数で発生しやすい。

15. The parameter 'offset' type is expected as 'number' but provided as 'array'

発生8件。 型違い。Read の offset に配列を渡していた。

16. File does not exist. Note: your current working directory is ...

発生19件。 存在しないファイルを読もうとした。

• 注目：Claude Code は親切に Did you mean ProgressiveComposer.jsx? と候補を提示してくれます。.js と .jsx の取り違えが典型。提案が出たら素直に従いましょう。

17. EISDIR: illegal operation on a directory, read

発生3件。 ディレクトリを Read しようとした。ファイル一覧が欲しいなら Bash の ls か Glob を使います。

18. File content (XX KB) exceeds maximum allowed size／exceeds maximum allowed tokens

発生5件。 巨大ファイルの一括読み込み。offset と limit で分割して読むか、Grep で必要箇所だけ絞ります。

19. Invalid pages parameter: ""

発生2件。 PDF読み込み時の pages 指定ミス。"1-5" のような形式で、1始まりで指定します。

③ コマンド実行系エラー（Bash：509件 / 13,832回中）

Bash の失敗率は 3.7%。多くはシェルの書き方と環境の問題です。

20. シェルのクォート崩れ：対応する ' を探索中に予期しないファイル終了 (EOF) です

発生13件。5月末から7月まで、いまだに繰り返している最重要パターン。

• 原因：ssh host '...長いスクリプト...' のように、シングルクォートの中に SQL や別のクォートを埋め込んで壊れる。
• さらに危険な派生：ダブルクォートで囲むと $ がローカルシェルで展開されてしまう。bcrypt ハッシュのような $ を含む値をそのまま埋めると、値が破壊されます。
• 対処：

– 長いスクリプト・SQL はファイルに書いて転送し、mysql < file.sql で流す。

- ヒアドキュメントは必ずクォート付き（<<'EOF'）で開き、変数展開を止める。

21. Command timed out after Xm Xs

発生25件。 ビルド、ssh、E2Eテストで頻発。

• 対処：timeout パラメータを明示的に伸ばす（最大10分）。それでも足りない処理はバックグラウンド実行にして、完了通知を待つ設計にする。

22. Error: Cannot find module 'xxx' (MODULE_NOT_FOUND)

発生9件。 puppeteer、better-sqlite3、相対パスのモジュールなど。

• 原因：実行ディレクトリが違う。一時ディレクトリに置いたスクリプトを実行すると、そこから見て node_modules が解決できない。
• 対処：プロジェクトディレクトリに移動してから実行する。 一時ディレクトリに置くなら、require を絶対パスにするか NODE_PATH を設定します。

23. SqliteError: no such column: "table"

発生7件。 SQL の中でダブルクォートを文字列リテラルのつもりで使ったケース。

• 原因：SQLite ではダブルクォートは識別子（カラム名）を意味します。エラーメッセージ自身が should this be a string literal in single-quotes? と教えてくれています。
• 対処：文字列は必ずシングルクォート。

24. ERROR 1054 (42S22): Unknown column 'username' in 'field list'

発生2件。 MySQL のカラム名を推測で書いた。

• 対処：DESCRIBE テーブル名; で実際のスキーマを確認してから SQL を書く。推測で書いたカラム名はほぼ外れます。

25. command-line line 0: unsupported option "20".

発生2件。 ssh -o StrictHostKeyChecking=20 のような、オプション名と値の取り違え。ConnectTimeout=20 と書くつもりで混線したもの。

26. can't open file '...': [Errno 2] No such file or directory

発生4件。 リモート実行時に、ローカルのパス感覚でスクリプトを指定した。リモート側にファイルが無い。

27. EACCES: permission denied, posix_spawn 'rg' / ENOENT: ... 'rg'

発生2件。 Grep ツールが内部で使う ripgrep バイナリが起動できない。権限や PATH の問題。Bash の grep へフォールバックします。

28. Exit code 1（メッセージ無し）

発生91件（Bash最多）。 出力が空のまま失敗。

• 正体の多くは「意図した失敗」：grep がヒット0件で終了コード1、pkill が対象プロセス無しで1、など。
• 対処：終了コードだけで異常判定しない。|| true を付けるか、標準エラー出力まで見る。「Exit code 1 = 障害」ではありません。

④ 安全機構による意図的ブロック（＝エラーではない）

ここを「エラー」と誤読すると、ガードレールを外す方向に動いてしまいます。 以下は全て「正しく止められた」記録です。

29. Blocked: sleep N followed by: tail ...

発生10件。 「一定時間待ってからログを覗く」パターンをハーネスが禁止しています。

• 理由：固定時間の待機は無駄が多く、条件が満たされたかも分からない。
• 正しい書き方：Monitor ツールで「条件が満たされるまでループ」の形にする。

30. Error: No such tool available: Bash. Bash exists but is not enabled in this context.

発生2件。 読み取り専用エージェント（プランナー等）から Bash を呼ぼうとした。

31. Error: No such tool available: Grep. ... search file contents with grep via the Bash tool instead.

発生5件。 同上。セッションによって有効なツールセットが違います。

32. カスタムフックによるブロック：🚫 DIFF確認なしのSCP転送をブロックしました

発生21件。 本番／ステージングへファイルを送る前に、差分確認を強制する自作フック。

33. カスタムフックによるブロック：🚫 ブロックルール発動: 危険な削除操作

発生7件。 再帰的強制削除の阻止。7回も救われていることになります。

執筆中の実例：この記事を書いている最中、本文に危険コマンドの文字列を含めただけで、このフックが作動して原稿の保存がブロックされました。フックはコマンドの意味ではなく文字列パターンで判定するため、こうした誤検知も起こります。これも含めて「効きすぎるくらいで丁度いい」というのが実感です。

34. カスタムフックによるブロック：🚫 影響分析ゲート: 影響分析・承認が未完了です

発生6件。 重要サブシステムのソース編集前に、影響分析と承認を強制するフック。

学び：.claude/hooks/ に自前のガードを仕込むと、AI の暴走を機械的に止められます。上記3種で計34回のブロックが作動しました。これは Claude Code 運用の最重要ノウハウです。

35. The user doesn't want to proceed with this tool use.

発生62件（Bash 48／Write 4／Edit 5／Read 1／AskUserQuestion 2）。 承認プロンプトでユーザーが却下した記録。人間の制止が正しく効いている証拠です。

エラー削減のためのチェックリスト（実データから導いた10項目）

1. Edit/Write の直前に必ず Read（77件が防げる）
2. Bash を挟んだら Read しなおす（30件が防げる）
3. 長い SQL・スクリプトは ssh のコマンド引数に埋め込まず、ファイルに書いて転送する（13件が防げる）
4. ヒアドキュメントは <<'EOF' とクォートする（$ の暴発を防ぐ）
5. 同じスキーマエラーが3回出たらリトライを止め、スキーマと指示文を突き合わせる（316件の浪費が防げる）
6. SQL のカラム名は DESCRIBE で確認してから書く
7. SQLite の文字列リテラルはシングルクォート
8. Node スクリプトはプロジェクトディレクトリで実行する（MODULE_NOT_FOUND対策）
9. 固定時間待機ではなく Monitor の条件ループを使う
10. Exit code 1 を即「障害」と判定しない（grep のヒット0件かもしれない）

よくある質問（FAQ）

Q. 「Rate limited」と「利用上限に達しました」は同じですか？

違います。 Server is temporarily limiting requests (not your usage limit) はサーバー側の一時的な制限で、数分待てば解消します。一方 You've hit your monthly spend limit はアカウントの支出上限で、設定変更かモデル切り替えが必要です。メッセージ本文が明確に区別しているので、読み分けてください。

Q. The model's tool call could not be parsed が頻発します。

サブエージェントの大量並列実行時に集中して発生する傾向があります。並列数を落とし、ツールに渡す入力サイズを小さくしてください。

Q. Bash のエラー率はどれくらいが普通ですか？

本記事のデータでは 13,832 回中 509 回、約3.7% でした。うち約2割はユーザーによる意図的な却下と安全機構のブロックなので、実質的な失敗は3%未満です。

Q. 過去のエラーを自分でも調べたいのですが、ログはどこですか？

~/.claude/debug/ にデバッグログがありますが、定期クリーンアップで消えます。過去分析には ~/.claude/projects/ 配下のセッション記録（JSONL）を使うのが確実です。 各行の is_error フラグと tool_use_id を突き合わせれば、本記事と同じ集計が再現できます。

繰り返し失敗・デグレ——「指摘」ではなく「仕組み」で止める

claude 動かないという状況の中でも、対処コストが最も積み重なるのがこの2パターンだ。

繰り返し失敗はCLAUDE.mdのガードレールに書く

Claude Codeに同じ失敗を「指摘」しても、次のセッションでは記憶がリセットされる。指摘はそのセッション内にしか効かない。繰り返しを止められるのは「指摘」ではなく「仕組み」だけだ。同じミスが2回発生したら、CLAUDE.mdに禁止ルールとして追記する。

# CLAUDE.md——禁止事項（繰り返した失敗から導いたルール）

## コマンド実行
- 実行前に必ず対象ファイル・パスを確認する
- 削除・上書きを伴う操作は必ずy/n確認を求める
- 実行ディレクトリは明示する（相対パスを前提にしない）

## 完了報告
- 「完了しました」と言うときはHTTPステータスコードまたはテスト実行結果を添える
- ビルドが必要な変更の場合はビルド実行後に確認する
- 証拠なしの「動作確認しました」は使わない

## コード生成
- 変数名は既存コードのものと重複しないよう確認してから使う
- オプションフラグは実際に存在するか確認してから使う（helpまたは公式ドキュメントで）

Claude Codeは新しいセッションを開いたとき、プロジェクトルートのCLAUDE.mdを自動的に読む。失敗を書いておけば、次のセッションでその前提が引き継がれる。CLAUDE.mdの設計については Claude Codeの実践的な使い方、スラッシュコマンドとの組み合わせは Claude Codeスラッシュコマンド解説 を参照されたい。

デグレは「変更前に本体名でgrep全件」で防ぐ

Claude Codeに「この関数を修正して」と頼むと、その関数を修正する。問題は、その関数が別の箇所でも呼ばれていることを見落とすか確認を省略することだ。A地点は直ったがB地点が壊れ、Bを直したらCが壊れる——この連鎖は、変更前の影響範囲把握を怠るときに発生しやすい。

# 変更前に必ずこれをやらせる
grep -rn "対象の関数名" . --include="*.ts" --include="*.js"
grep -rn "ClassName" . --include="*.ts"
grep -rn "CONFIG_KEY" . --include="*.ts" --include="*.env*"

Claude Codeへの指示の形は次のとおりだ。

この関数を変更する前に、プロジェクト全体でこの関数が呼ばれている箇所を
grep -rn で全件洗い出し、影響を受けるファイルとコンテキストを一覧してください。
その後、一箇所ずつ変更計画を提示してから実施してください。

影響範囲が広いとわかった場合は、一度に全部を変更させない。一箇所変更→テスト→確認→次の箇所のサイクルで進める。Claude Codeを使うと「まとめてやってもらえる」という錯覚が生じやすいが、変更を分割する意識を持つことが連鎖デグレを防ぐ。

「確実性の確認」を変更指示の前に挟む

曖昧なタスクや影響範囲が広い変更を依頼する前に、Claude Codeに確実性を問う。

この変更を行う前に、以下を教えてください：
1. 影響を受けるファイルと関数の一覧
2. この変更で壊れる可能性のある箇所
3. 確認が必要な前提条件
確実でない点があれば「不確かです」と先に言ってください。

Claude Codeは問われれば不確かさを開示できる。問われなければ自信ありげに誤りを提示することがある。確認を仕組みとして指示に組み込むことが、暴走の入口を塞ぐ。

---

入力の改行ができない・Enterで送信されてしまう場合

「claude codeで改行できない」は環境起因の定番のつまずきだ。公式リファレンス（Interactive mode、2026-07-03確認）が示す複数行入力の方法は次のとおり。

• \ を打ってから Enter：すべてのターミナルで動作する基本手段
• Ctrl+J：設定不要でどの端末でも改行できる制御シーケンス
• Shift+Enter：iTerm2・WezTerm・Ghostty・Kitty・Warp・Apple Terminal・Windows Terminalではネイティブ動作。VS Code・Cursor等では /terminal-setup を実行してキーバインドを導入する
• macOSの Option+Enter：ターミナル設定で「Option as Meta」を有効化した後に使える
• コードブロックやログは貼り付け（ペースト）でそのまま複数行入力になる

失敗パターン対処早見表と検証チェックリスト

以下の表に、claude 動かないの主要パターンと対処の対応関係をまとめる。

claude 動かない——失敗パターン別の原因・対処比較表

パターン	なぜ起きるか	指摘では防げない理由	仕組みで防ぐ方法
command not found	~/.local/bin がPATHから外れている	シェル設定が変わるたびに再発する	~/.bashrc / ~/.zshrc にPATH追記を固定
403 Forbidden / 認証エラー	旧ANTHROPIC_API_KEYが認証を上書き	環境変数が残存している限り継続	unset ANTHROPIC_API_KEY + /status で確認
Linux OOM（Killed）	RAM 4GB未満またはスワップ不足	メモリ構成が変わらない限り再発	スワップファイル追加（2GB以上）
偽の正常終了（完了→404）	AIは実HTTPコードを確認していない	次のタスクでまた省略する	CLAUDE.mdに完了定義（curl確認必須）を宣言
E2E偽陽性	テストが変更箇所をカバーしていない	テストは毎回異なる	タスク指示にカバレッジ確認を明記
コマンド文法ミス・幻覚	生成時に正確さより流暢さが優先される	別の形で同じ種類のミスが出る	実行前dry-run。コマンド提示→人間確認→実行
繰り返し失敗	セッションをまたぐと記憶がリセット	指摘はそのセッションのみ有効	失敗をCLAUDE.mdの禁止ルールとして蓄積
デグレ（連鎖破壊）	影響範囲を把握せず局所修正する	次の変更でまた省略する	変更前にgrep全件→影響一覧→個別検証を必須化

検証チェックリスト（コピーして使う）

## 作業前チェック
[ ] タスクの完了条件（証拠の形）を指示に明記したか
[ ] 不可逆操作（削除・上書き・本番書き込み）にy/n確認を求めたか
[ ] 変更対象の本体名でgrep全件を実行したか（影響範囲を把握）
[ ] 環境変数・ビルドモード・URLパラメータの前提を指示に含めたか

## 完了報告受領後チェック
[ ] HTTPステータスコード（curl -I）を確認したか
[ ] 変更したファイルの差分（git diff）を目視したか
[ ] 関連テストの実行結果を確認し、変更箇所をカバーしているか確認したか

## 失敗発生時
[ ] 失敗の内容をCLAUDE.mdの禁止ルールに追記したか
[ ] 同じ失敗が他の箇所でも起きていないかgrep確認したか
[ ] 次のタスク指示に再発防止の指定を追記したか

---

claude 動かないという状況の多くは、エラーメッセージが出ない形で積み重なる。完了報告を受け取っても動いていない、テストが通っても本番が壊れている、同じミスが繰り返される——これらは全て、AIの報告を検証する仕組みが欠けているときに起きる。

環境系には公式の定型対処（PATH修正・再認証・スワップ追加）が効く。生成系には「証拠なしのOKは採用しない」という設計思想を、CLAUDE.md・dry-run・grep全件という3つの習慣で実装することが、繰り返しを止める唯一の現実解だ。

Claude Codeの全体像は Claude Codeとは、料金・API費用の確認は Claude Code料金・プラン解説 および Claude Code API料金の詳細 を参照されたい。他ツールとの比較は Claude Code vs Codex比較 も読まれたい。SEOへの活用は Claude CodeとSEO入門 にもまとめている。

---

AIコーディングの安全な戦力化についてのご相談

本記事で紹介した検証の型やガードレール設計に関心のある方は、クリスタルメソッドのAI開発支援・内製化支援でご相談に応じている。詳しくはお問い合わせよりご連絡いただきたい。

---

利用できるモデルも進化を続けており、現在はClaude 5世代（最上位のFable 5、速度と知能のバランスに優れたSonnet 5）とOpus 4.8・Haiku 4.5が使えます。

参考文献

• Anthropic公式「Troubleshooting tool use」
  https://platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use
• Anthropic公式「Troubleshoot MCP tunnels」
  https://platform.claude.com/docs/en/agents-and-tools/mcp-tunnels/troubleshooting.md
• Anthropic公式「Handle Compliance API errors」
  https://platform.claude.com/docs/en/manage-claude/compliance-errors
• デジタル庁「人間にあってAIにないものは『意思』」（2026年4月8日）
  https://digital-agency-news.digital.go.jp/articles/2026-04-08_subtitles