50案を、戦わせた。

kotologが勝る理由は「痛みの汎用性と頻度」にある。「言った言わない」は車の取り合いに限らず、家事分担・病院予約・学校行事・出費の合意など週複数回発生するため、同じツールが何度も引っ張り出される。kurumaban は「車を複数人で共有している家庭」という条件がまず狭く（都市部は一人一台か車なし、地方の車複数台家庭は少数派）、Googleカレンダー共有や家族LINEグループでの一言連絡で代替できてしまう既存代替の壁が低い。一方kotologも「Notionの家族版」「共有メモ」で代替される懸念はあるが、#タグ台帳化+検索という「会話スレッドに埋もれず後から引き出せる」機能は既存LINEにない構造的欠落を突いており差別化余地がある。保守面では両案ともLINE Botで似た水準だが、kotologはユーザー起点のタグ設計なので外部データ依存がなく月次保守が軽い。配布面はLINEベースで同等。総じてkotologの方がターゲット世帯が広く、痛みの再現頻度が高い。

敗者の光: kurumaban は「予約が重複したとき即座にブロック」という体験の自然さが際立っており、機能スコープが絞られているぶん初期実装コストが低く、車共有世帯に刺されば口コミ経路も明確という点が評価できる。

kurumaban（車予約ボード）は「誰がいつ車を使うか」という単純なスケジュール衝突の解消が本質であり、2026年3月に本格展開したLINEカレンダーの共有カレンダー機能でほぼ代替される。家族グループのLINEトークから直接予定を登録・共有できる以上、「重複を警告する車専用Bot」に追加で月300円を払う動機が薄い。また車保有世帯でも共用1台は核家族の少数派で痛みの頻度が限られ、「取り合い」が起きるのは週末のみという家庭が多い。一方のkotologが解く「言った言わない」問題は、カレンダーではなく意思決定の台帳化というカテゴリであり、LINEカレンダーとは解決対象が異なる。家族間の「〇〇はどうなった」「いつ決めた」の検索・参照ニーズはメッセージ履歴の海に埋もれる構造的問題であり、タグ付き台帳として整理する価値は残る。ただし差別化は紙一重で、Notionの共有DBや家族用メモアプリ（ファミリーログ等）との競合はあるため確信度は「明確」にとどめる。

敗者の光: 家族の車の取り合いという痛みは実在し、LINEトークへの自然な接点設計（予約をトークから完結）はUX的に筋がよい。

痛みの強さ×頻度で kotolog が勝る。「言った言わない」は家族の決めごと全般（学校行事・申込期限・医療方針・大型出費）で繰り返し発生し、後から検索したいニーズが明確。kurumaban は車を複数人が取り合う家庭限定で発生頻度が低く、Googleカレンダーの共有カレンダーで80%代替できてしまう。保守面では kurumaban は外部依存が少ないが、kotolog の#タグ台帳もシンプルな Firebase+LINE Bot 構成で月2h以内に収まる可能性が高い。競合差別化でも「決めごとに特化した家族内wiki」というポジションは汎用カレンダーアプリとの差が立ちやすく、月300円の支払い意思は「トラブル防止ツール」として説明可能。配布面もLINEグループへの招待URLで検索なし導線が成立する。

敗者の光: kurumaban は問い合わせ負荷がゼロに近い（ルール設定後は完全自走）点で保守の軽さが際立っており、MVP開発コストが最小で済む。

「今日の夕飯に何を使うか」を決める瞬間、冷凍庫の扉を開けるたびに「あれ、これいつ入れたっけ」と詰まる体験は週3〜5回レベルで繰り返す。reitoko はその痛みに直撃し、段マップ＋経過日数という最小UIで「出すべきものを今日のうちに見つける」ことに特化している。ielog は家電・家具・日用品ストックの台帳という概念は正しいが、「寿命管理」を能動的に記録し続けるモチベーションが続かない。冷蔵庫の賞味期限アプリと同じ罠で、初期入力コストが高く、かつ通知が来るまで開かないため更新が止まる。競合面では ielog は「NotionやAirtable的な汎用DB」で代替されやすく差別化が薄い。reitoko は「冷凍庫の段という物理レイアウトをそのまま画面に再現する」点で既存の食材管理アプリ（FoodBank等）と明確に異なる。保守はどちらも外部依存が低く軽いが、ielog は家電寿命データの更新問い合わせ（「この機種の想定寿命は?」）が発生しうる点でやや重い。配布面は子育て世帯・自炊層のインスタやレシピ系コミュニティ（クラシルフォロワー等）に短い動画1本で刺さるreitoko が現実的。

敗者の光: ielog は「フィルター交換忘れ」「保証書を探す手間」という家持ちなら必ず1度は経験する痛みを突いており、初回入力さえ済ませば通知で価値が出るため、入力コストを下げる工夫（QRスキャンや品番OCR）を加えれば競争力が出る。

reitoko（冷凍庫マップ）は「タベキル」「Stamp冷蔵庫」「冷蔵庫食材管理くん」など無料〜基本無料の既存アプリが直撃している。いずれも冷凍庫の食材と経過日数を管理する機能を持ち、500円を支払わせる差別化軸（段ごとのビジュアルマップ）は体験として弱い——「どこに何があるか」は冷凍庫を開ければわかり、アプリへの入力コストが痛みより先に来る。対してielog（いえログ）は、給湯器・エアコン・フィルター・消火器等の交換どきを忘れてトラブルが起きるという「数年に一度・気づいたら手遅れ」型の確実な痛みを狙う。「トリセツ」アプリは取説管理が主であり寿命/交換通知には非対応で、完全な競合は確認されなかった。保守面でもielog は外部データ依存がなく月2h制約に収まりやすい。ただしielogも「そもそも入力するか」という登録摩擦が弱点で、配布経路（住宅系コミュニティ・新築購入層への導線）の設計が勝敗を分ける。

敗者の光: 冷凍庫という空間を「段マップ」で可視化するインタラクションの発想は直感的で、UI差別化の方向性自体は正しい。

reitoko は「冷凍庫を開けるたびに奥の食材の存在を忘れる」という週次〜月次で繰り返す実痛みに直撃し、食品ロスの罪悪感という感情的動機で500円の支払いを正当化しやすい。「段ごとの視覚マップ」はバーコードスキャン型の既存競合と切り口が異なり、料理系インスタ・節約系コミュニティという検索に依存しない具体的な配布経路もある。外部データ依存がゼロで月2時間以内の保守に収まる可能性が最も高い。ielogは「買ったら登録する」という継続摩擦が致命的で、期限通知だけなら無料リマインダーで代替されてしまう点を800円では崩せない。

敗者の光: ielog は「家じゅうのモノの寿命を一元管理したい」という潜在ニーズを正確に捉えており、持ち家オーナーが増えるほど需要が育つ中長期的なテーマを持っている。

ホシドキの痛みは「朝7時に洗濯機を回したが、11時に雨が降り始めて布団がびしょ濡れになった」という具体的・繰り返し性の高い失敗体験に直結する。頻度は週3〜7回（毎洗濯日）で、失敗コスト（乾かし直し・布団カバー洗い直し）が可視化しやすい。配布面もiOS天気ウィジェット層・主婦コミュニティ・洗濯機メーカーのSNSアカウントへの投稿で検索なしに刺さる経路がある。競合は「Yahoo天気の降水確率」だが、洗濯指数に特化したウィジェット形式で常時可視化する体験は代替されていない。一方、手入れどきは「包丁を研いでいない」という痛みが頻度・緊急性ともに低い——気づいた時はもう研いだ後か、あるいは何年も気にならずに使い続ける。500円を払う動機となる「今日まさにそれで困った」という即時性がなく、インストール動機が弱い。競合として「Notion・スプレッドシートの自作管理表」で賄えてしまい、差別化が難しい。保守面では両案とも軽いが、気象APIの利用制限・料金変動はホシドキのリスクになり得る。それでも频度と痛みの鮮明さで差がつく。

敗者の光: 「手入れどき」は道具ケアの習慣化という文化的に価値ある体験を狙っており、革靴・自転車好きのコアコミュニティ（RedditのR:goodyearwelt等）への刺さり方は検索なし配布の面で一定の現実性がある。

hoshidoki は「はれほす」という直接競合が App Store に既存し、洗濯指数・ウィジェット・ロックスクリーン対応まで無料で完備している。ウェザーニュースも同機能を標準提供しており、既インストール済みユーザーが追加導入する理由がなく、スキル獲得枠として出しても差別化の根拠がない。togiban は「道具の手入れ周期管理」に特化した直接競合が見当たらず、Apple 標準リマインダーで代替できるが「道具ごとの推奨周期を知っている」点が差別化になる。「気づいたら革靴がひび割れていた・包丁が鈍り切っていた」という後悔体験は実在し、道具好き・ものを長く使いたい層に 500 円の支払い意思を説明できる。外部 API 依存がなく道具データ（周期テーブル）の管理のみで月 2h 以内の保守制約にも収まる。

敗者の光: 「今日干せるか」という毎朝の判断ニーズは実在しており、痛みの頻度としては評価軸上で最も高い部類に入る。

hoshidoki はYahoo!天気・ウェザーニュースが「洗濯指数」「布団干し指数」ウィジェットをすでに無料で提供しており、差別化の余地がほぼない。加えて気象APIへの外部依存が保守の最大リスク——無料枠超過・仕様変更で突然サービスが止まるシナリオが月2h保守の想定とは相性が悪い。togiban は外部APIを持たず、道具×周期のマスターデータが静的なため保守コストが構造的に低い。痛みは「気づいたら劣化済み」という潜在型で強度はやや低いが、既存代替（Todoアプリ+手動リマインダー）を専用UIで上回る体験余地があり、道具ケア意識の高いサブコミュニティ（自転車・料理・革製品）への直配布経路を設定できる。500円買い切りは回収に時間がかかるが、保守ゼロに近いぶんランニング損失もない。iOS Widget + ローカルデータ設計のスキル獲得価値も明確。

敗者の光: hoshidoki はiOS Widget開発と気象データ計算を組み合わせた実装スキルとして習得価値が高く、スキル獲得枠としての目的は明確に達成できる。

痛みの頻度・強さで sakuhin が上回る。osagari は「おさがりを渡せる人がいる家庭」という条件付きで成立するが、現実には年1〜2回の衣替えタイミングにしか使わず、LINEのやりとりで現状も回っている。対する sakuhin は「子供が持ち帰る作品を捨てられない・でも増え続ける」という、核家族なら必ずぶつかる週次〜月次の痛みで、解決できていない人の比率が高い。競合面でも osagari は「メルカリで検索→フリーコメントで管理」「LINEアルバムで写真だけ共有」で実質代替されるが、sakuhin の「学年タイムライン＋フォトブック出力」は Google フォト等では年度という軸の整理と印刷まで一気通貫できておらず差が残る。配布面は両案とも検索流入に依存しにくいが、sakuhin は「卒園・卒業シーズン前のPTA・保育園コミュニティ」や育児系インスタアカウントの実需投稿に乗りやすく具体経路が見えやすい。保守は sakuhin の印刷連携（外部プリント業者API依存）がリスクだが、初期はフォトブック非推奨業者へのDeepLink誘導のみに絞れば月2h制約内に収まる。osagari はサイズ管理DBのスキーマ変更や「渡した先の記録整合性」でじわじわ問い合わせが増える懸念がある。

敗者の光: osagari は「渡す相手が決まった瞬間の達成感」という感情的な価値点が明確で、家族グループ内限定SNSとして設計し直せばエンゲージメントが見込める。

sakuhin（こども作品アーカイブ）は「子供の絵・工作を学年タイムラインで管理したい」という痛みが実在し、頻度も年間を通じて継続する。競合としてMUSEUM（ミュージアム）が2024年から子ども作品特化のフォトブック注文に対応しており、直接競合として強力だが、「学年タイムライン」という軸での整理×年度末フォトブックという体験設計で差別化余地はある。印刷課金は定番SaaSとの組み合わせ（しまうまブック等のAPI連携）で保守コストを抑えられる。対するosagari（おさがりまわし）は「親族間おさがりの行き先管理」という痛みの頻度が低い——子供服のサイズアウトは年数回、かつ親族間の調整はLINE・Googleスプレッドシートで十分に代替できており、支払い意思600円を発生させるほどの固有の不便が薄い。おさがり専用アプリは検索上ほぼ存在せず、空白があるように見えるが、それは「需要がない」からであってユーザーが解決済み（LINEグループ+写真共有）の領域。osagariはLINEで完全に代替されてしまう。sakuhinもMuseum競合が強敵だが、少なくとも「払う動機の実在」と「印刷収益モデルの成立性」で一段上。

敗者の光: osagariはおさがり管理専用アプリとしての市場空白が確認できており、サイズ別在庫の視認性はLINEでは実現しにくい唯一の強みがある。

sakuhinは「Googleフォトで撮ったが学年別に整理できない、Nohanaで印刷したいが作品カテゴリ管理ができない」という両既存サービスの隙間を埋める。保育園から届く絵・工作が毎月増え続けるという痛みは実在し頻度も高く、年1回フォトブック注文というLTV設計で800円の買い切り以上の収益が見込める。配布も保護者LINEグループ・ペアレンティング系Instagramという検索非依存の経路が使える。osagariは親族間おさがりの行き先管理というニーズがLINEやメモアプリで代替されやすく、「送り出す側だけ入れても機能しない」という共有コスト問題が保守・継続利用の両面で重くなりうる。

敗者の光: osagariはサイズアウト目安の算出と回送中ステータスの可視化というUI設計が具体的で、捨て場のないおさがりの流れを一元管理するコアバリューは明確に言語化されている。

otayoriは「明日提出のプリントをホーム画面に出す」という痛みが週2-3回・親なら誰でも経験する高頻度かつ実在の不便で、撮影+手入力期限+ウィジェットという設計がOSカレンダーと微妙に差別化できる。対してmimamoriの痛みは深刻だが、発生頻度は月単位で継続課金の価値を毎日感じさせにくく、既読付き共有ログに特化したアプリ（家族ノート等）が先行する競合帯への参入かつ、当事者がSNSで発信しない文化圏ゆえ「検索なしで届ける具体経路」が構造的に見つかりにくい。さらにリアルタイム家族同期にはサーバーが必要で月2h保守制約と相性が悪い。otayoriは外部依存なし・子育てインスタグループLINEで自然拡散でき、副業単独で回る構造として評価が上回る。

敗者の光: mimamoriは「誰かが通院記録を持っていて他の兄弟が知らない」という情報断絶の痛みを正確に捉えており、既読+申し送りの設計方針は本質を突いている。

otayori（学校プリント管理）は競合が致命的に飽和している。「プリゼロ」「おたよりクリップ」「おたよりポケット」「ポストック」が既にApp Storeに存在し、撮影→期限管理→ウィジェット表示というコア体験をほぼそのまま提供している。とりわけポストックはAI自動整理まで無料で出しており、月200円を取る差別化根拠が見当たらない。「提出期限だけ手入力」という不便さの解消がotayoriの売りなのに、その手入力すら他社がAIで代替しているため、後発で有料に設定するのは支払い意思の獲得が極めて困難。一方mimamori（みまもりノート）は、服薬リマインダー単体（お薬ノート等）や生死確認系（みまもるん等）は存在するが、「きょうだい間の申し送りと既読確認」という"ケアの引き継ぎ"に特化したアプリは現状見当たらない。「母が受診した、次は兄が連れていく」という役割交代の瞬間に情報が途切れる痛みは月次・週次で繰り返し発生し、LINEグループでは埋もれ、服薬管理アプリでは親の服薬側の記録が主眼で兄弟の申し送り視点がない。配布面はApple 家族共有グループやレビュー依頼を通じた口コミが現実的で、ターゲットが30〜50代の働く子世代という課金層と一致する。保守は外部データ依存ゼロ（ユーザーが入力）のため月2h以内に収まりやすい。競合の隙間は小さいがotayoriに比べれば明確に存在する。

敗者の光: 「学校プリント×提出期限」という痛みの特定は正確で、解決すべき瞬間（あす提出の見落とし）のイメージが鮮明な点は評価できる。

mimamoriは「兄弟間でLINEに親の通院結果を毎回送り直す」という40〜50代特有の長期継続痛みを捉えており、tetoruやClassiのような公式プラットフォームが市場を侵食するリスクがない。一方otayoriは学校配布の公式アプリ普及によって「プリント管理」の需要ごと消滅するシナリオが現実的で、iOS WidgetKit APIの年次変更も保守コストを恒常的に発生させる。mimamoriはテキスト+日付の単純構造でサーバーコストも低く、問い合わせもUIシンプル化で抑制できるため、月2h保守の制約内に収まりやすい。

敗者の光: otayoriはホーム画面ウィジェットに「あす提出」を表示するUXが明快で、ママコミュニティの口コミ経路も具体的に描けている点が強い。

痛みの強さ×頻度でカゴパレが勝る。「掃除機を買い替えたい、でもAmazonの上位は全部スポンサー枠で信用できず、楽天・Yahoo・ヨドバシを3タブ開いて目で見比べている」という体験は週に1〜2回は発生し、しかもタブを閉じると比較が消える——この「比較の手間と揮発性」は実在する慢性痛だ。月580円という価格も「1回の比較ミス購入を防ぐ保険」として正当化しやすく、ヘビーEC購買層（年間数十万円使う層）には支払い意思がある。配布面もChrome Web Storeからの有機流入＋EC節約系コミュニティ（価格.com民・ポイ活Xアカウント）への口コミ経路が具体的に見える。競合（Keepa・価格比較サイト）は「安値履歴」特化で横断比較UIではなく、差別化余地がある。一方desksignはRaspberryPi＋E-inkという初期セットアップの重さがユーザーのドロップ率を高め、「ゴミの日をスマートホーム化したい」痛みはGoogle HomeやAlexaルーティンで無料代替されてしまう。15,800円のハード頒布は在庫リスクと問い合わせ対応が1人副業の保守コスト上限を超えており、保守の軽さ軸で大きく負ける。

敗者の光: desksignは「画面を見ない生活」という静的・受動的な情報摂取体験への欲求を正確に捉えており、E-inkの消費電力ゼロ・目に優しいという本質的メリットはスマートホームアプリでは代替不可能な体験差分を持っている。

kagopareは「Amazonスポンサー除去の無料拡張」と「ショッピングリサーチャー（無料〜月3,980円）」がすでに同じ痛みを解消しており、月580円を払う正当化根拠が成立しない。EC比較という行為自体の摩擦は「比較サイトへの遷移を1クリックにする」だけでほぼ解消されているため、差別化が機能レベルで消える。一方desksignは「ゴミの日を忘れた」「家族メモがLINEに埋もれる」という玄関・物理デバイスでしか解決できない痛みを狙い、かつ「買えばすぐ動くE-inkキット」という既製品がBOOTH・Switch Scienceに現状ほぼ存在しない穴がある。15,800円は子育て・同居家族世帯の実用ガジェット価格として許容範囲内で、Maker系即売会・BOOTH・Zenn記事からの流入は検索非依存で現実的。保守リスクは天気API・ゴミカレンダー更新だが初回ドキュメントに自治体CSV設定手順を含めれば問い合わせを構造的に抑えられる。

敗者の光: kagopareはEC横断比較という実在の痛みを正確に捉えており、記事連動による有機的な配布導線の設計思想は正しい。

「運用の番人」視点で決定的な差は保守コストと外部依存の質にある。desksign はハード頒布モデルであり、初期ファームウェア・天気API・ゴミの日データ（自治体ごとに収集ルールが違う）の継続更新が必要で、月2h保守上限を構造的に破る。購入者からの「うちの市のゴミの日が反映されない」「Wi-Fi設定どうするの」という初期セットアップ問い合わせが発生頻度的に無視できず、個人AI組織の1日30-60分稼働とは相性が悪い。対してkagopareの外部依存はEC各社のDOM構造変化のみで、スポンサー除去・比較ロジックはフロントエンド完結。breakageは集中管理できる。支払い意思は月580円×Chrome拡張という既存市場（Rakuten系拡張の課金実績）に乗れる。痛みも「検索するたびにスポンサーに欺かれる」という高頻度かつ毎回感じる実在の不便。一方desksignの痛み「玄関で情報を見落とす」は頻度は高いがスマホのウィジェット・家族LINE・Googleカレンダー共有で代替されており、差別化余地が薄い。kagopareの弱点はECサイトDOM変更のたびのパッチ対応コストと、比較しないユーザー層への訴求の弱さ。

敗者の光: desksignは「買い切りキット＋実物ハード」という課金形態が支払い納得感を生みやすく、一度設置すると日常の接触頻度が高いプロダクトである点が強い。

fukurowakeのユーザー（現金封筒やりくり派）は毎月初の振り分け・月中の封筒間移動・月末残高確認と月に複数回、同じ摩擦を繰り返す。「食費が足りなくなったので雑費封筒から500円移す」という操作を紙の封筒でやるたびに「デジタルで管理できたら」と感じる痛みは具体的かつ反復性が高い。既存の大手家計簿アプリ（Zaim・マネーフォワード）はキャッシュレス・銀行連携前提で現金封筒管理には無力であり、競合回避の穴が実在する。節約系Instagram・主婦ブログ・節約コミュニティという検索非依存の配布経路も具体的。一方bestbuyは「買ってよかったものを記録したい」という欲求がNotionや標準メモアプリで代替可能で、600円を払ってまで専用アプリを使う動機が弱く、年1回の年間ベスト誌面というイベント性も購買継続の根拠に乏しい。

敗者の光: 年間ベスト誌面の共有画像生成という体験は「手帖を見せ合う」SNS文脈と親和性が高く、拡散起点になりうる独自の差別化ポイントを持っている。

fukurowake は「袋分家計簿」「袋分け家計簿 - 予算と支出が見やすい」など複数の既存アプリと正面衝突する成熟市場で、封筒間の移動・残高可視化という核機能も競合が実装済みの可能性が高い。検索なしで届く配布面（節約コミュニティへの拡散）は存在するが、既存アプリのデータ・習慣を持つユーザーの乗り換えコストが高く700円の差別化根拠が弱い。対してbestbuy は「買ってよかったもの記録×年間ベスト誌面生成」という組み合わせで直撃競合が薄く、痛みの頻度は低いが「購入記録を視覚資産に変える」という行為はモノ好き・ガジェット好き層に刺さる一点突破がある。スキル獲得・ポートフォリオ枠として保守も軽い。

敗者の光: 封筒やりくりという実在の日常習慣をそのままUIに落とす発想は正確で、痛みの頻度と具体性では本対戦で最も明確だった。

fukurowakeは「毎月・毎週の家計管理」という高頻度の実務行動に刺さる。現金封筒管理者が電卓とメモで封筒間移動額を計算する瞬間は具体的な痛みで、Instagramの #袋分け家計 #封筒管理 タグコミュニティという検索非依存の配布経路が明確に存在する。保守は計算ロジックのみで外部依存ゼロ。bestbuyは「買ってよかったもの記録」という痛みが弱く（Amazonの購入履歴・Instagramのブックマーク・メモアプリで代替可能）、「年間ベスト誌面生成」という差別化機能もCanva等で代替されてしまい、600円を払わせる動機が成立しない。ただしfukurowakeも「現金封筒管理者がApp Storeで有料課金するか」という行動パターンに不確実性が残る点と、既存の「袋分け家計簿」系アプリとの外観差別化が問われる点は保留リスクとして残る。

敗者の光: bestbuyは外部API依存ゼロ・データ全ローカルという保守最軽量構成で、「年間ベスト誌面」という出力成果物が他の記録アプリにない具体的なアウトカムになっている点は固有の強みがある。

genjoが勝る核心は「痛みの非対称性」にある。引っ越し手続きリスト(hikkoshi)の痛みは「何をすべきか分からない」認知コストだが、役所・ガス・電気のサイトに手続き一覧はすでに存在し、Googleで「引っ越し 手続き チェックリスト」を1検索すれば無料の網羅リストが大量に出る。つまり既存の無料代替で9割足りてしまう。対してgenjo(げんじょう回復フォト)の痛みは「退去時に敷金を不当に引かれる」実害——数万〜数十万円の金銭損失で、頻度は低くとも痛みの絶対値が桁違いに大きい。500円の買い切りは「1万円以上戻ってくるかもしれない」対比で支払い意思が極めて高い。配布面も「引っ越し 敷金 トラブル」系のSNS投稿や不動産系コミュニティで自然に拡散されやすく、検索依存が低い。保守面ではhikkoshiの方が手続き内容の法改正・自治体差異のデータ更新が重く月2h以内の維持が厳しい。genjoはPDF生成+タイムスタンプ付き写真保全のみで外部API依存が薄く保守が軽い。競合はiPhone標準カメラ+フォルダ管理だが、「退去時証拠用に整理・PDF化・撮影日時を法的に見やすい形で出力」という一連の文脈設計が差別化として機能する。

敗者の光: hikkoshiは「ライフイベントの全体像を一度に可視化する」体験設計が優れており、設問フィルタで自分に無関係な手続きを除外するUXは既存の静的チェックリストにはない付加価値がある。

hikkoshi は「らくらくMOVING」「引越し手続きガイド」など複数の無料アプリが App Store に存在し、設問カスタマイズ・時系列並び替えまで既に実装済みの競合に正面衝突する。差別化の余地が薄く、300円の買い切りで乗り換えさせる理由をユーザーに与えにくい。対して genjo は「入居時に撮影した傷の証拠PDF」という使途に特化したアプリが検索では見当たらず、汎用カメラアプリ・標準写真アプリで代替しようとすると日時の改ざん否定・部屋ごとの整理・PDF出力・送付性がバラバラになる弱点がある。痛みの発生は退去交渉という高額な一発勝負（数万〜十数万円の敷金）であり、500円で証拠力を担保できるなら支払い意思は実在する。配布面は「賃貸物件検索アプリのレビュー導線」「引越し系Xアカウントへのシェア」で検索依存を下げられる。保守はカメラ・PDF生成のみで外部APIへの依存が最小限。敗者 hikkoshi の勝因たりえた唯一の強みは「繰り返しの高頻度」だが、競合過多がそれを打ち消す。

敗者の光: 引っ越し直後の手続き漏れという「頻度は低いが全員が通る」痛みを正確に捉えており、ターゲットの裾野が広い点は正しい。

genjoは「退去時に敷金を削られる」という金銭的痛みが直撃する瞬間に刺さる。入居時に撮影済みの証拠と退去立会いを並べる場面は1回限りだが、損失が数万円規模になるため支払い意思500円は即決レベル。競合はカメラの標準アプリだが「撮影日時つき・物件ごとに整理・PDF書き出し」がひとまとめになる手間削減は差別化として成立する。保守面はOSのカメラAPIとPDFフレームワークに閉じており、外部APIゼロ・データ更新不要で月2h枠に余裕で収まる。一方hikkoshiは手続き内容が自治体ごとに異なり、転出届の締切や公共料金の窓口名など「情報の鮮度維持」が定常コストになる。手続きの種類と自治体差分を漏らさず追い続けるのは個人副業の保守限界を超えやすく、かつ引っ越しまとめサイト・不動産会社配布の紙チェックリストという無料代替がすでに広域をカバーしている。

敗者の光: hikkoshiは「自分に関係する手続きだけを時系列で出す」設問フィルタのUXが明確で、情報過多の既存チェックリストへの本物の不満を捉えている。

otsukiaiの痛みは「前回いくら包んだか分からずに香典袋を前に固まる」という実体験が年に数回、人生の節目ごとに繰り返される。特に40代以上は親・会社・地元・配偶者側と複数コミュニティを抱え、相場のズレが恥になるためメモを自力管理している人が確実にいる。800円の買い切りは「恥をかかない保険」として支払い意思が成立しやすい。競合（家計簿アプリのメモ欄・手帳）は「人別に時系列で往来を追う」設計になっておらず、特化アプリに差別化余地が残る。配布面はApp Store「香典」「ご祝儀」検索で親世代が実際に探す。保守は完全ローカル保存なら外部依存ゼロ。一方houjiは「命日を忘れそうな遺族」の痛みは確かに強いが、初七日〜四十九日は葬儀社・お寺が紙で案内するため「自分で計算する場面」が実は少なく、需要の発生タイミングが人生で数回しかない。PDF300円の課金導線も「悲しみの渦中に課金UI」という体験摩擦が大きく、収益化が難しい。

敗者の光: houjiは命日起点の繰り返し年忌計算という明確な単機能で、縦書き案内状PDFという印刷文化に刺さる出力形式が具体的で良い。

otsukiai（おつきあい帳）は「慶弔ダイアリー」「香典帳」「贈答記録帳 Gift Recorder」という機能的に重複するApp Store既存アプリが複数存在し、800円の買い切りで差別化できる空白がない。"人別台帳×相場メモ"という着眼は正しいが、現時点で無料または低価格の代替で足りてしまう層に、新規アプリを検索させ購入させる経路が描けない。一方houji（ほうじカレンダー）は、無料Webツール（keisan.site・komaseなど）が計算機能を提供しているものの、「繰り上げ候補の提示」「縦書き案内状PDF（300円）」の組み合わせは既存ツールにない。喪主・施主が法要の日取りを決めて寺と調整し参列者に案内を送るという一連の作業の中で「日付確定→PDF生成→印刷」を1動線で完結させる価値があり、300円PDFの支払い意思は「印刷屋に頼むよりずっと安い」比較対象で正当化できる。保守面では宗派ルール（繰り上げの曜日・地域慣習）の更新が重みになり得るが、基本ロジックは変動が少なく月2h以内に収まる見込みが高い。配布面も「葬儀社・寺のLINE公式アカウント連携」「Googleで法要名+計算で流入」という複数経路が具体的に描けるため、検索依存を完全に脱せなくとも到達可能性がotsukiaiより現実的。

敗者の光: otsukiaiは「人別往来台帳」という着眼が鋭く、香典とご祝儀を同一人物の時系列で追う需要は実在する。

houjiは「命日から四十九日・一周忌・三回忌をいつ設定するか、繰り上げはどうするか」という喪主が葬儀直後に必ず直面する痛みを捉えており、ミスが許されない場面ゆえ真剣に使われる。案内状縦書きPDF300円は、業者依頼なら数千円かかる文脈で支払い根拠が明確で、無料ツールでほぼ未カバーの機能差別化がある。葬儀社・寺院のQR経路という検索に頼らないオフライン配布面も現実的。対してotsukiaiはiOSネイティブ開発とバージョン追従という継続保守コストがあり、「香典帳」カテゴリは無料競合が多数存在し、SNSでシェアされにくいジャンルで検索非依存の配布経路が描きにくい。

敗者の光: otsukiaiは「香典・ご祝儀・中元歳暮を同一台帳で管理する」という統合軸が40代以降の実需に刺さっており、800円買い切りの課金設計もシンプルで迷いがない。

shohyoは「確定申告直前に領収書が出てこない・税理士に渡せる形式がわからない」という年次の巨大な痛みを捕捉しており、税理士コミュニティ経由という検索なし配布経路も現実的。receiptpostは仕訳出力がfreee/マネーフォワードと完全に重複し、GASのOCR精度問題とルール辞書保守という二重の負荷があり、価格帯が変わらない既存SaaSで足りてしまう層が多い。

敗者の光: LINEというゼロインストール配布面は最大の強みで、スプレッドシート出力との親和性も高く、家計管理の入口として別ターゲット設定なら活きる可能性がある。

receiptpost（レシートポスト）は「家計のレシートをスプレッドシートに仕訳」という用途で、Zaim・マネーフォワードME・OsidOriが無料〜月480円で同一の痛みをすでに解消している。スマホネイティブアプリとしてOCR精度・UI・連携の完成度が高く、LINE+GASという実装の複雑さと引き換えに得られる差別化がほぼゼロ。「ルール辞書で仕訳が並ぶ」は既存アプリのカテゴリ自動振り分けと機能的に等価で、支払い意思を持たせる固有の価値を提示できない。一方shohyo（証憑ポケット）は「税理士に渡せるZIP+CSV書き出し」に用途を絞っており、freee・マネーフォワードクラウド・弥生が競合になるものの、それらは月額1,000円以上の会計ソフト全体での課金が前提であり、「写真整理と書き出しだけシンプルにやりたい・税理士任せの個人事業主」という層への月400円の軽量解として差が出る余地がある。ただし競合の壁は厚く、優位性は限定的なため確信度は「明確」止まり。

敗者の光: LINE という既存インフラを配布面として使う発想は理にかなっており、アプリインストールの摩擦を下げる点で検索不要の配布経路として評価できる。

receiptpostは「仕訳まで自動化」を売りにするが、OCRの読み取りエラー訂正・勘定科目のルール辞書メンテナンス・LINEのAPI仕様変更対応という三重の保守負荷が月2h制約を容易に超える。税理士や青色申告ユーザーが本当に詰まる瞬間は「仕訳が合っているか不安で確認する」ではなく「月末にレシートを探し回って束ねる・税理士に渡す形式に揃える」であり、shohyoはその痛みに直射する。FirebaseとiPhoneカメラの組み合わせはOS標準OCR（Vision API）で入力手段として使え、ZIP+CSV書き出しは仕様が安定していて外部依存が少ない。確定申告・税理士提出という年次イベントへの支払い意思も「整理コストから解放される」文脈で月400円は通りやすい。配布面はfreee/マネーフォワードユーザーのコミュニティやnote記事経由の自然導線を取れる。

敗者の光: receiptpostはLINEという既存の生活動線に乗る配布面の現実性が高く、スマホ操作に慣れない個人事業主層への到達経路として具体的な優位がある。

kimegotoが刺さるのは「打ち合わせ中に決まった瞬間、話の流れを止めずにマークしたい」というビジネスパーソンの切実な場面で、痛みの頻度は週に何度もある。議事録ツール（Notion・miro等）は「後で書く」前提の設計なので、「決まった瞬間だけを即座に拾う」という目的とは競合しない。メニューバー常駐×ワンタップという体験の自然さも高い。一方teikeiは「同じ文を何度も打つ」頻度は実在するが、iOS標準のテキスト置換（設定 → 一般 → キーボード → 文字置換）で無料・ノーアプリで足りてしまう層が多く、500円でも差別化の説明コストが重い。配布面でもキーボード拡張は「知ってて探す人向け」でApp Storeの自然流入に依存しがちだが、kimegotoはMacユーザーのSlack/Discordコミュニティや生産性系ニュースレターでの口コミ伝播が具体的に描ける。保守面ではkimegotoはローカル完結でAPIなし・データ更新なしと最軽量。

敗者の光: teikeiは「変数付きテンプレート」というOS標準の文字置換では代替できない差別化要素を持っており、医療・不動産・法務など定型文の組み合わせパターンが多い職種では刺さり得る。

kimegoto が刺す痛みは「会議中に決まったことが散逸する」という反復性の高い実務痛で、かつ「AI要約ツール（Otter/Fireflies/Jamie）を導入するほどではないが手書きメモでは漏れる」という中間層が実在する。これらのAI系競合はLLM前提・録音要件・サブスク（月額$10〜$20）が重く、本憲法のLLM非使用・買い切り1,800円という軽量設計が明確な差別化軸になる。配布面もMacユーザー向けビジネスコミュニティ（Slack/ProductHunt/ツールまとめ記事）への差し込みが現実的で、検索依存を回避できる。一方 teikei（定型ポケット）は WordBoard・TextExpander Keyboard・Gboard個人辞書など iOS 上の直接競合がすでに App Store に複数存在し、500円の買い切りで支払い意思を引き出すには「変数差し込み」の優位が薄い。職種特化（営業/CS向け）の定型文管理ならSlack内ショートカットやNotion Templateで代替できてしまう層が多く、一般向けに広げると競合で足りると判断されるリスクが高い。kimegoto は競合がAI系に偏っており、非AI・軽量・瞬間キャプチャという切り口で空白地帯を狙える点でより勝算がある。

敗者の光: teikei は変数差し込み機能が既存定型文アプリにない独自性を持ち、「毎日同じ挨拶文を少しだけ変えて送る」営業・CS職の反復痛を確かに捉えている。

キメごとは「打ち合わせ中にワンタップでタイムスタンプを打ち、終了後に決定だけを拾い直す」という行動が、週複数回の商談・社内定例をこなす層の繰り返し痛みに正確に刺さっており、音声録音タイムスタンプという差別化軸は Granola 等の AI 議事録系（LLM 必須）が共通前提を外れるため競合回避できる。macOS メニューバー API への依存は年1回程度の確認で吸収でき、保守月 2h 以内の制約を守りやすい。対する定型ポケットは iOS 純正テキスト代替（設定アプリ・無料）と TextExpander が変数展開を含む同等機能をすでに提供しており、500円の支払い意思を引き出せる差別化が実質ない。加えて iOS キーボード拡張は毎秋の OS メジャーアップデートのたびにサンドボックス仕様が変動し、実機での動作確認が必須となるため保守上限を恒常的に超えるリスクが構造的に高い。

敗者の光: 定型ポケットは「カテゴリ分類＋変数プレースホルダ」という UX 設計が具体的で、ホワイトカラーの毎日のメール作業という高頻度の行動に乗っている点は評価できる。

「書きかけを放置して消える」痛みはiPhoneメモの死蔵下書きとして誰もが体験しており、頻度・切実さともに実在する。再提示というアクションが受動的に完成機会を与える体験設計が自然で、700円買い切りの支払い決断も軽い。一方、weeklyは「あとで読む」の未消化という罪悪感を扱うが、Pocket・Readwiseなど無料〜低額の競合で足りてしまう層が広く、「紙面フォーマット化」への課金動機が薄い。加えて、LLMなし縛りでの抜粋生成とメール配信チェーンの保守コストが月2h上限を超えるリスクが高く、サーバー依存ゼロで動くshitagakiの保守軽さとは対照的。

敗者の光: 「日曜朝に届く」という配信タイミングの設計は習慣トリガーとして良く、メール配信形式はストア審査リスクを回避できる点で副業運用に向いている。

週めくりリーダーは2026年時点でReadless・Instapaper・Readwise Readerが同機能を無料〜低額で提供しており、月300円の支払い意思が成立しない。加えてメール配信インフラとコンテンツ取得APIの保守が月2h制約を超えるリスクが高い。対して下書き熟成庫は「時間経過で再提示」という機能がiOS標準メモ・Notion・Bearのいずれにも存在せず、note・X発信層の「書いて放置」または「勢いで投稿して後悔」という毎日繰り返す具体的痛みに刺さる。700円買い切りはライタークラスタへの説明が1文で済む価格帯で、外部API非依存のローカル完結設計なら保守も軽い。

敗者の光: Pocket廃止後の難民需要という実在のトリガーを捉えた点は評価できる。

weeklyは「あとで読む」の蓄積という痛みは実在するが、コンテンツ取得にPocket/Instapaperなどの外部サービス連携が必須で、各サービスのAPI仕様変更・認証切れが月2h以内の保守制約を容易に超える。メール配信インフラ（SendGrid等）も外部依存の追加層になる。さらに月300円サブスクは「整理できていない自分への罪悪感解消サービス」に対して解約動機が高く、チャーン管理が継続的な問い合わせ負荷になる。対してshitagakiはiPhoneローカル完結が基本構造であり、外部API依存がほぼゼロ。「書いた日時を記録してX日後にリマインド」という機能の核心はローカルDB＋通知だけで実現でき、データ鮮度維持コストが発生しない。買い切り700円は「過去の自分の言葉に再会する瞬間」というはっきりした価値提供で、noteやXへの下書きを抱えるアウトプット系ユーザーに刺さる具体的な痛みがある。Notionの定期リマインドやAppleメモでは「意図的に寝かせて再提示」の設計思想がないため競合で代替しにくい。App Store経由の配布でも、「下書き 熟成」「書きかけ メモ」など情報収集目的でなく整理目的のキーワードで内部検索流入が期待できる。

敗者の光: weeklyは「日曜朝に読む紙面体験」というUXコンセプトが明確で、ハビット形成による解約抑制の発想は筋が良い。

shojo（賞状メーカー）は「年度末に賞状を作る担当者」の痛みだが、発生頻度が年1〜数回に留まり、かつWordのテンプレ＋差し込み印刷で代替できてしまう。100円/枚の課金ハードルを乗り越えるほどの切実さが薄い。一方sekigae（席替えルーレット）は「毎月または学期ごと」に繰り返す小学校担任の痛みで、前方固定・特定ペア離す・アレルギー配慮など条件が多い割に既存ルーレットアプリは条件制御が弱く、毎回Excelで手計算している担任は実在する。頻度が高いほど500円買い切りへの納得感が上がり、「4月に一括で払えば1年ずっと使える」という正当化がしやすい。配布面は教員向けX・小学校教員のnote・Pinterestの掲示板コミュニティ経由が現実的で、検索なし拡散の経路が描ける。保守もルールロジックさえ固めれば外部データ更新なし・問い合わせも設定UIで吸収できる。

敗者の光: shojoはCSV一括差し込みで枚数が多い表彰に価値があり、習い事教室運営者という明確な有料ターゲット層が存在する点は強い。

席替えルーレット（sekigae）は「席替えメーカー（sekigae.jp）」がほぼ同一機能をすでに無料Webアプリで提供しており、条件付き配置・ランダム配置ともカバー済み。先生がわざわざ500円買い切りを選ぶ理由を作れない。配布面も教員コミュニティへのリーチが難しく、App Storeには「Let's席替え」等の先行アプリが複数ある過密地帯。対して賞状メーカー（shojo）は、Canva・Word差し込みで「できる」ユーザーが既にいるものの、「CSV一括で複数受賞者を量産・即PDF印刷」というペインは保育士・習いごと講師・小規模社内担当者に実際に生じており、そこへの最短導線がまだ弱い。痛みの発生頻度は低い（年数回）が1回あたりの作業苦痛は高く、1枚100円の少額決済は心理抵抗が低い。保守も静的テンプレート＋差し込みエンジンで外部依存が薄く月2h以内に収まりやすい。配布面は「保育士・幼稚園教諭向けInstagram/Pinterest」「習いごと先生コミュニティ」と具体経路が描ける点で sekigae より有利。

敗者の光: 「せきがえルーレット」は痛みの発生頻度（学期ごとに必ず来る）と操作主体（先生1人）が明確で、プロダクト設計の的が絞りやすい点は優れている。

sekigaeは「前方固定・特定ペアを離す」という条件付き席替えという、既存のシンプルなルーレットアプリやExcelマクロが苦手とする要件を正面から解決する。担任が学期3〜4回・習い事教室が月次で直面する作業で、頻度がshojo より高い。外部API依存がなくロジックはクライアントサイドで完結するため月2h以内の保守制約に収まる。shojoはCanvaテンプレート＋Google Docs差し込み印刷の組み合わせで代替可能な領域が広く、低頻度（年4回）なのに月サブスク課金は合理化しにくい。さらにPDFレンダリングの依存更新とテンプレート追加要望の問い合わせが継続的に発生し、保守コストが個人運用の上限を超えやすい。

敗者の光: CSV一括差し込みによる量産機能は実在の需要を捉えており、教育系Instagramやちびむすドリル近傍のコミュニティで口コミ拡散できる配布面の具体性がある。

shiftban の痛みは「シフト希望の収集→確定→周知」という毎週または隔週で繰り返す実務で、店長が LINE・Excel・ホワイトボードを行き来して30分以上消費する場面が想定できる。頻度（月4〜8回の締め作業）×痛み（不足コマに気づくのが遅れてギリギリで人を探す）の積が大きく、月500円を店舗が払う根拠として「自分の時間代」が明確に成立する。一方 gessha の痛みは実在するが、月謝袋の管理は月1回・数十件という頻度で、スプレッドシートや LINEメモで代替できてしまう教室オーナーが多く、支払い意思の壁が高い。競合面では shiftban も「tes-work」「シフオプ」等があるが、それらは中規模以上向けで初期登録コストが重く、5〜15名規模の個人店が「LINEの延長」として使える黒板1枚の設計は差別化余地がある。gessha は既存の「コドモン」「Clas」等の月謝管理機能が無料プランで対応しており、競合で足りてしまうリスクが高い。保守は両案とも軽量だが、shiftban は LINEの仕様変更（Messaging API）が外部依存として残るのが唯一の弱点。

敗者の光: gessha は競合の少ない「個人教室」というニッチを狙っており、月謝袋という文化的文脈に合わせたUXの設計コンセプト自体は共感を呼びやすい。

gessha は「できた！DEKITA（15名まで無料・3,500校突破）」「Sgrum」「生徒管理メモ帳（App Store無料）」という先行無料アプリが月謝管理を十分にカバーしており、月謝袋風UIという体験差分だけではPWA月500円の課金根拠にならない。配布面もApp Store外で教室先生層に届ける具体経路が弱い。一方shiftban は Airシフト・oplus 等の競合が「管理者がツール導入→スタッフにアカウント作成させる」モデルの摩擦を持つのに対し、LINE完結でスタッフ側の導入コストをゼロにできる構造的差別化がある。シフト希望集め→転記作業は週次で繰り返す店長の実痛みであり、5〜10人規模の店長が月500円を払う意思決定は「Airシフトは大げさ・Excelは面倒」という既存の隙間に刺さりやすい。ただしLINE Messaging API依存のWebhook保守が月2h枠を超えるリスクは残る。

敗者の光: 個人教室の先生という支払い主体が明確で、振替管理という月謝帳固有の痛みポイントの特定は鋭い。

gessha（おけいこ月謝帳）が勝る理由は保守の軽さと競合の薄さの組み合わせにある。ピアノ・習字・そろばん教室の先生が月末に月謝袋をチェックして「山田さんまだ払ってない」と気づく瞬間は実在し、Excelで代替するには操作が重すぎ、LINE家計簿等の汎用アプリは振替授業の概念を持たない。データ更新は生徒マスタ変更のみで外部API依存もなく、月2h保守制約にほぼ抵触しない。配布面もピアノ教室コミュニティ（Facebook群・Twitterピアノ垢）やPTA伝達網でリーチできる。一方shiftban（シフトの黒板）は、店舗オーナーが「不足コマ警告まで出るのに月500円」を払う合理性が、すでにLINEグループ＋Notionや無料のShiftboard/らくしふで9割満たされる競合環境に阻まれる。加えてLINE OfficialAccount連携は審査・Messaging API維持のコストがあり、個人保守の月2h枠を食いやすい。シフト問い合わせ（「先週の変更どうなった？」）は頻度が高く問い合わせ負荷も見込まれる。

敗者の光: シフト黒板UIのビジュアル表現は「黒板1枚に全情報が収まる」という認知負荷低減コンセプトが明確で、デモのチョーク風デザインとマグネットチップの差別化軸は独自性がある。

kanmon の痛みは「大会当日の朝、関門時刻と目標ペースが頭の中でバラバラのまま走り始める不安」という具体的瞬間に集約される。フルマラソン完走者のうち初〜中級者の30〜40%が関門アウトのリスクを抱えており、その層は大会前夜にスプレッドシートで手計算しているか、そもそも諦めている。リストバンドに印刷できるPDFという形式は「走りながら確認する」という行動に完全に合致しており、競合（Garmin Connect / pace calculatorサイト）は数値は出せても関門時刻と重ねたラップ表PDFをリストバンドサイズで出力する機能がない。1大会300円は「完走メダルがかかっている」という心理的プレミアムがあり支払い意思が高い。配布経路はマラソン大会のSNSコミュニティ・ランナーズ系noteで検索なしに届く。keiko は稽古録という習慣ツールで痛みは「道場ノートが紙でバラバラ」程度の緩さ。武道・茶道人口は限定的で、既存の汎用日記アプリ（Day One / Notion）や専用アプリとの差別化が薄く、600円の支払い意思を引き出す切実さに欠ける。

敗者の光: keiko は「昇級年表を時系列で見る」という体験が既存汎用ツールにない独自価値を持っており、継続課金でなく買い切りで保守負荷を抑えた設計は正しい。

kanmonは「carb.jpやu-sol等の無料ラップ計算ツール＋手書きリストバンド」という既存フローで実質的に代替されており、300円の支払い意思の根拠が「PDF化の手間削減」という薄い理由に依存する。加えて各大会の関門データを年次更新する保守負荷が月2h枠を慢性的に圧迫し、大会中止・コース変更のたびにメンテが発生するリスクがある。keikoは武道・茶道ジャンルに縦割りの既存アプリ（MatchaNote / 弓道的中管理）が存在するが、「複数稽古事を横断した昇級年表の時間軸可視化」という切り口に残余があり、外部データ依存がなく保守が最軽量で、週次稽古に紐づくため使用頻度でも上回る。

敗者の光: kanmonは「大会直前にランナーが関門とにらめっこする瞬間」という実在の緊張感を正確に捉えており、ターゲット層への配布経路（runnet掲示板・ランニング系X）の解像度が高い点は評価できる。

kanmon は「大会当日に手首で関門通過時刻を確認したい」という痛みはリアルだが、プリセット拡充を求める問い合わせが発生した瞬間に「大会別関門データの継続入力・更新」という保守業務が固定コストになる。ユーザー自己入力に振り切れば保守は軽いが、そうすると無料のペースアプリやRunNetの公式ペース表との差別化根拠（=300円を払う理由）が薄れる構造的矛盾がある。keiko は外部依存がなく段位体系の変更対応のみで月2h以内に収まり、稽古録データが蓄積されるほどロックインが高まるため保守負荷と継続利用の関係が健全。iOSネイティブ開発スキルの獲得はポートフォリオ価値として最も汎用的で、既存の武道特化アプリが「昇段年表の静かな視覚化」を実装していない隙がある。

敗者の光: kanmon は「大会当日 × 関門 × 手首」という使用文脈が具体的で、課金タイミング（大会直前）と心理的動機（失格回避）が一致しており支払い意思の設計が鋭い。

釣り人は「今日あの仕掛けで釣れた」「ハリスが何本残ってるか」を釣り場でリアルタイムに確認・更新したい。消耗品の切れによる釣行機会損失は痛みが大きく、道具箱を開けるたびに「あれがない」を繰り返す頻度も高い。既存の釣りアプリ（つりタウン・キャスティングアプリ等）は釣果共有・店舗情報が主軸で、「自分だけの仕掛けレシピ×手持ち在庫の組み合わせ管理」は手薄。一方sitelayoutは、キャンプ設営の配置を考えるのは年数回・サイト着地後の数十分だけで、実際はLINEに写真を送り合うか口頭調整で済んでしまう。積載チェックリストは無料のメモアプリ・Notionテンプレートで代替され、800円の支払い動機を生む「これじゃないとダメ」な体験が弱い。tackleの保守は仕掛けDB更新が若干あるが、ユーザー自身が自分のレシピを登録する設計なら外部依存はほぼゼロ。配布はルアーメーカーSNS・釣具店コミュニティへのオーガニック投稿で検索依存を避けられる。

敗者の光: sitelayoutは「設営完了後に配置図を記録として残したい」というキャンプ記録ニーズを突ける点がユニークで、次回の自分へのメモとして一定の再利用価値がある。

sitelayoutは「妄想キャンプ」という同コンセプトの無料アプリがApp Storeに既存し、800円の有料アプリとして差別化する根拠がない。積載チェックリストは汎用メモアプリで代替できるため支払い意思が成立しにくい。tackleは釣り場で「この仕掛けの号数は何だったか」「ハリス在庫が何m残っているか」を即座に引き出したいという、釣行ごとに繰り返す実在の痛みをカバーしており、アングラーズ等の釣果記録系アプリが手を付けていない「仕掛けレシピ×消耗品在庫」の組み合わせに差別化余地がある。タックルに数万円を使う層は800円の障壁が低く、仕掛けデータをユーザー生成にすれば外部データ依存がなく保守も軽い。

敗者の光: 設営配置を視覚化したいという欲求は実在し、iPad縦画面でのドラッグ配置UIは体験として気持ちよく作れる素材がある。

tackleは「釣り場に着いたら昨日の仕掛けレシピが思い出せない・消耗品の在庫が見えない」という、釣行ごとに必ず発生する具体的な痛みを押さえている。仕掛けの組み合わせ情報をメモ帳やNotionで管理するには構造化が弱すぎ、既存の汎用代替で足りない穴がある。データをユーザー手入力のクローズドで完結させれば外部API依存ゼロ・データ鮮度維持コストゼロで、保守は月2h以内に収まる。sitelayoutはキャンプ設営配置図という発想は面白いが、iPhoneのフリーボード・GoodNotesの自由キャンバスで実質代替でき「専用アプリでなければできない」根拠が薄い。加えてキャンバス描画エンジンのiOSバージョン追従が保守リスクとして残り、月2h制約に対して構造的に不安定。

敗者の光: sitelayoutは積載チェックリストと配置図を1アプリで完結させる着想がシンプルで、データ持ち出しが不要な純ローカル構成なら保守負荷が極めて低い点は評価できる。

uedokiの痛みは「種袋に書いてある蒔き時が北海道基準で、うちの畑（神奈川・中間地）では何月なんだ」という毎シーズン繰り返す実務的な詰まり。家庭菜園人口は国内300〜400万人規模で、春秋の作付け期に集中して同じ疑問が繰り返し発生する。連作障害チェックは区画ごとに何を植えたか覚えていないという痛みで、ノートやメモで管理している人の置き換えになる。競合はNHK趣味の園芸アプリやGreenSnapだが、地域カスタマイズ×連作障害×種袋翻訳の三点セットをワンストップで出すものはなく、差別化余地がある。年300円の支払い意思も「失敗した苗代のほうが高い」という論理で正当化しやすい。保守はUIの季節更新と野菜データの軽い修正程度で月2h以内に収まる。hoshizoraは気象APIと月齢データの外部依存が常時あり、APIの仕様変更・レート制限・雲量データの精度劣化がそのまま体験品質に直結する。StarWalkやStar Chart等の無料アプリがウィジェット含めて既に「今夜の観測適性」を表示しており、差別化の核心である「光害×月齢×雲の三要素ひと目表示」は競合で概ね充足される。無料前提のためポートフォリオ価値は認められるが収益化の道が薄く、副業の経済的な意味では弱い。

敗者の光: 気象・月齢・光害という三変数を組み合わせた「今夜の星空スコア」のコンセプトは情報設計として明快で、ウィジェット一択の配布面選択がApp Storeの星空愛好家コミュニティとの親和性も高い。

hoshizora は「月齢×雲量×光害を統合してスコア1つにしたウィジェット」という体験が既存アプリに存在しない。Star Walk / SkySafariは星図であり今夜の可視性を前面に出す設計ではなく、Light Pollution Mapは雲と光害を重ねられるが「ひと目スコア＋ウィジェット」ではない。キャンプ系SNS・天文同好会Discordでスクリーンショットが自然に拡散する配布経路もあり、無料でも技術ポートフォリオとして回収できる。一方 uedoki は連作アラート付き区画管理をすでに備えた菜園プランナー・Farm Reco 等が無料で存在し、「種袋の翻訳体験」の磨き込みだけでは年300円を払わせる差別化根拠が薄い。

敗者の光: uedoki は「種袋の裏を自分の畑の日付に翻訳する」というコピーの解像度が高く、ユーザーの実際の作業痛みを正確に言語化できている点は評価できる。

uedoki の核は植付時期×連作チェックという静的DB で、気象 API など外部依存がゼロ。「一度作れば鮮度維持が不要」という構造は個人保守月2h 以内という前提に最も適合する。hoshizora は雲量・透明度の取得に気象 API が必須で、障害・利用規約変更・コスト変動リスクが月2h 枠を超えうる。加えて Clear Outside / Sky Tonight が月齢×雲×透明度を無料で統合表示しており、「無料の競合で足りてしまう」壁が高い。uedoki は区画連作マップとの組み合わせで既存アプリとの差別化余地があり、菜園コミュニティ SNS という検索外の配布経路も実在する。

敗者の光: ほしぞら指数は「今夜出かける価値があるか」をウィジェット 1 枚で答えるというコンセプトの切れ味が鋭く、iOS WidgetKit 習得というポートフォリオ価値も明確な点は評価できる。

chobaが解決する痛みは「社会人サークルの幹事が毎月の会費集金・出欠・立替を追うために費やす2〜3時間」という頻度も強度も明確な不便で、月300円の支払い意思は「幹事の時間コスト」と比べてほぼ抵抗なく生まれる。対してkininariの痛みは「運転中に気になった場所を後から思い出せない」という中程度の後悔感に留まり、SiriのリマインダーやGoogleマップの★保存で実質的に代替できてしまう——1,000円を払ってまで乗り換える理由を言語化しにくい。配布面もchobaはLINEグループ内で幹事が導入すれば全メンバーが強制的に使う構造で検索に頼らず済む一方、kininariはCarPlayユーザーという狭い層をApp Store経由で獲得する必要がある。

敗者の光: CarPlayという具体的な配布面を持ち、音声+位置情報+週末リスト化という体験の流れが一貫しており、保守負荷が最も軽い点（GPS・音声認識のみでAPI依存なし）は副業プロダクトとして非常に優れた特性。

kininari の痛みは「運転中に気になった店・場所を安全にメモしたい」という反射的・瞬間的な欲求で、頻度も週複数回起きる。CarPlay 対応の音声メモアプリは Auto Memo Recorder（$1.99 買い切り）が既に存在するが、「声でピン→週末リストに育てる」というワークフロー（場所タグ付き・週次リスト化）は未カバーで差別化余地がある。App Store という既存配布面を使え、保守もサーバーレス構成にすれば月2h 以内に収まる現実性がある。一方 choba は「社会人サークルの会費・出欠・割り勘を一枚に」という痛みだが、調整さん（月間800万人）・サークルスクエア（170万ユーザー・24年稼働）・E-ToMo・MiiT+ と無料の既存解が飽和しており、既存ツールで実務が十分に回っている。LINE チャネルでの月300円課金は、幹事が「自分のサークルにだけ新しい有料ツールを導入しよう」と決断する説得コストが高く、支払い意思を引き出す手前で止まる可能性が高い。choba は競合で足りてしまう典型ケース。

敗者の光: choba の「幹事一枚に集約する」というコンセプト自体は正しく、会費と出欠と割り勘が別ツールに散在する分断痛みを正確に捉えている点は評価できる。

chobaは「幹事が毎月LINEで個別に出欠を確認し、SpreadsheetとPayPayを行き来して会費と割り勘を管理する」という高頻度・高苦痛の実務を対象にしており、TimeTree・割り勘アプリ・Googleフォームのいずれも「三つをまとめて幹事ダッシュボードで見る」ユースケースを1ツールで完結させていない競合空白がある。配布面もLINEグループが既にある社会人サークルに対して「Botを追加するだけ」で届くため、検索不要の経路が現実的に成立する。対してkininariは、GoogleマップへのSiri音声ピン留め+リマインダーという無料代替が「8割のケースで十分」であり、CarPlayアプリ審査のゲートリスクと外部店舗データAPIへの依存（鮮度・コスト・問い合わせ対応）が個人副業の保守限界を超えやすい。

敗者の光: kininariは「運転中の一瞬の気づきを保存する」という体験のフォーカスが明快で、CarPlay×iPhoneの連携デモが視覚的に価値を一発で伝えやすく、ポートフォリオ映えする完成度がある。

bakers は「粉量が変わると全部計算し直し」という痛みが週次〜毎日発生し、かつ既存解がない。ホームベーカーが500g粉→700g粉に変えた瞬間、スプレッドシートや電卓で8〜12品目を手計算するか、紙メモを読み直す必要がある——この手間は毎回同じ箇所で発生し、解決した瞬間の感謝度が高い。一方 baisen は「再現性のために記録する」という行動自体がコーヒー愛好家の習慣として既にノートアプリ・Notion・専用の Roast.World や Barista.io で代替されており、800円の買い切り価格に対して「なぜこれで管理するのか」の説得力を出すのが難しい。配布面は baisen がコーヒーコミュニティ（#珈琲 / 自家焙煎Discord）で届きやすい反面、「豆→焙煎→抽出を一本でつなぐ」UXの差別化が弱く無料のノートで代替されやすい。bakers は製パングループ・レシピSNS（パンコミュ/cookpad）への投稿一枚でリーチでき、PWA のため App Store 審査不要で保守も軽い。競合は「パン 配合 計算」で出てくる簡易電卓サイトだが、比率保持＋スケール変換のセットで届くものは薄い。baisen は豆・焙煎・抽出の3軸管理の設計が複雑で、外部依存なし・月2h保守以内を守るためにはデータモデルの簡略化が必要になり、そのトレードオフが再現性の売りを削る可能性がある。

敗者の光: baisen は「豆・焙煎・抽出を一本の線でつなぐ」というコンセプトが明快で、自家焙煎コミュニティという届きやすいニッチが存在する点が強い。

bakersは2025年だけでLeaven・BakersScale・Baker's Percentageなど同機能の無料/安価アプリが複数リリース済みで、後発7番手が500円を取る差別化根拠を説明できない。一方baisenは焙煎プロファイル特化の既存アプリ（Roasty・焙煎タイマー）が温度グラフに集中している隙間を突き、「豆選定→焙煎→抽出を一本の記録線でつなぐ」ポジションは空白地帯として残っている。自家焙煎者は焙煎機に1〜10万円投じる層で800円買い切りの支払い障壁が低く、Instagram #自家焙煎・Xの焙煎クラスタというコミュニティ配布経路も具体的に存在する。

敗者の光: bakersはPWA構成で外部依存ゼロ・データ更新不要という保守の軽さが全候補トップクラスで、ポートフォリオ作品としての完成速度は際立って速い。

baisenは「先週の焙煎が再現できない」という自家焙煎特有の痛みに対し、焙煎プロファイルと抽出記録を一本でつなぐ競合空白が実在する。800円買い切りに対し、生豆・ギアに月数千円投じる層の支払い抵抗は低い。保守リスクである豆情報DBはユーザー入力完結で設計すれば鮮度維持コストを構造的に封じられ、外部依存ゼロ・月2h以内の制約を守れる。一方bakersは計算ロジックの保守は確かに軽いが、App Storeに既存の製パン電卓が複数存在し「それで足りる」層が多く、差別化の余地がUIとPWAの即時性という薄い勝負になる。

敗者の光: bakersはデータ更新不要・外部依存なし・問い合わせ最小という保守の完全なクリーンさが際立っており、運用負荷ゼロを最優先するなら最も安全な選択肢。

setori は「ライブ本番で譜面が迷子になる」という痛みを解く。ただし、このニーズを持つのはバンドマン・弾き語り勢の中でもセトリを紙や汎用メモ管理して不便を感じている層に限られ、市場は薄い。しかも GoodNotes / ForScore / piaScore といった汎用 PDF 譜面アプリが既にブックマーク機能で「セトリ順に並べる」用途をカバーしており、買い切り1,500円の価格で「専用アプリじゃないと解決できない」と感じさせるハードルが高い。配布面も「ライブハウスのコミュニティ」「バンドコミュニティ」は母数が小さく届かせるのが難しい。一方 metrolog が解くのは「今日の練習で何テンポ・何小節でつまずいたか記録したい」という日常反復の痛みだ。メトロノームアプリは Metronome＋・Pro Metronome など多数あるが、練習日誌として"テンポ×つまずき小節"を構造的に残せるアプリは存在しない。ギター・ピアノ・管楽器問わず「毎日練習する人が毎日使う」頻度の高さと、「昨日どこで詰まったか思い出せない」という反復する実痛みがある。700円は習慣化ツールとして払いやすく、保守も外部データ更新なし・ローカル完結で月2hの制約に収まる。配布面は「楽器練習 app」カテゴリのApp Store内検索でオーガニック流入が見込める。

敗者の光: setori は本番モード（画面消灯防止 + セトリ順自動並べ替え）が「ライブ直前の5分間」という極めてピンポイントな痛みを解いており、実際に体験した人のリテンション率は高いと思われる。

setori の痛みは「本番直前にセトリを組み替えて、譜面PDFが別アプリにバラバラに入っている」という実在かつ繰り返す状況で、ライブミュージシャンなら月複数回ぶつかる。競合は EasySetlist・Leadsheet・Set List Maker 等が10本以上存在するが、いずれも「曲の並び替え＋歌詞/コード表示」が主体で、「セトリ順に譜面が自動並列表示される」ことと「本番中に画面が消えない」を両立させたものは少ない。この2点を確実に実装すれば既存ユーザーの乗り換え動機になる隙間がある。一方 metrolog は「メトロノーム＋テンポ日誌」の組み合わせで、Music Journal Pro / Andante / Smart Metronome & Tuner がすでにほぼ同機能を提供しており、700円を払う理由として「つまずいた小節を残す」だけでは既存無料/低価格代替を超える差別化が見えない。また保守面では、setori は譜面PDFの読み込みさえ安定すれば外部データ依存がなく月2h以内に収まるが、metrolog は練習ログのバックアップ・デバイス移行の問い合わせが想定以上に重くなるリスクがある。

敗者の光: metrolog は「テンポと小節単位のつまずき記録を一画面で完結させる」という操作コストの低さが評価軸として誠実で、練習ログ自体への需要は実在する。

metrologの方が痛みの発生頻度が高い。セトリ管理はライブ本番時のみだが、テンポ記録の欲求は週3〜5回の練習ごとに繰り返す。保守コストでもmetrologが優位で、BPM+小節+日付のローカル記録はデータ更新も外部APIも不要、月2h以内に収まりやすい。setoriはforScore・Setlist Helperが「セトリ組んで譜面を並べる＋画面消灯防止」を既に包含しており、1,500円の支払い根拠を崩す既存代替が強い。metrologもModacityという直接競合があるが、日本語・シンプル・700円買い切りのポジショニングで差別化余地は残る。

敗者の光: setoriは「本番中に画面が消えてタッチし直す」という具体的な瞬間を射程にしており、痛みのリアリティとiPad横向きUIの完成度は高い。

nuirecipeはminne/Creema出品者の「同じものをまた作れない・原価がわからない」という販売行動に直結する痛みを狙っており、支払い動機が趣味層より明確に強い。配布面もコミュニティ内口コミが機能しやすく、iPhoneローカルのみで保守が最軽量。amimeはApple Watch所持という二重の絞り込みで母数が激減し、海外の段数カウンターアプリや100円の物理ロウカウンターとの差別化がリューズ操作だけでは薄く、watchOS追従という副業制約に重いコストも伴う。

敗者の光: amimeは「両手がふさがっている最中に手首で数える」という体験の自然さがユニークで、Apple Watch所持者の編み物層には刺さる可能性がある。

amime（あみめカウンター）はApple Watchのリューズ操作で「編みながら手を止めずに段数を数える」という痛みを解くが、競合は多い。Knit Row Counter・StitchTally・My Row Counter等が既にApple Watch対応済みであり、無料または低価格で機能的に重複する。それでも「リューズ1操作で±1」という物理インタラクションの差別化と、500円買い切りという価格設定はApp Store内でのニッチ占有が可能。編み物コミュニティ（Ravelry・ハンドメイドInstagram）という検索外の配布経路が実在し、熱量の高いユーザーが集まっている。一方nuirecipe（ぬいレシピ帳）は「自分の型紙・手順・原価を次も作れる形で残す」用途だが、Sew Help Me・My Patterns: Sew & Knit（2026年4月更新）・Sew Awesome 2等が型紙管理＋原価記録を既にカバーしており、無料ティアもある。手芸用途でのiPhoneノート代替（Notion・Craft・写真アプリ）まで含めると「なぜこのアプリが必要か」の説得が難しく、支払い意思の根拠が薄い。amimeは身体的インタラクションに絞った単機能なぶん保守も軽く、Apple Watch＋コミュニティ流入の実経路もある。

敗者の光: nuirecipeは「原価を記録して次回の見積もりに使う」という販売系ハンドメイド作家の実務ニーズを正確に捉えており、creema・minneコミュニティへの配布経路発想は正しい。

amime の痛みは「両手がふさがった状態で段数を数え間違えるたびに数十段解く」という身体的・反復的な実害で、頻度と痛みの強度が明確。AppleWatch + リューズという入力手段は編み物中の運針を止めずに操作できる唯一の形で、スマホ画面タップのカウンターアプリと物理的に差別化できる。競合（Knit Counter 等）はスマホタッチが前提で Watch 対応も音声前提が多く、リューズ操作で差別化できる余地がある。配布面は Ravelry・ニッターズコミュニティ・手芸 YouTube コメント欄などコミュニティ経由が使いやすく、検索なしで届く経路が具体的に描ける。保守もカウンターロジック単体でデータ更新ゼロ、外部 API 依存なし、問い合わせは「数字がリセットされる」系のバグ修正に限定される。nuirecipe は「次も同じものを作るために記録する」という痛みが実在するが頻度が低く（1アイテム完成ごと）、Notion・GoodNotes・専用の縫製ノートアプリで代替されており「600円払って専用アプリを入れる閾値」を超えにくい。型紙のスキャン保存は Files.app でも機能し、差別化点が薄い。

敗者の光: nuirecipe は「原価と手順を同一画面で管理する」という記録の粒度設計が具体的で、有料化よりコミュニティ向け無料ポートフォリオとして CoreData + CloudKit スキルの獲得枠にする判断は合理的。

ボドゲ棚は「ゲーム会の前日にLINEで持ちもの確認が流れる」という月1〜2回の具体的な幹事痛みを、所有管理・持ち寄り調整・勝率記録の3点で一本筋のユースケースとして解決する。PWAのURLシェアでインストール摩擦なし、BGGやゲームコミュニティという非検索経路が明確で配布面が現実的。日本語軽量の「ゲーム会幹事ツール」は競合空白地帯。対してcollectionは売り場での重複買い防止という痛みは実在するが、Memento DatabaseやDiscogs等の無料・高機能競合が趣味ジャンルごとに既に存在しており、汎用CSV対応という差別化では「何でも中途半端」に映りやすく、配布面も趣味コミュニティが分散して刺さる場所が定まらない。

敗者の光: 売り場での「これ持ってたっけ？」という衝動抑制の瞬間はリアルで、カメラ即登録+CSV出力というシンプルな設計は保守の軽さにつながっている。

collectionはmonoca・My図鑑・MyCollectionsがApp Storeで横断管理+CSV+写真をすでに無料または低額で提供しており、1,000円買い切りで逆転できる差別化軸が見つからない。対してbodoge の「幹事が持ち寄りを調整する瞬間」は既存の英語圏ボドゲ管理アプリ（BGG公式・BG Catalog等）がカバーしておらず、日本語PWAとして空白がある。痛みの発生場面が「ゲーム会当日の重複持ち寄り・所有確認」と具体的で繰り返し頻度も月1〜数回と十分。PWAのURL共有でゲーム会DiscordやボドゲカフェのLINEグループへ検索なしで届けられる経路が実在し、配布面の現実性でも勝る。保守は外部API依存を避ければゲームタイトルのデータ更新リスクも低い。

敗者の光: 「売り場で即答」という痛みの瞬間は感情的にリアルで、コレクター特有の所有欲と実用性が重なる着眼点は鋭い。

配布面の決定的な差が勝敗を分ける。bodoge はボドゲ会の幹事が「今週何持ってく？」と Slack/Discord で参加者に URL を貼る瞬間に自然に伝播する。検索不要で口コミ動線が成立する。一方 collection はレコードマニアや切手収集家に届ける経路がなく、コレクタービジネス向けの既存アプリ（Discogs・MyShows・独自 CSV 管理）で「ほぼ足りている」層が多い。保守面では collection が CSV エクスポートのみなら外部依存が薄いが、bodoge も PWA + ローカルストレージで同等に軽くできる。痛みの頻度は bodoge のほうが高い——ゲーム会は月1-2回開催され、幹事は毎回「誰が何を持ってくるか」を LINE で聞き回る同じ作業を繰り返す。600円の買い切りまたは無料で SNS シェア導線を作れば幹事という「1人が複数人に伝える」構造で自然な波及が生まれる。collection は「所有確認の痛み」は実在するが、売り場での即答ニーズは購入前の衝動であり月2-3回程度で頻度がやや低い。

敗者の光: collection は汎用性が高く「レコードでも切手でも同じ UI」という設計思想が保守コストを一定に抑える点で運用負荷は低い。

circlepost が勝る最大の根拠は「当日モードで列をさばきながらタップで在庫を減らす」という痛みの質と密度にある。コミケ・同人イベントのブースでは、頒布中の数時間に「あと何冊あるか」という情報が完売宣言・追加陳列・列案内に直接影響し、手計算やメモアプリでは品目が複数になった瞬間に破綻する。この痛みは強く・繰り返し発生し・汎用カウンターアプリでは「在庫バー + ペース予測 + 品目別管理 + イベント記録」の組み合わせを代替できない。一方、ensei は「遠征会計 + 半券コレクション」の組み合わせで差別化を図るが、会計管理は家計簿アプリのタグ機能で、コレクションは写真アルバムやNotionで代替でき、イベント後に落ち着いて記録する行動は習慣定着が弱い。支払い意思においてもcirclepostは「売上管理・機会損失防止」という業務的正当化ができ1,000円の根拠が立つが、enseiはエモーショナルな動機主体で700円の説得が難しい。

敗者の光: ensei の「半券コレクション × 遠征会計」の組み合わせはニッチなユーザーに強烈に刺さるコンセプトで、情緒的な価値訴求が明確な点は高く評価できる。

ensei（遠征手帖）は推し活支出管理・遠征サポートの既存アプリが複数存在しており、「推し活支出管理」「推し活家計簿 MyColor」「Fanfun」がチケット記録・写真コレクション・遠征費管理・カレンダー管理をすでに無料または基本無料で提供している。半券コレクションと予算残という差別化軸は有料700円の動機として弱く、既存アプリで実質足りてしまう。対してcirclepost（サークルポスト）は「即売レジ」という競合が存在するが、同アプリはカウンター+会計の特化型で、在庫管理と売上の当日ワンオペ統合に絞った設計ではない。コミケ・即売会当日に一人でサークルを回す人間が、頒布数カウント・在庫残・売上合計を画面ひとつで把握したい痛みは繰り返し発生し（年に複数回参加）、支払い主体は「自分のサークル運営に実害が出る人」なので1,000円の買い切りに対する支払い抵抗は低い。配布面はPixivのサークル向けコミュニティ・Xのサークル主クラスタで検索なしに届く経路が現実的に存在する。保守は頒布物カテゴリや価格変動の外部依存がなく、アプリ本体のUIのみで月2h以内に収まる。

敗者の光: 遠征手帖の「半券コレクション×予算残」という体験設計の軸は情緒的に筋が良く、既存アプリが数値管理に終始して思い出記録との統合が弱い点を突こうとしていた。

circlepostの痛みは「イベント当日、頒布しながら在庫と売上を同時に把握する」という手が止まる瞬間の実痛で、かつ繰り返し頻度が高い（サークル参加者は年数回〜十数回）。1,000円の支払い意思も「1冊1,000円で売っている層」として自然に通る。外部API・データベース依存がゼロで保守コストが月2h枠に収まりやすく、問い合わせも「数え間違い」程度。一方のenseiは遠征費管理自体はZaim・MoneyForwardで代替でき、「半券コレクション」は写真メモで足りてしまうと判断される可能性が高い。さらに「公演スケジュールが載っていない」系の問い合わせや、カレンダー連携要求が膨らむと保守コストが見積もりを超える。配布面でも同人作家コミュニティはX上で密集しており、「使ってみた」投稿が口コミになりやすいcirclepostの方が検索非依存の現実的動線を持っている。

敗者の光: enseiは「半券コレクション＋遠征会計」という情緒的価値の組み合わせが独自で、コアなオタク層の「現場を記録したい」欲求に正直に応えている点が差別化として機能しうる。

kidoriは「DIYを一つ作るたびに必ず直面する木取り計算の面倒くささ」という痛みを毎回・確実に解消する。板を何枚買うかの計算ミスや廃材の多さ、カットサービスへの手書き指示書という具体的な失敗シーンが繰り返し発生し、支払い意思も「板代が浮く・買い直しゼロ」という直接便益で正当化できる。対してgoshuinは御朱印文化×地図という組み合わせとして魅力的だが、利用頻度が巡礼回数に依存する低頻度アプリであり、ホトカミ等の無料コミュニティアプリが地図・記録の両方を無料で提供している競合に対する差別化が薄い。寺社データの保守コストも月2h以内の制約に対し重くなるリスクがある。kidoriは日本固有の「サブロク板×ホームセンターカットサービス」文化に特化した差別化と、DIYコミュニティ経由の検索非依存配布経路がある点で両案を通じて現実性が高い。

敗者の光: goshuinは和紙テクスチャ×朱印デモのUI完成度が高く、御朱印帳を持ち歩くユーザーの「旅のログを美しく残したい」という情緒的動機を的確に捉えている点は強みだった。

御朱印アプリ（goshuin）は「御朱印帳 No.1（500万人・無料）」「ホトカミ（140万人・無料）」が巡礼ルート・写真記録・SNS共有まで一通りカバーしており、800円の買い切りで新規参入しても「これを使う理由」の説明が困難。札所巡礼という高関与ユーザーほど既存アプリに深くロックインされている。一方、木取りプランナー（kidori）は日本語圏の競合は「板の木取」（無料Webアプリ）と「caDIY3D（無料版）」が存在するが、いずれも「カットリスト入力 → 最適割付図」に特化した単機能ツール。2,400円という価格設定は「ホームセンターのカットサービス利用前に枚数ミス・端材ロスを防ぎたいDIYer」という具体的ペインに対して正当化できる。痛みの発生タイミング（材料発注直前）が明確で、Reddit/X上のDIYコミュニティや木工系YouTubeコメント欄という検索非依存の配布経路も現実的に存在する。ただし競合無料ツールとの差別化を「買い物メモ出力まで一気通貫」という体験価値で明示できるかが勝敗を分ける。保守面では外部API依存がなくデータ更新も不要で、月2h以内の維持は現実的。

敗者の光: 御朱印（goshuin）は巡礼ユーザーの熱量と課金意欲は本物で、「オフライン地図 × 次の札所ナビ」という特化機能は既存アプリに薄い領域だが、競合の規模と無料モデルの壁が厚すぎる。

kidoriはDIY板取りの手計算痛みを直撃し、英語中心の既存ツール（CutListOptimizer等）が日本のサブロク板・ホームセンターカット指示書フォーマットに対応していない空白を埋める。2,400円は板材費節約と廃材削減で自己正当化でき、DIY層の道具課金耐性とも整合する。保守面では外部データ依存が皆無で、2Dパッキングアルゴリズムを一度実装すれば月2時間制約内で収まる。対するgoshuinは御朱印コレクター層に無料代替（既存アプリ複数＋Googleフォト）が満足として機能しており、800円の壁を崩す固有価値が現状の設計から見えない。

敗者の光: goshuin は和紙テクスチャ・朱印スタンプ表現のUI実装が完成度高く、情緒的価値の設計は正しい方向を向いている。

furima が刺す痛みは「二重売りで購入者を怒らせ、評価を落とし、謝罪連絡を入れる」という実害つきの体験であり、月40〜50点を複数プラットフォームに掛け持ち出品している中量出品者なら月400円の費用対効果が直感的に見える。対して tsukurikake の「趣味の再開をスムーズに」は心理的快適性の改善にとどまり、Notion テンプレートや普通の iPhone メモで 7 割が代替できてしまうため支払い動機が弱い。保守コストの懸念（メルカリ・ラクマ・ヤフオクの DOM 追従）は furima の実運用リスクとして本物だが、tsukurikake は「保守は軽いが誰も課金しない」という別の致命傷を抱えているため、痛みの強さ×支払い意思の軸で furima を選ぶ。

敗者の光: tsukurikake は保守コストがほぼゼロに抑えられ、個人副業の月 2h 制約に完全に収まる点が furima にない強みで、長期継続のしやすさは明確に優る。

furimaは「売れたのに取り下げ忘れて二重販売トラブル」という実害のある痛みを捉えているが、Chrome拡張「フリマアシスト」(2026年4月更新済み、バージョン3.68.1)が在庫管理・定型文を含む近い機能を既に提供しており差別化が薄い。加えてChrome拡張はメルカリ・ラクマ・ヤフオクのDOM仕様変更のたびにスクレイピングロジックが壊れる構造で、月2h保守枠を恒常的に超えるリスクがある。個人フリマ出品者から月400円サブスクを取る支払い意思も厳しい。tsukurikakeはiOS標準リマインダーで代替できるという弱点があるが、「中断した趣味の再開の一手だけ」に絞った体験設計は既存汎用ツールにない角度であり、外部API依存・データ更新・問い合わせ対応がほぼゼロの保守コストとApp Store一本の配布シンプルさ、600円買い切りの心理的摩擦の低さで実運用上の優位がある。どちらも強くないが、構造的な保守リスクと既存競合の直撃を抱えるfurimaより、弱点が代替可能性の問題だけで止まるtsukurikakeを選ぶ。

敗者の光: furimaは「売れたのに取り下げ忘れて購入者に謝罪・キャンセル」という具体的な実害と繰り返し頻度の高さを正確に捉えており、痛みの設定は明確だった。

furima案は「メルカリ・ラクマ・PayPayフリマで同じ物を出品中に売れた後の取り下げ忘れ」という実在の金銭的痛みと明確な支払い動機を持つが、3プラットフォームのDOM構造変更に無予告で追従し続ける保守コストが月2h制約を構造的に破るリスクがある。amazon比較拡張の調査でも「AmazonのDOM変更への追従コスト（運用負荷）」がリスク第一位と記録されており、furima案はそれを複数サイトで同時に抱える。一方tsukurikake案は外部API依存ゼロ・データ更新コストゼロで保守が軽く、月2h制約を安全に守れる。支払い意思とメモアプリとの差別化説明の弱さは残るが、「個人副業・保守は月2h以内で回る」という前提を恒常的に違反するリスクより軽い欠点と判断した。

敗者の光: furima案は「売れた後に他プラットフォームの取り下げを忘れてキャンセルペナルティ」という損失回避動機が明確で、月400円の支払い意思に実際の根拠がある点が最も優れていた。