RORK LABEN
TOOLING — Rorkの開発者向けリポジトリが動き続けています。rork-xcodeが7月16日、rork-deviceが7月15日、rork-plistが7月13日に更新されましたOPUS46 — RorkでClaude Opus 4.6が稼働しています。Rork MaxはClaude Codeを土台にアプリを組み立てる設計ですSIM — ブラウザ上で動くクラウドのiOSシミュレータを備え、実機へのインストールは1クリック、App Storeへの提出は2クリックと案内されていますMAX — Rork MaxはReact Nativeではなく純粋なSwiftを出力します。iPhone・iPad・Apple Watch・Apple TV・Vision Pro、そしてiMessageまでが射程ですNATIVE — HealthKit、ARKitとLiDAR、NFC、Dynamic Island、Live Activities、Metalによる3D、Core MLのオンデバイス推論まで扱えますSEED — RorkはLeft Lane Capitalが主導する1,500万ドルのシードラウンドを実施し、Peak XVとa16z Speedrunが参加しましたTOOLING — Rorkの開発者向けリポジトリが動き続けています。rork-xcodeが7月16日、rork-deviceが7月15日、rork-plistが7月13日に更新されましたOPUS46 — RorkでClaude Opus 4.6が稼働しています。Rork MaxはClaude Codeを土台にアプリを組み立てる設計ですSIM — ブラウザ上で動くクラウドのiOSシミュレータを備え、実機へのインストールは1クリック、App Storeへの提出は2クリックと案内されていますMAX — Rork MaxはReact Nativeではなく純粋なSwiftを出力します。iPhone・iPad・Apple Watch・Apple TV・Vision Pro、そしてiMessageまでが射程ですNATIVE — HealthKit、ARKitとLiDAR、NFC、Dynamic Island、Live Activities、Metalによる3D、Core MLのオンデバイス推論まで扱えますSEED — RorkはLeft Lane Capitalが主導する1,500万ドルのシードラウンドを実施し、Peak XVとa16z Speedrunが参加しました
記事一覧/開発ツール
開発ツール/2026-05-30上級

OTAアップデートを段階配信する仕組みを、壊さずに育てる

EAS Updateで全ユーザーに即時配信するのは危険です。チャンネル設計・段階的ロールアウト・自動ロールバックまで、累計5,000万DLの運用で固まった配信アーキテクチャを実装コード付きで共有します。

EAS Update6OTA6段階的ロールアウトReact Native209Expo149ロールバック2

プレミアム記事

OTA(無線)アップデートで一番怖いのは、配信ボタンを押した瞬間に全ユーザーの端末が新バンドルを取りに行く、という挙動です。私が累計5,000万ダウンロードのアプリ群を運用していて、もっとも肝を冷やしたのも、まさにこの「即時・全量配信」で壊れたJavaScriptバンドルが数万台に同時に届いてしまった夜でした。アプリはストア審査を通さずに直せるのがOTAの利点ですが、裏を返せば、壊れたものも審査を通さずに一瞬で広がります。

EAS Update(Expoの無線更新基盤)はとても優秀ですが、デフォルトの使い方は「ブランチにpublishしたら、そのチャンネルを見ている端末が次回起動時に取得する」というシンプルなものです。これは小規模なうちは十分でも、ユーザー数が増えると「いきなり全員」がリスクそのものになります。即時全量配信を、5%→25%→100%の段階配信に作り替え、さらに壊れたバンドルを掴んだ端末を自動で前バージョンへ戻すところまでを、実際に運用しているコードと数値で共有します。

なぜ「チャンネル=環境」「ブランチ=中身」で分けるのか

EAS Updateには channel(チャンネル)と branch(ブランチ)という二つの概念があり、ここの設計を最初に間違えると後で必ず破綻します。私の整理はシンプルで、**channel はビルドに焼き込む「環境ラベル」、branch は実際に配信する「コードの中身」**です。ビルド(ネイティブバイナリ)は channel を見にいき、channel は任意の branch に向け替えられます。この間接参照こそが段階配信とロールバックの土台になります。

// eas.json — production を一段の channel ではなく、配信レーンとして設計する
{
  "cli": { "version": ">= 12.0.0" },
  "build": {
    "production": {
      "channel": "production",
      "autoIncrement": true
    },
    "production-canary": {
      "extends": "production",
      "channel": "production-canary"
    }
  },
  "submit": { "production": {} }
}

ポイントは、本番ビルドに production チャンネルを焼き込みつつ、配信時には production チャンネルを production-v1.4.0 のようなバージョン付きブランチに向けることです。こうしておくと、巻き戻したいときに「チャンネルの向き先を前のブランチに戻す」だけで全端末が次回起動時に旧バンドルへ戻ります。新しいバンドルを再publishして上書きするのではなく、向き先を変える——これが事故対応の速度を決めます。

段階配信の手順(そのまま回せるチェックリスト)

段階配信は、頭の中だけで運用すると必ずどこかで「今何%だったか」を見失います。私は次の手順をスクリプトとチェックリストに固定し、迷いをなくしました。

  1. 新バンドルを誰にも見せないバージョン付きブランチに publish する。
  2. production チャンネルを、そのブランチへ 5% だけ向ける。
  3. 配信から6時間、新旧のクラッシュ率差を最優先で監視する。
  4. 24時間経過時点で adoption 率を確認し、条件を満たせば 25% へ昇格する。
  5. 25% を 48時間維持して問題なければ 100% へ昇格する。
  6. 100% 到達後も 24時間は監視を緩めない。
#!/usr/bin/env bash
# scripts/staged-publish.sh — 段階配信を1コマンドに畳む
set -euo pipefail
 
BRANCH="production-$(date +%Y%m%d-%H%M)"
MESSAGE="${1:?commit message required}"
 
# 1. 新ブランチに publish(まだ誰にも見せない)
eas update --branch "$BRANCH" --message "$MESSAGE" --non-interactive
 
# 2. production チャンネルで 5% だけ新ブランチに向ける
eas channel:edit production \
  --branch "$BRANCH" \
  --rollout-percentage 5 \
  --non-interactive
 
echo "✅ $BRANCH を 5% に配信しました。"
echo "   24時間後に scripts/promote.sh $BRANCH 25 を実行してください。"
#!/usr/bin/env bash
# scripts/promote.sh — 様子を見て昇格する。引数で % を指定
set -euo pipefail
BRANCH="${1:?branch required}"
PCT="${2:?percentage required}"
 
eas channel:edit production \
  --branch "$BRANCH" \
  --rollout-percentage "$PCT" \
  --non-interactive
 
echo "✅ $BRANCH を ${PCT}% に昇格しました。"

私が昇格の前に必ず見る数字は二つです。ひとつはadoption率(その新バンドルを実際に取得・適用した端末の割合)。配信から24時間で、ロールアウト対象の70%以上が新バンドルを掴んでいなければ、配信経路かバンドルサイズに問題があると見ます。もうひとつは新旧のクラッシュ率の差で、新バンドル側のクラッシュ率が旧バンドルより20%以上悪化していたら昇格しません。5,000万DL規模だと5%でも数十万台あり、統計的に十分な母数が24時間で揃うため、この粒度で判断できます。

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

この記事の続きを読む

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

この記事で得られること
eas.jsonとチャンネル/ブランチを分けた段階配信の最小構成(5%→25%→100%)を、そのまま使えるコードで示します
壊れたバンドルを掴んだ端末を自動で前バージョンへ戻す、起動時ヘルスチェック+ロールバックの実装手順
配信後24〜72時間のadoption率とクラッシュ率をどの閾値で監視し、いつ昇格・いつ巻き戻すかの具体的な判断基準
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

または
メンバーシップなら全記事が読み放題 →
シェア

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

Rork Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

開発ツール2026-06-24
EAS Update を入れたのに『直したはずのバグ』が消えないとき — OTA が静かに届かない原因と運用メモ
EAS Update を導入しても OTA が一部のユーザーに届かないことがあります。runtimeVersion のドリフト、配信したのに採用されない更新、安全なロールバックの選び方を、Rork アプリの運用で実際に効いた計装とともに整理します。
開発ツール2026-06-28
EAS Update を少人数から配り、クラッシュ率で自動的に止める
OTA 更新は一瞬で全員に届くからこそ、悪い更新も一瞬で全員に届きます。EAS Update を少人数(カナリア)から配り、クラッシュ率を見て広げるか止めるかを自動で判断し、最後は端末側で安全網を張る設計を、動くコードでまとめます。
開発ツール2026-05-01
Rork で EAS Update を配信したのに反映されない — 原因を切り分ける5つの典型パターン
Rork で EAS Update を publish したのにアプリ側に反映されない、というのは慣れていてもうっかり詰まるトラブルです。よくある5つの原因と、ターミナルで5分以内に切り分ける手順を実例ベースで紹介します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →