ClaudeをMacアプリにするがうまくいかないとき｜確かめる順番

Dockに置いたClaudeの窓は、うまく動いているときは意識されず、壊れるときは何も言わずに壊れます。アイコンが跳ねて消える。ログイン画面までは出るのに、そこで弾かれる。ショートカットを押しても何も起きない。どれも役に立つエラーメッセージを出してくれないので、同じ4つの操作を思いつく順に試して諦める、という時間の使い方になりがちです。原因はそれぞれ違う場所にあり、順番を決めて確かめれば2分ほどで切り分けられます。

触る前に、3つの層のどれが壊れたかを決める

動くために必要な層が3つあり、壊れ方も直し方も層ごとに違います。最初に層を特定しておくと、見当違いの作業に1時間使わずに済みます。

いちばん外側がアプリの本体です。macOSは、署名と隔離の印を見て、その.appを起動してよいかどうかを判断します。ここで止まると何も出ません。窓もログイン画面も出ず、開発元が確認できない、あるいは壊れている、という趣旨のダイアログが出ることがあります。

真ん中がプロファイルです。クッキーやローカルの保存領域、つまりサインインした状態が入っているフォルダのことです。ここが壊れると、アプリ自体は普通に開くのに、済ませたはずのログインを毎回求められます。

いちばん内側がサイトそのものと、Macとサイトの間にあるものです。ログインの拒否、真っ白な画面、ブラウザでは動くのに窓では動かない機能は、ここに属します。

症状	層	最初に見る場所
何も開かない、警告のダイアログが出る	本体	システム設定のプライバシーとセキュリティ
開くが毎回ログインを求められる	プロファイル	アプリのデータ保存先とプロファイルの設定
ログイン画面は出るが弾かれる	サイト	窓が使っているエンジンとログイン方法
ショートカットが効かない	システム	プライバシーとセキュリティのアクセシビリティ
通知が来ない	システム	通知の設定と、許可を答えた場所
昨日まで動いていた	本体かエンジン	夜のうちに更新されたもの

該当する行の確認を先にしてください。以降は、その行を起きやすい順に並べたものです。

ログイン画面までは出るのに、そこで弾かれる

いちばん多く、いちばん原因が見えにくい失敗です。画面は明らかに動いているので、サイト側が悪いように見えません。実際に断っているのは、多くの場合Claudeではなく認証を担っている側です。Googleはこの条件を公開しています。

To help protect your account, Google doesn't let you sign in from some browsers. Google might stop sign-ins from browsers that: Are embedded in a different application. 出典: support.google.com

最後の行が要点です。「別のアプリケーションに埋め込まれたブラウザ」からのサインインは止まることがある、と明記されています。小さなソフトの中に抱え込まれたエンジンで動く窓は、この条件に当たることがあります。同じページをChromeやSafariで開けば何事もなく通るので、アカウント側の問題だと勘違いしやすい場面です。同じ資料は、Chromium Embedded Frameworkで「Googleでログイン」を実装した開発者に対して、ブラウザを使うOAuthへ移行するか、Progressive Web Appへ移行するよう案内しています。方向ははっきりしています。

抜け道は3つあります。Googleのボタンではなくメールと確認コードのログインを使えば、この判定を通りません。Macにすでに入っているブラウザの上で動き、そのプロファイルを読む窓を使えば、ログインはそのブラウザのログインそのものになります。あるいは先にブラウザ側でログインを済ませ、その状態を窓に引き継がせる方法もありますが、これは後者の作りの道具でしか成立しません。

切り分けは10秒で済みます。同じMacの普通のブラウザの窓で同じURLを開き、同じ手順でログインしてみてください。そちらでも失敗するなら窓は無関係で、アカウントか回線か組織の方針の話です。そちらで成功して窓だけ失敗するなら、違いはエンジンだけです。窓の中でキャッシュを消しても結果は変わりません。

TeamやEnterpriseの組織では、もうひとつの型があります。シングルサインオンはログインをID基盤に回すため、判定される場所がclaude.aiを離れたあとになります。失敗する画面がClaudeの画面ではなくID基盤の画面なら、この型です。

初回にそもそも起動できない

道具で作ったアプリを初めて開いたときに何も起きない場合、原因はほぼアプリではなくmacOSの安全策です。Appleが案内している回避の手順は、わざと1回では終わらない形になっています。

If you're certain that an app that you want to open is from a trustworthy source and hasn't been tampered with, you might be able to temporarily override your Mac security settings to open it. 出典: support.apple.com

順番はこうです。まずアプリを開こうとする。次にシステム設定を開き、プライバシーとセキュリティを選び、下までスクロールして「このまま開く」を押す。警告がもう一度出るので、そこで確認すると例外として保存され、以降は普通に開けます。押す順番が決まっていて、一度起動をブロックされたあとでなければ「このまま開く」は現れません。

ここで混同されやすいダイアログが2種類あります。開発元を確認できない、という表示は、公証されていないという意味です。Macの中で生成した.appでは普通に起きます。一方、このアプリはコンピュータに損害を与える、あるいは壊れているので開けない、という表示は別物で、既知のマルウェアが検出されたか、署名のあとで中身が変更されたことを示します。後者は無理に開く対象ではありません。捨てて作り直すのが正解です。

管理されたMacでは3つ目の可能性もあります。Appleは、システム管理者やIT部門が管理しているMacでは、ダウンロードしたアプリの許可に関する設定自体が使えない場合があると書いています。この場合はどれだけ操作しても変わらないので、担当部署に依頼する話になります。

起動するたびにログインを求められる

アプリは開き、サイトも表示されるのに、20分前のログインが消えている。プロファイルの層の話で、よくある原因は3つです。

• 起動のたびにデータの保存先が新しくなっている。窓を作り直した直後に起きやすく、前のクッキーはディスクに残っているのに参照されない状態です
• 共有しているプロファイルを別の何かが消している。終了時にクッキーを消すブラウザの設定は、窓にもそのまま効きます
• 設定としてそうなっている。Claudeにはシークレットチャットがあり、そもそも何も残さない設定で開いた窓は、残らないのが正常な動作です

早く切り分けるには、ブラウザ側の状態を見てください。ブラウザはサインインしたままで窓だけが忘れるなら、窓は独自のプロファイルを持っています。両方忘れるなら、プロファイルを消している設定がブラウザ側にあります。

キーボードショートカットが効かない

公式版のクイックエントリーでよく起きます。条件がはっきりしているので、順に潰せます。公式に挙がっているのは、クイックエントリーにmacOS 12以降、音声入力にmacOS 14以降、そしてClaudeデスクトップ版が起動していること（背景で構わない）の3点です。

詰まりやすいのは許可です。画面収録、アクセシビリティ、音声認識の3つが必要で、システム設定のプライバシーとセキュリティで確認します。更新の直後は、前の版に与えた許可を一度切って入れ直すと通ることがあります。

もうひとつが他のソフトとの取り合いです。これは資料どおりの解決策があります。呼び出しのショートカットは、既定のOptionキー2回押しから、Option＋スペース、または任意の組み合わせに、設定の一般から変更できます。音声のほうは制約が強く、Caps Lockを使うか無効にするかの二択です。同じ組み合わせを別の常駐ソフトが先に取っているなら、どちらかをずらすしかありません。

道具で作った窓の場合、全体で効くショートカットを割り当てているのはその道具なので、同じくアクセシビリティの許可が要ります。macOSのキーボード設定側で割り当てたショートカットにはこの許可が要らないため、切り分けの検査として先に試す価値があります。

通知が来ない

何も鳴らない窓は、たいてい設定どおりに動いています。設定した場所が思っているところと違うだけです。

AppleのWeb Appについての説明はこの点で具体的です。Dockのアイコンに未読の数を出すには、通知の許可をSafariではなくWeb Appの中で答える必要がある、と書かれています。そのあとで初めて、システム設定の通知の一覧にそのWeb Appが現れます。ブラウザ側で許可しても、別のアプリケーションとして扱われる窓には引き継がれません。

見る場所は3つ、この順です。Claudeの設定の中でサイト側の通知が有効になっているか。システム設定の通知の一覧にそのアプリが並び、通知を許可されているか。集中モードが弾いていないか。新しく作ったアプリは、それ以前に作った許可リストには当然入っていません。

一覧にそもそも現れない場合、窓の中で許可を尋ねられた経験が一度も無いということです。手で追加する方法は用意されていないので、窓の中でもう一度尋ねさせる必要があります。Appleの資料にあるとおり、Web Appの設定のプライバシーのタブからそのサイトのデータ（クッキーとキャッシュを含む）を消せますが、これはログイン状態も一緒に消えます。他の不具合を調べている最中に軽く押す操作ではありません。

昨日まで動いていたのに、今朝から動かない

安定していたものが止まったときの問いは狭く、夜のうちに何が変わったか、だけです。

公式版では、完了しなかった更新が原因のことがよくあります。macOS向けの配備の資料に理由が書かれています。利用者のホームフォルダの下（~/Applications）に入れた場合は管理者権限なしで更新でき、システム側（/Applications）に入れた場合は、フォルダとアプリ本体、そして中のすべてのファイルへの書き込み権限と管理者権限が要ります。管理者権限の無い業務用のMacでは、更新が静かに失敗して版が取り残されます。管理者側はJamf・Kandji・Microsoft Intuneなどから.pkgを配り、更新をまとめて管理する経路を取れます。

Macに入っているブラウザを土台にした窓の場合、夜のうちに変わったのはそのブラウザです。エンジンの置き場所が動いたのに、作った.appは前の構成を指したままになります。ここでの振る舞いは道具ごとに分かれます。変化を検知して自分で直すもの、作り直しが必要なもの、単に動かなくなるもの。起きてから調べるより、選ぶ前に確かめておく種類の性質で、できることのページに書かれているのが普通です。

自前のエンジンを抱え込む窓なら、Chromeの更新は無関係です。代わりに、そのエンジンを配っている側が更新を出し続けるかどうかに賭けることになります。古い解説記事がいまも紹介しているNativefierは、READMEの先頭に手入れされていない旨が書かれ、リポジトリは2023年9月29日に所有者によってアーカイブされています。

公開されている情報から見る、直る確率の高い順

ここまでを、起きた回数ではなく「直る確率」で並べ替えると、順序が少し変わります。

いちばん確実に直るのは、許可の問題です。画面収録・アクセシビリティ・音声認識は、必要な条件が公式に列挙されていて、システム設定で確認できます。次が起動のブロックで、これもAppleが手順を明記しています。この2つは正解が公開されているので、調べれば必ず終わります。

不確実なのは、エンジンに起因する失敗です。ログインが通らない、更新のあとに壊れる、という型は、窓の中をいくら触っても変わりません。土台を替えるしか手がないため、最初から「Macに入っているブラウザを参照する作り」を選んでおくと、この層の問題が発生しません。300以上のプリセットからすぐ作れる形であれば、作り直す場合の手間も数分で済みます。作り直しを前提にした運用が現実的かどうかは、手順の分量を見ると判断できます。実際の流れは使い方ガイドにまとまっています。

なお、ここに挙げていない症状に当たった場合は、同じ型の質問がまとめられているよくある質問を先に見ると、層の特定だけでも早く済みます。