Coded Chords - Mac

pCloud DriveのmacOS Tahoe問題

2026-06-27T10:00:00+09:00

Table of Contents</summary> </details>

macOS Tahoe(macOS 26)に上げてから、pCloud Driveが起動するが機能しない状態となりました。やっかいなのは、アプリ単体では済まず、うっかりpCloud Driveを開こうとするとキーボードが効かなくなるなどMac全体が一時的に不安定になる点です。</p>

pCloudとは</h2>
pCloudは、スイスのpCloud AGが提供するクラウドストレージサービスです。買い切りの生涯プランがあること、ファイルを暗号化して預けられること、そしてアカウントを作ると無料枠から使い始められることで知られています。</p>
Macで使う場合、もっとも手軽なのは公式のpCloud Driveアプリです。これはクラウド上のファイルを、ローカルの仮想ドライブ(`~/pCloud Drive</code>)としてマウントして見せてくれます。Finderから普通のフォルダのように開けるので、クラウドを意識せずに使えるのが利点です。</p>`
`一方で、この「仮想ドライブとして見せる」仕組みは、macOSのファイルシステム拡張に依存します。後述するように、ここがOSのアップデートで影響を受けやすい部分でもあります。</p>`

macOS Tahoeでの不具合</h2>
私の環境はApple SiliconのMacで、OSはTahoe(macOS 26)です。アップデート後、pCloud Driveが機能せず、開こうとするとOS全体の挙動が一時的に不安定になりました。</p>
同様の現象が一般に報告されているか調べたところ、Tahoe環境での不具合報告が複数見つかりました。代表的なものは次の通りです。</p>

アップデート後に「Enable Disk(仮想ドライブのマウント)」が機能しない</li>
メニューバーのアイコンが表示されない</li>
ドライブは見えてもマウント・同期ができない</li>
ドライブ有効化時に「outdated(古い)」と表示され有効化できない</li>
</ul>
これらはフォーラムでの報告であり、「同様の事例が存在する」ことの裏付けにはなりますが、原因や解決を断定する根拠にはなりません。pCloud公式が症状ごとの原因を断定して公表しているわけでもありません。そのため、ここから先に書く原因は、あくまで私の推測として読んでください。</p>
pCloud Driveは、クラウドをローカルの仮想ドライブとして見せるために、ファイルシステム拡張(pCloudFS / macFUSE)を使います。この低レベルの拡張がロードに失敗したり、カーネル側で引っかかったりすると、アプリ単体のクラッシュにとどまらず、OS全体の挙動に波及することがあります。私が遭遇した「開こうとすると全体が不安定」という症状は、このパターンと整合します。OSのメジャーアップデート直後は、こうした低レベル拡張の互換性が崩れやすく、不安定になりがちです。</p>
pCloud Driveのアンインストール</h2>
macOS向けのpCloud DriveはApple Siliconになってから問題も多く、macOSの変更による影響も受けやすいのでうんざりしていました。</p>
OS全体を巻き込んで不安定になるアプリの回復に時間をかけるより、他の方法に移行しpCloud Driveはアンインストールすることにしました。</p>
アンインストールは次の2ステップが必要です。</p>

ログイン項目からpCloud Driveを外してmacOSを再起動</li>
pCloud Driveの削除</li>
</ol>
まずシステム設定 → 一般 → ログイン項目と機能拡張からpCloud Driveを外し、いったんmacOSを再起動して拡張の常駐を切ります。</p>
次にアプリ本体を削除です。</p>
手動で削除する場合は、pCloud Driveを完全終了(できればアプリ内でログアウト/Unlink)してから、アプリ本体をゴミ箱へ移し、~/Library</code>配下の残骸を削除します。主な残骸は次の場所です。</p>
~</span>/Library/Application Support/pCloud</span></span>
~</span>/Library/Application Support/com.pcloud.pcloud.macos</span></span>
~</span>/Library/Caches/com.pcloud.pcloud.macos</span></span>
~</span>/Library/Preferences/com.pcloud.pcloud.macos.plist</span></span></code></pre>
私が実際に使ったのは、CLIのアンインストーラであるMole(tw93/Mole</code>)です。Homebrewで導入でき、コマンド名はmo</code>になります。</p>
brew</span> install mole</span></span></code></pre>
mo uninstall</code>は、アプリ本体に加えて、launch agentやPreferences、Cachesといった関連ファイルもまとめて削除してくれます。安全のため、まず--dry-run</code>で削除対象を確認してから本実行しました。対象アプリの正確な名前は--list</code>で確認できます。</p>
mo</span> uninstall --list</span>                   # mo uninstall が受け付ける正確なアプリ名を一覧表示</span></span>
mo</span> uninstall --dry-run "pCloud Drive"</span>  # 削除対象を事前確認(変更は行わない)</span></span>
mo</span> uninstall</span>                           # 対話形式の一覧から pCloud Drive を選んで実行</span></span></code></pre>
引数なしのmo uninstall</code>は対話形式のセレクタを開くので、一覧からpCloud Driveを選んで実行します。アプリ名を引数で渡せば、対話なしで直接アンインストールできます。削除されたファイルは既定でゴミ箱へ送られるため、必要なら復元できます。</p>
Moleが消すのは、主にユーザーレベルの関連ファイルです。macOSにシステム拡張として登録された部分(pCloudFS / システム拡張)は対象外になることがあります。通常はmacOSを再起動するとクリアされますが、残っていないかは次のコマンドで確認できます。</p>
systemextensionsctl</span> list</span>   # pCloud AG の拡張が残っていないか確認</span></span></code></pre>
Mole自身も、macOS 15以降では一部の拡張系の権限エントリがアプリ削除後も残ること、そしてその種のリセットはグローバルかつリカバリモードを要するため自動では行わないことを、警告として明示しています。ツール任せにせず、最後は再起動とsystemextensionsctl list</code>での確認で締めるのが現実的です。私の環境では、ログイン項目から外して再起動したあとにアンインストールしたこともあり、最終的にpCloud AGの拡張は1つも残りませんでした。</p>
なお、pCloud Driveアプリをアンインストールしても、pCloudアカウント自体は消えません。Web(my.pcloud.com)からファイルにはアクセスできますし、消えるのは有効化済みの同期設定とカスタム設定だけです。</p>
rcloneでの設定方法とメリット</h2>
rclone</a>は、各種クラウドストレージをコマンドラインから統一的に扱えるツールです。以前「rcloneとS3ライフサイクルで作る個人データのコールドアーカイブ</a>」でAmazon S3を使った長期保管の構成をまとめましたが、pCloudもバックエンドとして公式にサポートされています。</p>
設定はrclone config</code>の対話で行います。ブラウザ認証を済ませると、設定ファイル~/.config/rclone/rclone.conf</code>が作られ、内容は次のようになります。</p>
[</span>pcloud</span>]</span></span>
type</span> =</span> pcloud</span></span>
hostname</span> =</span> eapi.pcloud.com</span></span>
token</span> =</span> {</span>"access_token":"<rclone config の認証で自動生成されるアクセストークン>"</span>,</span>"token_type":"bearer"</span>,</span>"expiry":"0001-01-01T00:00:00Z"</span>}</span></span></code></pre>
ここでtoken</code>はrclone config</code>のOAuth認証で自動生成されるものです。手で書く必要はありませんし、アクセストークンそのものなので、他人に見せたりリポジトリにコミットしたりしないよう注意してください。この記事でも実際の値はプレースホルダに置き換えています。</p>


    私はプライバシーを重視しているので、ヨーロッパリージョン(eapi.pcloud.com</code>)を使っています。</p>

</aside>

hostname</code>はリージョンを指します。eapi.pcloud.com</code>はヨーロッパリージョン、api.pcloud.com</code>(デフォルト)は米国リージョンです。アカウントがヨーロッパリージョンの場合は、ここをeapi.pcloud.com</code>に設定しておかないとトークンエラーになることがあります。通常はOAuth認証の過程で適切に設定されますが、うまくいかないときはこの値を疑ってください。</p>
設定できたら、まずは中身が見えるか確認します。</p>
rclone</span> lsd pcloud:</span>                                # トップ階層のディレクトリ一覧</span></span>
rclone</span> copy pcloud:My</span>\ </span>Pictures ~/Downloads/pics</span>  # 取り出し(ダウンロード)</span></span>
rclone</span> sync ~/work pcloud:work</span>                    # ローカルからクラウドへ同期(送信)</span></span></code></pre>
Finderのようにフォルダとしてマウントしたい場合はrclone mount</code>も使えますが、こちらはmacFUSEを必要とします。日常的なファイルの取り出しや同期は、マウントせずとも上記のコマンドだけで完結します。</p>
pCloud Driveからrcloneへ寄せる利点は、大きく2つです。</p>

macOSへの非依存</dt>
コマンドベースの転送(copy</code>、sync</code>、lsd</code>、cat</code>)はファイルシステム拡張を使わず、ユーザーランドだけで完結する。今回の不具合の原因だったpCloudFS / macFUSEとは無縁で、OSのメジャーアップデートにも振り回されない。</dd>
CLIでの自動化</dt>
CLIとなることで、launchd</code>やシェルスクリプトに組み込みが自由になる。バックアップや定期同期などを自動化して回せる。</dd>
</dl>
pCloudのサービス継続性について</h2>
ここで、pCloudというサービス自体の信頼性にも触れておきます。</p>
pCloudの大きなウリは、一度の支払いで使い続けられる買い切り(Lifetime)プラン</strong>です。
ただし、その「Lifetime」が何を指すのかは、規約を読むと印象より限定的です。pCloudの利用規約は、買い切りプランの有効期間を「アカウント所有者の生存期間か99年のいずれか短い方」と定義しています。さらに「pCloudが事業を停止した場合、アカウントは終了し、サービスは提供されない」とも明記されています。買い切りは、永久でも、企業の存続から独立した保証でもありません。</p>
そうなると運営元の規模が気になります。</p>
pCloudを提供するpCloud AGはスイスの非上場企業で社員は数十人規模、外部資本を入れないブートストラップ経営です。
非上場企業のため正確な業績は外から分かりません。出回っている年商も10億円程度1</a></sup>です。</p>
pCloudサービスは設立から10年以上続き、ユーザーも2,000万を超えて伸びており、「経営が危ない」という状況ではなさそうです。</p>
しかし、規模の小ささ自体が構造的な継続性リスクになります。買収や方針転換、大手との競争で、サービスの将来を一個人が見通すことはできません。また、規模の小ささが、今回の様な新しいmacOSへの対応の遅れの要因ともなっているかと思います。</p>
だからこそ、買い切りだからと唯一の保管先にはせず、今回のrcloneのような別経路や、ローカル・別クラウドにもコピーを持っておくのが現実的だと考えています。</p>
まとめ</h2>
macOS Tahoeとの互換性によるpCloud Drive不具合から、一旦rcloneに移行しました。</p>
とはいえ、pCloud DriveはDropboxのSmart Syncのようにキャッシュだけのローカルに置く方式で便利なので、いつか安定したら戻りたいものです。</p>
振り返ってみると、pCloudの2TBライフタイムを購入したのは2021年です。350ドル（当時のレート1ドル約109円で約38,200円）の一括払いでした。仮に、Dropbox Plusの2TBを使用していたとしたら、年額15,840円（税込）かかります。
2年半足らずで買い切りが追いつき、購入から約5年が経った今では、Dropboxなら累計8万円ほどかかっていた計算です。円で累計コストを並べると、その差がはっきりします。</p>


あまりヘビーに依存せず上手に使っていきたいと思います。</p>
References</h2>


    
pCloud</a>. 「pCloud for macOS リリースノート」</li>
pCloud</a>. 「コンピュータからpCloudをアンインストールするとどうなりますか」</li>
pCloud</a>. "Terms and Conditions"</li>
Apple Support</a>. "Delete apps on your Mac"</li>
rclone</a>. "pCloud backend documentation"</li>
Mole</a>. "tw93/Mole"</li>
</ul>

</div>




創業者の自己申告(約16.5億円)と第三者の推計(約6.6億円)で2倍以上の開きがあり、健全性を客観的に確かめる手段がありません。 ↩</a></p>
</li>
</ol>
</section>



Macバックアップ戦略・改訂版
2026-06-09T13:37:30+09:00

Table of Contents</summary>

</details>
</span>
長らくMacのバックアップにはSuperDuperを使い、Bootableなクローンを作ってきました。その方針は、以前Apple Silicon時代のMacバックアップ最新戦略</a>で整理したとおりです。ですが新しいmacOSへの対応がなかなか進まず、Tahoeに至っては一年あまり経った今も正式版すら出ません。そこでSuperDuperを諦め、rsyncでホームディレクトリを鏡像コピーする方式に切り替えました。この記事はその続編であり、乗り換えの理由と設定方法をまとめたものです。</p>
なぜTime Machineが嫌いか</h2>
バックアップの話をすると、まずTime Machineを勧められます。ですが私は、ごく初期に使ったきり、その後はすっかり避けるようになりました。</p>
もともとは、Bootableなクローンを作れるサードパーティツールを使っていたからです。
Bootableなクローンが作れれば、ディスクが壊れた際にはクローンからmacOSを起動して復旧できます。</p>
ただし、現在ではBootableなクローンを技術的に作成できなくなりました(後述)。
それでも、Time Machineには不信感が根強く、直感が先に拒否します。その裏には技術的な理由が3つあります。</p>


不確実性</p>

Time Machineはバックアップ先を専用のアーカイブ(sparsebundle)として抱え込む。中で何が起きているかは見えず、壊れていても警告は出ない。実際、復元しようとしたらアーカイブが読めず、修復もできず、履歴を全部捨てて最初からやり直すしかなかったという報告は後を絶たない。</li>
</ul>
</li>

破損に弱い</p>

sparsebundleは中身を多数の小さなバンドファイルに分け、その内側に1つのファイルシステムを抱える構造になっている。個々のファイルを直接取り出すことはできず、必ずイメージ全体をマウントして読む。だからバンドや内部の目次(カタログ)が一部でも壊れると、イメージごとマウント不能になり、世代を問わず全データに手が届かなくなる。世代を積み上げる構造だけに、過去のバックアップまでまとめて道連れになりやすい。</li>
</ul>
</li>

ブラックボックス</p>

何がどうコピーされ、どう積み上げられているのか、仕組みそのものがユーザーからは見えない。バックアップ先を開いても何がどう入っているか分からず、「このファイルが今そこにある」とFinderで素朴に確かめることもできない。中で何が行われているか把握できないものに大事なデータを預けるのは、技術者としてどうにも信用しきれない。</li>
</ul>
</li>
</ul>
私が欲しいのはその逆です。バックアップ先を開けば、コピー元とそっくり同じ構造でファイルがそのまま並んでいて、いざというとき個別のファイルをドラッグで取り出せる。履歴はいりません。今この瞬間の鏡像が1つあれば十分です。見えて、触れて、そのまま取り出せること。Time Machineはこの要求に対して、仕組みからして向いていません。</p>
そのため、私は丸ごとBootableなディスククローンを作成できるサードパーティ製のツールを利用してきました。</p>
macOSの変化で、bootableクローンが封じられた</h2>
ところが、ここ数年のmacOSの変化で、その前提が崩れました。サードパーティ製ツールによるBootableなクローンが、事実上できなくなったのです。経緯を追うと、じわじわと封じられてきたことが分かります。</p>


Big Surでシステムとデータが分離</p>

起動ディスクが、OSの入った読み取り専用のシステムボリュームと、ユーザーデータのデータボリュームに完全分離された。システム側は改ざん防止のため署名・封印され、サードパーティ製アプリが直接コピーできなくなった。OSを複製する役目はApple自身の仕組み(レプリケーター)に移り、それが動き続けるかどうかもApple次第になった。</li>
</ul>
</li>

Sequoia 15.2が決定打</p>

Appleがそのレプリケーターを壊し、SuperDuperはBootableなバックアップを作れなくなった。データ複製の終盤、PrebootやRecoveryをコピーするあたりで失敗する。これはツール側のバグではなく、Apple側の問題だと開発元が明言している。</li>
</ul>
</li>

Tahoeでは正式対応すら出せず</p>

互換性の壁がさらに増え、SuperDuperは正式版を出せていない。Tahoe対応は暫定ベータ(v3.20系)でしのぐ状態が続いている。一時はベータでの改善に期待もしたが、一年あまり経ってもベータのまま。起動可能クローンへの望みは、もう捨てた。</li>
</ul>
</li>
</ul>
要点を取り違えないことが大事です。壊れたのはBootableなシステム丸ごとクローンであって、ホーム(データ)のコピーが禁じられたわけではありません。Appleが封じたのはシステムボリュームの複製で、ユーザーのデータをコピーすること自体は今も普通にできます。</p>
今日のmacOSでのバックアップ戦略</h2>
ここで要件が変わります。</p>
Bootableにできないのなら、システムボリュームまで丸ごとコピーする意味はもうありません。bootableという目的が消えた以上、「全部コピーする」根拠も一緒に消えました。残ったのは、自分のデータだけを守れればいい、という縮退した要求です。</p>
つまり「ホームディレクトリだけでいい」は、最初からそう思っていたわけではありません。bootableを失った結果として、そこまで切り詰めた制約の上に成り立っています。この経緯を踏まえると、要件は次のように整理できます。</p>

バックアップ対象はホームディレクトリのみ。システムは諦める。</li>
アプリが~/Library</code>配下などに書く、ユーザーが関知しないデータも要らない。多くは再生成されるので、守る価値がない。</li>
差分でいい。変わっていないファイルは書き換えず、変わったぶんだけ転送する。</li>
世代管理はいらない。常にコピー元と同じ、今この瞬間の鏡像が1つあればいい。</li>
</ul>
rsyncのメリット</h2>
この縮退した要件に、rsyncはきれいに合います。</p>
第一に、差分転送が本職です。rsyncは初期状態で、サイズと更新日時を見て一致するファイルをまるごとスキップします。変わっていないファイルは触らず、変わったぶんだけ送ります。「変更ないファイルは書き換えたくない」という要求が、特別な設定なしにそのまま満たされます。</p>
第二に、コピー先がただのファイルになります。バックアップ先は元と同じフォルダ階層がそのまま並ぶので、Finderで全部見えますし、個別ファイルをドラッグで取り出せます。Time Machineの抽象化とは正反対の、見える鏡像が手に入ります。</p>
第三に、世代を持たない運用ができます。--delete</code>を付ければ、コピー元で消したものはバックアップ先からも消え、常に最新の一枚の鏡像が保たれます。履歴の束は作られません。</p>
第四に、無料で、スクリプトに組めて、スケジュール実行まで自前で完結します。専用アプリのライセンスや、OSの更新に追従できないツールの都合で振り回されることもありません。</p>


    </div>
    
        標準のrsyncは使わない</strong>
        Sequoia/Tahoe標準のrsyncはopenrsync</code>という別実装で、出来がよくありません。-a</code>で特殊ファイルに当たると止まる、拡張属性でクラッシュするといった報告があります。標準のものは避け、Homebrewで本家のrsync(3.x系)を入れて使いましょう。</p>

    </div>
</div>

準備</h2>
まずHomebrewで本家rsyncを入れます。TahoeはApple Silicon専用なので、入れると/opt/homebrew/bin/rsync</code>に置かれます。</p>
brew install rsync</span></span></code></pre>
もう1つ、フルディスクアクセスの設定が要ります。最近のmacOSでは、これが無いとホーム内の保護領域(メールなど)が読めず、警告も出さずに黙って飛ばされます。手で動作確認するときは使っているターミナルを、自動実行するときは後述のスクリプトを、システム設定のプライバシーとセキュリティ → フルディスクアクセスに追加しておきます。これを怠ると「バックアップしたつもりで一部入っていない」が起きます。</p>
コマンドと除外設計</h2>
バックアップ本体は、次の一本にまとめます。</p>
#!/bin/bash</span></span>
DEST</span>=</span>"/Volumes/Backup"</span></span>
LOG</span>=</span>"</span>$HOME</span>/Library/Logs/backup-home.log"</span></span>
</span>
if</span> !</span> /sbin/mount</span> |</span> grep</span> -q "on </span>$DEST</span> "</span>;</span> then</span></span>
  echo</span> "</span>$(</span>date</span>)</span> $DEST</span> not mounted, skipped"</span> ></span>"</span>$LOG</span>"</span></span>
  exit</span> 0</span></span>
fi</span></span>
</span>
/opt/homebrew/bin/rsync</span> -aE --delete --info=progress2</span> \</span></span>
  --exclude='/Library/'</span> \</span></span>
  --exclude='.Trash/'</span> \</span></span>
  --exclude=".cache/"</span> \</span></span>
  --exclude='tmp/'</span> \</span></span>
  --exclude='.DS_Store'</span> \</span></span>
  --exclude='/pCloud Drive'</span> \</span></span>
  --exclude='/.pcloud/'</span> \</span></span>
  "</span>$HOME</span>/" "</span>$DEST</span>/home/"</span> ></span>"</span>$LOG</span>"</span> 2>&1</span></span>
echo</span> "</span>$(</span>date</span>)</span> done"</span> >></span>"</span>$LOG</span>"</span></span></code></pre>
先頭のif ! /sbin/mount ...</code>は、バックアップ先が未マウントのときに内蔵ディスクへ誤って書き込む事故を防ぐガードです。-a</code>は権限・更新日時・シンボリックリンクなどを保ったまま再帰コピーし、-E</code>はmacOSの拡張属性を保持します。--delete</code>でコピー元から消したものをバックアップ先からも消し、常に鏡像に保ちます。--info=progress2</code>は全体の総進捗を一行で表示します。$HOME/</code>の末尾スラッシュは「ホームの中身を」コピーする指定で、これが無いとhome自体が一段深く入れ子になります。</p>
除外設計が実は一番の勘どころになります。詰まりの原因はほぼここに集約されます。</p>

.Trash</code>はゴミ箱、.cache</code>やtmp</code>は再生成される一時データ、.DS_Store</code>はFinderの表示情報。どれもバックアップする価値がない。</li>
クラウドや外部接続の仮想ドライブも必ず外す。ローカルに実体がなく、rsyncが舐めるとオンデマンドのダウンロードを次々誘発し、激遅やタイムアウト、最悪はクラウド上の全データの引きずり下ろしを招く。iCloud DriveやDropbox、OneDrive、Google DriveはLibrary/CloudStorage</code>やLibrary/Mobile Documents</code>にあるので、/Library/</code>を外せば一緒に消える。pCloud Drive</code>のようにホーム直下へマウントされるものだけ、個別に除外する。</li>
</ul>
Library</code>配下をどこまで残すかは判断が要ります。大半はアプリが再生成する状態ファイルなので、丸ごと--exclude='Library/'</code>で外しても困らない人は多いでしょう。ただしローカルにしか実体のないデータ(ローカル保存のメールなど)がある場合は、その特定フォルダだけ残す配慮がいります。</p>
自動化</h2>
週1回の自動実行は、非推奨のcronではなくlaunchdで組みます。さきほどの~/bin/backup-home.sh</code>に実行権を付けます。</p>
chmod +x ~/bin/backup-home.sh</span></span></code></pre>
次に~/Library/LaunchAgents/com.user.backup-home.plist</code>を作ります。毎週日曜の午前3時に走る例です(Weekdayの0が日曜)。</p>
<?</span>xml</span> version</span>=</span>"1.0"</span> encoding</span>=</span>"UTF-8"</span>?></span></span>
<!DOCTYPE</span> plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"</span>></span></span>
<</span>plist</span> version</span>=</span>"1.0"</span>></span></span>
<</span>dict</span>></span></span>
  <</span>key</span>></span>Label</span></</span>key</span>></span></span>
  <</span>string</span>></span>com.user.backup-home</span></</span>string</span>></span></span>
  <</span>key</span>></span>ProgramArguments</span></</span>key</span>></span></span>
  <</span>array</span>></span></span>
    <</span>string</span>></span>/Users/ユーザ名/bin/backup-home.sh</span></</span>string</span>></span></span>
  </</span>array</span>></span></span>
  <</span>key</span>></span>StartCalendarInterval</span></</span>key</span>></span></span>
  <</span>dict</span>></span></span>
    <</span>key</span>></span>Weekday</span></</span>key</span>><</span>integer</span>></span>0</span></</span>integer</span>></span></span>
    <</span>key</span>></span>Hour</span></</span>key</span>><</span>integer</span>></span>3</span></</span>integer</span>></span></span>
    <</span>key</span>></span>Minute</span></</span>key</span>><</span>integer</span>></span>0</span></</span>integer</span>></span></span>
  </</span>dict</span>></span></span>
</</span>dict</span>></span></span>
</</span>plist</span>></span></span></code></pre>
登録します。</p>
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.user.backup-home.plist</span></span></code></pre>
launchdの利点は、指定時刻にMacが起動していなくても、次に起動したときに取りこぼしを拾って実行してくれる点です。cronのように「その時刻に寝ていたら丸ごと飛ぶ」ということがありません。複数回ぶんが溜まっても、起動時に走るのは1回にまとめられます。週一の用途なら、これで実用上困りません。</p>
つまずきどころ</h2>
実際に動かすと、たいてい最初の数回はここで引っかかります。</p>

初回はホーム全体のフルコピーなので、容量とドライブ速度によっては数時間かかる。差分で速くなるのは2回目以降。止まっているのか遅いだけなのかは、du -sk /Volumes/Backup/home</code>を時間を空けて2回打ち、数字が増えているかで判別する。</li>
異常に遅い・止まる場合は、まず標準の/usr/bin/rsync</code>(openrsync)を叩いていないかwhich rsync</code>で確認する。そして上のクラウド系の除外が効いているかを見る。GoProなどをMTP接続してマウントしている場合、それもLibrary/CloudStorage</code>に入り込んでタイムアウトの山を作るので、除外で一掃される。</li>
Permission Deniedが出ても、rsyncはそのファイルを飛ばして続行する。多くはフルディスクアクセス不足か、root所有の触れないファイルだ。前者は設定で解決し、後者は無視してよいが、拒否されたのが自分の大事なデータでないかだけは確認する。</li>
</ul>
まとめ</h2>
この構成にも、諦めた点はあります。起動可能なクローンではないので、ディスクが飛んだら、まずmacOSを入れ直し、それからホームを書き戻す手間が残ります。アプリの再インストールも要ります。「つなげば即座に元通り」とはいきません。そこは割り切りです。</p>
それでも私は、こちらを選びました。中身が見えて、いざとなれば一ファイルから引き出せて、仕組みを丸ごと自分の手で握れる。バックアップに一番ほしいのは、派手な復旧速度ではなく、この「見えている」という安心でした。OSやアプリの都合に振り回されないかぎり、この鏡像は週末ごとに静かに更新され続けてくれます。それだけで、私には十分です。</p>


Mac環境のリフレッシュ
2026-03-17T15:34:11+09:00



Table of Contents</summary>

</details>
見送っていたMac環境のリフレッシュを実施しました。</p>
MacPaw関連ソフトウェアの見直し</h2>
MacPaw1</a></sup>の次の2つのソフトウェアを使用していました。</p>

CleanMyMac X</strong>: macOSのメンテナンス・ユーティリティ</li>
Gemini 2</strong>: 重複ファイル削除ツール</li>
</ul>
いずれもサブスクリプションが中心ですが、私は2022年にロシアのウクライナ侵攻が起こった際に支援のつもりでLifeTimeの買い切りで購入しています。コストも発生せず、どちらも便利なツールです。</p>
しかし、常駐して僅かですがリソースを食っているのが気になっていました。
今回はどちらもアンインストールして、CLI代替ツールに移行しました。</p>
Mole — macOSクリーンアップツール</h2>

</iframe>

macOSのクリーンナップと最適化に特化したコマンドラインツールです。
CleanMyMac、AppCleaner、DaisyDisk、iStat Menusなどの機能を1コマンドでカバーしていると謳っています。</p>
mo</span> clean</span>      # キャッシュ・ログ・ブラウザ残骸の削除</span></span>
mo</span> uninstall</span>  # アプリの完全アンインストール</span></span>
mo</span> optimize</span>   # キャッシュ再構築・サービスリフレッシュ</span></span>
mo</span> analyze</span>    # ディスク使用量の可視化</span></span>
mo</span> status</span>     # CPU/GPU/メモリ/ディスク/ネットワークのリアルタイム監視</span></span>
mo</span> purge</span>      # 開発プロジェクトのビルド成果物削除</span></span>
mo</span> installer</span>  # Downloads内の.dmg/.pkgの整理</span></span></code></pre>
結構危険な処理をするツールですが、いずれも--dry-run</code>オプションがサポートされており、実際に削除する前に検証できます。</p>
実際、CleanMyMac Xで使用していた機能のうちマルウェアスキャン以外はほぼカバーされています。
マルウェアスキャンについては、macOS標準のXProtectとGatekeeperがかなり優秀なので、基本的に追加のスキャナは不要と判断しました。</p>
Czkawka（チカフカ） — 不要ファイル検出ツール</h2>

</iframe>

主に重複ファイルの削除に使用していたGemini 2の代替です。名前はポーランド語で「しゃっくり」を意味します。</p>
rmlint</a>も検討しましたが、rmlintはバイト単位での重複判定のみで、Gemini 2のように画像の類似性による重複判定には対応していません。</p>
その点Czkawkaは、パーセプチュアルハッシュによる類似画像検出をサポートしています。GUI版もありますが、安定のCLI版を使っています。</p>
# 重複ファイル検出: -d 検索先 -e 除外先 -m 最小25B -s hash比較 -D aeo(最古以外を削除)</span></span>
czkawka_cli</span> dup -d ~/Documents -e ~/Documents/Archive -m</span> 25</span> -x 7z rar IMAGE -s hash -f results.txt -D aeo</span></span>
</span>
# 空フォルダ検出: 複数ディレクトリ指定可</span></span>
czkawka_cli</span> empty-folders -d ~/Documents ~/Downloads -f results.txt</span></span>
</span>
# 巨大ファイル検出: -n 上位25件 -x VIDEO拡張子を除外</span></span>
czkawka_cli</span> big -d ~/Documents -e ~/Documents/Archive -n</span> 25</span> -x VIDEO -f results.txt</span></span>
</span>
# 類似画像検出: パーセプチュアルハッシュで視覚的に似た画像を検出</span></span>
czkawka_cli</span> image -d ~/Pictures -e ~/Pictures/Wallpapers -f results.txt</span></span>
</span>
# 壊れたシンボリックリンク検出</span></span>
czkawka_cli</span> symlinks -d ~/Projects -e ~/Projects/.git -x jpg -f results.txt</span></span>
</span>
# 破損ファイル検出: ヘッダが壊れたファイル等を検出</span></span>
czkawka_cli</span> broken -d ~/Downloads -f results.txt</span></span></code></pre>
重複ファイル、類似画像、空ファイル・フォルダ、一時ファイル、破損ファイル、拡張子不一致、不正ファイル名など、Gemini 2以上に多彩な検出機能を備えています。</p>
なお、SenseiとCocktailは引き続き使用しています。Senseiはハードウェア情報やSSDのTrim管理に、CocktailはmacOSの定期メンテナンスタスクの自動実行に、それぞれ役割が明確なので残しました。</p>
メニューバーの整理</h2>
MacBookでメニューバーにたくさんアイコンが並ぶと、ノッチの裏に隠れて見えなくなる問題があります。この対策としてメニュー表示管理ツールを使用していました。</p>
Bartenderから数年前にIce</a>へ移行しましたが、macOS Tahoeではメニュー構造が変わった影響で動作が不安定になっていました。</p>
代替として次のようなツールがありますが、いずれも新しいmacOSのメニュー構造の変更に対応しきれていないようでした。</p>

Hidden Bar</li>
Bartender 5（有料）</li>
Vanilla</li>
iBar</li>
</ul>
しかし、macOS Tahoeではメニューバーのカスタマイズ機能が大幅に強化されました。「システム設定 > メニューバー > メニューバーの操作」から、次の操作が可能になっています。</p>

アプリごとにメニューバーへの表示のオン・オフを制御</li>
Apple純正機能はコントロールセンターへ移動可能</li>
Command+ドラッグでアイコンの並び替え</li>
</ul>
サードパーティ製ツールのように表示の動的な切り替えやレイアウト変更には対応していませんが、常駐アイコンの大半を整理できました。もうサードパーティ製ツールは不要です。</p>
ブラウザArcの代替</h2>
数年前に彗星のごとく登場したArcを愛用していましたが、2025年5月にThe Browser Companyが開発終了を発表しました。理由は「ほとんどの人にとってArcは違いが大きすぎて学習コストに見合わなかった」という"novelty tax"問題とのことです。後継としてAIブラウザ「Dia」の開発に注力するとされていますが、Arc自体はセキュリティ修正のみのメンテナンスモードに入っています。</p>
当初はGoogle Chrome + Side Space拡張機能でほぼArcと同等のことができるかと試していました。しかし、Arcの全機能を再現しようとすると拡張の組み合わせが増えるばかりで、本末転倒だと気づきました。</p>
結局、Safariに落ち着いています。iCloudとの連携、省電力性能、macOS標準のパスキー対応など、Apple製品で統一している環境であれば素直にSafariが最適という結論です。</p>
まとめ</h2>
GUIの常駐アプリをCLIに置き換え、メニューバーをOS標準機能で整理し、ブラウザもSafariに一本化しました。</p>
やっとメニューバーが整理でき、mo clean</code>一発でMacのクリーンナップもできる。そういう小さな快適さの積み重ねで、深呼吸できた心地がします。ゴミの山は鼻をつまんで走り抜けるに限ります。</p>
References</h2>


    
GitHub - tw93/mole</a>. "Mole - Deep clean and optimize your Mac"</li>
GitHub - qarmin/czkawka</a>. "Multi functional app to find duplicates, empty folders, similar images etc."</li>
Sensei — Cindori</a>. 「Mac Performance Monitor & Cleaner」</li>
Cocktail — Maintain</a>. 「A perfect mixture for macOS」</li>
Apple Support</a>. "Change Menu Bar settings on Mac"</li>
Engadget</a>. "The Browser Company stops active development of Arc in favor of new AI-focused product"</li>
</ul>

</div>




Macのユーティリティ系ソフトウェアを開発・販売しているウクライナのベンダー ↩</a></p>
</li>
</ol>
</section>


Apple Silicon時代のMacバックアップ最新戦略
2025-04-18T00:00:00+00:00
Macのバックアップ戦略</h2>
macOSはOS自体がTimeMachine</strong>という自動バックアップ機能を持っています。
以下のような特徴を持っています。</p>

特徴</strong>: macOSに標準搭載、独自形式でデータを保存</li>
メリット</strong>: 設定が簡単、自動バックアップ、過去バージョンへのアクセス</li>
デメリット</strong>: 独自形式のため通常のFinderからのアクセスが困難</li>
アプローチ</strong>: 問題発生時はリカバリーからOSインストール後、Migration Assistantでデータ復元</li>
</ul>
iMacを使っていた時は使っていましたが、Macbookを使うようになってから
TimeMachineの使用を止めました。
理由は、バックアップ用にディスクが常にマウントされているとは限らないので
「自動バックアップ」の恩恵が相対的に薄く、加えて独自形式のためTimeMachineの
メカニズムでしかバップアップにアクセスできないためです。</p>
Apple Silicon時代のバックアップの変化</h2>
TimeMachineを使用しない替わりに、長らくSuperDuper</a>
やCarbon Copy Cloner</a>を使いディスクごと
完全なクローンを取っていました。
完全なクローンはブート可能なので、リカバリーの際にはクローンディスクから
macOSをブートしてリカバリーを行うことができました。</p>
しかし、Apple Silicon搭載のMac（M1/M2/M3チップ）ではIntelが使われていた時代と
比較してシステムアーキテクチャが大きく変わりました。</p>
主な変更点は次の通りです。</p>

OSが読み取り専用として保護されるようになった</li>
リカバリー機能がより強化された（Recovery・Fallback Recoveryが内蔵）</li>
外部ドライブからの起動に制限が追加された</li>
</ul>
バックアップ戦略も見直す必要が出てきました。
このためBootableな完全ディスククローンという戦略は以前ほど重要ではなくなりました。</p>
推奨バックアップ戦略</h2>
次のようなバックアップ戦略を変更することが必要です。</p>


データ中心のバックアップ</strong>:</p>

OSではなく、ユーザーデータを確実に保護する</li>
SuperDuperの場合はBackup - User files</code>オプションが効率的</li>
TimeMachineを使う場合は、同様にデータのバックアップに重点を置く</li>
</ul>
</li>

リカバリー戦略</strong>:</p>

問題発生時：

リカバリーモードから起動（⌘+Rキー）</li>
OSをクリーンインストール</li>
Migration Assistantを使ってバックアップからデータを復元</li>
</ol>
</li>
</ul>
</li>

ストレージの選択</strong>:</p>

ユーザーデータのみをバックアップする場合、Mac本体と同程度の容量で十分</li>
頻繁にアクセスする場合はSSD、コスト重視ならHDDを選択</li>
NASを使用すれば、ネットワーク経由で自動バックアップも可能</li>
</ul>
</li>
</ol>
SuperDuperとTimeMachineの選択基準</h2>
私自身はSuperDuperを使用していますが、有償のソフトウェアですしApple謹製の
TimeMachineを使いたい方もいると思います。
次のような観点で選択すればよいと思います。</p>


SuperDuperを選ぶ場合</strong>:</p>

バックアップから直接ファイルにアクセスしたい</li>
標準ファイルシステムでの管理を好む</li>
選択的なバックアップをしたい</li>
バックアップスケールや方法を自分で調整したい</li>
</ul>
</li>

TimeMachineを選ぶ場合</strong>:</p>

設定の簡単さを重視</li>
過去バージョンへの簡単なアクセスが必要</li>
macOSに標準搭載の機能のみで完結させたい</li>
</ul>
</li>
</ul>
まとめ</h2>
Apple Silicon時代では、起動可能なバックアップよりも「確実にデータを保護し、
必要時に復元できる」戦略が重要です。OSはリカバリーモードから再インストールし
、大切なユーザーデータは確実にバックアップしておくことで、トラブル時も迅速に
復旧できます。</p>
SuperDuperの最新ベータ版ではブータビリティの改善が進んでいますが、
現実的な運用としてはユーザーデータに焦点を当てた戦略が効率的です。</p>
また、私はpCloudも使用しているため、
特に重要なファイルはpCloud上で作業するようにしています。
過去30日分のリビジョンが保存されますし、クラウドからいつでも取り出せます。</p>
家庭用途では、
特にストレージコストを考慮すると、データ中心の定期的バックアップと
クラウドなどへの直近のデータの保管を併用すれば十分な保護が可能です。</p>


Goodbye Bartender!
2024-11-12T00:00:00+00:00
Bartender</a> was menu bar wizard I'd been geeking out over. Turned out Ben Surtees had sold it to some shadowy outfit called Applause in March 2024. Reddit blew up with users freaking out.
Today, I've now ditched Bartender for Ice,too.</p>
Keep it FOSS, keep it safe, am I right?</p>
バーテンダー</a>はメニューバーの魔術師で、私は熱中していました。ベン・サーティーズが2024年3月にApplauseという正体不明の会社に売却していたことが判明しました。Redditではユーザーたちが大騒ぎしていました。
今日、私もバーテンダーを捨ててIceに乗り換えました。</p>
オープンソースを守れば安全、そうでしょ？</p>


M4 Macbook has been announced
2024-10-31T00:00:00+00:00
I'm currently using a MacBook Pro with M3 Max, so I've made a comparison between the M3 Max and M4 Max. I think I'll continue using my current MacBook Pro for a while longer rather than upgrading.</p>
Chip Model</th> CPU Core Count</th> GPU Core Count</th> Benchmark Scores</th> Transistor Count (Billions)</th> Memory Bandwidth (GB/s)</th> Release Date</th></tr></thead>

M3 Max</td> 12/4</td> 40</td> Single: 2971, Multi: 20785</td> 92</td> 400</td> 2023-10-30</td></tr>
M4</td> 4/6</td> 10</td> —</td> 28</td> 120</td> 2024-05-15</td></tr>
M4 Pro</td> 10/4</td> 20</td> —</td> Not announced</td> 120</td> 2024-10-29</td></tr>
M4 Max</td> 12/4</td> 40</td> —</td> Not announced</td> 546</td> 2024-05-15</td></tr>
</tbody></table>

Chip Model</th>	CPU Core Count</th>	GPU Core Count</th>	Benchmark Scores</th>	Transistor Count (Billions)</th>	Memory Bandwidth (GB/s)</th>	Release Date</th></tr></thead>
M3 Max</td>	12/4</td>	40</td>	Single: 2971, Multi: 20785</td>	92</td>	400</td>	2023-10-30</td></tr>
M4</td>	4/6</td>	10</td>	—</td>	28</td>	120</td>	2024-05-15</td></tr>
M4 Pro</td>	10/4</td>	20</td>	—</td>	Not announced</td>	120</td>	2024-10-29</td></tr>
M4 Max</td>	12/4</td>	40</td>	—</td>	Not announced</td>	546</td>	2024-05-15</td></tr> </tbody></table>

Coded Chords - Mac

pCloud DriveのmacOS Tahoe問題

References</h2>

Macバックアップ戦略・改訂版

Mac環境のリフレッシュ

Mole — macOSクリーンアップツール</h2> </iframe> macOSのクリーンナップと最適化に特化したコマンドラインツールです。 CleanMyMac、AppCleaner、DaisyDisk、iStat Menusなどの機能を1コマンドでカバーしていると謳っています。</p>

メニューバーの整理</h2> MacBookでメニューバーにたくさんアイコンが並ぶと、ノッチの裏に隠れて見えなくなる問題があります。この対策としてメニュー表示管理ツールを使用していました。</p>

Apple Silicon時代のMacバックアップ最新戦略

Macのバックアップ戦略</h2> macOSはOS自体がTimeMachine</strong>という自動バックアップ機能を持っています。 以下のような特徴を持っています。</p>

Goodbye Bartender!

M4 Macbook has been announced