2026年最速Node.jsパッケージマネージャーAubeとは?

Ashley Innocent

Ashley Innocent

21 4月 2026

2026年最速Node.jsパッケージマネージャーAubeとは?

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

Nodeのインストールは何年も前から遅いという問題がありました。`npm install`を実行してコーヒーを淹れに行き、戻ってきてもCIがまだ`@types/node`の解決をしている、といった状況です。Aubeはその状況を変えます。実際の1,400パッケージ規模のプロジェクトのウォームCIインストールを139ミリ秒で完了させ、これはpnpmより約7.3倍、Bunより3倍高速です。本当に興味深いのは、既存のロックファイルを読み書きするため、誰も移行を求めずに月曜日から試せる点です。

このガイドでは、Aubeとは何か、どのようにしてこれらの数値を達成するのか、そのインストール方法、pnpm、npm、yarn、Bunとの比較、そして毎日ApidogのようなツールでAPIを構築している場合にどのように活用できるかについて説明します。

ボタン

Aubeとは?

Aubeはen.devによって構築され、MITライセンスの下でリリースされた高速なNode.jsパッケージマネージャーです。その名前はフランス語で「夜明け」を意味し、「オーブ」と発音します。このプロジェクトはベータ版(執筆時点ではv1.0.0-beta.10)であり、pnpm v11との互換性を目標としています。

そのコンセプトは単純明快です。Aubeはpnpmと同じディスク上のモデル、つまりグローバルなコンテンツアドレス指定ストアと分離されたシンボリックリンクレイアウトを使用しますが、インストールパイプラインはJavaScriptではなく、ネイティブスレッド言語で書かれています。同じレイアウトで、より高速なエンジンです。この一つの設計選択により、いくつかのベンチマークシナリオでBunを上回り、なおかつ`pnpm-lock.yaml`を元の場所に書き戻すことができます。

もしパッケージマネージャー間の移行を一度でも経験したことがあるなら、本当のコストはツール自体ではなく、チームの全員に`install`の実行方法を変更させることによる社会的なコストであることをご存知でしょう。Aubeは`pnpm-lock.yaml`、`package-lock.json`、`npm-shrinkwrap.json`、`yarn.lock`、および`bun.lock`を直接読み込むことで、この問題を回避します。CIがまだpnpmを使っている間でも、ローカルでAubeを実行でき、チームメンバーにとっては何も変わりません。

Aubeのベンチマーク:「最速」とはどれくらい速いのか?

ベンチマークの対象は、約1,400パッケージの実世界のプロジェクトで、hyperfineを使って時間を計測しました。すべてのシナリオは、コミットされたロックファイルがあることを前提としています。変動する軸はキャッシュのウォーム状態です。*ウォーム*は`node_modules`をクリアしますが、グローバルストアとパキュメントキャッシュは保持します。*コールド*はすべてを消去します。

公式ベンチマークの数値(aube 1.0.0-beta.3、bun 1.3.12、pnpm 10.33.0、npm 11.12.1、yarn 1.22.22、node 24.15.0):

シナリオ aube bun pnpm yarn npm
CIインストール(ウォームキャッシュ、node_modulesなし) 139ms 416ms 1.01s 2.43s 2.78s
CIインストール(コールドキャッシュ、node_modulesなし) 1.12s 935ms 1.57s 6.60s 4.21s
install && run test(既にインストール済み) 21ms 42ms 453ms 351ms 615ms
依存関係の追加(add is-odd 209ms 414ms 1.33s 2.55s 2.89s

いくつか注目すべき点があります。ウォームCIインストールは主要な数値であり、これは実際のパイプラインで最も一般的なケースを反映しています。そこではランナーがキャッシュを復元し、グローバルストアにはすべてのtarballがハッシュ化されて残っています。そのシナリオでは、Aubeはpnpmより約7.3倍、Bunより3倍高速です。

`install && run test`のシナリオは、日常的な開発者のループを測定します。すべてのツールは、「まずインストールしてからスクリプトを実行する必要があるか?」を判断しなければなりません。Aubeは、インストール状態ファイルが最新であればインストール作業を完全にスキップできるため、`install && test`のループ全体が21ミリ秒で完了します。他のツールは、スクリプトを実行する前にロックファイルを再検証するため、400ミリ秒から600ミリ秒のオーバーヘッドが発生します。

コールドキャッシュでは、Bunのtarball取得パスが非常に最適化されており、コールドインストールはI/Oに支配されるため、BunがAubeをわずかに上回ります(935ミリ秒対1.12秒)。ウォームキャッシュは一般的な開発チームで日に何千回も実行されるシナリオであり、コールドキャッシュはランナーを破棄する際に月に一度実行されるシナリオです。

すべてのフィクスチャセットにおいて、ドキュメントではシナリオによってpnpmより最大22倍、Bunより最大3倍高速であると指摘されています。これらすべては、Aubeリポジトリから`mise run bench`を実行することでローカルで再現できます。

AubeがpnpmやBunより高速な理由

3つの設計選択がその重い作業を担っています。

これは魔法ではありません。これは、pnpmのレイアウトを採用し、JavaScriptのブートストラップを排除し、99%のインストールが「実際には何も変更されていない」という仮定に基づいてCLIを設計した結果です。

Aubeのインストール方法

推奨されるパスは、ポリグロットツールマネージャーであるmiseです。

mise use -g aube

PATHに設定されたか確認します。

aube --version

npmがお好みの場合:

npm install -g @endevco/aube

Homebrewを使用しているmacOSまたはLinuxでは、Endevのtapで入手できます。

brew install endevco/tap/aube

プロジェクト内で、Aubeのバージョンをローカルで固定できます。

mise use aube

これは`mise.toml`に`aube`をツールとして書き込み、プロジェクトフォルダに入るすべてのシェルが同じバージョンを使用することを意味します。もはや「去年pnpm 10をインストールしたから私のマシンでは動く」という状況はなくなります。インストールに関するドキュメントでは、tarballやOSごとのオプションも説明されています。

日常的に実際に使うコマンド

コマンドはpnpmに酷似しているため、慣れた操作がそのまま使えます。

aube install              # 依存関係をインストール
aube add react            # 依存関係を追加
aube add -D vitest        # 開発依存関係を追加
aube remove react         # 依存関係を削除
aube update               # package.jsonの範囲内で更新
aube run build            # package.jsonスクリプトを実行
aube test                 # テストスクリプトを実行。古ければまずインストールする
aube exec vitest          # ローカルのバイナリを実行
aube dlx cowsay hi        # 使い捨て環境でパッケージを実行
aube ci                   # CI用のクリーンで固定されたインストール

それらのほとんどを短縮できます。スクリプトが`package.json`に存在する場合、`aube dev`は`aube run dev`と同じです。同じバイナリには、2つのマルチコールシムも同梱されています。

aubr build       # aube run build
aubx cowsay hi   # aube dlx cowsay hi

パイプラインでは`aube ci`を使用します。これは`node_modules`を削除し、現在の`package.json`に対してロックファイルが最新であることを確認し、それからインストールします。ロックファイルにずれがあった場合、大音量で失敗します。これはCIで望ましい挙動です。

ロックファイルの互換性

これがAubeを低リスクで導入できる機能です。チーム全体で切り替えることを約束する必要はありません。

ロックファイル 読み込み その場で書き込み
aube-lock.yaml はい はい
pnpm-lock.yaml v9 はい はい
package-lock.json v2/v3 はい はい
npm-shrinkwrap.json はい はい
yarn.lock (v1 classic + v2+ berry) はい はい
bun.lock はい はい

実際のパターンは次のようになります。あなたのチームはpnpmを使用しています。CIではまだ`pnpm install --frozen-lockfile`を実行しています。あなたのマシンでローカルに`aube install`を実行します。それは`pnpm-lock.yaml`を読み込み、同じ`node_modules`レイアウトを生成し、解決の更新を同じ`pnpm-lock.yaml`に書き戻します。チームメイトがあなたのブランチをプルし、`pnpm install`を実行しても、何も問題は起きません。時間が経ち、Aubeがその有用性を証明すれば、CIを移行します。そうでなければ、それを削除しても下流の誰も気づきません。

2つの注意点があります。古いpnpm v5またはv6のロックファイルは、まずpnpmでアップグレードする必要があります。また、yarn PnPプロジェクト(`.pnp.cjs`スタイル)は、AubeがPnPアーティファクトではなく`node_modules`を書き込むため、`node_modules`リンカーに戻す必要があります。

セキュリティデフォルトはあなたが思う以上に重要です

過去18か月間にJavaScriptのコードベースに触れたことがあるなら、サプライチェーンインシデントが積み重なっているのを目にしてきたことでしょう。npmのサプライチェーンセキュリティガイドにそのパターンが記載されています。Axios npmの侵害は、単一の人気依存関係がどのように数千の開発者マシンにクロスプラットフォームRATを送り込むことができるかを示す、最も明確な現実世界の事例の1つでした。

Aubeは、インストールを利便性ではなくセキュリティ境界として扱う3つの明確なデフォルト設定を採用しています。

  1. 最小リリース期間。新しいリリースは、Aubeがインストールする前に設定可能な最小期間を待ちます。新しく侵害され、2時間以内に取り消されたパッケージは、あなたの`node_modules`に決して触れることはありません。
  2. 異種依存関係のブロック。Aubeは、疑わしい形状(異常なURL、パッチのようなエントリ、通常セマンティックバージョンを持つ場所にGitリファレンス)を持つ推移的依存関係をブロックします。明示的に必要とする場合は、承認します。
  3. ライフサイクルスクリプトの承認。依存関係の`postinstall`スクリプトはデフォルトでスキップされます。特定のパッケージ(esbuild、node-sass、ローカルで実際にビルドする必要があるものなど)を許可するには、`aube approve-builds`を実行します。スクリプトがスキップされたパッケージは`aube ignored-builds`に表示されます。

これらの3つの挙動があなたを無敵にするわけではありませんが、「そのパッケージがコードを実行することさえ知らなかった」を「私はそのパッケージにコードを実行させることを選択した」に変えます。それは次の本番インシデントの前に望ましいセキュリティ体制です。

Nodeモジュールのレイアウト

Aubeは分離された`node_modules`レイアウトを使用します。トップレベルの`node_modules/`には、`package.json`で宣言された依存関係が含まれます。推移的依存関係は`node_modules/.aube/`の裏側に存在します。パッケージファイル自体は`$XDG_DATA_HOME/aube/store/`に1度だけ格納され、これはデフォルトで`~/.local/share/aube/store/`となります。

3つの結果:

以前にフラットな`node_modules`レイアウト(従来のnpmまたはyarn v1)を使用していた場合、ファントムインポートに依存していた破損したパッケージが1つか2つ見つかることを予想してください。その解決策は常に「`package.json`に追加する」です。

ワークスペースとモノレポ

Aubeはワークスペースと`workspace:`プロトコルをサポートします。

aube install -r
aube run test -r
aube add zod --filter @acme/api

もしあなたのリポジトリに既に`pnpm-workspace.yaml`がある場合、Aubeはそれを読み書きします。Aubeを最初に使う新しいワークスペースは`aube-workspace.yaml`を使用します。`-r`(recursive)と`--filter`フラグは、pnpmで期待されるのと同じセマンティクスにマッピングされるため、TurborepoやNxのセットアップは変更なく機能し続けます。

APIモノレポにとって、ウォームキャッシュのCI実行時間が最も重要です。もしあなたのパイプラインがマージごとに`install, build, test, publish contract`を実行する場合、10個のパッケージでpnpmの1秒からAubeの139ミリ秒に`install`時間を短縮すると、1日あたり数分もの時間節約になります。

API開発ワークフローにおけるAubeの活用

APIを構築およびテストする場合、インストールはすべてのリファクタリングのホットパスに位置します。リクエストスキーマを修正し、TypeScriptクライアントを再生成し、再インストールし、モックサーバーに対してコントラクトテストを実行し、これを繰り返します。高速なインストールは単なる見栄えの良い数値ではありません。「これを変更した」という時点と、「それが壊れたかどうかを知る」という時点の間の時間間隔を意味します。

うまく機能する実践的なループ:

  1. ApidogでAPIを設計し、モックを作成します。他のチームと連携するものであれば、コードファーストよりもスキーマファーストが優れています。
  2. Nodeプロジェクト内で型付きクライアントを生成するか(またはApidogのモックに対してコントラクトテストを実行)、
  3. クライアントを反復作業中に、Aubeをローカルで使用してインストール時間をミリ秒単位に保ちます。
  4. 同じテストスイートを`aube ci`でCIに組み込みます。

昨年からPostmanからのツールシフトは、より大きなパターンの一部です。開発者は高速でローカルファースト、そしてデフォルトで安全なツールを求めています。Aubeは、インストールステップに適用された同じ話です。もしVS Code内でApidogを既に実行しているなら、その隣にAubeを導入するには1行の`mise use`コマンドだけで済み、ホットリロードごとに数秒を節約できます。

各パッケージマネージャーからの移行

現実世界での考慮事項

よくある質問

結論

2026年のほとんどのNodeプロジェクトでは、インストールステップは必要以上に遅いです。Aubeは、実際の開発ワークフローで支配的なウォームインストールおよび繰り返しコマンドパスにおいて最速のNode.jsパッケージマネージャーです。1,400パッケージのCIインストールで139ミリ秒、何も変更がない場合の`install && test`で21ミリ秒、複数のプロジェクトがあるマシン全体でディスク容量を90%削減します。既存のロックファイルを読み込み、セキュリティデフォルトを真剣に受け止め、`mise use aube`の一行で試すことができます。

もしApidogのような高速でローカルファーストのクライアントでAPIを既にテストしているなら、Aubeはインストール側でそれに合うピースです。まだApidogをダウンロードしていない場合は、次のNodeサービスでAubeと組み合わせて、フィードバックループがどれほど緊密になるかを確認してください。

ボタン

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる