新機能・最適化・専用基盤は、最初から恒久・大規模・最適化済みにしない。最適化するのは「可逆で安価な最小構成で価値と要件適合を先に確かめ、規模・遅延・適合が実測で必要を示してから本格化すること」、避けるのは「将来必要かもしれない、で先に専用基盤・索引・常時処理・高機能モデルを入れ、ノイズと不可逆な負債だけ抱えること」。

判断基準

• 専用基盤を増やす前に、既存資産で代替できないか見る。小規模なら専用ベクトル DB を増やすより既存 RDB の拡張で足り、コストも運用も軽い。新インフラは規模が実際に要求してから足す。
• 索引・最適化は遅くなってから足す。件数が小さいうちは全件スキャンで十分速いことが多く、最初から索引を張ると上限・保守コストだけ抱える。次元・解像度なども、まず控えめな構成で動かし実機で精度・遅延を見てから詰める。
• 品質を落としたくない経路（表示・撮影など）は元のまま保ち、最適化は影響の小さい裏側だけに限定する。最初から全体を最適化前提にしない。
• PoC で試した既製品・汎用モデルを、要件適合を確かめずに本線へ昇格させない。可逆な検証段階と本番採用を分け、適合を先に検証する。

なぜ

最小・安価・可逆な構成は、外れても捨てやすく、当たれば本格化の足場になる。先に重い構成を入れると、価値が出ない場合の不可逆コストと、消費側が育つまでのノイズだけが残る。

検証

導入予定の専用化・最適化について「いま実測で必要か」「既存資産で代替できないか」「外れたとき安く戻せるか」に答えられるか確認する。答えられないうちは最小構成で検証し、必要が見えてから本格化する。

根拠（synthesize 元）

• 505 追加インフラなしでセマンティック検索を導入する構成（既存 PostgreSQL + 埋め込み API）
• 504 Bun ORM + pgvector をスキーマ自動生成と共存させる（索引は遅くなってから後付け）
• 561 リアルタイム矩形検出は検出解像度と撮影解像度を分ける（控えめな縮小から実機で詰める）