SKILL.md: 時間区間推論（アレン 1983）
このスキルを使用するタイミング
以下の状況に遭遇した場合にこのスキルをロードしてください：
| トリガーとなる状況 | アレンの適用理由 |
|---|---|
| 「タスクAはタスクBの開始前に終了するか？」 | 区間関係の分類が必要（before, meets, overlaps…） |
| 「Xがいつ起こったか正確にはわからない。Yの間だったことだけがわかっている」 | 13の関係にわたる選言的曖昧性 |
| 「この制約を追加しても、スケジュールはまだ成立するか？」 | 制約伝播 + 非一貫性検出 |
| 「イベントAは毎日起こり、イベントBは毎年起こる。これらはどのように相互作用するか？」 | スコープ管理のための参照区間階層 |
使用しないでください：不確実性のない2つの絶対タイムスタンプを比較するだけであれば、単純な算術で十分です。
決定ポイント
新しい時間アサーションが追加された場合
IF アサーションが既存の制約と矛盾する場合：
→ 伝播中に空のアークラベルを検出
→ 即座に中断、矛盾する区間ペアを報告
→ 矛盾した状態で処理を続行しない
IF アサーションが一貫している場合：
→ 影響を受けるアークから制約伝播を実行
→ 推移性の結果を交差させることでラベルを更新
→ これ以上絞り込みできなくなるまで継続
時間的不確実性の処理
IF 証拠が複数の関係しかサポートしていない場合：
→ 完全な選言的ラベル {before, meets, overlaps} を維持
→ 証拠なしに単一の関係に絞り込まない
→ 制約セットがいつ、なぜ絞り込まれたかをログに記録
IF 不確実性下で行動を強いられた場合：
→ 計画のために選言的ラベルをそのまま使用
→ すべての仮定は撤回可能としてタグ付け
→ 早期のコミットメントを避ける
時間推論のスコープ設定
IF 異なるタイムスケールのイベントを扱う場合：
→ 参照区間階層を特定（年→月→日）
→ 各クラスター内で個別に推論
→ 境界に明示的なブリッジ制約を作成
→ すべてを1つのグローバルグラフにフラット化しない
IF 局所的な推論で十分と思われる場合：
→ クエリのスコープが参照区間レベルと一致することを確認
→ 関連するクラスター内でのみ伝播
→ 依存関係が検出された場合のみ、クロスクラスターにエスカレーション
状態の永続性
IF 状態が明示的な終了境界なしに継続する場合：
→ 永続性のデフォルトを適用し、かつ撤回可能としてマーク
→ 将来の終了境界アサーションはデフォルトを上書き
→ 永続性の仮定をハード制約として扱わない
IF 明示的な時間的境界が提供された場合：
→ 既存の永続性デフォルトを上書き
→ 新しい制約を通常どおり伝播
障害モード
| アンチパターン | 症状 | 診断 | 修正 |
|---|---|---|---|
| 点化 | イベントをタイムスタンプに還元し、重複/包含情報を喪失 | time=14:30 の代わりに [14:30, 14:45] 区間を使用 | すべてのイベントを開始/終了を持つ区間としてモデル化。期間が不明でも |
| 時期尚早なコミットメント | 証拠が複数をサポートするときに単一の関係を選択 | 「〜の間でない」ことだけしかわかっていないのに「前」を主張 | 証拠が絞り込みを強制するまで完全な選言的ラベルを維持 |
| グローバル伝播爆発 | 更新ごとにO(N²)コスト、KBサイズに応じて性能低下 | ローカルクエリのためにグラフ全体で制約伝播を実行 | 参照区間階層を使用して伝播スコープを制限 |
| 空ラベル否定 | 一貫性検出後も推論を継続 | 矛盾する制約が無視されたため無意味な結果を得る | 空のアークラベルをSUCCESS（非一貫性を早期に捕捉）として扱い、即座に中断 |
| 永続性の硬直性 | 「変更されるまで継続」の仮定を上書きできない | 新しい時間的境界が永続性と競合するため拒否される | すべての永続性デフォルトを撤回可能としてタグ付けし、明示的なアサーションによる上書きを許可 |
検出ルール:
- 期間のないタイムスタンプを見たら → 点化
- 任意に選択された単一の関係を見たら → 時期尚早なコミットメント
- 伝播コストがKB全体のサイズに応じて増加したら → グローバル伝播爆発
- 空ラベル後に推論を継続したら → 空ラベル否定
- 新しい時間的事実が拒否されたら → 永続性の硬直性
実例
例1: 会議スケジュールの競合検出
シナリオ: 「クライアントコール」と「エンジニアリングスタンドアップ」が既に入っているカレンダーに「チームレビュー」を追加
初期状態:
クライアントコール (I₁): [10:00, 11:00]
エンジニアリングスタンドアップ (I₂): [11:30, 12:00]
既知: I₁ {before} I₂
新しいアサーション: チームレビュー (I₃): [10:45, 11:15]
エキスパートの推論トレース:
-
新しい関係を分類:
- I₃ vs I₁: 10:45に開始、I₁は11:00に終了 → {overlaps}
- I₃ vs I₂: 11:15に終了、I₂は11:30に開始 → {before}
-
制約伝播:
- I₁ {before} I₂ と I₃ {overlaps} I₁ から
- 推移性: overlaps ∘ before = {before, overlaps, meets, starts, during}
- 新しい制約: I₃ {before, overlaps, meets, starts, during} I₂
- I₃ {before} I₂ と交差: ラベルは {before} になる
-
一貫性チェック: すべてのラベルが空でない → スケジュールは実行可能だが重複あり
初心者が見逃す点:
- I₃とI₁の重複がリソース競合を引き起こすことをチェックしない可能性
- 推移性が一貫性を維持していることを確認しない可能性
- 「実行可能な順序」と「リソース競合の不在」を区別しない可能性
エキスパートが捕捉する点:
- 重複検出が関係分類によって即座にフラグされる
- 伝播によってグローバルな一貫性が維持されることを確認
- 時間的実現可能性とリソース可用性の明確な区別
例2: プロセスフェーズの依存関係
シナリオ: タスク完了時間に不確実性があるデプロイパイプライン
初期状態:
ビルドフェーズ (B): 期間不明、デプロイの前に終了する必要あり
テストフェーズ (T): ビルドの終わりと重複、期間不確定
デプロイフェーズ (D): BとTの両方が完了した後に開始
制約ネットワーク:
T {overlaps, finishes} B (テストはビルドと同時に終了するか、それより前に終了できる)
B {before, meets} D (ビルドはデプロイの前に完了しなければならない)
T {before, meets} D (テストはデプロイの前に完了しなければならない)
新しい情報: 「テストで重大なバグが見つかり、2時間延長」
エキスパートの推論:
- 更新がスコープに影響: テスト延長によりTの終了点が後ろにずれる
- 伝播: T {finishes} B だった場合、現在は T {overlaps} B（ビルド終了を超えて延長）
- 一貫性チェック: T {overlaps} B でも B {before, meets} D と T {before, meets} D は許容される
- 結果: デプロイは遅延するが、パイプラインロジックは維持される
初心者が見逃す点:
- テスト完了がビルド-デプロイの依存関係に影響しないと想定する可能性
- テスト延長の影響をデプロイのタイミングに伝播しない可能性
- 「テスト延長」を制約ネットワークの更新ではなく、孤立した事実として扱う可能性
エキスパートが捕捉する点:
- テスト-ビルド関係を再評価する必要があることを認識
- タイミングの影響を制約ネットワーク全体に伝播
- 不確実性を適切に維持（デプロイはビルド直後、または延長されたテスト後のいずれかで開始可能）
品質ゲート
時間推論タスクは、以下の条件が満たされた場合に完了します：
- すべての区間が明示的な開始/終了境界で表現されている（点イベントなし）
- すべての区間ペアが13の関係語彙からの空でないアークラベルを持っている
- 制約伝播が完了まで実行された（保留中の推移性更新なし）
- すべての選言的ラベルが現在の証拠を正直に反映している（恣意的なコミットメントなし）
- マルチスケール推論のための参照区間階層が確立されている
- 該当する場合、永続性のデフォルトが撤回可能としてタグ付けされている
- 非一貫性検出が検証されている（空ラベルが捕捉され報告される）
- クロスリファレンスのスコープブリッジが明示的に定義されている
- すべての時間アサーションが証拠ソースにトレースされている
- クエリスコープが推論の粒度レベルと一致している
適用外の境界
アレンの区間代数を以下の目的で使用しないでください:
- 単純なタイムスタンプ比較 → 算術を使用:
if (t1 < t2) - メトリックな期間計算 → カレンダー算術を使用:
end_date - start_date - リアルタイムスケジューリング最適化 → 数値ドメインを持つ制約充足問題を使用
- 確率的時間推論 → 時間確率ネットワークを使用
- 連続時間ダイナミクス → 微分方程式を使用
- 高頻度イベントストリーム → ストリーム処理フレームワークを使用
代わりに委譲してください:
- メトリック制約の場合: 数値ドメインを持つ制約充足問題 を使用
- 確率的時間推論の場合: ベイズ時間ネットワーク を使用
- リアルタイムシステムの場合: レート単調スケジューリング を使用
- 連続ダイナミクスの場合: 時間論理モデル検査 を使用
- イベントストリーム処理の場合: 複合イベント処理 を使用
アレンが優れている点: 不確実性、漸進的な知識更新、階層的なスコープ管理を伴う定性時間推論。