Products Specs — Requirements
Round 1 を勝ち抜いた25案の要件定義書。各要件書は Round 1 の審査講評（懸念）への対応を必須セクションとして含み、Round 2 はこの要件書の質まで判定材料にして戦った。タップで展開。
主ペルソナ1: 子育て世帯の30-40代夫婦。学校行事の申込期限・病院の受診方針・大型出費の合意など、週に複数回「どうなった?」「いつ決めた?」のやりとりが発生する。LINE履歴を遡っても埋もれていて見つからない経験を繰り返している。主ペルソナ2: 親子同居・兄弟姉妹同居など2-4人が生活上の決定事項を共有する家庭。口頭合意が後になってトラブルになりやすく、「ちゃんと言ったのに」という摩擦が定期的に起きている。いずれも既にLINEグループを持っており、新しいアプリを入れる手間を嫌う層。
「学校のプール開放、申し込んだよね?」「え、誰が申し込むか決めてたっけ」——こういう会話が週に何度も発生する。LINEで話した内容はトーク履歴の奥に埋まり、Googleカレンダーは日時が決まっているイベントには強いが「どちらが担当するか」「いくらまで出す合意をしたか」という意思決定そのものは記録できない。メモアプリに書いても誰かが書いたことを誰かが知らない問題が残る。
LINE Messaging API (Webhook) + LIFF / バックエンド: Node.js (Hono) on Cloud Run または Render / DB: Firebase Firestore（無料枠でMVP完走可能） / 決済: Stripe Checkout リンク（月額課金）/ インフラ費用: 月額ほぼ0円（Firestore + Cloud Run 無料枠内を想定）
freemium + 家族月額 / 無料プラン: 1グループ・台帳50件まで / 家族プラン: 月額480円（税込）・台帳無制限・月次サマリ通知・LIFF台帳ビュー
審査員3名とも月300円に異論はなかったが、Stripeの決済手数料（3.6%+固定）と月2h保守コストを考慮すると300円は損益分岐が遅い。480円はスーパーマリオRun等の家族アプリの実績ラインであり、「トラブル防止ツール」としての支払い意思として許容される上限に近い。無料枠50件は数ヶ月の通常使用で上限に達する設計とし、アップグレード動機を自然に作る。
Firestore読み書きとLINE Webhook受信のみで外部データ依存がなく、APIが変わる箇所はLINE Messaging APIの仕様変更のみ。月次タスクは「LINE APIのchangelogを5分確認」「Stripeの課金ステータス確認」「Firestoreの使用量チェック」の3点で合計30分以内。CI/CDをGitHub Actionsで自動化するため手動デプロイは不要。月2h以内に収まる根拠として、ユーザー起点のタグ設計であるため「タグ辞書の更新」「外部データの同期」が発生しない構造を採用している。
審査員3名が共通して指摘した「Notionの家族版・共有メモで代替される懸念」に対し、コトログの差別化軸を「LINEトーク内で会話の流れのまま記録・検索が完結する」点に明確に絞る。ユーザーが別アプリを開かなくても「#タグ + 一文」でBotに送るだけで台帳化される設計は、Notionや共有メモアプリが構造上持てない「摩擦ゼロの記録導線」であり、これを要件の中心に据えた。審査員Mが言及した「LINEカレンダーとは解決対象が異なる」という分析を支持し、スコープをカレンダー・スケジュール領域から意図的に切り離すことで差別化を構造的に担保する。審査員Uが懸念した「タグ設計をユーザーに委ねる」点はむしろ外部依存をゼロにする保守上の強みとして位置付け、LLM分類を非スコープに明示することで制約条件との整合も取っている。審査員Bが「月300円の支払い意思はトラブル防止ツールとして説明可能」と評価した点を受け、価格を480円に引き上げて持続可能性と説明のしやすさを両立させた。
獲得スキル: LINE Messaging API + LIFF + Firestore + Stripe Checkout の4点セット実装経験（LINEミニアプリ系SaaSの標準スタック）
主ペルソナ1: 30代の自炊する共働き夫婦の一方（妻または夫）。週3〜4回自炊し、週末にまとめて冷凍ストックを作る習慣がある。冷凍庫の奥に何があるか把握できておらず、同じ食材を重複購入したことが複数回ある。食品ロスに罪悪感があり500円程度なら払う。主ペルソナ2: 一人暮らしの20代後半〜30代社会人。自炊頻度は週2〜3回。節約のために食材を冷凍保存するが、「入れたことを忘れる」「期限を過ぎた冷凍食材を発見する」を月1〜2回経験している。料理系インスタ・クラシルをフォローしている。
夕飯の準備で冷凍庫を開けるたびに、奥の段に何が入っているか思い出せず、結局手前のものだけ使い続ける。数週間後に奥から霜だらけの肉や魚を発見して捨てることになり、「また食品ロスしてしまった」という罪悪感が残る。バーコードスキャン系アプリを入れたこともあるが、毎回スキャンする手間が続かずやめた。
媒体: iPhone アプリ（iOS 16以上）。技術スタック: Swift / SwiftUI + SwiftData（ローカルDB）+ WidgetKit（ホーム画面ウィジェット）。外部API依存ゼロ。バックアップはiCloud Documents経由で自動化。配布はApp Store。
買い切り / 480円（税込）
審査員Mの指摘「500円を支払わせる差別化軸として体験が弱い」への対応として、App Storeの心理的な買い切り許容ゾーン（480〜600円帯）の下限に設定し購入障壁を下げる。サブスクは継続課金の罪悪感から削除を誘発しやすく、食材管理という日常ツールには不向き。無料トライアル（3件まで登録可）を設けることで、段マップUIの体験を先に届けてから購入判断させる設計にする。
月次タスクはApp Storeレビュー確認（約30分）とiOS新バージョンでのUIクラッシュ確認（約30分）の合計約1時間を想定。外部API・データベース依存がゼロのため、サーバー障害・API仕様変更・データ更新作業は発生しない。SwiftDataはApple公式フレームワークであり、iOSアップデートに伴う破壊的変更のリスクがCoreDataより小さい設計になっている。月2h以内に収まる根拠は「外部依存ゼロ＋ローカルDB＋Apple標準フレームワーク限定」の構成による。
審査員Mの最大懸念「段ごとのビジュアルマップは体験として弱い——冷凍庫を開ければわかる」に対して、本要件書は「冷凍庫を開けても奥の段が見えない・覚えていられない」という物理的制約を前提に据える。冷凍庫の引き出し奥段は実際には確認のたびに屈んで引き出す必要があり、アプリは「開けずに今何があるかを把握できる」価値を提供する。審査員M・Bが共通して指摘した「入力コストが継続の障壁」への対応として、バーコードスキャン・写真撮影を完全に排除し、タップ→テキスト入力2ステップ＋自動日付付与のみに絞り、競合より明示的に入力コストを下げる設計とした。価格は500円から480円に引き下げ、かつ無料トライアル（3件登録）でUIの体験価値を先に届けてから購入判断させることで「差別化軸が弱い段階での500円の壁」を構造的に解消する。配布チャネルは審査員U・Bが評価した「料理系インスタ・節約系コミュニティ」への短尺動画アプローチを具体化し、TDIL発信軸Aのnote記事と掛け合わせることで検索に依存しない二重の導線を設計した。
獲得スキル: SwiftUI + SwiftData + WidgetKit の三点セットによるiOSローカルアプリ開発の実践スキルと、App Storeリリース〜マーケティング導線設計の一気通貫の経験。
主ペルソナ1: 30代前半の会社員・道具好き。包丁・革靴・自転車など「長く使うもの」を意識的に揃えているが、手入れのタイミングは感覚任せで「気づいたらひび割れていた」「砥石を買ったまま1年放置」という後悔を繰り返す。Notionに管理表を作ろうとしたことがあるが続かなかった。主ペルソナ2: 40代の自転車通勤者・料理好き。道具の性能劣化には敏感で「もっと早く研いでおけば」という体験を言語化できる。コミュニティ（自転車・料理・革製品）に属しており、良いと思ったアプリは仲間にすすめる口コミ源になる。
包丁を久しぶりに使ったら刃が鈍り切っていて食材がつぶれた、革靴を履こうとしたら甲にひび割れが入っていた——どちらも「気づいたときには劣化済み」という後悔体験。手入れを忘れること自体が問題ではなく、「次の手入れがいつか」を考える仕組みがないことが根本原因。リマインダーアプリで代替しようとしても「推奨周期を自分で調べて設定する」手間が壁になり結局続かない。
媒体: iPhone（iOS 16以上）ネイティブアプリ + ホーム画面ウィジェット（WidgetKit）。技術スタック: Swift / SwiftUI / WidgetKit / UserNotifications / SwiftData（ローカルDB）。外部依存ゼロのオフライン完結設計。App Store配布（買い切り）。
買い切り / ¥250（App Store Tier 1）
審査員Uの指摘「500円を払う動機となる即時性がない」を正面から受け入れ価格を下げる。潜在型の痛みに対しては購入摩擦の低減が有効で、¥250は「迷わず試す」ラインに収まる。保守コストが構造的にほぼゼロ（外部API不依存・ローカルデータ完結）のためランニング損失が生じない設計と相性が良く、低単価でも損益分岐が成立する。スキル獲得目的（SwiftUI/WidgetKit習得）を主軸に置けば、収益よりも配布実績とコミュニティでの口コミ拡散を優先できる。
月次タスクは「プリセット道具テーブルの内容確認（新しい道具カテゴリの追加要望があればプリセット拡充）」のみ。外部APIが存在しないため障害監視・キー管理・料金超過確認が一切不要。iOSアップデート対応は年1〜2回のSwiftUI軽微修正で収まり、月換算30分以下。App Storeレビュー確認・クラッシュログ確認（Xcode Organizer）を含めても月計2時間以内に確実に収まる。
審査員Uの「即時性がなく500円の動機が弱い」という核心指摘に対しては価格を¥250に引き下げることで購入摩擦を最小化し、「迷わず試してみる」水準まで下げる。痛みが潜在型（気づいたら劣化済み）であることは認めた上で、それを補うのが「推奨周期プリセット付きのゼロ設定体験」と「ウィジェット常時可視化による思い出させる仕組み」であることをMVP設計に落とし込んだ。審査員Mの「直接競合が見当たらない・推奨周期を知っているのが差別化」という評価を軸に、プリセット20種と根拠メモをMustフィーチャーとして明示している。審査員Bの「外部API不依存で保守コストが構造的に低い」という指摘は設計の根拠として完全に採用し、ローカル完結・オフライン動作・SwiftDataのみの構成でこれを担保する。「Notionで代替できる」という指摘に対しては、ウィジェット常時可視化＋1タップ記録＋プリセット周期の三点セットが代替不可の体験差であることを競合ギャップとして明示した。
獲得スキル: SwiftUI + WidgetKit + SwiftData によるiOSネイティブアプリ開発の一気通貫実装経験（ローカルDB設計・ウィジェット更新ロジック・ローカル通知）
メインペルソナは保育園〜小学校低学年の子を持つ30代母親。毎月作品が持ち帰られるたびに「捨てられない・でも積み上がる」を繰り返しており、Googleフォトに撮っても学年・年度の軸で出てこないことへの不満を抱えている。サブペルソナは祖父母に孫の成長を見せたい父親で、卒園・卒業のタイミングに形として残るものを贈りたいと考えている。
保育園から毎月絵や工作が持ち帰られるが、押し入れに積み上げるか捨てるかの二択に追い込まれる。Googleフォトに撮っても「学年3年生」「2024年度」という軸で一覧できず、年度末に振り返ろうとしても探し出せない。MUSEUMで写真は撮っているが、年度ごとに「この1年の作品まとめ」としてフォトブック注文できる動線が直感的でなく、毎年の記念として形にできていない。
媒体: iPhone専用ネイティブアプリ（SwiftUI）。技術スタック: SwiftUI + Core Data（ローカル永続化）+ CloudKit（iCloud同期・家族共有）+ Vision framework（台形補正・OCR不使用）。フォトブック注文はしまうまプリントのWebURLへのDeepLink誘導のみ、印刷API契約なし。CI/CD: Xcode Cloud。配布: App Store 買い切り980円（後述）。
買い切り + 印刷実費（外部業者） / App Store 価格: 980円（税込）
審査員講評の「800円」から980円に上方修正。理由: MUSEUMが無料+フォトブック収益モデルで参入済みのため、無料競合に対して『アプリ本体に課金する価値』を明示する必要がある。980円は『フォトブック1冊の送料以下』という比較感を持ち、買い切りによる「解約不安ゼロ」が子育て世代の追加購入疲れに刺さる。印刷実費はしまうまプリント等の外部負担のため、アプリ側の収益は純粋に買い切り代のみで保守コストが低い。
月次タスク: CloudKitのストレージ使用状況確認（5分）、App Store Connectのクラッシュレポート確認（10分）、しまうまプリントのDeepLink URL疎通確認（5分）の計20分以内が定常。外部依存はCloudKit（Apple管理・APIなし）としまうまプリントのWebURL（API契約なし、URLが変わった場合のみアプリ更新が必要）の2点のみ。印刷API直接連携を持たないため、外部業者の仕様変更による緊急対応は発生しない。月2h以内の根拠: 外部API依存ゼロで、年1〜2回のOSアップデート対応以外に定常保守タスクがない。
審査員3名が共通して指摘した「MUSEUM（直接競合）が強敵」という懸念に対して、差別化軸を『学年×年度』という教育制度の時間軸に特化することで答える。MUSEUMの整理軸は「作成月」であり、小学校入学・卒園という節目を中心に据えた『2024年度 年長さんの作品集』という体験設計がない。この隙間に「年度末フォトブックへの収束動線をアプリ内で完結させる」という設計で差を作る。審査員Uが指摘した「印刷連携APIリスク」は、App内ではZIPエクスポートまでで完結させ、印刷サービスへはDeepLink誘導のみとすることで外部API依存ゼロを達成し、月2h保守制約を構造的に守る。審査員Bが挙げた「800円買い切り以上のLTV」という収益モデルの可能性は、価格を980円に見直しつつ、印刷実費は外部業者負担という分担で実現する。
獲得スキル: SwiftUI + CloudKitによるiOSネイティブ開発（Core Data連携・iCloud同期）と、Vision frameworkを使った画像前処理パイプラインの実装経験
主ペルソナ: 40〜50代の働くきょうだい（長男または長女）。実家から車で1〜2時間圏内に住み、親の通院付き添いや服薬管理を兄弟と分担している。LINEグループで「今日お母さん診察行ってきたよ」と送っても既読確認もなく流れてしまい、次回誰が何を把握しているか毎回確認し直す手間に疲弊している。サブペルソナ: 遠方在住の次男・次女。現地に行けない分「状況を把握できていない罪悪感」を持ちながらも、LINEに質問を重ねることをためらっている。月300〜500円の支払いには抵抗が少ないが、アプリを家族全員に導入させる心理的ハードルは高い。
長男が母を内科に連れて行き「血圧が少し高め、次回3週間後に再診、降圧剤が変わった」という情報をLINEに投稿したが、2日後には他の会話に埋もれ、次の受診当日に妹が「どの薬に変わったんだっけ」「次は誰が連れていくんだっけ」と改めて聞き直すところから始まる。毎月1〜2回この「情報リセット」が発生し、役割分担の確認と情報の掘り起こしで15〜20分が消える。LINEでは「既読」が誰が読んだかまで可視化できず、兄が本当に把握しているのかどうかが分からないまま当日を迎える不安が残る。
媒体: iPhone ネイティブアプリ（iOS 17+）/ 技術スタック: Swift + SwiftUI、CloudKit（iCloudによるデータ同期・サーバーレス）、StoreKit 2（月額課金）、EventKit（カレンダー連携）。バックエンドサーバーレスのためインフラ保守ゼロ。Apple Developerアカウント年額$99のみの固定費。
月額サブスクリプション（家族グループ単位・最大6名） / 月500円（年払い4,800円）
審査員Mの指摘「競合おやろぐが月500〜600円で総合介護管理を提供」を受け、300円では機能格差に対する割安感が逆に「大丈夫なのか」という不安を生む可能性がある。きょうだい申し送り特化の軽量ツールとして、おやろぐの簡易版ポジションで同価格帯に設定。年払いは20%割引で継続意欲を促進。初月無料で家族全員の招待完了までを無料期間内に体験させ、LTV向上を図る。
月次タスク: CloudKitのストレージ使用量確認（Appleダッシュボード、5分）、StoreKit 2のサブスクリプション状態モニタリング（収益レポート確認、10分）、クラッシュレポート確認（Xcode Organizer、15分）、ユーザーからのApp Storeレビュー返信（月5件想定、30分）。外部依存はCloudKit（Apple管理）とStoreKit 2（Apple管理）のみで自前サーバーゼロ。障害発生時はApple側の問題であり個別対応は不要。合計月60分以内で月2h制約に対し余裕あり。
審査員Uの「リアルタイム同期にはサーバーが必要で月2h保守制約と相性が悪い」という指摘に対しては、バックエンドをCloudKit（Apple管理のiCloud）で完結させることでインフラ保守ゼロを実現する。自前サーバーを持たないためCloudKitの可用性はAppleに委任され、障害対応も不要。審査員Uの「検索なしで届ける具体経路が構造的に見つかりにくい」という最大の懸念については、Apple Family Sharingの招待フロー自体を口コミ起点に設計する（招待URLがメッセージアプリを経由することで自然にアプリ名が伝播する）ことと、ケアマネ・地域包括支援センターへのリーフレット配布という非デジタル経路を組み合わせて対応する。審査員Mの「競合の隙間は小さい」という指摘については、おやろぐが「総合介護管理」を目指す中でみまもりノートは「きょうだい間の申し送りと既読確認」という単一のジョブに絞ることで、機能的差別化と学習コスト最小化を同時に達成する。価格は審査員講評を受けておやろぐと同価格帯の月500円に修正し、割安すぎる不信感を排除した。
獲得スキル: CloudKit + SwiftUI によるサーバーレスiOSアプリ開発、StoreKit 2 Family Sharing対応の課金実装、Apple Family Sharingを活用したグループ招待UXの設計
主ペルソナ1: 30〜40代の共働き世帯。家電・日用品・育児用品を年間30〜80万円規模でEC購入しており、Amazonを起点に楽天・ヨドバシ・Yahoo!ショッピングを複数タブで開いて目視比較する習慣がある。週1〜2回は「これ本当に安いのか？」と感じながら購入を決めている層。主ペルソナ2: ポイ活・節約系のX/Instagramアカウントをフォローしており、価格.comや比較サイトを使い慣れている30代前後の個人。スポンサー枠を「広告」と認識していて意識的に避けようとするが、手間がかかって結局スポンサー枠から買ってしまった経験がある。
Amazonで掃除機を検索すると上位10件のうち7件がスポンサー枠で、どれがオーガニック評価なのか判断できない。信頼できる結果を見つけるために楽天・Yahoo!・ヨドバシを別タブで開くが、タブが5枚になった時点で比較情報が頭の中にしか存在せず、タブを閉じると全部消える。この「スポンサーへの不信」と「比較の揮発性」が週1〜2回のペースで慢性的に発生している。
Chrome拡張（Manifest V3）。フロントエンド完結のバニラJS + Chrome Storage API + Chrome Side Panel API。外部サーバー不要（種あり連動のJSONのみGitHub Pages等で静的配信）。課金はChrome Web Store組み込みのIn-App Purchasesを使い、決済インフラをゼロ実装で調達する。
フリーミアム + 月額サブスク / 無料プラン: スポンサー除去 + ピック最大5件 + セッション保存5件。有料プラン: 月額380円（ピック・セッション無制限 + 種あり連動 + シェア機能）
審査員Uの「1回の比較ミス購入を防ぐ保険」論拠は維持しつつ、審査員Mが指摘した『月580円を払う正当化根拠が成立しない』懸念に対応するため価格を引き下げた。380円は月1本のコーヒー代以下であり、週1〜2回の比較体験を改善する価値に対して心理的ハードルが低い。競合のショッピングリサーチャー（月3,980円）はせどり事業者向けであり一般消費者は比較対象にしない。無料プランでスポンサー除去を体験させ、比較セッションの保存上限に当たったときに有料転換を促す導線設計。Chrome Web Store In-App Purchasesで決済実装コストをゼロにする。
月次保守タスク: ECサイトのDOM変更検知（週1回、各サイトでスポンサー除去が動作するか目視確認、5分×4回=20分）、breakageがあればセレクター修正（月0〜1回、30〜60分）、種あり連動JSONの更新（記事公開時のみ、10分）。合計月最大90分以内。外部依存はECサイトのDOM構造のみで、APIキーなし・サーバーなし・データベースなし。DOM変更は4サイト分が集中管理でき、広範囲な依存（天気API・行政データ等）を持たないため月2h上限を構造的に守れる。
審査員Mの最大の懸念「ショッピングリサーチャーが同じ痛みを解消している」に対して: ショッピングリサーチャーはせどり事業者が仕入れ価格をリサーチするツールであり、一般消費者向けの横断ピック・比較保存機能を持たない。実際のChrome Web Store説明文・対象ユーザー層を確認すると「転売目的のリサーチ支援」が主軸で、一般購買者の比較揮発性問題は解決しない。価格580円への懸念については月額を380円に引き下げ、かつ無料プランでスポンサー除去という核心価値を体験させてから有料転換する設計に変更した。審査員BのDOM変更パッチコスト懸念については、4サイト分のセレクター管理を一元集中し、月次目視確認フローを設計することで月最大90分以内に収まることを根拠とともに明示した。審査員Uの「比較しないユーザー層への訴求の弱さ」については、無料プランのスポンサー除去機能を入口にして「気づいたら比較保存まで使っていた」という段階的価値体験の設計で対応する。
獲得スキル: Chrome拡張開発（Manifest V3 / Content Scripts / Side Panel API / In-App Purchase）の実装経験と、ECサイトDOM差分追跡の保守オペレーション知見
主ペルソナ: 20〜40代女性、夫婦または子育て世帯、毎月初に現金を封筒に振り分けて「食費・日用品・外食・医療費・交際費」等を管理している。銀行口座はあるがキャッシュレス化は不完全で、日常支出の一部または全部を現金で運用。封筒が底をついたとき「別封筒から融通する」行為を電卓とメモでその場しのぎしており、月末に合わない残高と向き合うのが地味なストレス。サブペルソナ: 節約に取り組み始めた20代独身女性。袋分けを試みたいが物理封筒の管理が煩雑で続かず、スマホで完結させたい。
毎月中旬、食費封筒が残り1,000円になったとき「雑費封筒から500円移す」という操作が発生する。紙に書き直すか、電卓で計算し直すか、頭の中でだけ覚えておくかの3択しかなく、月末に残高が合わなくなる。「アプリに封筒間移動の概念そのものがない」ことが根本の痛みで、ZaimやマネーフォワードはそもそもこのUXを提供していない。
iOS / SwiftUI + Swift Data（ローカル永続化）+ CloudKit（iCloud同期）。外部APIゼロ・LLM機能なし。単一ターゲットのネイティブアプリ。配布はApp Store買い切りのみ。
買い切り（one-time purchase） / 480円
審査員3名全員が「700円では課金動機が弱い」と指摘。家計管理アプリの買い切り相場（300〜500円帯）に合わせ480円に引き下げる。封筒間移動という実務的な差別化機能1点で480円は正当化できる。節約文脈のユーザーは出費に敏感なため、500円未満の心理的ハードルを意識した設定。無料版はなしとし、試用へのニーズはスクリーンショット・レビューで対応する。
月次タスクは実質ゼロ。外部API依存がなく、CloudKitはAppleが管理するため障害対応不要。iOS新バージョンリリース（年1回9月）に合わせたSwiftUI互換確認が最大の作業で、年1〜2時間で完結する見込み。月2h上限は外部依存ゼロの設計により構造的に保証される。
審査員M・Bが指摘した「既存競合との外観差別化・封筒間移動の実装済み可能性」については、実際に競合2アプリを調査した結果、「袋分け家計簿（id1662950656）」「袋分家計簿（Funeasy Soft）」ともに封筒間移動・振替機能の実装が確認されておらず、残高可視化と支出記録にとどまっていた。本アプリはこの「封筒間移動ログ付き振替」を中核機能として設計することで競合との機能的差別化を明確にする。審査員Bが指摘した「現金管理者が有料課金するか不確実」という行動パターンの懸念に対しては、価格を700円から480円（500円未満）に引き下げることで節約志向ユーザーの心理的ハードルを下げ、かつInstagram・節約ブロガー経由の口コミ先行で「使って納得してから広める」信頼構造を構築する。審査員Mの「乗り換えコストが高い」指摘に対しては、既存アプリからのデータ移行は設計しない代わりに、初回セットアップを封筒テンプレート＋予算入力のみ5分以内で完了させ「新規に始める」ハードルを下げることで対応する。
獲得スキル: SwiftUI + Swift Data + CloudKit によるオフラインファーストiOSアプリのフルスタック実装経験、およびApp Store申請・審査フローの習得
主ペルソナは20〜30代の賃貸入居者で、引越し直後に「退去時の敷金トラブルが怖い」と感じた瞬間に購入する層。スマートフォンはiPhoneに慣れているが、写真整理やPDF作成を自力でこなすほどリテラシーは高くない。第二ペルソナは賃貸経験が2回以上ある30〜40代で、過去に敷金を引かれた実体験か知人からのトラブル話を持ち、次の引越しで「最初から記録しておく」動機が明確にある層。
入居当日、部屋の隅の傷やクロスの汚れをスマホで撮影するが、写真フォルダに「部屋の写真」として埋もれてしまい部屋ごとの整理ができていない。退去立会い時に「この傷は入居前からありました」と主張しても、撮影日時の証明ができず管理会社に反論できない。結果として数万円〜十数万円規模の修繕費を請求され、敷金がほぼ戻らない。
プラットフォーム: iOS(iPhone)ネイティブ / SwiftUI + SwiftData(ローカルDB) + PDFKit(PDF生成) + PhotosUI(カメラ・フォトライブラリ)。外部API・バックエンド・サーバーなし。TestFlightでβ配布 → App Store買い切り配信。
買い切り（Paid App） / 600円
Round 1 講評は500円前提で「即決レベル」と評価しており支払い意思は十分。App Store最低価格帯の600円（Tier 1）に揃えることで端数感をなくし、ストア内で見劣りしない価格帯に統一する。敷金数万〜十数万円の損失回避対比では600円も即決領域に変わりなく、ROI訴求が成立する。サブスク・広告なし。
月次保守タスクはiOS新バージョンリリース後のビルド確認（PDFKit / PhotosUIのAPIデグレチェック）と、App Storeレビューへの返信のみ。外部API・データ更新・サーバー監視がゼロのためダウン対応は存在しない。実作業は年2回のiOSメジャー対応（各30〜60分）と月次レビュー確認（15分程度）に収まり、月平均1h未満で月2h枠に十分収まる根拠がある。
3審査員とも「標準カメラ＋フォルダ管理が競合」と指摘したが、その弱点は証拠文脈の欠如にある。本アプリはExif日時の重畳表示・部屋ごとの整理・PDFKit出力・ShareSheetでの即時送付を一連のフローとして提供し、「退去立会い当日に管理会社へ送れる証拠書類」というアウトプットで差別化する。審査員Bが懸念した「iOS API変更リスク」については外部APIゼロ・PDFKit/PhotosUIはApple標準フレームワーク（廃止リスク最小）で対応し、保守を年2回のビルド確認に封じ込める。審査員M指摘の「競合アプリが見当たらない」状態は2026年6月の検索でも継続して確認されており、住むサポ（管理会社向け）・STYLE〜敷金〜（金融サービス）はいずれも代替にならない。審査員Uが評価した「痛みの非対称性」をROI訴求コピー（「600円で敷金数万円を守る」）としてApp Store説明文と配布SNS投稿に明示することで、価格障壁を実質ゼロにする。
獲得スキル: SwiftUI + SwiftData + PDFKit によるiOSローカルファーストアプリの設計・App Store申請・ASO最適化の実務経験
主ペルソナは50〜65歳の喪主・施主（故人の配偶者または長子）。親や配偶者の他界直後、葬儀社から「四十九日は〇月〇日頃です」と口頭で言われるが、繰り上げの可否・一周忌以降の年忌スケジュール・参列者への案内状の準備を自力でこなさなければならない。PCよりスマホ操作に慣れ、Wordは使えるが凝った書式設定は苦手。副ペルソナは葬儀社・寺院の担当者（50代）。喪家に配るQRシートや口頭で「こちらで計算できます」と案内できるツールを探している。
命日翌日、喪主は四十九日・百か日・一周忌・三回忌の日程を確定してお寺と日程調整し、参列者へ案内状を郵送しなければならない。keisan.site は計算結果を数字で返すだけで「仏滅・友引を避けて繰り上げた最寄り日」まで提示しない。案内状のWordテンプレートは別サイトから拾うが縦書き書式の調整で30分以上かかる。印刷屋に頼むと数千円かかる。計算→繰り上げ判断→案内状作成という3ステップが別々のツールに散らばっており、悲しみと時間的プレッシャーの中で一気に片付けられない。
媒体: Webアプリ（モバイルファースト、PWA対応）。技術スタック: Next.js（App Router）+ Tailwind CSS、PDF生成は @react-pdf/renderer（サーバーサイドレンダリング）、六曜・繰り上げロジックはピュアTypeScriptで完結（外部API依存ゼロ）、決済はStripe Checkout（ワンタイムリンク）、ホスティングはVercel無料枠。データベース不使用・サーバーレス構成で月次保守コストを最小化。
フリーミアム買い切り / 基本計算・スケジュール共有・無料PDF：無料 / 縦書き案内状PDF：300円（1法要につき1回のワンタイム決済）
審査員Uが指摘した「悲しみの渦中に課金UI」という体験摩擦を最小化するため、課金タイミングを『日程計算完了後・案内状印刷の直前』に限定する。300円は印刷屋（最低2,000〜3,000円）との比較対象で支払い根拠が明確。無料PDFのスケジュール表を先に価値提供することで、有料PDFへの心理的ハードルを下げる。審査員Mが評価した「印刷屋より安い比較対象」を維持しつつ、審査員Uの懸念に正面から対処する設計。
月次保守タスクは「Vercelデプロイログ確認（5分）」「Stripe決済ログ確認（5分）」「六曜データの年次先読み追加（翌々年分を毎年1月に追加、30分）」の3点のみ。外部API依存ゼロ・データベースなし・認証なしの構成のため、ライブラリのセキュリティアップデートも月1回npm audit + 自動PRで完結し、月2h以内に確実に収まる。宗派ルール（繰り上げ曜日・地域慣習）の変動は制度レベルでほぼ起こらず、コードロジックは初期実装後に触れない前提が成立する。
審査員Uが指摘した「自分で計算する場面が実は少ない」という懸念に対し、計算の主ユースケースを「四十九日の確認」ではなく「一周忌以降の年忌スケジュール確定と参列者への案内状作成」に明確化する。葬儀社が口頭で案内する四十九日と異なり、一周忌・三回忌・七回忌の日取り決定は喪主が自力で行う場面であり、複数回発生する需要を捉えられる。同じく指摘された「悲しみの渦中に課金UI」という体験摩擦は、課金タイミングを『日程計算完了・案内状フォーム記入後の最終ステップ』に限定することで対処し、計算と共有URLは完全無料で提供することで入口のハードルをゼロにする。審査員Mが評価した「印刷屋より安い比較文脈での300円」は維持し、無料のスケジュール表PDFを先行提供することで価値の先渡しを行ってから有料案内状へ誘導する動線を設計する。審査員Bが評価した葬儀社・寺院QRコード経路は、ツール内からQR入り紹介シートを生成できる機能としてMVPに組み込み、検索依存を構造的に排除する。
獲得スキル: Next.js App Router + @react-pdf/renderer によるサーバーサイドPDF生成、Stripe Checkout ワンタイム決済フロー、六曜アルゴリズムのTypeScript実装
主ペルソナ: フリーランス・個人事業主で税理士に帳簿を丸投げしているが、「領収書の写真を月ごとに束ねて渡す」作業だけが毎年の地獄になっている層。確定申告シーズン直前に「あの領収書どこだっけ」と4〜5時間消える体験を持つ。30〜45歳・iPhoneユーザー・会計ソフトを入れるほどではないが税務をおろそかにはできないと感じている。副ペルソナ: 個人事業主を複数クライアントに持つ税理士・記帳代行スタッフ。クライアントが送ってくるバラバラの写真をリネームして月別フォルダに整理する作業が月末に重なり、「最初から整理して送ってほしい」と感じている。
確定申告1〜2週間前、財布・引き出し・スマホのカメラロールに散らばった領収書を発掘し、月ごとに仕分けして税理士に渡せる形にまとめる作業に半日が消える。税理士に「ファイル名・月別フォルダ・金額CSVでください」と言われても何をどう準備すればいいか分からず、結局LINEで写真を大量送信して「あとはお任せします」になる。この非効率が税理士費用に転嫁されていると薄々わかっていても、会計ソフトを月1,000円以上払って契約するほどの取引量でもないと感じている。
媒体: iOS (Swift / SwiftUI) ネイティブアプリ + Firebase (Authentication / Firestore / Storage / Functions)。技術スタック: SwiftUI + Vision Framework (OS標準OCR)、Firebase SDK for iOS、Cloud Functions (TypeScript) でZIP生成・CSV書き出し・署名付きURL発行、Firebase App Distribution でベータ配布、App Store Connect で本番配布。
月額サブスクリプション（App Store In-App Purchase） / 月400円（税込）/ 年払い3,600円（25%引き相当）。7日間無料トライアル付き
審査員講評を踏まえ変更なし。freeeスターター月980円・マネーフォワードクラウド確定申告パーソナルミニ月900円（いずれも2026年5月時点）と比べ半額以下で、会計ソフト全体を契約せず『写真整理と書き出しだけ』したい層に対して支払い抵抗が低い。年払いオプションで税理士に渡す直前（確定申告期）の解約離脱を防ぐ設計。ユーザー1人あたりのFirebaseコストは月100〜200円見込みで40〜50円のマージンは確保できる（年払いユーザーは黒字が安定）。
月次保守タスク: Firebase Storageの使用量確認・コストアラート設定確認（15分）、App Store Connect のクラッシュレポート確認（15分）、iOSベータ版リリース時のVision Frameworkの動作確認（30分）。外部依存は Firebase SDK・App Store In-App Purchase・iOS Vision Frameworkの3点のみで、いずれもApple/Googleの主要インフラであり突然廃止リスクは低い。ZIP/CSV仕様は自前実装のため外部API変更の影響なし。月2h以内に収まる根拠: 仕訳自動化・ルール辞書・外部API連携を持たない設計にしたため、receiptpostで想定された「OCR精度問題+ルール辞書保守+LINE API変更対応」の三重負荷が構造的に発生しない。
審査員Mが指摘した「競合の壁は厚く優位性は限定的」という懸念に対し、本要件書では差別化軸を明確に絞る。freee・マネーフォワードクラウド・弥生の最安プランは月900〜980円で、仕訳・帳簿・申告書生成まで含む全部入りであり、税理士に丸投げする個人事業主には機能過剰かつ価格帯が2倍以上重い。証憑ポケットは「仕訳しない・勘定科目分類しない・税理士に渡せる形に整理するだけ」という意図的な機能絞り込みで月400円の正当性を作る。審査員Bが指摘したreceiptpostの三重保守負荷（OCR精度問題・ルール辞書・LINE API変更）は、勘定科目分類とLINEチャネルを非スコープにすることで構造的に排除し、月2h保守制約を担保する。審査員Uが評価した「税理士コミュニティ経由の配布」は要件に反映し、さらに税理士側が直接ダウンロードできる署名付きURL共有機能をMVPのshouldとして加えることで、税理士自身がアプリを「クライアントへ紹介したい」と思うプッシュ動機を設計に組み込んだ。
獲得スキル: Firebase Storage + Cloud Functions (ZIP生成・署名付きURL) + SwiftUI + Vision Framework (OCR) + App Store サブスクリプション課金の実装経験
主ペルソナ: 週3〜5回の社内定例・顧客商談をこなす30代のビジネスパーソン。MacBook持参で打ち合わせに臨み、会議後に「あれ、あの件どうなったっけ」と議事録を掘り返す手間に慢性的に消耗している。Notionやmiroなどのドキュメントツールはあるが「後で書く」前提の設計で、会議中のリアルタイムマークには重すぎると感じている。副ペルソナ: フリーランスのコンサルタントやプロダクトマネージャー。複数クライアントをまたぐため決定事項の散逸リスクが高く、AIサブスクへの警戒感（録音要件・月額コスト）から「軽量な手段」を探しているが、既存ツールで刺さるものがなかった層。
打ち合わせ中、議題が流れるなかで「それ決定でいきましょう」「Aさん、来週までに確認お願いします」という瞬間が来る。手書きメモでは後から決定なのかメモなのか区別がつかず、NotionやmiroはURL開くだけで話の流れが止まる。結果として宿題が抜け落ち、翌日に「あれどうなりましたっけ」というSlack往復が発生する。この後処理コストが週単位で積み上がっている。
媒体: macOS メニューバーアプリ（SwiftUI + AppKit MenuBarExtra API、macOS 13 Ventura 以降）。技術スタック: Swift / SwiftUI、SQLite（GRDB.swift）、ローカルファイル保存のみ。外部依存ゼロ（LLM API・クラウドDB・アナリティクスSDKなし）。配布: Gumroad（買い切り）+ 将来的にMac App Store（Notarization対応）。
買い切り（ライセンスキー方式） / 1,980円（税込）
Round 1 提案の1,800円から小幅引き上げ。Granola Business $14/月・Otter/Fireflies $10〜$17/月というAI系サブスクと比較して「1ヶ月分以下で永続」の訴求が成立する価格帯。1,980円は日本市場での心理的な整数感（2,000円以下）を保ちつつ、アプリ内の説得コストを下げる。クラウドインフラ・APIコストゼロのため、買い切りで採算が取れる構造。
macOS APIへの依存はMenuBarExtraとSQLiteのみで、年1回のmacOS メジャーアップデート後に動作確認（実機テスト30分）と必要に応じてNotarization再提出（30〜60分）を行う想定。外部API・クラウドDB・LLMサービスへの依存がゼロのため、サービス仕様変更によるランタイム障害が発生しない構造。月次保守の実工数は「macOS新バージョンのベータ確認15分 + ユーザーサポートメール対応30分以内」で月2h以内に確実に収まる根拠がある。
3名の審査員が共通して評価した「非AI・非録音・買い切り軽量設計」はMVPの設計原則として明文化し、AI機能・クラウド同期をスコープ外に固定することで差別化軸を構造的に守る。審査員Bが指摘したmacOS APIの年次変動リスクは、MenuBarExtraとSQLiteのみに依存を絞り外部API依存ゼロにすることで影響範囲を最小化し、年1回のベータ確認で吸収できると判断した。配布チャネルの具体性への期待には、生産性系Slack/Discordコミュニティへの制作ログ投稿とニュースレターピッチという「どこの誰に何を見せるか」まで落とした配布計画で応える。価格は審査員の講評にあったAI系サブスク（月額$10〜$20）との比較優位を最大化するため1,980円（買い切り）に設定し、「Granola1ヶ月分以下で永続」という訴求フレームを価格根拠に組み込んだ。
獲得スキル: SwiftUI + MenuBarExtra によるmacOSネイティブアプリ開発、Notarization・Gumroad連携を含む個人デベロッパー向けmacOS配布フロー全体の習得
主ペルソナはnoteやX（旧Twitter）でアウトプットを習慣にしている20〜40代の社会人。スマホで思いついたことを書き始めるが、完成させる前に別の作業に移ってそのまま放置し、下書きが10〜50本単位で溜まっている。「いつか書く」と思いながら結局見返さず、タイムリーだったはずのネタが古くなって投稿できなくなる体験を繰り返している。サブペルソナはSNS投稿よりも個人ブログや日記的なメモを書く層で、自分の思考の変化を後で読み返したいが専用のリマインド設計を持つアプリを知らない。
iPhoneのメモやDraftsに書きかけの文章が溜まり続けるが、自分からアプリを開いて一覧を漁らないと再会できない。書いた時の熱量が冷めたまま埋もれ、「いつか投稿しよう」が永遠に来ない。通知が来ても「何の通知か」が分からず無視してしまう——という問題は、アプリ側が「N日後に再提示する」という意図を設計に組み込むことで初めて解消される。既存のメモ・ノートアプリはリマインダー機能を持たないか、汎用リマインダーに委ねるだけで「熟成して食べごろになった下書き」という体験設計が存在しない。
媒体: iPhone（iOS 17以上）ネイティブアプリ / App Store配布。技術スタック: Swift + SwiftUI、データ永続化はSwiftData（CoreData後継・外部依存ゼロ）、通知はUserNotifications framework（ローカル通知のみ・プッシュサーバー不要）。外部APIゼロ・バックエンドゼロの完全ローカル完結設計で、保守タスクはSwiftおよびSwiftUIのOSバージョン追従のみ。
買い切り（one-time purchase） / ¥700
審査員3名全員が700円買い切りを肯定的に評価済み。ライタークラスタへの説明が「コーヒー1杯分で下書きを完成させる仕組み」と1文で済む価格帯。サブスクは「罪悪感解消」用途でチャーン率が高くなる構造的リスクを審査員Bが明示しており、買い切り維持が正解。App Store小規模アプリの慣例的価格（¥500〜¥980）内に収まり支払い決断の心理的摩擦が最小。
月次タスクはXcodeのiOS SDK/SwiftUIバージョン追従確認（毎年9月のiOSメジャーリリース前後に集中）と、App Storeレビューの確認・返信のみ。外部API・プッシュサーバー・メール配信インフラがゼロのため「外部サービスの仕様変更」「認証切れ」「配信失敗」の類の保守タスクが構造的に発生しない。月2h以内の根拠は、通知処理がすべてUserNotifications（OS管理）であり自前インフラ運用コストがゼロ点になること。
審査員3名の懸念はすべて「weekly（週めくりリーダー）側の弱点」への言及であり、shitagakiは懸念の核心（外部API依存・メール配信インフラ・サブスクチャーン）をローカル完結設計と買い切りモデルで構造的に排除している。審査員BがPocket/Instapaperなど外部連携必須と指摘した保守コスト問題は、本要件書でインポート機能を非スコープとすることで月2h制約を守る根拠を明示した。審査員MとUが「iOS標準メモ・Notion・Bearで代替しにくい」と評価した「意図的に寝かせて再提示する設計思想」を、熟成タイマー＋食べごろ通知という2つのMust機能に具体化した。審査員Bが懸念したApp Store内キーワード流入については「検索流入に依存しない配布」制約のもとnote記事とX告知の直接動線に集中するよう配布チャネルを設計し直している。
獲得スキル: SwiftData + UserNotifications のローカル完結設計、App Store審査・価格設定・リリースフロー一気通貫の個人アプリ開発経験
主ペルソナ1: 公立小学校の担任（20〜40代）。クラス30〜35名を学期に2〜3回席替えし、かつ月次または学期ごとに掃除・給食・配布等の係当番も更新する。席替えと係分担を別々のツールで管理しており、毎回「前方固定の子を除いてランダム配置→係の組み合わせを手で調整」という二段手間が発生している。主ペルソナ2: 習い事教室の講師（ピアノ・そろばん・学習塾、10〜20名規模）。月次でグループ替えまたは座席更新をしており、簡易な条件（保護者要望で特定の子を前に・仲良し組を離す）を毎回手で調整している。スマートフォン操作は日常的だがPCに不慣れな層も含む。
学期末または月末、担任は黒板前で30枚の名前カードを並べ替えながら「視力配慮の子は前2列固定、特定ペア3組は隣接禁止」を頭の中で制約チェックしつつ手動で配置する。配置が決まっても係当番の割り当ては別の紙またはExcelで再作業となり、合計30〜60分を要する。既存の無料Webアプリは席替え単体は解決できるが係当番との連動がなく、「席替えした後に係も変えないといけない」という二段手間は解消されない。
媒体: PWA対応Webアプリ（ブラウザ完結）。技術スタック: Next.js（静的エクスポート）+ TypeScript、TailwindCSS、Framer Motion（ルーレットアニメーション）、localStorage（データ永続化）、Stripe Checkout（買い切り決済）、Vercel（ホスティング、無料枠）。外部API依存ゼロ（席替えロジック・係抽選はすべてクライアントサイド）。
freemium + 買い切り / 無料（クラス1・生徒20名・係3種）/ 500円 買い切り（複数クラス・生徒40名・係10種・PNG書き出し）
Round1審査員U・Bが500円買い切りへの納得感を支持（「4月に一括で払えば1年使える」）。審査員Mの懸念「先生がわざわざ500円を選ぶ理由がない」への回答として、既存の席替え専業アプリにない『係当番ルーレットとの一体化』と『ルーレット演出モード』を差分として確立し、無料版を日常使いで触れさせてから買い切り誘導する設計にする。月サブスクは頻度3〜4回/年の習い事層には合理化しにくいため買い切り一本に絞る。
席替えロジック・係抽選はすべてクライアントサイドで完結し外部APIに依存しないため、ライブラリアップデートとStripe SDK更新（年1〜2回）が主な保守作業となる。Vercel無料枠の範囲内で動作するため月次のインフラ確認は不要。問い合わせはUIの設定ガイドとFAQページで吸収し、月2h制約に収まる根拠はサーバーレス構成（DB・認証・バックエンドロジックなし）による運用負荷ゼロが前提。
審査員Mの最大懸念「sekigae.jpがほぼ同一機能を無料提供しており500円を選ぶ理由がない」に対し、本要件書では2点の明確な差分を設ける。第一に「係当番ルーレットとの一体化」——席替えと係分担を同一セッションで完結させる機能は既存全競合が未対応であり、担任の二段手間を一度に解消する。第二に「ルーレット演出モード」——先生が教室のスクリーンに映してクラス全員と一緒に楽しむ体験価値は静的配置ツールでは代替できず、この演出がSNS拡散（動画投稿）の核になる。審査員BとUの支持した「頻度の高さと条件制御の弱さ」という評価軸は維持しつつ、過密市場での差分軸を「席替え機能の高度化」ではなく「係当番連動＋演出性」という既存競合が手を付けていない領域に置くことで500円への納得感を作る。
獲得スキル: Next.js静的エクスポート＋Stripe Checkoutのサーバーレス課金実装、およびクライアントサイドのみで動く制約付きランダム配置アルゴリズム設計
主ペルソナ: カフェ・居酒屋・美容室等を1〜2店舗運営する個人店長（アルバイト5〜12名規模）。シフト希望をLINEグループで集め、手書きホワイトボードまたはExcelに転記して確定版を再びLINEで送る作業を週1〜2回こなしている。ITツール導入に抵抗はないが、スタッフ全員にアプリをインストールさせることへの心理的ハードルが高い。サブペルソナ: 美容室のオーナー兼施術者。予約と並行してシフト管理もこなす必要があり、30分以上の転記作業が特に負担。
毎週または隔週の締め日に、LINEグループの希望コメントを読みながらExcelに転記し、不足コマを目視で探して個別に「誰か入れる人いる?」と声をかける作業に30分以上かかる。確定シフトを画像化して再送する手間も含めると、締め作業1回で1時間近く消費することもある。不足コマへの気づきが遅れてギリギリで人手不足が発覚するケースが繰り返される。
LINE Messaging API（Webhook）+ Next.js（App Router）/ Vercel でホスティング。DBはPlanetScale（MySQL互換、無料枠）またはSupabase（Postgres無料枠）。LINE公式アカウント（フリープラン: 月200通まで無料、応答メッセージはカウント外）を起点とし、Webhookはサーバーレス関数で受信。フロントはServer ComponentsでWebダッシュボードを構築。Stripe（月額課金）を組み込む。
店舗単位・月額サブスクリプション（Stripe） / 月額980円（税込）/ 1店舗・スタッフ人数上限なし
審査員講評でoplus（10名まで実質無料）・らくしふ（問い合わせ制）・Airシフト（スタッフ1人330円/月）を踏まえ当初500円から980円に改定。oplusの有料ラインは330円/人なので5名規模で1,650円/月かかる計算になり、スタッフ人数に課金しない980円/店舗は5〜12名規模で明確に安い。かつ審査員Bが指摘した「らくしふ等の競合でほぼ満たせる」リスクに対し、LINEアカウント不要（スタッフ側）・黒板1枚で完結する体験差分を前面に出し、980円の支払い根拠を「転記30分×週2回の時給換算（最低賃金換算でも月2,400円相当）」で示す。
LINE Messaging APIのWebhook疎通確認（月1回・15分）とVercel/Supabaseのダッシュボード確認（月1回・15分）が主タスク。Stripeの入金確認は自動通知に任せる。スタッフ側にアプリ・アカウントがないため問い合わせの接触面が店長のみに限定され、サポート負荷が構造的に低い。LINEの仕様変更リスクについては、Webhookの受信ロジックを薄いアダプター層に分離して変更箇所を最小化し、月2h枠を超えない設計にする。
審査員Mが指摘した「LINE Messaging API依存のWebhook保守が月2h枠を超えるリスク」に対しては、Webhookロジックをアダプター層に分離してLINE固有コードを局所化し、仕様変更時の修正範囲を最小化する。また応答メッセージはAPIの通数カウント外のため、実運用での追加課金リスクはほぼゼロ。審査員Bが指摘した「らくしふ等で9割満たされる競合環境」に対しては、らくしふが問い合わせ制・中規模以上向けである実態を確認済みで、個人店が当日から使える価格透明性（980円/月・カード決済即日開始）と、スタッフ側がLINEアカウント登録すら不要な導入ゼロ摩擦が本プロダクト固有の差別化軸であることを要件に明示した。審査員Uが勝因として挙げた「頻度×痛みの積の大きさ」はMVP設計の優先順位付け（不足コマ警告・確定通知をmust）に直接反映している。
獲得スキル: Next.js App Router + LINE Messaging API Webhook + Stripe サブスク課金の3点セット実装経験
主ペルソナは30〜50代の社会人稽古人（茶道・弓道・空手・合気道などを1〜2種掛け持ち）。週1〜2回の稽古を数年以上続けており、道場ノートは手書きか汎用メモアプリで管理しているが断片化している。昇段・昇級の節目を「いつ何を達成したか」という時系列で振り返りたい欲求はあるが、専用アプリは流派ロック／単一武道特化で使えず、Notion等は設計コストが高い。
道場ノートが紙・メモアプリ・LINEメモに散らばり、初段を取った日や特定の技を習い始めた稽古回を後から参照できない。複数の稽古事を掛け持ちしている場合、どの流派でいつ何段になったかを一覧する手段が存在せず、師範や仲間に経歴を聞かれたときに「だいたい4〜5年前…」としか答えられない。
iOS SwiftUI + SwiftData（ローカルDB）。iCloud Drive経由でCSVエクスポートおよびバックアップ。StoreKit 2でワンタイム買い切り課金。Xcodeのみで完結、外部サービス依存なし。
買い切り（ワンタイム購入） / 480円
審査員講評で「600円の支払い意思を引き出す切実さに欠ける」と指摘された。競合MatchaNoteの月額480円と同額の買い切りに設定することで『サブスクより安く、永続使用できる』という比較優位を明示できる。稽古録という習慣ツールは1回限りの体験でなく年単位で蓄積されるため、月額課金との非対称性が買い切りへの支払い意思を底上げする。将来的な価格引き上げはレビュー100件以降に検討。
外部データ依存（大会関門データ等）がなく、全データはユーザー自由入力のため年次更新作業が発生しない。保守タスクはiOS新バージョンのSwiftUI API差分対応（年1回・Xcode警告で把握）とApp Storeメタデータ更新のみ。年1回対応を月平均に換算すると実質30分/月以内に収まり、月2h枠に対して余裕が大きい。
審査員3名が共通して指摘した「600円の支払い意思を引き出す切実さ」への回答として、価格を480円（競合MatchaNoteの月額と同額の買い切り）に修正し、「サブスクより安く永続使用・データ蓄積でロックイン強化」という比較軸を設計に埋め込んだ。審査員Mが評価した「複数稽古事を横断した昇級年表の時間軸可視化という残余」を中心MVPに据え、審査員Bが懸念した外部データ依存を構造的にゼロにするため流派・段位体系の内包を非スコープに置いた（全入力ユーザー自由記述）。審査員Uが指摘した既存汎用アプリ（Day One/Notion）との差別化については、稽古録専用UIと横断タイムライン表示という「設計コストの肩代わり」を具体的な差別化軸として明文化した。審査員Bが明示したiOSネイティブスキル獲得の汎用性をtech選定の根拠として採用し、Android対応を意図的に非スコープとした。
獲得スキル: SwiftUI + SwiftData + StoreKit 2 + WidgetKit によるiOSネイティブ開発の実戦スキル（ポートフォリオ最汎用枠）
主ペルソナは30〜50代の海釣り・渓流釣り愛好者で、週1〜月2回釣行し仕掛けの選択にこだわりを持つ層。タックルに年数万円を投じており「釣果記録アプリは使っているが、自分専用の仕掛けレシピと消耗品残数を一元管理できる場所がない」状態にある。副ペルソナはサビキ・胴突き仕掛けを複数パターン持つ堤防ファミリー釣り師で、子どもを連れた釣行中に両手がふさがったまま在庫を確認したいニーズがある。
釣り場に到着してタックルボックスを開けたとき、「先週使った仕掛けの針の号数が思い出せない」「ハリスが何m残っているか分からない」という状況が釣行ごとに繰り返される。メモ帳では構造化が弱く検索できず、ノートアプリでは釣り場でのタップ操作が重い。消耗品が尽きていることに釣り場で初めて気づき、釣行機会を丸ごと損失するケースも頻発する。
iPhone（iOS 16以上）/ SwiftUI + SwiftData（ローカルDB）+ CloudKit（iCloudバックアップ）。LLM・外部API依存ゼロ。サーバーレスで月次保守コストは実質ゼロ。Xcodeとシミュレータのみで完結し、外部クラウドインフラ不要。
買い切り / 980円（App Store税込）
審査員講評で「タックルに数万円を使う層は800円の障壁が低い」と指摘されたことを踏まえ、元の800円案から980円へ微調整。App Storeの価格ティアでは0.99USD帯に相当し、有料アプリとして認知されやすい心理的アンカーとなる。サブスクを避けることで「一度買えばずっと使える」の訴求がオフライン釣り師層に刺さる。
SwiftData + CloudKit はAppleのOS更新に追随するだけでよく、外部APIのバージョン追従・データ鮮度維持は発生しない。月次作業はApp Storeのクラッシュレポート確認（15分）とiOSメジャーアップデート後のシミュレータ動作確認（30〜60分）のみで、合計月1〜2h以内に収まる根拠がある。ユーザー生成データのクローズド設計のため、コンテンツモデレーション作業は発生しない。
審査員3者全員が「釣行ごとに繰り返す実在の痛みをカバーしている」「仕掛けレシピ×消耗品在庫の組み合わせに差別化余地がある」と評価した点を軸に据え、MVP機能をその2点に集中させた。懸念として暗示されていた「汎用メモで足りるのでは」という代替可能性については、構造化フォーム入力・ワンタップ在庫更新・在庫アラート・レシピへの釣果紐付けをセットで設計することで「Notionでは自分で作り込まない限り再現できない」体験の密度を高め、支払い動機の根拠とする。保守コスト懸念に対してはサーバーレス・外部API依存ゼロ・ユーザー生成データのクローズド設計で月2h制約に構造的に収める。価格は800円から980円へ微調整し、「数万円をタックルに使う層への低障壁」という審査員の指摘を活かしつつApp Storeの価格帯でより認知されやすいティアに合わせた。
獲得スキル: SwiftUI + SwiftData + CloudKit による完結型iOSアプリ開発スキル（外部サーバー不要のAppleエコシステム完結構成）
主ペルソナは「神奈川・埼玉・愛知など中間地の家庭菜園歴3〜10年、30〜50代」。毎シーズン種袋の裏を見ながら「北海道基準の蒔き時を自分の地域に換算し直す」作業をアナログで繰り返している。区画は3〜6畝程度で、何を昨年どこに植えたかはノートかスマホメモで管理しており、連作障害の確認に都度調べ直す手間を持て余している。副ペルソナは「週末農園オーナー・市民農園利用者」で、区画番号ベースの管理記録を持ちたいが専用アプリを探すと機能過多か記録ツール止まりで時期翻訳ができないものばかりという状況。
春の種まき直前、種袋裏面の「播種適期：3月〜4月（北海道基準）」を見て「うちの畑（中間地）では何月に蒔けばいいんだ」と詰まる。ネットで調べると情報がバラバラで確信が持てず、結局去年の感覚で蒔いてしまう。さらに「去年ここにトマト植えたっけ」と区画の記憶が怪しく、ナス科の連作を繰り返して収量が落ちても原因の特定が遅れる。この二段階のつまりが毎シーズン再発する。
PWA（Next.js + Tailwind CSS）。データはIndexedDBにローカル保存、サーバーレスポンス不要。野菜カレンダーDBはJSONファイルとしてバンドル（API呼び出しなし）。ホスティングはVercel無料プラン。課金はRevenueCat + App Store / Google Playの年額課金（PWAのみの場合はStripe Payment Links）。
年額サブスクリプション（買い切りに近い感覚） / 年500円（税込）
講評M17で審査員Mが「年300円では種袋翻訳体験だけでは差別化根拠が薄い」と指摘。区画連作マップ＋アラートを必須セットとすることで「失敗した苗代のほうが高い（トマト苗1株150〜300円×複数本）」という正当化ロジックが成立し、300円→500円への引き上げも通りやすい。App Store / Google Playの最低課金単位（¥600前後）との整合性から500円に設定し、PWA直販（Stripe）でも同額を維持する。
野菜カレンダーDBはJSONファイル管理で、年1〜2回の追加・修正（新品種追加・誤植修正）のみ。気象APIのような外部依存がゼロのためAPIキー失効・レート制限・仕様変更による緊急対応が発生しない。UIの季節更新とデータ修正を合計しても月1〜2時間以内に収まる根拠はDB静的構造にある。
審査員Mの「連作アラート付き区画管理を備えた菜園プランナー・Farm Recoが無料で存在し、種袋翻訳だけでは年300円の差別化根拠が薄い」という指摘に対し、本要件書は三点で正面から応答する。第一に、菜園プランナー・Farm Recoの実調査で確認した通り、両者は「地域別播種カレンダー×連作アラート×種袋翻訳（北海道基準→自地域換算）の三点統合」を持たず、それぞれ記録ツールまたは情報参照ツールに留まる——この欠落が本プロダクトの差別化核心である。第二に、価格を年300円から年500円に引き上げ、連作アラートを必須MVP機能として確定することで「種袋翻訳＋区画連作マップ」のセット価値で支払い意思を担保する。第三に、配布を検索依存ではなく市民農園掲示板・SNS種まき投稿者への直接接触に設計し、審査員Bが評価した「菜園コミュニティSNSという検索外の配布経路」を具体的チャネルとして実装する。外部APIゼロ・静的DBバンドルの構造は審査員Bの「月2h以内保守」評価を維持したまま、審査員Mの懸念である差別化不足を機能セットの再定義で解消する。
獲得スキル: ローカルファーストPWA設計・IndexedDB活用・静的JSONデータ設計によるAPI依存ゼロのサービス構築パターン
主ペルソナ: 社会人サークル（週1バドミントン・月1飲み会型）の幹事を持ち回りで担う20代後半〜40代の会社員。ITリテラシーは普通で、スプレッドシートとLINEは使えるがSaaSの導入経験はほぼない。毎月の出欠集計→会費計算→立替精算を2〜3時間かけてLINEと表計算で手でこなしており、メンバーへの催促とPayPay送金依頼が特に億劫。
イベント前週、幹事はLINEグループに出欠スタンプを投げかけ、既読スルーするメンバーに個別DM。当日参加費の回収漏れをPayPay送金依頼で追いかけ、自分が立替えた備品代をメモに残しておくが翌月には誰が払ったか曖昧になる。同じ作業が毎月繰り返され、「幹事やりたくない」が口癖になっている。調整さんで出欠は取れるが会費・割り勘とは別ツール、サークルスクエアは機能が多すぎて導入ハードルが高く既存LINEグループを捨てる必要がある。
媒体: LINE Bot（Messaging API）+ Webダッシュボード（LINE Login認証）。スタック: Cloudflare Workers（Bot webhook + API）+ Cloudflare D1（SQLite、無料枠内）+ Next.js on Cloudflare Pages（幹事ダッシュボード）。サーバーレス構成でインフラ保守ゼロ、月額ランニングコストは実質0〜数百円。
チーム月額サブスクリプション（幹事1人が支払い） / 月300円（年払い2,400円で2ヶ月分無料）
Round 1の月300円を据え置き。審査員Mの「説得コストが高い」懸念に対し、価格そのものより導入摩擦（既存LINEグループにBotを追加するだけ）の低さで対応する。幹事の時間コスト換算（月2〜3時間×時給換算3,000〜5,000円）と比べると月300円の抵抗感は極めて低く、価格自体が障壁ではないとの審査員Uの評価を重視。初月無料トライアルで体験→継続の流れを設計する。
月次タスクは主にCloudflare D1の利用量確認（5分）とLINE Messaging APIのエラーログ確認（10分）のみ。サーバーレス構成のため再起動・スケーリング作業は発生しない。LINE APIの破壊的変更は年1〜2回程度で、公式ドキュメントのChangelog購読でキャッチアップ可能。外部依存はLINE Messaging API（LINE株式会社）とCloudflareのみで、どちらも個人副業規模では無料枠が当面超えない。月2時間以内に十分収まる。
審査員Mの「競合（調整さん・サークルスクエア等）で実務が十分に回っている」という懸念に正面から答える。競合各社の実際の機能を確認すると、調整さんは出欠・日程のみでLINE完結型の会費計算・立替・催促を持たず、サークルスクエアは全員アカウント登録が前提で既存LINEグループへのゲリラ追加ができない——つまり「出欠」「会費計算」「割り勘精算」「催促自動化」の4つをLINEグループ内で完結させる単一ツールは実在しない。審査員Mが指摘した「幹事が新しい有料ツールを導入する説得コスト」については、メンバー側にアカウント登録もアプリDLも不要（LINEにBotが増えるだけ）という設計で摩擦を排除し、幹事1人の判断だけで即日稼働できる構造で対応する。審査員Bが評価した「競合空白」を機能一覧で明示し、審査員Uの「LINE内で強制普及する構造」を実装レベルで具体化したのが本要件書の核心である。
獲得スキル: Cloudflare Workers + D1によるサーバーレスAPI設計、LINE Messaging API Webhook処理、LINE Mini App / LIFF認証の実装経験
主ペルソナは手網・電動小型焙煎機（ユニオンサンプルロースター・Gene Cafe等）を持つ自家焙煎歴1〜5年の30〜40代。生豆をオンラインで500g〜1kgロットで購入し、週1〜2回焙煎する。焙煎に月3,000〜15,000円を投じており、800円の買い切りアプリへの支払い抵抗は低い。補助ペルソナは精製・産地の違いを飲み比べたい中上級カフェ愛好家で、焙煎はせず抽出（ペーパードリップ・エアロプレス等）の再現に困っている層。
先週うまく仕上がった焙煎を再現しようとしても、その日の豆ロット・投入量・1ハゼのタイミング・排出温度がバラバラのメモアプリ・紙ノート・写真に散らばっており、同じ抽出レシピを適用しても味が再現できない。焙煎記録と抽出記録が別アプリ・別ノートに分断されているため「あのとき何がよかったのか」を特定する手がかりが毎回失われる。
iOS（iPhone）/ Swift + SwiftUI + CoreData + CloudKit。ローカルファーストでサーバーレス。TestFlight経由での事前配布→App Store公開。外部ライブラリは最小限（CSV生成のみ標準ライブラリで完結）。
買い切り（one-time purchase） / 980円
審査員M・Bが「焙煎機に1〜10万円投じる層の支払い抵抗は低い」と一致指摘。Round1の800円から980円に微上げ。理由は①App Store最小課金単位の切り上げで知覚価値を高める、②競合Roastmaster（英語・$9.99）と同水準に設定することで「日本語専用の本格版」ポジションを自然に取れる、③買い切りであることをサブスクへの反感が強い自家焙煎コミュニティに対する差別化として前面化する。
CoreData + CloudKit はAppleのインフラ依存のため外部サーバー保守タスクがゼロ。月次タスクはApp Storeのクラッシュレポート確認（15分）とiOSメジャーアップデート後の動作確認（1〜2回/年・各60分）のみ。依存ライブラリは標準フレームワークのみのため「ライブラリ廃止対応」が発生しない構造。月2h以内の根拠は「サーバー・外部API・外部DB・サードパーティライブラリをすべてゼロにした」という設計選択そのものによる。
審査員Uの「ノートアプリ・Notionで代替されやすい」という最大の懸念に対し、本要件書は「代替されにくい構造的理由」をデータモデルレベルで答える。豆ロット・焙煎セッション・抽出レシピを外部キーで明示的に紐付け、「再現ビュー」で三軸を一画面に統合する設計は、Notionや汎用メモアプリでは自作が必要な関係データ構造であり、フォーム+リンクを自分で組めない層にとって「最初から組み込まれている」ことが差別化になる。審査員Bが指摘した「豆情報DBの鮮度維持コスト」は、ユーザー入力完結・外部API不使用の設計で構造的に封じており月2h制約の根拠を技術選定まで遡って説明した。審査員Mが評価した「競合の隙間（温度グラフ特化アプリが抽出側を持たない）」は調査で裏付けられ、Roasty・焙煎タイマー等の国内既存アプリはいずれも抽出記録を持たないことを確認した。価格は審査員M・Bの「支払い抵抗が低い層」指摘を受け980円に上げ、英語競合Roastmaster（$9.99≒約1,500円）と比較した割安感と日本語専用の価値を同時に訴求する。
獲得スキル: SwiftUI + CoreData + CloudKit のサーバーレスiOSアプリ設計・App Store公開の一通りの実務経験
主ペルソナはギター・ピアノ・管楽器問わず「毎日または週3〜5回練習する社会人アマチュア奏者」。20〜40代、楽器歴3年以上、独学またはレッスン通いで目標曲を持っており、「昨日どこで詰まったか思い出せない」「練習したのに同じ箇所でまたミスる」という反復する悔しさを抱えている。スマホアプリのメトロノームは既に使っているが、練習内容を別途メモするのが面倒でやめてしまった経験がある層。
練習を終えて楽器を片付けた直後、「今日は132BPMで3小節目から詰まった」という記録を残したいが、開いているのはメトロノームアプリだけ。別のメモアプリに切り替えるのが億劫でそのまま忘れる。翌日また同じ箇所でつまずき、「これ先週も詰まったやつだ」と気づくが具体的なテンポは思い出せない。テンポ数値と詰まった小節番号というシンプルな2点セットを、メトロノームを止める動線の中で記録できれば解決する。
プラットフォーム: iOS（iPhone専用、iPad対応は後回し）/ 言語: Swift + SwiftUI / データ: Core Data（ローカル）+ NSUbiquitousKeyValueStore でiCloud Backup対象 / グラフ: Swift Charts（iOS 16以降標準）/ 通知: UNUserNotificationCenter / 配布: App Store 買い切り
買い切り（一度払えば永続利用） / 700円
審査員3名とも700円を支持。Modacityが月額$12.99・年額$129のサブスクで「練習管理は定額に払い続ける商品か？」という抵抗感がある層に対し、700円買い切りは『習慣化ツールに一回だけ払う』感覚でマッチする。Andanteの$3.99（約600円）より若干高いが、テンポ推移グラフ＋小節ヒートマップの構造化ログという差別化で正当化できる。サブスク嫌いな日本のユーザー層にも届きやすい。
保守作業: iOS年次アップデート後の動作確認（Swift Charts・Core Data APIの非推奨確認）が年1回・数時間。月次はクラッシュレポート確認（App Store Connectの標準機能）とレビュー返信のみ。外部依存: サーバーなし・外部API一切なし・LLMなし。iCloudバックアップは OS標準機構のため Appleの仕様変更以外でブレーカーが落ちない。月2h以内の根拠: データ更新不要・認証フロー不要・録音ファイル管理なし、という3つの重量機能をスコープ外にしたことで、問い合わせ頻発ユースケース（「データが消えた」「録音が保存されない」）を構造的に排除している。
審査員Mが「Music Journal Pro / Andante / Smart Metronome & Tuner がほぼ同機能を提供」と指摘した点について: 調査の結果、Andanteは練習時間・気分・フォーカスのログが主軸でBPM×小節番号の構造化記録は非対応、Music Journal ProはBPMログ有りだが小節ヒートマップなし、Modacityは多機能サブスクでシンプルさが損われていることを確認した。「テンポ推移グラフ＋つまずき小節ヒートマップ」の組み合わせに特化した買い切りアプリは現時点で空白である。審査員Mが懸念した「バックアップ・デバイス移行問い合わせの重さ」には、iCloud Backup標準対応＋アプリ内復元ガイドで対処し、録音・クラウド同期というサポート負荷の高い機能を意図的にスコープ外にすることで月2h保守を構造的に守る。審査員Uが懸念した配布面（App Storeオーガニック限界）については、楽器系YouTuberへのプロモコード配布とTestFlightβ配布を検索に頼らない初期チャネルとして追加した。
獲得スキル: Core Data + SwiftUI + Swift Charts によるローカルファースト iOS アプリ設計・App Store リリースの実務経験
主ペルソナ1: 週3〜5回棒針・かぎ針編みをする30〜50代女性。Apple Watch Series 6以降を日常使いしており、編み物中に「また数え間違えた、何段目だっけ」と手を止めてスマホを確認する行動を繰り返している。複数プロジェクトを並走させるため段数管理が煩雑になりやすい。主ペルソナ2: Ravelryや手芸系Instagramで積極的に作品を投稿するニッター。コミュニティ内でアプリや道具の使い心地を共有する習慣があり、「リューズで段数を操作できるアプリ」という体験型の情報を口コミとして広げやすい層。
棒針を両手で持ちながら段数を進めたとき、「今何段目か」を確認しようとするとスマホを置いて画面をタップする必要があり、集中が途切れてミスカウントが起きる。既存のWatch対応アプリはタップ操作が主流で「手がふさがっている状態での操作」を前提に設計されておらず、リューズ回転という指1本で完結する操作を段数カウントに使い切っているアプリが存在しない。数え間違いが発覚するたびに数十段ほどきが発生し、これが編み物セッションの最大のストレス源になっている。
Apple Watch (watchOS 11以降) + iPhone companion アプリ。SwiftUI + WatchKit + ClockKit(Complication) + iCloud(NSUbiquitousKeyValueStore)で完結。外部API・バックエンドサーバー一切なし。Digital Crown操作はWKCrownSequencer APIで実装。
買い切り（App Store 一括購入） / 370円（Tier 1 / 国内実効価格）
審査員M・Bが「500円買い切り」を肯定的に評価したが、競合のKnit Row Counter（無料〜数百円）・StitchTally（無料）との価格差を縮め即決ハードルを下げるため1段階引き下げ。370円は「飲み物1本分」の心理的ラインで編み物コミュニティでの口コミ購入に最適。iAP・サブスク・広告は一切導入しない。
watchOS major versionへの追従（年1回、秋のwatchOS更新時）がメイン保守タスク。外部APIゼロ・バックエンドなし・カウンターロジック単体のため、問い合わせは「リセットされる」「Complicationが更新されない」系のバグに限定される。年1回のwatchOS対応工数を4〜6h、月次換算で約0.5hと見積もり、月2h上限に対して大幅な余裕がある。iCloud同期はNSUbiquitousKeyValueStoreを使うことでCoreDataより実装・保守が軽量。
審査員U・Mが指摘した「Apple Watch所持という二重絞り込みで母数が激減する」懸念に対しては、Ravelry・海外編み物コミュニティへの英語対応UIで国内限定でなくグローバル市場を対象とすることで母数を拡張する。審査員Mが挙げた競合（Knit Row Counter・StitchTally）はいずれもWatch画面タップが操作前提であり、WKCrownSequencerを使ったDigital Crown専用設計のアプリは現時点で確認できず、「リューズ1操作で±1」は実装可能な差別化として成立する。審査員Uが懸念した「watchOS追従という副業制約に重いコスト」については、外部API・サーバーレス・カウンターロジック単体という構成で月次保守を0.5h相当に抑える設計とし、年1回のwatchOS追従が実質的な唯一の保守タスクになることを根拠に反論する。審査員B・Mが評価したコミュニティ配布経路（Ravelry・手芸YouTube）を具体的チャネルとして要件に組み込み、価格を500円から370円に1段階引き下げることで即決ハードルも下げた。
獲得スキル: watchOS/WatchKit + WKCrownSequencer + ClockKit Complication + iCloud KVS の実装経験（Apple Watch固有インタラクション設計の実践知）
主ペルソナは「月1〜2回ボードゲーム会を主催する幹事」。参加者5〜10人のDiscordサーバーまたはLINEグループを持ち、毎回「何持ってく？」の確認を個別DM・スレッドで回している30代前後。スマホだけで完結したい・インストールを参加者に強制したくないという前提を持つ。副次ペルソナはその参加者側——幹事からURLを受け取り、自分の所有ゲームを登録して「持っていく」を押すだけで済む人。
ゲーム会前日の夜、幹事がDiscordに「今週何持ってくか教えて〜」と投稿する。バラバラに返信が来て重複も抜けもあり、当日カチョウが3個・カタンがゼロというミスが起きる。この確認作業が毎回同じ手順で繰り返され、幹事だけが全体を把握していなければならない状態が続く。
PWA（Vite + React + TypeScript）、データ永続化はIndexedDB（Dexie.js）、ルーム共有はURLパラメータ＋Firebaseリアルタイムデータベース（持ち寄り申告のみサーバー同期）、課金はStripe Payment Links（買い切り1SKU）。デプロイはFirebase Hosting。サーバーレスで月額コスト0〜数百円に収まる構成。
フリーミアム買い切り / 無料プラン＋600円買い切り（永久アンロック）
審査員3名とも600円を肯定。幹事1人が払えば参加者は無料で使える非対称構造が600円の納得感を高める。月額サブスクにすると年間7,200円になり趣味ツールとして高すぎる。買い切りのシンプルさが保守コスト（返金・解約対応）も削減する。無料枠を棚20件・月2ルームに設定することで個人利用の試用は完全無料とし、月1〜2回開催するアクティブ幹事が自然に課金ラインに達する設計。
月次タスクはFirebaseコンソールの利用量確認（無料枠内か）とStripe入金確認のみ、合計30分程度。外部ゲームDB APIを持たないためタイトルデータの更新作業はゼロ。PWA自体はホスティングにデプロイするだけでOS更新の影響を受けない。月2h以内の根拠：バックエンドレスでFirebase SDKがインフラを吸収し、課金はStripeが管理するため、開発者が触る運用作業がほぼ存在しない。
審査員3名が共通して評価した「幹事が参加者にURLを投げると全員に届く非対称伝播構造」をMVP中核に据え、ルーム作成→URL共有→参加者がアカウント登録なしで持ち寄り申告できるフローを最優先で実装する。審査員Mが指摘した「外部API依存を避ければ保守リスクが低い」点に対しては、ゲームタイトルを手入力・外部DBなしで管理する設計を明記し月2h保守を構造的に担保した。最大の潜在的懸念はボドゲーマがゲーム会機能をすでに持つ点だが、ボドゲーマは参加者側もアカウント登録が必要でURL共有だけで全員を招待できない——この参加摩擦ゼロという差異が「幹事道具」として一本筋の差別化になる。600円買い切りは3名が肯定しており、月額に変える必然性はなく据え置く。
獲得スキル: PWA（IndexedDB・ServiceWorker・Web Share API）とFirebase Realtime Databaseによるリアルタイム同期の設計・実装経験、およびStripe Payment Linksを使ったフリーミアム買い切りの課金フロー実装経験を獲得する。
主ペルソナは「年2〜6回コミケ・地方即売会にサークル参加する同人作家」。一人または二人体制でブースを回しており、複数品目（3〜10冊程度）を同時頒布している。イベント当日の数時間は買い手対応と頒布数管理を並行せざるを得ず、手書きのカウント表や汎用メモアプリでは品目が増えた瞬間に集計ミスが発生する経験を持つ。サブペルソナとして「同人グッズ・BOOTH委託と掛け持ちしており、当日終了後にイベント別売上を記録しておきたい」層も存在する。
コミケ当日、頒布開始から数十分で複数品目の在庫状況が入り乱れる。「新刊あと何冊？」と聞かれた瞬間に手元のメモを探す、カウントがズレて終了後に在庫と売上が合わない、完売しそうな品目への列案内が遅れて機会損失が出る——これらが毎イベント繰り返し発生する。汎用カウンターアプリは単一数値の加減算しかなく、「在庫バー + 残数 + 売上金額 + 品目別」の組み合わせを同一画面で扱えない。
ネイティブ iOS アプリ（SwiftUI）、ローカルデータストア（SwiftData / Core Data）。外部 API・サーバーレス依存なし。CSV エクスポートは Files アプリ経由で共有。最低対応 iOS 16 / iPadOS 16（iPad での横画面利用を考慮したレイアウト分岐）。
買い切り（App Store 単品購入） / 1,000円
審査員3名が全員「1,000円の支払い意思が成立する」と評価。同人作家は1冊1,000円で頒布している層であり、業務的正当化（売上管理・機会損失防止）が明確。値下げ余地より根拠の補強を優先し据え置き。フリーミアム・サブスク・アドオンは保守複雑度を増やすため採用しない。
外部 API・データベース依存ゼロのため、OS バージョンアップ対応（年1回 iOS メジャーアップデート時の動作確認・軽微修正）と App Store Connect のメタデータ更新が主タスク。月次では問い合わせ確認とクラッシュレポート（Xcode Organizer）確認のみで合計1〜2時間以内に収まる根拠は、ローカルストアのみでサーバー障害・API 変更・外部認証トークン失効が発生しない構造による。
審査員3名の共通懸念は「即売レジとの差別化軸が実装レベルで明確か」という点。これに対し、circlepost は会計（合計金額・釣り銭計算）を意図的にスコープ外とし、「在庫残バーの視覚フィードバック＋完売警告バイブ＋当日モードロック」という在庫カウンター特化設計で差別化する。即売レジが「いくら売れたか」に答えるのに対し、circlepost は「あと何冊あるか・どの品目が危ないか」に答えるプロダクト定義を徹底する。審査員Mが指摘した「当日ワンオペ統合」については、品目別ビューを単一画面で完結させ、イベント切替ナビゲーションを最小タップ数に抑える UX 設計で応える。審査員Bが言及した「使ってみた投稿が口コミになりやすい」動線は、コミケ開催直前にスクリーンショット共有しやすい in-app 共有ボタン（売上サマリの画像書き出し）を MVP に含めることで構造化する。
獲得スキル: SwiftUI + SwiftData によるネイティブ iOS アプリのフルサイクル実装（設計・ローカル永続化・CSV エクスポート・App Store 審査・リリース）を習得
主ペルソナ1: DIY経験1〜3年の30〜40代男性。週末に棚・テーブル・収納を自作し、ホームセンターのカットサービスを定期的に使う。設計は頭の中またはメモ帳で済ませていて、毎回「板が1枚足りない」「端材が多く出た」「カット指示書を書き直す」という失敗を繰り返す。スマホとPCを両方使うが、専用ソフトを習得するほどの熱量はない。主ペルソナ2: DIY初心者の20〜30代女性。SNSや動画を見て「自分でも作れそう」と思い材料を買いに行くが、サブロク板から何枚取れるかが分からず店頭で困惑する。計算ミスで材料を買い直した経験を1〜2回持つ。課金に対して慎重だが「板代が浮く」ならお釣りが来ると感じる価格帯には払う。
ホームセンターのカットサービスカウンター前で、手書きメモをもとにカット枚数を口頭で伝えようとしたが枚数計算に自信がなく、その場でスマホ電卓を叩いて10分立ち尽くす。帰宅後に板が1枚足りないと気づき、翌週再度ホームセンターへ。2回目の交通費とカット料金で合計1,200円の追加出費。「最初から計算してから来ればよかった」という後悔が毎作品ごとに繰り返される。
媒体: ブラウザで動作するWebアプリ（PWA対応、スマホからも利用可）。技術スタック: フロントエンドのみ（Vite + React + TypeScript）、2Dパッキングは自前実装またはbin-packingライブラリ（guillotine-cut対応）、PDF出力はjsPDF、ホスティングはCloudflare Pages（無料枠、外部API依存なし）。バックエンドなし・DBなし・サーバーレスで保守コストゼロ。
買い切り / 2,400円（Stripe Checkout / 支払い後にlocalStorageにライセンスフラグを書き込み）
審査員3名全員が2,400円を「板材費節約・廃材削減の直接便益で正当化できる」と評価済みのため据え置き。無料でカットリスト入力・板取り図プレビューまで体験でき、PDF出力と買い物メモ出力が有料機能。「結果を見てから買う」フローで転換率を担保する。}
外部API依存ゼロ・DBなし・サーバーレス構成のため、障害対応・データ更新・依存サービス変更への追従が発生しない。月次保守タスクは「Stripe決済ログの確認（15分）」「Cloudflare Analyticsでのエラー確認（15分）」「ライブラリのセキュリティアップデート確認（30分）」の計1時間以内が想定上限。2Dパッキングアルゴリズムはロジック確定後に変更頻度がほぼゼロになる性質を持つため、機能追加しない限り月2h以内は恒久的に維持できる。
審査員M・Bが共通して指摘した「競合無料ツールとの差別化を体験価値で明示できるか」に対し、kidoriは「カットリスト入力→板取り図→ホームセンター向けカット指示書PDF→買い物メモ（金額計算付き）」という一気通貫フローで答える。既存競合（CutListOptimizer・caDIY3D・もでりんクラウド）はいずれも割付け計算または設計に特化しており、「ホームセンターのカウンターで使える資料を出力するまで」を一画面で完結させるプロダクトは日本語圏に存在しない。審査員Bが言及した「英語中心ツールが日本のサブロク板・カット指示書フォーマットに未対応」という空白を、プリセットと出力形式の両方で埋める設計にする。フリーミアム構造（板取り図プレビューまで無料・PDF出力から有料）により、ユーザーは結果を確認してから2,400円を払うかどうか判断できるため、「無料代替で足りる」という離脱を体験後の納得感で防ぐ。
獲得スキル: フロントエンドのみで完結するSaaS型課金フロー（Stripe Checkout + localStorageライセンス管理）と、2Dビンパッキングアルゴリズムの実装・チューニングの実践経験
主ペルソナは30〜45歳の社会人で、ギター・編み物・プラモデル・刺繍・水彩画などの趣味を2〜5個持ち、どれも3週間以上放置してある人。「また今度やろう」と思うたびに「どこまでやったか思い出す作業」が発生し、結局手をつけないまま次の週末になる。副業・育児・残業で可処分時間が短く、趣味に割ける精神的余白も少ない。
週末の2時間、ようやく趣味の時間を確保した。しかし作業台の前に座っても「前回どこで止まったか」「次に何をすればよかったか」が思い出せず、道具を引っ張り出しながら記憶を掘り起こすだけで30分が消える。最悪の場合「次回に回そう」で終わる。リマインダーアプリには「ギター練習」とあるだけで再開の文脈が何も書いていない。
iOS (SwiftUI + SwiftData + WidgetKit)。外部API依存ゼロ。iCloud CoreData同期のみ（OS標準）。バックエンドサーバーなし。App Store 単一配布。LLM・生成AI機能なし。
買い切り / 980円
審査員M・Bが「600円の心理的摩擦の低さ」を評価したが、審査員Uの「支払い動機が弱い」という懸念に対してはむしろ価格を上げることで『ガジェット・趣味にお金を使う層』に絞り込み、値ごろ感ではなくセグメント選別で解決する。980円は App Store の心理的ラインである1000円を下回りつつ、メモアプリ(無料)との差を「設計の専門性」で正当化できる価格帯。サブスク維持コスト(サーバー・API)がゼロなため、永続ライセンスとしての説明が自然にできる。
外部API・スクレイピング・バックエンドがゼロのためDOM追従リスクは構造的に存在しない。月次タスクはApp Storeレビュー確認(15分)とiOS新バージョンでのWidgetKit動作確認(30〜60分)のみ。年1回のmajor iOS updateで最大2時間の検証が発生するが月換算では10分以内。月2h枠の95%が未使用のまま運用できる。
審査員Uの「メモアプリで7割代替できる＝支払い動機が弱い」という核心指摘に対し、本要件書は3点で正面突破する。第一に200字制限・5分タイマー・放置日数ソートという設計上の意思決定そのものが価値であり、汎用メモには「書かせすぎない」という設計制約がない。第二にWidgetKitによるホーム画面・ロック画面への常駐は「気づきの仕組み」をOSレベルで組み込む差別化であり、リマインダーの通知とは接触の性質が異なる。第三に価格を980円に引き上げ、「趣味にお金を払う層」に絞り込むことで支払い意思の薄いユーザーをあらかじめフィルタし、少数購入×高満足のモデルに切り替える。審査員M・Bが評価した「外部API依存ゼロ・保守月2h以内」という構造的優位は維持しつつ、懸念の根本であった「誰も課金しない」問題をペルソナの絞り込みと設計の特化で応答する。
獲得スキル: SwiftUI + SwiftData + WidgetKit の実装経験 / App Store 申請・審査フロー / iOS ライフサイクル設計