Rork で作ったアプリが Sonnet 4.5 を呼んでいないか

自作のチャット機能付きアプリを久しぶりに開き直して、ソースを検索してみる場面を想像してみてください。「claude」で検索すると、思っていたより多くの場所にモデルの名前が書かれています。環境変数に1か所、画面側のコードに1か所、サーバー側の関数にもう1か所。どれが今も使われているのか、すぐには見分けがつきません。

Anthropic の廃止ページによると、Claude Sonnet 4.5 は 2026年9月30日に提供終了の告知が出ており、提供終了は 2026年11月30日（状況表では tentative と表記）の予定です。推奨される移行先は claude-sonnet-5-5 と記載されています。告知から終了まで 61 日で、公開モデルには最低 60 日前の通知を行うという規定どおりの日程です。

ここでは、アプリ内に残っているモデル ID を洗い出すスクリプトと、見つかった場所ごとの直し方をお伝えします。

まず、何が対象になるのかを切り分けます

混同しやすいので、先に線を引いておきます。

Rork のモデルメニューで選ぶモデルは、アプリを「作る」ときに働く AI の話です。アプリが実行時に呼び出すモデルとは別物です。メニュー側の考え方は Sonnet 5.5・GPT-6.1 Sol・Opus 5.5 のどれに頼むかを、修正の種類で先に決めておきますにまとめています。
点検の対象は、自分でアプリに足した Claude API の呼び出しです。チャット、要約、キャプション生成、検索の言い換えなど、アプリの中から Anthropic の API を叩いている箇所が該当します。

廃止ページで私が確認できた行は、日付付きの ID（claude-sonnet-4-5-20250929）だけでした。日付なしの別名（claude-sonnet-4-5）の扱いは表に載っていないため、同じ系統として「要対応」に入れて点検します。もう一つの claude-haiku-4-5-20251001 は Active で、廃止日の記載はなく、「最短でも 10月15日以降」という目安のみです。こちらは今すぐの対応は要りませんが、様子見の欄に置いておきます。

洗い出しスクリプト

依存パッケージは不要で、Node.js だけで動きます。claude- で始まる文字列をすべて拾い、廃止予定の系統かどうかを判定します。node_modules や ios・android の生成物は読み飛ばします。

// scan-claude-models.mjs — プロジェクト内の Claude モデル ID を洗い出す
// 使い方: node scan-claude-models.mjs ./my-app
import { readdirSync, readFileSync, statSync } from "node:fs";
import { join, relative, extname } from "node:path";
 
const root = process.argv[2] ?? ".";
const SKIP_DIRS = new Set(["node_modules", ".git", ".expo", "ios", "android", "dist", "build"]);
const EXTS = new Set([".ts", ".tsx", ".js", ".jsx", ".mjs", ".json", ".env", ".toml", ".yml", ".yaml", ".sql", ".md"]);
 
// 状態は Anthropic のモデル廃止ページで確認した値に書き換えてください（日付は確認日のもの）
const RETIRING = {
  "claude-sonnet-4-5": "2026-11-30 提供終了予定（後継: claude-sonnet-5-5）",
};
const WATCH = {
  "claude-haiku-4-5": "現時点で廃止予定の記載なし（最短でも 2026-10-15 以降の目安のみ）",
};
 
const idPattern = /claude-[a-z0-9]+(?:-[a-z0-9]+)*/g;
const hits = [];
 
function walk(dir) {
  for (const name of readdirSync(dir)) {
    if (SKIP_DIRS.has(name)) continue;
    const path = join(dir, name);
    const st = statSync(path);
    if (st.isDirectory()) { walk(path); continue; }
    const isEnv = name === ".env" || name.startsWith(".env.");
    if (!isEnv && !EXTS.has(extname(name))) continue;
    if (st.size > 1_000_000) continue;
    readFileSync(path, "utf8").split("\n").forEach((line, i) => {
      for (const m of line.matchAll(idPattern)) {
        hits.push({ id: m[0], file: relative(root, path), line: i + 1 });
      }
    });
  }
}
walk(root);
 
// 日付付き ID（claude-sonnet-4-5-20250929）も、日付を外した別名と同じ系統として判定する
const base = (id) => id.replace(/-\d{8}$/, "");
let danger = 0;
for (const h of hits) {
  const b = base(h.id);
  const label = RETIRING[b] ? "要対応" : WATCH[b] ? "様子見" : "対象外";
  const note = RETIRING[b] ?? WATCH[b] ?? "";
  if (RETIRING[b]) danger++;
  console.log(`${label} | ${h.id} | ${h.file}:${h.line} | ${note}`);
}
console.log(`\n検出 ${hits.length} 件 / 要対応 ${danger} 件`);
process.exit(danger > 0 ? 1 : 0);

使い方は次のとおりです。

node scan-claude-models.mjs ./my-app

要対応が1件でもあると終了コードが 1 になるので、後からビルド前の確認に組み込むこともできます。上の RETIRING と WATCH の中身は、廃止ページを見て書き換えてください。表の状態は変わることがあります。

動作確認用に、4か所へモデル ID を置いたダミーのプロジェクトで実行した結果です（node_modules の中にも同じ文字列を置いて、読み飛ばされることを確かめています）。

要対応 | claude-sonnet-4-5-20250929 | .env:1 | 2026-11-30 提供終了予定（後継: claude-sonnet-5-5）
要対応 | claude-sonnet-4-5 | src/chat.ts:1 | 2026-11-30 提供終了予定（後継: claude-sonnet-5-5）
様子見 | claude-haiku-4-5-20251001 | src/chat.ts:2 | 現時点で廃止予定の記載なし（最短でも 2026-10-15 以降の目安のみ）
要対応 | claude-sonnet-4-5-20250929 | supabase/functions/chat/index.ts:1 | 2026-11-30 提供終了予定（後継: claude-sonnet-5-5）

検出 4 件 / 要対応 3 件

見つかった場所で、直す順番が変わります

同じ「要対応」でも、直すのにかかる時間はまるで違います。ここが一番お伝えしたいところです。

見つかった場所	反映までに必要なこと	着手の目安
サーバー側の関数（Supabase Edge Functions など）	ID を書き換えて再デプロイするだけです。ストア審査は要りません	11月第2週までに
アプリ内のコードや `EXPO_PUBLIC_` で始まる環境変数	ビルドに埋め込まれるため、新しいビルドの公開と、ユーザーの更新が必要です	今週中に

Expo の EXPO_PUBLIC_ で始まる環境変数は、ビルド時に値がアプリ本体へ埋め込まれます。つまり、手元で .env を書き換えても、すでに配信済みのアプリは古い ID を持ったままです。ストアの審査待ちと、ユーザーが更新してくれるまでの日数を足すと、11月30日までの余裕は思ったより短くなります。

個人開発でアプリを運用している私が、この表から引いた線は一つです。モデル ID は、アプリではなくサーバー側に置く。API キーをアプリに持たせない理由と同じ方向の判断で、次にモデルが入れ替わるときは再デプロイだけで済みます。今回の洗い出しで「アプリ側に ID が埋まっている」と分かった方は、移行のついでにサーバー側へ寄せておくと、来年の同じ作業が一日分軽くなります。

差し替える前に、同じ入力で出力を見比べます

後継として案内されているのは claude-sonnet-5-5 ですが、ID を置き換えれば終わり、とはいかないと考えています。応答の長さや口調が変わると、画面のレイアウトや後続の処理に影響が出ることがあるからです。

私自身は、次の順で確かめています。

実際のアプリで使っている入力を3件選び、現行のモデルで出力を保存します。
同じ入力を新しい ID で実行し、文字数・形式（JSON を返す機能なら、パースできるか）・口調を見比べます。
料金とレート制限は、公式の料金ページで確認してから切り替えます。ここでは数値を載せません。変わっている可能性があるためです。
問題がなければサーバー側の ID を書き換え、再デプロイします。

同じ「上げる前に洗い出す」考え方で、SDK を上げる前の点検は SDK 58 で削除された React Native の API を、アップグレード前に洗い出すスクリプトも書いています。

今日できる最初の一歩

プロジェクトのフォルダでスクリプトを一度走らせて、「要対応」の件数を数えてみてください。0 件なら、今回は何もしなくて大丈夫です。1 件でもあれば、その場所がサーバー側かアプリ側かだけを先に確かめます。そこが分かれば、残りの作業の順番は自然に決まります。

廃止の日付は、公式ページで変更される可能性があります。実際に切り替える前に、もう一度だけ廃止ページの該当行を見ておくことをおすすめします。

Rork で作ったアプリが Sonnet 4.5 を呼んでいないか、11月30日の前に洗い出します

まず、何が対象になるのかを切り分けます

洗い出しスクリプト

見つかった場所で、直す順番が変わります

差し替える前に、同じ入力で出力を見比べます

今日できる最初の一歩

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

関連記事