nativefier macの使い方｜2026年に動く範囲と、詰まる4か所

毎日開くサイトが20枚のタブに埋もれて、目的のものを探すところから1日が始まる。この状態を抜けるために「nativefier mac 使い方」で検索した人が最初に知るべきなのは、コマンドの書き方ではなく、この道具がいまどういう状態に置かれているかです。インストールは通り、ビルドも数分で終わり、Dockに新しいアイコンが並びます。表面上は何の問題もありません。それでも判断が要るのは、出来上がったアプリの中身が2023年の時点で凍結されているからです。ここでは使い方の実際と、Macで詰まる場所、そして凍結が意味することまでを順に見ていきます。

2026年のnativefierが置かれている状態

まず事実の確認から始めます。公開されている最後の版は52.0.0で、公開日は2023年8月25日です。その約5週間後、2023年9月29日にリポジトリは作者の手で書庫入り（アーカイブ）になりました。以後、新しい版は出ていません。

書庫入りは「動かなくなった」という意味ではありません。npmの登録は残っているため、導入コマンドはいまも通ります。ビルドも成立します。変わったのは、不具合が直らないこと、新しいmacOSやNode.jsへの追随が止まったこと、そして後述するブラウザエンジンが更新されなくなったことの3点です。

作者が書庫入りの理由として挙げているのは、状況が変わったという一点です。この道具が作られた当時、ChromeやFirefoxにサイトを独立した窓として登録する機能はありませんでした。いまはどちらにもあります。同じ目的をブラウザ側の機能で満たせるなら、そちらのほうが安全だという判断です。

Nativefier is unmaintained and has been publicly archived. Users who want to build and use their own website wrappers should strongly prefer these options as they are protected from security vulnerabilities by the browser's self updating mechanism. 出典: github.com

つまり、この道具を選ぶ理由が「Dockにアイコンが欲しい」だけなら、2026年時点ではブラウザの機能で足ります。それ以外の目的があるかどうかが、使い方を学ぶ前に決めるべき最初の分岐です。

使い方の基本と、最初の1本

導入は1行です。Node.jsが16.9以降、npmが7.10以降であることが条件で、npm install -g nativefier で本体が入ります。ここが2026年のMacで最初に転ぶ場所でもあります。2023年に公開が止まったパッケージは、いま出回っているNode.jsの版では一度も試されていません。導入が通らない場合、記事の続きを読む前にNode.jsの版を切り替える判断が要ります。

最初の1本は、URLと名前と絵柄を指定するだけです。名前は--nameで決めます。Dockに出る文字とアプリケーションフォルダの名前がこれになるため、あとから変えるくらいならビルドの時点で決めておくほうが早いです。絵柄は--iconで、.icns形式か、変換に耐える大きさの正方形のPNGを渡します。

絵柄の指定を飛ばすと、共通の初期アイコンのアプリがいくつも並びます。タブの海から抜け出すために作ったはずのアプリが、今度はDockの中で見分けのつかない列になるという結果になり、これは実際によく起きます。

Apple Silicon搭載のMacでは、出来上がりの形式を確認してください。--arch arm64という指定があるのは、この判定が意図どおりにならない場面があるためです。x64向けのアプリはRosetta 2を介して起動しますが、Rosetta 2の導入が前提になるうえ、得るものは何もありません。

実際に効くオプション

多くのオプションのうち、使い勝手に直結するのは次の5つです。

• --internal-urls：アプリの中に留めるURLを正規表現で指定する。指定しないと、外部リンクを1つ踏んだだけでアドレスバーの無いブラウザに変わってしまう
• --single-instance：2つ目が起動しないようにする。アイコンを押すたびに窓が増える事故を防ぐ
• --tray：窓を閉じてもメニューバーに常駐させる。1日中開く道具向けの設定で、たまにしか開かないサイトには向かない
• --counter：ページのタイトルに含まれる数字をDockのアイコンに出す。メールや通知の未読数を表示させる用途
• --inject：CSSかJavaScriptのファイルを毎回の読み込み時に適用する。サイト側に設定が無い装飾の変更や要素の非表示を実現する

この中で最後まで残る理由になるのは--injectです。ブラウザ側の機能では代わりが利かないためです。逆に言えば、この5つのどれも要らないのであれば、ビルドを覚える必要はありません。

もう1つ、指定せずに手に入る利点があります。作ったアプリはそれぞれが独立した保存領域を持つため、同じサービスの2つのアカウントを2つのアプリに分けて同時に開けます。切り替えの操作が要らなくなるこの性質が、実務では絵柄よりも価値を持つ場面が多くあります。

Macで詰まる4か所

導入が終わったあとに待っている問題は、おおむね次の4つです。

配布で止まる。自分の端末で作ったアプリは、そのまま自分の端末で開けます。ところが同じものを同僚に渡すと、macOSが開発元を確認できないとして起動を止めます。回避するにはApple Developer IDでの署名とAppleの公証が要り、そのためにはApple Developer Programへの参加（年額99米ドル）が必要です。2分で終わるビルドの後ろに、この重さが控えています。

ログインで止まる。Googleは組み込み型のブラウザからのログインを遮断しており、包んだアプリはその判定に引っかかります。画面には、このブラウザまたはアプリは安全でない可能性がある、という趣旨の表示が出ます。回避策として使われるのが--user-agentで現行Chromeの名乗りを渡す方法ですが、これは中身を変えずに名札だけ書き換える行為です。

保護された動画で止まる。ElectronにはWidevineの復号モジュールが同梱されていません。DRMで保護された配信は再生できないため、音楽や映像のサービスはそもそもこの方式に向きません。

拡張機能が無くて止まる。パスワード管理も広告の抑制も、ブラウザの拡張機能に頼っている場合は使えなくなります。日常的に開くサイトほど、この不在は効いてきます。

中身のChromiumが2023年で止まる仕組み

nativefierが作るのはElectronのアプリです。ElectronはChromiumとNode.jsを1つにまとめたもので、アプリはそれを自分の中に抱えて配布されます。ビルドの瞬間に、そのアプリのブラウザエンジンの版が決まります。

52.0.0が同梱するのはElectron 25.7です。Electron 25が抱えるのはChromium 114とNode.js 18.15で、Chromium 114がChromeの安定版として配られたのは2023年5月です。この数字はアプリを再起動しても、macOSを更新しても、隣でChromeが更新されても動きません。同梱されたエンジンが新しくなるのは、誰かが新しいElectronで作り直したときだけです。

比較のための数字を1つ置きます。2026年9月初旬時点のmacOS向けChrome安定版は152で、同じ月からChromeの更新間隔は4週間から2週間へ短くなりました。差は38世代あり、月に2回ずつ開いていきます。Electron側も、修正が入るのは最新3系統だけと定めているため、Electron 25はとうに対象外です。

作ったあとに残る手間を先に見積もる

ビルドが2分で終わるため、作った時点では手間がゼロに見えます。実際に発生する手間は、作ったあとに繰り返しやってきます。

まず、ビルドに使った指定を残す作業です。放置されている包みアプリのほとんどは、URLだけを渡して作られています。名前も絵柄も内部に留めるURLの指定も無いまま並んでいるため、あとから作り直そうとしても、何をどう指定したのかを誰も再現できません。指定を書き留めていない状態は、実質的に作り直しの選択肢を失っている状態です。

次に、内部に留めるURLの調整です。ログインの途中で認証の提供元へ移動するサイトは多く、その移動先を含めていないとログインが完了しません。逆に広く取りすぎると、アドレスバーも履歴も拡張機能も無いブラウザの中に迷い込むことになります。この範囲は最初の1回では決まらず、使いながら直す前提で考えるほうが現実的です。

最後に、作り直す時期の管理です。エンジンが自動で新しくならない以上、期日は自分で持つしかありません。半年ごとに全部を作り直すのか、壊れてから対応するのかを先に決めておかないと、どちらも起きないまま古いアプリだけが残ります。3本や4本なら手作業で回せますが、10本を超えたあたりから、この管理そのものが目的だったはずのタブ整理より重くなります。

ブラウザ側で済む場合と、済まない場合

同じ目的を満たす手段を並べると、判断は単純になります。

手段	エンジンの更新	他人のMacへ配れるか	アプリごとの独立した保存領域
nativefierで作る	作り直したときだけ	署名と公証を自分で行えば可	あり
Electronを直接書く	作り直して配り直したときだけ	開発者登録が前提	あり
Chromeでアプリとして登録	Chromeと一緒に自動	端末ごとに登録	プロファイル単位
SafariでDockに追加	macOSと一緒に自動	端末ごとに登録	Safariと共有
専用の作成ツールを使う	ツール次第	ツール次第	ツール次第

見るべき列は2列目だけです。下2行は自分で更新するソフトの更新に乗るため、放置しても古くなりません。上2行は誰かが作り直すまで古いままです。窓とアイコンだけが目的なら下2行で足り、--injectや独立した保存領域が要るなら上に戻る、という分け方になります。

どのサイトをアプリにすべきかの見極め

最後に、対象の選び方です。手段よりも、どのサイトを選ぶかで結果が変わります。

判断の材料になるのは、他の人が何をアプリにしているかです。実際に独立させて使われているサイトの一覧は対応サービス一覧にまとまっており、空欄にURLを打ち込んで考えるより早く候補が絞れます。傾向としては、1日に何度も開くもの、複数のアカウントを使い分けるもの、通知の数を見たいものが上位に来ます。

必要な機能の側から絞るなら、独立した窓・独立した保存領域・メニューバーへの常駐・ページへの手入れといった項目ができることに整理されています。この一覧と、自分が--injectや--trayに期待していたことを突き合わせると、ビルドを覚える価値があるかどうかが判定できます。

作る手順そのものは使い方ガイドにまとまっており、1つのサイトを独立させるまでの流れが確認できます。ビルドスクリプトを書いて保守する労力と比べたうえで決めるのが、遠回りに見えて確実です。

見極めの基準は1つに集約できます。半年に1度、すべてのアプリを作り直す予定を自分の暦に入れられるか。入れられるなら手元でビルドする形が成立します。入れられないなら、エンジンの更新を引き受ける側にいる手段を選ぶほうが、結果として長く使えます。