Claude Mac アプリのキャッシュ場所と、保存先を変えられるか

起動ディスクの空きが減り、容量を調べるツールがライブラリの奥にあるフォルダを指していて、その名前がチャットのアプリだった。ここから先の疑問は2つに分かれます。中身を消してよいのか、それとも保存先そのものを別のディスクへ移せるのか。答えを分けているのは、このアプリがMac向けに書かれた普通のアプリではなく、中にChromiumを抱えたアプリだという事情です。保存先の決まり方も、消したときに何が起きるかも、ブラウザの規則に従います。

保存先は3か所に分かれている

まず場所です。関係するフォルダは3か所あり、混同したまま消すと戻せないものを消すことになります。

1つ目は「~/Library/Application Support/Claude」です。ここがプロファイルにあたります。開くと中身はブラウザのプロファイルそのもので、Cache、Code Cache、GPUCache、IndexedDB、Local Storage、Cookies、Local State、Preferences といったフォルダとファイルが並びます。Model Context Protocol の資料も、設定ファイルの置き場所として同じフォルダを指しています。

設定ファイルの場所は次のとおりです。macOS: ~/Library/Application Support/Claude/claude_desktop_config.json 出典: modelcontextprotocol.io

2つ目は「~/Library/Caches/com.anthropic.claudefordesktop」です。バンドルIDで名付けられた、macOS標準のキャッシュ置き場です。macOS自身が「消えても構わないもの」として扱う領域がここにあたります。

3つ目は「~/Library/Logs/Claude」で、接続まわりのログが書き出されます。同じ資料がこの場所も名指ししています。中身はテキストで、容量を圧迫する側ではありません。

ここで押さえておく点が1つあります。容量を食っているのは、名前に Caches と付いた2つ目ではなく、1つ目のプロファイルの側であることが多い、という点です。プロファイルの中の Cache と Code Cache は、Webから落としてきた素材と、コンパイル済みのスクリプトの置き場です。どちらも消せば作り直されます。それ以外のフォルダは状態、つまりログイン中であることを保っているCookieや、ローカルの設定や、接続先の設定ファイルです。ライブラリの中で名前が似た場所が2つあるので、片方だけを見て「大きくない」と結論づけると、実際の使用量を大きく読み違えます。

キャッシュとプロファイルが別の場所に置かれる理由

この分かれ方は、このアプリが決めたことではありません。Chromiumの側の規則で、公開されている資料に書かれています。

Chromiumは、履歴・ブックマーク・Cookieなどを収めた「ユーザーデータディレクトリ」を持ちます。そのうえで、macOSでは捨ててよい部分の置き場を別に導き出します。

macOSとiOSでは、ユーザーキャッシュディレクトリはプロファイルディレクトリから次のように導かれる。Library/Application Support がプロファイルディレクトリの祖先である場合、ユーザーキャッシュディレクトリは Library/Caches に、Application Support からプロファイルディレクトリまでの相対パスを足したものになる。 出典: chromium.googlesource.com

Electronで作られたアプリは、この土台の上に自分の製品名でフォルダを取ります。既定は「アプリケーションデータのフォルダに、アプリの名前を足したもの」と説明されており、macOSではそれが Application Support の下になります。ディスクキャッシュがChromiumの規則どおり Caches の側へ抜けるのか、それともプロファイルの中に留まるのかは、そのアプリの作りによって変わります。

読み取れることは実務的です。ライブラリの Caches だけを見て判断してはいけない、ということです。大きい方はたいてい、ログイン状態を保っているデータのすぐ隣に置かれています。

そのフォルダをFinderで開く

パスは分かっても、Finderのサイドバーには出てきません。ユーザーのライブラリフォルダはmacOSの標準設定で隠されているためです。

開き方は3通りあります。1つ目は、Finderで「移動」メニューを開き、Optionキーを押したままにすると「ライブラリ」の項目が現れるので、それを選ぶ方法です。2つ目は、Finderで Shift＋Command＋G を押し、出てきた欄にパスを直接打つ方法です。3つ目は、ホームフォルダをFinderで開いた状態で Command＋J を押し、「"ライブラリ"フォルダを表示」にチェックを入れて常時表示にしてしまう方法です。毎回この場所を触るなら3つ目が早く、一度きりなら2つ目で足ります。

日本語環境で迷いやすいのが表示名です。Finderの一覧では Application Support が「アプリケーションサポート」、Library が「ライブラリ」と日本語で表示されますが、実際のフォルダ名は英語のままです。ターミナルにパスを打つときやシンボリックリンクを作るときは、画面の表示ではなく英語の名前を使います。

大きさを測るのはFinderでもできますが、フォルダごとの内訳を一度に出すならターミナルが早く済みます。

du -sh ~/Library/Application\ Support/Claude/*

出てきた行を大きい順に見れば、判断は分かれます。Cache と Code Cache が大半を占めているなら、消せば片づく話で、あとは何日で元の大きさに戻るかという頻度の問題になります。キャッシュ以外の名前が上位に来ているなら、消しても取り戻せる容量は少なく、保存先を移す話に進む理由が出てきます。1週間使って測り直すと、その差がはっきりします。

消してよいものと、ログインし直しになるもの

保存先を変える前に、消すだけで解決するかを確かめる価値があります。多くの場合、困っているのは「保存先が間違っている」ことではなく「ディスクが足りない」ことだからです。

作業の前にアプリを完全に終了します。動いている間はキャッシュのファイルが開かれたままで、消しても書き戻されます。

影響の小さい順に並べると次のようになります。

• プロファイルの中の Cache と Code Cache。次の起動で作り直されます。最初の1回だけ表示が遅くなります
• GPUCache、DawnGraphiteCache、DawnWebGPUCache。描画まわりのキャッシュで、同じく作り直されます
• ~/Library/Caches の下のバンドルID名のフォルダ。macOSが最初から捨ててよい領域として扱っています
• Local Storage、IndexedDB、Cookies。ここはログイン状態そのものです。消すと次の起動でログインからやり直しになります
• Claude フォルダごと。上の全部に加えて、時間をかけて整えた接続設定のファイルも消えます

最後の選択肢を取るなら、claude_desktop_config.json だけは先に別の場所へコピーしておきます。会話の履歴はキャッシュの中にあるものではないので、キャッシュを消しても消えません。消えるのは、そこへ戻るための鍵の方です。

もう1つ、費用のかからない前置きがあります。消す前に、プロファイルのフォルダを丸ごと別のディスクへコピーしておくことです。想定していなかったサブフォルダに何かが入っていた場合でも、コピーがあれば数分で戻せます。macOS標準の機能だけで済むので、この保険にかかる費用は0円です。1週間ほど使ってみて問題が出なければ、コピーの方を消せば構いません。

保存先を変える3つの道

「別のディスクに保存先を変える」と一口に言っても、中身の違う3つの方法があります。使えるのは実質1つです。

方法	誰が使えるか	更新後も残るか	何が動くか
アプリ内の設定で変える	使えない。そうした設定項目は無い	該当なし	該当なし
起動時に user-data-dir を渡す	スクリプトから起動する人だけ	その起動方法を使う間だけ	プロファイル全体
フォルダを移してリンクを置く	誰でも	おおむね残る	プロファイル全体または一部

2つ目は、選ばないとしても仕組みを知っておく価値があります。Chromiumの資料には、多くのプラットフォームでコマンドラインの user-data-dir フラグによってユーザーデータディレクトリを上書きできると書かれています。同じエンジンを使うアプリは、内部の補助プロセスに対してこのフラグを自分で渡しています。実際に動いているプロセスの引数を見ると、Application Support の下のパスがそこに現れます。

問題は渡し方です。Dockのアイコンをクリックして起動する経路には、引数を差し込む場所がありません。毎回ターミナルから起動するか、起動用のスクリプトを作ってそれをDockに置くことになります。そこまでやると、Dockに見えているアイコンと実際に動くものが別になり、更新のたびに確認が要る状態になります。

現実的なのは3つ目です。アプリを完全に終了してからフォルダを外付けのボリュームへ移し、元の場所に同じ名前のシンボリックリンクを置きます。アプリは元のパスを開き、macOSがリンクをたどるので、アプリの側は何も気づきません。

壊れ方は2通りあります。1つは、ボリュームがマウントされていない状態で起動したときです。リンクの先が無いので、アプリによってはその場でフォルダを作り直し、ログアウトした状態の窓が開きます。後からディスクを挿しても、2つに分かれたものは合流しません。もう1つは、クラウド同期のフォルダの中に置いた場合です。ブラウザのストレージは、開いたままのファイルを外から書き換えられる前提で作られていません。壊れても、その場では気づけない壊れ方をします。

安全側に倒すなら、リンクにするのは Cache と Code Cache の2つだけにして、ログイン状態のデータは内蔵ディスクに残します。こうしておくと、リンクが切れても起動が遅くなるだけで済みます。

アプリが増えたときに効いてくる話

サイトを独立したアプリにして使う人にとって、この話は1本目のアプリでは終わりません。効いてくるのは5本目からです。

サイトごとにアプリを作れば、そのたびに Application Support の下にプロファイルのフォルダが増え、キャッシュが増え、それぞれ別の速度で膨らみます。5本あれば、容量を調べるときに見る場所が5か所、掃除のあとにログインし直す先が5か所になります。1本目のときには見えない負担です。

減らし方は2つあります。1つは、そもそもどのサイトを独立したアプリにするかを絞ることです。1日中開いていて、特定のアカウントでログインしていて、Command＋Tabの一覧に出てきてほしいもの。この条件に当てはまらないサイトは、タブのままの方が管理する対象が増えません。タブとの違いがどこにあるかはできることに整理されています。

もう1つは、土台にするブラウザの選び方です。アプリごとにChromiumの実体を1つずつ抱え込む作り方だと、アプリの数だけ実行ファイルとプロファイルが増えます。すでにMacに入っているChromium系のブラウザを土台にして動く作り方であれば、増えるのは設定の側だけで済み、ブラウザの更新にもそのまま乗ります。どのサービスが実際にアプリ化されているかは対応サービス一覧で確認でき、300以上のプリセットからすぐ作れる状態になっています。作る手順と、できあがったアプリがどこにデータを置くのかは使い方ガイドにまとまっており、道具を使う場合の費用は料金で確認できます。増やす前に迷いやすい点はよくある質問に集まっています。

順番としては、まずアプリを終了して Cache と Code Cache を消し、フォルダの大きさを測り直す。それで足りるなら、保存先を移す話には進まない方が安全です。1週間で元の大きさに戻り、かつディスクが本当に小さいときだけ、その2つのフォルダに限ってリンクを張る。アプリの本数が増えてきたら、置き場所の方針は1本ずつではなく全体で1回決める。この順番で判断すると、戻せない操作を踏まずに済みます。