Apple could not verify claudeと出たときの対処 — macOSのClaude Code

macOSのターミナルで claude を実行すると、「"claude"は開かれませんでした」というダイアログが出て、「Apple could not verify "claude" is free of malware that may harm your Mac or compromise your privacy.」と表示されることがあります。日本語環境では「Appleは、"claude"にMacに損害を与えたりプライバシーを侵害したりするおそれのあるマルウェアが含まれていないことを確認できません」という文面です。

これはmacOSのGatekeeperが、実行ファイルを止めた表示です。Claude Code自体のエラーではありません。この記事では、報告されている状況、先に確かめること、Apple公式の例外手順、再インストールで直ったという報告、配布物そのものの確かめ方を順に説明します。

報告されている状況

GitHubのissue #100735に、この症状の報告があります。起きた条件は次のとおりです。

報告者はそのうえで、spctl で実行ファイルを調べた結果を貼っています。出力は rejected、source=Unnotarized Developer ID で、署名者は Developer ID Application: Anthropic PBC (Q6L2SF6YDW) です。報告者の見立ては「最新ビルドが公証(notarization)されていないように見える」です。

ただし、これは報告者の見立てにとどまります。issueにAnthropic側の回答はなく、v2.1.296のリリースノートにも公証や署名に触れた項目はありません。原因が配布物にあるのか、手元のmacOSの状態にあるのかは、この時点で決着していません。

署名・公証・「壊れている」警告は別もの

この警告が何を言っているのかを、Appleのサポートページの区分で見ます。同じページには、似た文面の警告が3種類並んでいます。

今回の文面は1行目です。2行目と3行目は、macOSが中身の異常を見つけたときの警告で、「確認できない」という文面とは別になります。Appleは、署名と公証のないソフトを例外で開く手順を用意しつつ、Macや個人情報に害を及ぼすおそれがあるとも書いています。

つまり、rejected の表示だけでは、配布物が悪意あるものなのか、公証の付与が漏れたのか、手元の状態が崩れたのかは決まりません。切り分けには、次の確認が要ります。

まず手元で確かめること

警告を消す前に、止められたファイルが本物かを確認します。報告者の手順(realpath と spctl)に、codesign --verify を足した確認です。

BIN=$(realpath "$(which claude)")
echo "$BIN"
spctl --assess --type execute -vv "$BIN"
codesign --verify --verbose "$BIN"

見るのは次の3点です。

1. echo で出たパスが、自分が入れた場所(Homebrewなら /opt/homebrew/Caskroom/ 以下)か
2. spctl の origin= が Developer ID Application: Anthropic PBC か
3. codesign --verify がエラーなく終わるか

セットアップ解説には、macOS版のバイナリは「Anthropic PBC」で署名され、Appleの公証を受けていて、codesign --verify --verbose ./claude で確認できると書かれています。署名者が違う、codesign がエラーになる、パスに心当たりがない、のいずれかなら、例外を許可せず、削除して入れ直す選択になります。

spctl の結果が rejected でも、署名者がAnthropic PBCなら、報告と同じ状態です。「公証が付いていない」ことと「中身が改ざんされている」ことは別で、後者を示すのは署名の検証失敗のほうです。

選べる対処は3つ

選べる対処は、入れ直す、stableのcaskへ切り替える、Apple公式の手順で許可する、の順に手間が増えます。

入れ直す

Homebrewのissue(claude-codeの旧版で報告された同じ文面のもの)には、再インストールで直ったという書き込みが何件かあります。

brew uninstall --cask claude-code@latest
brew install --cask claude-code@latest

入れていたcaskの名前に合わせてください。セットアップ解説では、claude-code がstable、claude-code@latest がlatestを追うと説明されています。ある報告者は、brew upgrade のあとに claude-code@latest を外して claude-code を入れ直したら直ったと書いています。ただし、これは1人の体験談です。本人はstableからbetaへ移されたことが原因かもしれないと推測しているだけで、確定した原因の説明はありません。

stableのcaskに切り替える

issueの報告者はlatestのcaskでした。stableは新しい版の1週間ほど後を追うため、直近のビルドで起きた問題を避けられる可能性があります。ただし、この症状がlatestに限ると確認された記載はありません。試して直る保証はありません。

Apple公式の手順で一度だけ許可する

Appleのサポートページには、公証されていないアプリを開く手順があります。流れは次のとおりです。

1. いったん claude を実行し、警告を出させる
2. 「システム設定」を開き、「プライバシーとセキュリティ」へ進む
3. 下へスクロールし、「このまま開く(Open Anyway)」を押す
4. もう一度出るプロンプトで「開く」を選ぶ

Appleは、例外にしたアプリは以後、通常のアプリと同様に開けると説明しています。この手順は、上の確認で署名者を確かめたファイルに限った話です。

Homebrewのissueには、この手順に続けて隔離属性(quarantine)を外した人もいます。「Allow Anyway」を押したうえで、次のコマンドを実行したという書き込みです。

xattr -d com.apple.quarantine "$(realpath "$(which claude)")"

これはGatekeeperの確認を外す操作で、署名者を確かめていない実行ファイルに使う手順ではありません。同じissueの別の書き込みは、/Applications/Claude.app に対して sudo xattr -dr を使っています。これはデスクトップアプリの話で、claude コマンドとは対象が違います。

Homebrewのissueに残る、同じ文面の報告

同じ文面の報告は、今回のissueより前からHomebrewのissueに積まれています。書き込みを時系列で並べると、特定の1バージョンの問題ではなさそうだと分かります。

返信した人は「自分の環境では再現できない」とも書いていて、当時の時点でも配布側の不具合と断定した書き込みはありません。再インストールで直る例が続いているので、手元のGatekeeperやダウンロード時の状態が原因の例も混ざっていると読めます。今回のv2.1.295のissueが、それらと同じ原因かどうかは分かっていません。

配布物そのものを確かめる手段

署名者の確認は、macOSが見る情報の確認です。もう一段、Anthropicが公開している整合性情報で、手元のバイナリを照合する方法もあります。

セットアップ解説によると、各リリースは全プラットフォームのバイナリのSHA256チェックサムを載せた manifest.json を公開しています。このマニフェストにはAnthropicのGPG鍵による署名が付いていて、マニフェストの署名を検証すれば、載っているバイナリすべてを間接的に検証したことになる、という説明です。署名が付くのは 2.1.89 以降のリリースで、それより前はチェックサムのみです。

curl -fsSL https://downloads.claude.ai/keys/claude-code.asc | gpg --import
gpg --fingerprint security@anthropic.com
REPO=https://downloads.claude.ai/claude-code-releases
VERSION=2.1.295
curl -fsSLO "$REPO/$VERSION/manifest.json"
curl -fsSLO "$REPO/$VERSION/manifest.json.sig"
gpg --verify manifest.json.sig manifest.json

鍵の指紋は、セットアップ解説に載っている 31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE と一致するかを見ます。署名の検証では Good signature from "Anthropic Claude Code Release Signing <security@anthropic.com>" と出れば成功です。取り込んだばかりの鍵に対して WARNING: This key is not certified with a trusted signature! と出るのは想定どおりの表示だと、同じ解説に書かれています。

バイナリ側は、macOSなら shasum -a 256 の結果を、manifest.json の platforms.<platform>.checksum の値と比べます。

shasum -a 256 "$BIN"

この比較手順は、解説ではネイティブインストーラー版を前提に書かれています。ネイティブ版のファイルは ~/.local/share/claude/versions/VERSION にあります。Homebrewの Caskroom にあるファイルに同じ比較が成り立つかは、解説に書かれていません。値が一致すれば配布物の確認材料になりますが、一致しなかった場合は、入れた経路の違いも疑う余地があります。

別の症状と間違えやすいところ

macOSでClaude Codeが動かないとき、似て見えても原因が別のものがあります。

「Malicious Script Blocked」は動作中に出るダイアログ、こちらは起動時に出る警告です。出る場面で見分けられます。

更新の仕組みは入れ方で違う

この種の警告が更新の直後に出るのは、更新の主導権が入れ方で違うからでもあります。

セットアップ解説では、ネイティブインストーラー版はバックグラウンドで自動更新されます。macOSとLinuxでは ~/.local/bin/claude が ~/.local/share/claude/versions/ へのsymlinkで、直近の更新結果は claude doctor で見られます。一方、Homebrewは自動更新されず、brew upgrade claude-code か brew upgrade claude-code@latest で手動更新する作り方です。CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE を 1 にすると、Claude Codeが代わりにHomebrewの更新コマンドを走らせる設定もあります。

つまり、Homebrewで入れた場合は、自分で brew upgrade を打った瞬間が、新しいビルドを手元に置いた瞬間になります。更新の前後で spctl の結果を残しておくと、問題が出たときに、どの版から変わったかを報告できます。

BIN=$(realpath "$(which claude)")
spctl --assess --type execute -vv "$BIN" 2>&1 | tee spctl-before.txt
brew upgrade claude-code@latest
BIN=$(realpath "$(which claude)")
spctl --assess --type execute -vv "$BIN" 2>&1 | tee spctl-after.txt

brew upgrade のあとはCaskroom下のパスが変わるため、BIN を取り直しています。Homebrewは更新後も古いバージョンをディスクに残すと解説にあるので、brew cleanup をかける前なら、最後に動いていた版のファイルが残っている場合があります。issueの報告者は、v2.1.287では動き、v2.1.295で出たと書いています。

リリースの追い方は、/config の「Auto-update channel」か settings.json の autoUpdatesChannel で決まります。"latest" が既定で、"stable" は約1週間遅れの版を使い、大きな不具合のあるリリースは飛ばされます。Homebrewでは、この設定ではなくcask名(claude-code か claude-code@latest)で追う先を選びます。

導入方法そのものを選び直したい場合は、MacへのClaude Codeの入れ方やHomebrew・npm・ネイティブの比較が参考になります。ネイティブインストーラーに切り替えると、Homebrewとは別の経路で入ります。ただし、この症状がネイティブ版で起きないかは、issueには書かれていません。

まとめ

Claude Codeのバイナリは、セットアップ解説でAnthropic PBCの署名とAppleの公証済みと説明されています。警告が出たときは、署名者の確認で、配布物の問題か手元の問題かを切り分けられます。署名者がAnthropic PBCで codesign も通るなら、入れ直しとstableへの切り替えが手間の少ない側の選択肢で、Appleの例外許可はそのあとに来ます。