Claude Platform on AWSがGAに。AWSエンジニアにとって何が嬉しいのか

こんにちは。

もるふぉです。

「Bedrockを使ってるけど、Anthropic本家の新機能がいつまでたっても来ない」「Anthropic直契約したいけど、経理が海外SaaSの新規稟議を通してくれない」——そういうもやもやを抱えながら仕事してきた方に、今日は朗報をお届けします。

Claude Platform on AWSが、2026年5月11日にGA（一般提供開始）になりました。

発表直後のタイムラインを見ていると「で、これBedrockと何が違うの？」「Anthropic直契約のときと何が変わるの？」という反応がやたら多いです。

正直、私も最初は「AWS経由でClaude叩けるようになるだけでしょ？」と流しかけました。

でも、ドキュメントを読み込んだ瞬間に評価が変わりました。

これ、AnthropicとAWSの両方を業務で使っている組織にとっては、地味どころかかなり大きな構造変化です。

具体的に何が嬉しいかは3つにまとまるんですが、結論を先に言うと「Anthropic直契約の手間が消える」「Bedrockより新機能が早く来る」「既存のAWSコミットメントで支払える」の3点です。

この記事では、AWS公式ブログとAnthropicの一次情報を突き合わせながら、「AWSエンジニア視点で何が嬉しいのか」を実務目線で整理します。

読み終わる頃には、自社で採用すべきか、Bedrockのままで十分か、自信を持って判断できる状態になっているはずです。

結論：Claude Platform on AWSの「何が嬉しいか」を先に整理する

回りくどい前置きはやめて、結論から行きましょう。

Claude Platform on AWSをAWSエンジニアが歓迎すべき理由は、たった3つです。

1. AnthropicネイティブAPIが、AWSアカウントの認証情報そのままで叩ける
2. Skills・Managed Agents・Files APIといった最新ベータ機能が、Anthropic本家と同じタイミングで使える
3. 既存のAWSコミットメント（事前購入枠）でClaudeの利用料を消化できる

公式の言い方を借りるなら、「Anthropicと別アカウント・別契約・別請求書は要らない（no separate credentials, contracts, or billing relationships required）」。

これがClaude Platform on AWSの本質です。

Introducing the Claude Platform on AWS | Claude

The Claude Platform on AWS is now generally available, offering a new way for AWS customers to access the full set of Claude platform features with AWS authentication, billing, and commitment retirement.

claude.com

Introducing Claude Platform on AWS: Anthropic’s native platform, through your AWS account | Amazon Web Services

Today, we're excited to announce the general availability of Claude Platform on AWS. Claude Platform on AWS is a new service that gives customers direct access to Anthropic's native Claude Platform experience through their AWS account, with no separate credentials, contracts, or billing relationships required. AWS is the first cloud provider to offer access to the native Claude Platform experience. In this post, we explore how Claude Platform on AWS works and how you can start using it today.

aws.amazon.com

ここで先に1つ、混乱しやすいポイントを片付けておきます。

「Claude Platform on AWS」と「Amazon Bedrock上のClaude」は別物です。

両方残ります。

そして、設計思想がそもそも違います。

「なるほど」と思った方も、「いやちょっと待って、データがAWS境界の外で処理されるってどういうこと？」と引っかかった方も、安心してください。

次のセクションから、3つの嬉しさを順番に深掘りしていきます。

ここからが本題です。

AnthropicネイティブAPIがAWSアカウントから直接使えるのがClaude Platform on AWSの最大の価値

まず1つ目の嬉しさ、「AnthropicネイティブAPIが、AWS認証情報そのままで叩ける」という話です。

これ、文字にすると地味なんですが、実務で言うとめちゃくちゃ大きいんです。

Anthropic直契約の「二重管理コスト」が消える

これまで、AnthropicのClaude APIを直接使おうとすると、こんな運用になっていました。

• AnthropicのアカウントとAPIキーを別途発行する
• AnthropicとAWSで請求書が別々に届く
• APIキーの管理・ローテーションがAWS Secrets Managerの外側で必要になる
• 経理は「Anthropic Inc.からの請求書」を毎月手作業で処理する

想像してみてください。

エンジニアとして「Anthropic直契約でClaudeを使いたい」と思っても、稟議書に「Anthropic Inc.への海外送金、月額〇〇ドル」と書いた瞬間に経理・法務のハードルが上がる、あの感覚。

組織で運用すると、こういう摩擦が本当に効いてきます。

特に調達フローが厳しめの会社だと、「海外SaaSの直契約は稟議が重い」という理由でAnthropic直契約に踏み切れず、Bedrock経由で我慢していたケース、けっこう多いんじゃないでしょうか。

Claude Platform on AWSは、ここを根本から解決します。

• 認証は既存のAWS IAM（本番はSignature Version 4推奨、探索用にAPIキーも可）
• 請求はAWS Marketplaceに統合され、Cost Explorerで他サービスと並んで見える
• 監査はCloudTrailにデフォルトで記録される
• 契約はAWSとの既存契約のなかに収まる

つまり、「Anthropic Inc.という会社と新規契約しなくても、AnthropicのClaudeが本気で使える」という状態になりました。

稟議書の「新規契約先」の欄を埋める必要が、もうないんです。

IAM認証で叩く実装イメージ

ここは少しだけ実装の話を入れさせてください。

Claude Platform on AWSのAPIエンドポイントは、AWS IAMで認可されます。

公式が推奨しているのは、本番環境ではSignature Version 4で署名された一時的なIAM認証情報を使うこと。

探索やテスト段階では、環境変数のANTHROPIC_API_KEYとANTHROPIC_WORKSPACE_IDを使ったAPIキー認証も可能です。

これが何を意味するかというと、「ClaudeのAPIキーを別途S3でもVaultでもなくAWS IAMロールで管理できる」ということです。

普段からEC2やECS、LambdaでIAMロールを切ってAWSサービスを叩いている人なら、追加の認証基盤を持ち込まずにClaudeが組み込めます。

「ClaudeだけSecrets Managerに突っ込んでたの、なんだったんだ」となる瞬間です。

CloudTrailで「誰が・いつ・どのモデルを叩いたか」が見える

監査の話もしておきましょう。

Claude Platform on AWSの操作は、CloudTrailに記録されます。

管理イベント（ワークスペース設定の変更など）はデフォルトで記録され、データイベント（実際のAPI呼び出し）はオプションで有効化できます。

これが何を意味するかというと、「社員のAさんがいつClaude Opus 4.7を叩いたか」を、AWS標準の監査基盤で追える、ということです。

セキュリティチームから「AIサービスのアクセスログ、CloudTrailで吸えますか？」と聞かれて即答できる状態になりました。

「AIの利用ログをどう管理するか」が各所で課題になっているいま、これはAWSエンジニアとして説明責任を果たしやすくなる、地味に重要なポイントです。

ここまでが1つ目の嬉しさ、「契約と運用が一本化される」話です。

次は、もっとエンジニアの心が踊るパートに行きます。

Claude Platform on AWSなら最新ベータ機能を「遅延なし」で叩ける（Skills・Managed Agents・Files API・MCP connector）

ここからが、個人的には一番アツいパートです。

Claude Platform on AWSの2つ目の嬉しさは、「Anthropicの最新機能がAWSアカウントから本家と同じタイミングで使える」こと。

なぜ今までBedrockだと新機能が遅れていたのか

これまでBedrockでClaudeを使っていた方は、おそらく一度はこう感じたはずです。

「Anthropic本家ではSkillsが出ているのに、Bedrockにまだ来ない」

「Files APIがほしいのにBedrock版にはない」

この遅延、誰かが意地悪してたわけじゃなくて、構造上の理由があります。

BedrockはAWSが運営するネイティブAWSサービスなので、Anthropicが新機能をリリースしても、Bedrock側でAPIを再実装し、AWSのセキュリティ・コンプライアンス基準でレビューしたうえで提供する必要があります。

いわばAnthropicが新製品を出すたびに、AWSが「うちの工場でも同じもの作れるか検証する」工程が挟まる。

これが遅延の正体です。

Claude Platform on AWSは、ここをひっくり返しました。

サービスを運営しているのはAnthropic本家で、AWSは「アクセスレイヤー」として機能している。

だから、Anthropicが新機能を本家で出したその日に、Claude Platform on AWSでも使えるんです。

公式ブログでも「full feature parity and day-one access to new model capabilities」と明言されています。

GA時点で使える機能リスト

GA時点で利用可能な機能を整理します。

注目してほしいのが、Claude Managed AgentsとAgent Skills、Files API、MCP connectorのbeta群です。

本家AnthropicでもまだベータなんですけどClaude Platform on AWSで初日から触れます。

Bedrockで「いつ来るんだろう」とソワソワしていた機能が、AWSアカウントから直接叩ける。

これは新機能を素早く検証して競合に差をつけたいエンジニアにとって、明確な優位性です。

たとえばClaude Managed Agents。

エージェントの実行基盤をAnthropic側でまるごと持つので、自前でエージェントループを実装・管理しなくていい。

つまり、AIエージェントの「骨格づくり」に時間を使わず、「何をさせるか」の設計に集中できます。

Agent Skillsも同様です。

ベストプラクティスをClaudeに「教え込む」という仕組みで、いわばClaudeに専門スキルのテンプレートをインストールできる。

「このエージェントはコードレビュー専門」「こっちはドキュメント生成専門」という使い分けが、プロンプト設計の試行錯誤を大幅に減らしながら実現できます。

利用可能モデル

モデルもAnthropic本家と同じラインナップが揃っています。

• claude-opus-4-7（最大能力モデル）
• claude-sonnet-4-6（バランス型）
• claude-haiku-4-5（高速・低コスト）

新モデルもリリース同日にClaude Platform on AWSに登場する設計です。

「最新のOpusを真っ先に触りたい」という用途には、現時点でこれより速い導線がないと思います。

ここまでが2つ目の嬉しさ。

次は、組織導入で実は一番効いてくる「お金の話」です。

Claude Platform on AWSは既存AWSコミットメントで支払える（commitment retirement）

3つ目の嬉しさは、組織導入の現場で地味だけどものすごく効くポイントです。

commitment retirement とは何か

AWSを大規模に使っている企業は、Enterprise Discount Program (EDP)やReserved Instances、Savings Plansなどで、年間〜数年単位の事前購入を結んでいることが多いです。

これが「AWSコミットメント」と呼ばれるものです。

Claude Platform on AWSは、この既存コミットメントを使って利用料を消化できます。

これを公式はcommitment retirementという言い方で説明しています。

AWS統合請求により、既存AWSコミットメントを消化（commitment retirement）できる。

たとえばこういう状態を想像してください。

• 自社は年間1億円規模のAWSコミットメントを締結している
• Anthropicとは新規契約を結んでいない
• 経理は新規海外SaaS契約に厳しい

これまでは「ClaudeをPoCしたいけどAnthropic直契約は稟議が通らない」状態でした。

Claude Platform on AWSがGAになった今、この壁が消えます。

すでに支払い済みのAWS予算枠から、Claudeが使える。

新規契約の交渉は不要、新規調達フローも不要。

「来週から使い始めます」が、本当に来週から可能になりました。

経理フローへの影響

地味に大きいのが、経理・調達側の負担減です。

海外送金が増えない（AWSへの支払いに統合される）、為替リスクが新たに増えない、監査時に「Anthropicへの支払い」を別途追跡する必要がない——それだけでも十分ですが、もうひとつ見逃せないポイントがあります。

AWSのCost Explorerとリソースタグで、Claudeのコストをサービス・チーム単位で配分できることです。

たとえばProject=SalesForecastというタグを付けて運用すれば、「営業予測プロジェクトでClaudeに毎月いくら使ったか」がCost Explorer上ですぐ見える。

社内チャージバックのフローがそのまま使えるということです。

「ClaudeをどのチームがどれだけAI活用に使っているか見えない」という問題が、追加ツール不要で解消されます。

ここまでで、3つの嬉しさを全部見ました。

次は、現実的な疑問にお答えします。

「で、Bedrockとどう使い分けるの？」

Claude Platform on AWSとBedrock、どう使い分けるか

ここまで読んで、「じゃあBedrockは要らないの？」と思った方もいるかもしれません。

答えは、はっきりNoです。

両方残ります。

Anthropic公式も「Bedrock上のClaudeを補完する（complements Claude models on Amazon Bedrock）」と明言しています。

判断基準は「データの処理場所」と「使いたい機能」

判断のキーは2つです。

1. データレジデンシー要件があるか
2. Anthropicの最新ベータ機能を使いたいか

整理するとこうなります。

よくある誤解：「ネイティブAWSだからBedrockのほうが安全」は半分正しくて半分違う

念のため、ここでよく聞く誤解にも触れておきます。

「BedrockはAWSの中だから安全で、Claude Platform on AWSは外だから不安」という意見をたまに見ますが、これは正確じゃないです。

正確には、

• BedrockはAWSセキュリティ境界の中でデータを処理する
• Claude Platform on AWSは、AWSの認証と請求は通すが、リクエストの処理自体はAnthropic側のインフラで行う

どちらが「より安全か」ではなく、「どちらの境界に置きたいか」という設計選択の話です。

データレジデンシー規制で「データは絶対にAWSの中で完結させる」必要があるならBedrock一択。

そうでないなら、新機能の早さでClaude Platform on AWSが圧倒的に有利、というだけです。

ここまで腹落ちすれば、自社のどのプロジェクトをどっちに乗せるか、判断軸がはっきりするはずです。

最後に、明日から何を確認すべきかをまとめます。

AWSエンジニアが今すぐ確認しておくべき3つのこと

ここまで読んで「自社でも使ってみよう」と思った方向けに、明日から確認すべきポイントを3つに絞って渡します。

全部、今日中に確認できるレベルのことです。

1. 利用可能リージョンに自社プロダクトのリージョンが入っているか

GA時点で利用可能なリージョンは以下です。

• 北米: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central)
• 南米: São Paulo
• ヨーロッパ: Dublin, London, Frankfurt, Milan, Zurich, Paris, Stockholm
• アジア太平洋: Tokyo, Seoul, Melbourne, Jakarta, Sydney

東京リージョンが入っているのは日本のチームにとっては嬉しいニュースです。

自社のメインリージョンが上に入っていればOK。

入っていない場合は、データ転送コストとレイテンシーを別途検証する必要があります。

2. IAMポリシー設計（誰がClaudeを叩けるか）

次に、IAMポリシーの設計です。

Claude Platform on AWSはAWS IAMで認可されるので、「どのIAMロール／ユーザーがClaudeを叩けるか」を明示的に決める必要があります。

最低限考えるべきは以下の3つです。

• 開発者向けロール（探索用APIキー）
• 本番アプリ向けロール（Signature V4での一時クレデンシャル）
• 監査ロール（CloudTrailのData Eventを読むだけ）

IAMポリシーで許可するアクションと、タグベースでの予算配分を最初に決めておくと、後から運用が楽になります。

ここは既存AWSサービスのIAM設計と同じ考え方がそのまま使えるので、手を動かしてみると「あ、知ってるやつだ」と感じるはずです。

3. 既存AWSコミットメントの残額

最後に、これは技術というより組織側の確認です。

経理・調達チームに、「現在のAWSコミットメントの残額と、AI/MLサービスへの内訳」を聞いてみてください。

ここに余裕があれば、Claude Platform on AWSはほぼ追加交渉ゼロで使い始められます。

余裕がない場合でも、「commitment retirementで既存予算が消化できる」というメリットは経理にとってわかりやすい説明材料になります。

PoCの稟議資料に「新規契約不要」と書けるかどうかで、決裁スピードは大きく変わります。

まとめ：Claude Platform on AWSは「Anthropicの本気をAWSの運用に乗せる」最短経路

長くなりましたが、要点を3行で。

• AnthropicネイティブAPIが、AWSアカウントの認証情報と請求で使える
• Skills・Managed Agents・Files API・MCP connectorの最新ベータが、本家と同日に触れる
• 既存のAWSコミットメントで支払えるので、新規調達フローが要らない

データレジデンシー要件がない用途では、もはやAnthropic直契約に戻る理由はほぼないと思います。

逆にデータをAWS境界内で完結させたいなら、Bedrockのままで問題なし。

両方残るので、用途に応じて使い分けてください。

個人的には、Claude Managed AgentsとAgent Skillsをいち早く本番に乗せたいAWSユーザーにとって、これ以上ない朗報だと感じています。

東京リージョン対応なので、日本チームは特にレイテンシー面の心配なく試せます。

「使ってみたい」と思った方は、まず社内のAWS管理者にClaude Platform on AWSの有効化と、自分のIAMロールに必要な権限を確認するところから始めてみてください。

そこから5分でClaude Consoleを開いて、最新のOpus 4.7にプロンプトを投げる体験まで一気に進めるはずです。

それでは、また次の記事で。