Turborepo と Bun で作る快適フロントエンド基盤

＼スニダンを開発しているSODA inc.の Advent Calendar 2025 1日目の記事です!!!／

こんにちは。Frontend Rebirth（フロントエンドを再構築していく） チームの Maple です。

今回は、私たちのプロジェクトで検証中の Next.js × Turborepo × Bun という構成についてご紹介したいと思います。

「モノレポ構成に興味はあるけれど、設定が複雑そう」「Bun を実戦投入するのはまだ早いかな？」
そんな風に迷われている方の参考になれば幸いです。

なぜこの構成を選んだのか

もともと私たちのプロジェクトでは、1つの Next.js アプリケーション内で app/(user)（ユーザー向け）と app/(admin)（管理画面）を共存させていました。
Route Group 機能を使えばディレクトリ構成は綺麗に保てますし、コードの共有も簡単だったからです。

運用の中で見えてきた課題

しかし、サービスを運用していく中で、いくつか悩ましい場面が出てきました。

• デプロイの影響範囲
  管理画面側の修正をデプロイしたいだけなのに、もしビルドでコケるとユーザー画面のリリースまで止まってしまうというリスクがありました。
• 障害の切り分け
  片方で不具合が起きると、同じコンテナで動いているもう片方も巻き込まれてダウンしてしまう可能性があります。

Turborepo で「いいとこ取り」を実現する

そこで私たちは、Turborepo を活用したモノレポ構成 への移行を決断しました。
「コードは共有しつつ、ビルドとデプロイは明確に分ける」。
これにより、アプリを物理的に分割し、それぞれを独立した ECS サービスとしてデプロイできる体制を整えました。

そして、その足回りを支える重要なピースとして選んだのが Bun です。

1. Bun を採用した理由

正直なところ、最初は「速いとは聞くけれど、まだ時期尚早かな？」という懸念もありました。
ですが、実際に検証してみると、そのパフォーマンスの高さに驚かされました。

依存関係解決の速さ

npm install の待ち時間は、開発者にとって積み重なると大きなロスになります。
Bun はこれを劇的に短縮してくれました。特に CI 環境のように毎回クリーンな状態からセットアップする場合、この「インストールの速さ」が全体の実行時間に大きく貢献します。

Turborepo との親和性

Turborepo が Bun を公式にサポートしている点も安心材料でした。
package.json に以下のように記述するだけで、スムーズに導入できます。

package.json

{
  "packageManager": "bun@1.2.5",
  "workspaces": ["apps/*", "packages/**"]
}

2. Turborepo でタスクを最適化する

Turborepo の設定ファイル turbo.json は、一度適切に設定してしまえば、あとはツールが良きに計らってくれます。

依存関係の整理 (dependsOn)

「アプリケーションをビルドする前に、共通ライブラリのビルドを済ませておく」といった順序制御も、シンプルに記述できます。

turbo.json

    "build": {
      "dependsOn": ["^build"], // 依存しているパッケージのビルド完了を待つ
      "outputs": [".next/**", "dist/**"]
    }

キャッシュの活用 (inputs)

個人的に特に効果を感じているのが、この inputs 設定です。
「テストに関係のないファイル（README や CSS など）が変更されても、結果は変わらないはず」という意図をツールに伝えることができます。

turbo.json

    "test": {
      "inputs": [
        "src/**/*.{ts,tsx}", // 結果に影響するファイルのみを監視対象にする
        "**/*.test.{ts,tsx}"
      ]
    }

これを設定しておくことで、ドキュメント修正のみの Pull Request などではテストがスキップ（キャッシュヒット）され、一瞬で完了します。

3. 開発体験 (DX) の変化

共通コードの変更が即座に反映される

以前、リポジトリ分割（マルチレポ）を検討したこともありましたが、設定ファイルなどの整備やライブラリの重複を懸念していました。
Turborepo × Bun のワークスペース構成なら、packages/ 配下のファイルを保存した瞬間に Next.js のホットリロードが走り、アプリ側に変更が反映されます。

コマンド一つで開発環境が立ち上がる

turbo dev コマンドを実行するだけで、Userアプリ、Adminアプリ、そして必要なライブラリのビルドまで、すべて並列で立ち上がります。

4. CI/CD への効果：ビルド時間50%短縮

今回の移行で最も定量的な成果が出たのがここです。
Turborepo のキャッシュ機能により、変更がないパッケージのテストやビルドは自動的にスキップ されます。

• Before: 変更箇所に関わらず、毎回すべてのアプリ・パッケージをビルド＆テスト
• After: 変更があった箇所のみ実行（他はキャッシュを利用）

この結果、CI全体の実行時間が 約50% 短縮されました。（bunに変更したことで早くなった側面もあります）
デプロイ完了までの待ち時間が減ったことで、開発サイクル全体がスムーズに回るようになりそうです。

まとめ

特に私たちのように、「コード資産は共有したいけれど、デプロイ単位やインフラ構成は分けたい」というケースにおいて、この構成は良い選択肢になるはずです。
もし似たような課題をお持ちの方がいらっしゃれば、ぜひ一度試してみてください。