Claude Media
Claude Codeのロックファイル残留でインストール失敗する原因と直し方
Claude Codeチュートリアル

Claude Codeのロックファイル残留でインストール失敗する原因と直し方

Claude Codeのインストールやアップデートが古いロックファイルで失敗するケースの原因と、OS別の削除コマンド、GitHub Actionsでの再発防止をまとめます。

読了目安 約16分

Claude Codeのインストールがロックファイルで失敗する

Claude Codeのインストールやアップデートが次のメッセージで止まる場合、原因は前回のインストール試行が残した古いロックファイルです。

Could not install - another process is currently installing Claude. Please try
again in a moment.
 
Try running with --force to override checks

さらにやっかいなのは、GitHub Actions(anthropics/claude-code-action)上でこのエラーが起きると、ワークフローのログには✅ Installation complete!と成功したかのように表示される点です。実際にはclaudeバイナリがPATHに存在せず、直後の実行ステップがerror: Executable not found in $PATH: "claude"で落ちます。最初の報告時点の環境はubuntu-latestランナー・Action v1.0.21・Claude Code 2.0.50でした。後続のコメントでは異なるバージョンの組み合わせでも同じ症状が確認されており、特定のバージョン限定の不具合ではありません。claude-code-actionのGitHub issue #709で2025年11月29日に報告されました。それ以降、macOS・Ubuntu・Fedora・Windowsの各環境から同じ症状の報告が続いています。

なぜ古いロックファイルが残るのか

インストール処理は多重実行を防ぐため、作業中はロックファイルを作成し、完了時に削除します。ここで問題になるのがタイムアウトです。issue #709の報告では、最初のインストール試行が約2分でタイムアウトし、ロックファイルを消さないままプロセスが終了していました。

直後にアクションが自動でリトライすると、消え残ったロックファイルを「別プロセスが実行中」と誤認し、2回目の試行も失敗します。この時点でインストール自体は完全に失敗しているにもかかわらず、後続のステップは成功メッセージを出してしまうため、ログを流し読みしただけでは異常に気づけません。

issue内では、恒久対応の方向性として①リトライ前のロックファイル削除、②リトライ時の--force自動付与、③インストール完了報告前にバイナリの実在確認、④タイムアウト値の見直し、の4点が提案されています。

実はこのissueが報告される直前に、インストール処理そのものへの改善は2件マージされています。2025年11月22日にマージされたPR #694は、2分のタイムアウトと最大3回のリトライを追加しました。11月25日にマージされたPR #700は、timeoutコマンドがmacOSに無い問題へのクロスプラットフォーム対応です。issue #709はその4日後の11月29日に報告されています。つまりリトライの仕組み自体は既にあり、それでも直らなかったということです。リトライ処理には④タイムアウト値の見直しが入っていても、①のロックファイル削除は含まれていません。そのため3回リトライしても、毎回同じ古いロックに当たって失敗していたと考えられます。

経緯 — 長期間報告が続いている既知issue

このロックファイル問題は一度きりの不具合ではなく、インストール処理の改善が入った直後から2026年1月上旬まで、報告と回避策の確認コメントが続いています。

時期内容
2025-11-22内容PR #694マージ(インストールに2分タイムアウト・最大3回リトライを追加)
2025-11-25内容PR #700マージ(タイムアウト処理をmacOS対応にクロスプラットフォーム化)
2025-11-29内容初回報告(Action v1.0.21、Claude Code 2.0.50)
2025-12-04内容別ユーザーから「毎回発生する」という再現報告
2025-12-09内容手動インストールスクリプトによる回避策が共有される
2025-12-09〜15内容rm -rf ~/.local/state/claude/locksの回避策がUbuntu・Fedoraで確認される
2025-12-15〜18内容WindowsではC:\Users\...\.local\state\claude配下の削除で解決したという報告が続く(.localディレクトリ全体を消す誤った引用も出回ったが、後続コメントで訂正されている)
2025-12-19〜31内容同じ回避策がmacOSでも確認される
2026-01-05内容直近のコメント。同じコマンドでの解決報告と、自己修復機能を望む声

issue #709自体はこの2026年1月5日のコメントを最後に、新しいコメントが付いていません。issueはクローズされておらず、公式による恒久修正が別途取り込まれたという記録もありません。ロックファイル削除は暫定策のままです。

コメント欄では、anthropics/claude-codeリポジトリ側の別issue(#6200)でも同じrm -rf ~/.local/state/claude/locksが有効だったと紹介されています。claude-code-action経由のインストールに限らず、claude本体のインストーラー(CLIから直接claude install/claude updateを実行する場合)でも同じ症状が起きうるようです。

対処: ロックファイルを削除して再実行する

ロックファイルを手動で消せば、次のインストールやアップデートは通常どおり進みます。macOSとLinuxでは同じパスです。

rm -rf ~/.local/state/claude/locks
claude install

Windowsでは対応するディレクトリが異なります。

Remove-Item -Recurse -Force "$env:USERPROFILE\.local\state\claude"
claude install

issue内のログにあるとおり、エラーメッセージ自体が--forceでの上書きを案内しています。ロックファイルの場所を調べずに済ませたい場合は、こちらを先に試す手もあります。

claude install --force

ただし--forceでも直らないケースが報告されています。issue #709のコメントでは、Windows環境でclaude install --forceを実行しても解消せず、state\claude配下を直接削除して初めて直った例があります。--forceで解決しない場合は、上記のロックファイル削除に進んでください。

OS別のロックファイルの場所

ロックファイルの置き場所はOSで共通の考え方(ユーザーのローカル状態ディレクトリ配下)ですが、パスの書き方が変わります。

OSロックファイルのパス削除コマンド
macOSロックファイルのパス~/.local/state/claude/locks削除コマンドrm -rf ~/.local/state/claude/locks
Linux(Ubuntu / Fedora等)ロックファイルのパス~/.local/state/claude/locks削除コマンドrm -rf ~/.local/state/claude/locks
Windowsロックファイルのパス%USERPROFILE%\.local\state\claude削除コマンドRemove-Item -Recurse -Force "$env:USERPROFILE\.local\state\claude"

このstateディレクトリは別物です。Claude Codeアンインストールの手順が扱う~/.local/bin(バイナリ本体)や~/.local/share(インストール済みバージョン等)とは場所が違います。macOS・Linuxで削除するのはstate/claude/locksサブディレクトリだけです。Windowsの回避策だけはstate\claudeディレクトリ全体を削除する点に差があります。バイナリ本体や設定ファイルとは場所が異なるため巻き添えにはなりにくいものの、Windowsの手順は影響範囲がやや広いことは踏まえておいてください。

GitHub Actions(claude-code-action)で再発を防ぐ

CI上でこのエラーが繰り返し起きる場合、ワークフローが実行のたびに新規インストールを試みていること自体が原因になりやすくなります。claude-code-actionのpath_to_claude_code_executable入力を使うと、自動インストールをスキップし、指定したバイナリをそのまま使わせられます。

.github/workflows/claude.yml
- uses: anthropics/claude-code-action@main
  with:
    path_to_claude_code_executable: /usr/local/bin/claude
    claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

事前にセットアップジョブでインストール・キャッシュしたバイナリのパスを渡す構成にすれば、毎回のジョブでインストールを再試行する必要がなくなり、インストール起因のタイムアウトは起きなくなります。アクションの自動インストールを使わない分、claudeのバージョン更新は自分で管理する必要があります。組織全体でワークフローを配布している場合は、GitHub Actionsの組織導入手順にある共有ワークフロー化と組み合わせられます。バイナリの差し替えも1箇所で管理できるようになります。

path_to_claude_code_executableを使わず、アクション自体のインストール処理を経由しない選択肢もあります。issue #709のコメントで共有されていた手動インストール手順を、専用ステップとしてワークフローに組み込む形です。

.github/workflows/claude.yml
- name: Install Claude Code manually
  run: |
    version=$(curl -fsSL "https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/stable")
    curl -fsSL "https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/$version/linux-x64/claude" -o /usr/local/bin/claude
    chmod +x /usr/local/bin/claude
- uses: anthropics/claude-code-action@main
  with:
    path_to_claude_code_executable: /usr/local/bin/claude
    claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

この方法はclaude-code-actionのインストールステップを完全に迂回するため、ロック機構そのものの影響を受けません。引き換えに、バージョン追従とダウンロード先URLの維持は自分のワークフロー側の責任になります。actions/cacheでダウンロード済みバイナリをキャッシュしておけば、毎回のダウンロード自体も省略できます。

よくあるつまずき

~/.localディレクトリごと削除してしまうのが最も実害の大きい誤りです。issue #709のコメント欄でも、Windowsで.local全体を消す回避策が広まりかけました。しかし別のユーザーから「pipx・仮想環境・tmux・direnvなど多数のツールが道連れで壊れる」と指摘が入りました。消してよいのは.local\state\claudeのサブディレクトリだけで、.local全体は対象に含めません。

「Installation complete」の表示を信用してしまうのも典型的な見落としです。前述のとおりロック競合で失敗していても、ワークフローのログ上は成功表示が出ます。CI導入時は、インストール直後にclaude --versionを実行して終了コードを確認するステップを挟むと、この種の「見かけ上の成功」を早い段階で検知できます。

ローカルのclaude installとCI上の失敗を同じ原因と決めつけるのも避けたい点です。CI環境ではタイムアウトからの自動リトライが主因ですが、ローカル環境での発生原因はissue内では特定されていません。claude-code-action側の不具合修正が別途入ることもあります。Claude Code v2.1.227はその一例です。ロック削除で直らない場合は、アクションのバージョン自体も確認します。メモリ不足でインストーラーごと強制終了する「Installation was killed」エラーとは症状も対処も別物です。エラーメッセージの文言で切り分けてください。

よくある質問

claude updateでも同じエラーは起きますか

起きます。issue #709には、claude updateで2.0.72から2.0.73へのアップグレード中に同じエラーに遭遇し、ロックファイルの削除で解決したという報告があります。claude install限定の不具合ではなく、既存インストールの更新経路でも同じロック機構が使われています。

ジョブをまたいでロックが残ることはありますか

GitHub Hostedランナーは実行ごとに使い捨てられるため、別ジョブの実行がロックを持ち越すことは基本的にありません。issueで報告されている競合は、同一ジョブ内での1回目のタイムアウトと2回目のリトライの間で起きています。ただし、自己ホスト型ランナーのようにファイルシステムを使い回す構成では、前回のジョブが残したロックが次回の実行に影響する可能性があります。

レート制限のエラーと見分けるには

CIジョブの失敗はレート制限が原因のこともあり、ログだけでは区別しづらい場合があります。issueのコメントでは、レート制限は即座にAPI側から拒否されtotal_cost_usd: 0が返る一方、ロックファイルのエラーはインストールのタイムアウト(約2分)を経てから発生すると整理されています。失敗までの時間が長ければロック競合、即座に失敗していればレート制限を疑う切り分けです。

Windowsの「because it is being used by another process」と同じですか

別の症状です。公式のトラブルシューティングガイドはFailed to download binary: The process cannot access the file ... because it is being used by another processという別のエラーを扱っています。これはPowerShellインストーラーが%USERPROFILE%\.claude\downloadsへの書き込みでファイルロックに当たるエラーです。対処もRemove-Item -Recurse -Force "$env:USERPROFILE\.claude\downloads"と異なります。今回扱っているanother process is currently installing ClaudeはCLI自身のロック機構によるメッセージです。削除対象のディレクトリも文言も別物なので、エラーメッセージの文言で切り分けてください。

ロックファイルを削除しても直らない場合は

claude doctorを実行してインストール状態を確認したうえで、それでも失敗する場合は前述の手動インストール手順に切り替えてください。issue #709のコメント欄には、このほかの環境固有の報告も残っています。

まとめ

「another process is currently installing Claude」は、前回のインストール試行がタイムアウトし、ロックファイルを消さないまま終了したことが原因です。~/.local/state/claude/locks(Windowsは%USERPROFILE%\.local\state\claude)を削除すれば、その場は解決します。claude install --forceはエラーメッセージ自身が案内する手ですが、コメント欄で解消を確認できるのはロックファイルの削除のほうです。GitHub Actions上で繰り返し発生する場合は、path_to_claude_code_executableでバイナリを固定し、インストール自体を毎回走らせない構成に変えるのが根本的な再発防止です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →