🌍 001 システム全体像 (Overview)
登場人物・技術スタック・データフロー・Vercelの役割
設計書 v1.0 / 2026-04-19
1 登場人物
以下7つの登場人物でこのアプリは構成されています。
凡例ユーザーのもの（PC・iPhone・Drive）開発者のもの（Vercel）外部サービス（APNs・Google OAuth2）
図 1-1 システム全体関係図
登場人物の役割一覧
表 1-1 登場人物の役割一覧
| No | 登場人物 | 一言で言うと | 何のために使うか |
|---|---|---|---|
| 1 | 1⃣ 🖥 PC アプリ | デスクトップ付箋アプリ | 付箋の表示・編集・保存。iPhone に通知付きで送信。iPhone から受け取って付箋を開く |
| 2 | 2⃣ 📱 iPhone PWA | ホーム画面に追加した Web アプリ | PC からのノートを受け取り閲覧。メモを書いて PC に送る |
| 3 | 3⃣ ⚙️ Service Worker | iPhone の常駐プログラム | アプリを閉じていても Push を受信してノートを保存・通知表示。IndexedDB がデータの唯一の保存場所 |
| 4 | 4⃣ ☁️ Google Drive | PC と iPhone の中継所 | ノートデータを一時的に置く場所。処理したら即削除。開発者はアクセス不可 |
| No | 登場人物 | 一言で言うと | 何のために使うか |
|---|---|---|---|
| 5 | 5⃣ 🌐 Vercel | 開発者が置いた Web サーバー | iPhone PWA を配信。client_secret をブラウザに渡さず保護するための認証 API を置く |
| 6 | 6⃣ 🔑 Google OAuth2 | Drive の鍵を発行する仕組み | ユーザーが自分の Drive を読み書きするための access_token を取得する |
| 7 | 7⃣ 📡 APNs / FCM | 通知配信サーバー | PC からの「通知してください」を受け取り iPhone に届ける。APNs は iPhone/Mac、FCM は Chrome/Android |
2 技術スタック
PCアプリ・iPhone PWA・共有インフラの3層に分けて使用技術を整理します。
表 2-1 技術スタック一覧
🖥 PC アプリ
| 領域 | 技術・役割 |
|---|---|
| フレームワーク | Tauri v2（WebView + Rust） |
| UI | Next.js 14 / React 18 / TypeScript / Tailwind |
| エディタ | CodeMirror 6（Markdown ハイライト・検索） |
| バックエンド | Rust（AppState・ファイル I/O・Win32 API） |
| データ保存 | ファイルシステム（JSON / Markdown） |
| テスト | Vitest（ユニット）/ Playwright（E2E） |
📱 iPhone PWA
| 領域 | 技術・役割 |
|---|---|
| ページ | Next.js 14 App Router（app/viewer/page.tsx） |
| 配信 | Vercel（API Routes も同居） |
| バックグラウンド | Service Worker（worker/index.js） |
| ローカル DB | IndexedDB（fusen-drafts） |
| 認証 | Google OAuth2（Vercel API 経由） |
| 通知 | Web Push / APNs / FCM |
🌐 共有インフラ
| 領域 | 技術・役割 |
|---|---|
| ホスティング | Vercel（PWA 配信・OAuth2 API） |
| データ中継 | Google Drive API（ユーザー所有） |
| 通知基盤 | APNs / FCM（Apple / Google 運営） |
| CI / CD | GitHub Actions（ビルド・Winget 自動リリース） |
3 データフロー概要（2つのフロー）
PCアプリ・iPhone・Driveを結ぶ2つのデータの流れを概観します。
3.1 ➡️ フロー① PC → iPhone（メモを受け取る）
PCで書いたメモが、ロック画面の通知として iPhone に届くまでの全工程です。
図 3.1-1 PC → iPhone データフロー概要
3.2 ⬅️ フロー② iPhone → PC（メモを送る）
図 3.2-1 iPhone → PC データフロー概要
4 なぜ Vercel が必要か
Google OAuth2 の client_secret を安全に保護するためにVercelが必要な理由を説明します。
守っている対象：開発者（アプリ作者）のアプリ自体。 ユーザーの秘密情報ではない。
client_secret は開発者が Google Cloud Console で発行した「このアプリが本物であることを証明する鍵」。漏れると開発者のアプリが停止・悪用されるリスクがある。iPhone のコードに埋め込むと Safari DevTools で誰でも読めてしまう。
表 4-1 client_secret 保護方式の比較
| No | 手法 | client_secret の場所 | 問題点・利点 |
|---|---|---|---|
| 1 | ✕ iPhone 直接 | iPhone のコードに埋め込む | Safari DevTools でユーザーが読める → 開発者のアプリが悪用される |
| 2 | ✔ Vercel 経由 | Vercel の環境変数に置く | iPhone（Safari）には届かない。Vercel のサーバー内だけで使われる |
5 改版履歴
表 5-1 改版履歴
| No | バージョン | 日付 | 変更内容 |
|---|---|---|---|
| 1 | 1.0 | 26-04-19 | 設計書を 001/002/003 に再編。本ファイル（001）は全体像を担当。旧 001_ARCHITECTURE_DESIGN・003_SYSTEM_OVERVIEW の該当部分を統合 |
| 2 | 1.1 | 26-04-24 | システム全体関係図を graph LR（横向き）に変更。スクロールなしで全体が見えるよう改善。 |