Midjourney V8.2 API：画像タスクの送信と取得
Midjourney V8.2 APIで画像タスクを送信し、IDを保存してPythonで結果を取得する手順を解説します。バージョン別のパラメーター、画像操作、現在の料金も確認できます。
Markdown で読むMidjourney V8.2 APIを組み込むには、バージョンの明示、有効な画像リクエスト、完了したタスクを取得する仕組みが必要です。SeedRouterでは、/v1/images/generations に送信し、返されたタスクIDを保存して /v1/tasks/{id} をポーリングします。送信の成功はタスクが受け付けられたことを示し、画像は完了後の結果に含まれます。
このガイドはSeedRouterのリクエスト仕様に沿っています。2026年10月18日の有料検証では、V8.2 Fastのリクエストが完了し、1024 × 1024の画像が4枚返されました。下のポートレートはそのうちの1枚です。モデルページにはPlaygroundと現在の料金を掲載し、APIリファレンスでは対応する入力と、まだ検証が必要な組み合わせを区別しています。[1]
Midjourney V8.2 APIのモデルを明示してリクエストする
完全なモデルID midjourney-v8.2 を使用します。SeedRouterではモデルの明示が必須です。midjourney と省略したり、別の画面のアカウント設定から推測したりしないでください。送信したリクエストとともにモデルも記録します。[1]
サーバー側で使用するAPIキーと、結果を確認しやすい短いプロンプトを用意します。最初は参照画像や親画像を使う操作を省き、基本的な処理を確認しましょう。以下のリクエストで、掲載したポートレートの画像セットを生成しました。Fastを選び、追加のコンテンツチェックを有効にしています。
{
"model": "midjourney-v8.2",
"prompt": "Cinematic portrait of a young woman with freckles and wind-swept auburn hair, wearing a cream cable-knit sweater, laughing on a coastal cliff at golden hour, warm rim light, shallow depth of field, 85mm film photograph",
"speed": "fast",
"nsfw_check": true
}最小のリクエストに必要なのは model と prompt だけです。速度を省略するとFastになります。size を追加する場合は、WIDTHxHEIGHT 形式のピクセル指定ではなく "16:9" のようなアスペクト比を使用します。汎用の画像クライアント設定で送られる 1024x1024、quality: "high"、任意の n は、このモデルの仕様に合いません。別のモデルの設定をそのまま流用せず、Midjourneyのフィールド表に合わせてリクエスト本文を調整してください。
一度だけ送信し、保存したタスクIDをポーリングする
ダウンロードできるPythonサンプルは標準ライブラリを使用し、キーを環境変数に保持して、受け付けられたタスクIDをローカルファイルに保存します。送信とポーリングには別々のコマンドを用意しています。この分離により、新しい画像生成ジョブを作らずに結果の取得を再開できます。
export SEEDROUTER_API_KEY='your-server-side-key'
python3 midjourney-v8-2.py submit request.json --state mj-task.json
python3 midjourney-v8-2.py poll --state mj-task.json上記のJSONリクエストを request.json として保存します。ローカル環境でサンプルのキーを自分の秘密キーに置き換えてください。ブラウザー用のコードに含めたり、リポジトリにコミットしたりしてはいけません。ローカルに配置した環境をテストする場合は、サンプルの SEEDROUTER_BASE_URL にその環境の /v1 ベースURLを設定します。
このサンプルは、送信時に既存の状態ファイルを上書きしません。また、接続に失敗してもPOSTを自動で繰り返しません。応答が失われると、アプリケーション側ではタスクが受け付けられたか判断できない場合があります。再送信を決める前に、タスク履歴を確認してください。
ポーリングは既に存在するタスクを読み取る操作です。サンプルはタスクが完了または失敗すると停止し、処理が続く場合には待機時間の上限に達したことを通知します。待機上限はクライアント側の観測結果であり、タスクを生成し直す必要がある証拠ではありません。
操作に応じた結果の形式を読み取る
画像を返す操作が完了すると、output.data にURLが含まれます。常に4件あると決めつけず、配列の各要素を処理してください。画像生成、1枚の選択、画像の説明、編集入力の段階では、異なる種類の結果が返る場合があります。
| 結果のフィールド | アプリケーションでの扱い |
|---|---|
status | 処理中、完了、失敗を区別します |
output.data[].url | 返された画像をそれぞれ表示または保存します |
output.grid | グリッドとして返された画像にその旨を表示します。1ファイルに複数の候補が含まれる場合があります |
output.text | 候補が4件であることや英語であることを前提にせず、返されたテキストを表示します |
output.seed | 存在する場合に記録し、すべての結果に含まれることは要求しません |
output.awaiting_input | 文書に記載された編集入力の手順を続けます |
タスクの読み取りに使ったHTTPリクエストが成功しても、失敗したタスクはアプリケーション側でも失敗として扱ってください。HTTPの成功は状態照会が処理されたことを示し、要求した画像が生成されたことを意味しません。
output.grid がtrueの場合、1つのURLにグリッドが含まれます。そのファイルから4つの個別URLを勝手に作らないでください。後続の選択操作では、グリッド内の1から始まる画像位置を使用します。URLの数と選択可能な候補数は同じとは限りません。
サンプルは完了した結果をJSONとして出力します。アプリケーション側で画像の保存、サムネイル、選択用の操作部品を追加できます。後続の操作で正しい親を参照できるよう、結果とタスクIDを一緒に保持してください。
競合を把握しながらネイティブパラメーターを扱う
この連携は、構造化フィールドと対応するネイティブ形式のプロンプトフラグを受け付けます。優先順位は構造化フィールド、extra、prompt 内のフラグの順です。明示したゼロやfalseも保持されます。
たとえば、--stylize 700 を含むプロンプトと "stylize": 0 を併用すると、明示したゼロが使われます。UIから独立した設定値を送る場合に便利ですが、プロンプトとJSONを別々の場所で組み立てるアプリケーションでは、予想外の結果につながることがあります。各設定の指定元は1つにそろえるとよいでしょう。
SeedRouterのV8.2リクエストでは、対応する組み合わせで quality に0.25、0.5、1、2を指定できます。Qualityと hd は独立した入力であり、qualityを設定してもHDは選択されません。両方や他の参照設定を追加する前に、現在の組み合わせの制限を確認してください。入力への対応が文書に記載されていても、すべてのバージョンでの効果が実証されたことにはなりません。Rawはこの2つとも別の設定です。Rawガイドで違いを説明しています。[1]
この連携では、未知のJSONフィールドは破棄され、未知のネイティブフラグは拒否されます。リクエストが受け付けられたことだけを根拠に、無関係な追加JSONフィールドが出力に影響したと判断しないでください。文書に記載されたフィールド名を確認し、送信した本文をそのままテスト記録に残します。
親画像を使う操作は元のタスクに関連付ける
後続の操作には、SeedRouterの parent_task_id を使用します。依存する操作は元の実行コンテキストに関連付けられたままです。そのコンテキストが利用できない場合、別の場所に親を作ることなく操作が失敗します。親は同じアカウントに属し、同じモデルを使用し、要求する操作に引き続き利用できる必要があります。公開APIの画像インデックスは1から始まります。
画像の選択とクリエイティブアップスケールは異なる操作です。select の結果を解像度の向上として説明してはいけません。同様に、バリエーション、リミックス、公式のV8.2 Edit Modelも、要件が異なる別々の機能です。
現在の連携では、新しいEdit Modelを検証済みのAPI操作として公開していません。従来のinpaintリクエストを代用し、同じ動作になると考えないでください。編集ガイドでは利用可能な代替手段と検証済みのV6.1マスク編集手順を説明し、APIリファレンスには実装済みの操作の制限を記載しています。
サムネイル数ではなくジョブ単位で見積もる
この連携の料金仕様では、完了した生成を1ジョブとして扱います。グリッドから既存の画像を選択しても、新たな課金対象の生成は発生しません。編集入力の段階に進んでも、2回目の生成料金は加算されず、最後のmodal操作が課金対象になります。4枚の画像生成が、自動的に4件の個別課金ジョブになるわけではありません。10月18日のV8.2 Draft検証では、1ジョブで24枚の画像が返されました。返された画像数だけで料金を計算するのは適切ではありません。
選択したバージョン、操作、速度、モードの現在の料金を使用します。親画像を使う操作では設定が継承される場合があるため、推測した既定値ではなく、実際に適用されるリクエストに基づいて価格を求める必要があります。モデルページは設定済みの料金を読み取り、このチュートリアルに固定のドル金額を埋め込んではいません。
受け入れテストでは、リクエスト、タスクID、最終状態、出力数、アカウントへの実際の請求額を記録してください。コンパイルの成功や模擬HTTPテストでは、これらの実行時の事実は確認できません。SeedRouterでは、失敗したリクエストには課金されません。
よくある質問
同じAPIキーをフロントエンドのJavaScriptで使えますか？
キーはサーバーで保持してください。ブラウザーからは認証されたアプリケーションのエンドポイントを呼び出し、そのエンドポイントがサーバー側のキーでリクエストを送信するようにします。
タスクIDが返ったら画像は完成していますか？
まだ完成していません。タスクが完了または失敗を報告するまで読み取り、対応する結果を処理してください。ポーリングを始める前にIDを保存します。
タイムアウトしたら新しく生成すべきですか？
自動で生成し直さないでください。判明しているタスクIDを保持し、既存のタスクを確認します。接続やクライアントの待機がタイムアウトしても、元の送信が拒否されたとは判断できません。
親画像を使う操作でバージョンを変えられますか？
この連携では親と同じモデルが必要です。別のバージョンを評価する場合は、新しい生成を別途開始してください。
Midjourney V8.2 APIの組み込みは、モデルを明示した1回のリクエストとタスクIDの保存から始めましょう。参照画像や一連の画像操作を追加する前に、返された出力と請求額を確認してください。
出典
仕様と実行結果の根拠は2026年10月18日に確認しました。掲載画像は有料の連携検証で得た出力であり、モデル全般のベンチマークではありません。