最低サポート iOS をいつ上げるか — 利用率ではなく、コードに残った分岐の数で決める
最低サポート OS の引き上げを利用率で判断すると、毎年同じ結論になって先送りが続きます。OS 分岐に注記を付けて棚卸しし、引き上げ先ごとに消せる分岐を数えるスクリプトと、引き上げ後に見る指標をまとめました。
役目を終えたアプリをどう畳むか — 更新停止から完全終了までを先に設計する
収益がサーバ費を下回ったアプリを、どの順番で畳むか。更新停止・販売取り下げ・完全終了の3段階の判断表、サーバ由来の終了告知フラグとデータ持ち出し口のTypeScript実装、自動更新購読の後始末までを個人開発の実感から整理しました。
Rork Max 生成コードの再生成ゾーン設計 — 手を入れるほど失われる「作り直せる自由」を残す
Rork Maxの生成コードに乗っている「捨てて作り直せる」という見えない資産は、手を入れるたびに静かに失われます。再生成ゾーンの残し方、境界に置く型の決め方、台帳とCI検査によるドリフト検出、四半期ごとの再生成テストまで、個人開発の実運用からまとめます。
AI再生成に壊されない設計 — Rork の生成コードと手書きロジックを分ける境界の引き方
Rork へ追加指示を出すたびに手書きのロジックが消える。プロンプトで守るのは対症療法です。生成コードと自分の所有コードを層で分け、再生成が届かない境界を設計で引く方法を、Zustand と service 層の実装例つきでお伝えします。
どの生成でこの不具合が入ったのか — Rork アプリに生成来歴を刻む長期運用設計
AI ビルダーで同じ画面を何度も作り直していると、ある日現れた不具合がどの生成で入ったのか追えなくなります。ビルドスタンプ・生成台帳・テレメトリ埋め込みの3層で生成来歴を残し、リグレッションを世代単位で絞り込む設計をまとめました。
Rork 製アプリの expo-sqlite で、テーブル構造を変えてもデータを消さない — PRAGMA user_version で作る順次マイグレーション
「no such column」で起動直後に落ちる。テーブル構造を変えた新バージョンを既存ユーザーに配ると起きる事故です。expo-sqlite の PRAGMA user_version を使い、カラム追加・テーブル再構築・外部キーを含むスキーマ変更をユーザーデータを守りながら順に適用する設計を、実装の全文と運用ルールとしてまとめました。
Rork が生成したアプリの依存関係を棚卸しする — 供給網リスクを増やさない監査の習慣
画面四枚の小さな Rork アプリでも、間接依存は 900 を超えます。脆弱性が出たときどのアプリが影響するか分からなくなる前に、npm ls・npm audit・overrides・depcheck を使った棚卸しの習慣を、複数アプリ運用の視点で整理します。
Rork の再生成と手動修正を共存させる — 上書きされない境界の引き方
設定画面の文言を直しただけの再生成で、前週に手で入れた広告まわりの修正が消えていました。AI が書く土地と人が守る土地を分けるディレクトリ境界、1行アダプタ、パッチ資産化、プロンプトの絞り方までを実測値とともに整理します。
アップデートでお気に入りを消さないために — Rork 製アプリのローカルデータ・マイグレーション設計
「アップデートしたらお気に入りが消えた」という星1レビューを受け取らないための設計です。封筒形式とスキーマバージョン、マイグレーションランナーの実装、EAS Update をスキーマ中立に保つ運用ルールまでを実体験から整理しました。
クラッシュ率上昇時にAdMobを自動で絞る『収益を守る自動制動』アーキテクチャ — Rork × Firebase Remote Config × Crashlytics の連動設計
クラッシュ率が跳ね上がった瞬間、ユーザーに広告を出し続けて評価を落とすか、いったん広告を絞って安定性を守るか。12年の個人開発運用で出した答えは、Firebase Remote Config と Crashlytics のシグナルを AdMob に連動させる4状態の自動制動アーキテクチャでした。
Rork で作った個人アプリを3年以上持たせるための保守設計 — アプリ老化と静かに戦う実践
Rork で作ったアプリを長く運用していくと、リリース直後には見えなかった「老化」が少しずつ現れてきます。OS 更新、ライブラリの破壊的変更、ユーザーの端末環境の変化。私が10年以上アプリを運営してきた経験と、Rork で作ったアプリを2年以上運用してきた中で、3年目以降も安定させるために大事にしている保守設計の考え方をまとめます。