majiayu000 社名変更履歴エキスパート (Company Name Historian)
ARIA が「法人の名前の歴史」をどのように記録し、非時系列な書類取得（バックフィル）に対しても整合性を保つかを定義します。
1. 真実の源泉 (Source of Truth)
- 単一のソース: [documents_index.parquet]（カタログ）のみを情報源とする。
- 対象フィールド: カタログ上の
company_name（漢字名）のみ。カナ・英名は追跡対象外。 - 識別子:
JP:XXXXX形式の証券コードを主軸とする。
2. 履歴再構成アルゴリズム (Reconstruction Logic)
バックフィル等により書類が日付順に届かない状況下でも、以下の手順で決定論的に履歴（NameEvent）を再構成します。
- 全書類スキャン: 指定された証券コードに紐付く「全期間」の書類をカタログから抽出。
- 時系列ソート:
submit_at(提出日時) の昇順で物理的に並び替える。 - 状態遷移の検知: ソートされたリストを順に走査し、隣接する書類間で
company_nameが変化した地点を「社名変更イベント」として抽出。 - 重複排除:
(code, old_name, new_name, change_date)の 4 項目が完全に一致するイベントは物理的に 1 つに集約する。
3. 具体的な挙動ケース (Factual Cases)
ケース: 非時系列な書類取得 (Backfill Scenario)
システム運用開始後、以下の順序 (1～6) で書類を取得した場合の内部挙動： ※社名変更の事実は「2020年: A -> 2025年: B -> 2027年: C」と仮定。
| 取得順 | 書類提出日 | 提出時の社名 | システムの認識 (Name History) | 備考 |
|---|---|---|---|---|
| 1 | 2020-01-01 | ARIA株式会社(A) | [履歴なし] | 最初の書類 |
| 2 | 2024-01-01 | ARIA株式会社(A) | [履歴なし] | 2020年と変化なし |
| 3 | 2025-01-01 | ARIA商社(B) | [A -> B] を検知 | 変更記録: 2025-01-01 / A -> B |
| 4 | 2026-01-01 | ARIA商社(B) | [変化なし] | 2025年と変化なし |
| 5 | 2019-01-01 | ARIA総合(S) | 再構成実行 | 2019年(S) が先頭になり、[S -> A] (2020-01-01) を新たに検知 |
| 6 | 2027-01-01 | ARIA銀行(C) | [B -> C] を検知 | 変更記録: 2027-01-01 / B -> C |
最終的に完成する履歴 (name_history.parquet):
2020-01-01: ARIA総合(S) → ARIA株式会社(A)2025-01-01: ARIA株式会社(A) → ARIA商社(B)2027-01-01: ARIA商社(B) → ARIA銀行(C)
4. 物理的な掟 (Strict Rules)
- 非同期許容: 書類がどの順序でデータベースに登録されても、再構成ロジックにより常に「提出日時順のストーリー」が復元される。
- 推測の排除: 有価証券報告書だけでなく、各社が提出する全ての書類（四半期報、臨時報等）を判定対象とすることで、社名変更のタイミングを物理的に絞り込む。
- NULL 保護: カタログ上の
company_nameが欠落している書類は、遷移判定の計算から自動的に除外する。