Hello Tokenhot：マルチモデルアプリ向け統合APIゲートウェイ

AIアプリケーションでは、複数種類のモデルが必要になる場合があります。日常的なリクエストには小型モデル、難しい作業には推論モデル、メディア生成には画像または動画モデルといった使い分けです。モデルを追加するたびに、統合、認証情報、課金設定、運用上の詳細も増えます。

私たちは、このマルチモデル構成を管理しやすくするためにTokenhotを開発しました。Tokenhotは、GPT、Claude、Gemini、DeepSeekなどのモデルファミリーへOpenAI互換のchatでアクセスできる共通APIサービスです。使い慣れたクライアントインターフェースを保ちながら、タスクに合うルートを選べます。quick startドキュメントでは、ベースURL、認証、基本リクエスト形式を説明しています。

本記事は2026年9月14日に更新しました。公開時点の固定カタログ数に頼らず、現在の識別子と料金はモデルカタログで確認してください。

複数のモデルファミリーへ接続する1つの出発点

標準的なchatリクエストでは、アプリケーションからTokenhotのbearer keyを使ってhttps://api.tokenhot.ai/v1/chat/completionsへmessagesを送ります。OpenAI SDKを使う場合は、ベースURLをhttps://api.tokenhot.ai/v1に設定し、対応するモデル名を選択します。

この共通インターフェースは、異なるモデルをテストするための実用的な出発点になります。実験ごとにまったく別のクライアントを構築せず、プロンプトの組み立て、レスポンス処理、アプリケーション側の計測をまとめて管理できます。

互換性は操作とモデルによって異なります。基本的なchatリクエストが動作しても、別のプロバイダーが提供するすべてのツールオプション、構造化出力機能、推論制御、エンドポイントへの対応を証明することにはなりません。高度なワークフローを移す前に、該当するAPIドキュメントを確認してください。

最初のリクエストを送る

Tokenhotコンソールでキーを作成し、カタログからモデルを選び、サーバー環境にTOKENHOT_API_KEYとTOKENHOT_MODELを設定します。pip install openaiでOpenAI Python SDKをインストールしてから、次のコードを使用します。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TOKENHOT_API_KEY"],
    base_url="https://api.tokenhot.ai/v1",
    timeout=120.0,
    max_retries=0,
)

response = client.chat.completions.create(
    model=os.environ["TOKENHOT_MODEL"],
    messages=[{
        "role": "user",
        "content": "Suggest three checks for a reliable API integration."
    }],
)
print(response.choices[0].message.content or "")
print(response.usage)

これはドキュメントに基づく出発点であり、実際の性能テストではありません。最初の診断呼び出しには、明示的なタイムアウトを設定し、自動再試行を無効にしています。この呼び出しが成功したら、ワークロードに合わせて再試行とタイムアウトを設定し、アプリケーションが実際に使う機能をテストしてください。

キーはサーバー側の設定で管理します。サービスキーをブラウザコードに公開せず、フロントエンドからアプリケーションのバックエンドを呼び出してください。DeepSeek固有の手順については、中国国外からDeepSeek APIを使う方法を参照してください。

必要な作業を使ってモデルを比較する

有用なモデル比較は、代表的なタスクと合格基準から始まります。抽出では、出力がスキーマと情報源に一致するか確認します。コーディングでは、関連するテストを実行します。顧客向け回答では、事実上の裏付けと、回答が依頼を解決しているかを評価します。

選択したモデルルート、入力サイズ、出力設定、完了時間、失敗、課金使用量を記録してください。これらの測定値は、単一の公称料金やレイテンシの主張よりも、そのルートが適しているかを明確に示します。

選択したルートについて、現在のカタログ料金を使います。入力と出力では料金が異なる場合があり、キャッシュによって請求額が変わり、メディア生成では別の課金単位を使うことがあります。LLM API料金比較では、ワークロードの見積もり方法と、原開発元の料金をゲートウェイ料金から分ける方法を説明しています。

メディアワークフローには固有のリクエストライフサイクルがある

画像と動画の生成は、選択したモデルのドキュメントに基づいて統合します。たとえば、TokenhotのSeedance 2.5 APIでは、content配列を含む動画生成リクエストと非同期タスクレスポンスが記載されています。これは、完成したchat回答を読み取るワークフローとは異なります。

アプリケーションでメディアを生成する場合は、タスク追跡、失敗ジョブ、出力取得、保存を計画してください。大規模なバッチを作成する前に、対応解像度、時間、入力参照、課金を確認します。Sora API移行ガイドでは、既存の動画ワークフローを移す際の判断を順に説明しています。

ルートでのデータ処理方法を把握する

Tokenhotが公開しているプライバシー規約には、課金と運用に使うリクエストメタデータ、プロンプトと生成コンテンツの一時的なキャッシュの可能性、上流モデルプロバイダーへのリクエスト内容の転送が記載されています。その処理には上流プロバイダー自身のポリシーも適用されます。

ワークロードに合うルートとデータ設定を選び、機密情報を送る前に適用条件を確認してください。組織が特定の保持期間、処理地域、契約上の確約を必要とする場合は、利用予定のサービスと上流ルートがその要件を満たすことを確認します。

観測可能な障害を前提に構築する

ゲートウェイはアプリケーションが統合するサービス境界を簡素化できますが、アプリケーション側では失敗したリクエストと中断されたストリームを処理する必要があります。明示的な期限を設定し、利用できる場合はリクエスト識別子を保持し、完全な回答と部分的な出力を区別してください。

トラフィックを拡大する前に、適切なテスト環境で認証失敗、レート制限、タイムアウト、モデル固有のエラーを発生させて確認します。再試行が使用量に与える影響と、ルート変更によって出力動作が変わるかを検証してください。成功率と完了時間を含め、ユーザーが体験する結果にアラートを設定します。

Tokenhotは、こうした作業の共通の出発点を提供します。モデルカタログを開き、対応ルートを選び、quick startを使って小さなリクエストを送信してください。その後、アプリケーションにとって重要な品質、コスト、運用動作を検証します。