アプリを App Store に公開した直後、多くの個人開発者が思いがちなのが「公開できた、あとはダウンロード数を待つだけ」という感覚です。でも実際のところ、公開は始まりに過ぎません。リリース後の改善サイクルをどれだけ素早く回せるかが、アプリが伸びるかどうかを決める大きな要因になります。
Rork の強みはプロンプトでアプリを作れること。でもそれは「最初のリリースを速く出せる」だけでなく、「リリース後の改善も AI との対話で進められる」という意味でもあります。リリース後のデータを集めて Rork の AI にフィードバックし、継続的にアプリを改善していくワークフローを実例とともに整理しました。
「公開して終わり」になりがちな理由
個人開発で公開後に改善が止まりやすいのには、はっきりした理由があります。
まず「何を直せばいいかわからない」という問題です。ユーザーレビューが1件2件ついても、それが全体を代表しているのか判断できありません。クラッシュが起きていても、どの端末・どの操作で再現するのかが特定できありません。漠然と「もっと良くしたい」と思っていても、具体的な手が打てずに止まってしまいます。
もうひとつは「改善のサイクルを回す習慣がない」という問題です。最初のリリースには期限と熱量がありますが、リリース後の改善には締め切りがありません。意識的に仕組みを作らないと、いつの間にかアプリが放置状態になっていきます。
Rork + AI の組み合わせは、この2つの問題を同時に解決するのに向いています。データの収集・解釈を AI に手伝ってもらい、改善の方向性が決まったら Rork のプロンプトで素早く実装します。このサイクルさえ作れれば、エンジニアでなくても継続的にアプリを育てられます。
改善を支える3つのデータソースを整備する
継続改善の土台は、データを自動的に集める仕組みを最初から作っておくことです。
App Store Connect のレビューと評価
最も手軽で重要なデータソースです。ユーザーが何に不満を感じているか、何を気に入っているかが、生の言葉で集まります。
App Store Connect の「App Analytics」→「レビュー」から確認できますが、件数が増えてくると全部読むのが大変になります。そこで便利なのが、App Store Connect API を使ってレビューを取得し、AI で要約するスクリプトです。
// App Store Connect API でレビューを取得して要約する例
// Rork のバックエンドに組み込むか、ローカルで定期実行する
const ISSUER_ID = 'YOUR_ISSUER_ID';
const KEY_ID = 'YOUR_KEY_ID';
// 秘密鍵は環境変数から読み込む（コードに直書きしない）
const PRIVATE_KEY = process.env.APP_STORE_CONNECT_PRIVATE_KEY;
async function fetchRecentReviews(appId, limit = 50) {
// JWT 生成（jose ライブラリ使用）
const { SignJWT } = await import('jose');
const privateKey = await importPKCS8(PRIVATE_KEY, 'ES256');
const jwt = await new SignJWT({})
.setProtectedHeader({ alg: 'ES256', kid: KEY_ID, typ: 'JWT' })
.setIssuedAt()
.setIssuer(ISSUER_ID)
.setExpirationTime('20m')
.sign(privateKey);
const url = `https://api.appstoreconnect.apple.com/v1/apps/${appId}/customerReviews?limit=${limit}&sort=-createdDate`;
const res = await fetch(url, {
headers: { Authorization: `Bearer ${jwt}` },
});
if (\!res.ok) {
throw new Error(`API エラー: ${res.status} ${await res.text()}`);
}
const data = await res.json();
// レビューのタイトルと本文を抽出
return data.data.map(r => ({
rating: r.attributes.rating,
title: r.attributes.title,
body: r.attributes.body,
date: r.attributes.createdDate,
}));
}
// 取得したレビューを Claude API でまとめる
async function summarizeReviews(reviews) {
const reviewText = reviews
.map(r => `[${r.rating}星] ${r.title}: ${r.body}`)
.join('\n');
const response = await fetch('https://api.anthropic.com/v1/messages', {
method: 'POST',
headers: {
'x-api-key': process.env.ANTHROPIC_API_KEY,
'anthropic-version': '2023-06-01',
'content-type': 'application/json',
},
body: JSON.stringify({
model: 'claude-opus-4-6',
max_tokens: 1024,
messages: [{
role: 'user',
content: `以下のアプリレビューを分析して、改善すべき点を優先度順に3つ挙げてください:\n\n${reviewText}`,
}],
}),
});
const result = await response.json();
return result.content[0].text;
}
// 使用例
const reviews = await fetchRecentReviews('YOUR_APP_ID');
const summary = await summarizeReviews(reviews);
console.log('改善優先度:\n', summary);
// 出力例:
// 1. ログイン後に白い画面が表示されると複数報告あり（緊急）
// 2. ダークモード対応を求める声が多い（高）
// 3. 読み込み速度の改善要望（中）このスクリプトを週1回実行するだけで、「今週どんな問題があったか」を整理された形で把握できます。
Firebase Crashlytics でクラッシュを自動検出する
ユーザーはクラッシュしても必ずしかレビューを書かないので、Crashlytics は必須の設定です。Rork のプロジェクトへの組み込みは、Firebase を Supabase の代わりに使う選択をした時点で連動します。
クラッシュが起きたとき、Crashlytics のダッシュボードで「このクラッシュは何行目で起きているか」は分かりますが、Rork で生成されたコードの文脈では読み解きにくい場合があります。そのときは、スタックトレースをそのまま Rork の AI に渡すのが一番速いです。
// Rork へのプロンプト例
クラッシュログです。このエラーが起きる原因と修正方法を教えてください:
Fatal Exception: com.example.myapp
java.lang.NullPointerException: Attempt to invoke virtual method
'void com.example.myapp.UserSession.refresh()' on a null object reference
at com.example.MainActivity.onResume(MainActivity.kt:47)
at android.app.Activity.performResume(Activity.java:8147)
// → Rork の AI が原因と修正コードを提案してくれる
ユーザー行動データで「どこで離脱しているか」を知る
レビューとクラッシュログは「起きた問題」を教えてくれますが、「どこで静かに離脱しているか」は別のデータが必要です。Mixpanel や Amplitude を組み込むと、画面ごとの離脱率やユーザーの行動フローが可視化できます。
Mixpanel でユーザー行動を分析する方法では、Rork プロジェクトへの組み込みから基本的なイベント設計まで説明していますので、まだ設定していない方はこちらが参考になります。
AI に正確なフィードバックを渡すプロンプトの設計
データが集まったら、次は Rork の AI に改善依頼を出す番です。ここで大事なのは、「なんとなく直して」ではなく、集めたデータを元に「何が・どこで・なぜ問題なのか」を具体的に伝えることです。
うまくいくプロンプトの3要素
- 現象の説明（何が起きているか）
- データの根拠（何件のレポート・何%の離脱率か）
- 期待する結果（修正後にどうなってほしいか）
// 改善依頼の良い例
ユーザーレビューから、「登録後のオンボーディング画面で何をすべきか分からない」
という意見が過去2週間で8件来ています。
Mixpanel のデータでも、オンボーディング3ステップ目で42%が離脱しています。
オンボーディングフローを改善して、以下を実現したいです:
- 各ステップに進捗インジケーターを追加（全4ステップ中の何ステップ目か表示）
- 3ステップ目に「スキップ」ボタンを追加（強制感を下げる）
- 完了後に「最初にやること3つ」を表示する確認画面を追加
現在の OnboardingScreen.tsx を修正してください。
// 悪い例（曖昧すぎる）
オンボーディングを使いやすくしてください。
違いは明確です。前者は AI が「なぜ変えるのか」「どう変えるのか」を理解した上でコードを生成できます。後者では「使いやすい」の解釈が人によって違うため、望んだ結果が出にくくなります。
レビューの要約をそのまま渡す
先ほどのレビュー要約スクリプトを使うと、AI が作った要約を直接 Rork の改善プロンプトに貼り付けられます。
// Claude による要約:
// 1. ログイン後に白い画面が表示されると複数報告あり（緊急）
// 2. ダークモード対応を求める声が多い（高）
// 3. 読み込み速度の改善要望（中）
// → Rork へのプロンプト:
上記の1番の問題、ログイン後の白い画面について調査してください。
useEffect の実行タイミングや、認証状態が確定する前に画面が描画される
競合状態が原因の可能性があります。LoginScreen と HomeScreen の間の
ナビゲーション処理を確認して修正してください。
週1サイクルの設計——続けるための仕組み
「毎日データを見て改善する」は理想ですが、個人開発ではなかなか続きません。現実的な運用として、週1回・1〜2時間のサイクルが機能しやすいです。
私が実際に回しているサイクルは次のようなものです。
月曜 15分: レビュー要約スクリプトを実行して、今週の改善テーマを1つ決める
火〜木（30〜60分/日）: Rork でその改善を実装します。大きな変更は2〜3日かけて分割する
金曜 30分: 変更をビルド・TestFlight に上げて、週明けに App Store に申請する
このサイクルの良いところは、「今週の改善テーマ」を1つに絞ることで集中力が分散しないことです。データを見ると「あれも直したい、これも」となりがちですが、1つに絞ってしっかり完成させる方が実際には速く前進できます。
App Store Connect の分析ツールを使いこなす方法も参考にしながら、自分なりのダッシュボードを作っておくと、週1サイクルがさらに回しやすくなります。
また、ユーザーレビューへの返信も継続改善の一部です。ユーザーレビューへの返信戦略では、批判的なレビューへの対応方法も含めて説明しています。修正したバージョンをリリースしたら、関連するレビューへ「ご指摘の点を〇〇バージョンで修正しました」と返信するだけで、ユーザーの印象が大きく変わります。
「データがなくても改善できる」という誤解
最後に、個人開発者がよく陥るパターンを一つ。「まだダウンロード数が少ないからデータが取れない」という理由で、分析の仕組みを後回しにしてしまうことです。
でも実際は逆で、ダウンロード数が少ない時期こそデータを丁寧に見る価値があります。最初の100ユーザーは、あなたのアプリに一番敏感に反応してくれる人たちです。彼らがどこで迷い、何に感動し、なぜ離れたのかを理解することが、次の1,000ユーザーへの道を開きます。
Crashlytics と基本的なアナリティクスは最初のリリースに含めておく。レビュー取得スクリプトは週1回のルーティンにします。これだけで、リリース後の改善サイクルの質が大きく変わります。
Rork の AI は「作る」だけでなく「育てる」のにも力を発揮します。まずは今週中に、自分のアプリのレビューを一度 AI に整理してもらうところから始めてみてください。