nativefier chrome バージョンの調べ方と、上げる3つの方法

包んだアプリを開くと、画面の上に「お使いのブラウザは古くなっています」という帯が出る。ログイン画面で、このブラウザまたはアプリは安全でない可能性がある、と言われて先へ進めない。動画が再生できず、案内にはChromeを更新してくださいと書いてある。そこでアプリの中に更新の項目を探すことになりますが、見つかりません。更新すべきChromeがアプリの中に存在しないためです。「nativefier chrome バージョン」で調べる人が最初に確認すべきなのは、この構造です。仕組みが分かれば、次に取るべき手は3つに絞れます。

表示されているメッセージが指しているもの

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

ChromeやSafariは背後で自分を更新するため、ページの下にあるエンジンは何もしなくても前へ進みます。Electronのアプリにはその経路がありません。新しいエンジンを探しに行く処理も、取ってくる処理も入っていません。アプリを再起動しても、macOSを更新しても、隣で動いているChromeが新しくなっても、包んだアプリの中身は動きません。

したがって、画面に出ている警告は不具合ではなく、正確な報告です。サイトは古いエンジンを見て古いと言っており、その指摘は当たっています。

いま入っているバージョンを調べる

手間の少ない順に3つあります。

1つ目は、ビルドの設定を読む方法です。アプリを右クリックしてパッケージの内容を表示し、Contents/Resources/app/nativefier.jsonを開きます。ここに、対象のURL、アプリ名、内部に留めるURLの指定、そして名乗りを差し替えていればその文字列まで記録されています。誰かがすでに回避策を当てているかどうかが、いちばん早く分かる場所です。

2つ目は、名乗りを読む方法です。アプリの中で、送信された情報をそのまま表示してくれるページを開き、名乗りに含まれるChromeの版番号を確認します。サイト側が見ているのはこの数字です。ただし1つ目の手順で名乗りの差し替えが見つかった場合、ここに出るのは中身ではなく貼り替えた名札のほうになります。

3つ目は、部品そのものを見る方法です。アプリの中のContents/FrameworksにElectron Framework.frameworkが入っており、その日付と大きさが、取り込まれたElectronの版を反映します。ビルドに使った本体の版が分かっていれば、そこから逆算しても構いません。

比較のための数字を置きます。2026年9月初旬時点のmacOS向けChrome安定版は152で、同じ月からChromeの更新間隔は4週間から2週間に短縮されました。差の開き方は以前の2倍になっています。

バージョンがビルド時に固定される仕組み

公開されている最後の本体は52.0.0で、2023年8月25日の公開です。同梱されるのはElectron 25.7、その中身はChromium 114とNode.js 18.15です。Chromium 114がChromeの安定版として配られたのは2023年5月でした。

つまり、公開版の道具で作られたアプリはすべて、2023年前半のブラウザエンジンで動いています。新しい版が出ていないのは、公開から約5週間後の2023年9月29日にリポジトリが書庫入りしたためです。

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

Electronの側も、修正を入れる対象を最新3系統に限ると公表しています。Electron 25はその範囲から外れて久しく、Chromium 114以降に公開されたブラウザの脆弱性の修正は、このアプリには届いていません。技術的な詳細はElectronの公開資料に整理されています。

上げる方法は3つしかない

手段	実際に変わるもの	手間	時間が経っても持つか
新しいElectronで作り直す	エンジンそのもの	コマンド1回と動作確認	次の作り直しまで
名乗りだけ差し替える	サイトに見える文字列だけ	指定1つ、または設定の書き換え	持たない
包む方式をやめる	更新の担い手ごと	サイトごとの移行	持つ

エンジンが本当に新しくなるのは1つ目だけです。本体には--electron-versionという指定があり、同梱の既定より新しい版を指してビルドできます。注意点も実在します。包み側のコードはElectron 25の作法に合わせて書かれ、2023年で更新が止まっています。大きく飛ばすと、ビルドは成功するのに起動後に窓の設定や保存領域の扱いで落ちる、という結果になりがちです。1段ずつ上げ、そのつどログインまで含めて確認し、最新版には届かない前提で進めるのが現実的です。

2つ目は箱の表示だけを書き換える行為です。版番号だけを見ているサイトに対しては有効で、それ以外には効きません。

3つ目だけが、以後の手間が発生しない選択です。エンジンの更新が、自分で更新するソフトの側に移るためです。

名乗りの書き換えでは直らない理由

--user-agentで現行Chromeの文字列を渡すと、通信の見出しと画面上の申告が変わります。変わるのはそれだけです。

機能の有無を調べる作りのサイトには通用しません。最近のサイトは版番号ではなく、必要な機能が使えるかどうかを直接確かめます。Chromium 114より後に追加された機能を要求するページは、名乗りを新しくしても同じように失敗します。しかも今度は、こちらが新しいと申告しているぶん、原因の見当がつきにくい形で失敗します。版が古いという帯は分かりやすい報告であり、静かな不具合はそうではありません。

ログインの判定にも通用しません。Googleは組み込み型のブラウザからのログインを遮断しており、その判定は名乗りだけを根拠にしていません。差し替えで通ることはありますが、相手側の変更でいつでも止まります。自分の側で管理できない予定表に沿って壊れる仕掛けを、日常的に開くアプリに埋め込むことになります。

安全性は、どちらの方向にも変わりません。Chromium 114以降に修正された問題はそのまま残ります。ここは率直に書いておくべき部分です。版が古いという表示は問題そのものではなく、問題があることの通知です。通知を消しても問題は残ります。

作り直すと決めたときの手順

1つ目の手段を選んだ場合、半日で終わるか2週間かかるかを分けるのは、次の4点です。

記憶ではなく記録から始めます。Contents/Resources/app/nativefier.jsonには、対象のURL、アプリ名、内部に留めるURLの指定、名乗りの差し替えまで、当時の指定が残っています。作り直す前にここを丸ごと控えてください。うろ覚えのコマンドを組み立て直す作業に、いちばん時間が溶けます。

Electronの版は1段ずつ上げます。包み側のコードはElectron 25の作法に合わせて書かれ、2023年で更新が止まっています。1つ大きな版を上げるたびに、窓の設定、保存領域の扱い、権限の確認の作法が変わっている可能性があります。ビルドが警告なく終わったことは、何の証明にもなりません。実際にアプリを開くまでは未確認です。

確認は壊れやすい順に行います。最初に、保存された状態を消したうえでのログインです。すでに有効な状態が残っていると、認証の不具合が何週間も隠れます。次に、外へ出るはずのリンクがブラウザで開くか。続けて、中に留まるはずのリンクが留まるか。差し込んだCSSやJavaScriptがあるなら、その適用も確認します。2023年当時のサイトの構造に合わせて書いた指定は、真っ先に効かなくなる部類です。

古いほうのアプリは、新しいほうが1週間の通常利用を乗り切るまで残しておきます。前の版がフォルダに残っていれば戻すのは一瞬ですが、ごみ箱を空にしたあとでは戻せません。

そのうえで、使ったコマンドを見つかる場所に書き、次の作り直しの時期を添えておきます。作り直しの難所は作業そのものではなく、期日を思い出すことのほうにあります。

放置したときに壊れる順番

固定されたエンジンは、だいたい決まった順番で壊れます。残り時間を見積もるときの目安になります。

• 見た目の崩れが最初に来る。新しいCSSの機能を前提にした部分がずれる。困るが致命的ではない
• 次にログインが通らなくなる。更新の速度がいちばん速いのが認証まわりで、古い相手を危険な兆候として扱う
• そのあとに機能の欠落が来る。通知、ファイルの受け渡し、クリップボードの扱い、動画の形式などが順に合わなくなる。同じMacのブラウザでは動くのにアプリでは動かないため、原因の切り分けが難しい
• 最後に通信そのものが通らなくなる。暗号化や証明書の扱いは年々変わり、古い側はいずれ接続を完了できなくなる

この下に、症状の出ない未修正の脆弱性が積み上がっています。症状が出ないうちは判断材料にならないため、暦で管理するしかありません。

作り直しを繰り返すか、担い手を変えるか

作り直しは今日を直しますが、同じ作業を将来にもう一度置くだけでもあります。決める前に、そのアプリを何のために保っているのかを言葉にしてみてください。

答えが、Dockのアイコンと、他のタブと一緒に閉じられない窓と、切り替え画面での定位置だけであれば、ブラウザ側の機能で同じことができます。しかも自動で更新されます。答えにページへの手入れや、アカウントごとに分けた保存領域や、メニューバーへの常駐が含まれるなら、それは単なるショートカットでは満たせない要件です。この場合の問いは、作り直しが必要かどうかではなく、その作り直しを誰が担うかに変わります。

担い手を外へ出す選択もあります。独立した窓・独立した保存領域・常駐・ページへの手入れといった項目が実際にどこまで揃うかはできることに整理されており、自分がビルドの指定に期待していた内容と突き合わせられます。1つのサイトを独立させるまでの手順は使い方ガイドにまとまっているので、ビルドスクリプトを保守する労力と直接比べられます。費用の考え方は料金にあり、半年ごとの作り直しに費やす時間と並べて判断する材料になります。

最後に、いちばん実務的な確認をひとつ。作り直しの難所は作業そのものではありません。8か月後に「そろそろ作り直す時期だ」と自分で思い出せるかどうかです。思い出せないと分かっているなら、--electron-versionで1段上げる作業は解決ではなく先送りになります。凍結されたアプリが片付かずに増えていくのは、ほぼこの理由によります。