午後2時、医療機関からの緊急コールが変えた全て
株式会社Berryの開発チームに、ある医療機関から緊急の電話が入ったのは、平凡な木曜日の午後2時でした。「患者検索システムが使い物にならない。部分的な患者名での検索ができず、業務に支障が出ています」という深刻な内容でした。
Berryは赤ちゃん向けの頭蓋形状矯正ヘルメットを提供する医療機器メーカーです。全国の医療機関と連携し、3Dデータを活用した精密なヘルメット治療を実現していますが、その根幹を支えるのがWebシステムとモバイルアプリでした。
しかし、この日を境に、同社の開発チームは「検索弱いFirestore」という厳しい現実と向き合うことになります。そして、その解決策として選択したSupabase + Next.jsへの移行が、いかにユーザー体験を劇的に改善したか——その舞台裏をお伝えします。
Firestoreの"美しい罠"：リアルタイム性の裏に隠れた検索の限界
Berryが当初選択したFirebaseとFirestoreは、一見すると完璧な選択でした。医療機関と患者データのリアルタイム同期、認証システムの堅牢性、そして何より開発速度の向上。これらすべてが、急成長する医療テック企業にとって魅力的でした。
開発チームのリーダーである名越さんは当時を振り返ります。「Firestoreのリアルタイム同期機能に惚れ込んでいました。医療機関で治療データを更新すると、患者のスマートフォンアプリに即座に反映される様子は、まさに魔法のようでした」
しかし、サービスが拡大し、データ量が増加するにつれて、深刻な問題が露呈し始めました。Cloud Firestore は、ネイティブ インデックスの作成やドキュメント内のテキスト フィールドの検索をサポートしていませんという公式文書の一文が、現実の課題として立ちはだかったのです。
具体的な問題は以下の通りでした：
患者検索の制限: 医療スタッフが「田中」という姓で検索しても、「田中太郎」という患者は見つかるが、「太郎 田中」（姓名が逆）や「田中一郎（たなかいちろう）」のような類似パターンは検索できない。
治療履歴の検索困難: 過去の治療記録から特定のキーワードで関連ケースを検索することが不可能。医師の臨床判断に必要な情報へのアクセスが著しく制限されていました。
部分一致検索の不可能性: FirestoreのLIKE検索は厳密には不可能で、前方一致のみが限界という技術的制約により、柔軟な検索体験を提供できませんでした。
「検索のためだけに外部サービス？」—コスト vs 体験の板挟み
Firestoreの検索制限に対して、専用のサードパーティの検索サービスを使用しますとGoogle公式が推奨するAlgoliaやElasticsearchの導入を検討しました。しかし、医療機器スタートアップにとって、この選択は容易ではありませんでした。
Algoliaの料金体系を詳しく調査したプロダクトマネージャーは頭を抱えました。「月額29ドルから始まって、5万件のレコードと25万回の読み書きが含まれるが、それを超えると従量制。我々のような成長段階の企業には予算的に厳しい」
さらに深刻だったのは、アーキテクチャの複雑化でした。Firebaseのシンプルな設計思想に惹かれて導入したにも関わらず、検索機能のためだけに別のインフラを維持し、Cloud Functionsでデータ同期を管理する必要が生じました。
「シンプルさが魅力だったFirebaseなのに、検索のためだけに複雑な構成になってしまうのは本末転倒だ」と、CTOの判断により、根本的な解決策の検討が始まりました。
Supabaseとの運命的な出会い：「オープンソースのFirebase代替」の真価
転機となったのは、開発チームの一人が偶然発見した「Supabase」という技術でした。オープンソースのFirebase代替として注目を集めているフルスタックバックエンドサービスというキャッチコピーに興味を持ち、詳しく調査を開始しました。
Supabaseの第一印象は衝撃的でした。PostgreSQLという実績豊富なリレーショナルデータベースをベースとしながら、Firebaseのような直感的なAPIを提供していたのです。特に検索機能については、PostgreSQL自体の機能である全文検索や曖昧検索まで利用可能という情報に、開発チームは大きな希望を見出しました。
「これは単なる技術選択ではなく、ユーザー体験の根本的な改善につながる可能性がある」と確信した開発チームは、概念実証（PoC）の開始を決定しました。
移行プロジェクト開始：2週間という限られた時間での挑戦
BerryがSupabaseへの移行を決断した最大の理由は、医療機関からの要望の切迫性でした。患者の治療スケジュール管理や医師の診断支援に直接影響する検索機能の改善は、一刻の猶予もありませんでした。
移行には２週間程かかりましたが、Firestoreでつらみを感じていた部分が解消されて満足していますという先行事例を参考に、短期集中的な移行プロジェクトが開始されました。
週1：データ移行とアーキテクチャ設計
最初の課題は、FirestoreのNoSQLドキュメント構造をPostgreSQLのリレーショナル構造に変換することでした。Firestoreのサブコレクションを別テーブルとして管理する必要がありますという制約により、既存のデータ構造を再設計する必要がありました。
具体的には、患者情報、治療履歴、医療機関データを適切に正規化し、効率的な検索クエリが実行できるテーブル設計を行いました。この過程で、Firestoreでは設計が難しく、画面のUI構成やユースケースを熟考したうえでデータ設計を考える必要がありという従来の制約から解放される喜びを実感しました。
週2：認証システムの移行と検索機能の実装
Firebase Authenticationを使っている場合、Supabaseの Auth に移行する必要がありますという課題に対して、段階的な移行戦略を採用しました。まず新規ユーザーはSupabase Authで登録し、既存ユーザーは次回ログイン時に移行する仕組みを構築しました。
そして、待望の検索機能の実装です。PostgreSQLの強力な全文検索機能により、以下のような高度な検索が可能になりました：
sql-- 患者名の曖昧検索（ひらがな・カタカナ・漢字を統合）
SELECT * FROM patients
WHERE to_tsvector('japanese', name || ' ' || name_kana)
@@ plainto_tsquery('japanese', ?);
-- 治療履歴のキーワード検索
SELECT * FROM treatment_records
WHERE treatment_notes @@ to_tsquery('症状 & 改善');
-- 部分一致とランキング機能を組み合わせた高度な検索
SELECT *, ts_rank(search_vector, query) as rank
FROM patients, plainto_tsquery('田中') query
WHERE search_vector @@ query
ORDER BY rank DESC;Next.jsフロントエンドの全面刷新：検索体験の革命
Supabaseへの移行と同時に、フロントエンドもNext.jsで全面的に刷新されました。この決断の背景には、検索機能の向上を最大限に活かすためのユーザーインターフェース設計の必要性がありました。
リアルタイム検索候補の実装
Next.jsのServer Componentsとクライアントサイドの状態管理を組み合わせることで、入力と同時に検索候補が表示される体験を実現しました：
typescript// リアルタイム検索のカスタムフック
const useRealtimeSearch = (query: string) => {
const [results, setResults] = useState([]);
const [loading, setLoading] = useState(false);
useEffect(() => {
if (query.length < 2) return;
const searchPatients = async () => {
setLoading(true);
const { data } = await supabase
.from('patients')
.select('*')
.textSearch('search_vector', query)
.limit(10);
setResults(data || []);
setLoading(false);
};
const debounceTimer = setTimeout(searchPatients, 300);
return () => clearTimeout(debounceTimer);
}, [query]);
return { results, loading };
};検索結果のハイライト表示
PostgreSQLのts_headline機能とNext.jsのSSRを組み合わせることで、検索キーワードがハイライト表示される機能を実装しました。これにより、医療スタッフは検索結果の中から目的の情報を瞬時に特定できるようになりました。
劇的な改善：数字で見るユーザー体験の向上
移行完了から1ヶ月後の効果測定では、驚異的な改善が確認されました：
検索成功率の飛躍的向上
患者検索の成功率：65% → 94%（29ポイント改善）
治療履歴検索の利用率：12% → 78%（従来は複雑すぎて利用されていなかった）
医療スタッフの業務効率改善
患者情報検索時間：平均2.3分 → 18秒（約88%短縮）
1日あたりの検索回数：病院あたり45回 → 127回（利便性向上により利用頻度が増加）
システム応答性能の向上
検索クエリの平均応答時間：1.2秒 → 0.3秒
複雑な条件検索が可能になったことで、新たな業務フローが生まれました
最も印象的だったのは、医療機関からのフィードバックでした。「システムを使うのが楽しくなった」「患者さんへの対応時間が大幅に短縮された」といった声が数多く寄せられました。
PostgreSQLの隠れた威力：医療データに最適な高度機能
移行後に予想外の副次効果として発見されたのが、PostgreSQLの豊富な拡張機能でした。医療データという特殊な要件に対して、以下のような高度な機能を活用できるようになりました：
地理空間データの活用 PostGISエクステンションにより、患者の居住地と医療機関の距離計算が可能になり、最適な通院ルートの提案機能を追加できました。
データ暗号化の強化 pgcryptoエクステンションにより、医療情報の暗号化レベルを向上させ、HIPAA等の医療情報保護規制への対応を強化しました。
統計分析機能の内蔵化 PostgreSQLの統計関数により、治療効果の分析や予後予測といった高度な分析をデータベース層で実行できるようになりました。
セキュリティ強化：Row Level Security（RLS）の威力
Firestoreのセキュリティルールから、SupabaseのRow Level Security (RLS)に置き換える必要がありますという移行は、当初懸念されていましたが、実際には大幅なセキュリティ強化につながりました。
医療データという極めて機密性の高い情報を扱うBerryにとって、RLSの柔軟性は革命的でした：
sql-- 医師は自分が担当する患者のデータのみアクセス可能
CREATE POLICY doctor_access_policy ON patients
FOR ALL TO authenticated
USING (doctor_id = auth.uid());
-- 患者は自分のデータのみ閲覧可能
CREATE POLICY patient_access_policy ON treatment_records
FOR SELECT TO authenticated
USING (patient_id = auth.uid());
-- 医療機関管理者は所属機関のデータのみ管理可能
CREATE POLICY institution_admin_policy ON patients
FOR ALL TO authenticated
USING (institution_id IN (
SELECT institution_id FROM staff_assignments
WHERE user_id = auth.uid() AND role = 'admin'
));従来のFirestoreセキュリティルールでは実現困難だった、複雑な権限制御を簡潔に記述できるようになりました。
コスト構造の革命：予測可能な料金体系のメリット
財務面での改善も劇的でした。Firestoreがクエリごと料金が掛かるのと比較して、Supabaseはインスタンスごとの課金であり、セルフホストも可能のため、サービスがバズったときのコストの予測がつきやすいという特徴により、事業計画の精度が大幅に向上しました。
月次コスト比較（3ヶ月平均）
Firestore + Algolia構成：月額$847
Supabase Pro構成：月額$25（97%削減）
この劇的なコスト削減により、浮いた予算を研究開発や新機能の開発に振り向けることができ、競争力の向上につながりました。
オープンソースの力：コミュニティとの共創
Supabaseがオープンソースであることの価値も、予想以上でした。医療特有の要件に対して、コミュニティからの支援や、自社での機能拡張が可能になりました。
特に印象的だったのは、日本の医療制度に特化した機能の開発でした。保険点数計算や電子カルテとの連携機能を、Supabaseのエクステンション機能として開発し、コミュニティに還元することで、他の医療系スタートアップとの協力関係も生まれました。
移行プロジェクトの落とし穴と対策
しかし、移行は決して平坦な道のりではありませんでした。いくつかの重要な課題と、その解決策をご紹介します：
リアルタイム機能の実装方式の違い FirestoreのリアルタイムリスナーとSupabaseのRealtimeでは、実装方式が大きく異なりました。この問題は、Next.jsのWebSocketクライアントとSupabaseのPostgresChangesAPIを組み合わせることで解決しました。
データ移行時の整合性確保 大量の医療データを移行する際の整合性確保は、最も神経を使う作業でした。段階的移行とデータ検証スクリプトの並行実行により、データロス0を達成しました。
スタッフトレーニングの必要性 新しい検索機能は高機能な反面、医療スタッフへの操作説明が必要でした。この課題は、Next.jsの直感的なUIと、コンテキストヘルプ機能により解決しました。
医療業界への波及効果：業界標準への道
Berryの成功事例は、医療業界全体に大きな影響を与えています。「検索弱いFirestore」からの脱却事例として、多くの医療系スタートアップが同様の移行を検討し始めています。
特に注目されているのは、以下の点です：
規制対応の容易さ PostgreSQLの豊富な監査機能とSupabaseのログ機能により、医療情報保護法や薬機法といった厳格な規制への対応が容易になりました。
他システムとの統合性 既存の病院情報システム（HIS）や電子カルテシステムとの連携が、SQLの標準的なインターフェースにより大幅に簡素化されました。
スケーラビリティの実証 全国規模での医療機関ネットワークにおいても、Supabase + Next.jsの組み合わせが十分なパフォーマンスを発揮することが実証されました。
次世代医療システムへの展望
現在、Berryでは移行の成功を受けて、さらなる革新的機能の開発が進んでいます：
AI診断支援機能 PostgreSQLのベクター検索機能を活用し、過去の治療データから類似症例を自動抽出する機能を開発中です。
予測分析プラットフォーム 治療効果の予測や、最適な治療プランの提案機能を、Supabase Edge Functionsとして実装する計画です。
患者エンゲージメント向上 Next.jsのPWA機能を活用し、患者の治療意欲向上につながるゲーミフィケーション機能を検討しています。
技術選択が変えた未来：開発チームからのメッセージ
移行プロジェクトを主導した名越さんは、この経験を以下のように総括しています：
「技術選択は単なる手段ではなく、ユーザー体験と事業成長に直結する戦略的判断です。Firestoreの制約に諦めて妥協するのではなく、根本的な解決策を求めたことで、予想を超える改善を実現できました。Supabase + Next.jsの組み合わせは、我々の事業にとって転換点となりました」
開発チームが学んだ最も重要な教訓は、「技術的制約をビジネス制約として受け入れてはいけない」ということでした。ユーザーの真のニーズを満たすためには、時として大胆な技術選択の変更も必要だという確信を得ました。
「検索弱いFirestore」を超えて：新たな可能性の扉
Berryの事例は、「Firestoreの検索制限は仕方がない」という業界の諦めムードに一石を投じました。PostgreSQLの強力な検索機能とSupabaseの開発者体験、そしてNext.jsの柔軟性を組み合わせることで、従来は不可能とされていたユーザー体験を実現できることを証明したのです。
医療機関のスタッフが「システムを使うのが楽しくなった」と感じるほどの改善は、単なる技術的優位性を超えた、人間中心の価値創造だったのかもしれません。
Firebase × Firestoreが多くのプロジェクトで素晴らしい成果を上げていることは間違いありません。しかし、検索機能が中核的な要件である場合、Supabase + Next.jsという選択肢があることを、Berryの事例は教えてくれます。
技術は目的ではなく手段です。ユーザーの真の価値を追求する姿勢こそが、最適な技術選択を導き、結果として事業成功につながるのです。
お問い合わせ
Supabase + Next.jsを活用したシステム移行や、検索機能の強化についてのご相談は、お気軽にお問い合わせください。
連絡先: info@zetlinker.com
当社のNext.js専門開発チームが、Berryの成功事例から学んだ知見を活かし、貴社の技術的課題解決を全力でサポートいたします。Firestoreの制約に悩まれている場合でも、適切な移行戦略により、ユーザー体験の大幅な改善が可能です。