Claude Code Bedrock Mantleエンドポイントの使い方

Bedrock Mantleエンドポイントとは何か

Mantleは、Amazon BedrockでClaudeモデルを提供するエンドポイントの一つです。通常のBedrock接続がAmazon Bedrock独自のInvoke API形式でリクエストを送るのに対し、MantleはAnthropicのネイティブAPIと同じリクエスト・レスポンス形式でモデルを呼び出します。認証に使うAWS認証情報・IAM権限・awsAuthRefresh設定は通常のBedrock接続とまったく同じです。切り替わるのはAPIの形式とモデルIDの書式だけで、AWSアカウント側の契約や課金体系が変わるわけではありません。

Anthropic API形式をそのまま扱うツールやゲートウェイをBedrock経由でも使い回したい場合、Invoke API向けの変換層を挟まずに済むのがMantleを選ぶ理由になります。逆に、Bedrock標準のクロスリージョン推論プロファイルやaws bedrock系CLIの操作性をそのまま使いたいなら、通常のInvoke API接続で十分です。

Mantleを有効にする

AWS認証情報がすでに設定済みの状態を前提に、環境変数を2つ設定するだけでMantleへのルーティングが始まります。まだAWS側の認証を設定していない場合は、Claude Code Bedrockセットアップの/setup-bedrockウィザードで先にサインインを済ませておくと迷いません。

Claude CodeはAWSリージョンからMantleのエンドポイントURLを自動で組み立てます。v2.1.172以降、このリージョン解決は通常のBedrock接続(AWS_REGION → AWS_DEFAULT_REGION → AWSプロファイルのregion → us-east-1の順)と同じ優先順位で行われます。v2.1.171以前はAWS_REGIONのみを見るため、明示的に設定してください。カスタムエンドポイントやゲートウェイ向けにURLを上書きしたいときはANTHROPIC_BEDROCK_MANTLE_BASE_URLを使います。

設定後は/statusでプロバイダー行を確認します。Mantleが有効ならAmazon Bedrock (Mantle)と表示されます。この表示が出ない場合は環境変数がプロセスに渡っていないので、後述のつまずきやすいポイントを確認してください。

使えるモデルを選ぶ

Mantleのモデルカタログは、通常のBedrockカタログとは別に管理されています。モデルIDの書式も異なり、バージョンサフィックスの付かないanthropic.プレフィックス形式です。

利用できるモデルはAWSアカウントに何が許可されているかで決まり、追加のモデルIDはAWSからのオンボーディング資料に記載されています。想定しているモデルが使えない場合は、AWSアカウントチームにアクセス許可をリクエストする必要があります。/modelピッカーにMantleモデルを表示したいときは、設定ファイルのavailableModelsにIDを列挙します。このときanthropic.claude-haiku-4-5のようなMantle形式のIDと素のhaikuエイリアスは同じモデルファミリーに解決されるため、両方を残したい場合はバージョン付きのIDも一緒に列挙してください。

Invoke APIと併用する

Mantleで使えるモデルが、これまで使っていたモデルの全部をカバーするとは限りません。CLAUDE_CODE_USE_BEDROCKとCLAUDE_CODE_USE_MANTLEを両方設定すると、同じセッション内で両方のエンドポイントを呼び分けられます。

Mantle形式のモデルIDはMantleへ、それ以外はAmazon Bedrock Invoke APIへ自動的にルーティングされます。両方が有効なとき、/statusはAmazon Bedrock + Amazon Bedrock (Mantle)と表示します。

ゲートウェイ経由でルーティングする

組織が集中管理のLLMゲートウェイでAWS認証情報をサーバー側から注入している場合、Claude Code側のクライアント認証を無効化できます。CLAUDE_CODE_SKIP_MANTLE_AUTHを設定すると、SigV4署名やx-api-keyヘッダーを付けずにリクエストを送るようになります。

Mantle専用の環境変数は次の4つです。

Mantleでの1Mトークンコンテキストウィンドウ

Claude Sonnet 5・Opus 4.6以降・Sonnet 4.6は、Amazon Bedrockで1Mトークンのコンテキストウィンドウに対応しています。Sonnet 5はInvoke APIとMantleエンドポイントのどちらでも常に1Mウィンドウで動作し、選択のための[1m]バリアントは存在しません。Invoke APIでは、1M対応のモデルバリアントを選んだときに拡張コンテキストウィンドウが自動的に有効になります。

セットアップウィザードでモデルをピン留めする場合は1Mコンテキストのオプションが提示されますが、手動でピン留めしたモデルには末尾に[1m]を追加する形で有効化します。長いコードベース全体をコンテキストに載せたい用途でMantleを選ぶ場合、この挙動の違いを事前に把握しておくと変換作業のやり直しを避けられます。

つまずきやすいポイント

/statusを確認してもAmazon Bedrock (Mantle)と表示されない場合、CLAUDE_CODE_USE_MANTLEがプロセスに届いていません。claudeを起動したシェルでexportされているか、設定ファイルのenvブロックに書かれているかを確認してください。

有効な認証情報のまま403が返る場合は、リクエストしたモデルへのアクセスがAWSアカウントにまだ許可されていません。AWSアカウントチームへのアクセス申請が必要です。AWS_BEARER_TOKEN_BEDROCKでAPIキー認証している場合は、AWS_BEARER_TOKEN_BEDROCKとはで認証変数自体の設定ミスも切り分けられます。

モデルIDを名指しした400エラーが出る場合、そのモデルがMantleでは提供されていません。MantleはBedrock標準カタログとは別のモデルラインナップを持つため、us.anthropic.claude-sonnet-4-6のようなクロスリージョン推論プロファイルのIDはMantleでは通りません。Mantle形式のIDに直すか、Invoke APIとの併用設定でモデルごとに適切なエンドポイントへ振り分けてください。

Mantle対応はv2.1.94から何を直してきたか

MantleはClaude Code v2.1.94で追加された比較的新しい機能で、その後の版で認証・キャッシュ課金まわりの修正が続いています。運用中に古いバージョンを使っている場合、ここに該当する不具合が残っている可能性があります。

v2.1.211の課金回帰は、Amazon Bedrock・Google Cloud's Agent Platform(Vertex)・Mantle・Microsoft Foundryの4系統すべてに影響していた点で目立ちます。Mantle単体の不具合というより、サードパーティプロバイダー全体に共通する実装を経由していたことがうかがえます。

まとめ

Bedrock Mantleエンドポイントは、Amazon Bedrockの契約・IAM権限をそのまま使いながら、Anthropicネイティブ形式のAPIでモデルを呼び出す経路です。CLAUDE_CODE_USE_MANTLE=1とリージョン設定だけで有効化でき、CLAUDE_CODE_USE_BEDROCKとの併用で段階移行もできます。モデルカタログとIDの書式がInvoke APIとは別物である点、ゲートウェイ経由では自前のカスタムURL構成が必要な点を押さえておけば、導入判断に迷いません。

よくある質問

MantleとInvoke APIでAWSの課金は変わりますか

公式ドキュメントはMantleとInvoke APIの課金体系の違いを明記していません。同じAWSアカウント・同じBedrockモデルカタログの契約を土台にしている点は共通です。Bedrock経由の料金構造自体はAWS BedrockのClaude料金は直接APIとどう違うかで確認できます。

Mantleは全リージョンで使えますか

Mantleのエンドポイントは設定したAWS_REGIONから組み立てられますが、モデルの提供リージョンはAWSアカウントへの許可状況に依存します。想定リージョンで対象モデルが使えるかは、AWSアカウントチームへの確認が確実です。

/modelピッカーにMantleモデルが出てきません

設定ファイルのavailableModelsにモデルIDを明示的に列挙していないと、Mantle形式のIDはピッカーの候補に出ません。anthropic.プレフィックス付きのIDを追加してください。

Mantleを無効化するとどうなりますか

CLAUDE_CODE_USE_MANTLEを外すかfalseにすると、CLAUDE_CODE_USE_BEDROCKが設定されていれば通常のInvoke API接続に戻ります。どちらも未設定の場合はBedrock自体が無効になります。切り替えのたびに/statusのプロバイダー行を見て、狙った接続先になっているかを毎回確認する習慣をつけておくと、環境変数の外し忘れによる意図しない接続を早期に見つけられます。