個人的環境構築 2026

はじめに

最近、ツールチェーンやバージョン・パッケージマネージャーが多様化し、管理が難しくなっています。 mise や proto のような、パッケージマネージャーのパッケージマネージャー的存在まで浮上する始末です。 そのうち、何を何で管理していたか分からなくなったり、アップグレードを怠ってしまうのがオチです。

本記事では、私が繰り返し PC を初期化してきた経験から、最も良いと感じているソフトウェアの管理方法を紹介します。

対象読者

• これから MacOS の環境構築をしたい人
• 環境構築に一定の思想を持っている/持ちたい人

この記事で紹介すること

• 各パッケージの管理ルール
• 特に Node.js の管理ルール

この記事で紹介しないこと

• 具体的なインストール方法
• macOS 以外の環境構築

概要

以下の対象についてバージョン管理方法を考えます。

• アプリケーションソフトウェア
• 言語処理系
• パッケージマネージャー
• ライブラリ

以下のフローチャートに従います。が、このフローチャートは説明をだいぶ省略しているので注意してください。

言葉の定義

裏がある言葉があるので、先に定義しておきます。

バージョン管理機能

ここでは、バージョン管理機能を、「あるツールチェーンの使いたいバージョンをシームレスに使うことができる機能」と定義します。

使いたいバージョンは、ソフトウェアによって変わります。例えば、ほとんどのデスクトップアプリは常に安定版を使いたいですし、言語処理系はプロジェクトごとに最適なバージョンが指定されています。パッケージマネージャーは、言語処理系に合わせたバージョンを使いたいです。ライブラリは、プログラムが動くために必要なバージョンを使いたいです。

シームレスは、そのバージョンを使うのに、積極的な操作が必要ないことを指します。例えば、言語処理系やパッケージマネージャーはプロジェクトのディレクトリで実行するだけで自動で選択されてほしいです。ライブラリはパッケージマネージャーでインストールコマンドを実行するだけで、必要なバージョンがインストールされてほしいです。アプリは、最新版が出たら自動でアップデート、もしくはアップデートの通知が来て、ワンクリックでアップデートできて欲しいです。

例えば、いろいろなバージョンを使いたいのに常に最新版しか使えなかったり、アプリの最新版がリリースされたことを確認するのにいちいち自分からコマンドを実行しなければならないというのは、バージョン管理機能がない状態です。

Homebrew は upgrade コマンドを実行しなければアップグレードできないので、ここではバージョン管理機能とは呼びません。

要するに、何も考えずに、使いたいバージョンを使える状態が、バージョン管理機能がある状態です。

Homebrew でインストール可能

Homebrew でインストール可能とは、公式が Formula の管理をしている、もしくはコミュニティ管理の Formula ではあるものの公式が Homebrew でのインストールを推奨している状態です。

Homebrew は誰でも Formula を作成したり更新したりするための PullRequest を作成できるので、公式が関与していない Formula も存在します。しかし、公式が関与していない Formula は、更新が遅れたり Evil のリスクがあったりするため、そういったものは除外します。

インストール

インストール方法を指定せず、単にインストールという場合は、公式が最も推奨する方法でインストールすることを指します。また、この記事内では、インストールやアップデート、バージョン管理などをまとめてインストールと呼ぶことがあります。

以下、優先度の高い順に管理ルールを説明していきます。

パターン 1

自分自身にバージョン管理機能がある場合です。この場合は、公式推奨の方法でインストールします。

パターン 2

デファクトスタンダードのバージョンマネージャーがある場合で、バージョンマネージャー自身にもバージョン管理機能がある場合です。この場合は、デファクトスタンダードのバージョンマネージャーを公式推奨の方法でインストールして、目的のソフトウェアはバージョンマネージャーで管理します。

ここで、デファクトスタンダードは、私の独断になりますが、おおよそ以下のような判断基準です。

• コミュニティが活発であること
• 継続的に保守されていること
• 機能やパフォーマンスが優れていること

パターン 3

デファクトスタンダードのバージョンマネージャーがある場合で、バージョンマネージャー自身にはバージョン管理機能がないものの、Homebrew でインストール可能な場合です。この場合は、デファクトスタンダードのバージョンマネージャーを Homebrew でインストールして、目的のソフトウェアはバージョンマネージャーで管理します。

パターン 4

デファクトスタンダードのバージョンマネージャーがある場合で、バージョンマネージャー自身にバージョン管理機能がなく、Homebrew でもインストールできない場合です。この場合は、デファクトスタンダードのバージョンマネージャーを公式推奨の方法でインストールして、目的のソフトウェアはバージョンマネージャーで管理します。

パターン 5

デファクトスタンダードのバージョンマネージャーがない場合で、Homebrew でインストール可能な場合です。この場合は、Homebrew でインストールします。

パターン 6

デファクトスタンダードのバージョンマネージャーがない場合で、Homebrew でインストールできない場合です。この場合は、公式推奨の方法でインストールします。

理念

このルールの制定には、以下のような理念があります。

公式は正義

多くのソフトウェアは、推奨のインストール方法やバージョン（いわゆる LTS）、使用方法を定めています。多くの人はそのような環境でソフトウェアを使用しており、開発者もその環境に太鼓判を押しています。よって、推奨環境ではバグ報告がされやすく、修正も早いです。

そのため、同様の環境で使用することで最も安定した状態で使用することができます。逆に、そこから外れると、バグが発生しやすく、セキュリティリスクも高まります。特に、開発ツールについては、他の開発者と環境を合わせる必要があるため、推奨環境に則るべきです。

ソフトウェアはリスク

一般に、ソフトウェアのインストールはリスクです。バックドアを仕込まれたり、脆弱性を悪用されるリスクがあるからです。よって、理想的には最小限のソフトウェアのみをインストールするべきです。

ソフトウェアの中でも、信頼できるところが管理しているものや、多くの人に使われているもの （とりわけデファクトスタンダードと呼ばれるもの）、シンプルなものはリスクが少ないです。一方、誰が作っているのか分からないようなものは基本的に入れない方がいいです。

とはいえ、CVE やサイバー攻撃が飛び交う昨今、信頼できるソフトウェアもいつ攻撃されるか分からないので、いずれにしても、必要なソフトウェア以外は入れない方がいいです。

これは、バージョンマネージャーにも同様のことが言えます。目的のソフトウェアをインストールするために、バージョンマネージャーを入れることはリスクを増やすので、できれば避けたいです。

バージョン管理機能は重要

とはいえ、バージョン管理機能は多くの場合必要です。セキュリティ的な目線で言うと、適切にバージョンが管理されていれば、ゼロデイ脆弱性の影響を軽減できます。

また、環境の汚染を防ぐ役割もあります。言語処理系によってはプロジェクトごとに異なるバージョンが必要になる場合があります。この時、プロジェクトに合わせたバージョンの言語処理系をグローバルにインストールしていると、環境が汚染されてしまいます。そういったツールは、そのソフトウェアを参照することのできるスコープを最小限にする必要があり、そのためにはバージョン管理機能が必要です。

よって、バージョン管理機能がないソフトウェアに対しては、必要最低限のバージョンマネージャーを導入するべきです。

Homebrew はまだマシ

しかしながら、全てのソフトウェアにバージョン管理機能が組み込めるわけではありません。また、ソフトウェアの導入がリスクであるというところから、よく分からない人が作っていたり、保守されていないバージョンマネージャーを入れるくらいなら何も入れない方がマシです。

しかし、だからと言ってバージョン管理を諦めることもしづらいです。そこで、Homebrew が登場します。

macOS のパッケージマネージャーのデファクトスタンダードが Homebrew であることは疑いようがありません。汎用的なパッケージマネージャーにバージョン管理を任せている多くの macOS 対応ソフトウェアは、Homebrew でインストール可能です。それどころか、Homebrew でのインストールを推奨しているソフトウェアも多くあります。

そのため、バージョンマネージャーとしては機能が不十分かもしれませんが、管理が難しいソフトウェアは可能な限り Homebrew でインストールすることにします。全てを Homebrew で管理していれば、upgrade コマンドを叩くハードルも下がります。

ただし、再三になりますが、Homebrew はコミュニティ管理で更新が遅い場合や Evil のリスクがあるということは念頭に置いておくべきです。

理念に反する例

開発ツールでグローバルインストール

uv や cargo、npm、go mod などの洗練されたパッケージマネージャーでは、ツールをグローバルインストールする機能があります。

世のソフトウェアの中にはそのような機能を使ってインストールすることを推奨するものもありますが、基本的には使うべきではありません。グローバルインストールされたツールはバージョン管理が難しいためです。であれば、Homebrew を使った方がまだマシです。

一方これには例外もあり、プロジェクトの中でそのツールを使う必要があるのであれば、グローバルインストールではなく、そのプロジェクトの依存関係としてインストールするべきです。そうすることで、他の開発者も同じバージョンを使うことで環境の不整合を防ぐことができます。

この方法は、バージョン管理ができており、スコープも絞られているため、理念に反しません。

全てを一つのパッケージマネージャーで管理

Nix や mise などの一部のパッケージマネージャーは特定の思想を持っています。そのようなパッケージマネージャーの思想を体現しようと思うと、全ての対応ソフトウェアをそのパッケージマネージャーで管理する必要があります。

しかしながら、各ソフトウェアには（特に開発ツールでは）それぞれのコミュニティで成熟されたパッケージマネージャーがあり、それを使いたい場合が多いです。例えば、uv や pnpm、cargo、go mod などはプロジェクト単位で使用するツールが指定されますし、実際これらは各言語に特化した優れたバージョン管理機能を持っています。開発者としては、当然使いたいです。

一方、これらの優れたツールは自分自身のバージョン管理ができる機能が備わっています。それを無視して、優れたパッケージマネージャーを別の思想を持ったパッケージマネージャーで管理すると言うのは、シンプルに頭が悪いですし、「公式は正義」、「ソフトウェアはリスク」という理念にも反します。

実例

以上のルールと理念に基づき、一部のソフトウェアについて、私がどのように管理しているかを紹介します。

Node.js

Node.js 周りの開発ツールは、pnpm をデファクトスタンダードのパッケージマネージャーと位置付け、次のような管理にしています。

• pnpm: 公式の手順に従いスタンドアロンインストール（パターン 1）
• Node.js: pnpm runtime コマンドでインストール（パターン 2）
• npm: pnpm i -g npm コマンドでインストール（パターン 2）

Node.js 公式の推奨は nvm ですが、上記インストール方法に比べて必要なソフトウェアが増えてしまうため、pnpm を選択しています。この方法は pnpm の推奨ですし、どうせ pnpm しか使わないので。

LaTeX

公式の推奨だと macTeX ですが、macTeX は TeX Live のフルインストール相当のインストールが走るため、余計なパッケージがたくさん入ってしまいます。そこで、TeX Live により必要なパッケージだけをインストールしています。

終わりに

ただの思想の垂れ流しでした。サイバー攻撃が蔓延っているので、皆さんも気をつけてください。