Day 5: 設計の前提が崩れた朝、むしろ一番進んだ日
朝、本番カメラの選定が根っこから崩れた。 でもその崩壊から始まった日が、結果的に Okaeri にとっていちばん設計が前進した一日になった。
Day 4 まで、PoC で使っていたのは TP-Link の Tapo C210 という家庭用カメラだった。安くて、画質も悪くなく、RTSP で映像が取れた。 Day 5 の朝の予定は、これを「本番想定」 = FTP 設定に切り替えて、撮影画像を AWS に自動アップロードする経路に乗せることだった。
ところが、Tapo C210 には FTP 機能が搭載されていない。2026 年の最新ファームでも、Tapo アプリのどの階層を辿っても FTP の項目が出てこない。 正確に言うと、TP-Link は VIGI シリーズ(法人向け)にしか FTP を実装しておらず、家庭向け Tapo は Tapo Care(クラウドサブスク) に誘導される設計になっていた。
1. 朝、設計が崩れた
正直、最初は「Tapo Care 契約すればよくない?」と一瞬考えた。 でも、Okaeri の顧客に「ペットカメラの月額 + Okaeri の月額」のサブスク二重課金は、絶対に避けたい設計だった。 「うちの子の様子を見たい」だけのために、複数のサブスクが積み重なるのは、サービスとしての敗北だ。
ピボット先を決めるのに、Day 5 の朝の 2 時間を使った。 候補は 3 つ。Reolink E1 Pro(¥7,999、ONVIF 標準)、Ctronics の 4MP モデル(¥5,999、FTP / ONVIF / NAS 全対応)、そして Anker のスマートホーム連携系。 最終的に Ctronics B0C5BS9JPC を採用、Amazon に即発注した。
選定基準は単純で、「FTP がカメラ本体の機能として無料で含まれていて、サブスク追加がいらない」こと。 Ctronics は中国系ブランドだが、Amazon JP のレビュー数 / 日本語サポート / FTP 直接出力の挙動について、開発者ブログでの動作確認が複数あった。 Day 4 までの設計ドキュメント 9 本を、その朝のうちに Tapo → Ctronics の前提で書き換えた。 BUSINESS_MODEL のカメラキット原価、OKAERI_INFRA_PLAN の FTP 経路、ONBOARDING_SPEC の初日接続フロー、メモリの記録まで。
「思っていた前提が違った」と気づいた瞬間に、設計は強くなる。
本番想定が朝に崩れたから、午後の設計はむしろ厚みが増した。
2. 崩したから、UX も整理できた
ピボットで設計を書き直していたら、その隣にあった UX の歪みも一緒に直したくなった。 これは "消化器系の再起動" みたいなもので、一つ吐き出すと連鎖して他も整理される感覚がある。
これまで LP の「Try」ボタンは、いきなり 1 日分の連絡帳サンプルに飛ばしていた。 でも考えてみると、LP の中段にはすでに 1 日分の連絡帳サンプルがインラインで載っている。 クリックしたら、もう一度同じ次元の情報を見せていることになる。 ユーザーは「これ何?」の次に欲しいのは、「これが毎日続く」の証拠だ。
だから「Try」の遷移先を、月のカレンダーに切り替えた。 「カレンダーで毎日の様子を見る →」 が主導線、「今日の連絡帳を開く →」は補助。 8 日分の連絡帳マークが並ぶカレンダーを最初に見せたほうが、「毎日届く」が体感で伝わる。 連続性を視覚で証明してから、興味のある日に降りていく動線にした。
同時に、カレンダーの嘘も正直化した。 これまでのモックは、5/5-5/12 まで広範に「投稿あり」マークがついていたが、実体のあるサンプルは 5/12 と 5/13 の 2 日分だけ。 残りはマークだけあって押せない、いわゆる "演出マーク" だった。 これを 5/5-5/8 を空白、5/9-5/13 を実体ありリンクに戻した。 カレンダーは「生育ログ」になる。これから生成する連絡帳を順次追加していけば、空白が埋まっていく過程そのものが、ユーザーへの "毎日続く" の証拠になる。
3. LINE Push の URL 設計を確定させた
ピボットついでに、もう一つ厄介な決断を片付けた。 LINE で毎日届く連絡帳の通知をタップしたとき、ユーザーはどこに飛ぶのか。 選択肢は 3 つあった。
- A. マイページ配下の URL(認証必須、login redirect が挟まる)
- B. 公開 URL + login 必須(redirect 経由)
- C. 公開 URL + 署名トークン(redirect なし、純粋な記事体験)
採用したのは C。 JWT 署名されたトークンを URL に埋め込み、サーバ側で検証して即表示する方式。 これで LINE 内ブラウザでタップした瞬間、login redirect で離脱することなく、連絡帳本文がそのまま開く。
この設計には 「pure article view」 という呼び方をつけた。 プラットフォームの chrome(ナビ、ボトムタブ、設定アイコン)を全部消して、紙の連絡帳を読む体験だけを残す。 読者が「これは Okaeri が動くアプリだ」と気づく必要はない。ただ "うちの子の今日" が、紙のように届く。それだけでいい。
「サービスのことを忘れて、コンテンツに没入できる」という最高の体験設計だ。
chrome は、いつも邪魔ではないが、いつも視覚ノイズではある。
4. PoC を越える設計に踏み込んだ
ここまでで普通の一日分の仕事だったはずだが、Day 5 はさらに踏み込んだ。 Phase β(βテスト + 量産)を視野に入れた AWS インフラの Terraform skeleton を書いた。
これまでの Okaeri は、ローカル PC で動く Python スクリプトと、Vercel に置いた LP だけだった。 Phase α(クラファン前)は、それで間に合う設計だった。 でも本気で 30 顧客 → 300 顧客 → 3,000 顧客と伸ばしていくなら、どこかでサーバ側に移行しないといけない。 その「どこか」を 4 ヶ月先送りすると、移行が事業の制約になる。先に書いておけば、後の選択肢が増える。
書いたのは infra/terraform/prd/ 配下の 11 ファイル。
VPC、Lambda、RDS PostgreSQL、S3(画像保管)、Transfer Family(カメラからの FTP 受け)、EventBridge(定期処理)、IAM、KMS。
関連プロジェクトの Tasteck で運用中の AWS アカウントに相乗りする構成にして、論理分離だけ Terraform で表現した。Phase 3 で完全分離する時の移行コストも計算済みだ。
これは "Premortem(事前死亡分析)" という考え方に近い。 Gary Klein が提唱した意思決定手法で、「このプロジェクトが将来失敗するとしたら、何が原因か」を、開始前に想定する。 Okaeri の場合、最大の構造リスクは「スケール時のインフラ移行で 3 ヶ月止まる」シナリオだった。 その失敗を未然に潰すために、Phase α のうちに Phase β 用の設計を準備しておく。 ピボットの日に、半日でそこまで踏み込めたのは、設計の前提が崩れて「もう動かなきゃまずい」と思ったからだ。
5. 夜、撮影が再開した
17:20。Tapo C210 はまだ動いている。Ctronics が届くまでの数日、Day 1-4 で使った Tapo の運用を延長することにした。 RTSP 接続を再開して、15 分間隔で 22 ラウンドの撮影スケジュールを set した。22:35 までに 22 枚のスナップが手元に残る予定だ。
これを材料に、今夜の Cron で 5/14 分の連絡帳を生成する。 朝から続いてきたピボットの日が、夜には "うちの子の今日" として連絡帳 1 通に圧縮される。 その連絡帳が 月のカレンダー の 5/14 セルに追加されたとき、空白が一つ埋まる。 「ピボットの日も、連絡帳が届いた日」として、ログに残る。
同じ一日の中で繋がっている。
ピボットは、サービスを止める出来事じゃない。続けることの中で起きる出来事だ。
このシリーズの位置づけ
この Articles は、Okaeri 開発のオフィシャル記録だ。 note の方にも同内容を、少し時間差で公開していく。 初出は okaeri.pet、note はミラー。情報の正本はここに置く。
5/14(木) Day 5 の進捗、ここまで。 今夜の 22 時、撮影 22 枚から 5/14 の連絡帳が生成される予定。明日また書く。
