AI チャット機能を Rork アプリに実装するとき、最初に躓くのはレスポンスが一括で返ってくるからです。ユーザーが「送信」ボタンを押してから 10 秒間ローディングスピナーが回り、突然全文が表示される—これでは ChatGPT の体験とは程遠い。
LLM ストリーミング（SSE: Server-Sent Events）は、この問題を根本から解決します。トークンが生成されるたびにリアルタイムでテキストが流れてくる体験を、ユーザーは「生きている AI」として感じる。React Native でこれを実装しようとすると、ブラウザとは異なる壁にすぐ直面します。EventSource は動かありません。fetch() のストリーム読み取りは特殊な API が必要です。AbortController との組み合わせも癖があります。
ここで扱うのはRork で AI チャットアプリを作る開発者が実際に詰まるポイントを全て潰し、本番で動く実装コードを提供します。
なぜ LLM ストリーミングが UX の分水嶺になるのか
LLM API には 2 つの呼び出し方があります。一括レスポンス（blocking） と ストリーミング（streaming） です。
一括レスポンスは単純です。リクエストを投げ、モデルが全文生成を終えてから JSON が返ってくる。実装は簡単だが、Claude Sonnet のような大型モデルは長い回答を生成するとき 15〜20 秒かかることもあります。この待ち時間にユーザーの 40% 以上が離脱するというデータがある（個人開発でのチャーン計測では特に顕著）。
ストリーミングは、LLM がトークンを生成するたびにその断片を逐次送信します。ユーザーには数百ミリ秒後から文字が流れ始め、全体の生成時間が同じでも「速い」と感じる。これは単なる体感の話ではなく、エンゲージメント指標に直結します。
React Native でのもう一つの利点はコスト可視化です。ストリーミングを途中でキャンセルすれば、生成済みトークン分しか課金されない（Anthropic、OpenAI ともに途中キャンセル対応）。長い回答が不要なケースで「停止」ボタンを提供することで、API コストを 30〜50% 削減できる実績があります。
React Native で SSE を扱う際の根本的な違い
Web ブラウザでは EventSource API を使って SSE を受信できます。しかし React Native では EventSource は存在しない。これを知らずに new EventSource(url) を書いてビルドが通り、実機で真っ白になるパターンは定番の落とし穴です。
React Native でストリーミングを実現する正しいアプローチは fetch() API の ReadableStream インターフェースを使うことです。Expo SDK 49 以降、React Native の fetch は response.body から ReadableStream を取得できるようになっています。
// ❌ ブラウザでは動くが RN では動かない
const es = new EventSource('https://api.anthropic.com/v1/messages');
// ✅ RN / Expo で正しいアプローチ
const response = await fetch('https://api.anthropic.com/v1/messages', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'anthropic-version': '2023-06-01',
'x-api-key': 'YOUR_ANTHROPIC_API_KEY', // 本番ではプロキシ経由で渡す（後述）
},
body: JSON.stringify({ stream: true, ...params }),
});
// response.body は ReadableStream
const reader = response.body?.getReader();
const decoder = new TextDecoder();
while (true) {
const { done, value } = await reader.read();
if (done) break;
const chunk = decoder.decode(value, { stream: true });
// chunk を解析して UI を更新
}
Expo SDK 48 以前のプロジェクトでは response.body が null になります。その場合は react-native-fetch-api ライブラリか、Expo SDK のアップグレードが必要です。Rork が生成するプロジェクトは基本的に最新 Expo SDK を使うので、この問題は新規プロジェクトでは発生しません。
SSE フォーマットの解析
Anthropic の streaming API は以下の形式でチャンクを送信します。
event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"こんにちは"}}
event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"、今日は"}}
一つの read() 呼び出しで複数の SSE イベントが含まれることがあります。また、一つのイベントが複数の read() に跨がって届くこともあります。これを正しく処理しないと、JSON parse エラーが散発的に発生します。
OpenAI の streaming 形式は少し異なります。
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"delta":{"content":"こんにちは"},"index":0}]}
data: [DONE]
それぞれのパーサーを個別に書くより、抽象化レイヤーを設けることを強く推奨する（後述）。
本番で動く完全な streaming フック実装
以下は実際の Rork プロジェクトで使っている useStreamingChat フックの完全版です。AbortController によるキャンセル、エラーリトライ、ステータス管理を含む。
// hooks/useStreamingChat.ts
import { useState, useRef, useCallback } from 'react';
type Message = {
role: 'user' | 'assistant';
content: string;
};
type StreamingState = {
messages: Message[];
isStreaming: boolean;
error: string | null;
sendMessage: (text: string) => Promise<void>;
stopStreaming: () => void;
resetConversation: () => void;
};
// Cloudflare Workers プロキシ経由で呼ぶ（API キーをアプリに埋め込まない）
const PROXY_URL = 'https://your-worker.your-subdomain.workers.dev/api/chat';
export function useStreamingChat(): StreamingState {
const [messages, setMessages] = useState<Message[]>([]);
const [isStreaming, setIsStreaming] = useState(false);
const [error, setError] = useState<string | null>(null);
const abortControllerRef = useRef<AbortController | null>(null);
const stopStreaming = useCallback(() => {
if (abortControllerRef.current) {
abortControllerRef.current.abort();
abortControllerRef.current = null;
}
setIsStreaming(false);
}, []);
const sendMessage = useCallback(async (text: string) => {
if (isStreaming) return; // 多重送信防止
const userMessage: Message = { role: 'user', content: text };
const updatedMessages = [...messages, userMessage];
setMessages(updatedMessages);
setIsStreaming(true);
setError(null);
// 新しい AbortController を作成
const abortController = new AbortController();
abortControllerRef.current = abortController;
// AI 応答のプレースホルダーを追加
const assistantPlaceholder: Message = { role: 'assistant', content: '' };
setMessages([...updatedMessages, assistantPlaceholder]);
let retryCount = 0;
const maxRetries = 2;
const attemptFetch = async (): Promise<void> => {
try {
const response = await fetch(PROXY_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
messages: updatedMessages,
stream: true,
}),
signal: abortController.signal,
});
if (\!response.ok) {
const errorText = await response.text();
throw new Error(`HTTP ${response.status}: ${errorText}`);
}
const reader = response.body?.getReader();
if (\!reader) throw new Error('ReadableStream not supported');
const decoder = new TextDecoder();
let buffer = ''; // チャンク境界をまたぐデータの一時保持
let accumulatedText = '';
while (true) {
// AbortController でキャンセルされたら例外がスローされる
const { done, value } = await reader.read();
if (done) break;
buffer += decoder.decode(value, { stream: true });
// SSE は \n\n でイベントを区切る
const events = buffer.split('\n\n');
buffer = events.pop() ?? ''; // 最後の不完全なイベントをバッファに残す
for (const event of events) {
const lines = event.split('\n');
for (const line of lines) {
if (\!line.startsWith('data: ')) continue;
const data = line.slice(6); // "data: " の6文字を除去
if (data === '[DONE]') continue; // OpenAI 終了マーカー
try {
const parsed = JSON.parse(data);
// Anthropic 形式のデルタテキスト取得
const deltaText = parsed.delta?.text
// OpenAI 形式のデルタテキスト取得
?? parsed.choices?.[0]?.delta?.content
?? '';
if (deltaText) {
accumulatedText += deltaText;
// React の batching を活用して頻繁な setState を抑制
setMessages(prev => {
const next = [...prev];
next[next.length - 1] = {
role: 'assistant',
content: accumulatedText,
};
return next;
});
}
} catch {
// 個々のチャンクで JSON parse エラーが出ることがある（無視して継続）
}
}
}
}
} catch (err: unknown) {
if (err instanceof Error && err.name === 'AbortError') {
// ユーザーによる意図的な停止 — エラーではない
return;
}
// ネットワークエラーは指数バックオフでリトライ
if (retryCount < maxRetries) {
retryCount++;
console.warn(`ストリーミングエラー（リトライ ${retryCount}/${maxRetries}）:`, err);
await new Promise(resolve => setTimeout(resolve, 1000 * retryCount));
return attemptFetch();
}
const message = err instanceof Error ? err.message : 'Unknown error';
setError(`接続エラー: ${message}`);
// エラー時はプレースホルダーを除去
setMessages(prev => prev.slice(0, -1));
} finally {
setIsStreaming(false);
abortControllerRef.current = null;
}
};
await attemptFetch();
}, [messages, isStreaming]);
const resetConversation = useCallback(() => {
stopStreaming();
setMessages([]);
setError(null);
}, [stopStreaming]);
return { messages, isStreaming, error, sendMessage, stopStreaming, resetConversation };
}
このフックの設計で意識したポイントがいくつかあります。
buffer による境界処理: React Native の fetch は TCP パケット境界でチャンクが届く。一つの SSE イベントが 2 回の read() に跨がることがあります。buffer でデータを蓄積し、\n\n で区切ってから解析します。これを省略すると、本番で間欠的に JSON parse エラーが発生します。
setMessages の関数形式: setMessages(prev => [...]) を使うことで、クロージャが古い messages を参照する問題を防ぎます。ストリーミング中に他のメッセージが追加された場合でも安全に動作します。
リトライロジック: ネットワーク切断は特にモバイルで頻繁に起きる。1〜2 回のリトライを指数バックオフで実施することで、体験を大きく改善できます。ただし AbortError はリトライしない（ユーザーが意図して停止した）。
UI 実装 — 「停止」ボタンとカーソルアニメーション
フックができたら UI に接続します。ポイントは ストリーミング中は入力を無効化し、停止ボタンだけを表示することです。
// components/ChatUI.tsx
import { useState, useEffect } from 'react';
import { View, TextInput, Pressable, Text, FlatList, AppState } from 'react-native';
import { useStreamingChat } from '../hooks/useStreamingChat';
export function ChatUI() {
const { messages, isStreaming, error, sendMessage, stopStreaming } = useStreamingChat();
const [input, setInput] = useState('');
// バックグラウンド移行時にストリーミングを停止（iOSのネットワーク切断対策）
useEffect(() => {
const subscription = AppState.addEventListener('change', (nextState) => {
if (nextState === 'background' && isStreaming) {
stopStreaming();
}
});
return () => subscription.remove();
}, [isStreaming, stopStreaming]);
// コンポーネントアンマウント時にストリーミングを停止（メモリリーク防止）
useEffect(() => {
return () => { stopStreaming(); };
}, [stopStreaming]);
const handleSend = async () => {
if (\!input.trim() || isStreaming) return;
const text = input;
setInput('');
await sendMessage(text);
};
return (
<View style={{ flex: 1 }}>
<FlatList
data={messages}
keyExtractor={(_, i) => String(i)}
maintainVisibleContentPosition={{ minIndexForVisible: 0 }}
renderItem={({ item, index }) => {
const isLastAssistant =
item.role === 'assistant' && index === messages.length - 1;
return (
<View style={{
alignSelf: item.role === 'user' ? 'flex-end' : 'flex-start',
backgroundColor: item.role === 'user' ? '#007AFF' : '#F2F2F7',
padding: 12,
borderRadius: 16,
margin: 4,
maxWidth: '80%',
}}>
<Text style={{ color: item.role === 'user' ? '#fff' : '#000' }}>
{item.content}
{/* ストリーミング中のブロックカーソル */}
{isStreaming && isLastAssistant ? '▋' : ''}
</Text>
</View>
);
}}
/>
{error && (
<Text style={{ color: '#FF3B30', padding: 8, textAlign: 'center' }}>
{error}
</Text>
)}
<View style={{ flexDirection: 'row', padding: 8, gap: 8 }}>
<TextInput
value={input}
onChangeText={setInput}
placeholder="メッセージを入力..."
style={{
flex: 1,
borderWidth: 1,
borderColor: '#C7C7CC',
borderRadius: 20,
paddingHorizontal: 16,
paddingVertical: 8,
}}
editable={\!isStreaming}
onSubmitEditing={handleSend}
returnKeyType="send"
/>
{isStreaming ? (
<Pressable
onPress={stopStreaming}
style={{ justifyContent: 'center', padding: 8 }}
>
<Text style={{ fontSize: 24 }}>⏹</Text>
</Pressable>
) : (
<Pressable
onPress={handleSend}
style={{
backgroundColor: '#007AFF',
borderRadius: 20,
paddingHorizontal: 16,
justifyContent: 'center',
opacity: \!input.trim() ? 0.5 : 1,
}}
disabled={\!input.trim()}
>
<Text style={{ color: '#fff', fontWeight: '600' }}>送信</Text>
</Pressable>
)}
</View>
</View>
);
}
▋（ブロックカーソル）は小さなディテールだが、「AI が今考えている」という視覚的フィードバックとして効果的です。ストリーミングが完了すると自動的に消える。
Cloudflare Workers プロキシ — API キーをアプリに入れない設計
ここが多くの個人開発者が見落とすセキュリティの核心です。process.env.ANTHROPIC_API_KEY を Rork アプリのコードに書いても、ビルド済みバイナリから抽出可能です。App Store に公開したアプリで API キーが漏洩すると、知らない間に多額の請求が発生します。
解決策は Cloudflare Workers をプロキシとして使うことです。Workers はエッジで動き、シークレットを安全に保持できます。Rork は Cloudflare Workers との親和性が高く、この組み合わせは定番のアーキテクチャになっている（Hono × Cloudflare Workers REST API ガイドも参照）。
以下は streaming をパススルーする Workers の実装です。
// worker/src/index.ts（Hono を使用）
import { Hono } from 'hono';
import { cors } from 'hono/cors';
type Env = {
ANTHROPIC_API_KEY: string;
};
const app = new Hono<{ Bindings: Env }>();
app.use('/api/*', cors({
origin: ['*'], // 本番では特定のドメインに限定する
}));
app.post('/api/chat', async (c) => {
const body = await c.req.json();
const { messages, stream = true } = body;
// 入力バリデーション（攻撃者がコストを無限に増やすことを防ぐ）
if (\!Array.isArray(messages) || messages.length === 0) {
return c.json({ error: 'Invalid messages' }, 400);
}
if (messages.length > 50) {
return c.json({ error: 'Too many messages' }, 400);
}
// 各メッセージのコンテンツ長も制限する
const totalLength = messages.reduce((sum: number, m: {content: string}) => sum + m.content.length, 0);
if (totalLength > 100000) {
return c.json({ error: 'Message too long' }, 400);
}
const anthropicResponse = await fetch('https://api.anthropic.com/v1/messages', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'anthropic-version': '2023-06-01',
'x-api-key': c.env.ANTHROPIC_API_KEY, // シークレットは Worker 環境変数から安全に取得
},
body: JSON.stringify({
model: 'claude-haiku-4-5-20251001', // コスト効率重視なら Haiku、品質重視なら Sonnet
max_tokens: 2048,
messages,
stream,
}),
});
if (\!anthropicResponse.ok) {
const error = await anthropicResponse.text();
return c.json({ error }, anthropicResponse.status as 400 | 401 | 429 | 500);
}
// ストリーミングレスポンスをそのままクライアントに転送
return new Response(anthropicResponse.body, {
headers: {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive',
},
});
});
export default app;
Workers にシークレットを設定するには Wrangler CLI を使います。
# 対話的に API キーを入力（コマンド履歴に残らない）
wrangler secret put ANTHROPIC_API_KEY
# デプロイ
wrangler deploy
このプロキシ設計のもう一つの利点はレート制限の実装場所が明確になることです。Cloudflare のダッシュボードで Rate Limiting ルールを設定することで、一人のユーザーが短時間に大量リクエストを送ることを防げる。
マルチプロバイダー抽象化 — Anthropic・OpenAI・Gemini を一つのインターフェースで
プロダクションで AI 機能を運用していると、「Anthropic が障害を起こしたので OpenAI にフォールバックしたい」「コスト削減でモデルを切り替えたい」というニーズが必ず出てくる。プロバイダーごとに実装を書くと、後で変更コストが爆発します。
以下は Workers 側でマルチプロバイダーを抽象化するパターンです。
// worker/src/providers/types.ts
export type ChatMessage = { role: 'user' | 'assistant'; content: string };
export type StreamProvider = (
messages: ChatMessage[],
env: Record<string, string>
) => Promise<ReadableStream>;
// worker/src/providers/anthropic.ts
export const anthropicProvider: StreamProvider = async (messages, env) => {
const response = await fetch('https://api.anthropic.com/v1/messages', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'anthropic-version': '2023-06-01',
'x-api-key': env.ANTHROPIC_API_KEY,
},
body: JSON.stringify({
model: 'claude-sonnet-4-6',
max_tokens: 2048,
messages,
stream: true,
}),
});
if (\!response.ok || \!response.body) {
throw new Error(`Anthropic error: ${response.status}`);
}
return response.body;
};
// worker/src/providers/openai.ts
export const openaiProvider: StreamProvider = async (messages, env) => {
const response = await fetch('https://api.openai.com/v1/chat/completions', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${env.OPENAI_API_KEY}`,
},
body: JSON.stringify({
model: 'gpt-4o-mini', // コスト効率が高い
messages,
stream: true,
}),
});
if (\!response.ok || \!response.body) {
throw new Error(`OpenAI error: ${response.status}`);
}
return response.body;
};
// worker/src/providers/gemini.ts
export const geminiProvider: StreamProvider = async (messages, env) => {
// Gemini は messages 形式が異なるため変換が必要
const geminiContents = messages.map(m => ({
role: m.role === 'assistant' ? 'model' : 'user',
parts: [{ text: m.content }],
}));
const response = await fetch(
`https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:streamGenerateContent?alt=sse&key=${env.GEMINI_API_KEY}`,
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ contents: geminiContents }),
}
);
if (\!response.ok || \!response.body) {
throw new Error(`Gemini error: ${response.status}`);
}
return response.body;
};
// worker/src/index.ts — フォールバック付きプロバイダー選択
app.post('/api/chat', async (c) => {
const { messages, provider = 'anthropic' } = await c.req.json();
const env = {
ANTHROPIC_API_KEY: c.env.ANTHROPIC_API_KEY,
OPENAI_API_KEY: c.env.OPENAI_API_KEY ?? '',
GEMINI_API_KEY: c.env.GEMINI_API_KEY ?? '',
};
const providers: Record<string, StreamProvider> = {
anthropic: anthropicProvider,
openai: openaiProvider,
gemini: geminiProvider,
};
const selectedProvider = providers[provider] ?? anthropicProvider;
try {
const stream = await selectedProvider(messages, env);
return new Response(stream, {
headers: { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache' },
});
} catch (primaryError) {
// プライマリプロバイダーが失敗したら OpenAI にフォールバック
console.error('Primary provider failed, falling back:', primaryError);
try {
const fallbackStream = await openaiProvider(messages, env);
return new Response(fallbackStream, {
headers: { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache' },
});
} catch {
return c.json({ error: 'All providers failed' }, 503);
}
}
});
このアーキテクチャにより、アプリ側のコードを一切変更せずにバックエンドでプロバイダーを切り替えられます。コスト最適化の観点では、シンプルな質問は Haiku/GPT-4o-mini、複雑な推論タスクは Sonnet と振り分けるロジックも Workers 側に集約できます。
パフォーマンス最適化 — 60fps を維持するトークン表示
ストリーミング中は 1 秒間に数十回 setMessages が呼ばれます。各 setState が再レンダリングをトリガーし、長いメッセージリストでは顕著にフレームドロップが発生します。
スロットリングパターンで setState 頻度を制御します。最後の更新から 50ms 未満なら setState を遅延させる実装です。
// hooks/useStreamingChat.ts に追加するスロットリングロジック
const lastUpdateRef = useRef<number>(0);
const pendingTextRef = useRef<string>('');
const flushTimerRef = useRef<ReturnType<typeof setTimeout> | null>(null);
const flushPendingText = useCallback(() => {
if (flushTimerRef.current) {
clearTimeout(flushTimerRef.current);
flushTimerRef.current = null;
}
setMessages(prev => {
const next = [...prev];
next[next.length - 1] = {
role: 'assistant',
content: pendingTextRef.current,
};
return next;
});
lastUpdateRef.current = Date.now();
}, []);
// ストリーミングのデルタ処理内で使用
const updateText = (newText: string) => {
pendingTextRef.current = newText;
const now = Date.now();
const elapsed = now - lastUpdateRef.current;
if (elapsed >= 50) {
// 50ms 以上経過していれば即座に更新
flushPendingText();
} else {
// 50ms 後に更新をスケジュール（既存のタイマーはキャンセル）
if (flushTimerRef.current) clearTimeout(flushTimerRef.current);
flushTimerRef.current = setTimeout(flushPendingText, 50 - elapsed);
}
};
このパターンで setState 呼び出し回数を 80% 程度削減でき、FlatList のスクロールパフォーマンスが明確に改善します。ストリーミング完了時は flushPendingText() を呼んで最終テキストを確定させる。
日本語・中国語・絵文字のマルチバイト文字が化ける場合は、Hermes エンジンの TextDecoder の挙動差異が原因のことがあります。{ stream: true } オプションなしでデコードし直すか、Uint8Array を蓄積して最後に一括デコードするアプローチで解決できます。
よくある間違いと落とし穴
実際のプロジェクトで踏んだ地雷を整理します。
落とし穴 1: fetch に signal を渡し忘れる
stopStreaming を呼んでもストリームが止まらない場合、ほぼ確実に signal: abortController.signal を fetch オプションに渡していません。AbortController は fetch に接続されていないと機能しません。
落とし穴 2: max_tokens を省略する
省略するとモデルのデフォルト上限まで生成し続ける可能性があります。チャットアプリで 8000 トークンの回答が必要なことは稀で、その分コストが跳ね上がる。用途に応じて 1024〜4096 の範囲で設定します。
落とし穴 3: Component unmount 後に setState が呼ばれる
ユーザーが回答生成中に画面を離れると、unmount 済みコンポーネントへ setMessages が呼ばれ続ける。useEffect のクリーンアップで stopStreaming を必ず呼ぶ。上記の UI 実装例ではすでに対応しています。
落とし穴 4: バックグラウンド移行でストリーミングが切れる
iOS はアプリがバックグラウンドに移行すると、ネットワーク接続を数秒〜数十秒で切断することがあります。AppState を監視してバックグラウンド移行時に stopStreaming を呼ぶか、バックグラウンドでは新規ストリーミングを開始しない制御が必要です。上記 UI 実装例では AppState.addEventListener で対応しています。
落とし穴 5: プロキシなしで API キーをアプリに埋め込む
ビルド済みバイナリは逆コンパイルできます。API キーを直接コードに書くと漏洩リスクがあります。必ず Cloudflare Workers 等のプロキシ経由でアクセスする設計にすること（Cloudflare AI バックエンド設計ガイドも参照）。
落とし穴 6: SSE バッファ処理を省略する
チャンク境界をまたぐ SSE イベントを考慮せず直接 JSON.parse すると、本番で間欠的にエラーが発生します。再現性が低いため原因特定が難しくなります。必ず buffer で蓄積して \n\n 区切りで解析します。
コスト管理と監視体制
ストリーミング実装が完成したら、コストが見えないまま運用するのは危険です。Cloudflare Workers のログに各リクエストのトークン数を記録し、Anthropic/OpenAI のダッシュボードで使用量を定期的に確認する習慣をつける。
Workers 側でトークン消費の概算を記録する簡易ロギングを追加します。
// ストリーミング開始時にリクエストをログ記録
console.log(JSON.stringify({
timestamp: new Date().toISOString(),
model: 'claude-haiku-4-5-20251001',
messageCount: messages.length,
estimatedInputTokens: messages.reduce((sum, m) => sum + Math.ceil(m.content.length / 4), 0),
}));
Anthropic の streaming レスポンスは最後に message_delta イベントで実際の usage を含む。これを Workers で捕捉してログに残すと、コスト監視の精度が上がる。
また、一ユーザーあたりの日次クレジット上限を Cloudflare KV で管理することも検討に値します。KV でユーザー ID とトークン消費数をカウントし、上限超過後は 429 を返す設計です。個人開発アプリでは無料ユーザーへの無制限 AI アクセスを防ぐために有効な手段となります。
個人開発者の視点から（実体験メモ）
この実装を使ってみて変わったこと
自分のアプリにこのストリーミング実装を組み込んで最も驚いたのは、ユーザーから受けるフィードバックの質が変わることです。非ストリーミング時は「AI の回答が遅い」「バグっているのでは？」という声が多かった。ストリーミング導入後は「回答が来るのが楽しみになった」に変わった。
技術的な実装難易度（SSE 解析・AbortController・プロキシ設計）を考えると導入コストは確かにあります。しかし一度フックとプロキシを作ってしまえば、あらゆる AI 機能に再利用できます。チャット以外にも、文書要約・コード生成・翻訳といった機能で同じフックがそのまま使える。
次のステップとして、外部 API 統合ガイドと合わせて、ストリーミング応答をデータベース（Supabase 等）に保存する会話履歴機能を追加すると、より本格的な AI チャットアプリに仕上がる。Rork で生成したアプリのコード構造をベースに、このフックを src/hooks/ に配置して UI コンポーネントから呼び出す形が最もシンプルな統合方法です。