AIコーディングの待ち時間は、モデルやCPUより先に、ファイルシステムの小ファイル処理で伸びることがあります。エージェントは git worktree add、依存関係の install、クリーン削除を短い間隔で繰り返します。各操作は数十万のディレクトリエントリに触れるので、テクノロジー選定では「Macが遅いか」より「自分のリポジトリでどの操作が何秒かかるか」を先に測る方が役に立ちます。この記事は Linux へ一律移行する手順ではなく、測ったあとに残す・出す・分けるを決める判断材料です。
📑目次
出典の役割
- 同週の独立確認として、The Neuron（2026-08-21） は、macOS から Linux へ移したあとにエージェント性能が大きく伸びた、という報告を AI コーディングツール欄で伝えています。
- 公開されている秒数と容量の表は、daily.dev（2026-08-20） が再掲したデモ環境の値です。
- 日本語の二次まとめとして BigGo ファイナンス にも同じ話が載っていますが、採用判断の根拠にはしません。
この記事では、次の3点を整理します。
- 公開値の読み方
- macOS に残す条件
- Linux へ移す前の計測手順
公開数値の見取り図
公開ベンチは順位表ではありません。CPU、SSD、モノレポ規模が違うデモ機の記録です。次の表は、移行の可否を決める前に「どの操作を自分でも測るか」を決める材料です。
| 操作 / 指標 | macOS 側の公開値 | Linux 側の公開値 | 読者の読み方 |
|---|---|---|---|
| クリーン / 削除 | M1 Max 31秒 | ext4（Ryzen）6秒 | 約5倍。SSDの生速度差だけでは説明しにくい |
| node_modules install | M1 Max 44秒 | ext4 4.5秒 | 約10倍。キャッシュ済みでも差が出る、という報告 |
| 125 worktrees の容量 | ext4 75GB | XFS+VDO 24GB | 約3倍の差は VDO 前提。ext4 単体では膨らむ |
| worktree 作成（hard link 有効時） | APFS では悪化する報告あり | 7秒 → 2.85秒 | リンク戦略は OS で符号が逆になり得る |
出典：daily.dev（2026-08-20）（2026年8月時点）
The Neuron 側は「性能差がある」ことだけを確認しており、この容量表は持っていません。数字をそのまま自機の期待値に使わないでください。
エージェント開発でファイルシステムが先に詰まる理由
問題の本質は「Macが遅い」ことではありません。エージェントが量産する小ファイル負荷と、各ファイルシステムの設計目標がずれている点にあります。
git worktree が並列ツリーの土台になる
git-worktree は、同一オブジェクトデータベースを共有したまま、別ディレクトリに作業ツリーを足す公式手段です。
第一級コマンドは次のとおりです。
git worktree addgit worktree removegit worktree list
サブモジュールの複数チェックアウトは実験的です。エージェントがブランチごとにツリーを増やす運用は、この Primitive の上に乗っています。Git 側の履歴と安全網の置き方は、AIコーディングエージェントをGitで運用する｜履歴・worktree・安全網 と重ねて読むと整理しやすいです。
pnpm のストアと hard link
パッケージ側では、pnpm の git worktrees 手順 が公式に、bare リポジトリ + worktree + enableGlobalVirtualStore: true を示します。
グローバル仮想ストアを使うと、各ツリーの node_modules は共通のコンテンツアドレスストアへ symlink します。既定ではツリーごとに .pnpm 仮想ストアを持ち、hard link かコピーになります。
pnpm FAQ が明記している点は次のとおりです。
- hard link すると見かけの容量と実ブロックが一致しない
- ストアとプロジェクトが別ファイルシステムならコピーに落ちる
- 信頼境界を共有しないエージェントに、同一の書き込み可能ストアを渡してはいけない
APFS が最適化している対象
一方、Apple の APFS 役割ガイド は、APFS を暗号化前提の独自ファイルシステムとして説明します。対象は iPhone / iPad / Mac など Apple 機器です。
設計目標として挙げるのは次のとおりです。
- Flash / SSD
- CoW メタデータ
- クローン
- スナップショット
- I/O の合体
「開発者向けの小ファイル処理が最速」とは書いていません。コンシューマ向けフラッシュ最適化を、エージェントのメタデータ負荷にそのまま当てはめない方が安全です。
先に測る3操作
読者の次の一手は、自分のリポジトリで次の3点を一度測ることです。
- 1本の worktree 追加
- キャッシュ済み install
- clean / 削除
この3点が揃えば、公開表のどの行が自分に効くのかが見えてきます。
テクノロジー視点で公開ベンチマークを意思決定に落とす
数字はデモ環境での報告値です。自分のモノレポとパッケージマネージャで、符号が同じであることを確認してから移行を決めてください。
再掲されている公開値
daily.dev が再掲した値は次のとおりです。
- M1 Max の clean 31秒 / install 44秒に対し、AMD Ryzen 上の ext4 は 6秒 / 4.5秒。差は 5〜10倍と整理されています。
- 125本の worktree では、ext4 が 75GB、XFS+VDO が 24GB です。
- 速度と容量のバランスとして推されているのは XFS+LZ4/VDO です。ZFS と Btrfs は、この用途では不適と整理されています。
- macOS 向けの CoW 補助として名前が出る Rift（Anomaly）は、最終コミットが約2か月前で、放棄の可能性がある、と注記されています。
カーネル文書が保証する範囲
公式の裏取りとして、Linux カーネルの dm-vdo 設計文書 は次を説明します。
- インライン重複排除
- 圧縮
- ゼロブロック除去
- シンプロビジョニング
数値の上限は次のとおりです。
- ブロック上限は 4K
- 重複排除は最大 254:1
- 圧縮は最大 14:1
出自は Permabit（2009年開始、2013年製品化、2017年に Red Hat 買収後オープンソース化）です。24GB という特定値はカーネル文書には記載がありません。VDO は「容量を詰める仕組みがある」ことの公式根拠であり、「125本なら必ず3分の1になる」ことの保証ではありません。
意思決定に落とすときの注意
読み方の注意は3つです。
- CPU 世代も SSD も揃っていません。5〜10倍はハードウェア差を含みます。
- 容量比は VDO 前提です。VDO なしの ext4 では 75GB に膨らむ、という同じ表の行を同時に見てください。
- クロック制限デモや個別スイート名は、二次再話の範囲に留めます。本文の根拠は daily.dev の再掲表、The Neuron の同週確認、公式ドキュメントに限定します。
意思決定用には、次の4列を自分の紙に埋めてください。操作、自機の秒数、予備 Linux 箱の秒数、差。差が再現してから、実行層を移すか残すかを決めます。現場では、公開表の一点突破よりこの4列の方が実用的です。
Linuxへ移す前に使う判断チェックリスト
「全部移す」ではなく、エージェント実行層だけを Linux に切り出せるかどうかで判断してください。ノート1台の GUI 作業まで移す必要はありません。
判断に使う5つのチェック
判断に使うチェックは次の5つです。
- 常用の並列 worktree は 2〜3本か、常時 8本以上か。
- キャッシュ済み
pnpm installが 15秒を超えるか。 - clean / 削除が 20秒を超えるか。
- ディスクが 1TB 超の worktree 残骸で埋まっているか。
- GUI や computer-use を macOS に残す必要があるか。
2と3が継続して閾値を超えるなら、予備機で同じリポジトリを1本クローンし、同じ3操作を並べて記録します。1が小さく5が必須なら、移行より上限管理を優先すべきです。
関連する境界は次のとおりです。
- ハーネス側の指示・ガード・検証の分け方は、エージェントLoopを安全に回すハーネス設計 が近いです。
- テスト結果そのものをエージェントに握らせない話は、コーディングエージェントのテスト改ざんを見抜く と分けて考えてください。
- ファイルシステムを速くしても、検証境界は別問題です。
予備機での計測手順
予備機の手順は短くて足ります。
- Linux を入れ、速度だけ見るなら ext4 でよい。公開値でも ext4 は十分速いです。
- 容量を詰める目的があるときだけ、XFS の上に VDO を置く構成を検討します。
git clone --bareのあと、git worktree addでツリーを足します。- グローバル仮想ストアを使うなら、先に
pnpm-workspace.yamlへenableGlobalVirtualStore: trueを入れ、各ツリーでpnpm installします。 - 終わったツリーは
git worktree removeします。放置は安いですが、溜まります。
VDO を置くときの運用コスト
VDO はブロック層の最適化です。バックアップ、スナップショット、暗号化の運用コストが増えます。ノート1台運用では得しないことがあります。次の一手は、本番を触らず予備機で同じリポジトリを測ることです。
macOSに残す場合に切れる現実的な選択肢
移行しない選択は妥当です。ただし hard link と worktree 数の上限を先に決めてください。
現実的な切り方は次のとおりです。
- worktree を増やさず、ブランチ切替と stash で足りるか確認する。足りないなら 2〜3本に上限を置く。
- pnpm のストアを、プロジェクトと同じボリュームに固定する。別ファイルシステムへのコピー落ちを避けるためです。
- グローバル仮想ストアは、信頼できるエージェント同士に限定する。
- Rift のような CoW 補助は、メンテ状況を見てからにする。最終コミットが止まっているツールを本番前提にしない。
- APFS のクローンとスナップショットは、コンシューマ用途では強いです。エージェント税の免除ではありません。
公開報告では、APFS 上で hard link を有効にすると install が悪化する、という話があります。自環境で on / off を1回ずつ測ってください。符号が逆なら、Linux 側の 7秒→2.85秒をそのまま期待してはいけません。
GUI 作業が主体なら、Mac をオーケストレータとして残し、重い実行だけを Linux へ SSH で行う分割運用も有効な選択肢です。技術判断としては、「全部 Linux」にするより「どの層がメタデータ待ちをしているか」を分ける方が、再現性が高くなります。
よくある質問（FAQ）
公開の 5〜10倍差を自機でも期待してよいですか？
A. いいえ。CPU、SSD、モノレポ規模が違います。同じ3操作（worktree 追加、キャッシュ済み install、clean）を測ったあとで、差を解釈してください。
ストレージが3分の1になるのは普通ですか？
A. その比は、125本の worktree と XFS+VDO の公開例です。VDO なしの ext4 では逆に 75GB へ膨らみます。カーネル文書が保証するのは重複排除 254:1、圧縮 14:1 の上限であり、24GB という特定値ではありません。
出典：daily.dev（2026-08-20） / dm-vdo 設計
pnpm 以外でも同じことが起きますか？
A. 小ファイルの作成と削除が多いなら起き得ます。ただし hard link の符号はパッケージマネージャ依存です。使っているツールで測ってください。pnpm 公式は、ストアとプロジェクトが別ファイルシステムならコピーに落ちると書いています。
出典：pnpm FAQ / pnpm git worktrees
macOS のまま並列エージェントを増やす最短策は何ですか？
A. worktree 数の上限、同一ファイルシステム上のストア、終わったツリーの削除です。新しい CoW ツールを入れるより先に、この3つを固定してください。
公式は「APFSが遅い」と言っていますか？
A. 言っていません。Apple 文書は暗号化、フラッシュ、CoW、スナップショットを設計目標として書きます。遅さの数値は第三者の公開ベンチです。The Neuron も「公式が APFS を遅いと認定した」とは書いていません。
出典：
関連記事:
- コーディングエージェントのテスト改ざんをテスト差分の先読みと検証分離で見抜く
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
まとめ
AIコーディングのボトルネックは、エージェントが量産する小ファイル操作と、ファイルシステム設計の不一致になりやすいです。公開されている 5〜10倍や 3分の1容量は、特定デモ機と VDO 前提の値です。この記事は Linux へ全部移す前提ではなく、測ってから残すか分けるかを決める判断材料です。
次の一手は、自分のリポジトリで worktree add、キャッシュ済み install、clean/delete を測り、秒数を記録することです。その秒数で macOS に残す、エージェント実行層だけを Linux へ出す、Mac オーケストレータ + Linux SSH に分ける、のどれにするかを決めます。キャッシュ済み install が 15秒超、または clean が 20秒超なら予備 Linux で同じ3操作を並べます。超えなければ移行せず、worktree 上限と同一ボリュームのストアを先に固定します。VDO は容量が主目的のときだけ検討し、速度だけなら ext4 で足りることが多いです。
残る不確実性もあります。公開数値は特定デモ機です。Rift の継続は不明です。人気や二次まとめの見出しは、採用理由にしないでください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す