Skip to main content
よくある問題、パフォーマンス最適化、エラー処理のベストプラクティスをまとめています。接続前に一読することを推奨します。

タスク送信とポーリング

送信系のエンドポイントはすべて非同期タスクです。送信後に task_id が返り、その後 GET /v1/midjourney/{task_id} を定期的に照会してステータスを取得し、SUCCESS / FAILURE になるまで繰り返します。
  • ポーリング間隔:3〜5 秒に 1 回を推奨。これより高頻度にしても意味がなく、クォータの無駄になります。
  • web リクエスト内で同期的にブロックしてタスク完了を待たないでください。送信後はすぐに task_id を返し、フロントエンドで非同期にポーリングさせます。

Prompt 設計

良い prompt:
  • 主体を先頭に:まず主体、次にシーンの描写、最後に修飾語。
  • 構造化パラメータを明示--ar / --v / --s(または対応する body フィールド)を使う方が、デフォルト値に依存するよりも制御しやすくなります。
  • 曖昧な語を避けるphotorealisticrealistic よりも明確です。
避けるべきこと: 抽象的すぎる指定(“make it good”)、主体が散漫(複数の並列オブジェクトに主従の区別がない)、語に引用符を付ける(リテラル値として扱われます)。 Niji アニメ: niji: true + version: "7" を渡すと、プラットフォームが --niji 7 に正規化し、課金は midjourney@imagine-niji7 になります。

参照画像のベストプラクティス

  • 5 MiB 未満に圧縮:プラットフォームの上限は 12 MiB ですが、小さい画像の方が転送・処理ともに高速です。
  • 形式は PNG / JPG / WebP のいずれも可。高品質な JPG を推奨します。
  • 解像度は 1024〜2048 px で十分。それ以上は無駄になります。
  • 参照画像のウェイト iw(0〜3、既定 1):>1 で元画像に近づき、<1 でより自由になります。

エラー処理とリトライ戦略

二次操作のフロー

局部リペイント(inpaint → modal の 2 ステップ):
⚠️ inpaint が MODAL に入った後、30 分以内/modal を呼ぶ必要があります。そうしないとバックエンドが自動的に CANCEL + 返金します。

video の課金コントロール

  • 単一クリップ:batch_size: 1 → 1 × midjourney@video を消費
  • バッチ 4 クリップ:batch_size: 4 → 4 × midjourney@video を消費
  • 高解像度の単一クリップ:video_type: "vid_1.1_i2v_720" + batch_size: 1 → 1 × midjourney@video-720p を消費
推奨:完成品として 1 クリップだけ必要なら batch_size=1 を使い、バッチで比較検討する場合のみ 4 を使ってください。デフォルトで 4 を有効にしないこと(コストが N 倍になります)。

並行処理とスループット

  • プラットフォームには 1 分あたりの送信数に上限があり、超過すると 429 が返るためバックオフしてリトライしてください。
  • 実際の生成の並行数はシステム容量によって決まり、超過分はキューに入ります。タスクが長時間 SUBMITTED のままの場合、通常はキュー待ちです。
  • ポーリングには必ず sleep を入れ、sleep なしの無限ループにしないでください。

モニタリングの推奨

トラブルシューティングチェックリスト