Nativefierとは｜何ができて、どこで詰まるか

Nativefierとは何かを調べている人は、たいていブラウザのタブに並べたままのサイトを、独立した窓に出したいと考えています。名前だけ見ると何かのアプリのように読めますが、実体はコマンドラインの道具で、URLを1つ渡すとそのサイト専用のmacOSアプリを組み立てて置いていきます。ただしこの道具は2023年9月に開発が止まっており、いま手元に入れて使えるかどうかは、何に使うつもりかで答えが変わります。ここでは、この道具が具体的に何をするものなのか、どこまで機能を持っているのか、そしてどの段階で手が止まるのかを順に見ていきます。

Nativefierという名前が指しているもの

Nativefierはインストールして開くアプリではありません。npmから入れるコマンドラインの道具で、端末に nativefier 'example.com' と打つと、そのサイトを開くための実行ファイルが手元に出来上がります。macOSであれば拡張子が .app のもの、Windowsであれば .exe のものが生成されます。作ったあとはコマンドの側は不要で、出来上がったアプリだけが残ります。

出来上がるものの土台はElectronです。ElectronはChromiumというブラウザの描画部分とNode.jsを1つの実行ファイルに束ねたもので、いわゆるデスクトップアプリの多くがこの上に載っています。つまりNativefierがやっているのは、ブラウザの中身をそのまま1サイト専用に閉じ込めて、名前とアイコンを付け直す作業です。ブラウザの機能拡張でもプロファイルでもなく、単体で動く実行ファイルが増える点が、他の手段との一番の違いになります。

ライセンスはMITで、生成したアプリの配布にも制限は掛かりません。開発のきっかけはREADMEに書かれており、メッセンジャー系のサイトを開くたびにブラウザへ切り替えて大量のタブから目的のものを探す手間を減らす、というところから始まっています。用途の出発点が「タブから出す」だった点は、いまこの道具を検討している人の動機とほとんど同じです。

この道具が持っている機能

単にURLを窓に入れるだけの道具ではなく、ビルド時に指定できる項目がかなり細かく用意されています。代表的なものを挙げると、次のようになります。

• 名前とアイコンの自動取得。指定しなければ、対象サイトから拾って付けます
• 任意のJavaScriptとCSSの差し込み（--inject）。サイト側の見た目や挙動を自分の側で上書きできます
• 内部として扱うURLの範囲指定（--internal-urls）。範囲の外に出るリンクは、既定のブラウザ側で開きます
• 二重起動の抑止（--single-instance）。すでに開いていれば、その窓を前に出します
• メニューバー常駐（--tray）。閉じるボタンで終了せず、アイコンとして残ります
• ウインドウの初期サイズ、最小最大、常に手前、タイトルバーの形（--width --always-on-top --title-bar-style など）
• プロキシ規則やBasic認証の情報をアプリ側に埋め込む指定

保存領域についても知っておく価値があります。生成されたアプリはブラウザとCookieを共有しないため、同じサービスの別アカウントを別々のアプリに入れておくことができます。逆に、ブラウザ側でログアウトしてもアプリの側はログインしたまま残ります。この分離は利点にも落とし穴にもなります。

--portable を付けると、Cookieやキャッシュを含む利用データをアプリのフォルダ内に置く形になります。持ち運べる代わりに、そのまま人に渡すとログイン情報ごと渡ることになるため、公式の説明でも手順を分けて注意が書かれています。

出来上がったアプリの中身

生成物のサイズを見ると、この方式の性格がはっきりします。中に入っているのはブラウザの実行環境そのもので、Electron 25.7.0のmacOS向け配布物は、Apple Silicon用の圧縮された状態で84.0MBあります。展開されてアプリの中に収まるため、1本作るごとにこの規模の実体がディスク上に増えます。5本作れば5本分のブラウザを抱えることになり、更新も5本分それぞれに必要です。

この構造は、ブラウザ側の機能でDockに出す方式との決定的な違いです。ブラウザが作る窓は、ブラウザ本体の実行環境を共有します。本体が更新されれば、その窓も一緒に新しくなります。Nativefierで作ったアプリは自分専用の実行環境を抱え込んでいるため、作った瞬間の状態で固定されます。良い面としては、サイト側やブラウザ側の変更に引きずられません。悪い面としては、放っておくと中身が古いまま動き続けます。

指定した各種オプションも、生成時にアプリの中へ書き込まれます。あとから設定画面で変えられる作りではないため、名前を変えたい、内部URLの範囲を広げたいといった修正は、作り直しか --upgrade による上書きになります。この「ビルド時に決まる」という性質が、次の節の話に直結します。

2023年9月に開発が止まっている

この道具を検討するうえで、最初に知っておくべき事実があります。公開リポジトリは2023年9月29日に書庫化されており、READMEの先頭には保守されていない旨が1行で置かれています。npmに公開された最後の版は52.0.0で、公開日は2023年8月25日です。それ以降、新しい版は出ていません。

Nativefier is unmaintained and has been publicly archived. It was built a couple of years ago before the ability to create shortcuts for websites in Chrome, or similarly on Firefox. 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

書かれている理由は2つです。1つは、この道具が作られた当時はブラウザ側にサイトをアプリとして出す機能が無く、その穴を埋めるものだったこと。もう1つは、ブラウザが自分で更新される仕組みを持っているのに対し、自作の包み込みアプリはその保護から外れることです。作者側が案内している代替は、ブラウザの機能を使う方法と、Electronを直接使って自分で組む方法の2つです。

注意したいのは、書庫化は「使えなくなった」という意味ではない点です。npmからの導入は今も通りますし、ビルドも走ります。動かなくなったのではなく、直す人がいなくなったという状態です。この違いが、次に何を確かめるべきかを決めます。

止まっていることが実際に何を意味するか

生成されるアプリに入るブラウザの版は、道具の中に定数として書かれています。最後の版が指しているのはElectron 25.7.0で、名乗るChromeの版は114.0.5735.289です。Electronは公開時点で最新の3系統を保守対象としており、2026年9月に出ている最新版は44.3.0です。19世代分の開きがあり、25系はとうに保守の対象から外れています。

作られたアプリ自身も、この状態を検知して知らせます。ビルドからの経過が90日を超えると、起動時に「Old build detected」という警告の窓が出る作りになっています。文面には、古い版のChromeを使い続けるのは危険なので、道具を更新してアプリを作り直すようにと書かれています。ところが道具の側の更新が止まっているため、指示どおりに作り直しても、入るブラウザの版は同じ場所に戻ります。

この点をどう受け止めるかは、対象のサイトで決まります。社内の管理画面のように、外からの入力が限られていて自分の管理下にある相手であれば、影響は小さく済みます。一方で、不特定多数のページに遷移する可能性がある相手や、決済や機微な情報を扱うサービスであれば、古い描画部分を使い続ける判断は割に合いません。

手が止まりやすい4か所

実際に入れてみる段になると、順番に確認が要る箇所があります。

1つ目は導入の前提です。動作条件としてNode.jsが16.16.0以上、npmが8.11.0以上と指定されています。今のMacに入っている版はこれより新しいことがほとんどで、その組み合わせで動くかどうかは実際に走らせるまで分かりません。2023年の時点で想定されていた環境ではないという前提で臨むことになります。

2つ目はアーキテクチャです。生成されるアプリの対象は、ビルドしたマシンのNode.jsの種類に従います。Apple Silicon搭載機でも、Rosetta経由で入ったNode.jsを使っていると、出来上がるのはIntel向けのアプリです。公式の説明でもこの点は名指しで注意されており、-a arm64 を明示するか、Node.jsを入れ直すかのどちらかが必要になります。

3つ目はアイコンです。macOS向けには .icns 形式が基本で、PNGから変換させたい場合はImageMagickかGraphicsMagickを別途入れて、convert と identify、または gm がパスに通っている必要があります。この準備が無いままPNGを渡すと、アイコンだけが付かない状態になります。

4つ目は署名です。生成された .app にはApple発行の署名が付きません。そのまま開こうとするとmacOSのGatekeeperに止められるため、初回は右クリックから開く操作が要ります。自分の機械で使う分には通せますが、他の人に配る用途では、受け取った側に同じ操作を求めることになります。

どのサイトを独立させるべきかの見極め

ここまでを踏まえると、この道具は「何でも包める万能の手段」ではなく、条件がはっきりした場面で効くものだと分かります。判断の軸は3つです。対象サイトが自分の管理下にあるか。1日に何度開くか。ビルド時に埋め込みたい細工（差し込むCSS、プロキシ、認証情報）があるか。この3つがすべて当てはまるなら、作り込める自由度は他の手段より高くなります。

逆に、単に「タブから出したい」だけであれば、手段は他にもあります。どの種類のサイトが独立した窓に向いているかは、実際に外へ出されているサービスの顔ぶれを見ると見当が付きます。240以上のプリセットからすぐ作れる形で並んでいる対応サービス一覧を眺めると、業務の管理画面、会計、タスク管理、会話の窓口といった、1日中開きっぱなしになる種類が中心です。開く回数が多く、閉じる機会が少ないものほど、独立させた効果が出ます。

窓として何を引き受けるのかを比べたい場合は、できることに機能の範囲がまとまっています。独立したウインドウ、Dockのアイコン、保存領域の分離、通知といった項目は、包み込む方式であれば方法を問わず共通して得られるものです。ここに差が出ないのであれば、次に比べるのは作ったあとの手入れの量になります。

費用の条件を先に確かめておくと、比較が短くなります。買い切りか継続課金か、対応するmacOSの版はどこまでかは料金に書かれています。コマンドで作る方式は金銭的な費用が発生しない代わりに、更新が止まった道具を使い続ける前提と、作り直しの手間を自分で抱えることになります。どちらが安いかは、作る本数と保つ年数で変わります。

作ったあとに名前を変えたい、消したい、別のサイトに差し替えたいといった手入れの方法は使い方ガイドに並んでいます。導入前に気になる条件はよくある質問にまとまっているため、対応するOSの版や、作ったアプリの扱いをそこで先に確認しておくと、あとで作り直す回数が減ります。

最後に決めることは1つです。いま独立させたいサイトが、自分の管理下にある業務用のものか、外部のサービスか。前者であれば、更新が止まっている道具でも条件次第で成立します。後者であれば、中身のブラウザが自動で新しくなる方式を選ぶほうが、長い目で見て手が掛かりません。