技術記事

開発の背景――医療×学術コミュニティに必要な「信頼感」とは

医学部生が日常的に扱う情報は、一般のコンテンツとは性質が根本的に異なります。解剖学の図解、薬理学のノート、病態生理のまとめ。どれも正確性が求められ、誤情報が混入すれば将来の医療現場に影響を及ぼしかねません。そうした背景から生まれたのが、医学部生向けノート共有コミュニティアプリ「メディカルサークル」です。

開発を依頼いただいたとき、クライアントが最初に強調したのは「信頼感」という言葉でした。機能の豊富さよりも、アプリを開いた瞬間に「ここは安心して使える場所だ」と感じてもらえることが最優先だ、というわけです。

医学部生は勉学の厳しさゆえに時間が限られています。コミュニティへの参加も、SNSを娯楽として使うような気軽さとは異なります。大学の授業内容を共有する行為は、著作権・プライバシー・学術誠実性の観点から慎重さが問われる場面も多く、場の設計次第でユーザーが参加をためらう原因にもなります。

そこでmicomiaでは、開発の最初の問いを「どうすれば医療×学術という文脈で信頼感を生み出せるか」に設定しました。UIデザイン、課金設計、コミュニティ安全機能、管理画面に至るまで、すべての判断はこの問いに対する答えとして積み上げられています。

以下では、その設計判断を章ごとに詳しく説明します。

デザインシステムで視覚的信頼を作る――医療UIの設計哲学

「信頼感を視覚で伝える」と言うと抽象的に聞こえますが、実装レベルに落とすと具体的な制約の集合になります。メディカルサークルでは、デザインシステムをプロジェクト初期に策定し、全画面で一貫した見た目と挙動を保つことを最優先に置きました。

余白・角丸・色数を制限して揺れをなくす

余白は4段階、角丸は3段階のみ使用するルールを設けました。画面ごとに独自の値を設定する自由を排除したのは、統一感が失われると「作り込みが甘い」という印象を与えるからです。医療×学術の文脈では、この雑な印象がそのままアプリへの不信感につながります。

色はプライマリ（紺系）・セカンダリ・アクセントの3色と、テキスト3階調（メイン・サブ・ヒント）に限定しました。エラー・警告色は破壊的アクション専用と決め、中立的な操作にはプライマリ系のみを使うルールを徹底しています。

メディカルブルーで信頼感を、アンバーでCTAを

プライマリカラーに選んだのは深みのある紺——メディカルブルーと呼んでいます。AppBar、ボタン、選択状態など、アプリの骨格となる要素にこの色を使うことで、「医療×学術」の信頼感を色彩から体感してもらえるようにしました。

一方でアクセントカラーのアンバーは、有料プランのバッジやリワード的な要素にのみ限定して使います。色数を絞ることでCTAの存在感が自然に強調され、「ここは特別な場所だ」というシグナルが視覚的に伝わる設計です。

Noto Sans JPと段階的ウェイトで読みやすさを作る

医学用語が多く、テキスト密度が高くなりがちなアプリです。フォントはNoto Sans JPを採用し、本文400・ラベル500・見出し600・強調700の4段階で使い分けています。行間は本文系テキストに1.45〜1.5を設定し、長い科目名や教授名が詰まって読みにくくならないよう配慮しました。

フォントの選定とウェイトの設計は地味な作業ですが、「誠実さを伝える」という意味で非常に重要な要素だと考えています。

共通ウィジェットを先に作り、画面は組み合わせで構成する

プロジェクト初期に、ダイアログ・セクションヘッダー・メニュータイル・ソフトカード・空状態表示・エラーバナーといった基本部品を共通ウィジェットとして作り切りました。各画面はそれらを組み合わせるだけで構成するルールにしたことで、見た目と挙動を全画面で統一できています。コンポーネント化によって開発速度が向上し、不具合の発生率も低下しました。

空状態・エラー・ローディングを安心感に変える

空状態には必ず「次に何をすべきか」のCTAボタンを添えるルールにしました。「まだノートがありません」で終わらせず「ノートをアップロード」ボタンを置くことで、ユーザーが迷子にならない設計です。

エラー表示はバナー型に統一し、フォーム上部に赤背景で目立たせつつ、具体的な対処法を含む文言にしました。たとえばログイン失敗時は「メールアドレスまたはパスワードが正しくありません」、退会済みメールアドレスの場合は「このメールアドレスは退会済みです。再登録は新規会員登録からお願いします」のように、次のアクションが分かるメッセージにこだわっています。

ローディングは処理の重さに応じて使い分けました。画面遷移程度なら控えめなスピナー、アップロードや削除のような長時間処理は進捗パーセント付きのダイアログで操作をブロックし、「処理中であること」を明示することで安心感を演出しています。

RevenueCatによるサブスクリプション実装とFirestore同期

アプリ単体で収益化するとき、サブスクリプションの実装は事業の生命線です。メディカルサークルでは、Apple/Googleの課金をRevenueCat経由で統合し、Firestoreと同期させる構成を採用しました。実装を進めるなかで詰まったポイントがいくつかあり、それぞれに設計上の判断が必要でした。

Entitlement Identifierは変更不可——だから内部識別子として扱う

RevenueCatのEntitlement Identifierは、ダッシュボードで一度作成すると変更できません。有料プラン名を改名した際に合わせてIdentifierも変えようとしましたが、それが不可能であると分かりました。この経験から、Identifierは「内部的な識別子」、プラン名は「ユーザーに見せる表示名」と完全に分離し、コード側で定数として一元管理する設計に切り替えました。運用開始後の命名変更リスクを最小化するためです。

課金状態をFirestoreとアプリ内stateに二重反映する

RevenueCatのリスナーで課金状態の変化を検知し、変化時にはFirestoreのユーザードキュメントのisPremiumフラグを更新します。同時にアプリ内の状態管理プロバイダも更新し、UI側はプロバイダを監視するだけで有料機能のロック/アンロックが即座に切り替わるようにしました。

Firestoreにもフラグを置いているのは、セキュリティルールで参照する必要があるからです。「クライアントの自己申告だけでルールを書く」のはセキュリティ上危険なため、二重反映は必須の設計でした。

1つのプロバイダで有料機能の制御を統一する

有料機能のロック/アンロックを画面ごとにバラバラに書くと、改修時に必ずどこかが取り残されます。メディカルサークルでは、課金状態を返すプロバイダを1つ定義し、すべての画面からそれを参照する方式に揃えました。画面ごとの分岐は「プロバイダの値を見てif/elseする」だけで済むため、新規プラン追加や条件変更にも追従しやすい構造になっています。

「購入の復元」は機能よりテストが論点

App Storeの審査で必須となる「購入の復元」は、設定画面にボタンを配置し、タップ時にRevenueCatの復元APIを呼んで結果を反映する構成です。実装自体は数十行で済みます。しかし本当の論点は「ちゃんと動作するかをどう検証するか」でした。サンドボックスアカウントを用意し、購入→アンインストール→再インストール→復元というシナリオを実機で繰り返し検証することで、リリース後のサポート問い合わせを最小化できました。

RevenueCatを組み込んだ課金実装は、コードだけ見れば単純です。しかし「Identifierの不変性」「ルールとの同期」「画面横断の制御」「復元の検証」という、見落としやすい論点が積み重なります。これらをプロジェクト初期にまとめて解決しておいたことで、その後の機能開発を課金まわりに引っ張られることなく進められました。

コミュニティの安全設計――通報・ブロック・非表示機能

医学部生のノート共有という文脈において、不適切な投稿や迷惑行為への備えは「あれば便利」ではなく「なければサービスが成立しない」要件です。どれだけ優れたノートが集まっても、場が安全でなければ参加者は離れます。メディカルサークルでは、通報・ブロック・コンテンツ非表示という3つの仕組みを土台に、ユーザーが自分で快適さをコントロールできる設計にしました。

3つの機能を別コレクションに分離した理由

通報・ブロック・非表示を1つのコレクションにまとめると、セキュリティルールの条件が複雑化し、保守が重くなります。それぞれを別コレクションに分離したのは、各ルールをシンプルに保ちながら、クライアント側のフィルタ処理の見通しも良くするためです。利用頻度とアクセス権限がそれぞれ異なるため、コレクションを分けることでパフォーマンスも安定しました。

ブロックはクライアント側フィルタ＋ストリーム監視で全画面に反映

ブロックは「相手のファイル・コメント・メッセージが自分から見えなくなる」必要があります。Firestoreクエリ側で除外するのではなく、クエリ結果をクライアント側でフィルタする方式を採用しました。この判断の理由は2つあります。

• Firestoreクエリに複雑な除外条件を加えると複合インデックスが増え、長期の運用コストが上がる
• 新しい画面を追加する際、クライアント側のフィルタ処理なら「ブロックリストで除外する」1行を挟むだけで済み、機能拡張に強い

漏れを防ぐため、ブロックリストの取得は起動時1回ではなくストリームで常時監視しています。ブロック操作をした瞬間に全画面のフィルタが自動更新される設計で、ユーザーが操作後に「まだ見えている」と感じるストレスをなくしました。

通報フローと運営対応を1本のデータフローで設計

ユーザーが通報ボタンを押すと、理由選択と任意コメント付きの通報ドキュメントがFirestoreに作成されます。ドキュメントIDは「通報者＋対象種別＋対象ID」の組み合わせで決定的に生成しており、同じ人が同じ対象を二重通報できない構造です。運営側はWebの管理画面でこれらを一覧表示し、対応状況を更新できます。

アップロード前の確認UIとNGワードフィルタで二段構えにする

アップロード画面では、送信ボタンの手前に3項目のチェックボックスを設置しています。

• 私個人のノートです
• 教科書・市販教材の複製ではありません
• 他者の著作権を侵害していません

全てチェックしないとアップロードできない設計です。さらに、ユーザー名・タイトル・コメント・チャット・自己紹介の入力フォームにはNGワードフィルタをバリデーションに組み込み、不適切な表現が含まれていれば送信前にエラーを出します。

これはあくまで一次フィルタとしての位置づけで、最終判断は通報機能と運営対応に委ねる二段構えです。コミュニティ機能は「便利さ」より先に「安心」が前提になる領域であり、1つの仕組みに頼らず複数の手段を重ねることで、持続可能な安全設計が成立します。

ユーザーが迷わない画面体験と管理者機能

デザインシステムや安全設計が固まったら、次は日々の使い勝手です。メディカルサークルでは毎日使われるアプリを目指し、日常の学習導線の中に自然にノート管理やコミュニティ参加を組み込む設計を意識しました。

アップロード画面は上から下に進めば終わる

要素が多くなりがちなアップロード画面は、ファイル選択→タイトル・説明→科目・教授名→公開設定→アップロードの順に並べ、自然に上から下へ進めば完了する構成にしました。さらに、時間割登録済みユーザーが「今日の授業」カードからアップロードに入った場合は、科目名・教授名・曜日・時限がクエリパラメータで自動入力されます。実質的にファイルを選んでタイトルを付けるだけで投稿が完了する導線です。

ファイル種別を色と3Dアイコンで直感的に区別

ファイルカードには、ファイル種別ごとに色分けしたアイコンを配置しました。PDFは赤、画像はプライマリの青、ZIPはアンバーと色を変え、直感的に判別できるようにしています。アイコン自体を3D表現にすることで、周囲のテキストコンテンツより視覚的に浮かび上がり、一覧画面でも見つけやすくなります。小さなディテールですが、視認性の差が日常利用の快適さを生むと考えています。

有料導線は「気づくが押し付けない」場所に置く

検索機能は有料機能ですが、ボトムナビの検索アイコンに小さな有料バッジを添える程度の控えめな表示にとどめました。通常利用の動線上では有料表示が目に入りすぎず、ユーザーが自発的に検索に触れたタイミングでのみアップグレードダイアログが表示される仕組みです。ダイアログには「今は必要ない」を選べるようにし、押し付けがましさを徹底的に避けました。コンバージョンと体験の心地よさのバランスを意識した設計です。

ゲスト利用で価値を体感してから登録に誘導する

ゲスト（未登録）でも「自分の非公開ノート管理と時間割登録」は制限なく使えるようにしました。会員登録を強制する前に、まずアプリの価値を体感してもらう設計です。フレンド・コメント・チャットなどのソーシャル機能に触れたタイミングでのみ「この機能にはアカウント登録が必要です」というダイアログを表示します。文言は「何が使えないか」ではなく「登録すると何ができるようになるか」を伝えるように設計しました。

アカウント削除フローを多段階にして安心と確実を両立

アカウント削除フローは「確認ダイアログ→パスワード再入力→ローディング→完了」の多段階構成です。確認ダイアログでは「何が消えるのか」「何が残るのか」を具体的に記載し、チャット履歴は相手側に残ること、この操作は取り消せないことを明示しました。誤操作を防ぐために手間は増やしつつも、不安を与えないよう情報を十分に開示するバランスを取っています。

ボトムナビとFABを片手で扱える位置に置く

ボトムナビは「ホーム・マイノート・検索・マイページ」の4タブで、利用頻度の高い順に左から並べました。主要なアクション（ノート追加のFAB、通知ベル、チャットアイコン）は、片手操作で指が届く位置に配置しています。時間割の保存ボタンは最初AppBarの右上に置いていましたが、実機テストで「押しにくい」と分かった段階で画面下部の大きなボタンに移動しました。設計より、実機で触ったときの違和感を信じる姿勢を大切にしています。

管理画面は俯瞰性を最優先に、アプリとブランド一貫性を保つ

運営側の管理画面はReact＋shadcn/uiで構築しました。ユーザー・ノート・通報・コメント・チャットの各管理機能をサイドバーで切り替えるダッシュボード構成にし、一覧画面ではテーブル形式で一度に多くの情報を俯瞰できるようにしています。

配色はアプリ側と揃え、プライマリの紺やアクセントのアンバーを共通化することで視覚的な一貫性を保ちました。一方で操作体系は意図的に差をつけており、アプリはカード型のモバイルファーストUI、管理画面はテーブル中心のデスクトップ向けUIと、それぞれの利用シーンに最適な設計を採用しています。「同じブランドだが、別の道具」として設計したことで、両者が干渉せず、それぞれの役割を最大化できました。

開発を通じて学んだこと・まとめ

メディカルサークルの開発を振り返ると、「信頼感を作る」という最初の問いがいかに多くの設計判断を規定したかがよく分かります。

デザインシステムの策定は、単なる見た目の統一ではありませんでした。余白・色・フォントの制約を設けることで、画面が増えても見た目が散らからず、「作り込まれたアプリだ」という印象がユーザーの信頼につながります。

課金実装においては、RevenueCatというツールを使うこと自体より、Identifierの不変性を理解した命名設計、Firestoreとの二重反映による安全なルール構成、画面横断の一元制御という設計の丁寧さが重要でした。ツールの使い方より、その周辺の設計思想こそが品質を決めます。

コミュニティ安全機能では、技術的な実装の前に「何を守るのか」を明確にすることの重要性を学びました。通報・ブロック・非表示・セキュリティルール・UI誘導という5つのレイヤーを重ねることで、どれか1つが突破されても他が機能する多重防御が実現できます。

画面体験の設計では、実機テストで得られる「違和感」が設計書よりも正直だということを改めて実感しました。AppBarに置いた保存ボタンが押しにくかった、ゲスト誘導の文言が登録を急かす印象を与えていたなど、実機を触ることで初めて見えてくる課題がありました。

SNS・コミュニティ・課金機能を組み合わせたアプリを開発する事業者にとって、メディカルサークルの事例が示す最大の教訓は以下の点です。

• デザインシステムは後から整備しようとすると手戻りが大きい。初期段階でルールを固め、全員が守る運用に落とし込むことが長期の品質を保証する。
• 課金とセキュリティルールは必ず連動させる。クライアント側の状態管理だけに頼ると、セキュリティの抜け穴が生まれる。
• コミュニティの安全は機能1つでは成立しない。複数レイヤーを重ねる設計が必要であり、その設計は機能開発と並行して最初から行うべきだ。
• 有料機能の誘導は押し付けがましさとのバランスが命。コンバージョンを焦ると体験が損なわれ、長期的なリテンションに悪影響を与える。

医療×学術というニッチな市場でのコミュニティアプリ開発は、ユーザーへの誠実さを一切妥協できない領域です。その厳しさが、設計の密度を高め、結果的により良いプロダクトを生み出しました。同じ志を持つ事業者が同様の挑戦をするとき、この記事が少しでも参考になれば幸いです。