SaaSとバックエンドを共有するChrome拡張機能の作り方は？
第2のバックエンドを建てないことです。MV3拡張機能はHttpOnly Cookieに依存できないため、ワークスペースAPIキーで認証します。拡張機能は1つのワークスペースに紐付いたスコープ付きキーで、アプリのバージョン付きREST API（/api/v1）を呼び、Webアプリと同じ認証モデル・テナントスコープ・Postgres DBを再利用します。supastackのMV3スキャフォールド——ポップアップ、オプションページ、バックグラウンドワーカー、最小権限マニフェスト——はまさにこの配線です。
罠：気づかぬうちに建てる第2のバックエンド
よくある話です。SaaSに、ページ取得やコンテンツのクリップ、Webへの注釈のためのコンパニオン拡張機能が必要になる。半年後、あなたは2つの認証系（WebはCookie、拡張は手作り）、拡張が本当に呼べる並行API、そして本来1つのはずだった2つのデータストアを整合させる同期層を保守しています。
そのすべては不要です。拡張機能は既存製品の1クライアントにすぎません——保持できる資格情報と、プログラムアクセスのためのAPIがあれば足ります。間違いは、立派なSaaSがすでに持っているワークスペースAPIキーとバージョン付きREST面ではなく、新しいバックエンドに手を伸ばすことです。
Manifest V3で実際にできること
MV3はバックグラウンドページを短命のService Workerに置き換え、拡張機能を最小権限へと押しやりました。実務上は、永続的なメモリ状態に頼れず、セッション再利用のためにCookieを掻き回すべきではなく（HttpOnly Cookieはそもそも届かない）、すべてのホスト権限がWebストア審査の質問項目になります。
綺麗な答えはプラットフォームがすでに用意しているものです。chrome.storage.localのスコープ付き資格情報と、アプリのオリジンへのHTTPS呼び出し——インストール時ではなくセットアップ時にオプションホスト権限として要求します。
supastackのMV3スキャフォールド：配線済みの部分
supastackのapps/extensionは、意図的に小さくフレームワークレスに作られたManifest V3コンパニオン——「ページをワークスペースに保存」——で、パターン全体をエンドツーエンドで示します。アクティブタブのタイトル・URL・選択テキストを、バージョン付きREST API POST /api/v1/content-entries経由でワークスペースのコンテンツエントリに保存します。
認証はSettings → Developersで発行するワークスペースAPIキー（sk_…）。キーはちょうど1つのワークスペースに紐付くため、その紐付け自体がワークスペース選択であり、キーは決して外部には書けません。オプションページはアプリURLとキーをchrome.storage.localに保存し、そのオリジンのみへのアクセスを要求し、GET /api/v1/workspaces/currentで接続を確認します。
apps/extension/
manifest.json MV3: service worker, least-privilege permissions
src/
background.js context-menu save + badge feedback
popup.html/.js capture UI — title, URL, selection, note
options.html/.js app URL + workspace API key setup
lib/
api.mjs versioned /api/v1 client (key auth)
capture.mjs active-tab + selection capture
config.mjs chrome.storage.local persistence既定で最小権限
スキャフォールドは、仕事に必要な最小限の権限だけを同梱します——Webストア審査とユーザー信頼の両方に効きます：
tabsなし、<all_urls>なし、cookies/webRequest/declarativeNetRequestなし——不要なものを正直に宣言するスキャフォールドです。
| 権限 | 理由 |
|---|---|
| activeTab | 呼び出し時のみ現在ページのタイトル/URLを読む |
| scripting | 呼び出したタブ内の選択テキストを読む |
| contextMenus | 右クリックの保存メニューを登録 |
| storage | アプリURL、APIキー、キャッシュ済みワークスペースを保持 |
| optional_host_permissions | アプリオリジンはセットアップ時に要求——インストール時のサイトアクセスはゼロ |
スキャフォールドから自社製品のコンパニオンへ
リブランドはmanifest.jsonの名前変更で、拡張は面白い部分——そして同じパターンの内側に留まります。新しいキャプチャ種別は同じキーで新しい/api/v1エンドポイントを呼び、アプリのOpenAPIドキュメントから生成される型付き@supastack/api-sdkがリクエスト形状の誠実さを保ちます。
拡張機能は他のクライアントと同じテナントスコープAPIで読み書きするため、保存したページはWebダッシュボードが一覧する同じPostgres行に落ちます——1つのDB、1つの認証モデル、workspaceIdスコープを強制する場所は1か所。第2バックエンドなし、同期なし、ドリフトなし。ティアは価格ページで比較を。
| DIY第2バックエンド方式 | supastack MV3スキャフォールド | |
|---|---|---|
| 認証 | Cookieの隣に手作りトークン系 | ワークスペースAPIキー——Webと同じ認証モデル |
| API | 拡張用に新エンドポイントを発明 | バージョン付き/api/v1 + OpenAPI型付きSDK |
| データ | 第2ストア + 同期ロジック | 同じPostgres行、ワークスペーススコープ |
| 権限 | 便利さ優先の広いアクセス | 最小権限マニフェスト、審査に有利 |
FAQ：1つのバックエンドでのSaaS + Chrome拡張
拡張コンパニオンを出荷する前に開発者が尋ねる質問：
- セッションCookieではなくAPIキーなのはなぜ？, HttpOnly Cookieは設計上、拡張JSから不可視で、MV3 Service Workerは短命です。
chrome.storage.localのスコープ付きsk_…キーは永続・失効可能で、1ワークスペース紐付きのためテナントを跨げません。 - Firefoxでも動きますか？, MV3は同じ面をサポートします。コードは
browser ?? chromeの名前空間シムでChromium優先に開発されているため、Firefoxは書き直しではなく移植です。 - そのままストア申請できますか？, 本番パターンのスキャフォールドであり、ストア提出物ではありません。マニフェストの改名、独自キャプチャロジック、リスティング文はあなたの仕事です。難しい部分（認証、API、テナントスコープ）は完成済みです。
- 拡張機能が含まれるライセンスは？, $299のFull Bundleが5面すべて——2つのWebエンジン、Expo、Tauri、拡張機能スキャフォールド——を1リポジトリで提供します。