mac webアプリ作り方｜コードを書かずにサイトをアプリにする

mac webアプリ作り方で検索すると、まったく別の2つの作業の情報が混ざって出てきます。ひとつはフレームワークとサーバーを用意してWebアプリケーションをゼロから開発する話。もうひとつは、すでに存在しているサイト、たぶん今このMacのタブで開いているサイトに、Dockのアイコンと独立した窓を与える話です。タブが30枚並んでいて目的のものを見失っている状態を解決したいなら、必要なのは後者で、こちらはコードを1行も書かずに数分で終わります。

「Webアプリを作る」の2つの意味を先に分ける

見分け方は単純で、「すでにURLがあるかどうか」だけです。

サイトが動いていてURLで開ける状態なら、公開サービスでも社内の管理画面でも、やることは開発ではなく「包む」ことです。入れ物を選び、URLを指し、名前とアイコンを決める。それで完成します。

一方、フォームとデータベースと処理があるだけで、まだ誰も作っていない状態なら、包むのは最後の工程になります。コードを書かずに作る手段としてノーコードのプラットフォームがありますが、その出力もやはりURLです。つまり2つの作業は競合しておらず、順番に並んでいます。開発してURLができたら、その次に包む。

この記事が扱うのは後半の「包む」ほうです。タブが増えすぎる問題が解けるのはこちらで、迷いが生まれやすいのもこちらになります。macOSには包む方法が少なくとも3つあり、しかもその違いは作った当日ではなく1週間後に効いてくるからです。

包むと何が変わり、何は変わらないのか

入れ物はコンパイラではありません。中身はブラウザのエンジンが描いているWebページのままで、読み込むものも、通信の先もタブのときと同じです。オフラインで使えるようになることはなく、サイト自体がもともとオフライン対応していない限り、そこは変わりません。

変わるのは、そのサイトのMac上での立ち位置です。40枚のタブの1枚だったものが、独立して呼び出せる対象になります。Dockに固定できるアイコンができ、Command＋TabとMission Controlに別の項目として出て、タブバーもアドレスバーも無い窓になり、システム設定の「通知」に単独で並びます。多くの道では、さらにCookieの保管場所が分かれます。これが同じサービスの2つのアカウントを同時にサインインさせたままにできる仕組みです。

Appleの資料も、Webアプリが通常のアプリと同じ扱いになる点に触れています。

そのほかのさまざまな点で、Webアプリはほかのアプリと同じように機能します。ログインすると自動的に開くように、ログイン項目として追加することもできます。 出典: support.apple.com

逆に、ブラウザで持っていなかった能力は増えません。ファイルの読み書きも、メニューバーへの常駐も、表示速度の改善もありません。速くなることを期待して作ると失望しますが、タブを見失う問題を消したくて作ったなら、期待どおりに働きます。

コードを書かない3つの道を並べる

	SafariのDockに追加	Chromeのアプリとしてインストール	専用のWebアプリ化ツール
必要なもの	macOS Sonoma 14以降	現行のChrome	別途の導入
費用	0円（macOSに同梱）	0円（Chromeに同梱）	無料枠あり、買い切りは3,980円前後から
エンジン	WebKitのみ	Chromeのみ	Chrome、Brave、Edge等から選べるものがある
Cookieとログイン	アプリごとに独立	インストールしたプロファイルと共有	アプリごとに独立
同じサービスの2アカウント	使える	プロファイルに従うため不可	使える
Chrome拡張機能	使えない	使える	アプリごとに切替できるものがある
アイコンの変更	画像ファイルから可能	サイト側のものが使われる	プリセットを持つものがある
複数サイトを1つの窓に	不可	不可	対応するものがある
壊れるとき	サイトのURLが変わったとき	プロファイルを消したとき	道具の更新が止まったとき

判断を左右する行は、実質2つです。

拡張機能の行は、広告ブロッカー、パスワード管理、翻訳ツールをChromeウェブストアから入れて日常的に使っている人にとって決定的です。Safariの道ではエンジンがWebKitのため、これらは動きません。

ログインの行は、同じサービスのアカウントを2つ使い分けている人にとって決定的です。Chromeでインストールしたアプリは、インストール元のプロファイルの中で動くため、そのプロファイルのログインをそのまま引き継ぎます。ログインを再利用したい場合は便利ですが、片方のアカウントを分離したかった場合には目的を達成できません。

メニューの場所と、実際の手順

3つの道はどれもサブメニューの奥にあり、解説記事のほうが古いバージョンのままになっていることも珍しくありません。現在の場所を整理しておきます。

SafariのDockに追加

サインインした状態で対象のページを開き、メニューバーの「ファイル」から「Dockに追加」を選びます。ツールバーの共有ボタンからでも同じ項目に届きます。名前を入れて「追加」を押せば完了です。

保存先はホームフォルダの中の「アプリケーション」フォルダで、ディスク直下の共通のアプリケーションフォルダではありません。「作ったはずのアプリが見つからない」という報告のほとんどはこれが原因です。Finderの「移動」から「ホーム」を開けば辿り着けます。作ったあとの設定は、アプリを開いてメニューバーのアプリ名から「設定」を選ぶと開き、名前、URL、アイコン、ツールバーの表示をそこで変更できます。

Chromeのアプリとしてインストール

関係する項目は2つとも、右上の3点メニューの中の「キャスト、保存、共有」にあります。窓として独立するのは「ページをアプリとしてインストール」のほうです。「ショートカットを作成」は現在、通常のタブでページを開くだけのランチャーになっており、以前あった「ウィンドウとして開く」のチェックボックスはこのダイアログから無くなりました。

古い解説どおりに進めると後者のダイアログに辿り着き、機能が廃止されたと結論してしまいます。廃止ではなく、2つに分かれています。インストール済みのアプリは chrome://apps で管理でき、間違えて作ったものはそのページの「アンインストール」から消せます。保存されたデータを一緒に削除するかどうかも選べます。

専用のWebアプリ化ツール

こちらはメニューではなくフォームです。サービスを選ぶかURLを貼り、名前とアイコンを確認して作成を押す。実務上の違いは、どこまで自分で決めるかにあります。プリセットを使えばURL、公式アイコン、アプリ名が1手で埋まり、拡張機能の有効・無効、タブバーの表示、ポップアップの扱いといったアプリごとの設定が、作成の時点で目に見える位置に並びます。あとから設定画面を探す必要がありません。

効き目がいちばん大きいのは社内ツール

Webアプリ化の例として挙げられるのはメールやチャットですが、効果が大きいのは、そもそもアプリになる想定で作られていないページのほうです。ホスティングされた管理画面、監視のダッシュボード、社内の勤怠システム、ログインの奥にある顧客データベース。

これらには共通点があります。朝いちばんに開いて一日開きっぱなしになる。ログインの再取得が面倒で、シングルサインオンだと1分近くかかることもある。URLに長いクエリ文字列が付いていて、誰かがチャットに貼ったものを使い回している。そしてタブの掃除のときに誤って閉じられる。

これを包むと、4つの問題が同時に片づきます。URLを覚えておく必要がなくなる。ブラウザの窓を閉じてもログインが飛ばない。調べもののタブと混ざらない。そしてプロファイルが分離される道であれば、検証環境と本番環境を2つのアプリとして並べても、片方がもう片方をログアウトさせません。見た目の話よりも、この最後の1点のほうが日々効きます。

注意が1つあります。認証のたびにポップアップ窓を開く社内ツールは、入れ物によって扱いが異なります。ポップアップがブロックされると、見た目は「アプリが壊れている」と区別がつきません。導入前にその挙動だけは確かめておくと安全です。

作ったあと使われるかを決める細部

放置されたWebアプリには、たいてい小さい理由があります。

名前

名前はDock、Command＋Tab、強制終了の一覧、通知の一覧に出ます。サービス名だけで3つ作ると、見分けのつかない行が3つ並びます。「メール 仕事」「ダッシュボード 検証」のように、アカウントか環境を名前に入れておくと1年後でも読めます。

起点にするURL

サービスのトップではなく、実際に見ている画面を指してください。絞り込み済みのボード、保存した検索条件、特定の受信箱。これで毎回の起動から2クリックが消えます。そもそもそのタブが開きっぱなしだった理由は、その2クリックを省くためだったはずです。

アイコン

Dockで滲んでいるアイコンは目に入らなくなります。ファビコンが小さいサイトは拡大すると粗くなるので、画像を差し替える1分の価値があります。アイコンのプリセットを持つ道具があるのはこのためで、300以上のプリセットからすぐ作れる形なら、URLもアイコンも名前も選んだ時点で埋まります。何が用意されているかは対応サービス一覧で確認できます。

窓の作り

ツールバーを消すとサイトだけの画面になります。数字を眺めるダッシュボードには合い、リンクをたどって戻る操作が仕事に含まれるサイトには合いません。一律で決めず、アプリごとに変えるのが妥当です。

コードが必要になる境目

包むだけでは足りなくなる線は、はっきりしています。ローカルのファイルを読む、機器と通信する、オフラインで動かす、メニューバーに独自の画面で常駐する。この4つのどれかが要件に入っていたら、Webページを包んだ入れ物では届きません。設定をいくら見ても変わらない領域です。

もうひとつの限界は、データがまだ存在しない場合です。表計算のファイルを共有の仕組みに変えるのは、包む作業ではありません。そこはノーコードのビルダーか、小さなアプリケーションの出番で、包むのはその後になります。

この線より手前は全部「包む」作業で、そこでの失敗は決まっています。30秒で作り直せる決定に、半日かけて比較検討してしまうことです。作るのは高くつきません。合わないログインの持ち方のまま1か月使うほうが高くつきます。

費用と手数から、次の一手を決める

同じ「サイトをアプリにする」でも、総額の幅は大きく開きます。macOSの標準機能は0円。専用のWebアプリ化ツールには、3アプリまで無料で、それ以上を作るときに3,980円の買い切りへ移る形があります。月額課金の製品では3年間の合計が28,700円前後、上のほうでは47,900円前後に達するものもあります。何を求めるかを決めずに比べても、金額の意味が出てきません。

順序としては、まず既に入っている手段で1つ作ってみるのが早い。そこで拡張機能、エンジン、アプリの個数、複数サイトのまとめのどれかに詰まったら、そのときに専用の道具が何を肩代わりするのかを見にいく。各ツールで制御できる範囲はできることに整理されており、実際の作成手順は使い方ガイドで画面付きに追えます。無料枠と買い切りの線引きは料金にまとまっています。

長く使うときに効いてくるのは、機能の数よりも壊れにくさです。Chromeは数週間ごとに更新され、ブラウザ本体に紐づく方式の入れ物は、そのたびにアイコンが戻ったり起動しなくなったりすることがあります。アプリが3個ならその都度直せばよく、25個になると更新のたびに作業が発生します。どこまで自動で復旧するのかは道具によって差があるので、数を増やす前に確かめておく価値があります。導入前に出やすい疑問はよくある質問に集まっています。