言問手形 × 言問名店 ── 連携と収益化の設計

大原則 ── 単一正本 → 公開射影（ヘッドレス方式）

連携設計で最初に決めるべきは「データをどこに、いくつ持つか」である。結論は明快 ── 名店マスター（社内・106社）を唯一の正本（マスター）とし、手形アプリはそこから"公開してよい情報だけ"を射影した派生ビューにする。 誌面・アプリ・ホテル送客は、別々のデータベースではなく、同じ1つのマスターを別チャネルへ出しているだけ。これにより二重管理（同じ店の情報を2か所で別々に直す事故）を構造的に消す。

① 正本は1つ

店の情報は名店マスターにのみ書き込む。住所が変わったら、直すのはマスター1か所だけ。

② 出力は射影

誌面・アプリ・ホテル案内は、マスターから「そのチャネル向けの項目だけ」を機械的に書き出した結果。手で写さない。

③ 同期は自動

マスターが更新されれば、公開シート → アプリへ自動で反映。人の転記作業をゼロにする。

データの流れ（全体図）

🗄 名店マスター（社内・正本／106社）

店の全情報を1社1レコードで保持する唯一のデータソース。社内項目（出稿額・営業担当・評価など）と公開項目（店名・住所・紹介文など）を同居させるが、出力時に厳密に切り分ける。

▼① 公開射影パイプライン（公開フィールドだけを抽出・書き出し）

📤 公開シート（手形アプリ用の派生ビュー）

マスターから「公開」と明示指定した項目だけを書き出した、外部公開してよいデータの層。社内項目は物理的にここへ来ない。

▼アプリが公開シートを読む

📱 言問手形アプリ（Glide）

公開シートを表示。加盟店一覧・地図・スタンプ対象・紹介文を観光客に提供する。

🧳 観光客 / 宿泊客

アプリで街を回遊し、加盟店でスタンプ（チェックイン）を押す。インバウンドが大半。

▲② 来店データの逆流（チェックイン実績をマスターへ日次集計）

🔁 来店実績がマスターへ還流

手形アプリのチェックイン件数を、店ごとに集計して名店マスターの「来店実績」へ書き戻す。これが後述の送客レポートと順位づけの原資になる。誌面・アプリ・ホテルが相互に送客し合う循環（フライホイール）が、ここで初めてデータで閉じる。

この方式の要点

マスターは社内の意思決定（誰に何を売るか）を支える「分厚い台帳」のまま。アプリは「公開してよい薄いビュー」だけを受け取る。太い正本と、薄い公開ビューを分けることで、情報漏洩を構造で防ぎ、二重管理をゼロにし、来店データで循環を閉じる ── これが連携設計の背骨。

社内 / 公開の切り分け ── フィールド単位・ホワイトリスト方式

射影で最も重要なのは「どの項目をアプリに出すか」をフィールド（項目）単位で決めることである。原則はホワイトリスト方式（既定は非公開） ── 何もしなければ全項目が非公開、明示的に「公開」と指定したフィールドだけを書き出す。

なぜ「既定公開・例外を隠す」ではいけないか

漏洩はほぼ常にブラックリスト方式（既定公開・隠したい項目を1つずつ除外）で起きる。新しい項目（例：新設した「営業メモ」列）が増えたとき、除外し忘れればそのまま公開されてしまう。ホワイトリストなら、新項目は明示公開しない限り永久に非公開。安全側に倒れる。

3区分のフィールド一覧

区分	対象フィールド	扱い
🔴 社内のみアプリに一切載せない	累計出稿額／直近出稿額／契約種別／広告ランクラベル／ポテンシャル／次アクション／営業担当／継続途絶ステータス／手形適性の理由	物理分離。公開シートにこれらの列を一切作らない。営業・経営の機微情報であり、加盟店・観光客・競合の目に触れてはならない。
🟢 公開アプリ・誌面・ホテル案内へ	店名／業種／エリア／住所／緯度経度／ GoogleマップURL ／公式サイト／紹介文／タグ／写真／スタンプ対象フラグ	明示公開。観光客が店を見つけ・行くために必要な情報のみ。ホワイトリストに載せた項目だけが射影される。
🟡 内部スコア順位算定に使うが数値は非公開	世界観適合度／手形適性レベル／ホテル送客親和性／評価	計算には使い、数値は出さない。これらのスコアでアプリ内の表示順を決めるが、スコアそのものは観光客にも加盟店にも見せない（順位の根拠を外に出すと操作・苦情の温床になる）。

鉄則

default 非公開。 公開シートには 🟢 のフィールドだけが存在し、🔴 の列は物理的に作らない。🟡 はマスター内で順位計算にのみ使い、出力には数値を含めない。新しい項目を足したら、それは自動的に非公開 ── 公開したいなら明示的にホワイトリストへ追加する、という一方通行を守る。

広告順・ランクづけ ── 2層分離モデル（信頼と収益の両立）

アプリで「どの店を上に出すか」は、収益化の核であると同時に最大の地雷でもある。ここを誤ると、利用者の信頼を一度で失う。他社の事例が、その境界線を明確に教えてくれる。

他社事例の教訓

食べログ（2016年の論点）

「課金額でオーガニック（自然）順位を操作しているのでは」という疑念が表面化し、信頼問題に発展した。教訓：自然順位そのものを売ってはいけない。順位を金で動かせる仕組みは、見えた瞬間に媒体の信頼を破壊する。

Google マップ

自然な検索結果（オーガニック）と、明確に「スポンサー」ラベルを付けた広告枠を、別レーンとして併置している。教訓：広告は売る。ただし"広告である"と明示し、自然順位とは別の場所に置く。

百名店 / ミシュラン

掲載や星は課金とは独立した編集・評価の軸で決まる。だからこそ権威（バッジ）として機能する。教訓：課金と切り離した認証バッジは、売り物ではなく信頼の源泉になる。

設計：3つのレーンを分離する

レーン	決まり方	課金	表示
① オーガニック順位	世界観適合＋評価＋手形チェックイン実績＋距離/関連性で自動算定（内部スコア 🟡 を使用）	売らない	通常の一覧・地図表示。利用者にとっての「素直な並び」を保証する。
② スポンサー枠	加盟ティア（後述の会員ランク）に応じて上位固定・特集掲出	売る	「PR」ラベル必須。オーガニックとは別枠・別レーンとして明示し、広告であることを隠さない。
③ 言問名店バッジ	編集局による認証（選定基準に基づく）。課金とは独立した軸	独立	店に付与する認証マーク。課金では買えない権威。掲載順位とは別の信頼シグナル。

この設計の核心

課金で買えるのは「枠・ブースト・バッジ※・送客レポート」であって、オーガニック順位ではない。（※バッジは編集認証で、購入で"審査を経ずに"付与されるものではない ── 課金は掲出グレードに連動するが、認証基準そのものは売らない。）自然順位を売らないことが、利用者の信頼＝媒体の価値を守る。広告は「別レーン・PR明示」で堂々と売る。信頼と収益は、レーンを分ければ両立する。

売れる広告商品 ── 会員ティアと直結

レーンを分離したうえで、加盟店に売る具体的な商品を設計する。いずれもオーガニック順位ではなく、枠・掲出・認証・データを対価とする。価格は既存事業計画の会員ティア試算に整合させた水準。

スポンサー枠 ¥120,000/年〜

アプリ内の「PR」表示付き上位掲出・特集枠。オーガニックとは別レーンとして広告であることを明示。スタンダード会員ティア相当。

詳細LP ＋クーポン ¥120,000/年〜

店ごとの詳細ページ（写真・物語・メニュー）と、アプリ会員向けクーポンの掲出。来店動機を作り、手形チェックインへ繋げる。

言問名店バッジ ¥36,000〜

編集認証マークの付与・掲出（ライトティア相当）。課金とは独立した審査を通った店のみが対象。権威の可視化による送客効果。

送客レポート ¥360,000/年最強の差別化

手形チェックインの月次来店データを PDF で提供。「この店に、いつ、何人が実際に来店したか」を可視化する。プレミアム会員ティア相当。

送客レポートが効く理由 ── OMOの最後の1マイル

多くの地域メディアは「掲載した／表示された」までしか示せない。言問手形はチェックインで「実際に来店した」を計測できる。これは OMO（オンラインとオフラインの融合）の最後の1マイル ──「実来店の対価化」── を成立させる。広告掲出の対価ではなく、実来店という成果の対価を売れることが、他のどの地域メディアにも真似できない差別化になる。

価格は既存の事業計画（会員ティア：ライト¥36k／スタンダード¥120k／プレミアム¥360k・年額）の推計に基づく。実勢は営業による検証が前提推計。

実装方針 ── 既存資産の再利用（新規DB禁止）

この連携は新しいデータベースを作らない。既にある資産（名店マスター・エンリッチ処理・手形スプレッドシート・Glideアプリ）を組み替えるだけで成立するよう設計する。新規構築を最小化することが、最短・最低コスト・最少事故での実装になる。

構成要素	方針
正本	名店マスター（JSON・106社）。スキーマを拡張せず既存のまま使う。店の全情報はここにのみ書く。
射影	既存のエンリッチ処理を「公開射影」に拡張し、手形スプレッドシートの公開シートへ公開フィールド（🟢）だけを書き出す。ホワイトリストはこの処理に1か所だけ定義する。
アプリ	既存の Glide アプリが、その公開シートを読むだけ。アプリ側に新規開発はほぼ不要。
逆流	手形チェックイン → 名店マスターの「来店実績」へ日次集計。マスターに新規フィールドを1つだけ追加（来店実績）。これが送客レポートと順位の原資。

設計のミニマリズム

新規に作るのは「公開射影の1処理」と「マスターの来店実績フィールド1つ」だけ。あとは既存資産の接続。部品を増やさないことが、最も壊れにくく・最も速い実装になる。

リスクと留意

個人情報の最小化

観光客は匿名で扱う（個人を特定しないチェックイン集計のみ）。インバウンドが大半（約95%）であり、海外の個人情報保護法（EUのGDPR・台湾の個人資料保護法など）の射程に入りうる。そもそも個人データを集めない設計が最も安全。送客レポートも店単位の集計のみで、個人を出さない。

PR表示・景品表示法 / ステマ規制

2023年施行のステルスマーケティング規制により、広告は「広告である」と明示する義務がある。スポンサー枠・PR掲出には必ず「PR」ラベルを付け、編集（自然順位・バッジ認証）と広告を明確に区別する。これはレーン分離（03章）と一体の遵守事項。

社内データの物理分離

🔴 社内項目（出稿額・営業担当など）は、公開シートに列として存在させない。「非表示にする」ではなく「そもそも書き出さない」を徹底する。ホワイトリスト方式（02章）が、この物理分離を構造的に保証する。

次の実装ステップ

公開フィールドのホワイトリストを確定する。02章の 🟢 一覧を正式定義し、射影処理の唯一の公開定義とする。
既存エンリッチ処理を「公開射影」へ拡張する。名店マスター → 手形公開シートへ、公開フィールドだけを自動書き出し。
Glideアプリを公開シートに接続する。加盟店一覧・地図・スタンプ対象・詳細LPを公開データで表示。
マスターに「来店実績」フィールドを1つ追加する。手形チェックインの日次集計を書き戻す逆流を実装。
順位ロジック（オーガニック）を実装する。世界観適合＋評価＋チェックイン実績＋距離で内部スコア算定。数値は非公開。
スポンサー枠・PR表示・バッジ掲出を別レーンとして実装する。「PR」ラベルを標準装備。
送客レポート（月次PDF）の雛形を作る。店単位の来店実績を可視化。プレミアム会員の主力商品として営業に載せる。

まとめ

名店データを一度だけ持ち、公開してよい部分だけを射影し、来店実績を逆流させて循環を閉じる。広告は別レーン・PR明示で売り、自然順位は売らない。送客レポートで実来店を対価化する ── これが、信頼を壊さず収益を立てる連携設計の全体像。新規DBを作らず既存資産の組み替えで成立するため、追加投資を最小に実装できる。