# 言問散歩 名店DB → 現場CRM 設計書

**作成：** 2026-06-06  
**作成者：** CTO（エンジニアリング大臣）  
**前提データ：** meiten-master.json v1.0.0（106社）  
**位置づけ：** CEO要望（多人数モバイル営業CRM）への技術設計回答  
**決裁ゲート：** プラットフォーム選定・月額予算・ユーザー範囲 の3点はCEO決裁必須

---

## 1. プラットフォーム比較（MECE）

### 比較軸の定義

| 軸 | 重み | 理由 |
|---|---|---|
| モバイル体験 | 高 | 社員・契約社員がスマホで使う → 死活問題 |
| 編集容易性 | 高 | 担当者がその場で記録できること |
| 多人数/権限管理 | 高 | 9名＋契約社員、編集者/閲覧者を分ける |
| AI/HQからの読み書き | 高 | ニュース紐づけ自動化の前提 |
| 既存Glide資産との親和 | 中 | チームのGlide経験活用 |
| 写真添付 | 中 | 訪問記録に現場写真を添付 |
| コスト | 中 | 無料開始→有料判断の余地 |
| オフライン | 低 | 台東区内の移動なのでほぼ圏内 |

---

### 選択肢A：Glide（+ Google スプレッドシート）

**概要：** 正本をGoogleスプレッドシートに置き、Glideがノーコードでモバイルアプリ化する。言問手形アプリと同じスタック。

| 軸 | 評価 | 備考 |
|---|---|---|
| モバイル体験 | A | PWA/ネイティブ感。スマホ専用設計 |
| 編集容易性 | A | フォームUI（訪問記録1タップ）が簡単に作れる |
| 多人数/権限管理 | B | Glide Users機能でロール設定可。GlideのTeamプランでメンバー招待 |
| AI/HQからの読み書き | A | スプレッドシートをバックエンドにすればOAuth Desktop App方式で直接読み書き可 |
| 既存Glide資産との親和 | A | 言問手形チームがGlide経験あり。共通UIコンポーネント流用可 |
| 写真添付 | A | Glideはネイティブで写真アップロード対応（Google Drive保存） |
| コスト（要確認） | B | Makerプラン$49/月〜（要確認）。無料枠は機能制限あり |
| オフライン | C | オフライン非対応（ただし本件では不要） |

**コスト（要確認・2026-06時点の公式料金を確認すること）：**
- Free：シングルユーザー相当。多人数は実質不可
- Maker：$49/月（要確認）。複数ユーザー・パブリックアプリ対応
- Team：$99/月（要確認）。権限管理・ロール機能
- Business以上：$249/月〜（要確認）

**メリット：**
- チームのGlide経験が即活きる（立ち上げ工数が最小）
- Google スプレッドシートが正本なのでHQからOAuth方式で読み書き可
- スプレッドシートをCEOが直接確認・修正できる（非エンジニアに優しい）
- 言問手形との統合的なUI世界観を作りやすい

**デメリット：**
- 月額課金必須（無料枠は実運用に使えない）
- Glide自体の将来性・プラン変更リスク（ノーコードSaaS共通の問題）
- 複雑なリレーション（複数テーブルのJOIN）が制限される場合あり

---

### 選択肢B：Google AppSheet

**概要：** Google Workspace内のノーコードアプリビルダー。スプレッドシートをバックエンドに。

| 軸 | 評価 | 備考 |
|---|---|---|
| モバイル体験 | B | PWAだが、GlideよりUIの洗練度は低い |
| 編集容易性 | B | フォーム機能あり。設定は少し複雑 |
| 多人数/権限管理 | A | Google Workspaceのアカウントで自然に管理 |
| AI/HQからの読み書き | A | バックエンドがスプレッドシートなのでOAuth方式と完全互換 |
| 既存Glide資産との親和 | C | 別スタック。チームの再学習が必要 |
| 写真添付 | A | 写真添付・Drive保存対応 |
| コスト | A | Google Workspace契約内で追加課金なし（要確認：Starterプランで利用可かどうか） |
| オフライン | A | オフラインモード対応 |

**コスト：**
- Google WorkspaceのEnterprise以上：AppSheet Core含む（要確認）
- それ以外：AppSheet Core $10/ユーザー/月（要確認）

**メリット：**
- Google Workspaceアカウント（会社アカウント）でシームレスにログイン
- スプレッドシート連携が最も自然
- Workspaceプランによっては追加コスト0

**デメリット：**
- **会社Googleアカウント = GASがブロックされる環境では、AppSheetのデプロイ・権限設定でも制約が出る可能性がある（要検証）**
- UIの洗練度でGlideに劣る
- Glide経験が活きない

---

### 選択肢C：Notion

**概要：** ドキュメント+DB複合ツール。訪問記録や情報メモとの親和性が高い。

| 軸 | 評価 | 備考 |
|---|---|---|
| モバイル体験 | B | アプリ有り。編集は可能だが営業CRM的な「1タップ入力」には向かない |
| 編集容易性 | B | ページ形式の自由度は高いが、フォーム的なUXは弱い |
| 多人数/権限管理 | B | ページ/DB単位の権限設定あり |
| AI/HQからの読み書き | B | Notion API経由で読み書き可能。ただし構造がスプレッドシートより複雑 |
| 既存Glide資産との親和 | D | 全く別スタック |
| 写真添付 | A | 写真・ファイル添付は自然にできる |
| コスト | A | Plus $10/メンバー/月（要確認） |
| オフライン | C | オフライン不可 |

**メリット：**
- 情報の「文章+DB」構造がfield_intel（気軽な情報共有）に向いている
- AIによるNotionDB書き込みはNotion MCP経由で既に可能（本HQにMCPあり）

**デメリット：**
- 「訪問記録を1行追加する」というCRM的なUXが苦手
- 106社分のDB移行と構造設計が別途必要
- CRMとして使うには「使い方の徹底」が難しい

---

### 選択肢D：自前Webアプリ（Next.js + Supabase等）

**概要：** フルスタックWebアプリを一から作る。

| 軸 | 評価 | 備考 |
|---|---|---|
| モバイル体験 | A（設計次第） | 完全自由だが作り込みが必要 |
| 編集容易性 | A（設計次第） | 完全自由 |
| 多人数/権限管理 | A（設計次第） | 完全自由 |
| AI/HQからの読み書き | A | DBに直接書ける |
| 既存Glide資産との親和 | D | 全く別スタック |
| 写真添付 | A | 実装すれば可 |
| コスト | B | Supabase無料枠あり、Vercel無料枠あり。ただし**実装工数が最大** |
| オフライン | A（設計次第） | PWA対応可 |

**結論：overengineering。**  
9名の営業チームのCRMに対して「フルスタックWebアプリを作る」は典型的な過剰実装。Glideで6時間の仕事を、Next.js+Supabaseで200時間かけてやることになる。現フェーズでは選択しない。

---

### 推奨：選択肢A（Glide + Google スプレッドシート）

**理由（1行）：** チームのGlide既存知識＋スプレッドシートのHQ読み書き互換性＋言問手形との世界観統一が、他の選択肢と比べて明確に優位。

**条件：**
- Maker〜Teamプランへの課金がCEO承認されること（月額$49〜99・要確認）
- 会社GoogleアカウントでGlideにログインできること（要検証）
- AppSheetが会社アカウントのWorkspaceプランで追加費用なしで使えることが判明した場合、AppSheetへ切り替えを再検討する価値あり

---

## 2. データモデル

### 全体構造

```
stores（106社・既存）
├── storeId（PK）
├── [既存フィールド全て継承]
├── lastVisitDate（計算：visit_logsから自動）
└── visitCount（計算：visit_logsから自動）

visit_logs（訪問/接触記録）
├── visitId（PK）
├── storeId（FK → stores）
├── rep（担当者名）
├── visitedAt（日時）
├── type（種別：挨拶 / 情報交換 / 商談 / 受注 / 飲食メモ / 電話 / その他）
├── summary（自由メモ・本文）
├── photoUrl（写真URL・Google Drive）
├── nextAction（次アクション・任意）
├── nextActionDate（期日・任意）
└── createdAt（記録日時）

field_intel（気軽な情報共有）
├── intelId（PK）
├── storeId（FK → stores・任意。地域全般情報はnull）
├── rep（投稿者）
├── intelAt（情報を得た日時）
├── source（情報源：飲食中/知人/SNS/現地観察/その他）
├── content（内容・自由記述）
├── relevance（関連性タグ：広告可能性/新規店舗/閉店懸念/イベント/その他）
└── createdAt

news_clips（台東区ニュース紐づけ）
├── clipId（PK）
├── storeId（FK → stores・任意）
├── publishedAt（記事日付）
├── source（出典：媒体名）
├── url（記事URL）
├── headline（見出し）
├── summary（要約・AIが入力可）
├── tags（配列：string[]）
└── addedBy（人間/AI識別）
```

### リレーション図（テキスト表記）

```
stores (1) ───< visit_logs (N)   : 1店舗に複数の訪問記録
stores (1) ───< field_intel (N)  : 1店舗に複数のフィールド情報（任意）
stores (1) ───< news_clips (N)   : 1店舗に複数のニュース（任意）
```

### Glide実装時のシート構成（Googleスプレッドシート）

| シート名 | 用途 | 行数目安 |
|---|---|---|
| stores | 106社マスター（meiten-master.jsonを移行） | 106行＋増分 |
| visit_logs | 訪問記録（新規） | 月30〜50行程度 |
| field_intel | フィールド情報（新規） | 月10〜30行程度 |
| news_clips | ニュースクリップ（AI主導） | 月20〜50行程度 |

---

## 3. アクセス/権限設計

### 社外スマホからの到達問題

**現状の限界：** meiten-db.htmlはTailnet（hq-server.py:8788）配信。Tailscaleに参加していないデバイスからは開けない。社員全員にTailscale参加を求めるのは現実的でない。

**解決策：** GlideはSaaS（Glideのクラウド上にデプロイ）なので、インターネット接続があれば社外スマホから即アクセス可能。Tailscaleは一切不要になる。

### ログイン方法

**推奨：Google OAuth（@gmail.com / 個人アカウント含む）**

会社Googleアカウント（@sanyogroup等）がGAS/AppSheetでブロックされる環境であることを踏まえ、Glideのログインは個人Googleアカウント（gmail.com）でも可能な設定にする。ユーザーリストをGlide側で管理（メールアドレスで招待）。

### 権限ロール（3段階）

| ロール | 対象 | できること |
|---|---|---|
| Admin | CEO・編集長 | 全編集・ユーザー管理・storesマスター変更・削除 |
| Editor | 社員営業（9名） | visit_logs/field_intel/news_clips の追加・自分の記録の編集・stores閲覧（編集は制限） |
| Reader | 契約社員等 | 全閲覧・visit_logs追加のみ（編集/削除不可） |

**storesマスターの直接編集：**  
Glide上では Admin のみ許可。一般社員がstoresに変えたい情報（電話番号更新・閉店等）は visit_logs の「種別：情報交換」に「店が閉店」などメモとして残し、Admin（編集長）が月次でstoresを確認・反映する。これにより「誰かが間違ってマスターを消す」事故を防ぐ。

### 現静的ビューアの位置づけ

**残す（補完的に維持）。** 理由：
1. hq-server.pyの既存インフラを壊さない
2. CTO/CEO等がTailnet内から高速に読み取り専用で確認できる
3. Glideが障害・解約になった際のフォールバック

ただし正本はGoogleスプレッドシートに移行し、meiten-db.htmlは「スプレッドシートから生成する読み取り専用ビューア」という位置づけに格下げする。更新スクリプト（HQの既存OAuth方式）でスプレッドシート→JSONをエクスポートし、meiten-db.htmlが読み込む構成を維持。

---

## 4. コスト試算（3ゲート①・CEO決裁必須）

**注意：** 以下の料金はCTO推計値。Glide公式サイト（glideapps.com/pricing）で必ず確認すること。プラン名・金額は変更されている可能性あり。

### Glide プランと想定コスト（要確認）

| プラン | 想定月額 | ユーザー上限 | 実用可否 |
|---|---|---|---|
| Free | $0 | 制限あり（詳細要確認） | 本件では不可（多人数編集が実質難しい） |
| Maker | 要確認 | 要確認 | 要確認 |
| Team | 要確認 | 要確認 | 9名+契約社員の本格運用に要検討 |
| Business | 要確認 | 要確認 | 過剰の可能性 |

**CTO見解：** Glideは料金改定が頻繁なため、現時点の正確な数字は公式サイトを直接確認すること（2024年に大幅改定あり）。月$49〜99程度であれば年間$600〜1,200（約9〜18万円）。9名の営業チームの情報共有基盤として妥当なコスト水準。

### AppSheetが無料になるケース

会社のGoogle WorkspaceプランがEnterprise Standard以上であれば、AppSheet Coreが含まれる可能性がある（要確認）。もしそうであれば追加費用ゼロでスタートできる。**AppSheetの会社アカウント制約問題が解消されるなら、こちらが最安コストになる。**

### Google スプレッドシート

既存のGoogle Driveスプレッドシートを使うため追加費用なし。

---

## 5. 移行計画

### Phase 0（即実行・無料・1日）

**目標：** 正本をスプレッドシートに置く

1. `meiten-master.json` → Googleスプレッドシートの `stores` シートへ変換スクリプトで一括移行
   - 変換スクリプト（Python・30行以内）：JSONのネスト構造をフラット化し、CSVでDriveにアップロード
   - salesReps（配列）は `rep1_name`, `rep1_issues`, `rep1_note`, `rep2_*` ... とカラム展開
   - tegataFit/hotelEastFitはlevel/reasonをカラム展開
2. スプレッドシートに `visit_logs` / `field_intel` / `news_clips` シートを追加（空）
3. meiten-db.htmlをスプレッドシートから動的に読み込む形に更新（OAuth方式）

### Phase 1（Glide MVP・約6〜8時間）

**目標：** 閲覧＋訪問記録1行追加 が動く

1. Glideプロジェクト作成、スプレッドシートを接続
2. 店舗一覧画面（検索・ラベルフィルタ）
3. 店舗詳細画面（既存フィールド表示）
4. 訪問記録追加フォーム（storeId自動引き継ぎ・rep/type/summary/photo）
5. 訪問記録一覧（店舗詳細から紐づき表示）
6. ユーザー招待（Admin: CEO/編集長 → Editor: 営業9名）

### Phase 2（エンリッチ自動化・1〜2週間）

**目標：** AIがニュースをスプレッドシートに書き込む

- HQのPython（OAuth Desktop App方式）でニュースサイトを巡回
- 台東区関連の記事をnews_clipsシートに自動追記（storeId紐づけはキーワードマッチ）
- field_intel（気軽な情報共有）のGlide画面追加

### Phase 3（高度化・オプション）

- next_actionの一覧ビュー（今週アクション必要な店）
- 担当者別ダッシュボード（自分の担当店の最終接触日）
- 月次集計レポートのGlide表示

### HQ/AIからの読み書き方法

```python
# 概念コード（oauth_sheets_write.py）
# 既存のOAuth Desktop App方式を踏襲
import gspread
from oauth2client.service_account import ServiceAccountCredentials

gc = gspread.authorize(credentials)
sh = gc.open_by_key(SPREADSHEET_ID)
news_sheet = sh.worksheet("news_clips")

# AIが生成したニュースクリップを追記
news_sheet.append_row([
    clip_id, store_id, published_at, source, url, 
    headline, summary, ",".join(tags), "AI"
])
```

---

## 6. 段階導入とMVP

### MVP定義（Phase 1 完了条件）

以下が動けば「使える状態」とみなす：
- [ ] 社員が自分のスマホのブラウザでGlideアプリを開ける
- [ ] storeIdを選んで訪問記録1行を追加できる
- [ ] 追加した記録がスプレッドシートに書き込まれ、他のメンバーに見える
- [ ] 検索・ラベルフィルタで店舗を絞り込める

### 撤退ライン（事前明記）

以下のいずれかを満たしたら、Glide採用をやめてスプレッドシート直接編集（最もシンプルな代替）に切り替える：

1. **Phase 1完了後4週間で、訪問記録の週間入力数が平均3件を下回り続ける**  
   → チームが「使わない」と判断。ツールの問題ではなくCRM文化定着の問題。Glideをやめ、シンプルなスプレッドシートフォームに切り替える。

2. **Glideのプラン料金が月$200を超える**  
   → コスト過剰。AppSheetかスプレッドシート直接運用へ切り替える。

3. **会社Googleアカウント制約でGlideユーザー管理が機能しない**  
   → AppSheetを再評価、または個人アカウント運用への切り替えを判断。

### 最小代替案（Glideをやめる場合）

Glideなしの最小構成：
- storesはスプレッドシートのまま（閲覧はmeiten-db.htmlで継続）
- visit_logsはGoogleフォーム1枚（店名選択+種別+メモ+写真）→ スプレッドシートに自動記録
- 工数: 2時間以内、コスト: 0円

**GRチェック：** この「Googleフォーム案」は十分有力な案。「訪問記録をつける」だけならGlideより先にこれを試してもよい。MVP中のMVPとして最初の2週間はGoogleフォームで運用し、ニーズと定着を確認してからGlideに移行する判断も合理的。

---

## 7. overengineering チェック

| 要素 | 判定 | 理由 |
|---|---|---|
| 自前Webアプリ | 過剰 | 9名CRMにフルスタック開発は100倍の工数 |
| Next.js/Docker | 過剰 | 導入禁止 |
| Salesforce / HubSpot等の専用CRM | 過剰 | 月数万円、設定工数大、Glideで代替可 |
| 独立したDB（MySQL/PostgreSQL） | 過剰 | スプレッドシートで十分 |
| リアルタイム同期（WebSocket等） | 過剰 | 30秒遅延のスプレッドシート同期で十分 |

---

## 8. CEO 決裁が要る3点

以下の3点はCTOが代わりに決められない。CEO判断を仰ぐこと。

### 決裁①：プラットフォーム選定

**選択肢：**
- A. Glide（推奨。月$49〜99・要確認）
- B. AppSheet（会社WorkspaceプランがEnterprise以上なら無料の可能性・要確認）
- C. Googleフォーム+スプレッドシート（無料・MVP最小版として先行試用）

**CTO推奨：** CからスタートしてAへ移行する「2段ロケット」。最初の2週間はGoogleフォームで訪問記録の文化が定着するか試し、定着したらGlide移行。

### 決裁②：月額予算

Glide採用の場合、月$49〜99（年間約9〜18万円）の課金が発生する。Google Workspaceプランの確認次第でAppSheetが0円になる可能性もある。

### 決裁③：ユーザー範囲と招待アカウント

- 社員9名全員を即招待するか、コアメンバー3名でまず試すか
- 契約社員を含めるか（含める場合、Readerロールのみ）
- 個人Googleアカウントで招待するか、会社アカウントを使うか（会社アカウントの制約確認が先）

---

## 9. 実装着手の最小手順（CEO GO後）

1. Googleスプレッドシートを作成し、meiten-master.jsonをCSVで移行（Python30行・CTO担当）
2. visit_logs/field_intel/news_clipsシートを追加
3. Glide無料トライアルでスプレッドシートを接続し、店舗一覧と訪問記録フォームを作成（Glide経験者担当・6時間）
4. CEO・編集長をAdminとして招待し動作確認
5. 営業1名をEditorとして招待し「試しに1件入れてみて」でフィードバック収集
6. 1週間後にフィードバックを踏まえて有料プランへ移行判断

---

*本設計書：CTO作成・CEO決裁3点の回答をもって実装着手可*