翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon Bedrock API エラーコードのトラブルシューティング
<a name="troubleshooting-api-error-codes"></a>

このセクションでは、Amazon Bedrock API を使用する際に発生する可能性のある一般的なエラー、エラーの原因、およびエラーを解決するためのソリューションについて詳しく説明します。

## AccessDeniedException
<a name="ts-access-denied"></a>

**HTTP ステータスコード: **403

**原因: **リクエストされたアクションを実行するための十分なアクセス許可がありません。

**解決策:**
+ IAM ユーザーまたはロールが、実行しようとしているアクションに必要なアクセス許可を持っていることを確認します。
+ 一時的なセキュリティ認証情報を使用している場合は、有効期限が切れていないことを確認してください。

## FTUFormNotFilled
<a name="ts-ftu-form"></a>

**HTTP ステータスコード: **404

**原因: **このアカウントのモデルユースケースの詳細が送信されていません

**解決策:**
+ モデルを使用する前に、Anthropic ユースケースの詳細フォームに記入してください。

## IncompleteSignature
<a name="ts-incomplete-signature"></a>

**HTTP ステータスコード: 400**

**原因:** リクエスト署名が AWS 標準に準拠していません。

**解決策:**
+ Amazon Bedrock をサポートする AWS SDK バージョンを使用していることを確認します。
+  AWS アクセスキー ID とシークレットキーが正しく設定されていることを確認します。
+ リクエストに手動で署名する場合は、署名の計算プロセスを再確認することをお勧めします。

## InternalFailure
<a name="ts-internal-failure"></a>

**HTTP ステータスコード: **500

**原因: **サーバーエラーによりリクエスト処理が失敗しました

**解決策:**
+ 信頼性を向上させるために、[エクスポネンシャルバックオフとランダムジッターで再試行](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)を使用する AWS 推奨アプローチを採用することをお勧めします。 [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ 問題が解決しない場合は、[AWS サポートセンター](https://aws.amazon.com/support)に連絡して、リクエストの詳細と発生しているエラーをお知らせください。

## InvalidAction
<a name="ts-invalid-action"></a>

**HTTP ステータスコード: 400**

**原因: **リクエストされたアクション、またはオペレーションは無効です。

**解決策:**
+ リクエスト内のアクション名のスペルとフォーマットを再確認することをお勧めします。
+ アクションの呼び出しが Amazon Bedrock でサポートされており、[Amazon Bedrock API リファレンス](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_Operations.html)で示されているように正しく文書化されていることを確認します。
+  AWS SDK または CLI up-to-dateを使用していることを確認します。

## 無効なクライアントトークンID
<a name="ts-invalid-client-token"></a>

**HTTP ステータスコード: **403

**原因: **指定された X.509 証明書または AWS アクセスキー ID がレコードに存在しません。

**解決策:**
+ 正しい AWS アクセスキー ID を使用していることを確認します。
+ 最近新しいアクセスキーを作成した場合は、古い認証情報ではなく、新しい認証情報を使用していることを確認してください。

## AWS Marketplace 契約が 15 分以内に失敗
<a name="ts-mp-agreement-failed"></a>

**HTTP ステータスコード: **403

**原因: **根本的な問題により AWS Marketplace 契約が失敗しました。

**解決策:**
+ エラーメッセージを確認し、根本的な問題を修正します。よくある根本的な問題は、無効な支払いエラーと地理的な場所の制限です。
+ 無効な支払いエラーについては、Amazon Bedrock でモデルアクセスをリクエストした後[、 AWS Marketplace と INVALID\_PAYMENT\_INSTRUMENT を使用する AISPL のお客様のクレジットカードおよびデビットカード購入の制限](https://aws.amazon.com/blogs/awsmarketplace/restriction-on-credit-and-debit-card-purchases-for-aispl-customers-using-aws-marketplace/)を確認してください。 [https://repost.aws/questions/QU0UOsutrWSSS4nOqgHcIUJg/invalid-payment-instrument-after-requesting-model-access-in-amazon-bedrock](https://repost.aws/questions/QU0UOsutrWSSS4nOqgHcIUJg/invalid-payment-instrument-after-requesting-model-access-in-amazon-bedrock)

## AWS 15 分後に保留中の Marketplace 契約
<a name="ts-mp-agreement-pending"></a>

**HTTP ステータスコード: **403

**原因: ** AWS Marketplace 契約は成功せず、リクエストが作成されてから 15 分が経過しています。

**解決策:**
+ 15 分ごとにリクエストを再試行します。問題が解決しない場合は、[AWS サポートセンター](https://aws.amazon.com/support)に連絡して、リクエストの詳細と発生しているエラーをお知らせください。

## MPAgreementBeingCreated
<a name="ts-mp-agreement-created"></a>

**HTTP ステータスコード: **403

**原因: **アカウントには、このモデルにアクセスする権限がありません。このモデルの AWS Marketplace サブスクリプションはまだ処理中です

**解決策:**
+ 15 分後に再試行します

## NotAuthorized
<a name="ts-not-authorized"></a>

**HTTP ステータスコード: 400**

**原因: **このアクションを実行するためのアクセス許可がありません。

**解決策:**
+ IAM アクセス許可を確認し、Amazon Bedrock リソースでリクエストされたアクションを実行するために必要な権限があることを確認します。
+ IAM ロールを使用している場合は、ロールに適切なアクセス許可と信頼関係があることを確認します。
+ アクセスを制限している可能性のある組織ポリシーまたはサービスコントロールポリシーがないか確認します。

## RequestExpired
<a name="ts-request-expired"></a>

**HTTP ステータスコード: 400**

**原因: **タイムスタンプの有効期限が切れたため、リクエストが無効になりました。

**解決策:**
+ システムクロックが信頼できるタイムソースと正しく同期されていることを確認します。
+ 異なるタイムゾーンからリクエストを行う場合は、タイムスタンプの不一致に注意してください。

## ServiceUnavailable
<a name="ts-service-unavailable"></a>

**HTTP ステータスコード: **503

**原因: **サービスは一時的にリクエストを処理できません。503 エラーは、サービスに高い需要または一時的な容量の制約があることを示します。これは、アカウントレベルのクォータまたはレート制限 (429 ThrottlingException を返す) とは関係ありません。

**解決策:**
+ 信頼性を向上させるために、[エクスポネンシャルバックオフとランダムジッターで再試行](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)を使用する AWS 推奨アプローチを採用することをお勧めします。 [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ 現在のリージョンで問題が解決 AWS リージョン しない場合は、別の に切り替えることを検討してください。リージョンによって負荷と可用性のレベルが異なる場合があります。
+ [クロスリージョン推論を使用して](https://docs.aws.amazon.com//bedrock/latest/userguide/cross-region-inference.html)、異なる 間でコンピューティングを使用して、計画外のトラフィックバーストをシームレスに管理します AWS リージョン。
+ スループット要件が高い場合は、ユースケースの[プロビジョンドスループット](https://docs.aws.amazon.com//bedrock/latest/userguide/prov-throughput.html)を調べることをお勧めします。

**ベストプラクティス**
+ エラー処理と再試行ロジックで、アプリケーションが 503 ステータスコードを適切に処理できることを確認します。
+ Service Health Dashboard で、 AWS サービスに影響を与える可能性のある発表された問題やスケジュールされたメンテナンスを確認します。

503 のエラーが頻繁に発生する場合、またはそれが業務に大きな影響を与える場合は、[AWS サポート](https://aws.amazon.com/support)に連絡して、特定のユースケースに合わせたサポートとガイダンスを受けてください。

## ThrottlingException
<a name="ts-throttling-exception"></a>

**HTTP ステータスコード: **429

**原因: **Amazon Bedrock のアカウントクォータを超えたため、リクエストが拒否されました。

**解決策:**
+ [ Service Quotas](https://docs.aws.amazon.com/general/latest/gr/bedrock.html#limits_bedrock) コンソールで Amazon Bedrock サービスクォータをチェックして、アカウントに割り当てられている制限について確認します。
+ 信頼性を向上させる[https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)ために、[エクスポネンシャルバックオフで再試行](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)を使用する AWS 推奨アプローチを採用することをお勧めします。
+ スループット要件が高い場合は、ユースケースの[プロビジョンドスループット](https://docs.aws.amazon.com//bedrock/latest/userguide/prov-throughput.html)を調べることをお勧めします。
+ ワークロードのトラフィックがアカウントクォータを超える場合は、アカウントマネージャーまたは [AWS サポート](https://aws.amazon.com/support)に連絡してクォータの引き上げを要求します。

## ValidationError
<a name="ts-validation-error"></a>

**HTTP ステータスコード: 400**

**原因: **入力が、Amazon Bedrock で指定された制約を満たしていません。

**解決策:**
+ API ドキュメントを確認して、必要なパラメータがすべて含まれ、正しくフォーマットされていることを確認します。
+ 入力値が許容範囲内にあるか、期待されるパターンに準拠していることを確認します。
+ 使用しているアクションの API リファレンスに記載されている特定の検証ルールに注意を払うことをお勧めします。

## ResourceNotFound
<a name="ts-resource-not-found"></a>

**HTTP ステータスコード: **404

**原因: **リクエストされたリソースが見つかりませんでした。

**解決策:**
+ リクエスト内のモデル ID、エンドポイント名、またはその他のリソース識別子が正しいことを確認します。
+ 主なリソースが見つからない場合は、代替モデルまたはエンドポイントを使用するフォールバックメカニズムを実装してください。

**ベストプラクティス**
+ [ListFoundationModels](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_ListFoundationModels.html) を使用して、使用可能な Amazon Bedrock 基盤モデルについて確認します。
+ ローカルリソースカタログを更新するには、定期的な同期プロセスの実装をお勧めします。

これらのソリューションを試した後も問題が続く場合は、[AWS サポート](https://aws.amazon.com/support)に連絡し、特定のユースケースに合わせたサポートとガイダンスを受けてください。

## 長時間実行接続またはアイドル接続での接続タイムアウトまたはリセット
<a name="ts-connection-timeout"></a>

**症状: **API コールは接続のリセットやタイムアウトで失敗します。特に、トラフィックが NAT ゲートウェイ、インターフェイス VPC エンドポイント、Network Load Balancer を通過する場合に、ストリーミング、拡張思考、大規模な推論レスポンスなどの長時間実行されるリクエストでは失敗します。また、アイドルプール接続がネットワークがサイレントに切断された後に再利用されると、コールドスタートレイテンシーが長くなることがあります (たとえば、アイドル期間後の最初の呼び出しには通常の数秒ではなく 70 秒以上かかる）。

**原因: **NAT ゲートウェイ、インターフェイス VPC エンドポイント、Network Load Balancer のアイドル接続タイムアウトは 350 秒に固定されています。この期間を超えて TCP 接続がアイドル状態のままである場合、クライアントに通知せずに接続が切断されます。クライアントは、次のリクエストまで切断された接続を検出しない場合があります。その時点で、接続を再確立する前に OS レベルの TCP 再試行またはタイムアウトを待つ必要があります。

**これが適用される場合:**
+ Amazon Bedrock へのポッドトラフィックが NAT ゲートウェイまたは VPC インターフェイスエンドポイントを介して出力される Amazon EKS または Amazon ECS で実行されているアプリケーション。
+ NAT ゲートウェイ、Amazon Bedrock のインターフェイス VPC エンドポイント、または Network Load Balancer の背後にある Amazon EC2 インスタンスで実行されるアプリケーション。 Load Balancer
+ Amazon Bedrock クライアント接続が通話間の接続プールでアイドル状態になっている長時間稼働またはバーストワークロード。

**解決策:**

Amazon Bedrock クライアントで TCP キープアライブを有効にするには、2 *つの*設定が連携する必要があります。1 つだけ設定するだけでは不十分です。

1. **AWS SDK クライアントで TCP キープアライブを有効にします。**boto3 `Config` オブジェクトは、デフォルトで である `tcp_keepalive`パラメータを受け入れます`False`。Amazon Bedrock クライアントを構築する`True`ときは、 に設定します。

   ```
   import boto3
   from botocore.config import Config
   
   config = Config(tcp_keepalive=True)
   client = boto3.client("bedrock-runtime", config=config)
   ```

   その他の AWS SDKs、対応する HTTP クライアント設定ドキュメントを参照してください。

1. **OS レベルのキープアライブ間隔を設定して、350 秒のアイドルタイムアウトの前に起動します。**Linux のデフォルトは `net.ipv4.tcp_keepalive_time = 7200` (2 時間) で、NAT または VPC エンドポイントのアイドルタイムアウトよりもはるかに長いため、SDK レベルのキープアライブだけでは効果がありません。カーネル設定を安全に 350 秒 (45 秒など) 未満の値に下げます。

   ```
   sysctl -w net.ipv4.tcp_keepalive_time=45
   ```

   Amazon EKS および Amazon ECS では、ポッドまたはタスク 、init コンテナ`securityContext`、またはカスタムノード AMI に sysctl を適用します。Amazon EC2 では、値を再起動後も保持`/etc/sysctl.d/`するように に設定します。

VPC ネットワークで長時間実行される TCP 接続の詳細については、 AWS Networking & Content Delivery Blog の[「Implementing long-running TCP Connections within VPC networking](https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-long-running-tcp-connections-within-vpc-networking/)」を参照してください。

両方の設定を適用した後も接続の問題が解決しない場合は、 [AWS サポート](https://aws.amazon.com/support)にお問い合わせください。