Columns

AIにコードを任せるほど、分かれたリポジトリが「壁」になる ― Shopifyが全社のコードを一つ〈World〉にまとめた理由

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

この記事でわかること

  • → マルチリポジトリが、AIエージェントによる横断開発で摩擦になりやすい理由
  • → Shopifyがモノリポ〈World〉と再現可能な開発環境を整備した背景
  • → 複数クライアントを支援する企業が、機密性を守りながら同じ考え方を活かす方法
  • → モノリポを検討するときに、メリットとあわせて見るべき運用コスト

AIがコードを書くこと自体は、すでに珍しくありません。実務上の論点は、AIにどこまでの変更を任せられるか、そして正しい判断に必要なコードや設計情報をどこまで渡せるかへ移っています。

Shopifyは2026年5月、社内のAIコーディングエージェント「River」の運用実績を公開しました。直近30日で59,918セッションが実行され、Riverが共同作成者となったプルリクエストは3,536件。Shopify全体でマージされたプルリクエストのおよそ8件に1件にあたります。

この規模の活用を支えているのは、モデルやプロンプトだけではありません。Shopifyは2024年春、出荷するコードをモノリポ〈World〉へ統合し、ローカル開発・CI・本番環境をNixで再現できる基盤づくりを始めていました。

本稿では、マルチリポジトリがAIエージェントの利用でなぜ課題になりやすいのかを整理したうえで、Shopifyの〈World〉から当社が何を学べるかを考えます。結論から言えば、重要なのは「すべてを一つのリポジトリに入れること」ではなく、AIが許可された範囲のコードと知識を、一貫した状態で参照・検証できるようにすることです。

マルチリポジトリは、なぜ合理的だったのか

リポジトリを機能やチームごとに分ける設計には、明確な利点があります。担当範囲を小さく保ち、アクセス権を分け、チームごとにリリースサイクルを持てるためです。システムの境界と組織の責任範囲を揃えやすいことも、マルチリポジトリの強みです。

フロントエンド、バックエンド、在庫、出荷などを別々のチームが担当する場合、「自分たちの変更に必要な範囲だけを見ればよい」状態は、人間の認知負荷を下げます。マイクロサービスとマルチリポジトリが広がった背景にも、こうした合理性がありました。

したがって、AIエージェントを使うからといって、マルチリポジトリが直ちに誤った設計になるわけではありません。課題が表れやすいのは、複数の境界をまたぐ変更をAIに任せる場面です。

AIエージェントでは、リポジトリの境界が摩擦になりやすい

AIエージェントにフルスタックな変更を任せるとき、主に二つの摩擦が生じます。

必要な変更を一度に見渡せない

たとえばShopifyの開発では、ストアフロント、カスタムアプリ、ERP・WMSなどの外部連携が、別々のリポジトリで管理されることがあります。商品属性を一つ追加するだけでも、ストアフロントの表示、Webhookのデータ変換、同期処理、テストを一緒に変更しなければならない場合があります。

AIがストアフロントのリポジトリしか参照できなければ、画面上の変更は正しくても、外部連携側が古いデータ構造のまま残る可能性があります。参照を許可されたリポジトリを同じワークスペースから見られれば、AIは影響範囲を横断して検索できます。一方、必要なコードが参照範囲に含まれていなければ、その不足はモデルの性能だけでは解決できません。

設計意図や運用知識がコードから離れている

AIが必要とするのは、ソースコードだけではありません。設計上の判断、障害対応の手順、命名規則、テストの実行方法、変更してはいけない領域なども必要です。これらがWiki、チャット、担当者の記憶に分散していると、AIはコードの形だけを見て判断することになります。

コンテキストウィンドウの大きいモデルを選ぶだけでも解決しません。必要な情報が参照範囲に存在しない、アクセスが許可されていない、あるいは古いまま更新されていない場合、AIはそれを補えないためです。重要なのは、必要な知識をコードの近くに置き、変更と一緒に更新できる状態にすることです。

Shopifyは、コードと知識を〈World〉へ集約した

Shopifyは2024年春、次の二つを決めたと説明しています。

  • Shopifyが出荷するコードを、一つのモノリポ〈World〉へ統合する
  • ローカル開発環境、CI、本番イメージをNixで構築し、同じ実行環境を再現できるようにする

背景には、「今後、コードはAIによって書かれる割合が増え、開発インフラはそのための基盤になる」という見立てがありました。統合は容易ではなく、ShopifyによればCIには桁違いの処理能力が必要になり、マージキュー、ビルドキャッシュ、テスト基盤も作り直しています。

その投資によって、〈World〉では次のことが可能になりました。

  • 変更を横断して検証できる ― コード、呼び出し側、テスト、ドキュメントを同じ変更単位で扱えます。
  • 実行環境を再現できる ― 開発者の手元、CI、本番で同じNixベースの環境を使い、AIも同じ条件でビルドやテストを実行できます。
  • 知識をコードと一緒に更新できる ― 設計意図、runbook、開発規約、AGENTS.md、スキル定義などが同じツリーに置かれます。
  • 調査経路を一つのワークスペースに保てる ― 本番ログから関連コードや原因となったコミットまでを横断して追えます。

ここで注目したいのは、モノリポだけを導入したのではない点です。再現可能な環境、速いCI、明文化された知識、変更を安全に統合する仕組みまでを一体で整えています。AIエージェントが機能するのは、これらが揃っているからです。

Shopifyは、コードを再び分割して負荷を逃がすのではなく、統合を維持したまま、その負荷を開発基盤への投資で吸収する道を選びました。〈World〉を実際に動かす技術については、第2部で詳しく取り上げます。

Flagshipとしての見立て ― 越えてはいけない境界を守りながら、文脈をつなぐ

Shopifyは一つの会社として、コードを一つの〈World〉へ統合できました。複数のクライアントを支援する当社では、同じ形をそのまま採用することはできません。

クライアントごとのコードには、機密保持、知的財産、アクセス権限の境界があります。クライアントAとクライアントBのコードを同じ場所に集め、同じAIに無条件で参照させるべきではありません。これは技術で取り払う障壁ではなく、守るべき境界です。

一方で、プロジェクトをまたいで再利用できる知識もあります。たとえば、Shopify移行で先に確認すべき項目、負荷試験の進め方、日本向け会員ページで見落としやすい要件、アクセシビリティや多言語対応の検証手順などです。個別の機密情報を含めずに一般化できれば、組織の共通知識として育てられます。

当社では、この考え方を二層に分けて設計するのが現実的だと考えています。

  • 契約の内側に閉じた「案件内World」 ― その案件で参照を許可されたリポジトリ、設計判断、運用手順、テスト方法、やり取りの記録を一つの作業範囲として整えます。作業領域、認証情報、AIのセッションは案件ごとに分離し、別案件の情報が混ざらないようにします。
  • 案件を横断するFlagshipのナレッジ層 ― 特定のクライアントに依存しない設計パターン、チェックリスト、プロンプト、検証ツールを共通資産として管理します。案件内の知識を共通化するときは、機密情報を除き、抽象化とレビューを経てから必要な案件へ配布します。

この二層を混同しないことが重要です。案件内の具体的なコードや情報は外へ出さず、共通知識へ移すときは抽象化とレビューを行う。AIに広いコンテキストを与えることと、アクセス範囲を無制限に広げることは同じではありません。

ここでは、三つの段階を分けて考える必要があります。複数リポジトリを同じワークスペースに置くと、AIが横断して参照できるようになります。モノリポに統合すると、コード、テスト、ドキュメントを一つの変更・CI単位として検証しやすくなります。さらに再現可能な実行環境があれば、AI自身がビルドやテストを実行し、その結果を次の判断に使えるようになります。

人がAIへ指示を出し、結果をレビューする段階であれば、まずは同じワークスペースから始められます。AIが自律的に変更、テスト、マージまで進める段階では、モノリポや統合された検証基盤の価値が大きくなります。

当社では、コラムの執筆や日々の技術検討についても、結果だけでなく判断の過程をリポジトリへ残す取り組みを進めています。知識をコードの近くに置き、人にもAIにも参照できる形で更新するという点で、〈World〉から学べることは少なくありません。

モノリポは目的ではなく、運用基盤とセットで考える

モノリポは万能ではありません。統合によって依存関係が見えやすくなる一方で、CIの負荷、ビルド時間、権限設計、コードオーナーシップ、変更の衝突といった課題が大きくなります。

Shopifyは、こうした課題に対して統合を維持したままインフラへ投資する道を選びました。一方、クックパッドは巨大なRailsアプリケーションの改善において、計測と可視化を進めながら、責任範囲の明確化やマイクロサービスへの分割を進めました。どちらか一方が普遍的な正解なのではなく、システムの変更特性、組織構造、運用基盤によって適切な境界は変わります。

モノリポ化を検討するときは、少なくとも次の点を確認する必要があります。

  • 複数領域をまたぐ変更が、どの程度の頻度で発生するか
  • 統合後のCI・ビルド・テストを継続して改善できるか
  • コードオーナーとアクセス権限を明確に保てるか
  • 設計文書や運用手順を、コード変更と一緒に更新できるか
  • AIが実行した変更を、人がレビューし検証できる体制があるか

多くの組織では、最初からモノリポへ移行する必要はありません。まず、複数リポジトリをまたぐ変更を洗い出し、参照を許可されたコードを案件単位のワークスペースへまとめ、依存関係とテスト手順を明文化する。そこでなお、変更や検証を別々に行うことがボトルネックになる場合に、モノリポ化とCI基盤への投資を検討するのが現実的です。

まとめ

AIエージェントに横断的な開発を任せるうえでは、モデルの性能だけでなく、AIが参照できるコードと知識の範囲、その鮮度、検証環境が重要です。Shopifyの〈World〉は、モノリポ、再現可能な環境、CI、文書化された知識を一体で整えた事例だと捉えられます。

複数のクライアントを支援する当社にとって、契約や機密性の境界は守るべき前提です。そのうえで、案件内では必要な文脈をつなぎ、案件外では一般化した知識を共通資産として育てる。この二層の設計が、AIファースト時代の開発基盤を考える出発点になると考えています。

第2部では、巨大な〈World〉を手元で軽く扱うTectonixと、どこでも同じ実行環境を再現するNixを中心に、Shopifyがモノリポを実際に動かす仕組みへ踏み込みます。

参考・出典

本記事の情報は2026年7月時点のものです。Shopify社内ツールに関する数値は、Shopifyが公開した直近30日間の実績に基づきます。

関連記事

Columns All