CursorでPWA化する手順｜非エンジニアでもスマホアプリ風に

「自社サイトをアプリストアに出すほどではないけれど、スマホのホーム画面から起動できるアプリっぽい見え方にしたい」。そう考えてPWA化にたどり着いた方は多いはずです。

この記事では、AIコードエディタのCursorを使って、既存のWebサイトをスマホアプリ風（PWA）に作り変える手順を、非エンジニアの方にも分かるように解説します。何を準備し、Cursorに何を渡し、出てきたコードのどこを確認すればいいか。実際に手を動かせるところまで踏み込みます。

Contents / 目次

1. 結論。PWA化は「3つの部品」をそろえるだけで始められる
2. CursorでPWA化する具体的な手順
3. PWA化で実際にどんな変化が期待できるか
4. よくある失敗と、その防ぎ方
5. PWA化の落とし穴と妥協点
6. よくある質問（FAQ）
7. まずは「自社に合うか」を整理するところから

結論。PWA化は「3つの部品」をそろえるだけで始められる

PWA化で最初にやるべきことは、サイトに足りない「3つの部品」をそろえることです。難しい改修は要りません。既存のサイトを土台にして、足りないものを追加するイメージです。

PWAとは、かんたんに言うと「Webサイトなのに、スマホアプリのように使えるサイト」のことです。ホーム画面にアイコンを置けて、起動するとブラウザのアドレスバーが表示されず、アプリと同じ見た目で立ち上がり、通信が不安定でも前に見たページが表示される。こうした体験をふつうのサイトに足す技術です。

そのために使う部品は次の3つです。インストールに必須なのはマニフェストとHTTPSで、service workerは表示の高速化やオフライン表示のために足します。

• Web App Manifest（マニフェスト）：アプリ名・アイコン・テーマカラー・起動時の画面などを書いた設定ファイル。これがあると、対応するブラウザがアプリとしてのインストール（ホーム画面への追加）を案内できるようになります。
• Service Worker（サービスワーカー）：裏側で動く小さなプログラム。ページの中身を一時保存（キャッシュ）して、表示を速くしたりオフラインで開けるようにしたりします。
• HTTPS：通信が暗号化された安全な状態。PWAとしてインストールできるのは、HTTPSで配信されているサイトだけです（開発中に自分のパソコンで確かめるlocalhostは例外）。service workerもHTTPSが必要です。

つまり、PWA化は「ゼロから作り直す」作業ではなく、「今あるサイトに設定ファイルと小さなプログラムを足す」作業です。だからこそ、コードを全部自分で書けなくても、Cursorのようなツールに手伝ってもらえば内製で進められます。

下の表で、PWAとネイティブアプリ（App StoreやGoogle Playから入れる従来のアプリ）の違いを整理しておきましょう。どちらを選ぶか迷ったときの判断材料になります。

比較項目	PWA（スマホアプリ風サイト）	ネイティブアプリ
入手方法	サイトを開いて「ホーム画面に追加」	App Store / Google Playから審査を経て配信
開発の土台	既存のWebサイトを活かせる	iOS用・Android用に別々に作るのが基本
更新のしやすさ	サイトを更新すれば反映（service workerを使う場合は、キャッシュの切り替えが済んでから）	ストア審査を経て配信
検索流入	Webサイトとして検索にも出る	原則アプリストア内での露出が中心
機能の幅	OSの一部機能は制約あり（特にiOS）	OSの機能を幅広く使える

判断の目安。カメラやBluetoothなどスマホの機能を深く使う必要がなく、「既存サイトをアプリっぽく、軽く、安く出したい」ならPWAが向いています。逆に決済や通知が事業の中心で確実性が最優先なら、ネイティブアプリも検討する場面です。

CursorでPWA化する具体的な手順

ここからは実際の進め方です。Cursorは、AIに「こうしたい」と伝えると、必要なコードを書いたり直したりしてくれるエディタです。だから手順の中心は「正しく材料を渡す → 出てきたものをご自身で確認する」という流れになります。

手順1。始める前に準備するもの

最初にそろえておくと作業が一気にスムーズになる材料があります。Cursorに渡す前に、手元で用意しておきましょう。

• サイトのファイル一式：PWA化したいWebサイトのソースコード（HTML・CSSなど）。CursorでそのフォルダをそのままAIに見せます。
• アプリ名と短縮名：ホーム画面に表示する正式名称（例「コレットラボ」）と、アイコン下に出る短い名前（例「コレット」）。
• アイコン画像：正方形の元画像を1枚。ここから192px・512pxのアイコンを作ります。背景が透けない画像が無難です。
• テーマカラー：起動時やステータスバーに使うブランドカラー（例「#1f2a44」のような色コード）。
• HTTPSで動く公開先：独自サーバーでもよいですが、HTTPSが標準で使えるホスティング（FirebaseやNetlifyなど）だと手間が減ります。

手順2。Cursorに「何を作りたいか」を伝える

Cursorへの最初の指示は、作り込んだ長い文章である必要はありません。ただし、AIは指示に無い条件を推測で埋めることがあるので、アプリ名・テーマカラー・やりたいことは短くても書いて渡します。足りない情報があれば質問するよう指示に書いておくと、聞き返してもらえます（次のたたき台の最後の1行）。出発点として、次のくらいの短い「たたき台」で十分です。

このフォルダの既存サイトをPWA化したいです。
- アプリ名：［正式名称を入力］／短縮名：［短い名前を入力］
- テーマカラー：［色コードを入力］
- やりたいこと：ホーム画面に追加できる、2回目以降の表示を速くする、簡単なオフライン表示
まず必要なファイル（マニフェスト・service worker）と、HTMLへの追記内容を提案してください。
不明点があれば質問してください。

このあとはAIと対話しながら、自社の状況に合わせて詰めていきます。「アイコンはこの画像を使いたい」「トップページだけでなく問い合わせページもオフラインで開きたい」など、要望を会話で足していくのが現実的な進め方です。プロンプトを完璧に作り込むより、出力を見ながら調整するほうが速く確実です。

手順3。マニフェストファイルを置く

マニフェストは、アプリの「名札」にあたる設定ファイルです。Cursorに作らせたうえで、中身が自社の情報になっているかを必ず人の目で確認します。標準的な書き方は次の通りで、これはツールの画面に依存しないので、そのまま参考にできます。

ファイル名は「manifest.webmanifest」とし、サイトのルート直下に置きます。なお、このファイルはJSON形式で、行コメント（//）を書き加えると読み込みに失敗します。下のコードはそのまま保存できる形にしてあるので、コメントは足さず、値だけを自社のものに書き換えてください。書き換える中心は次の3か所です。

• name：正式名称。
• short_name：短縮名。ホーム画面など、正式名称が入りきらないときに代わりに使われることがあります。
• theme_color：テーマカラーの色コード。

{
  "name": "コレットラボ",
  "short_name": "コレット",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#1f2a44",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" },
    { "src": "/icons/icon-512-maskable.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

各項目の意味も押さえておきましょう。「start_url」は起動時に開くページ、「display」を「standalone」にするとアドレスバーなどのブラウザの表示を除いた、アプリと同じ見た目で起動（表示領域全体を使うのは「fullscreen」）、「background_color」は起動時の背景色です。あわせて、全ページのHTMLの<head>内にマニフェストを読み込む記述を足します。Cursorに頼めば一括で入れてくれますが、内容はこの形です。

<link rel="manifest" href="/manifest.webmanifest">
<meta name="theme-color" content="#1f2a44">
<!-- iOSでホーム画面アイコンをきれいに出すための保険 -->
<link rel="apple-touch-icon" href="/icons/icon-192.png">

手順4。service workerを置いて読み込む

service workerは、表示を速くしたりオフライン表示を可能にしたりする裏方のプログラムです。まずは「2回目以降の表示を速くする」最小構成から始めるのが安全です。次のコードはコピーすれば動く完結した形になっています。

// ファイル名：sw.js（サイトのルート直下に置く）
// 役割：よく使うファイルを保存し、2回目以降の表示を速く・オフラインでも開けるようにする

const CACHE_NAME = 'site-v1';  // ［更新時はv2,v3…と上げる。これが更新の合図になる］

// 最初に保存しておくファイル一覧（自分のサイトに合わせて増やす）
const ASSETS = [
  '/',
  '/index.html',
  '/style.css',     // ［自社のCSSファイル名に変更］
  '/main.js',       // ［自社のJSファイル名に変更／無ければ削除］
  '/offline.html'   // ［オフライン時に出す予備ページ。用意しておくと親切］
];

// インストール時に一覧のファイルを保存
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(ASSETS))
  );
});

// 新バージョンに切り替わったとき、古いキャッシュを掃除
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(keys.filter((k) => k !== CACHE_NAME).map((k) => caches.delete(k)))
    )
  );
});

// 表示時は、保存済みがあればそれを返し、無ければ通信。通信も失敗したら予備ページを返す
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) =>
      cached || fetch(event.request).catch(() => caches.match('/offline.html'))
    )
  );
});

このsw.jsを動かすには、各ページで読み込む登録コードが要ります。これもHTMLに一度入れるだけです。

<script>
// service workerに対応したブラウザだけで登録する
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}
</script>

service workerは強力な反面、設定を誤ると「古いページがいつまでも表示される」「更新が反映されない」というトラブルの原因になります。だからこそ最初は上のような最小構成にとどめ、CACHE_NAMEのバージョンを更新のたびに上げる運用を徹底してください。いきなり複雑なキャッシュ戦略を組まないのがコツです。

手順5。出力を確認して仕上げる（ここが一番大事）

AIはコードを生成できますが、「これで本当に正しいか」の最終判断は人がやります。Cursorが出したものを、次のチェックリストで確認しましょう。これがPWA化の品質を決めます。

• アプリ名・色・アイコンの値：マニフェストの中身が、コピペ元のままになっていないか。自社の情報に置き換わっているか。
• ファイルの置き場所：マニフェストとsw.jsがサイトのルート直下にあるか。階層がずれると読み込まれません。
• HTTPSで配信されているか：本番URLが「https://」で始まっているか。ローカル確認以外はHTTPS必須です。
• キャッシュ一覧の正しさ：ASSETSに書いたファイル名が、実際に存在するファイルと一致しているか。存在しない名前が1つでもあると、service workerのインストールが失敗して動きません。
• 監査ツールでの点検：Chromeに付属のLighthouse（ライトハウス）などの監査ツールで、表示速度や品質を点検する。

「ホーム画面に追加できる」状態の条件は、Mozillaの開発者向け資料PWA をインストール可能にする（MDN）でも整理されています。MicrosoftのPWA の開発を開始する（Microsoft Learn）もあわせて読むと、要件の全体像がつかめます。Cursorの提案に不安があるときは、こうした一次情報と突き合わせて確認するのが確実です。なお、Cursorの画面上のボタン名やメニューの位置は更新で変わることがあるため、操作の細部は公式ヘルプで最新の表示を確認してください。

コードを読めなくてもAIと対話しながらサイトを直していく進め方は、Vibe Codingでサイト修正でも具体的に紹介しています。PWA化と同じ感覚で取り組めます。

PWA化で実際にどんな変化が期待できるか

PWA化の効果は、大きく「表示の速さ」「再訪のしやすさ」「アプリ化の心理的な近さ」の3つに表れます。順番に見ていきましょう。

まず表示の速さです。service workerが一度見たファイルを手元に保存するため、2回目以降のアクセスは通信を待たずに表示できます。ページを開いた瞬間に出る感覚に近づくので、「読み込みが遅くて離脱する」というモバイルサイトの弱点を補えます。

次に再訪のしやすさです。ホーム画面にアイコンが置かれると、ブラウザでURLを打ち直す手間がなくなります。タップ1回で、アドレスバーを表示せずに起動できるので、リピート利用が前提のサービスや会員向けサイトでは、戻ってきてもらいやすくなります。MDNも、インストールしたPWAは「他のアプリのように OS から直接起動できる」と説明しています。

3つ目はアプリ化の心理的な近さです。アプリストアの審査やインストールの抵抗を避けながら、「アプリを持っている」体験を提供できます。ストア配信のネイティブアプリを別途作るのに比べ、既存サイトを土台にできる分、初期コストと運用コストを抑えやすくなります。

数字の扱いについて。PWA導入による改善幅は、サイトの作りや業種、もともとの速度によって大きく変わります。仮にトップページの再表示が数秒から1秒未満に縮むケースを考えると、離脱の抑制やページ回遊の増加が見込めますが、これはあくまで条件次第の例示です。自社の効果は、導入前後でLighthouseのスコアや実際の表示時間を計測して判断するのが確実です。

なお、PWAは通常のWebサイトとして配信するため、MDNも説明しているとおり、ウェブ検索から見つけてもらう経路はそのまま残ります。そのため、ユーザー行動（回遊や再訪）を損なわずに体験だけをアプリ風に底上げできる、という点が中小企業にとって現実的なメリットです。Cursorで配色などのデザインを変更する進め方はCursorでダークモードを後付けする方法も参考になります。

よくある失敗と、その防ぎ方

PWA化は手順自体はシンプルですが、つまずきやすい点は決まっています。代表的な3つを「どんな状況で起きるか → どうなるか → どう防ぐか」のセットで紹介します。

失敗1。古いページが表示され続ける（キャッシュ事故）

サイトを更新したのに、ユーザーの画面では前の内容のまま。これはservice workerのキャッシュが効きすぎて起きる、起きやすいトラブルです。料金やお知らせを直したのに反映されない、という事故につながります。

防ぎ方はシンプルです。内容を更新したら、必ずsw.js内のCACHE_NAMEのバージョン（site-v1→site-v2）を上げること。これが「中身が変わったので保存し直して」という合図になります。さらに、価格やお知らせなど頻繁に変わるページは、無理にキャッシュ対象に含めない判断も有効です。

失敗2。iOSで思ったように動かない

Androidでは問題なく動いたのに、iPhoneでは挙動が違うことがあります。これはAndroidとiOSでPWAの対応状況が異なるために起きます。iOSのSafariでは、利用者が共有メニューから手動で「ホーム画面に追加」を選ぶ必要があります。プッシュ通知などの対応状況はiOSのバージョンによっても変わるため、自社が想定する端末・OSでどこまで動くかは、AppleやMDNの最新情報を確認したうえで判断してください。

防ぎ方は、公開前に必ず複数の環境（iPhoneのSafari、AndroidのChromeなど）で実機テストをすること。そして「通知は事業の生命線か」を先に見極めることです。通知の確実性が売上に直結するなら、PWA単独に賭けず、Androidを重視する設計や別手段の併用を検討します。

失敗3。「アプリなのに使い方が分からない」と言われる

多くの人にとって「アプリ＝ストアから入れるもの」です。そのため「サイトからホーム画面に追加する」という流れ自体が伝わらず、せっかくPWA化しても使われない、という状況が起こります。

防ぎ方は、追加のやり方を画面上で分かりやすく案内することです。「ホーム画面に追加すると次回から速く開けます」といった一文と、簡単な手順（共有ボタンから追加するなど）を、邪魔にならない位置にそっと置く。技術より「伝え方」で差がつくポイントです。

プッシュ通知などでユーザー情報を扱う場合は、何をどこに保存するかを設計段階で決めておきましょう。AIに作らせたコードをそのまま本番に出す前に、個人情報の扱いを点検する習慣が大切です。社内ルールの作り方はAIに入力してはいけない個人情報｜線引きと社内ルールの作り方を参考にしてください。

PWA化の落とし穴と妥協点

ここまで前向きな話をしてきましたが、PWAは万能ではありません。導入前に知っておいてほしい注意点をお伝えします。

まず、PWAは「ネイティブアプリの完全な代わり」ではありません。特にiOSでは機能の制約があり、通知の確実性やOSの深い機能を使う点では、ストア配信のアプリに及ばない場面があります。「アプリと同じことが全部できる」と期待してスタートすると、後でギャップに悩みます。最初に「PWAでできること・できないこと」を線引きしておくのが、満足度を下げないコツです。

次に、AIに任せきりにできる範囲の話です。マニフェストや基本のservice workerのような定型コードは、Cursorに作らせて十分機能します。ここは内製で回せる部分です。

一方で、キャッシュをどう設計するか、どのページを保存対象にするか、通知をどう扱うかといった「運用方針の判断」は、サイトの目的を理解している人でないと決められません。ここを曖昧にしたままAIに丸投げすると、冒頭の「古いページが残り続ける」事故につながります。AIは生成役、人は判断役、という役割分担を崩さないことです。

コスト面の見落としもあります。PWA化そのものは安く始められますが、ネイティブアプリと並行運用する場合は、管理する対象が二重になり、かえって手間が増えることがあります。「アプリも作ってPWAも作る」と欲張る前に、まずどちらか一方で十分かを冷静に考えたほうがよいケースが多いです。

そして公開後の運用です。PWAは、そのままではアプリストアに並びません。Google PlayやMicrosoft Storeでも公開できますが、ストアごとにパッケージ化する作業が別に必要です。ストアに出さない限り、ストア経由の新規露出は期待できません。存在を知ってもらうには、検索やSNS、サイト上での案内といったWeb側の集客が前提になります。「作れば使われる」ではなく「作ってから、どう届けるか」までを最初に設計しておく。ここまで考えられているかどうかで、PWA化が成果につながるかが分かれます。

現場の結論。PWA化は「内製で始めて、判断と運用設計だけ押さえる」のが最も費用対効果が高い進め方です。技術的な実装はAIで巻き取れる時代になりました。難しいのは技術より、自社にとっての正解を決める部分です。

よくある質問（FAQ）

まずは「自社に合うか」を整理するところから

スマートフォンでの見やすさから、サイトのリニューアルを検討している方は、コレットラボのホームページ制作・LP制作をご覧ください。デザインはスマートフォンで見たときの画面から作り、公開前にスマートフォンとパソコンの両方で文章とリンクを確認します。