⬡ 開発ツール/2026-06-12上級

Rork の再生成と手動修正を共存させる — 上書きされない境界の引き方

設定画面の文言を直しただけの再生成で、前週に手で入れた広告まわりの修正が消えていました。AI が書く土地と人が守る土地を分けるディレクトリ境界、1行アダプタ、パッチ資産化、プロンプトの絞り方までを実測値とともに整理します。

✦ プレミアム記事

6月のはじめ、ストア公開直前の差分確認で手が止まりました。前の週に手で入れたはずの修正——ATT の同意ダイアログが閉じる前に広告 SDK の初期化を始めないようにするガード——が、跡形もなく消えていたのです。

直接のきっかけは私自身の操作でした。設定画面の文言を直したくて Rork に小さな修正を頼み、出力されたプロジェクトをそのままエクスポートした。それだけです。Rork は依頼どおり文言を直し、同時に、依頼していない場所を生成時点の「正しい姿」に揃え直していました。手動修正は、AI から見れば揃え直すべき逸脱のひとつだったわけです。

再生成は Rork の中核的な強みで、これを手放す選択はありません。一方で、エクスポート後のコードに手を入れる場面は、運用が長くなるほど確実に増えます。広告（AdMob）の初期化順序、課金イベントの取りこぼし対策、クラッシュへの応急対処。つまり「再生成を続けながら、手動修正も守る」を構造として成立させる必要があります。

私はこの出来事を境に、プロジェクトの中に「AI が書く土地」と「人が守る土地」を明示的に分ける設計へ切り替えました。以下、その境界の引き方を、実測と実装、日々の取り込み手順まで含めて書いていきます。

再生成が手動修正を消す仕組みを、数字で確かめる

Rork のチャットへの依頼は、ファイル単位の編集指示ではありません。「アプリがこうあるべき」という状態への指示で、その実現に関わるファイルがまとめて再構成されます。どのファイルが書き換わるかは、依頼文の小ささからは予測できません。

これを体感ではなく数字にしておきたくて、運用中のプロジェクトの複製に対して影響範囲が小さいはずの依頼を3種類投げ、書き換わったファイル数を git diff --stat で数えました。

依頼内容                                書き換わったファイル数
設定画面のボタン文言を1箇所変更               7
ホーム画面のカードの角丸を 8 → 12 に変更      4
設定画面にトグルを1つ追加                   11

文言1箇所の変更で 7 ファイルです。依頼に直接関係していたのは 1 ファイルだけで、残る 6 ファイル、率にしておよそ 85% は依頼と無関係の書き換えでした。内訳を見ると、目的のファイルに加えて、共有フックやユーティリティが体裁の揃え直しで書き換わっていました。diff の大半は無害な整形です。問題は、その無害な差分の山の中に、手動修正の打ち消しが 1〜2 行だけ混ざることです。数百行の diff から毎回それを人の目で拾い続けるのは、現実的ではありません。

ここから引ける結論は「再生成を避ける」ではありません。再生成されても壊れない場所に手動修正を置く。発想をそちらへ切り替えます。

境界の原則 — 上書きされてよい土地と、守る土地を分ける

私が運用しているルールは3つだけです。

第一に、Rork が生成するツリーは全て「いつ上書きされてもよい」とみなします。app/ も components/ も hooks/ も、次の再生成で消える前提で扱い、ここには手動修正を直接書きません。

第二に、手で書くコードは guarded/ という独立ディレクトリに隔離します。名前は何でも構いません。重要なのは「Rork が生成しないパスである」ことと、「取り込み時に機械的に保護できる」ことの2点です。

第三に、生成コードから guarded/ への接続は、1行の import と1回の関数呼び出しまでに絞ります。接続点が細いほど、再生成で消えたときの復旧が「1行戻す」だけで済みます。

ディレクトリはこうなります。

project/
├── app/              # Rork の土地（いつ上書きされてもよい）
├── components/       # 同上
├── hooks/            # 同上
├── guarded/          # 人の土地（再生成の影響を受けない）
│   ├── ads/
│   │   └── initializeAds.ts
│   ├── analytics/
│   │   └── track.ts
│   └── billing/
│       └── listeners.ts
└── patches/          # guarded に移せない修正のパッチ置き場（後述）

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦文言1箇所の変更依頼で 7 ファイルが書き換わった実測から導く、被害半径を前提にした境界設計の原則

✦広告・課金・計測の手動ロジックを再生成から守るアダプタ層の TypeScript 実装と接続点を1行に絞る理由

✦git format-patch で手動修正を資産化し、再生成のたびに機械的へ再適用する取り込みフローの全コマンド

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

アダプタ層の実装 — 画面が呼ぶのは薄い入口だけにする

冒頭で消えた ATT ガードを例に、手動ロジックを guarded/ へ引き剥がします。消える前の状態では、app/_layout.tsx の中に初期化処理が直接書かれていました。再生成のたびにこのファイルは書き直されるので、ここに置いた修正は必ずいつか消えます。

本体を guarded/ads/initializeAds.ts に移します。

// guarded/ads/initializeAds.ts
// ATT → UMP 同意 → SDK 初期化の順序を保証する。二重呼び出しは無視。
import { Platform } from "react-native";
import mobileAds from "react-native-google-mobile-ads";
import {
  getTrackingPermissionsAsync,
  requestTrackingPermissionsAsync,
} from "expo-tracking-transparency";
 
let started = false;
 
export async function initializeAdsOnce(): Promise<void> {
  if (started) return;
  started = true;
 
  try {
    if (Platform.OS === "ios") {
      const current = await getTrackingPermissionsAsync();
      if (current.status === "undetermined") {
        // ダイアログが閉じるまで SDK 初期化を始めない（消えていたのはこの待機）
        await requestTrackingPermissionsAsync();
      }
    }
    await mobileAds().initialize();
  } catch (e) {
    // 広告の初期化失敗でアプリを止めない。ログだけ残して次回の再試行を許す
    console.warn("[ads] initialize failed", e);
    started = false;
  }
}

画面側に残すのは入口の1行だけです。

// app/_layout.tsx（Rork の土地に置く接続点は1行だけ）
import { initializeAdsOnce } from "../guarded/ads/initializeAds";
 
useEffect(() => {
  void initializeAdsOnce();
}, []);

再生成で _layout.tsx が書き直されても、失われるのはこの1行だけです。復旧は import と呼び出しを戻すだけで、ATT の順序やエラー処理という本体は無傷のまま残ります。

同じ型がそのまま使えるのは、アナリティクスの送信ファサード、課金イベントのリスナー登録、Remote Config の既定値定義あたりです。共通するのは「壊れても画面では気づきにくく、気づいたときには被害が積み上がっている」処理だという点です。

取り込み手順 — 再生成はブランチで受け、guarded を機械的に守る

境界を引いたら、エクスポートの取り込みを毎回同じ手順に固定します。やることは次の5つです。

エクスポートを受け皿ブランチへ丸ごと反映する
被害半径を diff の統計で先に確認する
guarded/ に差分がないことを機械的に検証する
main へ合流させる
接続点の import が生きていることを確認する

私は main をストアに出す正本、rork-sync を Rork エクスポートの受け皿にしています。

# 1. エクスポートを受け皿ブランチへ丸ごと反映
git checkout rork-sync
rsync -a --delete --exclude .git --exclude guarded --exclude patches \
  ~/Downloads/rork-export/ ./
git add -A && git commit -m "sync: rork export $(date +%Y%m%d)"
 
# 2. 被害半径を先に数字で見る
git diff main...rork-sync --stat | tail -5
 
# 3. guarded/ に差分が出ていないことを機械的に確認（出たら設計違反）
git diff main...rork-sync --stat -- guarded/ | wc -l   # 0 であること
 
# 4. main へ合流
git checkout main
git merge rork-sync
 
# 5. 接続点の生存確認
grep -rn "initializeAdsOnce" app/ | wc -l   # 1 以上であること

ポイントは 2 と 3 を merge より前にやることです。統計を先に見ておくと、「文言修正のはずなのに 30 ファイル動いている」といった異常に、コードを読み始める前に気づけます。

一度だけ、手順 3 がゼロになりませんでした。原因を辿ると、guarded の中身を Rork のチャットに貼り付けて相談したことがあり、その内容が生成対象に取り込まれていました。境界は AI 側が覚えてくれるものではなく、運用する人間の手順で守るものだと実感した一件です。

guarded に移せない修正は、パッチとして資産化する

すべての手動修正が guarded/ に移せるわけではありません。生成されたファイルの内部に 1〜2 行だけ手を入れたい場合があります。一覧画面の FlatList に removeClippedSubviews を足す、生成されたフェッチ処理にタイムアウトを足す、といった類です。

この種の修正は、1修正 = 1パッチの粒度で patches/ に保存しています。

# 修正を1コミットにまとめてから、説明的な名前でパッチ化
git format-patch -1 HEAD -o patches/
mv patches/0001-*.patch patches/flatlist-remove-clipped-subviews.patch
 
# 再生成の取り込み後に、全パッチを機械的に再適用
git am --3way patches/*.patch
# 当たらないパッチだけが止まるので、そこだけ人が判断する

実測では、patches/ にある 9 個のパッチのうち、再生成 5 回をまたいで自動適用が通り続けたのは 4 個でした。残りは生成側の構造変化で当たらなくなりました。ただ、これは失敗ではないと考えています。「当たらなくなったパッチ」は、その修正を guarded/ へ昇格させるか、Rork への恒久指示に変換するかを検討する明確なシグナルとして機能するからです。

プロンプトで被害半径を狭める — ただし境界の代わりにはしない

依頼文の書き方でも、書き換え範囲はある程度狭まります。先ほどの「ボタン文言1箇所」の依頼に制約を書き添えて比較しました。

制約なしの依頼では 7 ファイルが書き換わりました。「変更は設定画面の表示文言だけにしてください。ナビゲーション、フック、ユーティリティ、他の画面には触れないでください」と添えた依頼では、2 ファイルに収まりました。プロジェクトの説明欄に「guarded/ 以下は変更しない」と恒久指示を書いておくのも効きます。

効果は明確にあります。それでも、プロンプトを境界の代わりにはしません。指示の遵守は確率的で、生成のたびに結果が揺れるからです。構造（guarded とパッチ）が防波堤、プロンプトは波を小さくする工夫。この主従を逆にしないことが、長期運用では効いてきます。

運用して固まった、任せ方の基準

半年ほどこの体制で本番運用を回して、Rork に任せる領域と人が守る領域の線引きは次の形に落ち着きました。

画面のレイアウト、遷移、文言、色やアイコンといった「壊れたら起動した瞬間に気づくもの」は、すべて Rork に任せます。再生成の恩恵が最も大きい領域でもあります。

広告と課金の初期化順序、データの永続化、アナリティクスの送信は guarded/ に置きます。ものさしはシンプルで、「壊れたことに気づくまでの時間が長いものほど、人の土地に置く」です。課金イベントの取りこぼしや初期化順序の崩れは、画面上では何も起きず、数字に表れるまで数日かかります。個人開発では、その数日が売上と信頼の毀損として直接返ってきます。

時間の面では、取り込みのたびに 30 分ほどかけていた diff の目視レビューが、境界導入後は 5〜10 分に収まるようになりました。レビューの中身が「guarded に差分ゼロの確認」と「止まったパッチの判断」に置き換わったためです。

最初の一歩としては、guarded/ を作り、広告か課金の初期化をひとつ移すところから始めることをお勧めします。接続点が1行になったときの安心感は、次に再生成ボタンを押す指の軽さに、そのまま表れます。再生成と長く付き合っていく方の足場になれば幸いです。