> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 画像理解リクエストがタイムアウトし続ける — 画像が大きすぎますか？

> GPTビジョンリクエストがハングする、429 upstream saturatedが返される、または400 patches exceeding the limitが発生する場合、画像が大きすぎる可能性が非常に高いです。ルートごとの制限、確認方法、およびリサイズコードについて説明します。

## 簡潔な回答

その可能性が極めて高いです。GPT モデルは画像を32×32ピクセルのパッチ単位で処理するため、画像が大きくなるほどパッチ数が増加します。単一の画像がおよそ**30メガピクセル**（例：6700×4500）を超えると、一部のルートでは即座に拒否されます。約**60メガピクセル**を超えると、ピーク時にはリクエストが**拒否される前に数分間キューに入ったままになる**ことが多く、クライアント側で先にタイムアウトが発生して、リクエストが「まったく応答しない」ように見えてしまいます。

これらの失敗は必然的に発生します。**再試行したり API キーを切り替えたりしても解決しません**。アップロードする前に、画像の長辺が約2048ピクセルになるようリサイズしてください。認識精度は変わらず、入力 tokens を元のほんのわずかな量まで削減できます。

## 3つの典型的な症状

サイズが大きすぎる同一の画像であっても、ルートや時間帯によって次のいずれかの形で失敗することがあります：

| 表示される現象 | エラーキーワード | 説明 |
| - | - | - |
| リクエストの応答が一切返らず、最終的にクライアント側でタイムアウトするか接続が切断される | なし（クライアント側にはタイムアウトのみが表示される） | プロバイダーがピーク時間帯にリクエストをキューイングし、約5分後に拒否しますが、その時点ですでにクライアント側の接続は切断されています |
| `429` 現在のグループのアップストリーム負荷が飽和 | `exceeds the maximum usage size allowed during peak load` | 単一のリクエストがピーク負荷時に許可されている使用量を超えています。これは同時実行数のレート制限ではありません |
| `400` 画像が上限を超過 | `requires 67081 patches after processing, exceeding the limit of 30000` | 処理された画像がパッチ数の上限を超えているため、リサイズが必要です |

> [!WARNING]
>
> `429` が表示されても、安易にリトライを増やさないでください。まずはエラーメッセージを確認してください。`maximum usage size` または `patches` が含まれている場合、リクエスト自体が大きすぎるため、リトライしても同時実行数を占有して待機し続けるだけです。

## テスト結果：画像サイズと結果

2026-10-20に、同じ画像を異なるサイズで `gpt-6.1-sol` に送信しました（JPEG、OpenAI互換のチャットエンドポイント上で `image_url` 経由でbase64としてアップロード）：

| 画像サイズ | ピクセル数 | リクエストボディ | 結果 | 所要時間 | 入力 tokens |
| - | - | - | - | - | - |
| 2048×1365 | 2.8 MP | 0.75 MB | 成功、すべてのテキストが正しく認識されました | 6秒 | 3,321 |
| 4096×2731 | 11.2 MP | 2.9 MB | 成功 | 10秒 | 13,228 |
| 6000×4000 | 24 MP | 6.2 MB | 成功 | 20秒 | 28,219 |
| 7200×4800 | 34.6 MP | 8.8 MB | 成功 | 26秒 | 40,519 |
| 9000×6000 | 54 MP | 13.7 MB | 成功 | 40秒 | 63,638 |
| 10240×6827 | 70 MP | 17.7 MB | **応答なし。約300秒後に接続が切断されました** | — | — |

ここからわかること：

* **tokens はピクセル数に比例して直線的に増加します**。おおよそ「ピクセル数 ÷ 1024 × 1.2」です。9000×6000の画像は2048バージョンの約19倍の tokens を消費しますが、認識結果は同じです。
* **大きな画像が処理を通るかどうかは、ルートと時間帯に依存します。** 上記の表は、オフピーク時に単一のルートで測定した結果です。別のルートでは画像1枚あたり30,000パッチ（約30メガピクセル）の厳格な制限が適用されており、ピーク時にはそのしきい値がさらに下がります。
* したがって、**「テストで通った」ことを安全な上限値とみなさないでください。** 画像理解においては、長辺が2048ピクセルあれば十分です。

## 画像が大きすぎるかどうかを判断する方法

**1. リクエストボディのサイズを確認する**

Base64エンコードを行うと、サイズは約1.33倍に膨らみます。リクエストボディが数MB、あるいは10MBを超えている場合、画像がリサイズされていない可能性が極めて高いです。

**2. エラーメッセージを確認する**

`patches`、`maximum usage size`、または`image exceeds`を検索してください。これらのいずれかが含まれている場合、画像が大きすぎることを意味します。

**3. リサイズした画像と比較する**

同じ画像の長辺を2048にリサイズして再送信してみてください。数秒以内にレスポンスが返ってくる場合、問題はモデルやネットワークではなく、画像のサイズにあります。

## 解決策：アップロード前にリサイズする

```python theme={null}
import base64, io
from PIL import Image

def image_to_data_uri(path, max_side=2048, quality=85):
    img = Image.open(path)
    img = img.convert("RGB")                      # normalize to RGB; handles PNG, MPO, etc.
    img.thumbnail((max_side, max_side))           # keep aspect ratio, longer side <= max_side
    buf = io.BytesIO()
    img.save(buf, "JPEG", quality=quality)
    return "data:image/jpeg;base64," + base64.b64encode(buf.getvalue()).decode()
```

戻り値を`image_url.url`に指定してください。リサイズ後、画像は通常数百KB程度になり、数秒以内に結果が返ってきます。

> [!TIP]
>
> 非常に小さな文字（ページ全体のスキャンにある脚注など）を読み取る必要がある場合は、巨大な元画像を1枚アップロードするのではなく、**ページを複数のタイルに分割して**個別にアップロードするか、必要な領域を切り取ってください。各タイルが安全な範囲内に収まり、多くの場合、認識精度も向上します。

## よくある質問

> **同じモデルが他のユーザーでは正常に動作するのはなぜですか？**
>
> ほとんどのユーザーがアップロードするスクリーンショットやスマートフォンの写真は、結果として数メガピクセル程度に収まります。リクエストごとの使用量制限に達するのは、数十メガピクセルの元画像がアップロードされた場合のみであるため、他のユーザーが同時に影響を受けることはありません。

> **これらの失敗に対して課金されますか？**
>
> プロバイダーによって拒否されたリクエスト（`429`、`400`）では消費記録は生成されません。これは利用ログで確認できます。

> **クライアントのタイムアウト時間を延ばせば解決しますか？**
>
> いいえ、解決しません。タイムアウトを延ばしても、プロバイダーがリクエストを拒否するまで待機することになるだけで、失敗することに変わりはありません。解決策は画像をリサイズすることです。

> **Claude、Gemini、およびその他のモデルにも制限はありますか？**
>
> はい、モデルごとに異なるルールがあります。Claude は 10 MB を超える単一画像を拒否し（同様に `429` が発生）、Kimi は 1 枚の画像が 16,384 tokens を超えるとエラーを返し、Seed は総ピクセル数を 36 メガピクセルに制限し、Gemini は自動的に縮小します。詳細は[画像理解](/ja/api-capabilities/vision-understanding)の「まずは大きな画像を縮小」セクションを参照してください。

## 関連ドキュメント

> **[ビジョン理解](/ja/api-capabilities/vision-understanding)**
>
> 各モデルへの画像送信方法、大容量画像の処理、およびテスト結果

> **[モデルAPIのエラーをトラブルシューティングするには？](/ja/faq/model-error-troubleshooting)**
>
> エラータイプ別に問題を特定

> **[APIタイムアウトを回避するには？](/ja/faq/timeout-configuration)**
>
> タイムアウト設定と長時間リクエストのトラブルシューティング

> **[APIの同時実行数制限とは？](/ja/faq/api-concurrency)**
>
> 実際の同時実行数制限とその他の429エラーを見分ける


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.