サイトをアプリにする方法｜自分用に包むか、配布するアプリにするか

サイトをアプリにする方法を調べていると、まるで違う話が同じ見出しの下に並んでいることに気づきます。片方は個人の作業環境の話です。毎朝開くサイトがタブの列に埋もれていて、専用のアイコンと窓を持たせたい。もう片方は製品の判断です。運営しているサイトを、他の人が端末にインストールできる形で配りたい。この2つは手順も費用も桁が違います。最初に決めるべきなのは、どちらの話なのかという1点です。

2つの作業を分ける質問

判定は1問で終わります。そのアプリは、自分以外の人の端末で動く必要があるか。

答えが「いいえ」なら、これは作業環境の問題です。すでに入っている道具だけで数分で片が付き、どこにも公開せず、コードも書きません。

答えが「はい」なら、これは配布の問題です。ストアの審査、コード署名、更新の仕組み、そして公開している間ずっと続く保守が伴います。最短でも数週間の作業になります。

この質問を声に出して確かめる価値があるのは、2つの作業が事故のように混ざるからです。始まりは「チームの全員が管理画面をタブの中で見失っている」という一言なのに、打ち合わせを2回する間に「自社アプリを出す」という企画書に姿を変え、最初の一言のほうは最後まで解決されない。相談のきっかけになった文をそのまま書き留めて、ストアに並ぶアプリがその文を解決するのかを確かめる。この作業は1分で終わり、数週間分の工数を守ります。

その中間に、名前を付けておく価値のある場合があります。社内の業務システムを、同じ部署の数人がそれぞれのMacでアプリとして開きたい、という場合です。見た目は配布に似ていますが、ストアを通す必要がないため、実際には個人用の手順を人数分繰り返して、手順書を1枚共有すれば終わります。配布の計画として扱い始めると、必要のない工数がそこで生まれます。

自分のMacで使う場合の3つの経路

どの経路でも、専用のアイコンを持つ窓、Command＋Tabの一覧に並ぶ独立した項目、システム設定の通知一覧に並ぶ単独の行が手に入ります。違いはログインの持ち方です。

	SafariのDockに追加	Chromeのアプリとしてインストール	専用の道具
必要なもの	macOS Sonoma 14以降	現行のChrome	別途の導入
最初の1本ができるまで	1分未満	1分未満	数分
ログインの持ち方	Safariと分かれる	作成したプロファイルと共有	アプリごとに独立
同じサービスの2アカウント	使える	プロファイルに従うため不可	使える
拡張機能	Safariの拡張機能をアプリ単位で	そのプロファイルのものが使える	方式による
アイコンの変更	アプリの設定から可能	サイト側のものが使われる	たいてい可能
壊れる条件	サイトのURLが変わったとき	プロファイルを削除・改名したとき	道具の更新が止まったとき

Safariの経路は、メニューバーの「ファイル」から「Dockに追加」を選ぶだけです。できあがるものが何かは、Appleのサポート文書に書かれています。

Webアプリは、Safariとは別に機能します。閲覧履歴、Cookie、Webサイトデータ、設定はSafariと共有されません。 出典: support.apple.com

だから最初の起動ではログアウトした画面が出ます。同時に、これが同じサービスから2つのアプリを作って別々のアカウントで入れる理由でもあります。タブの整理をどれだけ工夫しても、この状態は作れません。

Chromeの経路は3点メニューの「キャスト、保存、共有」の中にある「ページをアプリとしてインストール」です。よく似た名前の「ショートカットを作成」は、現行版では通常のタブでページを開くランチャーを作ります。機能が無くなったと誤解される原因は、ほぼこの取り違えです。

自分用の経路では手に入らないもの

この3つのどれを選んでも、サイトがオフラインで動くようにはなりません。ページは今までどおりネットワーク越しに取得され、接続が無いときにエラーを出すサイトは、アプリの中でも同じエラーを出します。オフライン対応はサイト側が持つ仕組みであって、外側の器で足せるものではありません。

OSの機能が増えるわけでもありません。ブラウザのエンジンが許す範囲を超えてファイルを読み書きすることはできず、閉じている間に裏で処理を走らせることもできず、メニューバーの常駐項目やシステム全体のキーボードショートカットも付きません。窓から余計な部品を取り除いたブラウザの窓、と考えるのが正確です。

そして、配れません。できあがるのは1台のMacの中のアプリです。バンドルを別のMacへコピーしても、署名の扱いで開けないことがあり、開けたとしても自動では更新されません。顧客に渡すことを考えている場合は、この記事の後半の話になります。

その代わり、保守するものもありません。中身はサイトそのものなので、サイト側の改修は再ビルドも審査も無しに、次に開いた瞬間から反映されます。裏を返せば、サイトがURLを変えたりログインの導線を作り替えたりすると、アプリは何の説明も出さずに開かなくなります。直し方は作り直すことだけで、その所要時間が短いからこそ、この経路は失敗しても安いままです。

作った後に効いてくる細かい点も2つあります。1つはアイコンです。同じようなファビコンを持つサイトを5本包むと、Dockでの狙いにくさはタブの頃より悪化します。見分けの付くアイコンを当てられるかどうかは、装飾ではなく実用の問題です。もう1つは外部リンクの扱いです。包んだアプリの中で他サイトへのリンクを押したとき、既定のブラウザに渡してくれるのか、それともアプリがそのまま別サイトへ移動してしまうのか。この挙動を設定できるかどうかは道具によって違います。

他人に配る場合の4つの選択肢

費用の安い順に4つあります。

• PWA（プログレッシブWebアプリ）。サイト側がマニフェストとService Workerを用意し、ブラウザが導入を提案する形です。どこにも提出せず、更新はサイトの公開と同時に反映され、1つのコードでPCとスマートフォンの両方に届きます。オフライン動作とキャッシュはここで初めて本物になります。弱点はOSの深い機能に届きにくいことと、ストアで見つけてもらえないこと。実装の入口としてはweb.devの資料が読みやすい。
• デスクトップ向けの同梱型。Electronのような枠組みでブラウザエンジンごと同梱し、通常のアプリとしてインストールできる形にします。よく使われている多くのデスクトップアプリがこの方式です。代償は容量とメモリ、そしてエンジンの脆弱性修正が出るたびに更新版を配り直す責任です。
• モバイル向けの同梱型。同じ考え方をスマートフォンに適用し、ネイティブの容れ物の中でWebの画面を動かします。カメラ、連絡先、プッシュ通知などは橋渡しの層を通して使います。Webの資産を活かしたままApp StoreやGoogle Playに並べるなら、この経路になります。
• 作り直し。Webの画面を使わず、最初からネイティブで作ります。費用は最も高く、OSとの統合は最も深い。ブラウザエンジンを保守対象から外せる唯一の道でもあります。

審査の基準が計画を変える

配布の相談で最初に出てくる案は、たいてい「今のサイトを包んで提出する」です。この案については、Appleの審査ガイドラインが直接触れています。

アプリを作成する際は、Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するようにしてください。 出典: developer.apple.com

同じ節には、主な目的がWebクリッピングやリンク集であるアプリは許可されない、とも書かれています。実際に通っているアプリは、モバイル版のサイトにはできないことを持っています。アカウントの動きに連動したプッシュ通知、取得済みのコンテンツをオフラインで読める仕組み、カメラや位置情報を実際の業務の流れの中で使う画面、生体認証でのロック解除。逆に、同じページを同じ導線のまま包んだだけのものが、差し戻される側です。

4つの選択肢は、修正が利用者に届くまでの経路も違います。この差は開発が終わった後もずっと残ります。PWAはサイトの公開と同時に反映されるので、火曜の朝に直した不具合は火曜の午後には全員の手元で直っています。デスクトップの同梱型は利用者が新しいビルドを受け入れたときに更新されるため、常に一定の割合が古い版のまま動きます。ストアのアプリは、審査を通り、利用者が更新して初めて届きます。緊急の修正が数日単位の待ち行列に並ぶことになり、ホットフィックスは配信作業ではなく計画の問題に変わります。週次で改善を出しているチームほど、この差を強く受けます。

この基準は、設計に入る前に読んでおく価値があります。見積もりの中心が変わるからです。作業の本体は包む工程ではなく、そのアプリが存在してよい理由になる2つか3つのネイティブ機能のほうです。

初日の費用ではなく2年で見る

初日の費用は判断を誤らせます。サイトを包むだけなら半日で動くものができるので、経路が安く見えます。請求は後から、次の4か所に届きます。

• エンジンの更新。同梱したブラウザエンジンは、脆弱性の修正が出るたびに上げ直す必要があります。放置すると、既知の穴を抱えた製品を配り続けることになります。
• 審査基準の変更。ルールは動きます。2年前に通ったアプリが、再提出で落ちることがあります。
• 署名と公証。ストアを通さないデスクトップアプリでも、開発者証明書と公証は必要で、証明書には期限があります。
• 実質2つ目の製品。ネイティブ機能が入った時点で、そのアプリはWebサイトの写しではなく、独自のリリース周期を持つ別の製品になります。

これに対して、自分用の経路の維持費はほぼゼロです。動き続けるか、壊れたら1分で作り直すかのどちらかで、2年先の保守計画を立てる必要がありません。この非対称性が、「本当に配布が必要なのか」を先に確かめるべき最大の理由です。

3つの経路をデータで見比べる

自分用の経路に絞ったとき、道具の比較で先に見ると判断が速くなるものが2つあります。

1つは、雛形として用意されているサービスの並びです。対応サービス一覧のようなページを見ると、その道具が何を想定して作られているかが分かります。300以上のプリセットからすぐ作れる作りであれば、一覧に載っていない社内の管理画面も同じ手順で扱える見込みが立ちます。設定できる項目の細かさはできることに整理されており、実際の手数は使い方ガイドで確認できます。

もう1つは費用の形です。買い切りか継続課金か、対応するmacOSの下限はどこかを料金で先に見ておくと、後から乗り換える手間を避けられます。判断が割れやすい点はよくある質問にまとまっています。

決め方はここまでの内容で1本の線になります。誰がそのアプリを動かすのかを紙に書く。名前の挙がる数人が自分のMacで使うだけなら、個人用の経路を人数分繰り返して終わりにする。相手が顧客なら、モバイル版のサイトにはできないことを3つ書き出す。その3つが空欄なら、正直な答えはストア向けのアプリではなくPWAです。審査担当にも利用者にも、差し出せるものが無いからです。3つが埋まったなら、選択肢は同梱型か作り直しに絞られ、その3つが画面全体に関わるかどうかで分かれます。