1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめての記事投稿
Qiita Tech Festa20262026年7月13日まで開催中！
@FlatkeyAITeam Coffee

OpenAI互換APIのbase_urlを変更して、AI APIコストを下げる方法

1
Last updated at Posted at 2026-06-08

はじめに

生成AIアプリケーションを本番運用していると、あるタイミングから トークンコスト が無視できなくなります。

PoCや社内検証では小さかったAPI利用料も、次のようなケースでは急に増えます。

  • AI Agent が1回の処理で何度もLLMを呼び出す
  • RAGで長いコンテキストを毎回渡す
  • バッチ処理で大量の文章を要約・分類・翻訳する
  • チャットボットやCopilotのユーザー数が増える
  • GPT / Claude など複数の主流モデルを使い分ける

この記事では、OpenAI / Anthropic互換APIの base_url を変更して、既存コードを大きく変えずにAPI接続先を切り替える方法を整理します。

この記事で扱うこと

この記事では以下を扱います。

  • OpenAI / Anthropic互換APIとは何か
  • base_url を変更する基本的な考え方
  • Python / Node.jsでの接続例
  • コストを比較するときの考え方
  • 本番導入前に確認すべきポイント
  • 小さく検証するための手順

OpenAI / Anthropic互換APIとは

OpenAI / Anthropic互換APIとは、OpenAI SDKやOpenAI / Anthropicに近い形式のリクエスト構造を使って呼び出せるAPIのことです。

アプリケーション側では、主に以下のような項目を扱います。

  • model
  • messages
  • temperature
  • stream
  • api_key
  • base_url

通常は公式エンドポイントにリクエストしますが、互換APIを提供しているゲートウェイやプロバイダーを使う場合、base_url を変更することで接続先を切り替えられます。

イメージは以下です。

Application
  ↓
OpenAI / Anthropic compatible request
  ↓
AI Token Gateway
  ↓
Routing / Available model routes
  ↓
GPT / Claude などの主流モデル

なぜbase_urlを変更するのか

base_url を変更するメリットは、既存コードの変更範囲を小さくできることです。

例えば、すでにOpenAI SDKを使っているアプリケーションであれば、以下のような部分だけを変更して検証できます。

  • APIキー
  • base_url
  • 利用するmodel名
  • 必要に応じて一部パラメータ

アプリケーション全体の設計やSDKを変えずに検証できるため、コスト削減やモデル切り替えのテストを小さく始めやすくなります。

Pythonでの例

まず、通常のOpenAI SDK利用例です。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_OPENAI_API_KEY"
)

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "user", "content": "日本語で短い自己紹介を書いてください。"}
    ],
)

print(response.choices[0].message.content)

OpenAI互換APIゲートウェイを使う場合、考え方としては base_url を指定します。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://YOUR_API_BASE_URL/v1"
)

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "user", "content": "日本語で短い自己紹介を書いてください。"}
    ],
)

print(response.choices[0].message.content)

実際の base_url、APIキー、利用可能なモデル名は、利用するサービスのドキュメントに従ってください。

Node.jsでの例

Node.jsでも考え方は同じです。

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AI_API_KEY,
  baseURL: "https://YOUR_API_BASE_URL/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [
    {
      role: "user",
      content: "日本語で短い自己紹介を書いてください。",
    },
  ],
});

console.log(response.choices[0].message.content);

環境変数で管理する場合は、以下のように分けておくと切り替えやすいです。

AI_API_KEY=your_api_key
AI_API_BASE_URL=https://YOUR_API_BASE_URL/v1
AI_MODEL=gpt-4o-mini

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AI_API_KEY,
  baseURL: process.env.AI_API_BASE_URL,
});

const response = await client.chat.completions.create({
  model: process.env.AI_MODEL,
  messages: [
    {
      role: "user",
      content: "要点を3つにまとめてください。",
    },
  ],
});

console.log(response.choices[0].message.content);

コストを比較するときの考え方

AI APIのコストは、ざっくり以下で考えられます。

APIコスト = 入力Token数 × 入力単価 + 出力Token数 × 出力単価

例えば、月間で以下のような利用があるとします。

入力Token: 100,000,000
出力Token: 20,000,000

この場合、モデルごとの入力単価・出力単価によって、月額コストは大きく変わります。

実際に比較するときは、単純な平均単価だけでなく、以下を分けて見るのがおすすめです。

  • 入力Token
  • 出力Token
  • モデル別利用量
  • 用途別利用量
  • 成功リクエスト
  • リトライや失敗リクエスト
  • バッチ処理とリアルタイム処理

特にAgent系のアプリケーションでは、1回のユーザー操作に対して内部で複数回LLMを呼び出すことがあるため、リクエスト数だけではなくToken量で見る必要があります。

簡単なコスト計算例

以下は、仕組みを説明するための仮の単価による計算例です。実際の単価は利用するモデルやプロバイダーによって異なります。

input_tokens = 100_000_000
output_tokens = 20_000_000

input_price_per_1m = 0.15
output_price_per_1m = 0.60

cost = (
    input_tokens / 1_000_000 * input_price_per_1m
    + output_tokens / 1_000_000 * output_price_per_1m
)

print(f"monthly cost: ${cost:.2f}")

出力例：

monthly cost: $27.00

実際にはモデルごとに単価が異なるため、モデル別に集計した方が正確です。

usage = [
    {
        "model": "model-a",
        "input_tokens": 80_000_000,
        "output_tokens": 15_000_000,
        "input_price_per_1m": 0.15,
        "output_price_per_1m": 0.60,
    },
    {
        "model": "model-b",
        "input_tokens": 20_000_000,
        "output_tokens": 5_000_000,
        "input_price_per_1m": 0.30,
        "output_price_per_1m": 1.20,
    },
]

total = 0

for item in usage:
    cost = (
        item["input_tokens"] / 1_000_000 * item["input_price_per_1m"]
        + item["output_tokens"] / 1_000_000 * item["output_price_per_1m"]
    )
    total += cost
    print(item["model"], f"${cost:.2f}")

print("total", f"${total:.2f}")

こうしてモデル別に見ると、どのモデル・どの用途がコストの中心になっているか分かりやすくなります。

base_urlを切り替える前に確認すること

base_url を変更するだけで接続先を切り替えられる場合でも、本番投入前にはいくつか確認が必要です。

1. モデル名の対応

互換APIであっても、利用できるモデル名が完全に同じとは限りません。

確認すべき項目：

  • 使いたいモデルが利用可能か
  • モデル名は同じか
  • 代替モデルを使う必要があるか
  • 入力Token上限は同じか
  • 出力Token上限は同じか

2. パラメータの互換性

利用するゲートウェイによって、対応しているパラメータの範囲は異なります。

以下のようなパラメータを使っている場合は、事前に確認します。

  • temperature
  • top_p
  • max_tokens
  • stream
  • tools
  • tool_choice
  • response_format

特に、function calling / tool calling など公式API固有の機能を使っている場合は、利用するゲートウェイ側で対応しているか、実際のレスポンス形式まで確認した方が安全です。

3. ストリーミング

チャットUIでは stream: true を使うことがあります。

ストリーミングを使っている場合は、以下を確認します。

  • 最初のTokenが返るまでの時間
  • chunkの形式
  • エラー時の挙動
  • フロントエンド側の表示に影響がないか

4. レイテンシ

コストが下がっても、レスポンスが遅すぎるとユーザー体験に影響します。

用途ごとに許容できるレイテンシは違います。

リアルタイムチャット: レイテンシ重要
バッチ処理: レイテンシより単価が重要
社内ツール: 中程度
Agent処理: 全体完了時間を見る

5. 可用性とエラー率

本番環境では、価格だけでなく安定性も重要です。

確認すべき項目：

  • 5xxエラー率
  • タイムアウト率
  • レート制限
  • リトライ時の挙動
  • 利用量ログの確認方法
  • 障害時の切り戻し手順

6. データの扱い

企業利用では、送信データの扱いも確認が必要です。

  • 入力内容がログ保存されるか
  • 保存期間はどれくらいか
  • 個人情報や機密情報を送れるか
  • 利用規約上の制限はあるか
  • セキュリティレビューに必要な情報があるか

小さく検証する手順

いきなり全トラフィックを切り替えるのではなく、小さく検証するのがおすすめです。

Step 1: 開発環境で疎通確認

まずは開発環境で base_url を変更します。

AI_API_BASE_URL=https://YOUR_API_BASE_URL/v1
AI_API_KEY=your_test_key

確認すること：

  • APIが正常に返るか
  • レスポンス形式が期待通りか
  • 既存コードで例外が出ないか

Step 2: 低リスクな処理で試す

最初は、ユーザー体験への影響が小さい処理で試すのが安全です。

例：

  • 社内用の要約
  • バッチ分類
  • 開発用テスト
  • 非同期のコンテンツ生成
  • ログ分析やデータ整形

Step 3: 結果を比較する

以下を比較します。

項目 確認内容
品質 出力内容が実用レベルか
コスト 同じToken量でどれくらい変わるか
レイテンシ 許容範囲か
エラー率 本番利用できる水準か
運用性 ログや利用量を確認しやすいか

Step 4: 一部トラフィックで試す

問題がなければ、一部の本番トラフィックで試します。

例えば：

  • 5%だけ切り替える
  • 特定機能だけ切り替える
  • 特定ユーザーグループだけ切り替える
  • バッチ処理だけ切り替える

この段階で、品質・コスト・安定性を見ながら段階的に広げます。

どんなケースに向いているか

base_url の切り替えによる検証は、以下のようなケースに向いています。

AI Agent

Agentは内部で複数回モデルを呼び出すため、Tokenコストが増えやすいです。

AI SaaS

ユーザー利用量に応じてAPIコストが増えるため、粗利率に直結します。

コンテンツ生成

文章生成、要約、翻訳、分類などを大量に実行する場合、単価差の影響が大きくなります。

社内AIツール

複数部署で生成AIを使う場合、利用量管理とコスト管理が重要になります。

開発・検証用途

Claude CodeやGPTなどを使いながら開発・検証する場合、検証コストを抑えやすくなります。

向いていない可能性があるケース

一方で、以下のようなケースでは慎重に検証した方がよいです。

  • 超低レイテンシが必要なリアルタイム処理
  • 特定モデルの細かい挙動に強く依存している
  • function callingの互換性が重要
  • セキュリティ要件が非常に厳しい
  • 公式API以外を使えない契約・社内ルールがある

コストだけで判断せず、品質・安定性・運用要件も含めて比較する必要があります。

まとめ

AI APIのコストは、本番運用に入ると大きな課題になります。

特に、AI Agent、AI SaaS、バッチ処理、コンテンツ生成のようにToken消費が大きい用途では、モデル単価の差がそのまま利益率に影響します。

OpenAI / Anthropic互換APIを使って base_url を変更する方法は、既存コードを大きく変えずに接続先を切り替えられるため、小さく検証しやすいアプローチです。

ポイントは以下です。

  • Tokenコストは本番運用で急に大きくなる
  • 互換APIなら既存SDKを活かしやすい
  • base_url の変更だけで接続先を切り替えられる
  • コストだけでなく、品質・レイテンシ・互換性・可用性を見る
  • まずは開発環境や低リスクな処理から試す

補足

この記事で紹介したようなOpenAI / Anthropic互換APIゲートウェイの一例として、Flatkeyがあります。

Flatkeyは、GPT・Claudeなどの主流AIモデルをOpenAI / Anthropic互換APIのまま利用しながら、トークンコストを下げることを目的としたAI トークンゲートウェイです。

管理画面では、APIキーの作成、クレジット追加、リクエスト送信、残高、利用量、リクエスト数、利用履歴、モデル料金などを確認できます。

導入は base_url を変更する形で小さく検証できます。

なお、削減率はモデル構成や利用量、当時の供給状況によって変動します。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?