Coded Chords - Application

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>


Sublime Text - 職人主義的ソフトウェアの美学と持続可能なビジネスモデル
2026-01-08T00:00:00+00:00


  Table of Contents
  </summary>

</details>
Sublime Textは、高速性と簡潔さを重視したクロスプラットフォームのテキストエディタです。
派手な統合機能や巨大なエコシステムを志向せず、「編集体験そのものの質」を最優先に設計されている点が最大の特徴といえます。</p>
2008年にリリースされて以来、その圧倒的なパフォーマンスと洗練されたUIで多くの開発者に愛されてきました。
かつてはAtomやBracketsといった競合が次々と登場する中でも独自の地位を確立していましたが、
2015年のVisual Studio Codeの登場によって状況は一変しました。
Microsoftの豊富なリソースとオープンソースモデルによって急速に機能を拡充したVS Codeは、
瞬く間に開発者コミュニティの主流となったのです。</p>
しかし、Sublime Textは市場シェアを失っても開発を継続し、現在も継続的にアップデートされています。
それを可能にしているのが、独自のビジネスモデルと一貫した設計思想です。
2026年現在もBuild 4000番台の開発が進められており、その品質は今も一級品を保ち続けています。</p>
1. 技術的・思想的特徴</h2>
1.1. 圧倒的なパフォーマンス</h3>

起動が非常に速い</li>
大規模ファイルや巨大リポジトリでも編集が軽快</li>
入力遅延がほぼ発生しない</li>
</ul>
Sublime Textの最大の強みは、何よりもそのパフォーマンスです。
エディタを起動してから実際に編集を開始できるまでの時間は、ほとんどの環境で1秒以内に収まります。
VS CodeがElectronベースでJavaScriptエンジンの起動コストを伴うのに対し、Sublime TextはC++ とカスタムUIツールキットで実装されており、
OSネイティブに近い起動速度を実現しています。</p>
また、数万行を超える大規模ファイルや、数十万ファイルを含む巨大なリポジトリでも動作が重くなることはほとんどありません。
GitのLinuxカーネルリポジトリのような巨大なコードベースでも、ファイル検索や全文検索が瞬時に完了します。
これは独自の描画エンジンとインデックス機構によって実現されており、「常に軽いこと」を最優先事項として設計されているためです。</p>
特に重要なのが、入力に対するレスポンスの速さです。キーボードからの入力が画面に反映されるまでの遅延が極めて少なく、タイピングの快適さが損なわれません。この「入力遅延のなさ」は、長時間コーディングを行う開発者にとって、想像以上に重要な要素となります。</p>
1.2. ミニマルで静かな UI</h3>

不要なアニメーションや通知が少ない</li>
情報密度は高いが、視覚的ノイズが少ない</li>
IDE的な自動介入を極力行わない</li>
</ul>
Sublime Textのユーザーインターフェースは、極めて静かです。
近年のソフトウェアに多く見られる派手なアニメーションや、頻繁なポップアップ通知、自動的に表示されるヒントやサジェストといった「親切な機能」は最小限に抑えられています。</p>
これは決して機能が貧弱だからではなく、ユーザーの集中を妨げない設計を意図的に選択した結果です。
情報密度は高く保たれており、必要な情報はすぐにアクセスできますが、視覚的なノイズは徹底的に排除されています。
エディタという道具が前面に出てくることなく、書いているコードそのものに集中できる環境が提供されているのです。</p>
また、IDEによくある「自動的な修正」や「勝手な補完」といった介入も控えめです。
開発者が意図しないコード変更や、予期しないフォーマットが適用されることはほとんどありません。
これは一見不便に思えるかもしれませんが、自分の書いたコードを完全にコントロールしたい開発者にとっては、むしろ信頼できる特性となります。</p>
1.3. 保守的で一貫した設計思想</h3>

等幅フォント・静的フォント前提</li>
Variable Fontの軸指定や高度なタイポグラフィ機能は非対応</li>
フォントフォールバックや複雑な文字組みも対象外</li>
</ul>
Sublime Textは、技術トレンドを積極的に追いかけるタイプのソフトウェアではありません。例えば、近年広まってきたVariable Font（可変フォント）の軸指定機能や、高度なタイポグラフィ機能には対応していません。また、複雑なフォントフォールバックや文字組み処理も、必要最小限にとどめられています。</p>
これを見ると「技術的に遅れている」と感じるかもしれませんが、実際には異なります。これらの機能は確かに便利ですが、実装にはレンダリングエンジンの複雑化が伴い、結果としてパフォーマンスの低下を招きます。Sublime Textは、パフォーマンス低下を招く機能を意図的に排除している</strong> のです。</p>
この姿勢は、ソフトウェア全体に一貫しています。新機能を追加する際には、常に「これはパフォーマンスに影響するか」
「これは本当にエディタに必要な機能か」という問いが立てられ、慎重に判断されています。
結果として、機能の追加ペースは遅いものの、一度実装された機能は安定しており、長期間にわたって同じように動作し続けます。</p>
1.4. 拡張は可能だが、万能ではない</h3>

Pythonによるプラグイン拡張</li>
LSP対応により、現代的な言語サポート機能は充実</li>
ただしIDE全体としての統合度はVS Codeに及ばない</li>
エコシステムは小規模</li>
</ul>
Sublime Textには、Pythonによるプラグイン機構が備わっており、機能を拡張可能です。Package Controlというパッケージマネージャーを使えば、コミュニティが開発した様々なプラグインを簡単にインストールできます。また、Language Server Protocol (LSP) にも対応しており、現代的なコード補完や定義ジャンプ、型チェックといった言語サポート機能は充実しています。</p>
しかし、VS Codeのような統合開発環境としてのトータルな統合度</strong>を期待すると、物足りなさを感じるかもしれません。デバッガやターミナル、バージョン管理といった周辺機能の統合度や、拡張機能エコシステムの規模では、VS Codeには及びません。</p>
エコシステムも、VS Codeの巨大なマーケットプレイスと比べれば小規模です。しかし、これも設計思想の表れといえます。Sublime Textは「プラットフォーム」になることを目指しておらず、あくまで「高品質なエディタ」であり続けることを選択しているのです。必要十分な拡張性は保ちつつ、複雑化や肥大化は避けるというバランスが取られています。</p>
2. 継続的な開発と進化</h2>
Sublime Textは市場シェアを失った後も、着実に開発を継続しています。2024年から2025年にかけても、
複数の重要なアップデートがリリースされており、「保守的」でありながらも「停滞していない」ことを示しています。</p>
2.1. 最近の主要アップデート</h3>
Build 4200（2025年5月リリース）</strong></p>
2025年5月21日にリリースされたBuild 4200では、以下の重要な変更が含まれています。</p>


Python プラグインの近代化</strong>: Python 3.3のサポート終了を段階的に開始し、Python 3.8への移行を進めている。さらに、次の開発サイクルではPython 3.13への移行が計画されており、プラグインエコシステムの技術的負債を解消する取り組みが進められている。</p>
</li>

OS サポートの見直し</strong>: 将来のバージョンでは、macOSの最低要件が10.9から10.13に引き上げられる。また、Windows 7、8、8.1のサポートが終了し、Windows 10以降が最低要件となる。この変更により、より新しいOS機能を活用できるようになる。</p>
</li>

UI の柔軟性向上</strong>: サイドバーを右側に配置できる sidebar_on_right</code> 設定が追加される。これは小さな変更に見えるが、長年のユーザー要望に応えたもの。</p>
</li>

ビルドシステムの強化</strong>: ビルドシステムで "interactive": true</code> を指定することで、インタラクティブな入力ボックスを表示できるようになった。これにより、コンパイル時の引数指定などがより便利になっている。</p>
</li>

構文ハイライトの刷新</strong>: SQL、ActionScript、Diff、Bash、Graphvizの構文ハイライトが書き直され、より正確で高速になった。また、ZshとTOMLの構文ハイライトが新たに追加されている。</p>
</li>
</ul>
Build 4180（2024年8月リリース）</strong></p>
2024年8月12日にリリースされたBuild 4180では、プラットフォーム固有の問題に対応しています。</p>

Linux: KDE環境でのドラッグ＆ドロップ問題への対処（kwin 6.0.4でも修正済み）</li>
Windows: スクロールバーをドラッグした際の動作改善</li>
その他、複数のバグ修正</li>
</ul>
2.2. Language Server Protocol（LSP）サポートの充実</h3>
Sublime TextのLSPサポートは、近年大きく進化しています。Package Controlから利用できる LSP パッケージ</a>は、VS Codeと同等の高度な言語サポートを実現しています。</p>
主要な言語サーバーには、以下のようなものがあります。</p>

LSP-typescript / LSP-javascript</strong>: TypeScriptとJavaScriptのサポート</li>
LSP-pyright / LSP-pylsp</strong>: Pythonの型チェックと補完</li>
LSP-rust-analyzer</strong>: Rustの高度なIDE機能</li>
LSP-intelephense / LSP-Phpactor</strong>: PHPの補完と定義ジャンプ</li>
LSP-clangd</strong>: C/C++ の高度な補完</li>
LSP-json / LSP-css / LSP-html</strong>: Web開発のサポート</li>
LSP-angular / LSP-vue</strong>: モダンなフロントエンドフレームワーク</li>
</ul>
これらのヘルパーパッケージは、言語サーバーの自動インストールと設定を簡単にし、追加機能も提供しています。例えばLSP-pylspは2025年12月にも更新されており、エコシステムが活発に維持されていることがわかります。</p>
興味深いのは、Sublime TextのLSP実装は同じファイルタイプに対して複数の言語サーバーを同時に実行できる点です。例えば、Pythonプロジェクト内のLSP-pyrightで一般的な機能を使いつつ、LSP-ruffでリンター警告を同時に表示するといった使い方が可能です。</p>
このように、Sublime Textは「保守的」な設計思想を保ちながらも、現代的な開発環境に必要な機能を着実に取り込んでいます。急激な変化は起こりませんが、必要な進化は確実に続けられているのです。</p>
3. 市場における位置づけ</h2>

かつては高速GUIエディタの代表格</li>
現在はニッチだが評価の高い存在</li>
VS Codeのような統合開発環境とは競争しない立場</li>
</ul>
2010年代前半、Sublime Textは高速なGUIエディタの代表格として、多くの開発者に愛用されていました。TextMateの後継とも目され、Macユーザーを中心に広く普及していたのです。その影響力は大きく、VS Codeの初期バージョンはSublime Textのキーバインドやショートカットを参考にしたとも言われています。</p>
しかし現在では、市場シェアという観点では完全にニッチな存在となりました。Stack Overflowの開発者調査でも、利用率は数パーセント程度にとどまっています。それでも、使い続けているユーザーからの評価は一貫して高く、「速さ」「安定性」「シンプルさ」を求める開発者の間では根強い支持を得ています。</p>
興味深いのは、Sublime Textのユーザー層です。多くは、日常的にNeovimやEmacsといったCLIエディタを使いつつ、GUIが必要な場面や、より視覚的な操作が適している場面でSublime Textを併用しています。つまり、「メインのIDE」として使うのではなく、職人的な開発者の道具箱の中の1つとして位置づけられているのです。</p>
VS Codeのような統合開発環境とは、もはや直接競争する立場にありません。機能の豊富さや拡張性では勝負せず、「軽快さ」「シンプルさ」「信頼性」という独自の価値を提供し続けることで、固有のポジションを確立しています。</p>
4. ビジネスモデル</h2>
Sublime Textが長期にわたって開発を継続できているのは、独自のビジネスモデルによるところが大きいです。多くのソフトウェアが無料化やサブスクリプションモデルに移行する中、Sublime Textは独自の道を歩んでいます。</p>
4.1. 買い切り型ライセンス + 更新権</h3>

一度購入すれば永続的に使用可能</li>
購入時点から 約3年間のアップデート権</strong> が付与される</li>
更新権が切れても使用不可にはならない</li>
新しいメジャー版や最新ビルドを使いたい場合のみ再購入</li>
</ul>
Sublime Textのライセンスは、買い切り型を基本としています。一度購入すれば、そのバージョンは永続的に使用可能です。ただし、購入時点から約3年間のアップデート権が付与され、その期間内にリリースされた新バージョンには無料でアップグレードできます。</p>
重要なのは、更新権が切れても、ソフトウェアが使用不可になることはない点です。購入時のバージョンは引き続き使用でき、セキュリティアップデートなどの重要な修正も提供されます。新しいメジャーバージョンや最新機能を使いたい場合にのみ、ライセンスを再購入すればよいのです。</p>
このモデルは、月額・年額で支払い続けなければ使えなくなるSaaS的なサブスクリプションとは明確に異なります。ユーザーは「払い続けなければ使えなくなる」というプレッシャーから解放され、自分のペースでアップグレードを判断できます。一方で、開発側も定期的な収入が見込めるため、持続可能な開発が可能になっています。</p>
4.2. 非 SaaS・低固定費構造</h3>

クラウドサービスではない</li>
常時稼働サーバや大規模インフラが不要</li>
開発チームは少人数</li>
営業・マーケティングコストが極小</li>
</ul>
Sublime Textのもう1つの強みは、極めて低い固定費構造にあります。Sublime Textはクラウドサービスではなく、ユーザーのローカル環境で完結するスタンドアロンアプリケーションです。そのため、常時稼働するサーバーインフラや、大規模なデータセンターといった継続的なコストが一切発生しません。</p>
開発チームも非常に小規模で、創設者のJon Skinner氏を中心とした数名程度で運営されていると言われています。大規模な開発組織を抱える必要がなく、人件費も抑えられています。</p>
また、営業やマーケティングにも積極的に投資していません。広告を出すこともなく、口コミとブランド力だけで販売を続けています。Sublime Textの公式サイトは極めてシンプルで、派手なマーケティングメッセージもありません。</p>
この結果、ユーザー数が爆発的に増えなくても黒字が成立する</strong>構造になっています。年間数万人程度のライセンス購入があれば、十分に開発を継続できるのです。これは、成長至上主義に陥らず、持続可能な開発を可能にする重要な要素となっています。</p>
4.3. 法人・プロユーザーによる支え</h3>

個人購入に加え、法人でのまとめ買い</li>
経費精算による定期的な更新</li>
長期利用を前提としたユーザー層</li>
</ul>
Sublime Textのユーザーには、個人利用だけでなく、法人でのまとめ買いも多いと考えられます。開発チームが一斉にライセンスを購入するケースや、企業の標準ツールとして採用されているケースもあります。特に、パフォーマンスや安定性を重視する企業にとって、Sublime Textは魅力的な選択肢となります。</p>
また、プロフェッショナルな開発者が多いため、ライセンスを経費として精算し、定期的に更新する傾向があります。個人で$99を支払うのは躊躇するかもしれませんが、会社の経費であれば、更新のハードルは下がります。</p>
Sublime Textのユーザーは、長期利用を前提としている傾向が強いです。一度使い始めたら、数年から十年以上にわたって使い続けるユーザーが多いのです。これは、Sublime Textの安定性とシンプルさが、長期的な信頼を生んでいることを示しています。</p>
一人あたりのLTV（顧客生涯価値）は、サブスクリプションモデルと比べると低めですが、非常に安定しています。ユーザーの離脱率が低く、定期的な更新が見込めるため、予測可能な収益構造となっているのです。</p>
4.4. 成長を前提としない経営姿勢</h3>

ベンチャーキャピタルに依存しない</li>
利用データの収集・広告モデルなし</li>
ユーザー数や市場シェアの拡大を至上命題としない</li>
</ul>
Sublime Textの最も特徴的な点は、成長を前提としない経営姿勢にあります。ベンチャーキャピタルからの資金調達を受けておらず、外部投資家からの「成長しろ」というプレッシャーとは無縁です。そのため、ユーザー数を爆発的に増やすことや、市場シェアを最大化することを目標とする必要がありません。</p>
また、ユーザーの利用データを収集して分析したり、広告モデルで収益化したりといったことも一切行っていません。Sublime Textは、インターネット接続を必要とせず、ローカル環境で完結するため、プライバシーの観点でも安心できます。テレメトリデータの送信もなく、ユーザーがどのような使い方をしているかは開発者にはわかりません。</p>
この経営姿勢は、現代のスタートアップ文化やシリコンバレーの常識とは真逆です。「急成長」「ユニコーン」「市場の独占」といった価値観とは距離を置き、その代わりに**「小さく、長く、静かに続ける」**ことを選択しています。</p>
これは、短期的な利益最大化ではなく、長期的な持続可能性を重視した結果です。派手さはありませんが、10年後、20年後も同じように開発が続いている。そんな可能性を信じさせてくれるのが、Sublime Textなのです。</p>
5. Sublime Merge - 同じ思想の Git クライアント</h2>
Sublime HQは、テキストエディタのSublime Textだけでなく、Gitクライアントの Sublime Merge</strong> も開発しています。Sublime Mergeは、Sublime Textと同じ設計思想をGitクライアントに適用したソフトウェアです。</p>
Sublime Mergeの特徴も、Sublime Textと共通しています。</p>

起動が非常に速く、大規模リポジトリでも軽快に動作する</li>
UIがシンプルで、視覚的なノイズが少ない</li>
複雑なGit操作も、キーボード中心の操作で素早く実行できる</li>
独自のマージツールが優れており、コンフリクト解決が快適</li>
</ul>
Gitクライアントの世界でも、GitKrakenやSourceTreeといった多機能なGUIツールが主流となっていますが、Sublime Mergeはそれらとは異なるアプローチを取っています。必要な機能に絞り込み、パフォーマンスと操作性を優先した結果、Gitの複雑な操作を快適に行えるツールとなっています。</p>
ビジネスモデルもSublime Textと同様で、買い切り型ライセンス + 約3年間の更新権という形式です。Sublime TextとSublime Mergeをセットで購入すると割引が適用されるバンドルライセンスも提供されています。</p>
私自身も、Sublime Textの思想に共鳴し、今回Sublime Textのライセンスを更新すると同時に、Sublime Mergeのライセンスも購入しました。どちらも、長く使い続けられる信頼できるツールだと感じています。</p>
6. 評価と総括</h2>
Sublime Textは次のようなソフトウェアです。</p>

主役ではなくなったが、品質は今も一級品</li>
時代の要請すべてには応えないが、軸はぶれない</li>
利便性よりも、編集体験の純度を重視</li>
商業的成功よりも、持続可能性を優先</li>
</ul>
その結果として、</p>

「勢いはないが、消えもしない」</strong></p>
</blockquote>
という独特のポジションを確立しています。</p>
現代のソフトウェア業界では、「より多くの機能」「より大きなエコシステム」「より速い成長」が正義とされがちです。しかし、Sublime Textはそれとは異なる価値観を示しています。機能を抑制し、シンプルさを保ち、持続可能な開発を優先することで、長期的な信頼を獲得しているのです。</p>
このアプローチは、すべてのソフトウェアに適用できるわけではありません。しかし、少なくとも「開発ツール」という領域においては、十分に成立する戦略であることを、Sublime Textは証明しています。</p>
Sublime Textは、現代では稀少になった職人主義的ソフトウェアと、そのビジネスモデルの実例</strong>です。派手さはありませんが、確かな品質と一貫した思想を持ち続けることで、静かに、しかし確実に生き残っているのです。</p>


Scaler3で作曲支援
2025-05-31T00:00:00+00:00


先日発売されたScaler3ですが、音楽理論を知らなくても作曲や編曲ができると話題なので購入してみました。</p>

Table of Contents</summary>

</details>
## Scaler3とは
Scaler3</a>は音楽理論やコード理論
がわからなくても凝ったコード進行が作れる作曲支援ソフトです。</p>
裏では音楽理論に基づいて適切なコード進行を提案してくれるの
その中から気に入ったコードをどんどんドラッグしてコード進行を作っていけます。</p>
「コードに合う違和感のない音はどれか」「コード進行で冒険したいが、このコード
は適切か」といったプロでも抱えてしまいそうな悩みを解消してくれます。</p>
Scaler3を検証してみた</h2>
今回は既存のメロディを取ってきてSuggest機能に従ってコード進行を作ってみまし
た。使用したのはThe Banglesの"Eternal Flame"です。</p>
またScaler3から追加されたアレンジ機能を使って伴奏を付けています。
ドラムの生成機能はないので、ドラムだけはLogic ProのPlayer機能を使っています
。</p>
前半がScaler3で生成した伴奏、後半がオリジナルのコード進行に従った伴奏です。</p>
</p>
オリジナルは、G Majorで次のようなコード進行です。</p>
G Em7 | C D | G Em7 | C D | Em B7 | Em7 A7 | D Bm7| Am7</span></span></code></pre>
ですが、 Scaler3でもっともノートとコードにのマッチ度が高かったB Phrygian
Modeでコードを構成してみました。</p>
  Bm G | C D | Em G | Am G | Em7 Dsus2 | Bm Em | A7 D| Bm7</span></span></code></pre>
メロディから判断され推奨されるコードはブルーで示されますが、
メロディをすべてマッチするわけではないんで、実際は推奨コードから試しながら
決めていくことになります。しかし、何も参考にせず自分で考えるより数倍生産性は上が
ります。</p>
オリジナルのほうが安心して聞ける印象です。
一方、Scaler3で作ったコード進行はちょっと印象が違っていますが、まぁ成り立っているのではないでしょうか。</p>
多分、メロディからコードを作るより、コード進行をScalerで練って、
メロディを提案してもらったほうがうまく働くと思います。</p>
まとめ</h2>
Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。</p>
🎯 習得難易度について</h3>
完全な素人には難しいものの、基本的な音楽理論（メジャー・マイナー、ダイアト
ニックコードなど）を理解していれば十分活用できます。 転調の提案など高度な
機能については、理論と感性のバランスを取りながら使い分けることが重要です。</p>
💡 Scaler3の真価</h3>
最大の価値は 「0→1の創作支援」</strong> にあります。白紙の状態から音楽理論に基づ
いた膨大なコード進行のアセットを参考にできるため、創作の起点として非常に強力
です。また、安全圏を抜け出した「冒険的なコード進行」への挑戦も、理論的裏付け
があるので安心して試せます。</p>
🤖 AI作曲時代における位置づけ</h3>
AIが楽曲を自動生成する時代になりましたが、創作者が主導権を握りながら音楽理
論の恩恵を受けられるScaler3のようなツールは、まだまだ重要な役割を果たすでし
ょう。</strong> 完全自動化ではなく、人間の創意工夫とテクノロジーの協働による作曲ス
タイルは、今後も価値を持ち続けると考えられます。</p>
結論として、Scaler3は音楽制作の生産性を大幅に向上させる優秀なパートナーツールです。</strong></p>


Synthersizer V Studio 2 Pro
2025-04-15T00:00:00+00:00
とりあえず、昨年Synthersizer V 1で作った藤原さくらさんの「Just One Girl</a>
」をSynthesizer V 2でヴォーカル部分をリテイクしてみました。</p>

  
  </iframe>
</div>
以前のバージョンでもかなりリアルなヴォーカルなのであまり改善点がわからないか
もしれませんが、以下に変更点をまとめておきます。</p>
Sythesizer V Studio 2 Proの変更点</h2>
次のような変更がなされています。</p>
歌声生成速度の改善</h3>
Synthesizer V 2では歌声の生成速度が改善され、以前のSynthesizer Vに比べると300% 速くなったとのことです。</p>
以前のバージョンでは編集時にノート1つ音程を変更しただけで少し待たないと再生できませんでしたが、
Synthesizer V 2では、ノートの編集後に再生できるまでの時間が短くなり待たされ
るという感覚がほぼありません。</p>
新しいボーカルモードの機能</h3>
ボーカルモードはシンガーの歌声にバリエーションを持たせる機能ですが、
Synthesizer V 2では各パラメータが「ピッチ(Pitch)」「音色(Timbre)」「発声
(Pronun)」へと分解可能となりました。</p>
これにより、ピッチに関しては「Clear」スタイルを強く適用するけれど
発声は「ソフト」スタイルを強くするなど、細かやかな調整が可能となりました。</p>
AIリテイク機能の改善</h3>
AIリテイクは、AIの技術を用いて異なる歌い方を生成できる機能です。</p>
以前のバージョンでは、「ピッチ」と「声色」のみがリテイク可能でしたが、
Synthesizer V 2から「タイミング」も生成できるようになりました。</p>
AIリテイク生成時のパラメータはXYパッドのようなインターフェイスとなり、
「Vibrant」「Refined」「Stable」「Raw」をコントロールする方式となりました。
より直感的に音を調整できます。</p>
スマートピッチコントロール</h3>
以前のSyhthesizer Vでは、ピッチ関係のパラメータは「ピッチ推移」や「ビブラー
ト」がありましたが、どのように変化するか分かりづらいものがありました。</p>
V2ではピアノロール状でピッチ制御点を直接追加できます。制御点を通るピッチカー
ブが自動生成され、制御点をドラッグするとリアルタイムにカーブが変化します。
これまでよりずいぶんと分かりやすくなりました。</p>
アクティベーション方法の変更</h3>
これまでアクティベーションコードを製品に入力する方式だったと思いますが、
今回からDreamtonicsのアカウントと紐付いて製品がアクティベーションを行うよう
になりました。</p>
従ってDreamtonicsのアカウントを作成し、そこに製品登録をきちんとやっておく必
要があります。</p>
まとめ</h2>
以前のバージョンでもかなりリアルなヴォーカルを生成できましたが、
今回のバージョンアップでより細かなコントロールが可能となりました。</p>
私自身はそこまでヴォーカルを調整することはありませんが、
エンジンとデータベースを更新するだけでも以前不自然だった部分が
かなり改善されます。</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>


Finaleがフィナーレを迎える
2024-08-27T00:00:00+00:00
採譜ソフトのFinaleが開発・販売を終了するそうです。</p>
音楽はざっくり言うと作曲->アレンジ->採譜->演奏というプロセスが必要ですが、
「採譜」というプロセスは現代では端折られることも多いし、
何か新しい革新があるわけでもないから「incremental value for our customers」
が無くなったというのは確かにそうなんだろうと思います。</p>
ただ日本のクラシック音楽界隈ではデファクトスタンダードなどで、関係者には
「Finaleがフィナーレを迎えた」などと冗談を言える雰囲気ではないくらい深刻なよ
うです。</p>
The music notation software Finale will be discontinued in terms of
development and sales.
In music, the general process involves:</p>

composition</li>
arrangement</li>
notation</li>
performance</li>
</ul>
However, the notation process is often skipped in modern times, and since there hasn't been any significant innovation in this area, it's understandable.
They feel there is "no incremental value for our customers" anymore.
That said, Finale is the de facto standard in Japan's classical music community.
So for those involved, it's not exactly a laughing matter where they can joke that "Finale has reached its finale."</p>

  Today, Finale is no longer the future of the notation industry—a reality after
  35 years, and I want to be candid about this. Instead of releasing new
  versions of Finale that would offer only marginal value to our users, we’ve
  made the decision to end its development.
  
    
      {" "}
      the finale blog -{" "}
      
        {" "}
        The End of Finale
      </a>
    </cite>
  </footer>
</blockquote>

Coded Chords - Application

pCloud DriveのmacOS Tahoe問題

References</h2>

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

Mac環境のリフレッシュ

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

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

Sublime Text - 職人主義的ソフトウェアの美学と持続可能なビジネスモデル

1. 技術的・思想的特徴</h2>

1.1. 圧倒的なパフォーマンス</h3> 起動が非常に速い</li> 大規模ファイルや巨大リポジトリでも編集が軽快</li>

Scaler3で作曲支援

まとめ</h2> Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。</p>

Synthersizer V Studio 2 Pro

Sythesizer V Studio 2 Proの変更点</h2> 次のような変更がなされています。</p>

Goodbye Bartender!

Finaleがフィナーレを迎える

まとめ</h2>
Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。</p>

Sythesizer V Studio 2 Proの変更点</h2>
次のような変更がなされています。</p>