メインコンテンツまでスキップ

Cursor で AWS Bedrock を使用する（BYOK）

AWS Bedrock BYOK in Cursor

BYOK（Bring Your Own Key）を使うと、Cursor の組み込みモデルルーティングではなく、すでに支払っているモデルプロバイダーを Cursor に向けることができます。AWS Bedrock は、すでに管理している AWS アカウントの背後で Anthropic Claude やその他のフロンティアモデルをホストするため、最も一般的な選択肢の 1 つです。本ガイドでは、BYOK とは何か、なぜ特に Bedrock なのか、Cursor での設定方法、請求とコスト管理の仕組み、そして遭遇する可能性が最も高いエラーの修正方法（紛らわしい「Invalid signature in thinking block is bound to a different conversation」を含む）を順に説明します。

BYOK とは何か、いつ使うか​

BYOK とは、自分自身のプロバイダー認証情報を提供し、消費したトークンに対してプロバイダーが直接あなたに請求することを意味します。Cursor では、モデルは依然として Cursor のインターフェースと機能を通じて実行されますが、推論リクエストは Cursor のものではなくあなたのアカウントに送られます。

一般的に次の場合に BYOK を望むでしょう:

  • すでにクラウド支出をコミットしている。 組織に AWS のコミットメントやエンタープライズ割引がある場合、モデルトラフィックを Bedrock 経由にすることで新たな費目を追加せずにその支出を使えます。
  • コンプライアンスが特定の境界を要求する。 Bedrock はデータをあなたの AWS アカウントとリージョン内に保ち、データレジデンシーとセキュリティレビューを簡素化します。
  • 調達が単一ベンダーを好む。 AWS 経由で購入する方が、契約に別の AI ベンダーを追加するより簡単なことが多いです。

BYOK が常に安いとは限りません。Cursor の含まれる料金と使用量ベースの料金は小規模チームでは Bedrock を上回ることがあり、クォータ管理を自分で担うことになります。BYOK は価格のためだけでなく、制御とコンプライアンスのために選んでください。

BYOK はチャットごとではなくモデルプロバイダーごとです

Cursor では Settings > Models でプロバイダーを有効にします。Bedrock を有効にして認証情報を保存すると、選択した Bedrock モデル ID がモデルを選ぶあらゆる場所で選択可能になります。他のモデルで Bedrock に縛られることはありません。

BYOK と Cursor の組み込みルーティング​

契約する前に、2 つの経路を並べて見ると役立ちます。

観点Cursor の組み込みモデルBedrock での BYOK
請求Cursor があなたに請求AWS があなたに直接請求
認証情報Cursor が管理あなたが AWS キーを提供しローテーション
クォータCursor が管理あなたがモデルごとのクォータを管理
コンプライアンスCursor の境界あなたの AWS アカウントとリージョン
セットアップの手間ゼロIAM、モデルアクセス、プロバイダー設定
モデル一覧Cursor がキュレーションあなたのリージョンが公開するもの

速度のために最適化する個人開発者なら、組み込みルーティングにとどまってください。AWS の請求、リージョン、IAM ポリシーのすべてが自分たちのものでなければならない組織にいるなら、BYOK が正解です。

なぜ AWS Bedrock なのか​

Bedrock はホスト型の推論レイヤーであり、モデルそのものではありません。Anthropic Claude、Amazon Nova、Meta Llama、Mistral などを単一の AWS API を通じて公開します。その単一の API こそが、エンタープライズ利用で魅力的である理由です。

  • コンプライアンスとガバナンス。 リクエストとデータは、既存のコントロールと監査ログの下、あなたの AWS アカウントとリージョン内に留まります。
  • 既存の AWS 支出。 モデル利用は AWS の請求に現れ、既存のコミットメントで賄えます。
  • データレジデンシー。 リージョンを自分で選べます。規制がデータを国内に留めることを要求する場合に重要です。
  • エンタープライズ調達。 AWS はほとんどの大組織ですでに承認されたベンダーです。

トレードオフは裏返しです。クォータ、IAM の設定、トラブルシューティングはあなたが担います。

前提条件​

Cursor を設定する前に、AWS 側で次のものを整えてください。

AWS アカウントとモデルアクセス​

請求が有効な AWS アカウントが必要です。Bedrock コンソールではモデルアクセスはモデルごとにオプトインであるため、使用する予定の Anthropic Claude モデルへのアクセスを明示的にリクエストする必要があります。自動的に付与されるモデルもあれば、同意ステップや短いユースケースフォームが必要なものもあります。

IAM 権限​

依然として機能する中で最も狭い権限を持つ IAM ユーザーまたはロールを Cursor 用に作成してください。最低限、Cursor はモデルを呼び出し、それらを一覧する必要があります。

IAM 権限Cursor が必要とする理由
bedrock:InvokeModel非ストリーミングリクエストをモデルに送信する
bedrock:InvokeModelWithResponseStreamストリーミングリクエストを送信する。これはチャット UI が使用するもの
bedrock:ListFoundationModelsモデルピッカーを埋め、モデル ID を検証する

Bedrock 上の Claude モデルでは、通常 bedrock:InvokeModel をモデル ARN に、あるいはもっと簡単にはリージョンの推論プロファイルにスコープした権限も必要です。ポリシーはスコープを限定し、広範な管理者ポリシーを付けないでください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CursorBedrockInvoke",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-v1:0",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0"
      ]
    },
    {
      "Sid": "CursorBedrockList",
      "Effect": "Allow",
      "Action": "bedrock:ListFoundationModels",
      "Resource": "*"
    }
  ]
}

このポリシーは、既存の管理者アイデンティティを再利用するのではなく、Cursor 専用の IAM ユーザーまたはロールに付けてください。組織が短命の認証情報を使う場合、静的キーを作成するのではなく、ロールを引き受けてセッショントークンを定期的に更新してください。

Cursor を設定する前にアクセスを検証する​

まずコマンドラインから認証情報が機能することを証明してください。ここで呼び出しが失敗するなら Cursor でも失敗し、紛らわしい往復を避けられます。

# Confirm the configured identity is the one you expect
aws sts get-caller-identity

# List the models your region exposes
aws bedrock list-foundation-models \
  --region us-east-1 \
  --query "modelSummaries[?contains(modelId, 'anthropic')].[modelId]" \
  --output table

一覧は成功するのに呼び出しが失敗する場合、問題は認証情報ではなくモデルアクセスまたは特定のモデル ID です。

リージョンの選択​

望むモデルが利用でき、データを置くことが許可されているリージョンを選んでください。一部のモデルでは推論プロファイルのプレフィックスを通じてクロスリージョン推論がサポートされているため、単一のリージョンに限定されないかもしれません。

Cursor で Bedrock を設定する​

Cursor は Models 設定で BYOK プロバイダーを公開しています。フローはどのプロバイダーでも同じ形です。

  1. Cursor Settings > Models を開きます。
  2. AWS Bedrock プロバイダーを見つけて有効にします。
  3. AWS アクセスキー ID、シークレットアクセスキー、リージョンを入力します。
  4. ピッカーに表示したいモデル ID を選択します。
  5. 保存してチャットに戻り、Bedrock モデルを選択します。

認証情報フィールド​

Cursor にはリージョンを含む設定が必要です。Bedrock プロバイダーブロックはおおよそ次のようになります:

{
  "provider": "bedrock",
  "aws_access_key_id": "AKIAIOSFODNN7EXAMPLE",
  "aws_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "aws_region": "us-east-1",
  "models": [
    "anthropic.claude-sonnet-4-5-v1:0",
    "anthropic.claude-3-5-haiku-v1:0"
  ]
}

開発者マシンでは、長命の IAM アクセスキーは最後の手段として優先してください。チームでは、キーがディスク上に平文で保存されないよう、一時セッションや引き受けたロールを使用してください。

モデル ID とクロスリージョン推論​

Bedrock のモデル ID は予測可能な形に従います。ベンダー、ファミリー、バージョンです。一部のモデルは推論プロファイルのプレフィックスを必要とし、可用性とスループットのためにリクエストをリージョン間でルーティングします。

# Direct model IDs (region-scoped)
anthropic.claude-sonnet-4-5-v1:0
anthropic.claude-3-5-haiku-v1:0

# Cross-region inference profile IDs (note the region prefix)
us.anthropic.claude-sonnet-4-5-v1:0
eu.anthropic.claude-sonnet-4-5-v1:0
apac.anthropic.claude-sonnet-4-5-v1:0

有効にしたのにモデルがアクセスエラーを返す場合、ほぼ常にモデル ID が原因です。選択したリージョンで us. や eu. のプレフィックスが必要かどうかを確認してください。

アクセスキーはシークレットです

アクセスキーをチャット、ルールファイル、共有スクリーンショットに貼り付けないでください。Cursor がプロバイダー認証情報を保存する場所に保管し、漏洩した疑いのあるキーはローテーションしてください。上記の例のキーは AWS の公開ドキュメンテーションのプレースホルダであり、実際の認証情報ではありません。

Cursor での接続の検証​

プロバイダー設定を保存したら、実際のタスクではなく些細なプロンプトで配線を確認し、失敗があいまいでないようにしてください。

  1. 新しいチャットを開き、モデルピッカーから Bedrock モデル ID の 1 つを選択します。
  2. 「reply with the word ready」のような小さなものを求めます。
  3. 応答が返れば、認証情報、リージョン、モデル ID はすべて正しいです。
  4. 失敗する場合は、以下の CLI 呼び出しテストを再実行し、エラーテキストを Cursor が表示するものと比較します。
# Invoke the model directly so you can see the raw error text
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-sonnet-4-5-v1:0 \
  --region us-east-1 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":16,"messages":[{"role":"user","content":"reply with the word ready"}]}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/out.json && cat /tmp/out.json

使用するモデルごとに動作する CLI コマンドを保持しておくと、成功する呼び出しがどのようなものかすでにわかっているため、Cursor のエラーメッセージがあいまいなものから解読可能なものになります。

請求とコスト管理​

BYOK では、AWS がトークンに対してあなたに請求し、Cursor ではありません。それにより予算の組み方と監視の仕方が変わります。

モデルの価格​

Bedrock は入力トークンと出力トークンごとに課金し、料率はモデルによって異なります。入力トークンは一般に出力トークンより安く、ロングコンテキストモデルは小さいものよりトークンあたりのコストが高くなります。

モデルファミリー相対的な入力コスト相対的な出力コスト備考
Claude Sonnet クラス中中強力な一般的コーディングのデフォルト
Claude Haiku クラス低低高速で安価、小さな編集に適する
Claude Opus クラス高高最高の推論、最高コスト
Amazon Nova低低コスト効率の良い代替

コスト配分と監視​

Bedrock の使用量にタグを付けて帰属可能にし、請求書ではなくメトリクスを監視してください。

# Enable cost allocation tags on the resources that call Bedrock
aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0 \
  --tags Project=cursor-byok Team=platform

CloudWatch で Bedrock の呼び出しメトリクスを追跡し、暴走したエージェントが一晩で静かに月次予算を使い果たさないよう請求アラームを設定してください。

# Quick cost sanity check: list recent Bedrock usage with Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-10-20 \
  --granularity DAILY \
  --metrics BlendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Bedrock"]}}'

トークンコストを削減する​

BYOK はトークンメーターをあなたの手に委ねるため、いくつかの習慣がすぐに報われます:

  • モデルを適切にサイズ調整する。 小さな編集には Haiku クラスのモデルを使い、Opus クラスのモデルは本当に難しい推論のために取っておいてください。
  • コンテキストをタイトに保つ。 肥大化したコンテキストウィンドウは最大の隠れたコストです。スレッドがそれたら新しいチャットを始めてください。
  • 小さな編集をまとめる。 いくつかの小さなプロンプトは、同じ変更をカバーする 1 つの範囲を定めたプロンプトより高くつきます。
  • ルールを削る。 常時適用されるルールはすべてリクエストごとに送られるトークンなので、.cursor/rules はスリムに保ってください。
  • 最初の 1 週間を監視する。 最初の 1 週間は Cost Explorer を毎日確認し、その後は週次にして、驚く前に本当のベースラインを把握してください。

「Invalid signature in thinking block」エラーの修正​

これは Cursor で最も紛らわしい Bedrock エラーです。API キーの問題のように聞こえますが、ほぼ常に会話状態の問題です。完全なメッセージは次のとおりです:

Invalid `signature` in `thinking` block is bound to a different conversation

根本原因​

Claude の拡張思考は、それが作成された正確な会話とターンに結び付けられた署名を運ぶ暗号化された推論ブロックを生成します。それらのブロックが新しいリクエストに再生されると、署名された内容が一致しなくなり、プロバイダーがリクエスト全体を拒否します。これは次の場合に発生します:

  • 以前のターンの拡張思考ブロックが後のターンで再送される、
  • プロキシやゲートウェイがリクエストボディをキャッシュして再生する、
  • 会話状態が古いか重複している。たとえばスレッドの途中でモデルを切り替えた後など。

修正​

次の順に進めてください:

  1. 新しいチャットを始める。 署名は会話に結び付けられているため、新しいチャットが信頼できるリセットです。
  2. デバッグ中はそのモデルの拡張思考を無効にする。 フローがクリーンになったら再有効化します。
  3. Cursor を更新する。 思考ブロックの署名処理は新しいビルドで修正されています。古いクライアントはよくある原因です。
  4. 中間プロキシやゲートウェイを削除する。 Cursor と Bedrock の間でリクエストボディをキャッシュまたは書き換える可能性があるものです。
  5. temperature を下げ、スレッドを短くする。 コンテキストに蓄積する思考ブロックを減らします。
まず新しいチャット、それから他すべて

10 回中 9 回は、新しいチャットを始めると署名エラーはすぐに解決します。真新しいチャットでも再現するなら、プロキシとクライアントのバージョンを確認してください。

スロットリングと resource_exhausted エラー​

Bedrock はアカウントごと、モデルごとのスループットクォータを適用します。それを超えると、クリーンな失敗ではなくスロットリングまたは resource_exhausted エラーが発生します。

ResourceNotFoundException / ServiceQuotaExceededException:
You have exceeded the rate of requests allowed for this model.

これは認証情報の問題ではなくクォータの問題です。2 つの修正:

  • モデルやリージョン間で負荷を分散する。 クロスリージョン推論プロファイルは、まさに容量をプールするために存在します。
  • クォータの引き上げをリクエストする。 使用している Bedrock モデルについて AWS Service Quotas コンソールで行います。
# List the Bedrock service quotas you can request increases for
aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'Claude')].[QuotaName,QuotaCode,Value]" \
  --output table

エラーはバーストトラフィックが収まれば自然に解消することが多いですが、慢性的な場合はクォータのリクエストが修正です。

アクセス、リージョン、プロキシのエラー​

モデルアクセスが付与されていない場合の Access Denied​

AccessDeniedException: You don't have access to the model with the specified model ID

ここでは 2 つの原因が支配的です:

  • モデルアクセスが Bedrock コンソールで一度も付与されていない。 コンソールを開き、その特定の Anthropic モデルへのアクセスをリクエストしてください。
  • IAM ポリシーが狭すぎるか、モデル ID が間違っている。 ポリシーが bedrock:InvokeModelWithResponseStream を付与していること、モデル ID 文字列が実際に有効にしたモデルと一致することを確認してください。

誤ったリージョン​

Cursor に設定されたリージョンがそのモデルをホストしていない場合、またはモデル ID がクロスリージョンのプレフィックスを必要とする場合、キーが有効でもリクエストは失敗します。Cursor のリージョンが、モデルアクセスを有効にしたコンソールのリージョンと一致することを確認してください。

企業プロキシ背後のストリーミング失敗​

ストリーミングはチャットのデフォルトです。企業プロキシや TLS 検査ファイアウォールはしばしば text/event-stream レスポンスを壊し、チャットがハングするか部分的な回答を返す形で現れます。

  • Bedrock のリージョナルエンドポイント（たとえば bedrock-runtime.us-east-1.amazonaws.com）をホワイトリストに登録してください。
  • プロキシがストリーミングレスポンスをバッファリングしないことを確認してください。「streaming」や「chunked transfer」の設定を探してください。
  • プロキシを避けられない場合、Cursor が Bedrock ホストに対してそれをバイパスできるかを確認してください。

トラブルシューティングのクイックリファレンス​

症状考えられる原因修正
thinking ブロック内の Invalid signature思考ブロックが会話をまたいで再生された新しいチャットを開始し、拡張思考を無効にし、Cursor を更新する
resource_exhausted / スロットリングモデルごとのクォータ超過リージョン間で分散し、クォータ引き上げをリクエストする
AccessDeniedExceptionモデルアクセスが付与されていない、またはポリシーが狭すぎるコンソールでモデルを有効にし、IAM ポリシーを広げる
あるリージョンでモデルが見つからない / アクセスできない誤ったリージョン、または推論プロファイルのプレフィックスの欠落リージョンを合わせ、us. / eu. プレフィックスを使う
チャットがハングしてストリーム出力がないプロキシが text/event-stream をバッファリングしているBedrock エンドポイントをホワイトリストに登録し、プロキシのバッファリングを無効にする
モデルピッカーが空bedrock:ListFoundationModels の欠落権限を追加し、認証情報を再保存する
キーローテーション後の認証エラーCursor に保存された古い認証情報Models 設定でアクセスキーとシークレットを再入力する
ローカルでは動作するが CI で失敗するパイプラインでリージョンやプロファイルが渡されていないCI 環境でリージョンとプロファイルを設定する

フローが安定したら、リージョン、モデル ID、クォータ制限の短いメモをプロバイダー設定の隣に残しておいてください。6 か月後にエラーが現れたとき、そのメモが 2 時間の調査を 2 分の修正に変えます。