複数のAIモデルを使い分けたい｜用途ごとにモデルを切り替える仕組みの作り方

連載の現在地:Phase 2「費用と安定」(3 / 4本目) — 使われ始めたら、財布と稼働を守る
1. 公開 → 2. 費用と安定 → 3. 安全 → 4. 品質 → 5. 自動化

こんな悩みの人へ

すべての処理に一番高いモデルを使っていて、費用がかさんでいる。OpenAIとAnthropicの両方を使いたいが、コードがプロバイダーごとに分かれてしまう。新しいモデルが出るたびに、コードを書き換えている。そんな方に向けた記事です。

結論

接続先をCloudflare AI Gatewayにまとめ、どの処理にどのモデルを使うかは設定ファイルで管理します。 新規実装では現在のREST APIを使い、OpenAIにはResponses形式、AnthropicにはMessages形式を選びます。モデル名とAPI形式を一緒に管理すれば、切り替えの処理を1か所にまとめられます。

分類や短い要約のような軽い処理は、Cloudflare上で動くWorkers AIのモデルも選択肢になります。

役割は次のように分かれます。モデルを入れ替えるときに書き換えるのは、真ん中の設定ファイルだけです。

アプリのコード   generate("classify") / generate("summarize") / generate("proposal")
                     |  用途名だけを書く
                     v
models.ts        用途名 -> モデル名・API形式   ← 入れ替えはここだけ
                     |
                     v
AI Gateway       記録・上限をまとめて、各プロバイダーへ中継
                     |
                     v
                 OpenAI / Anthropic / Workers AI

なぜモデルの使い分けは難しいのか

モデルの使い分けが難しいのは、まず、プロバイダーごとにAPIの形が違うからです。SDK、リクエストの書き方、エラーの返し方がそれぞれ異なり、使い分けるほどコードが増えます。

また、どの処理にどのモデルが合うかは、試してみないと分かりません。価格表だけでは判断できず、実際の入力で比べる必要があります。

そのうえ、モデル名がコードのあちこちに散らばりがちです。入れ替えのたびに、何か所も書き換えることになります。

解決策の比較

ライブラリでの抽象化とAI Gatewayは、併用できます。

どれを選ぶか

費用の見える化や上限設定もあわせて行いたいなら、AI Gatewayが向いています。多数のモデルを比較・試作したい場合は集約サービス、コードの書き方を統一したいだけならライブラリでの抽象化で足ります。

手順

1. 用途とモデルの対応表を作る

まず、アプリの中のAI処理を洗い出し、重さで分けます。

候補は2026-11-03時点のOpenAIの現行モデルとClaude Sonnet 5.5の仕様に基づきます。用途への適性は、自社の質問で比較して決めます。

2. 接続先をAI Gatewayにまとめる

AI Gatewayの現在のREST APIでは、モデル名にプロバイダー名を付けて指定します。次はGPT-6 LunaをResponses形式で呼ぶ例です。アカウントの「Workers AI: Read」権限を持つCloudflare APIトークンを使い、cf-aig-gateway-id で作成済みのゲートウェイを指定します。

curl -X POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/v1/responses" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "cf-aig-gateway-id: my-app" \
  --header "Content-Type: application/json" \
  --data '{"model":"openai/gpt-6-luna","input":"こんにちは","reasoning":{"effort":"none"},"max_output_tokens":1024,"store":false}'

プロバイダーごとの窓口(https://gateway.ai.cloudflare.com/v1/{アカウントID}/{ゲートウェイ名}/{プロバイダー})を使えば、各社のSDKとAPIキーを使いながら、記録や上限設定をまとめることもできます。こちらはProvider Nativeという接続方式です。

3. モデル名を設定ファイルに出す

コードにはモデル名を書かず、用途名だけを書きます。

// models.ts
export const MODELS = {
  classify: { model: "openai/gpt-6-luna", api: "responses" },
  summarize: { model: "openai/gpt-6.1-sol", api: "responses" },
  proposal: { model: "anthropic/claude-sonnet-5.5", api: "messages" },
} as const;

// サーバー側の呼び出し関数
async function generate(task: keyof typeof MODELS, input: string) {
  const selected = MODELS[task];
  const body = selected.api === "responses"
    ? { model: selected.model, input, max_output_tokens: 2048, store: false }
    : {
        model: selected.model,
        max_tokens: 2048,
        messages: [{ role: "user", content: input }],
      };
  const res = await fetch(
    `https://api.cloudflare.com/client/v4/accounts/${process.env.CLOUDFLARE_ACCOUNT_ID}/ai/v1/${selected.api}`,
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.CLOUDFLARE_API_TOKEN}`,
        "cf-aig-gateway-id": "my-app",
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    },
  );
  if (!res.ok) throw new Error(`AI request failed: ${res.status}`);
  return res.json();
}

上記はサーバーの環境変数にアカウントIDとAPIトークンを設定して使う例です。generate("summarize", 本文) のように用途名で呼び出します。戻り値は各APIのJSONなので、画面へ渡す回答文は、Responses形式なら output、Messages形式なら content から取り出します。

MODELS に as const を付け、引数を keyof typeof MODELS にしているのは、存在しない用途名を書いたときに型エラーで気づけるようにするためです。モデル名を文字列で直接渡す作りにすると、打ち間違いが実行時まで見つかりません。

Cloudflare経由では anthropic/claude-sonnet-5.5、Anthropicへ直接接続する場合は claude-sonnet-5-5 を使います。OpenAIも、Cloudflare経由の openai/gpt-6-luna と直接接続の gpt-6-luna を区別します。モデルIDと対応APIはCloudflareのモデル一覧で確認します。

4. 同じ質問で比べて記録する

用途ごとに、答えの分かっている質問を10〜20個用意し、候補のモデルで同じように実行します。品質、応答時間、1回あたりの費用を表にして比べます。比べ方は「回答が不安定で、品質をどう測ればいいか分からない」で整理しています。

5. 費用と品質を見ながら見直す

AI Gatewayの分析で、モデル別の費用を確認します。高いモデルを使っている処理のうち、安いモデルでも品質が落ちないものを探して切り替えます。

更新日:2026-11-03

つまずきやすい点

モデルごとに、出力の癖が違います。同じプロンプトでも長さや書式が変わるので、JSONで受け取る処理は、切り替え先でも形が崩れないか確認してください。

AI Gatewayには、内容に応じてモデルを自動で選ぶ機能(Auto Router)や、条件で振り分ける機能(Dynamic Routing)もあります。ただし、どちらもベータ機能です。本番で使う場合は、挙動を確認してからにしましょう。

Workers AIの一部のモデルは、有料プラン限定です。2026年7月から、負荷の高い一部のモデルには、Workersの有料プランが必要になりました。

認証の方法も確認が必要です。上のREST APIの例は、CloudflareのAPIトークンで認証し、第三者モデルの利用料をCloudflareのクレジットから支払う方式(Unified Billing)です。自社のプロバイダーキーを使う場合は、Provider Nativeなど、対応する接続方式を選びます。

次に出やすい悩み

使い分けを始めると、モデル別の費用と、切り替えて品質が落ちていないかを確かめる必要が出てきます。モデル別・用途別の費用を比べたいなら「LLM APIの請求額が読めない」を、1つのモデルが止まったときの切り替え先にも使いたいなら「レート制限やエラーで、AIの機能が止まる」を読んでみてください。安いモデルに替えても品質が落ちないかを根拠を持って判断したい場合は、Phase 4の「AIの回答が不安定で、品質をどう測ればいいか分からない」で評価の方法を整理しています。

「どの処理を安いモデルに替えられるか、一緒に見てほしい」という段階からご相談いただけます。モデルの使い分けを含めたAI機能の設計はCloudflareインフラ構築をご覧ください。

よくある質問

Q. 単価が安いモデルへ替えるだけで、費用を下げられますか？

単価に加え、必要な品質、入出力の量、再試行の増加、応答時間を同じ業務の質問で比較します。安いモデルで修正や再生成が増えると、期待した削減にならない場合があります。採用の判断に使う質問と基準を先に揃えておきます。

Q. モデル名をコードへ直接書くと、何が困りますか？

複数の場所へモデル名が散らばると、変更時の修正漏れが起きやすくなります。本文では、要約や分類などの用途名とモデルの対応を設定へまとめます。接続先を共通化しても各社のAPI形式が同じになるとは限らないため、応答の取り出し方も確認します。

Q. 別のモデルへ切り替えても、JSONや出力形式は同じですか？

同じプロンプトでも、長さや書式、対応する出力機能に違いがあります。切り替え先でも期待する形式を守れるか、実際のテストケースで検証します。アプリ側で出力を検査し、形式が崩れたときの表示や処理も決めてください。

Q. 用途別の振り分けと、障害時のモデル切り替えは同じですか？

用途別の振り分けは、処理に必要な品質や費用に合わせて接続先を選ぶ設計です。障害時の切り替えは、エラーやタイムアウトの際に代替先へ進む設計で、条件と待ち時間を別に決めます。後者は再試行と切り替えの記事もあわせて確認してください。

執筆者情報

パブロフ株式会社

IT顧問、AI・業務アプリ開発、SESを通じて、企業のIT活用を支援しています。代表の藤澤 昌隆は、2007年からシステム開発・運用に携わり、アクセンチュアでの業務ITコンサルティングを経て、2019年にパブロフ株式会社を設立しました。

AI活用の支援事例として、営業工程を支える7つの業務別AIアプリの構築を公開しています。アプリの開発に加え、入力・出力の形式、評価基準、テストケースの整備にも取り組んでいます。

記事の内容に関するご質問や誤りのご指摘は、お問い合わせ窓口へお寄せください。

参考資料

• AI Gatewayの現在のREST API
• Unified Billing
• Auto Router / Dynamic Routing
• Workers AI有料限定モデル
• モデル一覧
• GPT-6 LunaのモデルIDとAPI形式
• GPT-6.1 SolのモデルIDとAPI形式
• Claude Sonnet 5.5のモデルIDとAPI形式
• Claude Sonnet 5.5の公式仕様