2026年11月1日 ・ お問い合わせの裏側から、支払いの裏側（別府君）へ
名簿・支払いの状態・ログインのすり合わせ
2人の仕組みがつながる所だけを決めます。Stripe の作り方、お手入れ中への切り替え、支払いの画面の中身は別府君が決めます。どれにも推奨を書いたので、そのままで良いかどうかだけ答えてください。
当日決めること
1
お店の名簿の正本はどこに置くか
推奨 Cloudflare D1 の新しい箱 ut-shops の表 shops を1つだけ。2人の係が同じ箱を直接読む
推奨のとおり変える
2
名簿のどの欄を誰が書くか
推奨 支払いとプランは別府君、LINE とサイトの情報はこちら（下の表）
推奨のとおり変える
3
支払いの状態の書き方
推奨 名簿には4つ（active・past_due・maintenance・ended）。サイトに出す合図 A は今のまま2つ
推奨のとおり変える
4
管理画面の入口とログイン
推奨 Cloudflare のログインの門（Zero Trust の Access）を1つ。Google のログインで2人とも入り、中の画面は別々の係
推奨のとおり変える
5
別府君が当方の Cloudflare に係を載せる方法
推奨 当方の Cloudflare のアカウントに別府君をメンバーとして招く（無料）。鍵を手渡しすると、どこで使われているか追えなくなる
推奨のとおり変える
今回は決めないこと: 回数を超えた直し（1回 3,000円）の支払いリンクの窓口は5軒目から。年払い・銀行振込の扱いは別府君の引き継ぎ書で未決のまま。
1. 名簿の正本
お店1軒を1行にします。2人の仕組みは、店ID を共通の鍵にして同じ表を使います。
依頼の係（こちら）LINE の郵便受け・作業台
同じ表
支払いの係（別府君）Stripe・お手入れ中・支払いの画面
名簿 D1
ut-shops の表 shopsお店1軒＝1行・店ID が鍵・それぞれ自分の欄だけ書く- 箱を新しく分ける理由: こちらの郵便受けの箱にはお店の文と写真の記録が入っています。支払いの係には名簿だけを見せ、お店の文は見せません
- 2人の係が同じ箱を直接つなぎます（Cloudflare の同じアカウント）。間に窓口を作らないので、作るものが1つ減ります
- いまの名簿（KV の
shops）は、こちらが D1 へ移します。移したあと KV の名簿は使いません - 費用は増えません（Workers Paid は契約済み。D1 はその枠の中）
Next.js ＋ Neon にしたい場合 名簿の正本は D1 のままにして、支払いの係から読み書きする窓口をこちらが1つ作ります。Neon にもう1つ名簿を持つのはやめます（2つあると必ず食い違います）。推奨は Cloudflare（Workers ＋ D1）でそろえる形です。
店ID の決まり
- 英小文字・数字・ハイフンだけ。一度決めたら変えない（例: 小林建工＝
kobayashikenkou） - 停止の合図 A のキー
site:<店ID>、問い合わせの控え B、こちらの依頼の記録は、全部この店ID を使う
行を作るのは誰か
- 申込の仕組みが動くまで（1軒目の小林建工）: こちらが手で1行入れる
- 申込の仕組みが動いたあと: Stripe で契約が始まった時に、支払いの係が行を作る（店ID・店名・プラン・支払いの状態）。LINE とサイトの欄はこちらがあとから埋める
2. 名簿の欄と、書く人
それぞれ自分の欄だけを書き換え、相手の欄は読むだけにします。updated_by に書いた係の名前を残します。
| 欄 | 中身 | 書く人 |
|---|---|---|
shop_id | 店ID（主キー） | 行を作った人 |
name | 店名 | 行を作った人 |
plan | basic・standard・premium | 別府君 |
billing_status | 支払いの状態（3 を参照） | 別府君 |
billing_checked_at | 支払いの状態を最後に確かめた時 | 別府君 |
contract_started_on | 契約の始まりの日 | 別府君 |
stripe_customer_id | Stripe のお客さんの番号 | 別府君 |
kind | 業種 | こちら |
line_user_id | LINE の窓口の人の ID | こちら |
site_url | サイトの住所 | こちら |
site_worker | サイトの係の名前（例 kobaken-site） | こちら |
repo | お店のリポジトリの場所 | こちら |
has_blog | ブログ（EmDash）があるか | こちら |
koekake | 声かけを送るか | こちら |
updated_at・updated_by | 最後に書いた時と係 | 書いた人 |
- 直しの回数の上限はプランで決まります（ベーシック 月2回・スタンダード 月4回・プレミアム 月8回）。こちらは
planを読んで数えるだけです - 表の形（列の名前・型）はこちらが書き、別府君に見てもらってから作ります
3. 支払いの状態の書き方
名簿の billing_status は4つにします。サイトに出す合図 A（KV ut-site-status）は今のまま2つです。
| 名簿の値 | 意味 | 合図 A | 依頼の側の動き |
|---|---|---|---|
active | 払われている | active | 受けて、公開もする |
past_due | 払いが遅れている（お手入れ中になるまでの3週間） | active | 受けて、公開もする |
maintenance | お手入れ中（90日の保持の間） | maintenance | 記録はするが公開しない。お店には「いまはお直しを止めています」と返す |
ended | 解約・保持の期限切れ | 別府君が決める | 依頼を受けない（郵便受けには残す） |
- 状態が分からない時（行が無い・欄が空・D1 が答えない）は、サイトは出したまま、新しい直しの公開だけ待ちます。合図 A の「キーが無い時は表示を続ける」と同じ考えです
billing_checked_atが3日より古い時も「分からない」と同じに扱います。Stripe からの知らせが止まっていても気づけますpast_dueで公開を止めないのは、3週間はサイトを出す約束だからです。止めるのはmaintenanceからです- 公開の直前に、こちらの係が名簿を読み直して確かめます（依頼を受けた時の状態では決めません）
4. 入口とログイン
- 住所: 当方のドメインを Cloudflare に置くまでは、2つの係に別々の住所を使います（どちらも同じ門の内側なので、1回ログインすれば両方に入れます）。ドメインを置いたら
admin.<当方のドメイン>/billing（別府君）と/requests（こちら）に並べます - 入れる人: 最初は運営者（小林）と別府君の2人。どちらも両方の画面に入れて、書き換えはそれぞれの画面の中だけです
- 門を通ったかを係でも確かめる: Access が付ける署名
Cf-Access-Jwt-Assertionを、それぞれの係の中で検証します。門の設定を誰かが外しても素通しにならないようにするためです - お店1軒の画面: こちらの依頼の画面に、名簿の支払いの状態を読んで並べます（別府君の画面は埋め込みません）
- 費用: 0円（Access は50人まで無料）。門の設定はこちらが1回やります
5. 決まったあとの段取り
こちらがすること
ut-shopsを作り、表shopsの形を書いて別府君に見てもらう- いまの名簿を D1 へ移す（小林建工の1行。
billing_statusは契約が始まるまで空なので公開は待つ。支払いの仕組みが動くまでは、契約が始まった日にこちらが手でactiveにする） - LINE の郵便受けが、名簿を D1 から読むように替える
- 依頼の記録・状態の表・作業台を作る
- ログインの門を作り、作業台をその内側に置く
別府君にお願いすること
- 名簿の
plan・billing_status・billing_checked_atを、Stripe からの知らせに合わせて書く係 - 合図 A を
billing_statusと食い違わないように書く