UUIDハイブリッドストラクチャの検討
このスキーマの核心は、「フラグで状態を管理せず、全ての「対象（Object）」『動(Morphism/Arrow)』にIDを与えてオブジェクト化する」という数学領域の圏論的構成点にある。
デジタルツイン・イベント発行ガイドライン
1. 基本原則
本システムにおける全ての事象（デジタルツイン・イベント）は、以下の2つの識別子を組み合わせて記録する。
logic_id(UUIDv4): 乱数で記述する空間や時間に依存しない事象の「点」。何者とも重複しない絶対的なアイデンティティ。検索キーに使うことは基本的にはなく、ユニバーサルスキーマの基本として「場」として機能する。phys_id(UUIDv7): 時間軸でソートされる事象の「座標」。時系列ソートと物理的な書き込み最適化用。検索に利用する
2. イベント発行ケース一覧
以下のあらゆるフェーズで、必ず「イベントオブジェクト」を生成し、IDを付与する。
| カテゴリ | イベント名 | UUID発行のトリガー | 格納すべき属性 (Attribute) |
| Existence (存在) | 生成 (Instance) | 実体（人、モノ、場所）が初めて登録された時。アカウント仮登録でUUID登録、eKYCというイベントに別のUUIDとして登録、２つのUUIDを紐付け | 氏名、アカウントID、メールアドレス、イベント生成時間（UUIDv7）、イベント属性など |
| 複製 (Clone) | 既存の定義から新しい実体が派生した時。例えば100mの生地が100点のSKUに分割された場合 | 親ID (Source UUIDv4) | |
| Action (動作) | 開始 (Start) | 職人が作業を開始、または機械が稼働した瞬間。 | 実行者ID、対象物ID、位置情報 |
| 完了 (Finish) | プロセスが終了した瞬間。 | 結果ステータス、消費リソース | |
| 変更 (Update) | 属性（メールアドレス、所属など）が変わった時。 | 変更前後の差分 (Diff) | |
| Transfer (移動) | アップロード | ローカルからサーバーへ情報が移動した時。 | 通信プロトコル、ハッシュ値、送信元 |
| ダウンロード | サーバーから端末へ情報が取得された時。 | 取得者ID、デバイス情報 | |
| 所有権移転 | 権利がAからBへ移った瞬間。 | 元所有者ID、新所有者ID、署名ID | |
| Relation (接続) | コミット | GitHub等でコードが確定した時。 | Gitハッシュ、リポジトリID |
| プッシュ | コードが同期された時。 | 同期範囲、ブランチ名 | |
| 署名 (Sign) | 真正性を証明する意思表示。 | 署名方式、公開鍵情報、対象事象ID | |
| Incident (異常) | 衝突/故障 | 予測可能性が崩れた瞬間（例：転倒、エラー）。 | 衝撃度、エラーログ、直前の予測ベクトル |
3. 実装上の禁止事項（アンチパターン）
- 状態の「上書き」の禁止:
is_active = falseのようにDBレコードを更新してはならない。必ず「無効化イベント（UUIDv4）」を新しく発行し、積み上げること。 - IDの「意味付け」の禁止: UUIDv4の文字列の中に特定のコードを埋め込んではならない。意味は全てアトリビューション（属性レイヤー）に記述すること。
- IDの「省略」の禁止: 「これは小さなアクションだからIDはいらない」という判断を禁止する。全ての微細な挙動をユニバーサルスキーマの「点」として打刻する。
4. エンジニアへの補足説明
「なぜここまで徹底するのか？」→単なるデータベースを構築するわけではなく、産業の全履歴をコホモロジー的に連結した『現実の写し鏡（デジタルツイン）』を生み出そうとしているから。
UUIDv7で検索性能（物理）を確保しつつ、UUIDv4で事象の不変性（論理）を担保することで、10年後に『ある製品の不具合が、誰の、どのコミットの、どのダウンロードイベントに起因したか』を瞬時に特定できる。
この構成の肝は、「その事象や実体が何であるか（v4）」と「それがいつ、どの順序でシステムに現れたか（v7）」を分離することにある。
システム 対象オブジェクト (v4: 論理ID) 記録タイミング (v7: 物理ID) 記録されるイベント・事象の例 OMS (受注・発注) 受注伝票ID ( order_v4)
得意先ID (customer_v4)受注登録 ( order_v7)「受注稟議の承認」という意思決定の瞬間。
「ASN（出荷事前通知）作成」の実行。WMS (在庫・物流) 資材ロールID ( roll_v4)
棚番・ロケーション (loc_v4)入庫スキャン ( inbound_v7)「生地ロールが倉庫に到着し、スキャンされた」瞬間。
「棚卸による在庫数の差異確定」という特異点。MES (生産・裁断) 裁断パーツID ( part_v4)
縫製仕様書 (spec_v4)工程通過 ( process_v7)「1枚の生地が100個のパーツに裁断された」瞬間（親v4から複数の子v4が発生）。
「検品通過」という品質確定イベント。AURA (データ抽出) 抽出定義ID ( query_v4)抽出実行 ( export_v7)「PLOG抽出エンジンが稼働し、データを外に出した」瞬間。 2. 具体的なシナリオ例：生地から製品への転移
生産フローにおいて、どのようにIDが「もつれ」ながら記録されるかの具体例です。
A. 生地の入庫 (WMS)
- 事象: 工場に10mの生地ロールが届く。
- UUIDv4 (論理):
roll_a_v4を発行。この生地の「UUIDv4」として不変。- UUIDv7 (物理):
arrival_v7を付与。これにより「今日届いた順」での在庫検索が可能になる。B. 裁断とパーツ化 (MES)
- 事象:
roll_a_v4が裁断機にかけられ、100個のブラジャー用パーツになる。- UUIDv4 (論理): 新たに100個の
part_001~100_v4が発行される。各パーツは親のroll_a_v4を属性として保持し、系譜（コホモロジー）を繋ぐ。- UUIDv7 (物理):
cut_v7。100個のパーツは「ほぼ同時」に生成されるが、v7によって正確なミリ秒単位の生成順序がインデックスされる。C. 受注と出荷 (OMS/WMS)
- 事象: 顧客から受注があり、縫製された製品が出荷される。
- UUIDv4 (論理): 受注伝票の
order_v4と、製品のproduct_v4をリンクさせる。- UUIDv7 (物理):
ship_v7。出荷作業の物理的順序を記録し、WMSの出荷履歴検索を高速化する。3. 何を「属性」とし、何を「ID」とするか
エンジニアへの指示出しにおいて、以下の基準を徹底してください。
- UUIDv4は「実体の座標」:
- 製品、原材料、人間（職人、作業員）、設備。これらは一度決めたら変えない。メールアドレスや棚番などの「名前」が変わっても、v4は変えさせない。
- UUIDv7は「行動の足跡」:
- スキャン、承認、ダウンロード、アップロード、エラー発生。これらの「動詞」が発生するたびにv7を付与したレコードを作成し、時系列インデックスとして機能させる。
- Aura（PLOG Extractor）での活用:
- 「過去1時間以内の全MESイベントを抽出せよ」というクエリに対し、物理キーである UUIDv7 で範囲スキャンを行い、取得されたデータ内の UUIDv4 を辿って「そのパーツがどの生地から来たか」の因果律（論理）を解決する。
「高速な時間軸の検索（v7）」と「確実な実体の特定（v4）」を使い分けることで、点群によるトポロジーの勾配をコンピュータに理解させることができるようになる。