こんにちは！Works Human Intelligence の井上と申します。
早いもので AgentCore が GA されてから2カ月経とうとしていますね...！
はじめに
みなさんそれぞれいろんなエージェントを開発・運用されているかと思いますが、私も例に漏れずここ最近は AgentCore と向き合っている日々です。
先日 AgentCore のクォータ（≒制限）を参照していたのですが、よくよく読んでみるとセッション管理、デプロイサイズ、呼び出し制限等、きちんと認識しておいた方がよさそうなことがたくさん書かれていました。開発するにあたって事前に知っておくべきことがたくさんあったので、今日は AgentCore Runtime に絞っていくつか重要なものをピックアップしてまとめました。
Memory や Identity, Gateway といった他のサービスのクォータについては記事の分量の都合上、今回は触れていません。
これから AgentCore Runtime を使っていこうと考えている人はもちろん、既に使っている人も是非この機会に一緒に確認していきましょう！
AgentCore のクォータに関する公式ドキュメントはこちらになります。
- 記載内容に誤りがあればコメントで教えていただけると大変助かりますm(__)m
- 東京リージョンを対象に 2025/12/11 時点でのドキュメントに記載のクォータについてまとめています
- 特に明記されていない限り、各クォータはリージョン固有のクォータです
AgentCore Runtime のクォータ
リソース割り当ての制限
同時に実行できるエージェントのセッション数は最大500（調整可能）
runtimeSessionId ごとに1つのセッションとカウントされます。このため、たくさんのユーザーが同時にエージェントを利用するサービスでは、ピーク時にセッションを確保できなくなる可能性があります。
バージニア北部とオレゴンでは1,000、その他のリージョンでは500がデフォルトです。サポートチケット経由で引き上げリクエストが可能です。
アイドル状態のセッションもカウントされるので、セッションの適切なタイムアウト設定により不要なセッションを解放する設計が重要になります。
作成できるエージェントの数は最大1,000（調整可能）
テナントごとに Runtime を構築するような設計を採用する場合は注意が必要です。ただし、こちらもサポートチケット経由で引き上げリクエストが可能です。
1つの Runtime に作成できるバージョン数は最大1,000（調整可能）
Runtime は更新するたびに新しいバージョンが作成されます。CI/CD で頻繁にデプロイする運用だとバージョンが増加していきますが、非アクティブなバージョンは45日後に自動削除されるため、通常は上限を意識する必要はありません。
1つの Runtime に作成できるエンドポイント（エイリアス）数は最大10（調整可能）
エンドポイント（エイリアス）は prod、stg、dev のように、特定バージョンを指す論理名です。環境分離を細かくしすぎると上限に達する可能性がありますが、10個あれば通常の運用（prod / stg / dev +α）には十分だと思います。
Docker イメージの最大サイズは1GB（調整不可）
AgentCore Runtime へのデプロイ方法には「コンテナ展開（Container）」と「直接コード展開（Direct Code）」の2種類があります。コンテナ展開は自分でビルドした Docker イメージを使う方法で、カスタマイズ性が高い反面、イメージサイズの管理が必要になります。
| デプロイ方法 | 説明 |
|---|---|
| Container | 自分でビルドした Docker イメージを ECR にプッシュしてデプロイする方法。実行環境を完全にコントロールでき、Python 以外の言語も利用可能 |
| Direct code | Python コードと依存関係を ZIP にまとめて S3 経由でデプロイする方法。Docker の知識が不要で手軽だが、Python にのみ対応 |
実際に1GBを超えるサイズのイメージを指定して Runtime を作成しようとするとエラーになります。
このクォータは調整不可なので、設計段階で1GB以内に収める前提で考える必要があります。（あまりないかと思いますが）機械学習モデルをイメージに含めたり、ブラウザバイナリを含む Playwright のような大きな依存関係を含める際には注意が必要です。
.dockerignore でテストコードやドキュメントを除外する、マルチステージビルドでビルド時のみ必要なファイルを最終イメージから除外する、python:3.x-slim のような軽量ベースイメージを使用する、といった対策が有効です。
直接コード展開パッケージの最大サイズは圧縮時250MB / 非圧縮時750MB（調整不可）
直接コード展開（Direct Code）はサイズ制限がより厳しくなります。
圧縮状態で250MB、解凍後で750MBを超えるとデプロイできません。こちらも不要な依存関係の削除（pip install --no-deps の活用）や、__pycache__・テストコード・ドキュメントの除外が重要です。
このクォータも調整不可なので、超過しそうな場合はコンテナ展開への切り替えを検討する必要があるかもしれません。
最大ハードウェア割り当ては 2vCPU / 8GB（調整不可）
1つのセッション（microVM）が使用できる CPU・メモリの上限です。重い計算処理（大規模データ処理、画像処理など）をエージェント内で行おうとすると CPU が張り付いたり、OOM が発生したりする可能性があります。
このクォータも調整不可なので、重い処理は別途 Lambda や Fargate などの外部サービスにオフロードするアーキテクチャ設計が重要です。
Runtime 上で MCP サーバーを構築するときなども注意が必要になります。
呼び出し制限
リクエストタイムアウトは15分（調整不可）
同期リクエスト（InvokeAgentRuntime API）の最大実行時間です。15分を超えるとタイムアウトとなります。
複雑な推論や複数のツールを何度も呼び出すエージェントでは、処理時間が長くなりがちです。タイムアウトが懸念される場合は、非同期ジョブ（最大8時間）の利用を検討する必要があります。
15分を超えるとタイムアウトすることを確認するために 16分間 sleep してレスポンスを返却するエージェントを Runtime にデプロイし、InvokeAgentRuntime API で呼び出してみたのですが、15分経ってもレスポンスが返ってきませんでした...！
Runtime 上にデプロイしているエージェント
import time
from bedrock_agentcore import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
# 16 分間
SLEEP_SECONDS = 16 * 60
@app.entrypoint
def invoke(payload):
"""Sleep to trigger timeout."""
time.sleep(SLEEP_SECONDS)
# This should never be reached due to timeout
return {"result": f"Completed after {SLEEP_SECONDS} seconds"}
if __name__ == "__main__":
app.run()
呼び出し
aws bedrock-agentcore invoke-agent-runtime \
--agent-runtime-arn "${RUNTIME_ARN}" \
--runtime-session-id "${RUNTIME_SESSION_ID}" \
--payload "${PAYLOAD}" \
--region "${AWS_REGION}" \
--cli-read-timeout 1200 \
--cli-connect-timeout 60
最大ペイロードサイズは100MB（調整不可）
リクエストとレスポンスそれぞれの最大サイズです。大きなファイルをエージェントに渡したい場合や、エージェントから大きなデータを返したい場合に制約となる可能性があります。
100MB を超えるデータを扱う場合は、S3 を経由してファイルの URL やキーだけをやり取りするなどの工夫が必要になります。
ストリーミングの最大継続時間は60分（調整不可）
WebSocket 等を使ったストリーミング接続の最大持続時間です。同期リクエストの15分より長いため、長時間の対話が必要な場合はストリーミング接続の利用が有効です。
60分を超える継続的なやり取りが必要な場合は、接続を再確立する設計を検討してください。
非同期ジョブの最大実行時間は8時間（調整不可）
非同期で実行するジョブの最大実行時間です。同期リクエスト（15分）やストリーミング（60分）よりも長時間の処理が可能です。
大量のデータ処理やバッチ的なタスクをエージェントに実行させることができますが、その上限は8時間になります。8時間を超える処理が必要な場合は8時間以内に収まる単位にタスクを分割するか、AgentCore Runtime 外で実行する方法を検討する必要があります。
1秒あたりの呼び出し回数はエンドポイントあたり最大25（調整可能）
API 呼び出しのレート制限です。1つのエンドポイントに対して、秒間25リクエストを超えるとスロットリングされます。
多数のユーザーが同時にアクセスするサービスでは、この制限に達する可能性があります。サポートチケット経由で引き上げリクエストが可能なので、本番運用前に想定トラフィックを見積もっておくと良いでしょう。
スロットル制限
新規セッション作成の上限（調整可能）
新しいセッションを作成できる頻度に制限があります。デプロイ方法によって上限が異なります。
- コンテナ展開（Container）: 1分あたり100セッションまで
- 直接コード展開（Direct Code）: 1秒あたり25セッションまで
朝の業務開始時に一斉アクセスがあったり、イベントで急にトラフィックが増加したりすると、新規セッションの作成が追いつかなくなる可能性があります。
既存セッションの再利用（同じ runtimeSessionId での呼び出し）はこの制限に含まれないため、セッションを効率的に再利用する設計が重要です。
アイドルセッションタイムアウトは15分（調整可能）
セッションが何も処理をしていない状態が15分続くと、実行環境（microVM）が終了します。同じ runtimeSessionId で再度リクエストを送ると新しい環境が起動しますが、前のセッションで保持していたメモリ上のデータやファイルは失われます。
LifecycleConfiguration の idleRuntimeSessionTimeout パラメータで 1分〜8時間の範囲で調整可能です。短くすればセッションを早く解放でき、長くすれば断続的な利用でもコンテキストを維持しやすくなります。
最大セッション期間は8時間（調整可能）
1つのセッションが存続できる最大時間です。アクティブに使い続けていても、8時間経過すると強制終了します。
LifecycleConfiguration の maxLifetime パラメータで 1分〜8時間の範囲で設定可能です。デフォルトが最大値（8時間）なので、実質的には短くする方向でのみ調整できます。
おわりに
いかがでしたでしょうか。Docker イメージの最大サイズや同期リクエスト（InvokeAgentRuntime API）の最大実行時間などは他の基盤から AgentCore へ移行しようとする際などには注意が必要なポイントかと思います。
Memory や Identity, Gateway 等のクォータについては今回触れることができなかったので、別途まとめたいと思います。
クォータはしばしば厄介な存在と思われがちですが、最後にゲーテの残した言葉として広く知られている一節を引用して締めます。
In der Beschränkung zeigt sich erst der Meister.
— Johann Wolfgang von Goethe, Sonett „Natur und Kunst“（1800）, 『Gedichte』所収
（日本語訳）制限の中に初めて名匠は自らを示す
この言葉は創作や職能において「制約があるからこそ技量が浮かび上がる」というゲーテの思想を象徴する表現として、後世に多く引用されてきたそうです。素敵な言葉ですね。
最後までご覧いただきありがとうございました！