模倣ではなく目的を選んだ — Haru Spaceがメッセンジャーになった最初の一週間

この記事は、2026年7月1–5日のGit記録と当時の設計文書をもとに、約7週間後に振り返って書いた最初の一週間の記録だ。

Haru Spaceの最初の画面は、今のHaru Spaceとはほとんど似ていなかった。

初めはポートフォリオに近いページがあり、その次には、あるコミュニティの運営構造を参考にした小さなPoCがあった。部屋があり、メンバーがいて、管理者がいる画面は作れた。しかし画面が増えるほど、もっと大切な問いがはっきりしてきた。

私たちは何を作れるのかではなく、何を守るためにこれを作るのか。

最初の一週間で最も大きく変わったのは、新しいボタンでも華やかな機能でもなかった。参考にしたものへ近づける作業をやめ、Haru Space自身の目的を選んだことだった。

参考にはするが、複製はしないという決断

既存サービスを調べることは、素早い出発に役立つ。ユーザーがすでに慣れている画面や運用の流れを通じて、どのような問題が繰り返されるのかを推測できるからだ。しかし、参考と複製の間には思った以上に大きな隔たりがある。

参考にした構造には、ログイン、参加承認、複数の部屋、管理者機能、リアルタイムの会話があった。必要だったのは、そのサービスのコードや画像、非公開データではない。人々が小さな共同体を運営するとき、本当に必要になる行動の順序だった。

私はその順序を、Haru Spaceの目的に合わせて解釈し直すことにした。

• 知らない人をできるだけ多く集めるのではなく、承認された人が安心して入れる空間
• メッセージを大量に消費させるのではなく、異なる言語を使う人も同じ会話を続けられる空間
• 翻訳文だけを見せるのではなく、必要なときに原文を自分で確認できる空間
• 管理者が参加を承認し、システムに誰が誰を承認したかの記録が残る空間

この決断から、プロダクトを表す一つの文が生まれた。

Haru Spaceは、大切な人たちが言葉の違いによって遠ざからないよう支える、プライベートなグループメッセンジャーだ。

一つの文ができると、機能の優先順位も変わった。何が格好よく見えるかではなく、どの流れを先に途切れさせてはいけないかを判断できるようになった。

モックアップではなく、一度最後まで歩ける流れ

最初のMVPの基準はシンプルだった。何枚もの画面を見せるのではなく、一人のユーザーが実際に最初から最後まで歩けなければならない。

参加を申請する。管理者が確認する。承認されたユーザーがログインする。グループの部屋に入る。メッセージを残す。相手は自分の言語に翻訳された文を先に読み、必要なら原文を開く。

文章にすると短いが、この流れにはプロダクトのほぼすべての基礎的な問題が含まれていた。認証状態、管理者と一般ユーザーの権限、部屋へのアクセス範囲、メッセージの保存、翻訳の失敗、画面の更新、モバイル入力、運用データまで、どれか一つでも途切れればユーザーは目的地へたどり着けない。

そこで最初の一週間は、メニューを増やすよりも、この道をつなぐことに集中した。部屋の一覧とチャット画面を分け、お知らせ、メディア、管理の領域をそれぞれの責任に分離した。デプロイしたサーバーが稼働しているか確認できるヘルスチェックの経路も作った。

当時は小さな技術的整理に見えた。振り返れば、サービスが大きくなっても再利用できる最初の骨格だった。画面を分けたことで機能ごとに障害の範囲を絞り込めるようになり、ヘルスチェックができるようになったことで、「サイトが動かない」という曖昧な言葉ではなく、どこまで正常なのかを問えるようになった。

AIが失敗しても会話は止めない

翻訳はHaru Spaceの重要な機能だが、会話そのものより重要であってはならない。

初期設計で最も慎重になったのも、この点だった。翻訳プロバイダーが遅かったり応答しなかったりすることはある。外部APIキーがまだ接続されていない開発環境もある。そのときメッセージの送信まで失敗させてしまえば、AIは助けになる機能ではなく、会話を止める単一障害点になる。

そこで原文は専用のフィールドに、翻訳はその隣のフィールドに保存する構造を選んだ。翻訳はまずOpenAIを試し、失敗すればAzureへフォールバックする。両方を利用できない場合やAPIキーがない場合は、「翻訳待ち」という表示と原文を含むフォールバック文を翻訳フィールドに保存し、メッセージ作成自体は失敗させない。翻訳結果だけを保存して原文を失う方法は選ばなかった。

この原則は、その後Haru SpaceのAI機能を設計するときにも、繰り返し立ち返る基準になった。

AIは、中心となる行動を可能にする唯一の鍵ではなく、その行動をよりよくできるよう助ける仲間であるべきだ。

AI機能を加えるときは、「成功すれば何をしてくれるか」だけを問いがちだ。最初の一週間に学んだ、より大切な問いは「失敗しても、ユーザーは本来やろうとしていたことを続けられるか」だった。

最初の本番インシデントは画面の外から来た

機能が目の前で動き始めると、すぐに運用上の問題が現れた。本番サービスで使っていたアカウントは、まずアクセス状態の修復が必要だった。その後、一部環境の既存usersテーブルに、アプリケーションが想定するカラムがないことが分かった。画面上ではどちらもログイン失敗に見えたが、原因はいずれも認証UIの外にあった。

当初、私は見えている症状に沿ってアカウントとログイン経路を再確認した。復旧には二つの異なる手順が必要だった。本番アカウントのアクセス状態を修復し、次に既存usersテーブルへ想定カラムを安全に追加した。さらに例外ログを増やし、スキーマ修復の手順を整理して、予期しないAPIエラーをサーバー側で観察できるようにした。

この経験は小さいながらも、長く残る教訓になった。

1. 運用エラーは、ユーザーが見た画面と同じ層で起きているとは限らない。
2. データベース変更には、コードのデプロイとは別のライフサイクルがある。
3. エラーメッセージを分かりやすくすることと、原因を観察できるようにすることは、どちらも必要だ。
4. スキーマの補強は一度だけ成功するスクリプトではなく、何度実行しても安全な手順でなければならない。

サービスを作り始めたときは、成功経路がよく見える。運用が始まると、失敗経路がプロダクトの品質を決める。最初の一週間に起きたログイン問題は、Haru Spaceが画面の集合から、運用すべきサービスへ移る最初の兆しだった。

モバイルの小さな不便は、小さな問題ではなかった

同じ時期、モバイルで入力欄をタップすると画面が拡大する、新しいメッセージが届いても最新位置へ移動しない、更新時に画面がちらつく、といった問題が続いた。メディアのアップロードに失敗しても、ユーザーには理由が分かりにくいこともあった。

一つひとつは小さなUIバグに見えた。しかしプライベートなメッセンジャーにとって、モバイルは補助画面ではなく中心となる利用環境だ。入力するたびに画面を合わせ直し、届いたばかりのメッセージを探してスクロールしなければならないなら、翻訳がどれほど優れていても会話は長続きしない。

問題をまとめて覆い隠すのではなく、一つずつ分けて対処した。モバイル入力時の拡大を抑え、最新メッセージの位置を補正し、更新中の不要なちらつきを減らした。アップロードの失敗も、何も知らせず消えるのではなく、ユーザーが次の行動を選べるようにした。

この過程で、「モバイル対応は最後に画面を縮める作業だ」という考えを捨てた。モバイルで頻繁に途切れる行動から、プロダクトの基本フローとして扱う必要があった。

一枚の写真と一つの通知が運用機能になるまで

最初の一週間の後半には、画像と動画のサムネイル、プッシュ通知も加わった。表面上は便利な機能だが、どちらも運用コストと信頼に直結していた。

一覧で毎回オリジナルのメディアを読み込めば、画面は遅くなり、転送量も増える。そこで会話一覧では小さなサムネイルを先に表示し、ユーザーが開いたときにオリジナルを取得する方向を選んだ。プッシュ通知も全員へ無条件に送るのではなく、ユーザーが有効と無効を選べる必要があった。その通知設定とは別にブラウザーや端末の購読情報を管理し、自分が送ったメッセージを自分へ再び通知してはいけなかった。

当時は、まだ完全なコストモデルも精緻な通知ポリシーもなかった。それでも小さな機能を加えるときから、三つのことを一緒に考え始めた。

• ユーザーが本当に求める瞬間はいつか
• その瞬間までに、どのデータを必ず送る必要があるか
• 失敗したときや望まないときに、どう止められるか

この三つの問いは、その後メディアストレージ、リアルタイム接続、AI呼び出し、自動化のコストを設計するときにも、同じ基準になった。

素早く作った最初の一週間で、考え違いをしていたこと

最初の一週間には、多くの変化が短期間で入った。すぐ目で確認できる利点はあったが、プロダクトの方向性より機能一覧が先に進みかけた瞬間もあった。ホームハブ、複数のメニュー、パーソナライズ、通知を作る中で、「ユーザーが本当にこれを最初に必要としているのか」を十分に検証できていない選択もあった。

また、検証の順序を文書に書いたからといって、実際の運用検証が自動的に証明されるわけではなかった。当時の記録には、ログイン、承認、メッセージと添付ファイルの送信を確認する手順が残っている。しかし今日確認できる記録では、すべての時点のCI出力とデプロイログを同じ水準で再確認することはできない。

そこで今回の振り返りでは、今日確認できる記録を超えて「検証した」と誇張せず、どこまで実装され、どのような確認手順を設けたのかを分けて書く。うまくいった結果だけをつなげれば宣伝記事にはなるが、次の判断を助ける開発記録にはなりにくい。

最初の一週間が残した実践チェックリスト

似たサービスを初めて作る人へ、この一週間の経験を渡すなら、次の順序で整理したい。

1. 機能一覧の前に、一文の約束を書く

「誰が、どの瞬間に、何を続けられるようにするのか」を含む文が必要だ。この文がなければ、参考にしたプロダクトの機能数が、そのままロードマップになる。

2. 参考にするものからは行動の構造だけを取り出す

画面、コード、データ、ブランドは複製しない。ユーザーが参加し、承認され、目的を達成するまでの行動の順序を取り出し、自分のサービスの価値に合わせて再設計する。

3. AIを外しても中心の流れを歩けるか確認する

外部モデルやAPIが失敗しても、原文、入力データ、ユーザーの次の行動が残らなければならない。AIを取り除くと何もできない構造なら、失敗のコストが大きすぎる。

4. スキーマと可観測性を最初のデプロイ範囲に含める

ヘルスチェック、エラーログ、冪等なマイグレーション、最低限の運用点検手順を機能とともに作る。「自分のPCでは動いた」と「本番で復旧できる」の間をつなぐ仕組みだ。

5. モバイルで最も頻繁に繰り返す行動から検証する

ログイン、入力、送信、最新メッセージの確認、エラーからの復旧を小さな画面で先に歩いてみる。デスクトップ画面を縮めるだけでは、モバイル体験にはならない。

6. 決断と限界を同じ文書に残す

何を選んだかだけを記録すれば、次の人は同じ議論を繰り返す。なぜ選んだのか、何を諦めたのか、まだ検証できていないことは何かも一緒に残す。

Haru Spaceが始まった瞬間

最初の一週間が終わったとき、Haru Spaceは完成したサービスにはほど遠かった。権限はさらに細かくする必要があり、グループ間のデータ境界、リアルタイム処理のコスト、公開と非公開の区別も、これから解くべき課題だった。

それでも、以前とははっきり違っていた。

ポートフォリオ画面とコミュニティPoCを経て、誰がなぜこの空間に入り、どの体験を守るべきかを言葉にできるようになった。参加から承認、会話、翻訳、原文の確認まで、一度歩ける道ができた。そしてその道が運用で初めて途切れたとき、見えている画面だけを直すのではなく、データと可観測性にも手を入れ始めた。

振り返れば、Haru Spaceは最初のコミットから始まったのではなかった。

何に似せるかより、何を守るかを選んだ瞬間に、ようやく始まった。

次の記録では、一枚の写真と一つのチャットルームがどのようにコストポリシーでありセキュリティポリシーにもなったのか、そしてグループが増える中で「見えないように隠すこと」と「サーバー側でアクセスできないように防ぐこと」の違いを学んだ過程を続けたい。