Copilot Designer／Bing Image Creator で、生成待ちのジョブが無いのに「You can’t submit any more prompts」と表示されて詰まるケースが散見されます。本記事は再現条件・最速の解除方法・再発防止の運用までを実務目線で整理し、無料／有料（Copilot Pro）を問わず役立つ具体的な手順とチェックリストを提供します。
症状の概要
プロンプトを送信しようとすると、以下のエラーが表示され、以降の送信ができなくなります。
You can't submit any more prompts
Please wait until your other ongoing creations are complete before trying to create again.
- 実際には「Creations（履歴）」に新規ジョブが見当たらない、または全て完了しているのに発生する。
- ページの再読み込み（F5）や「Explore Ideas／Creations」タブの頻繁な往復の直後に起きやすい。
- 無料ユーザーだけでなく、Copilot Pro（有料）契約者でも発生報告がある。
- キャッシュ／Cookie／閲覧履歴の削除、デバイスやネットワークの変更では改善しないことが多い。
結論（最短での解除方針）
送信後はリロードや連打をせず、しばらく操作をやめて待つのが最も確実です。UI操作の連打により、同一プロンプトが内部的に重複送信され、バックエンド側の「同時生成スロット」を使い切ったように見えるためです。スロットは数分〜十数分で自然解放されることが多く、放置が効きます。
最短解除の手順（推奨）
- プロンプト送信後、そのタブは閉じずに5〜15分放置する（再読み込み／戻る操作は避ける）。
- 別タブで「Creations（履歴）」を開き、進捗／完了を確認する。
※ 直接URLが必要な場合は「designer.microsoft.com/history」のように開く（リンク化せずに記載）。 - 改善しなければ1〜3時間ほど間隔を空けて再試行する。
- 24時間以上継続する場合は、アプリの「ヘルプ → フィードバック」から日時・エラーメッセージ・再現手順を添えて送信する。
回答・解決策まとめ
| 種別 | 解決策・ポイント | 補足 |
|---|---|---|
| ★受け入れられた回答 | 操作を控えて待つ プロンプト送信後に「Explore Ideas／Creations」タブを頻繁に行き来したり、ブラウザの更新（F5）を連打すると、同一プロンプトが内部で蓄積されてロックが掛かる。入力後は別タブに移動するか、数分〜十数分放置してから「Creations」を開く。ブラウザの更新は避ける。 | 短時間に多数リクエストするとバックエンドが「同時生成中」と誤検知。Boost を使わない場合ほど起きやすい。 |
| その他の報告 | 別の Microsoft アカウントでログインしてみる／24時間ほど待つと自動解除される場合がある。 | 根本解決ではないが、アカウント単位のスロットリングの可能性が高い。 |
| 効果が薄い・未解決 | キャッシュ／Cookie／閲覧履歴の削除、デバイスやネットワークの変更。 | 端末依存ではなくサーバー側制限のため、多くの場合効果なし。 |
| 有料ユーザーの注意点 | Copilot Pro でも同様に制限が掛かることがある。Microsoft 365 / Copilot Pro サブスクリプションの返金・クレジット対応はサポート窓口依存で、手続き中にサブスクリプションが勝手に解約されたとのユーザー報告もある。 | 画像生成に対する優先度や “100 Boost/日” が常に保証されるわけではない。 |
なぜ起きるのか（技術的背景の理解）
このエラーの本質は、サーバー側の同時生成スロット／日次クォータの消費が「UI上の状態」とズレることにあります。Copilot の画像生成は Azure 上のGPUリソースを共有し、ユーザー／アカウントごとに同時実行数（スロット）と短時間あたりの送信回数（スロープ制限）が管理されています。
- タブ往復や再読み込み、送信ボタンの連打により、同一プロンプトが重複送信され、スロットが一時的に占有される。
- UIは失敗（または保留）と認識しても、バックエンド側ではジョブが残留し、しばらく「同時生成中」の状態が続く。
- Boost を使わない通常キューでは、GPU割り当ての待ち時間が長くなり、残留の影響が表面化しやすい。
起きやすい操作と回避策
| 起きやすい操作 | なぜ悪いか | 推奨の置き換え |
|---|---|---|
| 送信後にF5を連打 | 同一リクエストが再送され、スロットが重複占有される。 | 送信したタブはそのまま放置、別タブで履歴だけを見る。 |
| Explore ↔ Creations を高速に往復 | 履歴のプリフェッチが重複し、内部状態がズレやすい。 | Creations は数分後に1回だけ開く。 |
| 連続プロンプトの投入（間隔1分未満） | 短時間のスロープ制限（rate limit）に引っかかる。 | 最低でも3〜5分空ける。大量投入はバッチで時間分散。 |
| 拡張機能／自動翻訳の常時書き換え | 入力欄への介入で二重送信が発生することがある。 | 発生時は拡張を一時停止して検証。常用時は1セッション1タブ。 |
トラブルシューティング（保存版）
標準手順（個人利用）
- 発生時刻をメモ（ローカル日時・タイムゾーン）。
- 問題のタブは閉じずに5〜15分放置。ページ遷移・リロードはしない。
- 別タブで「Creations（履歴）」を開いてステータス確認。履歴に同一プロンプトが複数ある場合は自然完了を待つ。
- 未解決なら1〜3時間空けて再試行。間隔内は送信を控える。
- 24時間を超えて継続する場合は、アプリの「ヘルプ → フィードバック」から報告する。
チーム・業務利用向けの追加手順
- 同じアカウントを複数人で同時利用しない（アカウント単位のスロットリングを避ける）。
- 自動化ツールから叩く場合は指数バックオフ（3分→6分→12分…）を必須化し、最大同時送信数を1に固定。
- プロンプト投下の「間引き」ルール（1時間あたりN件）をチーム標準にする。
サポートに送ると伝わりやすい情報テンプレ
・発生日時／タイムゾーン：
・アカウント種別：無料 or Copilot Pro
・表示されたエラーメッセージ（原文）：
・再現手順（送信→F5→タブ往復 など）：
・発生頻度（回／日）：
・試した対処（待機時間・別端末・Cookie削除など）：
・Creations の状態（同一プロンプトの重複有無）：
「効きやすい」対処と「効きにくい」対処の見極め
| 分類 | 対処 | 期待値 | 理由 |
|---|---|---|---|
| 効きやすい | 送信後の放置（5〜15分）→再試行 | 高 | 内部に残ったジョブが自然に解放されるのを待つ。 |
| 効きやすい | 別タブで履歴のみ確認 | 中 | 問題のタブを動かさず、重複送信を避ける。 |
| 条件次第 | 別の Microsoft アカウントで試す | 中 | アカウント単位のスロットリングに当たっている場合は回避できる。 |
| 効きにくい | Cookie／キャッシュ削除、端末・回線変更 | 低 | 多くはサーバー側のスロット管理・キュー残留が原因。 |
Copilot Pro（有料）ユーザーの注意点
- 同様の制限は発生し得る：Boost（優先枠）や日次上限の表示があっても、瞬間的な混雑や内部不整合でスロットが埋まることがある。
- 返金・クレジットは窓口依存：対応内容や可否はサポート判断。進行中にサブスクリプションが意図せず解約されたというユーザー報告もあるため、手続きは慎重に。
- 業務影響の回避策：重要案件は時間に余裕を持ち、代替手段（外部の生成サービスや自社GPU推論）を併用する。
大量生成が必要なユーザー向けの設計指針
- アカウント分散：無料枠でも解像度やモデル品質は実運用で許容できるケースが多い。注意：利用規約と社内ポリシー順守。
- サードパーティの併用：DALL·E API直契約や他社ツールの併用でピーク負荷を回避。
- ジョブキュー化：内部ジョブキューで投入をスロット数に合わせて制御、指数バックオフで衝突を低減。
追加の補足（筆者による考察）
- サーバー側の同時生成上限
Copilot の画像生成はクラウドGPUを共有し、ユーザーごとの同時ジョブ数や日次クォータがある。エラーはこれらのカウンタの不整合でも発生する。 - トラブルシューティング手順（推奨）
- プロンプトを送信したタブを閉じずにそのまま放置（5〜15分）
- 別タブで
designer.microsoft.com/history（Creations 直接URLの表記例）を開き、ジョブ完了を確認 - 改善しなければ 1〜3 時間以上間隔を空け再試行
- 24時間以上継続する場合は ヘルプ → フィードバック から日時とエラーメッセージを添えて送信
- 大量生成が必要なユーザー向け対策
- 複数アカウント運用（無料プランでも解像度・モデルは近似）
- 外部生成サービス（例：DALL·E API、Midjourney など）との併用で業務を分散
よくある質問（FAQ）
Q. 履歴にジョブが無いのに「同時生成中」と言われます。なぜ？
A. UIに出ない内部キューや、失敗後の残留ジョブがスロットを占有している可能性が高いです。最初は5〜15分の放置で解消することが多いです。
Q. シークレットウィンドウなら回避できますか？
A. 一時的に回避できることがありますが、サーバー側スロットが原因なら根本解決になりません。
Q. 送信間隔はどのくらいが安全ですか？
A. 個人利用なら3〜5分間隔を目安に。業務用途で長文・高解像度が続くときはさらに余裕を。
Q. 同時に複数タブで生成しても大丈夫？
A. 推奨しません。1アカウント＝1タブ運用が安全です。
Q. Boost を使えば常に避けられますか？
A. Boostは優先度を上げますが万能ではありません。混雑時は詰まることがあります。
実務に効くベストプラクティス
- 1セッション1タブ：同一アカウントで複数タブ生成は避ける。
- 送信はワンクリックのみ：確定後は連打しない、進捗は別タブで確認。
- 投入をバーストさせない：ポスト間隔3〜5分、バッチは時間分散。
- 拡張機能の影響を検証：発生時はいったん停止。
- 落ち着いた時間帯の活用：混雑時間の回避で成功率を上げる。
関連エラーの見分け方
| エラー | 典型的な原因 | 対処の方向性 |
|---|---|---|
| You can’t submit any more prompts | 同時生成スロットの占有、残留ジョブ、短時間のスロープ制限 | 放置→別タブで履歴確認→間隔を空けて再試行 |
| Rate limit reached / Too many requests | 短時間に多すぎる送信／自動化ツールの連続実行 | 指数バックオフと件数制御、送信間隔の拡大 |
| Your request was blocked | 内容ポリシー違反、ネットワークのセキュリティ制限 | プロンプト修正、企業ネットワーク設定の確認 |
再発防止のチェックリスト
- 送信後に5〜15分待機する運用をチームで徹底した。
- 履歴確認は別タブのみで行うルールにした。
- 自動化／バッチは最大同時実行1、指数バックオフを実装した。
- 同一アカウントの同時使用を禁止した。
- 月末・締切前など混雑が予想される時期は早めに作業を開始する。
行動指針（まとめ）
真因はサーバー側のスロットリングまたはジョブ残留。
最も確実なのは「プロンプト送信後は放置し、リロードを避ける」こと。
長時間解除されない場合は、別アカウントで回避しつつ、フィードバックで運用側へ情報提供しましょう。
付録：現場で使えるタイムライン例
| 経過時間 | やること | 目的 |
|---|---|---|
| 0分 | 発生時刻の記録、画面スクリーンショット（可能なら） | 後続調査とサポート報告に備える |
| 5〜15分 | 同一タブは放置、別タブで履歴のみ確認 | 残留ジョブの自然解放を待つ |
| 60〜180分 | 少数の再試行（ワンクリックのみ）、連続投入はしない | スロープ制限解消の確認 |
| 24時間 | ヘルプ → フィードバックで詳細を送付 | アカウント単位のスロットリングや不整合の調整を促す |
付録：プロンプト投入運用のひな形
// 1. 下書き → 送信（1回だけ）
// 2. タブは放置、別タブでCreationsを数分後に1回だけ開く
// 3. 完了したら次のプロンプトへ（間隔3〜5分）
// 4. エラー時は5〜15分待機 → それでもダメなら1〜3時間あける
// 5. 24時間継続時はヘルプから報告
最後に
このエラーは、ユーザー操作が悪いというより、UIとバックエンドの非同期性に由来する設計上の難しさが主因です。だからこそ、送信後は触らない・別タブで静観する・投入を分散するという「待つ技術」を身につけるだけで、体感の成功率は大きく上がります。業務上クリティカルなワークフローでは、代替ルートの併走やアカウント分散といったリスクヘッジも忘れずに。
コメント