うむ。ここで一度、実装に入る前の Serial 仕様スナップショットとして紙にしておこうｗ
まだ決めていないところは勝手に埋めず、「未確定」にしておく。
Kaia Serial 仕様整理 — 現時点案
1. 製品の位置づけ
Kaia Serial は独立した有料コンポーネント。Free は存在しない。
現状の製品ラインは、
- Standard — 基本となるSerial発行・管理・公開照合
- Creative — Standardを包含し、企業向けに取得できる発行情報を拡張
とする。
既存Registry上では、
Parent：KS-0017-CNT-17
Standard：KS-0027-CNT-17
が存在する。
Creativeは新規製品として、Registryの通常ルールに従って新規採番する。既存番号の並べ替えや、Freeの追加は行わない。
2. 基本思想
Serialは単なるランダム文字列生成器ではない。
発行物に固有Serialを与え、発行時のCounter・Timestamp・Binder/Refillとの関係を台帳として保持し、後から公開照合できる「発行管理装置」。
UIについては新規設計を極力避け、
Timestamp Standardの金型へSerial機能を流し込む
ことを基本とする。
表側の操作感はTimestampと兄弟機にする一方、内部にはSerial専用の採番・仮予約・一意性保証・発行台帳を持つ。
3. Serial候補UI
ページ取得時、自動的にSerial候補を1個採番する。
この時点から単なる表示候補ではなく、仮予約済みSerialとして扱う。
その後ユーザーは ROLLを最大5回実行できる。
したがって、
ページ取得
↓
Serial #1 自動採番・仮予約
ROLL #1 → Serial #2
ROLL #2 → Serial #3
ROLL #3 → Serial #4
ROLL #4 → Serial #5
ROLL #5 → Serial #6
最大6候補となる。
候補はTimestampと同様、ラジオボタンで1個を選択する。
初期候補はデフォルト選択状態。
6候補に達したら、それ以上ROLLできない。
4. 仮予約と重複防止
画面へ提示されたSerialはすべて仮予約済み。
したがって別ユーザーへ同じSerialを提示しない。
採番時にはサーバー側で一意性を確認し、仮予約が成立したSerialだけをWebへ返す。
仮予約と正式発行は同じ一意性空間で管理する。
Serial A → temporary
Serial B → temporary
Serial C → issuedtemporary のSerialも他者へ再採番しない。
DB側でもSerial全体に対する UNIQUE制約を最終防衛線として持つ。
仮予約の有効期限・失効処理などの具体値は未確定。
5. Serial番号の構造
Serialの先頭には、発行対象となるCounter番号に依存した通し番号部分を持たせる。
概念例：
Counter Number : 152
Serial Number : 152-H7K2M9後半部分はSerial固有部分。
ただし、一意性判定はBinder単位・Refill単位ではなく、
Serial Number全体についてGLOBAL UNIQUE
とする。
Binder + Serial の複合一意性にはしない。
BinderやRefillはSerialの一意性を決める住所ではなく、発行後に内部台帳でSerialへ関連付けられる情報。
6. Binder / Refillとの関連
Serialは共通の Refill N によってKaiaファミリーと関連付ける。
内部ではBinder ID / Refill IDを保持する。
ただし公開照合では、
Binder
Refill
という内部用語をそのまま見せる必要はない。
企業・設置者が公開用の項目名と表示名を設定できるようにする。
例：
内部
Binder ID : 7
Refill ID : 12
公開用
Binder項目名 : 開催時期
Binder表示名 : 2026年夏
Refill項目名 : イベント
Refill表示名 : アイドルAライブ記念公開側では、
開催時期
2026年夏
イベント
アイドルAライブ記念のように表示できる。
内部構造のBinder / Refillそのものの名称やIDは変更しない。
変更可能なのは公開側の表札。
個人情報・社内管理情報等を公開表示名へ入れないよう、管理画面で注意表示を行う。
発行時の公開表示名については、後日の名称変更で過去発行物の意味が変わらないよう、発行時Snapshotとして保存する方向。
7. 正式発行時に固定する情報
正式発行時には少なくとも以下を、その発行物のSnapshotとして保持する。
Binder ID
Refill ID
Binder 公開項目名
Binder 公開表示名
Refill 公開項目名
Refill 公開表示名
Counter Number
Issued Timestamp
Serial NumberCreative用の詳細情報については後述。
Counter NumberはSerial prefixから後で復元するのではなく、独立した発行時Snapshotとしても保存する。
現在のCounter値を後日参照してはいけない。
8. 公開Serial逆引き
Serialプラグイン自身が、公開サイトへ逆引き窓口を設置できるようにする。
WordPressでは専用ショートコードを用意する方向。
概念：
[kaia_serial_verify]固定ページ等へ設置すると、
Serial Verification
[ Serial Number ]
[ Verify ]という検索UIが生える。
一致する正式発行Serialが存在した場合、公開する基本情報は、
2026年夏
アイドルAライブ記念
Counter Number
152
Issued Timestamp
2026.08.31 14:32:18
Serial Number
152-H7K2M9とする。
Binder / Refillについては、設定された公開項目名・公開表示名を使用する。
9. 公開しない情報
Timezone情報は公開逆引きには表示しない。
技術的に取得可能であっても、
「なぜこのサイトが自分のTimezoneを知っているのか」
という不要な不安を一般ユーザーへ与えるため。
したがって公開照合は必要最小限。
TZは企業向け内部台帳情報として扱う。
10. 企業向け発行台帳
Serialは正式発行済みデータについて、企業・管理者向け台帳を持つ。
通常の台帳・エクスポートには仮予約Serialを混在させない。
基本的に issued の正式発行記録を対象とする。
デフォルト表示順は、
新しい発行ほど上
とする。
すなわち発行順の降順（DESC）。
#156
#155
#154
...
#2
#1内部の発行番号そのものは通常通り増加する。
11. 台帳エクスポート
企業向け台帳は少なくとも、
Markdown (.md)
CSV (.csv)
Excel (.xlsx)
の3形式でダウンロード可能にする。
三形式で別の台帳を作るのではなく、同一の発行台帳データを異なる形式で出力する。
デフォルトの並び順も管理画面同様、最新発行が上。
12. Standardの企業向けデータ
Standardでも普通の企業運用に必要な情報は取得できる。
基本イメージ：
Issue No.
Binder ID / 発行時公開表示
Refill ID / 発行時公開表示
Counter Number
Issued Timestamp
Serial Numberつまり、
何の発行物か
Counter何番だったか
いつ発行されたか
どのSerialか
を企業が後から追える。
13. Creativeの企業向け詳細情報
Creativeでは、Standardの台帳を包含したうえで、発行時刻についてより深い情報を取得可能にする。
特に重要なのがTimezone。
発行時には同じ一瞬について、
Visitor Timestamp
Visitor TZ
Company Timestamp
Company TZを扱えるようにする。
例：
Visitor Timestamp
2026-08-31 14:32:18
Visitor TZ
Asia/Tokyo
Company Timestamp
2026-08-31 07:32:18
Company TZ
Europe/Berlinこれは別々の発行時刻ではない。
同一の発行瞬間を、利用者側と企業側それぞれの現地時計で表現したもの。
会社側はSerial設定で自社のIANA Timezoneを設定する方向。
Company Timezone
Europe/Berlinこれにより企業は、
「このSerialは利用者の現地では何月何日何時に発行されたか」
だけでなく、
「その瞬間、うちの国・地域では何月何日何時だったか」
も台帳から即座に確認できる。
DST等を考慮するため、単純な固定時差ではなくIANA TZを使用する。
基準となる発行瞬間をUTC等でも内部保持する設計が望ましい。
14. Standard / Creativeの境界思想
安全性をグレード差にしない。
以下のようなSerialの安全機構はStandardから備える。
仮予約 / 重複防止 / GLOBAL UNIQUE / 正式発行の固定 / 安全な逆引き
Creativeとの差は、
企業が台帳から持ち帰れる情報の深さ
で作る。
したがって、
Standard＝通常の発行管理に必要な台帳
Creative＝国際利用・分析・照合などに使える詳細台帳
という関係。
内部データ構造については、将来Standard→Creativeへ上げても壊れないよう、最初から上位互換を意識する。ただし、Standardで何を内部保存するか／Creativeになった際に過去分まで詳細出力可能にするかは未確定。
15. Timestampとの関係
UIの基本金型はTimestamp Standardを利用する。
対応関係は、
Timestamp
ページ取得 → 時刻候補1
RECORD × 最大5
最大6候補
ラジオ選択
Serial
ページ取得 → Serial仮予約1
ROLL × 最大5
最大6候補
ラジオ選択となる。
つまり、
顔・操作思想＝Timestamp系
心臓＝Serial専用採番・予約・台帳エンジン
とする。
SerialはTimestamp内部へ組み込まず、独立プラグインとして作る。
16. PDFとの将来連携
Serialをまず独立機として完成・実機確認する。
その後PDFから差し込み連携する。
基本原則は、
SerialがSerialを決める。PDFは決めない。
PDF側がSerial DBを直接覗いて採番ロジックを再実装しない。
Serial側で確定した値を、PDFが発行データとして受け取って転記する。
Counter / Timestampについても同様に、
Webで確定した値をPDFが書き写す
という事故防止原則を維持する。
17. 現時点で意図的に未確定のもの
まだ勝手に決めないものは残しておく。
Serial文字列の具体的な桁数・文字種・prefix表記
仮予約のTTL
ページ離脱時の仮予約解放方法
一度提示したが未発行だったSerialを将来再利用するか
Standard / Creativeの正確なExport列境界
CreativeのRegistry採番
公開逆引きUIの最終デザイン
Company TZ設定UIの具体形
正式発行をSerial単独試験するときのテスト導線
ここは実装前または実装中に必要になったところから決める。
一行でいうSerial君
Kaia Serialは、Counterに紐づく固有Serialを仮予約・選択・正式発行し、その発行時情報を台帳として保存して、公開照合と企業向けデータ出力を提供する独立発行管理コンポーネント。
しゃむ語ならもっと短い。
Timestamp Standardの金型に、採番機と市役所をぶち込む★
これで一旦、かなり実装に渡せるところまで仕様になったと思うｗｗｗ
特に今回は**「公開窓口」と「企業がぶっこ抜く台帳」を分離した**のがでかい。
No comments yet.