# 施設到達可否の表示処理軽量化 — 2026-09-29

## 変更

開業ガイドは到達可否しか表示しないが、従来は施設の全候補入口から最安経路を選ぶ詳細レポートを取得していた。
Runtime に `is_facility_reachable` を追加し、到達可能な候補が一つ見つかれば終了する。候補生成を Guest AI と共用し、入口、アクセス禁止、通行制約は同じとする。状態キャッシュは追加せず、遮断や復元後もその時点の経路で判断する。
実際の客の移動は従来の最安経路選択を維持。保存形式・ゲーム内経済・施設数に変更なし。

## 検証

- 新規回帰 `tests/performance/test_facility_reachability.gd`: 33チェックPASS。実際に建設した複数階施設で既存詳細レポートとの一致、存在しない施設、アクセス禁止、入口遮断、保存復元を確認。
- 既存のインフラ統合180、スナップショット所有権89、清掃アクセス6チェックPASS。
- 同一プロセス・同一状態・順序を交替する100回の計測（各回はデモ全施設の一巡）: 詳細レポート平均6222.41µs/P95 6391µs、到達可否平均4222.04µs/P95 4335µs。平均約32%短縮。
- 計測機: macOS Apple M4、Godot 4.7.2、headless。小規模デモのこの照会処理だけの測定であり、全体Tick予算やWindows描画性能の合格ではない。

証拠: `artifacts/facility-reachability-2026-09-29/` の comparison.json、comparison-summary.json、関連試験ログ、変更前ソース。
通しデバッグの結果は同ディレクトリの opening-restart に保存する。

前回の Windows-cleaning ZIP は変更前のソースを固定した成果物であり、この軽量化を含むとは扱わない。

描画あり通しデバッグ: 書込80＋再起動読込17＝97チェックPASS（62.91秒＋48.00秒）。実行中のソース変更なし、再起動前後のゲーム状態JSON一致。3営業日の決算まで完走し、再起動後の3日目決算画面を目視確認。