チュートリアル

1つのAPIキーで複数の画像モデルを呼び出す方法

GPT Image 2、Nano Banana、Qwen Image、FLUXを、モデルごとに認証を再構築することなくテストしたいチームのための実用的なルーティングパターン。

Jun 20, 2026

チームが統一された画像生成APIを求める理由

画像生成は通常、単一のモデルから始まります。プロダクトチームは1つのプロンプトを試し、1つのSDKを接続し、小さなプロトタイプを提供します。問題が現れるのは後の段階です。製品が複数の出力スタイルを必要とするとき——社内レビュー用の素早いドラフト、ポスター上の読みやすい文字、地域マーケティング向けの中文字のレンダリング、あるいは製品ページ用のフォトリアルな素材などです。

モデルごとに異なるAPIキー、リクエスト構造、課金アカウント、コールバックパターンがあると、モデルのテストはインフラ作業になってしまいます。よりシンプルなパターンは、認証を安定させたまま、モデルの選択をリクエストボディに移すことです。

HiAPIのAI Image APIsページは、このワークフローの主要な比較ページです。これを使ってどの画像モデルを製品に組み込むべきかを判断し、各モデルのページで正確なパラメータとサンプルを確認してください。

サーバーサイドのAPIキーを1つ使う

APIキーはブラウザのコードではなく、バックエンドに保管する必要があります。フロントエンドはプロンプト、画像、生成設定を収集できますが、HiAPIタスクを作成するのはバックエンドです。

API Keysページでキーを作成またはローテーションします。本番環境ではサーバーの環境変数に保存し、Authorizationリクエストヘッダーとして付加します：

Authorization: Bearer YOUR_API_KEY

これにより、認証情報をローテーションする場所が1つ、レート制限を追加する場所が1つ、生成ワークフローのトラフィックが増えたときに確認するための課金面が1つ確保されます。

プロバイダーのクライアントではなくモデルIDでルーティングする

実装上の重要なポイントは、エンドポイントを安定させ、モデルIDをルーティングパラメータとして扱うことです。アプリケーションは「draft」「poster」「product image」「photorealistic」などのプリセットを公開し、バックエンドがそれらのプリセットをモデルIDにマッピングできます。

たとえば、ある製品ではまずNano Bananaで素早いアイデア探索を行い、画像に読みやすい文字やレイアウト変更が必要なプロンプトではGPT Image 2を使い、中国語のソーシャルメディア用グラフィックはQwen Image 2.0にルーティングし、商業的な質感を持つ製品ビジュアルの生成にはFLUX 1.1 Proを使う、といった構成ができます。

アプリケーションコードは、これをサポートするために4つの認証フローを必要としません。必要なのはタスク作成のパス1つと、小さなルーティングレイヤーだけです。

最小限のリクエストパターン

以下は、統一されたタスクエンドポイント経由でGPT Image 2を呼び出す簡潔なリクエストです：

curl -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2/text-to-image",
    "input": {
      "prompt": "A premium ecommerce hero image for a smart lamp, clean studio lighting",
      "aspect_ratio": "16:9",
      "resolution": "1K"
    }
  }'

GPT Image 2の正確なフィールドについては、GPT Image 2 API ドキュメントを参照してください。モデルの選択については、AI Image APIs 比較から始めてください。

コールバックを使った本番フロー

ポーリングはローカルでのテストには便利ですが、本番トラフィックは通常、コールバックの恩恵を受けます。バックエンドがタスクを作成するときにコールバックURLを渡し、コールバックを最終状態の情報源として扱います。照合のためのフォールバックとして、タスクポーリングを引き続き保持することもできます。

実際の流れは次のとおりです：

フロントエンドがプロンプトと生成設定をバックエンドに送信します。
バックエンドがリクエストを検証し、モデルIDを選択して、HiAPIタスクを作成します。
HiAPIがタスクIDを即座に返します。
バックエンドがタスクIDを保存し、最終コールバックを待ちます。
タスクが最終状態に達すると、アプリケーションが出力URLを表示します。

これにより、ユーザー向けのページを素早く応答させたまま、生成量が増えるにつれて煩雑になる激しいポーリングループを避けることができます。

価格をハードコードしない価格ワークフロー

静的な価格表をアプリケーションコードや古い社内ドキュメントにコピーしないでください。より安全なワークフローは、ユーザーと運用担当者をリアルタイム価格ページに誘導し、その後、自社製品内で使用量を追跡することです。

コスト重視のアイコン生成では、プロンプトがまだ変化している間は低コストのモデルを使用します。プロンプトが安定してから初めて解像度を上げます。出力により鮮明な文字、より厳密なレイアウト、より多くの商業的な磨き込みが必要になったら、最終的なブランドや製品の素材をより強力なモデルに移行します。

このパターンにより、実験を低コストに保ちながら、製品に高品質な最終パスを提供できます。

SEOパスを明確に保つ内部リンク

この記事は画像APIのハブページを支援することを目的としており、それに取って代わるものではありません。標準的な比較ページは最高のAI画像生成APIです。モデル固有の実装ページはGPT Image 2 APIです。コンバージョンページはHiAPI上のGPT Image 2、価格、API Keysです。

関連ワークフローについては、テキストtoビデオ vs 画像toビデオ APIワークフローとGPT Image 2の価格要因と本番事例をお読みください。

よくある質問

1つのAPIキーで複数の画像モデルを呼び出せますか？

はい。HiAPIでは、同じAPIキーで複数の画像モデルのタスクを作成できます。リクエストボディのモデルIDを変更するだけで、異なる画像モデルにルーティングされます。

ブラウザアプリケーションでAPIキーを公開すべきですか？

いいえ。キーはサーバー側に保管してください。ブラウザのコードは自社のバックエンドを呼び出し、バックエンドがHiAPIタスクを作成するようにします。

どの画像モデルから始めるべきですか？

タスクに合ったモデルから始めてください。Nano Bananaは素早いアイデア出しに適しており、GPT Image 2は長いプロンプトや読みやすい文字に強いデフォルトの選択肢、Qwen Image 2.0は中国語の文字レンダリングに適しており、FLUX 1.1 Proはフォトリアルな製品ビジュアルに適しています。