Columns

30GBの巨大モノリポでも、開発環境は重くならない ― Shopifyが〈World〉を動かす仕組み

連載「AIファースト時代の開発基盤アーキテクチャ」第2部（全3部）

第1部で、Shopifyは「割らずに、痛みを技術でねじ伏せにいった」と書きました。全社のコードを一つの〈World〉に畳み、CIが10倍に膨れても、それを成立させるインフラを自前で作る道を選んだ、と。第2部は、その“技術”の中身です。

その前に、時代の空気を確認しておきます。モノリポは長らく、「時代遅れの一枚岩」の代名詞でした。この10年、モダンな設計といえばマイクロサービス。サービスを小さく割り、リポジトリを分け、チームを独立させる。スタートアップがピッチで「うちはマイクロサービスで」と誇らしげに語ってきた、あの流れです。全部を一つのリポジトリに戻すなど、退化にしか見えなかった。

その振り子が、いま逆へ振れています。きっかけは、第1部で見たAIでした。人間の視野に合わせて割ってきた境界が、AIには壁になる。だから「開発の単位」としてのモノリポが、回帰してきた。ただし、昔の一枚岩にそのまま戻るわけではありません。戻れるようにするための、技術的な裏付けが要る。ここからが本題です。

モノリポには、昔から手を焼かされる問題があります。Gitが重くなる、CIが崩壊する、依存関係がこじれる。Shopifyの〈World〉は、コードだけで30GBを超え、数万人が触ります。常識どおりなら、真っ先に破綻するはずの規模です。それがなぜ回っているのか。鍵は、進化したGitの使い方と、Nixという少し変わったパッケージマネージャ（Shopify自身の解説は「What Is Nix」）にありました。

この記事でわかること

  • → なぜ、素直にモノリポ化するとGitもCIも破綻するのか
  • → Shopify製のビルド基盤Tectonixが、巨大リポジトリを「手元で軽く」する仕組み
  • → Nixの「誰がどこでやっても同じ」が、AIの自律実行にとってなぜ決定的なのか
  • → Shopify規模でなくても持ち帰れる、「再現性」という考え方

01 素直にモノリポにすると、まずGitが悲鳴を上げる

モノリポ化の最初の壁は、たいてい足元のGitです。

NixにはFlakesという仕組みがあり、ビルドの再現性を担保してくれます。ところがこれは、評価のたびにソースツリー全体をローカルの保管領域（/nix/store）へコピーする作りになっている。数十MBのリポジトリなら気になりません。30GBの〈World〉でやると、ディスクI/Oが枯渇し、評価速度が実用にならないところまで落ちる。素のツールを、そのまま巨大リポジトリに当てると壊れるわけです。

CIも同じでした。第1部で触れたとおり、全リポジトリの統合でCIの実行規模は一夜にして10倍に。マージ処理を捌くキューは作り直し、ビルドキャッシュそのものを内製プロダクトに仕立て直しています。「モノリポは重い」という常識は、少なくとも初日には、そのとおりに牙をむいた。第1部で挙げたクックパッドが「割る」ことで逃げた痛みと、根は同じです。違うのは、Shopifyがそこから逃げずに、道具のほうを作り替えた点でした。

02 Tectonix ― 全部コピーせず、Gitを直接読む

その道具がTectonixです。〈World〉を動かすためにShopifyが内製したビルド基盤で、Gitのsparse-checkout、NixOSのモジュールシステム、そして独自拡張を組み合わせています。名前だけ聞くと難しそうですが、やっていることは、ひとつです。全部を手元にコピーしない。

開発者は、sparse-checkoutを使って、自分の担当ぶんのファイルだけをローカルに引き出します。30GB全部は要らない。必要なゾーン（サブプロジェクトの単位）だけを手元に置く。

問題は、手元に無いコードとの依存関係をどう正しく扱うかです。ここがTectonixの勘所でした。ShopifyはNixの評価エンジンそのものをフォークし（社内でtecnixと呼ばれています）、lazy-treeという仕組みを先行投入しました。これは、実ディスク上のファイルを介さず、Gitのオブジェクトデータベースから直接ソースを読む発想です。手元にチェックアウトしていない領域も、Gitが持つハッシュのインデックスを参照して、依存グラフを正確に組み立てられる。リポジトリ全体を物理的に複製する無駄が、丸ごと消えます。

図書館にたとえると分かりやすい。全蔵書を自宅に運び込むのではなく、いま読む本だけを借りる。それでいて、目録（Gitのハッシュ）を見れば、借りていない本との関係まで正確に追える。Tectonixがやっているのは、これに近いことです。

開発者が直接触るのは、各ゾーンに置かれたzone.nixという小さな宣言ファイルだけ。「このサービスは何を必要とし、どうビルドされるべきか」という意図を書けば、複雑な評価ロジックは裏の配管が引き受けます。加えてCIの低いレイヤーには、Semgrepによる静的解析とOPA（Open Policy Agent）によるポリシー適用が入り、数百万のマーチャントに響きうる設定ミスを、マージ前に止める防衛線が敷かれています。

03 「誰がやっても同じ」が、AIの自律実行を成り立たせる

ShopifyがここまでNixにこだわったのは、再現性のためです。

ローカル、CI、本番コンテナ。この三つで、まったく同じ環境が寸分違わず再現される。人間にとっては「自分のマシンでは動くのに本番で落ちる」という、あの不毛な事故が消える。そしてAIにとっては、もっと切実な意味を持ちます。環境の差異から来る推論ノイズが消え、AIが遭遇するビルドエラーが「純粋なコードのエラー」だけに絞られる。エージェントが自分でテストを回し、結果を信じて次の手を打てるのは、この再現性があるからです。

Riverを動かすエージェント基盤Aquiferの設計も、この再現性の上に立っています。中身は三つの層に分かれている。会話と意思決定の履歴を残すSession（Postgresの追記専用ログで、クラッシュしても消えない）、思考を担う使い捨てのHarness、そして実際にコードをビルド・実行する隔離環境のSandbox。SandboxはNixで固めた使い捨てで、Harnessの外側に完全に切り離されています。仮にエージェントが誤って破壊的なコマンドを走らせても、被害の範囲（爆発半径）がそのサンドボックス内に閉じる。安全に「AIに手を動かさせる」ための、物理的な仕切りです。

04 デプロイは分けたまま、開発だけを一つにする

ひとつ、誤解を解いておきます。〈World〉が一つのリポジトリだからといって、本番が一枚岩のアプリになったわけではありません。

Shopifyは、本番へは従来どおりマイクロサービスとしてデプロイしています。畳んだのは「開発・管理の単位」であって、「デプロイと障害の単位」ではない。第1部の言い方に戻せば、サービスを割ることで得ていた障害の分離はそのまま保ちつつ、AIを苦しめていたコンテキストの分断だけを解消した、という二段構えです。開発はひとつ、デプロイは分けたまま。これが2026年時点の、大規模開発のひとつの落としどころになりつつあります。

同じ課題に、GoogleのBazelやMetaのBuck2も取り組んできました。ただしそれらは、ビルドの正しさを担保するために、npmやCargoといった言語標準のパッケージ管理を事実上「排除」し、独自のビルドルールへ書き換えることを求めます。専任チームと、大きな移行の摩擦が要る。対してTectonixは、Nixでそれら既存のツールを包み込むので、開発者は惯れた道具を捨てずに済む。Gitの物理的な限界にはlazy-treeで正面から挑む一方、言語標準のツールはそのまま残す。その無理のなさが、この方式の持ち味です。

仕上げに、Shopifyは2026年、Nix系CIのGarnixを買収しました。その中核技術call-by-hashは、マージされたコミットのハッシュから本番環境を一意に組み上げる手法で、無駄な再ビルドを挟まない瞬時のデプロイと、アトミックなロールバックを可能にします。ビルドからデプロイまでを、一本のハッシュで貫く構えです。

Flagshipとしての見立て ― Shopify規模でなくても、再現性の考え方は効く

ここまで、かなりの重装備の話をしてきました。正直に言えば、この大半は、私たちがそのまま導入するものではありません。

第1部で引いた線を思い出してください。人が手元でAIに指示を出すだけなら、sparse-checkoutもlazy-treeも要りません。クライアント名のフォルダに複数リポジトリを並べ、判断の経緯を明文化しておけば、それで足りる。Tectonix級の投資が元を取るのは、数万人が触り、自律エージェントが本番のコードを日常的に回す、あのフェーズです。これは、その規模があって初めて見合う重さです。

一方で、真似るべき思想もはっきりしています。再現性です。私たちは負荷試験のMockingbirdで本番前にわざとシステムを壊し、移行案件では手順を細かく文書に残して、誰が担当しても同じ結果に着地する段取りを組んできました。再現できない環境は、人にもAIにも危ない。この実感は、ShopifyがNixにこだわった理由 ―「どこで動かしても同じ結果になること」― と、まるきり同じです。だから私たちが実際に整えるのは、フルのTectonixではなく「再現できる環境と明文化」です。投資と効果がいちばん噛み合うのは、そこ。

限界と運用上の注意

Nixは銀の弾丸ではありません。Shopify自身、2019年ごろに一度は開発環境へのNix導入を試み、学習コストの高さで頓挫しています。今回うまくいったのも、宣言的に環境を組めるdevenvのような道具が育ち、条件が整ってからでした。

泥臭い適合も避けられません。たとえばNixの読み取り専用ファイルシステムと、書き込みを前提にした既存ツールが衝突し、Cloudflareのトンネルツールが起動時にクラッシュする、といった問題が実際に起きています（EROFSエラー）。Shopifyはバージョンをピン留めし、書き込み先を逃がす対応で解決していますが、こうした一つずつの手当ての積み重ねが、Tectonixを実用の水準へ押し上げた実体です。派手なアーキテクチャ図の裏に、地味な適合作業が大量にある。ここを見誤ると、道具だけ入れて回らない、という結果になります。

まとめ

「モノリポは重い」という常識は、進化したGit（sparse-checkoutとlazy-tree）と、どこでも同じ結果を返すNixによって、ねじ伏せられるところまで来ました。ただし、それは相応のインフラ投資とセットで初めて成り立つ話です。開発はひとつに、デプロイは分けたまま ― 大規模開発は、いまその形に落ち着きつつあります。

では、ここまでAIのために手をかけたインフラは、いったい誰を幸せにするのか。最終・第3部では、AIのために整えた環境が、そのまま人間の開発まで速くしていく話 ― DXからAX（Agent Experience）への移り変わりに踏み込みます。

参考・出典

本記事の情報は2026年7月時点のものです。Tectonix・tecnix・lazy-tree・zone.nixの実装詳細は、Shopifyの登壇資料（SCALE 23x / Planet Nix 2026）および公開リポジトリに基づく参考情報で、今後変更される可能性があります。

関連記事

Columns All