CursorでPWA化する手順｜非エンジニアでもスマホアプリ風に
この記事の要点
- PWA化に最低限必要なのはマニフェスト・service worker・HTTPSの3点
- Cursorに材料と完成イメージを渡し、出力を人が確認して直すのが基本の進め方
- iOSは通知や挙動に制約があり、過信せず公開前テストで切り分ける
「自社サイトをアプリストアに出すほどではないけれど、スマホのホーム画面から起動できるアプリっぽい見え方にしたい」。そう考えてPWA化にたどり着いた方は多いはずです。
この記事では、AIコードエディタのCursorを使って、既存のWebサイトをスマホアプリ風（PWA）に作り変える手順を、非エンジニアの方にも分かるように解説します。何を準備し、Cursorに何を渡し、出てきたコードのどこを確認すればいいか。実際に手を動かせるところまで踏み込みます。
Contents / 目次
結論。PWA化は「3つの部品」をそろえるだけで始められる
PWA化で最初にやるべきことは、サイトに足りない「3つの部品」をそろえることです。難しい改修は要りません。既存のサイトを土台にして、足りないものを追加するイメージです。
PWAとは、かんたんに言うと「Webサイトなのに、スマホアプリのように使えるサイト」のことです。ホーム画面にアイコンを置けて、起動するとブラウザのアドレスバーが消えて全画面で立ち上がり、通信が不安定でも前に見たページが表示される。こうした体験をふつうのサイトに足す技術です。
そのために必要な部品は次の3つです。ここを押さえれば全体像がつかめます。
- Web App Manifest（マニフェスト）：アプリ名・アイコン・テーマカラー・起動時の画面などを書いた設定ファイル。これがあるとホーム画面に追加できるようになります。
- Service Worker（サービスワーカー）：裏側で動く小さなプログラム。ページの中身を一時保存（キャッシュ）して、表示を速くしたりオフラインで開けるようにしたりします。
- HTTPS：通信が暗号化された安全な状態。PWAはセキュリティ上、HTTPSで配信されているサイトでしか動きません。
つまり、PWA化は「ゼロから作り直す」作業ではなく、「今あるサイトに設定ファイルと小さなプログラムを足す」作業です。だからこそ、コードを全部自分で書けなくても、Cursorのようなツールに手伝ってもらえば内製で進められます。
下の表で、PWAとネイティブアプリ（App StoreやGoogle Playから入れる従来のアプリ）の違いを整理しておきましょう。どちらを選ぶか迷ったときの判断材料になります。
| 比較項目 | PWA（スマホアプリ風サイト） | ネイティブアプリ |
|---|---|---|
| 入手方法 | サイトを開いて「ホーム画面に追加」 | App Store / Google Playから審査を経て配信 |
| 開発の土台 | 既存のWebサイトを活かせる | iOS用・Android用に別々に作るのが基本 |
| 更新のしやすさ | サイトを更新すれば即反映 | ストア審査を経て配信 |
| 検索流入 | 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は、ざっくり伝えればこちらの意図をくみ取り、足りない情報を質問し返してくれます。出発点として、次のくらいの短い「たたき台」で十分です。
このフォルダの既存サイトをPWA化したいです。
- アプリ名：［正式名称を入力］／短縮名：［短い名前を入力］
- テーマカラー：［色コードを入力］
- やりたいこと：ホーム画面に追加できる、2回目以降の表示を速くする、簡単なオフライン表示
まず必要なファイル（マニフェスト・service worker）と、HTMLへの追記内容を提案してください。
不明点があれば質問してください。このあとはAIと対話しながら、自社の状況に合わせて詰めていきます。「アイコンはこの画像を使いたい」「トップページだけでなく問い合わせページもオフラインで開きたい」など、要望を会話で足していくのが現実的な進め方です。プロンプトを完璧に作り込むより、出力を見ながら調整するほうが速く確実です。
手順3。マニフェストファイルを置く
マニフェストは、アプリの「名札」にあたる設定ファイルです。Cursorに作らせたうえで、中身が自社の情報になっているかを必ず人の目で確認します。標準的な書き方は次の通りで、これはツールの画面に依存しないので、そのまま参考にできます。
ファイル名は「manifest.webmanifest」とし、サイトのルート直下に置きます。なお、このファイルはJSON形式で、行コメント（//）を書き加えると読み込みに失敗します。下のコードはそのまま保存できる形にしてあるので、コメントは足さず、値だけを自社のものに書き換えてください。書き換える中心は次の3か所です。
- name：正式名称。
- short_name：短縮名（12文字程度まで）。
- 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」にするとアドレスバーを消して全画面で起動、「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に書いたファイル名が、実際に存在するファイルと一致しているか。存在しない名前を書くと登録に失敗します。
- 監査ツールでの点検：Chromeに付属のLighthouse（ライトハウス）などの監査ツールで、表示速度や品質を点検する。
「ホーム画面に追加できる」状態の条件は、Mozillaの開発者向け資料PWA をインストール可能にする（MDN）でも整理されています。MicrosoftのPWA の開発を開始する（Microsoft Learn）もあわせて読むと、要件の全体像がつかめます。Cursorの提案に不安があるときは、こうした一次情報と突き合わせて確認するのが確実です。なお、Cursorの画面上のボタン名やメニューの位置は更新で変わることがあるため、操作の細部は公式ヘルプで最新の表示を確認してください。
コードを読めなくてもAIと対話しながらサイトを直していく進め方は、「指示出し」だけでサイトが直る快感：Vibe CodingでWeb担当者の脱ストレスでも具体的に紹介しています。PWA化と同じ感覚で取り組めます。
PWA化で実際にどんな変化が期待できるか
PWA化の効果は、大きく「表示の速さ」「再訪のしやすさ」「アプリ化の心理的な近さ」の3つに表れます。順番に見ていきましょう。
まず表示の速さです。service workerが一度見たファイルを手元に保存するため、2回目以降のアクセスは通信を待たずに表示できます。ページを開いた瞬間に出る感覚に近づくので、「読み込みが遅くて離脱する」というモバイルサイトの弱点を補えます。
次に再訪のしやすさです。ホーム画面にアイコンが置かれると、ブラウザでURLを打ち直す手間がなくなります。タップ1回で全画面起動できるので、リピート利用が前提のサービスや会員向けサイトでは、戻ってきてもらえる確率が上がります。OSにアプリのように常駐する点は、MDNでも「インストールされると、プラットフォーム固有のアプリとしてユーザーに現れる」と説明されています。
3つ目はアプリ化の心理的な近さです。アプリストアの審査やインストールの抵抗を避けながら、「アプリを持っている」体験を提供できます。ストア配信のネイティブアプリを別途作るのに比べ、既存サイトを土台にできる分、初期コストと運用コストを抑えやすいのが現場での実感です。
数字の扱いについて。PWA導入による改善幅は、サイトの作りや業種、もともとの速度によって大きく変わります。仮にトップページの再表示が数秒から1秒未満に縮むケースを考えると、離脱の抑制やページ回遊の増加が見込めますが、これはあくまで条件次第の例示です。自社の効果は、導入前後でLighthouseのスコアや実際の表示時間を計測して判断するのが確実です。
なお、PWAはWebサイトとして検索エンジンにもインデックスされます。アプリ化しても検索からの流入経路を失わないため、ユーザー行動（回遊や再訪）を損なわずに体験だけをアプリ風に底上げできる、という点が中小企業にとって現実的なメリットです。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に入力してはいけない個人情報｜AIセキュリティ社内ルールの作り方を参考にしてください。
PWA化の落とし穴と、現場で見える妥協点
ここまで前向きな話をしてきましたが、PWAは万能ではありません。相談前に知っておいてほしい「本音」を率直にお伝えします。
まず、PWAは「ネイティブアプリの完全な代わり」ではありません。特にiOSでは機能の制約があり、通知の確実性やOSの深い機能を使う点では、ストア配信のアプリに及ばない場面があります。「アプリと同じことが全部できる」と期待してスタートすると、後でギャップに悩みます。最初に「PWAでできること・できないこと」を線引きしておくのが、満足度を下げないコツです。
次に、AIに任せきりにできる範囲の話です。マニフェストや基本のservice workerのような定型コードは、Cursorに作らせて十分機能します。ここは内製で回せる部分です。
一方で、キャッシュをどう設計するか、どのページを保存対象にするか、通知をどう扱うかといった「運用方針の判断」は、サイトの目的を理解している人でないと決められません。ここを曖昧にしたままAIに丸投げすると、冒頭の「古いページが残り続ける」事故につながります。AIは生成役、人は判断役、という役割分担を崩さないことです。
コスト面の見落としもあります。PWA化そのものは安く始められますが、ネイティブアプリと並行運用する場合は、管理する対象が二重になり、かえって手間が増えることがあります。「アプリも作ってPWAも作る」と欲張る前に、まずどちらか一方で十分かを冷静に考えたほうがよいケースが多いです。
そして公開後の運用です。PWAはアプリストアに並ばないため、ストア経由の新規露出は期待できません。存在を知ってもらうには、検索やSNS、サイト上での案内といったWeb側の集客が前提になります。「作れば使われる」ではなく「作ってから、どう届けるか」までを最初に設計しておく。ここまで考えられているかどうかで、PWA化が成果につながるかが分かれます。
現場の結論。PWA化は「内製で始めて、判断と運用設計だけ押さえる」のが最も費用対効果が高い進め方です。技術的な実装はAIで巻き取れる時代になりました。難しいのは技術より、自社にとっての正解を決める部分です。
よくある質問（FAQ）
プログラミングが分からなくてもPWA化できますか
基本的な部分はできます。Cursorに「サイトをPWA化したい」と伝えれば、必要なファイルやコードを提案してくれます。ただし出てきた内容が自社向けになっているかの確認は人が行う必要があるため、最低限の見極めは身につけたいところです。
PWAにすると検索（SEO）に不利になりませんか
不利にはなりません。PWAはWebサイトとして検索エンジンにインデックスされるため、検索からの流入経路は維持されます。むしろ表示が速くなることで、ユーザーが快適に回遊しやすくなる効果が期待できます。
iPhoneでもちゃんと動きますか
ホーム画面への追加や全画面起動は動きますが、プッシュ通知などはAndroidに比べて制約があります。通知が事業の中心でないなら十分実用的です。公開前にiPhoneの実機で必ずテストしてください。
ネイティブアプリとどちらを作るべきですか
既存サイトを活かしてアプリっぽく見せたいだけならPWAが向いています。カメラや決済など端末機能を深く使い、通知の確実性が最優先ならネイティブアプリも検討します。まずはPWAから試すのが現実的です。
まずは「自社に合うか」を整理するところから
ここまで読んで、PWA化の手順は分かったけれど「自社のサイトで本当にうまくいくか」「キャッシュや通知の設計を任せられる人が社内にいない」と感じた方もいるはずです。コレットラボのAI業務システム化支援では、AIで内製したい会社にも、まるごと任せたい会社にも合わせて、判断と運用設計から伴走します。いきなり契約ではなく、現状を整理するだけの相談でも大丈夫です。AI業務システム化の詳細はこちらからお気軽にお声がけください。
30分の無料相談
現状をお聞きし、優先順位を一緒に整理します。
予約する →
