📋 000 要求仕様 (Requirements)
機能要件・非機能要件・USDM
v2.10 | 2026-04-19 | USDM (Universal Specification Describing Manner)
1 全体概要
このプロダクトが何者で、どの品質基準を満たすかを定義します。
1.1 製品定義
毎日、アプリを渡り歩いていた。
付箋アプリ・テキストエディタ・スプレッドシート・ノートアプリ・メッセージアプリ……
それぞれ「惜しい」。全部揃ったものが、ない。
欲しいものが、ない。
だから作った。

図 1-1 設計の芯:各ツールの良いところだけを、ストレスなく一つに
図 1-2 ユースケース概要
表 1.1-1 製品定義
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_OV_01 | 【要求】 ユーザーは、デスクトップ上で手軽にメモを取り、それらをファイルとして永続化・管理できるアプリケーションを求めている。 【理由】 既存の付箋アプリはデータのポータビリティが低く、テキストエディタは起動や管理が手軽でないため。 | SPEC-OV-01-01 | アプリケーション名は「俺の付箋 (OreNoFusen)」とする。 |
| SPEC-OV-01-02 | Windows デスクトップアプリケーションとして動作し、.exe 形式で配布される(Tauri v2 環境)。 | ||
| SPEC-OV-01-03 | データの実体はプレーンテキスト(Markdown)とし、独自データベースを持たない。 | ||
| SPEC-OV-01-04 | iPhone PWA(/viewer)を補助アプリとして提供し、Google Drive 経由で PC と双方向同期する。 | ||
1.2 品質保証
表 1.2-1 品質保証
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_OV_02 | 【要求】 ユーザーは、日常的に安心して使用できる安定した品質を求めている。 【理由】 メモアプリは毎日使うツールであり、予期しないクラッシュやデータ欠損が起きると信頼を失うため。 | SPEC-OV-02-01 | リリース前に Backend(Rust)ユニットテスト・Frontend E2E テストをクリアすること。 |
| SPEC-OV-02-02 | 既知の許容不具合(v2.10 時点):パブリッシャー情報が一部 OS 画面で表示されない(仕様として許容)。 | ||
2 ライフサイクル要件
アプリの起動・終了・作成・削除など、付箋のライフサイクル全体を定義します。
2.1 アプリケーションの常駐と起動
表 2.1-1 アプリケーションの常駐と起動
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_LF_01 | 【要求】 ユーザーは、アプリを常に起動状態のまま維持し、必要な時に素早くメモを確認したい。 【理由】 メモを取りたい瞬間に起動待ち時間が発生すると、思考が中断されるため。 | SPEC-LF-01-01 | アプリケーションはシステムトレイに常駐する。 |
| SPEC-LF-01-02 | 起動時、設定されたフォルダ(Vault)をスキャンし、以前の状態(位置・サイズ)で付箋ウィンドウを復元する。 | ||
| SPEC-LF-01-03 | ウィンドウの復元は、負荷分散のためキューシステムを用いて順次行う。 | ||
| SPEC-LF-01-04 | 二重起動を防止する(tauri-plugin-single-instance)。 | ||
2.2 初回セットアップ
表 2.2-1 初回セットアップ
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_LF_02 | 【要求】 ユーザーは、最初にアプリを使用した際に、メモの保存場所を自分で決めたい。 【理由】 デフォルトの場所に勝手に保存されると、ユーザーのファイル管理ポリシーに反する場合があるため。 | SPEC-LF-02-01 | 初回起動時(設定ファイルが存在しない場合)、セットアップ画面を表示する。 |
| SPEC-LF-02-02 | ユーザーにフォルダ選択ダイアログを提示し、選択されたパスを「ベースフォルダ」として保存する。 | ||
| SPEC-LF-02-03 | セットアップ完了後、メインウィンドウをダッシュボードモード(小型)に切り替える。 | ||
2.3 新規付箋の作成
表 2.3-1 新規付箋の作成
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_LF_03 | 【要求】 ユーザーは、思いついたその瞬間に新しいメモを書き始めたい。 【理由】 操作の手数が多すぎると、メモを取る意欲が減退するため。 | SPEC-LF-03-01 | システムトレイメニュー、または既存付箋の右クリックメニューから「新規メモ」を実行できる。 |
| SPEC-LF-03-02 | 作成操作後、即座に新しいウィンドウが開き、入力可能な状態(カーソルが1文字目に当たっている)になる。 | ||
| SPEC-LF-03-03 | ファイル名は作成日時から自動生成(NNNN_YYYY-MM-DD_Context.md)し、ユーザーに入力を求めない。 | ||
2.4 アプリケーションの終了
表 2.4-1 アプリケーションの終了
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_LF_04 | 【要求】 ユーザーは、メンテナンスや PC 終了時にアプリを完全に停止させたい。 【理由】 常駐アプリであっても、ユーザーの意思でプロセスを終了させる手段が必要不可欠であるため。 | SPEC-LF-04-01 | 個別の付箋を「閉じる(非表示にする)」汎用ボタンは提供しない。「アーカイブ」または「削除」を選択することで付箋をデスクトップから消去する。 |
| SPEC-LF-04-02 | システムトレイメニューの「終了」を選択した場合のみ、全プロセスを終了する。 | ||
2.5 アラーム機能
表 2.5-1 アラーム機能
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_LF_05 | 【要求】 ユーザーは、指定した時刻に付箋をデスクトップ通知として受け取りたい。 【理由】 重要なメモを決まった時刻に気づけるようにするためのリマインダーが必要なため。 | SPEC-LF-05-01 | 付箋ごとにアラーム日時を設定できる。設定はフッターエリアのボタンから行う。 |
| SPEC-LF-05-02 | 指定時刻にデスクトップ通知(OS ネイティブ)を表示し、通知クリックで該当付箋を前面に表示する。 | ||
| SPEC-LF-05-03 | アラームは一度発火したら解除される(繰り返しなし)。 | ||
3 データ管理要件
付箋データの保存形式・メタデータ・自動保存の仕組みを定義します。
3.1 Markdown 形式での保存
表 3.1-1 Markdown 形式での保存
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_DT_01 | 【要求】 ユーザーは、メモの内容を他のテキストエディタやツールでも閲覧・編集したい。 【理由】 独自フォーマットによるベンダーロックインを避け、長期的なデータの可読性を保証するため。 | SPEC-DT-01-01 | ファイル拡張子は .md とする。 |
| SPEC-DT-01-02 | 本文は標準的な Markdown 記法で保存する。 | ||
3.2 メタデータの管理
表 3.2-1 メタデータの管理
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_DT_02 | 【要求】 ユーザーは、前回終了時のウィンドウ位置・サイズ・色を維持したい。 【理由】 デスクトップ上の配置自体が情報の整理・優先度付けの意味を持つため。 | SPEC-DT-02-01 | windowX, windowY, width, height, backgroundColor, tags, alwaysOnTop 等を YAML Frontmatter 形式でファイル先頭に記録する。 |
| SPEC-DT-02-02 | アプリ以外のエディタで開いた際も、本文の可読性を損なわない形式とする。 | ||
3.3 ファイル名の自動同期
表 3.3-1 ファイル名の自動同期
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_DT_03 | 【要求】 ユーザーは、ファイル名を管理する手間から解放されたい。 【理由】 ファイル名を考える時間はメモの本質的な価値とは無関係であり、認知負荷を下げるため。 | SPEC-DT-03-01 | 本文の1行目をファイル名の「コンテキスト」部分として使用する。 |
| SPEC-DT-03-02 | 1行目が変更された場合、0.8 秒の待機時間(デバウンス)を経て自動的にリネームを実行する。 | ||
| SPEC-DT-03-03 | ファイルシステムで使用できない文字(\ / : * ? " < > |)は自動置換してサニタイズする。 | ||
3.4 変更の自動保存
表 3.4-1 変更の自動保存
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_DT_04 | 【要求】 ユーザーは、保存ボタンを押す操作を意識したくない。 【理由】 保存忘れによるデータ消失を防ぎ、紙の付箋のような「書けば残る」体験を提供するため。 | SPEC-DT-04-01 | テキスト変更後、自動的にファイルシステムへ書き込みを行う(アトミック処理でデータ破損を防ぐ)。 |
| SPEC-DT-04-02 | ウィンドウからフォーカスが外れた(Blur)時点で、未保存の変更があれば即座に保存する。 | ||
4 編集・表示要件
付箋の編集体験と表示機能を定義します。
4.1 リッチテキスト編集
表 4.1-1 リッチテキスト編集
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_ED_01 | 【要求】 ユーザーは、強調やリストなどの構造を使ってメモを見やすくしたい。 【理由】 プレーンテキストだけでは情報のメリハリが付けにくく、視認性が低いため。 | SPEC-ED-01-01 | **太字** は赤色・太字で表示する(重要事項の強調)。 |
| SPEC-ED-01-02 | # 見出し はフォントサイズを大きく表示する。 | ||
| SPEC-ED-01-03 | [ ] / [x] はクリック可能なチェックボックスとして表示する。 | ||
| SPEC-ED-01-04 | 編集モードと表示モードをダブルクリックで切り替える。クリック位置(余白・テキスト・フッター)によって編集開始位置をインテリジェントに制御する。 | ||
| SPEC-ED-01-05 | 元に戻す / やり直し(Undo/Redo)をサポートする。 | ||
4.2 画像の取り込み
表 4.2-1 画像の取り込み
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_ED_02 | 【要求】 ユーザーは、画面上の情報をスクリーンショットとして素早くメモに貼りたい。 【理由】 テキスト化しにくいビジュアル情報を、コンテキストを失わずに保存するため。 | SPEC-ED-02-01 | ツールバーのカメラボタン押下で、OS のスクリーンショットツールを起動する(Windows Snipping Tool 連携)。 |
| SPEC-ED-02-02 | クリップボード内の画像を assets フォルダに自動保存し、Markdown リンクとして挿入する。 | ||
| SPEC-ED-02-03 | エディタ上の画像はドラッグ操作で表示サイズ(倍率)を変更できる。 | ||
5 検索・整理要件
付箋の検索・タグ管理・アーカイブ・削除を定義します。
5.1 全文検索
表 5.1-1 全文検索
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_OR_01 | 【要求】 ユーザーは、大量のメモの中から特定のキーワードを含むものを即座に見つけたい。 【理由】 メモが増えるにつれて、視覚的な探索だけでは目的の情報に到達するのが困難になるため。 | SPEC-OR-01-01 | Ctrl+F またはトレイメニューから検索画面を開く。 |
| SPEC-OR-01-02 | 入力されたキーワードで全 .md ファイルを Grep 検索し、結果をオーバーレイのリスト UI で表示する。 | ||
| SPEC-OR-01-03 | 検索結果をクリックすると、該当する付箋ウィンドウを開き最前面へ移動する。 | ||
| SPEC-OR-01-04 | 検索ウィンドウは「×」ボタン押下時に破棄・非表示にし、システムリソースを節約する。 | ||
5.2 タグによるコンテキスト切り替え
表 5.2-1 タグによるコンテキスト切り替え
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_OR_02 | 【要求】 ユーザーは、現在の作業(仕事・プライベートなど)に関連するメモだけを表示したい。 【理由】 無関係なメモがデスクトップにあると集中を阻害するため。 | SPEC-OR-02-01 | 右クリックメニューから付箋に任意のタグ(複数可)を追加できる。 |
| SPEC-OR-02-02 | 全付箋から特定タグを一括グローバル削除できる削除モードをコンテキストメニュー内に提供する。 | ||
| SPEC-OR-02-03 | 「タグで絞り込み」機能により、選択したタグを持つ付箋のみを表示し、それ以外を非表示にする。 | ||
5.3 不要メモの整理(アーカイブ・削除)
表 5.3-1 不要メモの整理(アーカイブ・削除)
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_OR_03 | 【要求】 ユーザーは、アクティブでないメモをデスクトップから退避させたい。 【理由】 デスクトップ領域は有限であり、常に現在進行形の情報のみを配置したいため。 | SPEC-OR-03-01 | アーカイブ: 通常ノートは Archive/ フォルダへ移動。タグ付きノートは最初のタグフォルダ(例: tags/Work/)へ移動し、関連アセット(assets/内の画像)も同時に移動する。 |
| SPEC-OR-03-02 | 削除: ノートを Trash/ フォルダへ移動する。論理削除ではなく物理移動とする。 | ||
6 UI/UX 仕様
付箋ウィンドウの外観・コンテキストメニュー・効果音を定義します。
6.1 ウィンドウデザイン・外観
表 6.1-1 ウィンドウデザイン・外観
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_UI_01 | 【要求】 ユーザーは、愛着の持てる「かわいくてシンプル」な外観を求めている。 【理由】 デスクトップに常駐するアプリは毎日目に入るため、視覚的な心地よさがモチベーション維持に直結するため。 | SPEC-UI-01-01 | ウィンドウ枠(Decorations)を無効化し、背景を透過・角丸デザインとする。 |
| SPEC-UI-01-02 | 背景色はユーザーが任意に選択できる(デフォルト: 淡い黄色)。 | ||
| SPEC-UI-01-03 | ツールバーの各種操作アイコンは、付箋へのホバー時のみ表示され、閲覧時のノイズにならないようにする。 | ||
6.2 コンテキストメニュー
表 6.2-1 コンテキストメニュー
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_UI_02 | 【要求】 ユーザーは、付箋に対する操作を右クリックから直感的に行いたい。 【理由】 ショートカットを知らなくても直感的に機能にアクセスできるようにするため。 | SPEC-UI-02-01 | 右クリック時に Tauri 連携による独自カスタムメニューを表示する(現在のモードに応じてメニューを切り替える)。 |
| SPEC-UI-02-02 | 閲覧モード時: フォルダを開く / 新規メモ / 色を変更 / 常に手前 / タグ / アーカイブ / 削除 の7項目を基本構造とする。 | ||
| SPEC-UI-02-03 | 編集モード時: Undo/Redo / Cut/Copy/Paste/Select All / 日付挿入 / 時刻挿入 のテキスト操作特化メニューを表示する。 | ||
| SPEC-UI-02-04 | タグサブメニューには「削除モード(Delete Mode)」を提供し、タグのグローバル一括削除を安全に行える。 | ||
6.3 効果音
表 6.3-1 効果音
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_UI_03 | 【要求】 ユーザーは、無効化しない限り、付箋の操作時に心地よいフィードバックを得たい。 【理由】 視覚以外のフィードバックが操作の確実性を高めるため。 | SPEC-UI-03-01 | 効果音設定は設定画面でグローバルに ON/OFF 切り替え可能とする。 |
| SPEC-UI-03-02 | 設定変更は全ウィンドウに即座に反映されること。 | ||
7 インターフェース仕様
フロントエンド↔バックエンド間の通信と設定永続化の仕様を定義します。
7.1 フロントエンド–バックエンド間通信
表 7.1-1 フロントエンド–バックエンド間通信
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IF_01 | 【要求】 UI 操作は、安全かつ効率的にファイルシステムへ反映されなければならない。 【理由】 フロントエンドとバックエンドが分離した Tauri 構成では、通信の仕組みを明示しないと実装が散乱し、バグ混入やリソースリークが起きやすいため。 | SPEC-IF-01-01 | Tauri v2 の非同期コマンド(invoke)を使用してファイル操作を要求する。 |
| SPEC-IF-01-02 | 未処理の Floating Promise 防止設計を取り入れ、unlisten 等イベント解除の例外によるクラッシュをガードする。 | ||
| SPEC-IF-01-03 | システムイベント(設定変更・外部リロード・画面更新)は Tauri イベントシステム(emit / listen)で通知・同期する。 | ||
7.2 設定の永続化
表 7.2-1 設定の永続化
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IF_02 | 【要求】 アプリの設定(ベースフォルダ等)は再起動しても維持されなければならない。 【理由】 起動のたびに設定を求められるアプリは使い続けるのが苦痛になるため。 | SPEC-IF-02-01 | アプリのグローバル設定は JSON 形式で AppData ディレクトリに保存・参照する。 |
| SPEC-IF-02-02 | PWA 機能(Service Worker)は開発モードでは無効化し、エラーを抑制する。 | ||
8 非機能要件
ショートカット・マルチモニター・セキュリティ・パフォーマンス・多言語化を定義します。
8.1 キーボードショートカット操作
表 8.1-1 キーボードショートカット操作
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_NF_01 | 【要求】 ユーザーは、キーボードから手を離さずに主要な操作を素早く実行したい。 【理由】 思考のスピードを落とさないため。 | SPEC-NF-01-01 | Ctrl+N: 新規付箋の作成 |
| SPEC-NF-01-02 | Ctrl+F: 全文検索ウィンドウの呼び出し | ||
| SPEC-NF-01-03 | Ctrl+S: 明示的保存(基本は自動保存のため安心感の提供用) | ||
| SPEC-NF-01-04 | Esc: 開いているモーダル・ダイアログを閉じる | ||
| SPEC-NF-01-05 | Ctrl+B: 太字トグル(編集中) | ||
| SPEC-NF-01-06 | Ctrl+H: 見出し1トグル(編集中) | ||
| SPEC-NF-01-07 | Ctrl+L: 箇条書きトグル(編集中) | ||
| SPEC-NF-01-08 | Ctrl+Shift+C: チェックボックストグル(編集中) | ||
| SPEC-NF-01-09 | Ctrl+Shift+H: 全付箋を一括で隠す / 戻す | ||
8.2 マルチモニター・環境変動対応
表 8.2-1 マルチモニター・環境変動対応
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_NF_02 | 【要求】 外部ディスプレイの抜き差し等で、付箋が画面外に取り残されてしまう事故を防ぎたい。 【理由】 見えない場所に行った付箋を探すのは大きなストレスになるため。 | SPEC-NF-02-01 | 定期的または環境変化検知時に全付箋の座標を評価する。 |
| SPEC-NF-02-02 | 付箋がすべてのアクティブモニターの論理領域外に存在する場合、メインモニターの安全な領域へ自動再配置(レスキュー)する。 | ||
8.3 セキュリティ・プライバシー
表 8.3-1 セキュリティ・プライバシー
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_NF_03 | 【要求】 メモという極めてプライベートなデータを扱うため、情報漏洩や不正利用を防ぎたい。 【理由】 情報の安全性が担保されないツールは使用できないため。 | SPEC-NF-03-01 | PC アプリはローカル動作: PCアプリ単体では外部サーバーと通信しない。ファイルはユーザー指定の Vault 内にのみ保存する。 |
| SPEC-NF-03-02 | iPhone 連携時のデータ経路: 付箋データの中継はユーザー自身の Google Drive のみを使用する。第三者のサーバーに付箋の内容を送信しない。 | ||
| SPEC-NF-03-03 | Vercel の役割はシークレット保護のみ: Vercel は Google OAuth2 の client_secret を保護するためだけに存在し、付箋データは保持・参照しない。 | ||
| SPEC-NF-03-04 | ノー・テレメトリー: 開発者や第三者への利用状況送信・エラーレポートの自動送信は一切行わない。 | ||
8.4 パフォーマンス・リソース制約
表 8.4-1 パフォーマンス・リソース制約
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_NF_04 | 【要求】 常駐アプリであるため、作業の邪魔にならない程度の軽快さと低負荷を維持したい。 【理由】 メイン作業のパフォーマンスを落としてしまっては本末転倒なため。 | SPEC-NF-04-01 | 最大 500 枚程度の付箋が Vault 内に存在しても、高速な起動処理を意識した設計とする。 |
| SPEC-NF-04-02 | ファイル数増加に伴う線形的な負荷増加は、UI 描画の遅延評価(Lazy load)などで防ぐ。 | ||
8.5 多言語化・i18n 要件
表 8.5-1 多言語化・i18n 要件
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_NF_05 | 【要求】 環境に縛られず、様々な言語話者が直感的にツールを使用できること。 【理由】 より多くのユーザーに利用可能とするため。 | SPEC-NF-05-01 | 起動時に OS のロケール設定を自動取得し、UI 言語を決定する。 |
| SPEC-NF-05-02 | サポート言語は日本語(ja)および英語(en)を基本とする。設定画面からも強制切替可能。 | ||
| SPEC-NF-05-03 | コンテキストメニュー・ツールバーヒント・各種ボタンはすべて翻訳ファイルのキー(lib/i18n.ts)を通じた動的出力とする。 | ||
9 iPhone 連携要件
PCとiPhoneを繋ぐ双方向同期・通知・PWA機能を定義します。v2.10で追加。
9.1 PC → iPhone 送信(プッシュ通知)
表 9.1-1 PC → iPhone 送信(プッシュ通知)
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IP_01 | 【要求】 ユーザーは、PC で書いた付箋の内容をiPhone のロック画面通知として受け取りたい。 【理由】 移動中でも PC の重要メモを目に入る場所(ロック画面)に残しておけるようにするため。「そこに残る」という付箋の本質をモバイルでも実現する。 | SPEC-IP-01-01 | PC アプリの「iPhone に送る」ボタン押下で、Google Drive の notes_to_iphone.json に送信データを書き込む。 |
| SPEC-IP-01-02 | VAPID を使用した Web Push 通知を APNs/FCM 経由で iPhone に送信する。 | ||
| SPEC-IP-01-03 | Service Worker が Push を受信し、本文・画像(fusen_img_*)を Drive からダウンロードして IndexedDB(fusen-drafts)に保存する。 | ||
| SPEC-IP-01-04 | Drive に書き込んだ画像ファイルは、IndexedDB 保存完了後に即座に削除する(Drive は未処理キューであり、処理済みは残さない)。 | ||
| SPEC-IP-01-05 | iPhone のロック画面に通知として表示し、タップすると PWA の該当ノートへ遷移する。 | ||
9.2 iPhone → PC 送信
表 9.2-1 iPhone → PC 送信
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IP_02 | 【要求】 ユーザーは、外出先で iPhone に書いたメモを PC に戻ったとき付箋として受け取りたい。 【理由】 外出先のアイデアをデスクトップに自動で届けることで、「転記」の手間をなくすため。 | SPEC-IP-02-01 | iPhone PWA の write 画面で「PC に送る」を押すと、テキストと画像を Google Drive に送信する(notes_from_iphone.json + fusen_img_*)。 |
| SPEC-IP-02-02 | PC アプリが 30 秒ポーリングで Drive を監視し、受信後に付箋として新規ウィンドウを開く。 | ||
| SPEC-IP-02-03 | PC 受信後、Drive 上の JSON から処理済みアイテムを除外して書き戻す(空になったらファイルごと削除)。 | ||
| SPEC-IP-02-04 | PC 受信後、Drive 上の画像ファイルは即座に削除する。 | ||
9.3 通知の常駐(ロックだぜ)
表 9.3-1 通知の常駐(ロックだぜ)
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IP_03 | 【要求】 ユーザーは、重要な通知を意図的に消すまでiPhone のロック画面に表示し続けたい。 【理由】 紙の付箋のように「消す意思がないかぎり目に入る場所にある」体験をモバイルでも実現するため。 | SPEC-IP-03-01 | list 画面の 🔔 ボタンで通知常駐(locked: true)を ON/OFF できる。 |
| SPEC-IP-03-02 | locked: true のノートは notificationclick 時に通知を再表示する(自動再通知)。 | ||
| SPEC-IP-03-03 | locked フラグは IndexedDB(fusen-drafts)の boolean フィールドで管理する。 | ||
9.4 iPhoneロック画面常駐体験
表 9.4-1 iPhoneロック画面常駐体験
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IP_05 | 【要求】 ユーザーは、PC で送った付箋が iPhone のロック画面に「消す意思がないかぎり」ずっと残り続け、タップすれば内容を確認でき、確認後もロック画面から消えないという体験を得たい。 【理由】 紙の付箋は「剥がすまで目に入る場所にある」。この体験を iPhone のロック画面で再現することで、「そこに残る」というプロダクトの本質をモバイルでも実現する。 | SPEC-IP-05-01 | ① PC から送信すると、iPhone のロック画面に通知が表示され、ポップアップが出る。このとき通知常駐(🔔)は ON のまま。 |
| SPEC-IP-05-02 | ② ポップアップをタップすると PWA が開き付箋の内容が表示される。表示後、通知を再表示してロック画面から消えない状態を維持する。 | ||
| SPEC-IP-05-03 | ③ ①② のサイクルは、ユーザーが明示的に通知を OFF にするまで繰り返す。 | ||
| SPEC-IP-05-04 | ④ ユーザーが list 画面の 🔔 ボタンで通知を OFF にすると、ロック画面からも通知が消え、以降ポップアップもしない。 | ||
9.5 iPhone PWA の認証と持続可能性
表 9.5-1 iPhone PWA の認証と持続可能性
| 要求(Requirement) | 仕様(Specification) | ||
|---|---|---|---|
| ID | 要求事項・理由 | ID | 仕様・制約 |
| REQ_IP_04 | 【要求】 ユーザーは、複雑な手順なしに iPhone PWA にログインでき、セッションが途切れても自動で再接続されたい。 【理由】 モバイルでの再ログイン手順が複雑だと、機能そのものが使われなくなるため。また Vercel 無料枠・Google API 制限の範囲内で運用を続けられる設計が必要。 | SPEC-IP-04-01 | Google OAuth2 PKCE フローでログインする。client_secret は Vercel API Routes で保護し、iPhone 側には渡さない。 |
| SPEC-IP-04-02 | アクセストークンの有効期限切れを検知した場合、Vercel 経由で自動リフレッシュしてから処理を続行する。 | ||
| SPEC-IP-04-03 | Vercel は無料枠、Google API は標準クォータの範囲内で運用できる設計とする(ポーリング頻度・Drive アクセス回数を意識する)。 | ||
10 改版履歴
表 10-1 改版履歴
| No | バージョン | 日付 | 変更内容 |
|---|---|---|---|
| 1 | v2.11 | 26-04-20 | REQ_IP_05「iPhoneロック画面常駐体験」追加 |
| 2 | v2.10 | 26-04-19 | HTML化・iPhone連携要件追加・ショートカット更新等 |
| 3 | v2.0 | 26-02-22 | ベータリリース時の初版(Markdown形式) |