設定だけ直すつもりが、気づけば一晩で 9 回も再生成を回していました。運用中の壁紙アプリで、特定の端末だけサムネイル一覧がときどき真っ白になる——その一件です。
Rork のチャットに症状を伝えると、最初の修正案はもっともらしく出てきました。けれど直したつもりの箇所を本番環境のビルドで確かめると、今度は別のリストでスクロールが引っかかります。そこをまた頼むと、最初の白画面が再発します。修正と再発を行き来するうちに、夜が更けていました。
翌朝に冷静になって気づいたのは、私が「直るまで頼み続ければいい」と無意識に思い込んでいたことです。Rork のバグ修正は確かに優秀で、私の体感でも、渡したバグのおよそ 7 割はほとんど手を入れずに片づきます。問題は残りの 3 割で、ここに同じ姿勢で踏み込むと、昨夜のような堂々巡りに入ります。
個人開発で複数のアプリを並行して回していると、この 3 割をいかに早く見抜いて手作業へ切り替えるかが、そのまま一日の生産性を決めます。以下では、夜なべの反省から組み立てた、バグを AI に任せ続けるか手で引き取るかのトリアージ手順を、退却ラインと回帰ガード、判断ログまで含めて書いていきます。
自己解決する 7 割と、手が必要な 3 割はどこで分かれるか
まず押さえておきたいのは、Rork が得意なバグと苦手なバグには、はっきりした傾向があるという点です。
得意なのは、症状が安定して再現し、原因が一つのまとまりに収まっているバグです。「このボタンを押すと必ずクラッシュする」「この画面だけ余白が崩れる」といった種類は、再生成の一往復で直ることが多いです。Rork は症状の記述から該当箇所を絞り込み、周辺ごと整える形で修正を返してくれます。
苦手なのは、症状が確率的にしか出ないバグ、複数の要因が絡むバグ、そして本番環境とプレビューで挙動が変わるバグです。昨夜の白画面は、画像キャッシュの破棄タイミングと描画の競合という、まさに確率的で複合的な種類でした。再現条件が言葉で固定できないため、Rork は毎回「ありそうな原因」を別々に潰しにいき、私はその場当たりの修正を順番に踏んでいたわけです。
この線引きを感覚に任せると、つい「あと一回頼めば」と粘ってしまいます。そこで踏み込む前に必ず通す判断軸を、三つに絞りました。
トリアージの判断軸を三つに絞る
新しいバグに出会ったら、Rork のチャットを開く前に、次の三点を声に出して確かめます。
1. 症状は決定的に再現するか
同じ操作で 100% 再現するなら、Rork に任せて構いません。再現手順を箇条書きで添えれば、修正の精度はさらに上がります。逆に「ときどき」「特定の端末で」という言葉が出た時点で、自己解決の確率は大きく下がると見ておきます。確率的なバグは、まず再現条件の特定を人間側で進めるほうが速いです。
2. 修正の影響は局所か広域か
一画面・一コンポーネントに閉じる修正なら、再生成の被害半径は小さく保てます。一方、広告（AdMob）の初期化順序や課金状態の判定のように、アプリ全体へ波及する箇所は、再生成が無関係なファイルまで揃え直すリスクを抱えます。広域に触るバグは、Rork に丸ごと任せず、人が境界を決めてから部分的に頼みます。
3. 失敗は取り返しがつくか
レイアウトのずれなら、間違えてもやり直せます。しかし、ストア審査直前のビルドや、課金レシートの検証ロジックは、失敗が公開済みユーザーへ届いてしまう領域です。取り返しのつかない場所では、AI の提案を採用する前に、必ず人間の確認を一段挟みます。
この三軸を通すだけで、昨夜の白画面が「確率的・広域・低リスク」に分類でき、最初から再現条件の調査に時間を割くべきだったと、はっきり分かります。
任せ続ける前に「退却ライン」を決めておく
トリアージで「任せる」と判断したバグでも、無制限に再生成を回してはいけません。私は再生成に三回ルールを設けています。
同じバグに対する再生成が三往復を超えても直らなければ、それは Rork が苦手とする 3 割に入っていたという合図です。四回目を頼む代わりに、いったん手を止めて、症状の切り分けに回ります。
退却ラインを言語化しておくと、深追いの誘惑をかなり抑えられます。判断を勢いではなく事前の取り決めに委ねられるからです。具体的には、再生成のたびに次の三点だけメモします。
- 何回目の依頼か
- 何を直すよう頼んだか
- 結果として新しい症状が出たか
三回目で「新しい症状」の欄が二つ以上埋まっていたら、それ以上は任せません。症状が増えているのは、原因に届いていない証拠だからです。
手で直す側に回ったときの回帰ガード
手作業へ切り替えると、今度は別の不安が出てきます。せっかく手で直しても、次に Rork へ別の依頼をしたとき、再生成で上書きされてしまうのではないか、という不安です。
私はこれを、テストで物理的に止める形にしています。手で直したバグには、必ずその再発を検知する回帰テストを一本足してから先へ進みます。先ほどの白画面なら、サムネイルのデータ整形が空配列を返さないことを確かめる、こんな小さなテストです。
// thumbnails.test.ts — 白画面の再発を検知する回帰ガード
import { buildThumbnailRows } from "./thumbnails";
describe("buildThumbnailRows", () => {
it("壊れた画像メタを含んでも空配列を返さない", () => {
const input = [
{ id: "a", uri: "file://ok.jpg", width: 1080, height: 1920 },
{ id: "b", uri: "", width: 0, height: 0 }, // 破損データ
];
const rows = buildThumbnailRows(input, { columns: 2 });
expect(rows.length).toBeGreaterThan(0);
expect(rows.flat().every((cell) => cell.uri !== undefined)).toBe(true);
});
});
このテストが通る限り、たとえ Rork が整形ロジックを再生成しても、白画面の条件は復活しません。万一それを壊す再生成が来れば、テストが赤くなり、push 前に気づけます。手で直した 3 割を守る防波堤は、注意力ではなくテストに持たせるのが私の推奨です。
エラーを再現するテストを先に書き、それから直す。手作業に回った瞬間こそ、この順序が効いてきます。
引き継ぎを記録に残す — 判断ログのすすめ
トリアージを続けていると、同じ種類のバグに何度も出会います。そのたびに一から判断していては、せっかくの夜なべが資産になりません。
そこで手で引き取ったバグについて、短い判断ログを残しています。形式は決まっていて、後から検索できることだけを重視しています。
日付: 2026-06-17
症状: 特定端末でサムネイル一覧が確率的に白画面
分類: 確率的 / 広域 / 低リスク
Rork に任せた回数: 3（退却ラインで停止）
原因: 画像キャッシュ破棄と描画の競合
手で入れた対処: 整形時に空配列ガード + 回帰テスト追加
次回の指針: 確率的な描画バグは最初から手で切り分ける
このログがたまると、新しいバグに出会ったとき「これは前の白画面と同じ系統だ」と一目で当たりがつきます。Rork へ再び依頼する場合も、原因と対処をそのまま貼れば、的外れな再生成の往復を省けます。判断ログは、未来の自分への引き継ぎであると同時に、AI への引き継ぎ資料にもなります。
App Store と Google Play の両方へ複数アプリを出していると、同じ系統のバグが別アプリで再発することも珍しくありません。ログがあれば、一度きりの解決を横展開できます。
任せる 7 割の精度を、頼み方で底上げする
トリアージで「任せる」と決めたバグは、頼み方しだいで一往復の成功率がさらに上がります。私が Rork に渡すときは、症状だけを書かず、四つの要素を必ずそろえます。
【症状】 設定画面で言語を切り替えると、一覧の並びが前の言語のまま残る
【再現手順】 1) 設定を開く 2) 言語を英語へ 3) 一覧画面へ戻る
【期待する挙動】 言語切替の直後に一覧が新しい言語で並び替わる
【触ってよい範囲】 一覧画面とそのフックのみ。広告と課金の初期化には触れない
最後の「触ってよい範囲」が、再生成の被害半径を縛る一文です。Rork は依頼の周辺を整えにいく性質があるため、触れてほしくない場所を先に宣言しておくと、無関係なファイルの揃え直しをかなり防げます。期待する挙動を一行で添えるのも効果的で、Rork が「直ったかどうか」を自己判断する基準になります。
逆に言えば、この四要素を一行で書けないバグは、たいてい確率的か複合的な 3 割の側にあります。頼み方を整える作業そのものが、トリアージの最終確認も兼ねています。
次の一歩
まずは、いま抱えているバグを一つ選び、Rork に頼む前に三軸——再現性・影響半径・失敗コスト——で分類してみてください。確率的・広域・取り返しのつかない、のどれかに当てはまるなら、その一件は最初から手で切り分ける価値があります。任せる範囲を決めることは、AI を信頼しないことではなく、AI が最も力を発揮する 7 割に集中させるための準備だと感じています。