作った後の話、
誰もしない。

動かし続けるために向き合わなければならないものを並べると、こうなる。

全部を同じ優先度で扱うと、何もできなくなる。優先度の基準は「対応しなかったときのリスクの大きさ」だ。

セキュリティ脆弱性は即対応が原則だ。CVE（脆弱性情報データベース）や使用しているライブラリのリポジトリをウォッチしておき、criticalやhigh評価のものはパッチが出たらできるだけ早く当てる。対応が遅れた時間は、そのままリスクが続く時間だ。

パッケージ更新は「溜めないこと」が一番の対策になる。大量に溜めてから一気に更新しようとすると、破壊的変更が重なって手に負えなくなる。マイナーバージョンは月次、メジャーバージョンは半期に一度くらいのペースで向き合う習慣をつけると、毎回の更新コストが小さく済む。

プラットフォーム追従はOSのリリーススケジュールに合わせて計画する。iOSは毎年9月前後にメジャーアップデートが来る。その1〜2ヶ月前から動作確認を始め、対応が必要なら修正してリリースする。バグ対応はSeverity（重大度）で仕分けして、クラッシュや動作不全から先に片付ける。UX改善やコンテンツ修正は後回しにしてもいい。

個人開発でこれを全部やるのは、かなり重い。だから最低限として「クラッシュは毎日見る、パッケージは月に一度確認する、OS追従は年次で計画する」の3つだけでもやっておくと、致命的な状態を避けられる確率が上がる。

一番わかりやすいのはストアからの削除だ。Appleは定期的に、古いSDKバージョンに対応していないアプリに警告を送り、更新がなければ削除する。通知は来るが、見落としたまま放置すると数ヶ月後にアプリが消える。ユーザーがいれば当然クレームになる。

セキュリティ脆弱性を放置した場合は、悪意ある第三者に攻撃される可能性がある。Firebaseのセキュリティルールが甘ければ大量リクエストで課金が爆発する。認証の穴があればデータが抜かれる。気づいたときには損害が出ている、というのがこのリスクの厄介な点だ。予防コストより事後対応コストの方が、桁違いに高い。

パッケージを長期間更新しないと、「更新したいのに更新できない」状態になる。依存パッケージ間の互換性が崩れ、一つ更新すると別が壊れる。その状態で新機能を追加しようとしても、土台が腐っているから乗せられない。技術的負債は利子がつく。後回しにすればするほど、返済コストが上がっていく。

運用保守の最も残酷な特性は、うまくやっても誰にも見えないことだ。脆弱性を塞いでも「ありがとうございます、セキュリティを維持してくれて」とは誰も言わない。パッケージを最新に保っていても、ユーザーには何も変わって見えない。iOS新バージョンに対応して動作を維持しても、それは「当たり前」として処理される。

一方で、何かが壊れたときは即座に見える。「動かなくなった」「クラッシュする」「データが消えた」——問題が表面化した瞬間に批判が来る。何百時間もかけて維持してきた実績より、一回の障害の方が印象に残る。これはインフラエンジニアが長年感じてきた非対称性と全く同じ構造だ。

バイブコーディングで作った側には、この現実が届きにくい。作るのは楽しい。でも運用は楽しくない。「楽しくないのに続けなければならない」という時間が、アプリの寿命の大半を占める。その覚悟がないままリリースすると、問題が出た段階で詰まる。

運用コストに向き合えないなら、向き合わなくて済む構成を最初から選ぶか、畳み方を決めておくかのどちらかだ。

保守が少ない構成を選ぶという方向は現実的だ。外部依存が少ないほど更新の必要がなくなる。静的サイトならサーバー管理がほぼ不要だし、ライブラリを最小限にすれば更新対象も減る。Firebaseを使うならルールだけ正しく書いてあれば、コア機能は長期間維持できる。「シンプルに作る」は設計の美学だけでなく、運用コストの削減でもある。

畳み方を決めておくことも、作る前から考えておくべきことだ。いつ、どういう条件になったら終了するか。ユーザーへの告知をどうするか。データはどう扱うか。運用できなくなったときに「突然消える」だけでは、使っていたユーザーへの責任を果たせない。サービス終了はプロジェクトの一部だ。

もう一つの選択肢はOSSとして公開することだ。自分で保守できなくなっても、コードを公開して誰かに引き継げる形にしておく。ユーザーがゼロでなければ、誰かが引き取ってくれる可能性がある。