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つの設計選択がその重い作業を担っています。
- ネイティブかつスレッド化されたインストールパイプライン。 npm、pnpm、yarnはすべてNode.jsでインストールエンジンを実行します。これは、すべてのハッシュ計算、すべてのtarball展開、すべてのシンボリックリンク呼び出しがJavaScriptのディスパッチコストを伴うことを意味します。AubeはホットパスをV8からネイティブコンパイルされたネイティブスレッドランタイムに移行させます。Bunも同様のことを行いますが、パッケージマネージャーと並行して完全なJavaScriptランタイムを提供します。Aubeはインストールパス専用に構築されており、これがウォームインストールでBunを上回る理由の一部です。
- グローバル仮想ストアがデフォルト。 pnpm v11で`enableGlobalVirtualStore`が追加されましたが、プロジェクトのインストールではデフォルトではありません。Aubeはグローバル仮想ストアをデフォルトとするため、重複する依存関係を持つ繰り返しプロジェクトは、ほとんどの場合、ディスク上に既に存在するパッケージツリーにリンクされます。もしReact、Vite、TypeScript、Playwrightをすべて使用する3つのサービスがある場合、重いファイルは1箇所に置かれ、すべてのプロジェクトがそこへシンボリックリンクを張ります。ドキュメントでは、典型的なモノレポ設定でnpmと比較して約90%ディスク容量が削減されると見積もられています。
- フレッシュ状態ファイルによるインストールショートサーキット。 `aube run test`はまずコンパクトなインストール状態ファイルをチェックします。`package.json`とロックファイルのハッシュが状態ファイルと一致する場合、インストールフェーズは1回のstat呼び出しで済み、テストはすぐに実行されます。これが`install && test`の数値を21ミリ秒まで引き下げています。
これは魔法ではありません。これは、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つの明確なデフォルト設定を採用しています。
- 最小リリース期間。新しいリリースは、Aubeがインストールする前に設定可能な最小期間を待ちます。新しく侵害され、2時間以内に取り消されたパッケージは、あなたの`node_modules`に決して触れることはありません。
- 異種依存関係のブロック。Aubeは、疑わしい形状(異常なURL、パッチのようなエントリ、通常セマンティックバージョンを持つ場所にGitリファレンス)を持つ推移的依存関係をブロックします。明示的に必要とする場合は、承認します。
- ライフサイクルスクリプトの承認。依存関係の`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つの結果:
- 重複する依存関係を持つ複数のプロジェクトが、ディスク上のパッケージファイルを共有します。もはや「モノレポやサイドプロジェクト全体でlodashが12個もコピーされている」といった状況はなくなります。
- ファントム依存関係は難しくなります。パッケージが`package.json`になければ、`node_modules/`に存在しないため、トップレベルから`require`することはできません。これはpnpmが提供する保証と同じです。
- 繰り返しインストールでは、ディスク上に既に存在するファイルを再利用します。残りの作業は、ストアから新しい`node_modules/.aube/`へのハードリンクだけです。
以前にフラットな`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クライアントを再生成し、再インストールし、モックサーバーに対してコントラクトテストを実行し、これを繰り返します。高速なインストールは単なる見栄えの良い数値ではありません。「これを変更した」という時点と、「それが壊れたかどうかを知る」という時点の間の時間間隔を意味します。

うまく機能する実践的なループ:
- ApidogでAPIを設計し、モックを作成します。他のチームと連携するものであれば、コードファーストよりもスキーマファーストが優れています。
- Nodeプロジェクト内で型付きクライアントを生成するか(またはApidogのモックに対してコントラクトテストを実行)、
- クライアントを反復作業中に、Aubeをローカルで使用してインストール時間をミリ秒単位に保ちます。
- 同じテストスイートを`aube ci`でCIに組み込みます。
昨年からPostmanからのツールシフトは、より大きなパターンの一部です。開発者は高速でローカルファースト、そしてデフォルトで安全なツールを求めています。Aubeは、インストールステップに適用された同じ話です。もしVS Code内でApidogを既に実行しているなら、その隣にAubeを導入するには1行の`mise use`コマンドだけで済み、ホットリロードごとに数秒を節約できます。
各パッケージマネージャーからの移行
- npmからの移行。プロジェクトで`aube install`を実行します。Aubeは`package-lock.json`を読み込み、それを書き戻します。フラットではなく分離された`node_modules`になるため、ファントムインポートに注意してください。もし問題が発生した場合、不足しているパッケージを`package.json`に追加して先に進んでください。詳細なワークフローはnpmユーザーガイドに記載されています。
- pnpmからの移行。オンディスクレイアウトが同じであるため、最も摩擦の少ない移行です。Aubeは`pnpm-lock.yaml` v9を直接読み込みます。`workspace:`プロトコルは機能します。フィルターも機能します。`pnpm-users`ページには、挙動が異なる少数のフラグがリストされています。
- yarnからの移行。Aubeはv1 classicとv2+ berryの両方のロックファイルを読み込みます。Aubeは`node_modules`を書き込み、`.pnp.cjs`は書かないため、Yarn PnPユーザーはAubeを試す前に`nodeLinker: node-modules`モードに戻す必要があります。
- Bunからの移行。Aubeは`bun.lock`を読み込みます。主な違いは、BunのパッケージマネージャーがBunのJSランタイムと密接に結合しているのに対し、Aubeは任意のNode.jsバージョンで動作するスタンドアロンのインストールツールであることです。もしあなたが既にmiseをNodeのバージョン管理に使用しているなら、Aubeも同じように組み込むことができます。
現実世界での考慮事項
- ベータ版のステータス。2026年4月現在、Aubeはv1.0.0-beta.10です。ドキュメントには明示されており、pnpm v11との互換性を目指していますが、まだ多くのプロジェクトでテストされていません。他の1.0未満のツールと同様に扱ってください。まずローカルで実行し、既存のロックファイルを保持し、1ヶ月間動作することを確認するまでは、本番リリースパイプラインをこれに賭けないでください。
- 対象外となるもの。Aubeは、miseが既に実行していることを意図的に重複させません。ランタイム管理(`env`、`runtime`、`setup`、`self-update`)はmiseの領域です。いくつかのレジストリアカウントヘルパー(`whoami`、`token`、`owner`、`search`、`pkg`、`set-script`)は、npmコマンドを指す互換性スタブです。もしCIスクリプトがこれらのいずれかを呼び出す場合、フォールバックとしてnpmを残しておいてください。
- プラットフォームのサポート。推奨されるインストーラーはmiseで、macOS、Linux、およびWSL経由のWindowsをサポートします。tarball経由のネイティブWindowsサポートは存在しますが、まだ初期段階です。現在の対応状況についてはインストールページを確認してください。
- コミュニティ。このプロジェクトにはDiscord(ホームページからリンク)があり、執筆時点でGitHubで325のスターを獲得しています。小規模ですが活動的です。BuildkiteがプロジェクトのCIを提供しており、リポジトリのルートで確認できます。
よくある質問
- 「aube」は何を意味しますか?フランス語で「夜明け」です。「オーブ」と発音します。このプロジェクトのキャッチフレーズは「Nodeインストールの新しい夜明け」です。
- Aubeはpnpmのドロップイン代替ですか?概ねそうです。pnpm v11との互換性を目指し、pnpmのロックファイル形式を読み込みます。ほとんどのpnpmに似たワークフローは変更なしで移行できます。一部のpnpmコマンド(ランタイム管理、いくつかのレジストリヘルパー)は、他のツールに属するため、意図的に対象外とされています。
- ローカルでpnpmを使いながら、CIでAubeを使用できますか?はい、どちらの方向でも機能します。Aubeは`pnpm-lock.yaml`をその場で読み書きするため、2つのツールはロックファイルを共有できます。チームは通常、逆の方法で開始します。つまり、ローカルでAubeを使い、CIでpnpmを使い、全員が慣れるまでそうします。
- AubeはBunとどう比較されますか?ウォームインストールでは、Bunがインストール前に多くの状態を再検証するため、AubeはBunより約3倍高速です。コールドインストールでは、Bunの取得パスが非常に最適化されているため、Bunがわずかに先行します。BunはJSランタイムも提供しますが、Aubeはインストール専用です。もしあなたが既にNodeを使用しているなら、Aubeを使うためにBunのランタイムは必要ありません。pnpmスタイルの分離レイアウトの比較は、レイアウト選択がなぜ重要であるかの背景を提供します。
- AubeはWindowsで動作しますか?WSL経由であればはい。ネイティブWindowsも動作しますが、まだ初期段階です。miseは3つのOSすべてでインストールと更新を行う最も簡単な方法です。
- Aubeはオープンソースですか?はい、MITライセンスで、ソースコードはGitHubにあります。
- 既存の`pnpm-lock.yaml`はどうなりますか?Aubeはそれを読み込み、インストールを実行し、解決の変更があれば同じファイルに書き戻します。pnpmを実行しているチームメイトは、通常のロックファイルの差分を確認できます。
結論
2026年のほとんどのNodeプロジェクトでは、インストールステップは必要以上に遅いです。Aubeは、実際の開発ワークフローで支配的なウォームインストールおよび繰り返しコマンドパスにおいて最速のNode.jsパッケージマネージャーです。1,400パッケージのCIインストールで139ミリ秒、何も変更がない場合の`install && test`で21ミリ秒、複数のプロジェクトがあるマシン全体でディスク容量を90%削減します。既存のロックファイルを読み込み、セキュリティデフォルトを真剣に受け止め、`mise use aube`の一行で試すことができます。
もしApidogのような高速でローカルファーストのクライアントでAPIを既にテストしているなら、Aubeはインストール側でそれに合うピースです。まだApidogをダウンロードしていない場合は、次のNodeサービスでAubeと組み合わせて、フィードバックループがどれほど緊密になるかを確認してください。
