DEVELOPMENT PLAN DOCUMENT
AI口コミ促進アプリを社内システムとして開発する場合の
開発プラン検討書
「クチラク」（キャンター合同会社提供）のLPを参考に、同様のコンセプト＝「来店客のアンケート回答からAIがGoogle口コミの下書きを自動生成し、QRコード1枚で運用できる口コミ促進アプリ」を、社外への販売を目的としない社内システムとして開発する場合に必要な検討事項を整理しました。外部課金は発生させず、自社が運営する各院（拠点）ごとに個別のログインアカウントを発行し、院単位でデータを分離管理する前提で、要件・機能・システム構成・データ設計・AI設計・法務リスク・開発工程・コスト感を検討しています。
01 対象サービスの概要整理
LPの構造化データ（schema.org）およびOGP画像から読み取れる、対象サービスの提供価値・機能と、社内システム化にあたっての運用条件の整理
提供価値（コアバリュー）
- 来店客がQRコードを読み取り、60秒程度の簡易アンケートに回答
- AIが回答内容（評価・タグ）からGoogle口コミの下書き文面を自動生成
- 来店客は生成文面をコピーし、Google口コミ投稿ページへワンタップ遷移して投稿
- 店舗側は初期費用ゼロ・QRコード設置のみで運用開始でき、複数店舗も一元管理できる
LP記載の主要機能（featureList）
対象業種イメージ：歯科クリニック・動物病院・飲食店など、Google検索/マップ経由の集客比重が高い小規模店舗
参考LP（外部販売SaaS）と自社版（社内システム）の違い
| 観点 | 参考LP（クチラク） | 自社版（本プラン） |
|---|---|---|
| 利用対象 | 社外の任意の店舗・施設（他社への販売） | 自社が運営する各院（拠点）のみ |
| 料金 | Lite ¥3,000／Standard ¥4,500（月額課金） | 課金なし（社内システムとして無償提供） |
| アカウント管理 | 契約店舗ごとにセルフサインアップ | 本部（情報システム部門等）が各院ごとに個別アカウントを発行 |
| 決済機能 | クレジットカード決済（Stripe等）が必要 | 不要（決済・プラン管理機能は開発対象外） |
※本プランでは課金・決済に関わる機能一式（プラン管理、請求、決済代行連携等）を開発スコープから除外し、その分のコスト・工数を各院への展開・権限管理・セキュリティ強化に充当する方針とします。
02 自社開発の方針
同一サービスの模倣ではなく「同種のコンセプトを、自社の顧客基盤・強みに合わせて再設計する」方針とする
独自ブランド・社内呼称として企画
「クチラク」という名称・デザイン・商標は他社サービスであるため、機能コンセプトを参考にしつつ、名称・UI・ロゴは完全に独自の社内システムとして新規設計する。
MVPから段階リリース
まず1院でAI下書き生成〜QR運用まで動く最小構成を作り、複数院展開・分析機能は後続フェーズで拡張する。
ガイドライン準拠を設計に内在化
Googleの口コミポリシーおよび景品表示法（ステマ規制）への抵触リスクを、後付けではなく機能設計段階から織り込む（詳細は8章・12章）。
課金機能は開発せず、院別ログインに投資
プラン管理・決済連携は開発スコープから外し、各院ごとの個別アカウント発行・権限管理・データ分離の設計に開発リソースを重点配分する。
03 機能要件一覧
利用者を「エンドユーザー（来店客・患者等）」「各院担当者（院ごとの個別ログイン）」「本部管理者（全院横断管理）」の3種に分け、それぞれの機能を整理
- QRコード読み取り→アプリDL/会員登録不要でアンケートページに直接アクセス
- 星評価＋タグ選択（例：接客・清潔感・味・待ち時間 等）による簡易回答（30〜60秒目安）
- 任意の自由記述欄
- 回答内容をもとにAIが口コミ下書き文を複数パターン生成し提示
- 文面を自由に編集した上でコピーし、Google口コミ投稿画面へ遷移（投稿操作自体は本人がGoogle上で行う）
- 低評価回答時は口コミ投稿への誘導を行わず、店舗宛の非公開フィードバックフォームに切り替え
- 院ごとに発行された個別アカウントでログイン（院ID＋パスワード、または社内SSO連携）
- ログイン後は自院のデータのみ閲覧可能（他院のデータは権限上参照不可）
- 院プロフィール設定（院名、診療科目・業種、Google Business Profileの口コミ投稿URL登録）
- アンケート設問設計（標準テンプレート＋業種別タグ、必要に応じ院独自のカスタム設問）
- QRコード発行・ダウンロード（受付・診察室など設置場所別に複数発行）
- 自院の回答一覧・AI生成文のログ閲覧
- 自院の分析ダッシュボード（回答数推移、平均評価、タグ別傾向、口コミ遷移率）
- CSVエクスポート、院ロゴ・カラーの表示カスタマイズ
- パスワード再設定・院内スタッフへの利用案内資材ダウンロード
- 院マスタ管理（新規院の登録、院ごとの個別アカウント発行・停止・パスワードリセット）
- 全院横断の利用状況モニタリング（院ごとの回答数・口コミ転換率の比較、未活用院の把握）
- サポート対応用の代理ログイン（各院担当者からの問い合わせ対応）
- AI API利用量・コストモニタリング、レートリミット管理（全院合算の予算管理）
- 不適切コンテンツ（誹謗中傷・虚偽記載の疑いなど）の監視・通報対応
04 利用者フロー
来店客がQRコードを読み取ってから口コミ投稿に至るまでの体験設計
※ポイントは「投稿ボタンを自動で押す」のではなく、必ず本人が内容を確認・編集し、Google上で自らの意思で投稿する設計にすること（Googleガイドライン・法令対応上の必須要件。詳細は8章・12章）。
05 システム構成（アーキテクチャ案）
静的コンテンツ配信＋API＋LLM連携を組み合わせた、院ごとの個別ログイン・データ分離を前提とする社内システム構成（決済機能は含まない）
06 データモデル設計（主要テーブル）
RESTful Table APIまたはPostgreSQLを想定した論理設計イメージ（課金関連の項目は持たず、院ごとのログイン・権限制御に必要な項目を中心に設計）
organizations（自社/運営主体）
| id | 組織ID（原則自社のみの1レコード） |
| name | 組織名（法人名） |
| admin_contact | 本部管理者の連絡先 |
stores（院・拠点）
| id | 院ID |
| organization_id | 所属組織（自社） |
| name / category | 院名／診療科目・業種 |
| google_review_url | Google口コミ投稿直リンク |
| is_active | 院の稼働状況（新設・休止等） |
| brand_color / logo_url | 院ロゴ・カラー表示用（任意） |
users（院ごとの個別ログインアカウント）
| id | ユーザーID |
| organization_id | 所属組織（自社） |
| store_id | 紐づく院ID（本部管理者はnull＝全院参照可） |
| email / role | ログインメール／権限（hq_admin・store_staff） |
| last_login_at | 最終ログイン日時（利用状況把握用） |
qrcodes（QRコード）
| id | QR ID |
| store_id | 紐づく院 |
| label | 設置場所ラベル（卓番等） |
| survey_id | 誘導先アンケート |
| scan_count | スキャン数（分析用） |
surveys / survey_questions
| survey.id | アンケートID |
| survey.store_id | 対象院 |
| question.type | 星評価／タグ選択／自由記述 |
| question.tag_options | 選択肢タグ一覧 |
survey_responses / review_drafts
| response.id | 回答ID |
| response.rating | 星評価 |
| response.selected_tags | 選択タグ（配列） |
| draft.generated_text[] | AI生成文面（複数案） |
| draft.was_copied | コピー実行有無（転換率算出用） |
※本人特定につながる氏名・連絡先は「口コミ生成」用途では原則取得しない設計を推奨（個人情報保護の観点、および回答ハードルを下げる観点の両方から）。※課金・プラン管理に関するテーブル（サブスクリプション、請求情報等）は本システムでは不要なため設計対象外です。
07 AI（生成）設計
本サービスの中核となる「回答→口コミ下書き生成」ロジックの設計方針
入出力設計
- 入力：星評価、選択タグ（複数可）、任意の自由記述、店舗の業種情報
- 出力：トーン違いの下書き文を2〜3パターン生成（丁寧調／親しみやすい調 等）
- 文字数は実際のGoogle口コミの平均的な長さ（100〜250字程度）に最適化
- 生成結果はその場で編集可能なテキストエリアに表示し、そのままコピー
プロンプト設計上のガードレール
- 回答者が選択・入力した事実の範囲内でのみ生成し、事実にない体験を創作させない
- 医療・健康効果等の断定的表現、誇大表現を禁止するルールをシステムプロンプトに組込み
- 差別的表現・個人名・第三者の誹謗中傷につながる語句をフィルタ
- 「必ずこの文章のまま投稿してください」等、誘導・強制を示唆する文言をUI・生成文双方に含めない
生成処理シーケンス
system: あなたは店舗の口コミ下書き作成を支援するアシスタントです。 制約: - ユーザーが入力・選択した情報の範囲内でのみ文章を作成すること - 事実として述べられていない体験や効果を創作しないこと - 差別的表現、個人を特定する情報、誹謗中傷を含めないこと - 断定的な効果効能の表現（治った、必ず良くなる 等）は使用しないこと - 100〜250文字程度、自然な一人称の口コミ文体で3パターン生成すること - 投稿を強制・誘導するような文言は一切含めないこと
08 非機能要件・法務対応
この種のサービスで特に重要になる、法令・プラットフォームポリシー対応の要件
景品表示法（ステマ規制）
2023年施行の指定告示により「事業者が第三者に依頼して口コミを投稿させる行為」で表示であることを隠すものは規制対象。本サービスは「来店客自身の体験に基づく投稿を支援する」設計に徹し、金銭的インセンティブと引き換えに投稿を依頼する運用は避ける必要がある。
Googleの口コミに関するポリシー
「やらせ・誘導コンテンツ」「見返り提供によるレビュー依頼」を禁止。低評価者を意図的に投稿から除外する設計（本設計の分岐フロー）は業界で一般的だが、レビュー内容の改ざん・自動投稿は厳禁。必ず本人の確認・編集・実投稿を挟む。
個人情報保護
氏名・連絡先等の直接識別情報は原則取得しない設計を基本とする。取得する場合は個人情報保護法に基づくプライバシーポリシー整備、利用目的の明示、安全管理措置（暗号化・アクセス制御）が必要。
可用性・性能
QRスキャンからアンケート画面表示まで3秒以内を目標。LLM応答は数秒かかるため、ローディングUI・タイムアウト時のフォールバック文面を用意する。
セキュリティ
通信のTLS化、社内ネットワーク（VPN／IP制限）からのみ管理画面へアクセス可能とする構成の検討、管理画面へのアクセスログ記録。決済情報を扱わないため、カード情報の保持・PCI DSS対応は不要。
院間データ分離・アクセス制御
院ごとの個別ログインアカウントにstore_id（院ID）を紐づけ、自院以外のデータには一切アクセスできないよう認可制御を行う。本部管理者のみ全院横断の閲覧権限を持つロール設計とする。
アクセシビリティ／端末対応
来店客側画面はスマートフォンでのタップ操作を前提としたレスポンシブ・大きめタップ領域のUI。高齢層利用も想定し文字サイズ・コントラストに配慮。
09 技術スタック案
課金機能を持たない社内システムとして、早期リリース・低運用コストを重視した構成例
| レイヤー | 候補技術 | 採用理由 |
|---|---|---|
| フロントエンド | Next.js（React）+ TypeScript + Tailwind CSS | SEO対応・表示速度・開発効率のバランスが良く、SPA/SSR/PWA構成に対応しやすい |
| バックエンドAPI | Node.js(NestJS) または Python(FastAPI) | LLM APIとの連携ライブラリが豊富。型安全なAPI設計が可能 |
| データベース | PostgreSQL（Supabase等のマネージドサービス活用可） | リレーショナルなマルチテナント設計に適し、Row Level Securityも利用可能 |
| 認証 | Supabase Auth / Auth0 / Firebase Auth（または社内SSO連携） | 院ごとの個別アカウント発行・失効を管理しやすく、自前実装よりセキュリティリスクを低減 |
| 生成AI | OpenAI GPT系 / Google Gemini / Anthropic Claude（比較検討） | 日本語自然文生成の品質とAPIコストで比較し、複数プロバイダの併用も検討 |
| QRコード生成 | qrcodeライブラリ等によるサーバー/クライアント内製生成 | 外部APIに依存せずコストゼロで生成・カスタマイズ可能 |
| 分析ダッシュボード | Chart.js（自前実装） | 回答数推移・タグ別集計など基本分析を軽量に実装可能 |
| インフラ／ホスティング | Vercel（フロント）＋ AWS/GCP（API・DB） | スケーラビリティと運用のしやすさを両立 |
10 開発工程・マイルストーン（目安）
要件精査後に確定させる想定のたたき台スケジュール（決済機能の開発が不要なため、その分の工数を院展開・権限管理に充当。全体でおよそ5〜7ヶ月）
Phase 0（約1.5ヶ月）
要件定義・法務確認・UI設計。ここで社内システムとしての名称、対象となる院の範囲、展開スケジュールを確定。
Phase 1（約2ヶ月）
MVP開発。1院でQR→アンケート→AI生成→Google遷移までの一気通貫フローを実装。
Phase 2（約1.5ヶ月）
分析ダッシュボードと、院ごとの個別ログイン・データ分離の基盤を実装。
Phase 3-4（約1.5ヶ月）
院マスタ・アカウント発行フローを整備し、少数院でのベータ運用を経て全院展開。
11 開発体制・概算コスト（社内投資）
本システムは課金を行わないため、開発・運用コストはすべて自社（本部）負担の投資となる。あくまで規模感を掴むための目安であり、実際の金額は要件確定後の見積もりで確定させる
想定チーム体制
- プロダクトマネージャー：1名（要件整理・優先度管理）
- UI/UXデザイナー：1名
- フロントエンドエンジニア：1〜2名
- バックエンドエンジニア：1〜2名（AI連携含む）
- QA／テスター：1名（フェーズにより兼任可）
概算開発費用レンジ（目安）
| MVP（Phase 0-1） | 約 250万〜500万円 |
| 全院展開込みフル版（Phase 2-4） | 約 600万〜1,200万円 |
| 月額ランニングコスト | 約 3万〜15万円（対象院数・回答数により変動） |
※決済・プラン管理機能を開発対象外としたことで、参考LP同等のフル機能版と比べコスト・工数を抑制できる見込み。外部委託か内製か、既存基盤の流用有無によっても大きく変動するため、参考値として利用してください。
ランニングコスト内訳イメージ（決済手数料は発生しない想定）
12 リスク・留意点
開発着手前に経営判断として整理しておくべき論点
口コミ誘導の適法性・プラットフォームポリシー遵守
「AIが口コミを代筆する」設計自体が、運用次第ではGoogleポリシー違反や景品表示法上の懸念を招く可能性がある。必ず「本人の実体験に基づく下書き支援」「投稿は本人の自発的意思」という建付けを崩さない機能・UI・利用規約設計にすること。導入前に弁護士等への確認を推奨。
商標・意匠との抵触回避
「クチラク」は既存事業者（キャンター合同会社）の商標・サービスであるため、社内システムであっても名称・ロゴ・UIデザインをそのまま使用することはできない。機能コンセプトのみを参考にし、名称・デザインは独自に企画する。
生成AIの品質・コスト変動リスク
LLM APIの料金改定・モデル廃止に対応できるよう、特定ベンダーに強く依存しない抽象化レイヤーを設計しておく。生成文の品質担保のため、人手によるレビュー・フィードバックループも用意する。
院ごとのアカウント発行・運用定着化の負荷
院数が増えるほど、アカウントの発行・失効（異動・退職対応含む）や各院への利用定着の働きかけが本部側の運用負荷になる。院展開のロールアウト計画と、問い合わせ窓口・マニュアル整備をセットで用意する必要がある。
医療・診療関連情報を扱う場合の取り扱い厳格化
対象が医療機関（院）の場合、アンケート回答が症状・通院目的等の要配慮個人情報に触れる可能性がある。取得項目を必要最小限にし、症状等の医療情報は取得しない設問設計とするなど、通常の口コミサービス以上に慎重な設計が求められる。
13 次のアクション（提案）
- 1対象となる院の範囲（全院／一部院から開始）と展開スケジュールを明確化する
- 2景品表示法・Googleポリシーの適法性、および医療情報の取り扱いについて、弁護士や専門家に一次確認を取る
- 3本ドキュメントの機能要件を基に、詳細な画面設計（ワイヤーフレーム）と院ごとのアカウント発行フローを作成する
- 4LLM APIプロバイダを選定し、プロンプトのプロトタイプ検証（PoC）を行う
- 5MVPスコープを確定し、社内予算承認を得た上で開発会社または内製チームへの見積もり依頼を行う
14 本番移行ロードマップ・優先順位
現在のモック（静的サイト＋Table API＋localStorage認証＋擬似AI生成）を本番の社内システムへ移行するにあたり、着手すべき項目を優先度3段階に整理し、それぞれの技術要件・実装方針・想定工数の目安をまとめました。🔴必須はリリース前に必ず対応が必要な項目、🟡重要はリリース前後で対応すべき項目、🟢中長期は運用が安定した後に段階的に強化する項目です。
🔴 必須（Phase 1）
4項目
本番公開の前提条件。ここが未対応のままの一般公開は情報漏えい・法的リスクが高く推奨しない。
🟡 重要（Phase 2）
3項目
全院展開の前後で対応。Phase1と並行着手も可能だが、展開院数が増える前に完了させたい。
🟢 中長期（Phase 3）
3項目
運用開始後、データが蓄積してから段階的に投資すればよい項目。初期リリースのブロッカーにはしない。
着手順序イメージ（マイルストーンは目安であり、体制・予算により前後します）
※LLM API連携・認証基盤刷新は本番リリースのコア部分であり、最初に並行着手することを推奨します。法務レビューは結果待ちで開発がブロックされないよう、できるだけ早期に相談を開始してください。
Phase 1：🔴 必須（本番リリースの前提条件）
① 認証基盤の刷新
想定工数：2〜3週間✅ 対応済み：Supabase Auth（Email/Password）への移行が完了しました。ログインIDはメールアドレス形式に変換して認証し、パスワードはSupabase側でハッシュ化・安全に管理されます。Row Level Security（RLS）による院ごとのデータアクセス制御も導入済みです。詳細はREADME.mdの「Supabase移行（進行中）」セクション、およびsupabase/schema.sqlを参照してください。
技術要件・実装方針
- Supabase Auth / Firebase Authentication / Auth0 等の認証SaaSを採用（自前でパスワードハッシュ管理を実装しない）
- 院（store）ごとにアカウントを発行し、ロール（本部管理者 / 院スタッフ）を持たせたRBAC設計
- パスワードリセット・初回パスワード変更強制・セッション有効期限（例：8時間）・多要素認証（本部アカウントのみ推奨）
- 本部ダッシュボード（hq-dashboard.html）と院管理画面（store-dashboard.html）でアクセス権限を分離
対応すべき理由・リスク
localStorageは端末に平文で残り、開発者ツールから誰でも閲覧・改ざん可能。院IDを差し替えれば他院データにアクセスできてしまうため、実データを扱う前に必ず刷新が必要。
② DB側アクセス制御（Row Level Security）
想定工数：2週間現状：Table APIはプロジェクト単位のフラットなテーブルであり、フロントのJSがstore_idで絞り込んでいるだけ。API自体は他院のレコードも取得・更新できてしまう「アプリ側だけの論理分離」。
技術要件・実装方針
- PostgreSQL（Supabase等）に移行し、
RLS（Row Level Security）ポリシーで「自院のstore_idの行しか読み書きできない」制約をDB側で強制 - 認証基盤のJWTに含まれる
store_id／ロールクレームとRLSポリシーを連携 - 本部ロールのみ全院横断参照を許可するポリシーを別途定義
- API呼び出しはサーバーサイド（Edge Function）経由に統一し、フロントから直接書き込み権限を持たせすぎない設計に
対応すべき理由・リスク
アプリ側のフィルタだけでは、API URLを直接叩かれた場合に他院の口コミ回答・タグ設定などが閲覧・改ざんされるリスクがある。実データ（顧客の回答内容）を扱う以上、DB側での強制分離は必須。
③ LLM API連携（サーバーサイド化）
想定工数：3〜4週間現状：js/ai-mock.jsによる疑似乱数（xorshift32）を使った文章生成。本物のLLMは呼んでおらず、辞書ベースの言い回しパターンを組み合わせているのみ。
技術要件・実装方針
- OpenAI API / Google Gemini API / Anthropic Claude API等から選定（コスト・日本語品質・レイテンシで比較検討）
- APIキーはフロントに絶対に埋め込まないため、Supabase Edge Function / Cloudflare Workers等のサーバーレス関数を1つ用意し、フロントはそこにPOSTするだけの構成に変更
- プロンプトには評価点・選択タグ・自由記述・院名のみを渡し、症状等の医療情報は渡さない設計を徹底
- 生成結果の文字数・NGワード（誹謗中傷、医療効能を断定する表現等）を簡易フィルタリングするガードレイヤーを追加
- API障害時は現行の疑似生成ロジック（ai-mock.js）にフォールバックできるようにしておくと可用性が高い
対応すべき理由・リスク
「AIによる下書き生成」がこのサービスの中核価値であり、擬似生成のままでは文章のバリエーション・自然さに限界がある。一方でAPIキーを静的サイトに直書きすると即座に不正利用されるため、必ずサーバー経由の構成にする必要がある。
④ 個人情報・ログ取り扱い整備
想定工数：1〜2週間現状：モックのためプライバシーポリシー表示・同意取得・ログ保持ポリシーは未整備。
技術要件・実装方針
- アンケート画面にプライバシーポリシーへのリンクと、送信前の同意チェック（任意項目である旨も明記）を追加
- 通信は全ページHTTPS化（ホスティングサービス側で標準対応されることが多いが要確認）
- 回答データ・アクセスログの保持期間（例：24ヶ月）を定め、期限超過分を自動削除するバッチ処理を用意
- 症状・既往歴等の要配慮個人情報は設問に含めない（既に自由記述はあるため、注意文言＋簡易NGワード検知を追加）
対応すべき理由・リスク
実在の顧客（飼い主）情報を扱う以上、個人情報保護法・社内規程への準拠は必須。特に動物病院は診療内容に触れる自由記述が集まりやすく、要配慮情報の混入対策が重要。
Phase 2：🟡 重要（展開前後で対応）
⑤ Googleポリシー・景品表示法レビュー
想定工数：外部依頼含め3〜4週間現状：チャット上の検討のみで、専門家レビューは未実施。
技術要件・実装方針
- 顧問弁護士 or 法務担当に「AI下書き支援＋任意投稿」の建付けで確認を依頼（社内システムのため景品提供は無しの想定を明記）
- Googleのレビューガイドライン（やらせ・虚偽レビューの禁止、投稿の自発性）への抵触有無を確認
- 結果を踏まえ、アンケート画面・印刷ポスターの文言（「AIが作成した文章はあくまで下書きです。投稿するかどうか、内容を編集するかは自由です」等）を最終調整
対応すべき理由・リスク
法務レビューは結果が出るまで時間がかかるため、Phase1と並行して早期に着手すべき。レビューの結果次第でUI文言修正が発生する可能性がある。
⑥ QRコード物理印刷・院内運用の整備
想定工数：1〜2週間現状：A4ポスター印刷ページ（qr-print.html）は完成済み。各院への配布・掲示ルールは未整備。
技術要件・実装方針
- 院ごとの掲示場所（レジ横・待合室等）のガイドラインを作成し、簡易マニュアルをPDF化
- ラミネート加工や卓上スタンド設置など、物理的な運用方法を本部側で標準化
- QRコードの読み取り動線（アンケート画面URL）の有効期限・更新運用（院閉鎖・移転時の差し替えフロー）を決めておく
対応すべき理由・リスク
機能自体は完成しているが、実際に院スタッフが迷わず印刷・掲示できないと利用が定着しない。展開院数が増える前にルール化しておくと後の問い合わせ対応コストを抑えられる。
⑦ 各院Google口コミURLの整備（残り10院）
想定工数：数日〜1週間現状：38院中28院はスプレッドシートの情報をもとに登録済み。残り10院は未登録（Google口コミへの自動遷移が機能しない状態）。
技術要件・実装方針
- 各院のGoogleビジネスプロフィールから「クチコミを書く」の短縮URL（
https://g.page/r/.../review）を本部側で収集 - 各院の院管理画面（store-dashboard.html）から院自身でも登録・修正できる導線は実装済みのため、未登録院への入力依頼を並行して進める
- 収集後はTable APIで
stores.google_review_urlへ一括登録
対応すべき理由・リスク
URL未登録の院では「コピー後にGoogle口コミページへ自動遷移する」体験が提供できず、機能の一部が使えないまま展開されてしまう。全院展開前に完了させたい。
Phase 3：🟢 中長期（運用安定後に強化）
⑧ 分析機能さらなる強化
想定工数：継続的（1ヶ月〜）現状：本部ダッシュボードに期間フィルター・低評価アラート・院別集計を実装済み。
技術要件・実装方針
- 自由記述テキストへの感情分析・頻出キーワード抽出（LLM APIまたは形態素解析ライブラリを活用）
- 院別・タグ別のトレンド推移（週次・月次）を可視化するレポート機能
- 低評価アラートのメール／チャット通知（Slack Webhook等、CORS対応かつ認証不要なWebhookに限定）
対応すべき理由・リスク
初期リリース時点ではデータ量が少なく分析価値が限定的。運用開始後にデータが蓄積してから投資対効果を見て強化するのが効率的。
⑨ サーバーサイド永続化・バックアップ体制
想定工数：1〜2週間現状：Table API（モック環境の行データベース）にデータを保持。本番グレードのバックアップ・障害復旧計画は未整備。
技術要件・実装方針
- Supabase / Firebase 等マネージドDBへの本移行（Phase1のRLS実装と合わせて実施すると効率的）
- 自動日次バックアップ・Point-in-Time Recoveryの設定
- 障害復旧手順（RTO/RPOの目標値設定）をドキュメント化
対応すべき理由・リスク
DB移行自体はPhase1（RLS）とほぼ同時に行うのが効率的だが、バックアップ・DR計画の整備は運用が軌道に乗ってから段階的に厳格化しても問題ない。
⑩ 監視体制の構築
想定工数：1週間現状：エラー監視・稼働監視の仕組みはなし。
技術要件・実装方針
- フロントエンドエラー監視（Sentry等）を導入し、JSエラー・API失敗を可視化
- LLM API・DBの稼働監視（UptimeRobot等の外形監視、Edge Functionのログ監視）
- アラート発生時の一次対応フロー（誰が・どこに通知されるか）を明文化
対応すべき理由・リスク
利用院数が少ない初期段階では手動確認でも回せるが、展開院数が増えるにつれ障害検知の遅れが機会損失に直結するため、Phase3のうちでも早めの着手が望ましい。
優先順位サマリー表
| 優先度 | 項目 | 現状 | 想定工数 | 主な技術要素 |
|---|---|---|---|---|
| 🔴必須 | ①認証基盤刷新 | localStorage簡易認証 | 2〜3週間 | Supabase Auth / Auth0 / RBAC |
| 🔴必須 | ②DBアクセス制御(RLS) | アプリ側フィルタのみ | 2週間 | PostgreSQL RLS / JWTクレーム連携 |
| 🔴必須 | ③LLM API連携 | 疑似乱数生成(ai-mock.js) | 3〜4週間 | OpenAI/Gemini API + Edge Function |
| 🔴必須 | ④個人情報・ログ整備 | 未整備 | 1〜2週間 | 同意UI / 保持期間ポリシー / HTTPS |
| 🟡重要 | ⑤法務・ポリシーレビュー | チャット検討のみ | 3〜4週間 | 弁護士確認 / 文言調整 |
| 🟡重要 | ⑥QR印刷運用整備 | 印刷ページのみ完成 | 1〜2週間 | 運用マニュアル / 掲示ルール |
| 🟡重要 | ⑦口コミURL整備(残10院) | 28/38院登録済み | 数日〜1週間 | 院管理画面から入力 / Table API一括更新 |
| 🟢中長期 | ⑧分析機能強化 | 基本集計・アラート実装済み | 継続的 | 感情分析 / レポート機能 / 通知連携 |
| 🟢中長期 | ⑨永続化・バックアップ | モックTable API | 1〜2週間 | マネージドDB移行 / 自動バックアップ |
| 🟢中長期 | ⑩監視体制構築 | 未整備 | 1週間 | Sentry / 外形監視 / 通知フロー |
※工数は1〜2名体制での目安であり、要件確定度・既存基盤の有無により変動します。Phase1の①〜④は並行着手が可能なため、合計期間は単純合計ではなく最長路（LLM API連携：3〜4週間）を目安にするとよいでしょう。