web app to desktop app｜Macで選べる4つの経路と選び方

ブラウザのタブには、実質的にソフトウェアとして使っているサイトが必ずいくつかあります。社内の管理画面、案件管理、デザインツール、メール、チャット。毎日開き、状態を持ち、それでいてニュース記事や通販の商品ページと同じ並びに置かれています。「web app to desktop app」で調べる人が本当に決めたいのは、変換の手順そのものではなく、どの経路を選べば2年後も同じように動いているか、です。この記事では、Macで選べる4つの経路を、作ったあとの面倒を誰が見るかという基準で並べ、独立させる価値のあるサイトの見分け方まで整理します。

経路の違いは「作った後で誰が面倒を見るか」

どの経路を選んでも、見える結果はほぼ同じです。Dockにアイコンが並び、タブバーのない窓が開き、Command+Tabの切り替え対象に入ります。差が出るのは初日には見えない部分、つまり土台のブラウザエンジンが更新されたとき、その窓を動かし続ける責任が誰にあるかです。

責任の持ち主は4種類に分けられます。サービスを提供している会社、ブラウザを作っている会社、自分でアプリを組んだ本人、そしてMacに入っているブラウザを土台として参照する生成ツールです。

この4つを「手軽さ」で並べるのは順番が違います。並べる基準は、Chromiumの更新が来た日に何が起きるかです。更新は数週間おきに必ず来ます。手作業での作り直しが必要な経路を選ぶと、その時点で保守の予定表を1つ抱えることになります。

経路1: 提供元の公式デスクトップアプリ

道具を探し始める前に確認すべきは、そのサービスに公式のデスクトップ版があるかどうかです。あるなら、それを使えば問題そのものが消えます。

確認する点は2つです。1つは対応OSの下限で、ここが公式サイトとWeb版で食い違います。ブラウザでは古いMacでも開けるサービスが、インストール版では新しいmacOSを要求することがあり、その下限は年々上がります。もう1つは、その公式アプリの中身です。公式デスクトップアプリの相当数は、Webの画面に枠を付けたものです。

後者は両方向に効きます。公式アプリが枠であるなら、同じサイトを自分で窓に入れても機能面で劣ることはありません。逆に、オフライン同期やローカルファイルの検索、OS側との連携を持つ本当のネイティブアプリなら、どの窓でも再現できないので公式アプリを選ぶのが正解です。

経路2: ブラウザが最初から持っている機能

Chromeには専用の手順があり、ヘルプにも記載されています。サイトを開いた状態で右上のメニューから「キャスト、保存、共有」を開き、「ページをアプリとしてインストール」を選ぶだけです。

A web app is an app built for the web that you can access on any device. You can use web apps to have a website work as an app and access it on your computer or mobile devices through the launcher or home screen. 出典: support.google.com

Safariにも同じ位置づけの機能があり、メニューバーの「ファイル」から「Dockに追加」を選びます。Appleのサポート記事では、こうして作ったWebアプリはSafariと閲覧履歴・Cookie・Webサイトデータ・設定を共有しないと説明されています。

どちらも無料で、所要は1分未満、しかも保守はブラウザの提供元が持ちます。最初に試す価値が高いのはこのためです。限界は2つ目、3つ目のアプリを作るときに出ます。Chromeの機能で作った窓は元のプロファイルを引き継ぐので、いくつ作ってもログイン状態と拡張機能は共通です。SafariのDockに追加は分離できますが、動くのはWebKitなので、Chromeウェブストアの拡張機能に依存する使い方はできません。

経路3: 自分でアプリとして作る

3つ目は、アプリケーションとして書いてしまう方法です。代表的な枠組みは2つあり、Webサイトを包む用途では性格がはっきり分かれます。

Electronは自前のエンジンを同梱します。公式ドキュメントでは、ChromiumとNode.jsをバイナリに埋め込むことで、1つのJavaScriptのコードからWindows・macOS・Linux向けのアプリを作れる枠組みだと説明されています。Tauriは反対に、利用者のシステムに既にあるWebViewを使う設計です。

製品を作るならどちらも妥当な選択です。ただし「すでに動いているサイトを包むだけ」の目的では、共通の弱点があります。出来上がった配布物は、ビルドした瞬間の状態で固定されるという点です。埋め込んだエンジンは古びていき、システム側のWebViewを使う場合も更新のたびに動作確認が要ります。どちらにせよ、人が気づいて手を入れる必要があります。

その弱点を最もはっきり示しているのがNativefierです。コマンド1つでサイトをアプリ化できる有名な道具で、GitHubのスター数は35,000を超えていますが、リポジトリは2023年9月以降アーカイブ（読み取り専用）になっています。生成済みのアプリは今も起動しますが、中身のChromiumはビルド時のままです。自作の枠が抱えるリスクはこの形で現れます。放置された日に壊れるのではなく、しばらく経ってから、サイト側が新しい機能を要求した時点で静かに動かなくなります。

経路4: 入っているブラウザを土台にする生成ツール

4つ目の経路は、いま挙げた壊れ方を避けるために存在します。エンジンを同梱せず、ビルドを固定もせず、Macに既に入っているChromium系ブラウザ（Chrome、Brave、Edge、Vivaldi等）の実体をシンボリックリンクで参照する方式です。ブラウザを更新すれば、それを土台にした全アプリが同時に最新になり、作り直しは要りません。

ここから2つの結果が生まれます。1つは、Chromeウェブストアの拡張機能が窓の中で動くこと。しかもマシン単位ではなくアプリ単位で入れ分けられます。WebKit系の経路では実現できない部分です。もう1つは、アプリごとにプロファイルが分かれるため、同じURLから作った2つのアプリが別々のログインを保持できることです。どの設定がアプリごとに持てるのかはできることにまとまっています。

経路	エンジンの出どころ	保守の主体	拡張機能	プロファイル
公式デスクトップアプリ	提供元の選択	提供元	基本的に不可	提供元のログイン方式
Chromeのアプリ化	入っているChrome	Google	プロファイル全体	元と共有
SafariのDockに追加	WebKit	Apple	Safari拡張機能	Webアプリごとに分離
ElectronやTauriで自作	同梱またはシステム	作った本人	自分で実装した分だけ	自分で実装した分だけ
サイトをアプリにする生成ツール	入っているブラウザ	ブラウザ提供元	アプリごとに個別	アプリごとに分離

窓に入れる前に確かめておく、そのサイトの癖

経路を決める前に、対象のサイトが「タブの無い窓」に耐えるかを見ておくと、作り直しが減ります。ブラウザのタブでは意識せずに済んでいた挙動が、窓に入れた途端に表面化するからです。確認する点は3つあります。

1つ目は、ログインが別窓で行われるかどうかです。Googleアカウントでの認証や、社内のシングルサインオンは、小さな別窓を開いて処理を進める作りになっているものが多くあります。ポップアップを一律で塞ぐ設定の窓に入れると、ボタンを押しても何も起きない状態になります。塞ぐ・通す・認証だけ通すの3段階を選べるかどうかは、業務用の管理画面を扱うなら先に見ておく項目です。

2つ目は、外部リンクの行き先です。チャットや案件管理のサイトには、他人が貼ったURLが日常的に流れてきます。それを窓の内側で開くと、専用のはずだった窓が数分後には無関係な記事だらけになります。リンクを既定のブラウザへ逃がす設定があるかどうかで、窓が専用のまま保たれるかが決まります。

3つ目は、ファイルの受け渡しです。請求書のPDF、書き出した画像、CSVの取り込み。ダウンロードの保存先を指定できるか、印刷のダイアログが窓から普通に呼び出せるかは、実際に1回試せば数十秒で分かります。この3つを通ったサイトは、どの経路で窓にしても問題が起きにくい部類です。

見落とされがちな3つのコスト

機能比較の表には出ないコストが3つあります。どれも作った後に現れます。

1つ目は署名と公証です。macOSでは、インターネット経由で入手したアプリに検疫の印が付き、初回起動時にDeveloper IDの署名とAppleの公証を確認します。自分のMacでビルドしたものはこの確認を通らないため、作った本人の環境では普通に開くのに、同僚のMacに渡すと止まります。社内に配るなら開発者プログラムへの登録とビルドごとの公証が必要で、これは一度きりの作業ではありません。

2つ目はディスクの重複です。プロファイルの分離は複数アカウント運用の要ですが、分離とは実体のあるディレクトリが増えることでもあります。Cookie、キャッシュ、拡張機能のデータがアプリごとに育ちます。現代のディスク容量では大きな負担ではないものの、使わなくなったアプリを残さず消す運用のほうが健全です。

3つ目は初日のログインです。分離されたプロファイルは空の状態から始まるため、作った直後は毎回ログイン画面が出ます。ブラウザ本体では入りっぱなしだったサービスも例外ではありません。ログイン済みの状態をテンプレートとして保存し、新しいアプリへコピーできる仕組みを持つ道具なら、この手間は1回で済みます。

独立させる価値があるサイトの見分け方

すべてのタブにアイコンが要るわけではありません。次のうち2つ以上に当てはまるなら独立させる価値があり、1つだけならブックマークで足ります。

• 1日に3回以上開く。頻度が高いほど、開くまでの手数の削減が効いてくる
• 他と混ぜたくないログインがある。同じサービスの2アカウント、顧客の管理画面、共有の受信箱など
• 通知を他と別扱いにしたい。独立したアプリはmacOSの通知設定に個別の項目として並ぶ
• ブラウザを閉じても生かしておきたい。タブのままだとブラウザの終了に巻き込まれる
• 特定の拡張機能に依存している。この条件が入った時点でWebKitの経路は外れる

判断に迷ったときは、逆から考えるのが早い方法です。そのサイトを閉じたまま半日過ごせるなら、アイコンは要りません。閉じた瞬間に開き直しているなら、それは道具であり、道具は道具の置き場所に置くべきです。300以上のプリセットからすぐ作れる種類のツールなら、対象を決めてから並べ直すまでの作業は数分で終わります。手順の詳細は使い方ガイドに、どのサービスがプリセットに入っているかは対応サービス一覧に、無料で作れる本数は料金にあります。