Rork で『自社ブランドの動画配信アプリ』を一人で立ち上げる実装 — HLS配信・サブスク課金・オフライン視聴・解約後の視聴停止まで

Step 1: 動画配信基盤を選ぶ — Mux・Cloudflare Stream・Bunny Stream の比較

個人開発で選択肢に入るのは、おおむねこの3つです。それぞれ向き不向きがあります。

• Mux: API設計が洗練されていて、React Native SDKもあり、HLSマスタープレイリストの配信とAnalyticsが強力です。視聴時間課金で、視聴数の伸びに比例して課金されるため、初期コストが読みやすいのが特徴です。FairPlay DRMにも対応（Mux Plusプラン）
• Cloudflare Stream: 保存は1,000分あたり月$5（前払い）、配信は1,000分あたり$1の従量課金で、固定の月額プランはありません（Cloudflare公式の料金ページで確認しました）。HLSとDASHが両方出て、署名付きURLの生成もシンプル。個人開発の初動にいちばん向きます。DRMは別途のご相談になります
• Bunny Stream: 帯域料金が安いのが魅力で、月間10TB流すようなスケールでも他の半額程度。DRM（MediaCage）の追加料金が比較的明瞭

私は個人開発のスタート時はCloudflare Streamを推します。単純な価格体系と、サインドURLのコードがシンプルで、Rorkと組み合わせたときに余計な摩擦が起きないからです。ユーザーが増えて月間視聴時間が大きくなってきたらMuxに寄せるパスが現実的です。

動画のアップロードと再生準備

ここでは例としてCloudflare Streamを使います。Rork側からの直接アップロードは大容量で不安定になりやすいので、管理画面は別途（ダッシュボードで管理するか、Remix/Next.jsの簡易管理画面を作る）でアップロードし、アプリは再生に専念します。

アップロード時に取得できる uid が動画ごとのIDになります。サブスクリプション権限と紐づけるマスタテーブルを作り、「どのプランで見られるか」を定義します。

-- videos テーブル
CREATE TABLE videos (
  id TEXT PRIMARY KEY,            -- Cloudflare Stream の uid
  title TEXT NOT NULL,
  description TEXT,
  required_plan TEXT NOT NULL,    -- 'free' | 'pro' | 'premium'
  duration_sec INTEGER,
  thumbnail_url TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Step 2: Rork で HLS プレイヤーを実装する

Rorkに「expo-videoを使ってHLSを再生し、シークバー・再生速度切替・ピクチャーインピクチャー対応のプレイヤーを作って」とプロンプトを投げると、おおむね動く雛形が出てきます。ただしそのままだと、iOSのバックグラウンド再生・音声フォーカス制御・AirPlay対応が抜けていることが多いので、以下のコードをベースに補強します。

// app/components/StreamPlayer.tsx
import { useEvent } from "expo";
import { useVideoPlayer, VideoView } from "expo-video";
import { useEffect, useState } from "react";
import { View, StyleSheet, ActivityIndicator } from "react-native";
 
type Props = {
  videoId: string;
  getSignedUrl: (videoId: string) => Promise<string>;
};
 
export function StreamPlayer({ videoId, getSignedUrl }: Props) {
  const [sourceUrl, setSourceUrl] = useState<string | null>(null);
  const [error, setError] = useState<string | null>(null);
 
  // 視聴権限チェック → 署名付きHLS URL取得
  useEffect(() => {
    let canceled = false;
    (async () => {
      try {
        const url = await getSignedUrl(videoId);
        if (!canceled) setSourceUrl(url);
      } catch (e: any) {
        // 権限エラーはユーザーに原因を明示する(プラン不足 / 未ログイン)
        if (!canceled) setError(e.message ?? "動画を読み込めませんでした");
      }
    })();
    return () => { canceled = true; };
  }, [videoId, getSignedUrl]);
 
  const player = useVideoPlayer(sourceUrl ?? "", (p) => {
    p.loop = false;
    p.allowsExternalPlayback = true; // AirPlay 許可
    p.timeUpdateEventInterval = 1.0; // 再生位置を1秒ごとに購読
  });
 
  // バックグラウンドで音だけ鳴らしたい場合は staysActiveInBackground を有効化
  // （config plugin 側の supportsBackgroundPlayback も必要です）
  // ただしApp Store審査でバックグラウンド音声モードの理由説明が必要になるため
  // 「音声教材アプリ」など正当な用途がある場合のみ有効にすること
  // player.staysActiveInBackground = true;
 
  useEvent(player, "statusChange", { status: player.status });
 
  if (error) {
    return <View style={styles.centered}><ErrorNotice message={error} /></View>;
  }
  if (!sourceUrl) {
    return <View style={styles.centered}><ActivityIndicator size="large" /></View>;
  }
 
  return (
    <VideoView
      style={styles.video}
      player={player}
      allowsFullscreen
      allowsPictureInPicture
      contentFit="contain"
      nativeControls
    />
  );
}
 
const styles = StyleSheet.create({
  video: { width: "100%", aspectRatio: 16 / 9, backgroundColor: "#000" },
  centered: { width: "100%", aspectRatio: 16 / 9, alignItems: "center", justifyContent: "center", backgroundColor: "#111" },
});

このコードのポイントは、useVideoPlayer に URL を直接渡すのではなく、署名付きURLの取得を useEffect 内で非同期に行う点です。こうすることで、Stripeの権限チェックが先に走り、権限がなければ再生URL自体が手元に来ない構造になります。「URLが届いていなければ再生できない」というシンプルな原理に還元できるのが、個人開発での運用で重要です。

Step 3: 署名付きURLの発行と視聴権限チェック

Cloudflare Stream の署名付きURLは、Cloudflare Workers から数行で発行できます。このエンドポイントにStripeのサブスク状態チェックを組み込むのがこの章の主題です。

// workers/api/video-token/route.ts (Cloudflare Workers + Hono 例)
import { Hono } from "hono";
import { getCookie } from "hono/cookie";
import { decode } from "./jwt"; // 自前 JWT 検証
 
type Bindings = {
  STREAM_CUSTOMER_SUBDOMAIN: string;
  STREAM_KEY_ID: string;
  STREAM_SIGNING_JWK: string;      // RS256 用の署名鍵（JWK）。Stream の署名鍵は RSA です
  STRIPE_SECRET: string;
  DB: D1Database;
};
 
const app = new Hono<{ Bindings: Bindings }>();
 
app.post("/video-token/:videoId", async (c) => {
  const videoId = c.req.param("videoId");
  const session = getCookie(c, "session");
  if (!session) return c.json({ error: "unauthorized" }, 401);
 
  // 1) セッションから userId を取り出す
  const user = await decode(session, c.env);
  if (!user) return c.json({ error: "invalid_session" }, 401);
 
  // 2) videos テーブルから必要プランを確認
  const video = await c.env.DB.prepare(
    "SELECT required_plan FROM videos WHERE id = ?"
  ).bind(videoId).first<{ required_plan: string }>();
  if (!video) return c.json({ error: "not_found" }, 404);
 
  // 3) Stripe のサブスク状態を確認(KVキャッシュ付き)
  const plan = await getActivePlan(user.email, c.env);
  if (!canView(plan, video.required_plan)) {
    return c.json({
      error: "upgrade_required",
      currentPlan: plan,
      requiredPlan: video.required_plan,
    }, 403);
  }
 
  // 4) 署名付き JWT を発行(10分有効)
  const token = await signStreamToken(videoId, {
    exp: Math.floor(Date.now() / 1000) + 600, // 10分
    kid: c.env.STREAM_KEY_ID,
    jwk: c.env.STREAM_SIGNING_JWK,
  });
 
  // Cloudflare Stream の HLS マスタープレイリスト URL
  const hlsUrl = `https://${c.env.STREAM_CUSTOMER_SUBDOMAIN}/${token}/manifest/video.m3u8`;
  return c.json({ url: hlsUrl, expiresIn: 600 });
});
 
function canView(active: string | null, required: string) {
  if (required === "free") return true;
  if (!active) return false;
  const rank: Record<string, number> = { pro: 1, premium: 2 };
  return (rank[active] ?? 0) >= (rank[required] ?? 0);
}
 
export default app;

このコードで大事なのは有効期限を短く切ることです。Cloudflare Streamの署名付きURLは、一度発行されるとその有効期限内は誰からでも再生可能になります。解約直後のユーザーが保存していたURLを使い続けられない設計にするには、10分〜30分程度で失効させ、再生中もアプリが定期的にトークンを更新する作りが必要です。

再生中のトークン更新は、timeUpdate イベントで残り有効期限を見張り、2分を切ったら新しいトークンを取って差し替える形にします。ここで気をつけたいのは、player.replace にURLと再生位置の2つを渡すことはできない点です。位置は currentTime で別に戻します。iOSでは replace がUIスレッドで読み込みを行うため、公式ドキュメントが勧める replaceAsync を使います。

import type { VideoPlayer } from "expo-video";
 
// 残り有効期限が2分を切ったら呼びます
async function refreshSource(
  player: VideoPlayer,
  getSignedUrl: () => Promise<string>
) {
  const position = player.currentTime;      // 差し替え前の位置を覚える
  const nextUrl = await getSignedUrl();
  await player.replaceAsync(nextUrl);       // 別スレッドで読み込む
  player.currentTime = position;            // 位置を戻す
  player.play();
}

トークンの形式もここで確かめておきます。Cloudflare Streamでは、署名したトークンが動画IDの代わりにURLへ入り、https://customer-<CODE>.cloudflarestream.com/<TOKEN>/manifest/video.m3u8 の形になります。exp は署名時点から24時間以内にしか設定できません。10分という値は、その上限よりはるかに短く切っているわけです。

Step 4: Stripe サブスクリプションと視聴権限の状態同期

ここがこの記事の核です。「解約したユーザーが、翌日から再生できなくなる」この一点を確実にするには、Stripe Webhook → KV/DB 更新のパイプラインを信頼できる状態にする必要があります。

// workers/api/stripe-webhook/route.ts
import { Hono } from "hono";
import Stripe from "stripe";
 
const app = new Hono<{ Bindings: Bindings }>();
 
app.post("/stripe/webhook", async (c) => {
  const sig = c.req.header("stripe-signature")!;
  const body = await c.req.text();
  // apiVersion は SDK の既定に任せます。固定する場合は、Dashboard に表示される
  // 「2025-xx-xx.basil」のような日付＋コードネームの名称をそのまま使います
  const stripe = new Stripe(c.env.STRIPE_SECRET);
 
  let event: Stripe.Event;
  try {
    event = await stripe.webhooks.constructEventAsync(
      body, sig, c.env.STRIPE_WEBHOOK_SECRET,
      undefined, Stripe.createSubtleCryptoProvider()
    );
  } catch (e) {
    return c.json({ error: "signature_failed" }, 400);
  }
 
  switch (event.type) {
    case "checkout.session.completed":
    case "customer.subscription.updated": {
      const sub = event.data.object as Stripe.Subscription | Stripe.Checkout.Session;
      await upsertSubscription(sub, c.env);
      break;
    }
    case "customer.subscription.deleted": {
      // 解約 → KV からエントリ削除
      const sub = event.data.object as Stripe.Subscription;
      const email = await resolveEmail(sub, c.env);
      await c.env.KV.delete(`plan:${email}`);
      break;
    }
    case "invoice.payment_failed": {
      // 支払い失敗 → 3日以内に更新されなければ解約扱いにする運用
      await markPaymentFailed(event, c.env);
      break;
    }
  }
  return c.json({ received: true });
});

なぜ Webhook を信頼するのかという点は必ず明文化しておいた方がいいです。Stripe API をアプリ側から毎回呼ぶのは、レイテンシーと料金の両面で割に合いません。Webhook でKVに書き、KVを権限チェックの一次情報として扱う — このパターンが最も現実的です。

ただし、Webhook は配信失敗・順序逆転が起きます。対策は2つ：

1. リトライを前提にした冪等設計: 同じevent.idが二度届いても結果が変わらないよう、INSERT OR REPLACE を使います
2. 状態逆転の防止: customer.subscription.updated より後に古い状態のイベントが届くことがあります。current_period_end のタイムスタンプで比較し、新しい情報だけを反映します

この2点を入れておかないと、運用を始めて2週間くらいで「解約したはずなのに再生できる」「課金したのに再生できない」のどちらかが必ず起きます。

課金経路の整理 — Stripe だけで App Store に出せるのか

Step 4 は Stripe を権限の源にしていますが、ここに見落とすと審査で止まる点がひとつあります。

App Store Review Guidelines の 3.1.1 は、サブスクリプションやプレミアムコンテンツへのアクセスをアプリ内で解錠する場合、アプリ内課金（In-App Purchase）を使うよう定めています。独自の仕組みで解錠することは認められていません。一方、3.1.3(b) のマルチプラットフォームサービスは、他のプラットフォームやWebで購入した内容へアプリからアクセスさせることを認めていますが、その商品がアプリ内課金としてもアプリ内で買えることを条件に挙げています（App Store Review Guidelines の原文で確認しました）。

私の読みでは、「Webで Stripe 契約 → アプリはログインして視聴するだけ」という構成を成り立たせるには、同じ商品をアプリ内課金でも買えるようにしておく必要があります。国や地域による例外は変わりうるため、提出時点の最新ガイドラインで確かめていただくのが確実です。この点は、作り始めてから気づくと手戻りがいちばん大きくなるのかもしれません。

実装の側でできる備えは、権限の置き場所を経路から切り離しておくことです。KV の plan:{userId} という一つの形式に、Stripe の Webhook と Apple の通知の両方が書き込む——そうしておけば、審査の結果で課金経路が変わっても、署名付きURLを出すエンドポイント（Step 3）は一行も変えずに済みます。

Step 5: オフライン視聴の実装と暗号化

オフライン視聴は、画面のない地下鉄やフライト中に視聴してもらうための重要な機能です。ただし、素のmp4をデバイス内に保存するのはやってはいけません。ダウンロードされた動画ファイルをユーザーがFilesアプリ経由で抜き出し、第三者に渡してしまう可能性があります。

現実的なアプローチは次の3択です。

• DRM不要の軽量アプローチ: AES-128 で暗号化した HLS セグメントをダウンロードし、アプリ内の暗号化ストレージに保存します。復号鍵は毎回バックエンドから取得。プロでないユーザーを想定した通常用途はこれで十分
• FairPlay Streaming (FPS): Apple の本格DRM。配信会社（Mux Plus など）と契約し、Apple Developer Programから FPS Deployment Package を取得する必要があります。審査が複雑
• ダウンロード機能そのものを提供しない: 意外ですが、初期リリースではこれが最適解のことも多いです。リソースを本編のコンテンツ制作に回せます

私が個人開発で推すのは、最初はオフライン機能なしで出して、プレミアムプラン加入率が見えてきたらAES-128の軽量暗号化を足すという順序です。初期から FairPlay を組み込むとリリースが3ヶ月遅れます。

AES-128 の軽量実装パターンは次のような形になります。

// app/lib/offline.ts
import * as FileSystem from "expo-file-system";
import * as Crypto from "expo-crypto";
 
export async function downloadEncryptedVideo(
  videoId: string,
  getDownloadManifest: (id: string) => Promise<{ segments: string[]; key: string }>
) {
  const { segments, key } = await getDownloadManifest(videoId);
  const dir = `${FileSystem.documentDirectory}offline/${videoId}/`;
  await FileSystem.makeDirectoryAsync(dir, { intermediates: true });
 
  // 復号キーはアプリ内のセキュアストレージ(iOS Keychain / Android Keystore)に保存
  await saveKeyToSecureStore(`key:${videoId}`, key);
 
  for (const [index, segmentUrl] of segments.entries()) {
    const path = `${dir}seg_${String(index).padStart(5, "0")}.ts`;
    await FileSystem.downloadAsync(segmentUrl, path);
  }
  return dir;
}
 
async function saveKeyToSecureStore(name: string, key: string) {
  // expo-secure-store で AES キーをデバイスのセキュア領域に保存
  // 絶対に AsyncStorage に置かないこと — ルート化端末で抜ける
}

なお、このコードは骨格です。セグメントを保存しただけでは再生できません。端末内で読めるプレイリスト（.m3u8）を組み立て直し、#EXT-X-KEY の鍵URIを手元の配信先へ向け直す工程が別に要ります。

ここで重要なのが復号鍵の保存場所です。AsyncStorage に置いてはいけません。必ず expo-secure-store（iOS Keychain / Android Keystore）を使います。さらに、解約されたユーザーがアプリを再開したときには SecureStore からキーごと削除し、オフラインファイルも再生できないようにします。

Step 6: DRM が必要なケースと回避するケースの判断基準

「DRMを入れるべきか」はよく迷いますが、判断軸はシンプルに2つです。

• ストリーミング配信だけ（オフライン不可）: 署名付きURL＋短い有効期限で十分。DRMなしで構築可能
• オフライン視聴あり: AES-128 軽量暗号化 or FairPlay DRM が必要

さらに、次の条件に一つでも当てはまるなら FairPlay 導入を真剣に検討してください。

• コンテンツ制作者から「他の配信プラットフォームと同等の保護」を明示的に求められているとき
• 月商100万円以上の配信ビジネスに育ち、コンテンツ流出が事業損失に直結するとき
• 企業研修・医療系など、契約上「保護された配信」を要求されるとき

逆に、自主制作のフィットネス動画や料理レシピ動画など、「漏洩しても致命傷にはならない」コンテンツなら、DRMの実装コストに見合いません。

Step 7: よくある落とし穴 — 初期リリースで詰まりやすい3つ

動画配信アプリで個人開発者が必ず詰まるポイントを、先に共有しておきます。

落とし穴 1: バックグラウンド再生モードの審査

Info.plistの UIBackgroundModes に audio を追加すると、ロック画面でも音声が鳴り続けるようになります。しかしこれを入れると、App Store審査で「なぜこの機能が必要か」を必ず聞かれます。教育系・オーディオブック系なら通りますが、理由が曖昧だとリジェクトされます。初期リリースではバックグラウンド再生を入れず、必要になってから機能追加する順序が安全です。

落とし穴 2: AirPlay/Chromecast 使用時の権限バイパス

AirPlayで再生中のコンテンツは、署名付きURLがAppleTVに転送されるため、URLが露出します。サブスク解約直後でもAppleTV側のキャッシュで再生が続く可能性があります。対策は署名URLの有効期限を短く保つこと（10分以内）と、ホスト側で再生セッションを追跡してバックエンドから強制停止する仕組み（長時間の視聴では再トークン取得を必須にする）を用意することです。

落とし穴 3: 「解約後3日経っても再生できる」問題

もっとも起きやすい事故は、Webhookが配信失敗したまま気づかないケースです。Stripe Dashboardの「Events」→「Failed」を監視する仕組みを、リリース前に必ず入れておきます。Cloudflare Workersで月に1回、Stripe Subscriptions APIを叩いてKV状態と突合する夜間ジョブを走らせておくと、Webhookが落ちていても遅くて翌月には気づけます。

運用コストと収支設計 — 具体的な数字

最後に、月額コストの試算をお伝えします。実測値ではなく、月間ユニークユーザー1,000人・平均視聴時間20分・保存ライブラリ1,000分以内という仮定を置いた計算です。

• Cloudflare Stream: 配信 20,000分 × $1／1,000分 = $20、保存（1,000分まで）$5 で 約$25
• Cloudflare Workers: 無料枠内（10万req/日）で収まる = $0
• Stripe手数料: 国内カードは決済成功1回あたり3.6%で、固定額の上乗せはありません（Stripe公式の料金ページで確認しました）。月商10万円なら 約¥3,600
• Apple 手数料: 15%（Small Business Program適用時）。月商10万円なら ¥15,000。Stripeと両方を差し引いているのは、課金経路が決まる前の安全側の見積もりだからです。実際には前の節で整理した通り、経路ごとにどちらが掛かるかが変わります

月商10万円なら、両方を差し引いた安全側の試算で手取りは約77,000円です。スケールに応じてMux等へ移行すると効率が上がります。

リリース前に必ず手作業で確認しておきたい5つのシナリオ

課金機能を含むアプリは、壊れていると信頼を一気に失います。自動テストで全て網羅するのは難しいので、リリース前に手作業で次の5シナリオを走らせておくと安心です。

1. 新規契約直後の再生: Stripe テストモードで契約し、Webhookが飛び、KVが書き込まれ、/video-token が成功する、ここまでが10秒以内に完了することを確認します。ここに時間がかかるとUX評価が下がります
2. 即時解約の反映: cancel_at_period_end=false で即時解約し、次の /video-token が 403 を返すことを確認します。cancel_at_period_end=true の場合は current_period_end まで再生可能で、その後停止することも確認します
3. 支払い失敗時の猶予期間: 更新時に card_declined になるテストカードで、3日間は視聴可能・4日目から停止、という運用が意図通り動くことを確認します
4. ダウングレード時の権限反映: Premium → Pro へのダウングレード直後に、プレミアム限定動画が 403 になり、Pro 対象動画は再生できることを確認します
5. 無料トライアルの自動終了: 7日間のトライアル終了時、未決済のまま期限を迎えたら再生権限が即時に失われることを確認します

この5つが通れば、課金の中核は信頼して運用できる状態です。UIのバグや計測の抜けは、後から直しても顧客の信頼を損ねません。

事業として計測すべき3つの指標 — MRRよりも先に見るべき数字

個人開発者はMRR（月次経常収益）を見がちですが、動画サブスク事業では翌月以降の収益を予測する指標のほうが意思決定に役立ちます。重要な3指標を紹介します。

なお、ここに出てくる数値（40%・60%・45分・10分・40%）は業界の統計ではなく、私が仮置きしている目安です。ご自身のコホートで必ず検証してください。

7日間のアクティベーション率: トライアル登録者のうち7日以内に1本以上の動画を完視聴した人の割合です。40%未満だとトライアル→有料転換率が弱く、60%超ならプロダクト自体は成立しています。その場合の課題は成長（新規獲得）であって製品ではない、という判断が早期にできます。

有料会員の月間視聴分数: 月45分以上視聴している人は、90日以内の解約率が大きく下がります。10分未満の人は60日以内に解約する確率が高いです。コホート別にこの数字を追うと、改善の優先順位が見えます。

1ユーザーあたりのライブラリ広さ: 月に何本の異なる動画を見たかです。月1本の人は価格改定時に離脱しやすく、月5本以上の人は最大40%程度の値上げにも耐えます。ライブラリの「深さ」を作ることが長期LTVに直結します。

この3つは MRR より先行してチャーンを予測するので、ダッシュボードの一等地に置く価値があります。

コンテンツ運用 — 技術的な実装より重要な部分

HLS・Stripe・DRMの実装は、動画配信ビジネスの全体作業の30%程度です。残り70%はコンテンツを制作・アップロード・タイトル付け・サムネイル作成・公開する繰り返しの運用そのものです。ここを軽視するとリリース後に息切れします。

リリース前に決めておきたい運用方針が3つあります。

公開ペース: 12ヶ月続けても燃え尽きないペースを選びます。個人運営だと週1本がスイートスポットです。週2〜3本はフルタイムのクリエイター向けで、副業では3ヶ月目に続かなくなるケースが多いです。

サムネイル・タイトル作成のワークフロー: 動画1本につきFigmaのテンプレートで30分以内に仕上げる、という時間制限をつけます。自社アプリ内でもサムネイルの手抜きは発見率を大きく下げます。

古い動画の扱い: 全てを永久保存すると、ストレージコストとライブラリの見通しの悪化を招きます。50本を超えたあたりから「おすすめ」「最新」「アーカイブ」のセクションを分け、全て時系列で並べるのをやめる運用にシフトすると快適です。

全体を振り返って — 次の一歩

ここまで実装を進められる段階まで来たなら、最初に取り組むのは最小構成での公開です。DRMもオフライン機能も後回しで、署名付きURL + Stripeサブスクの組み合わせだけでベータ版を出し、実際のユーザーの反応を見ましょう。「どの動画が見られているか」「どこで解約されているか」が見えたタイミングで、機能を足していくほうが、順番として効率的です。

次にやることは一つだけです。Stripeのテストモードで「契約 → 即時解約 → 403」の一周を、今夜のうちに通していただければ幸いです。

権限の真実は一か所に置き、ほかはすべてその写しとして扱う——この線引きさえ守れていれば、機能は後から足せるのだと、いまも感じています。

課金の流れは Rork × Stripe サブスクリプション収益化ガイド に、Apple側の通知の受け方は App Store Server Notifications V2 の自前受信 にまとめています。

関連記事として、Rork × Stripe サブスク収益化ガイド には課金フロー全般の詳細を、Rork × Cloudflare R2 ファイルストレージガイド には動画のバックアップ用途での使い方を書いています。