Tech BlogAWSツール & 技術ブログ
メニュー

カテゴリ

AWS & AI ツール

タグ

AI24Claude Code23AWS12セキュリティ11Claude9効率化8開発ツール6プラグイン5S35CloudFront5Next.js4Opus 4.83すべて見る →

AWS上でClaudeを使う選択肢を検討して、結局「乗り換えなかった」話──Bedrock / Claude Platform / API / Claude Code

AWSClaudeBedrockClaude CodeIaCTerraformservice-selectionprocurementcomparison

はじめに

「AWS上でClaudeを使いたい」と言ったとき、実は複数の経路がある。2026年に入ってAWSとAnthropicが共同で Claude Platform on AWS を発表した（公式ページ）ことで、選択肢はさらに増えた。すでにある Amazon Bedrock 経由のClaude、Anthropicと直接契約するClaude API、開発者の手元で動く Claude Code――名前が似ていて役割が違うため、どれを選ぶべきか迷いやすい。

結論から書いておくと、個人でClaude Code（課金プラン）を使っている自分は、これらの経路を検討した上で今のところ乗り換えていない。この記事は、その判断に至るまでに4つの経路をどう比較したかの記録であり、同じように「AWSでClaudeを使うべきか」と迷っている人が、自分の状況で選び分けるための整理ノートでもある。

この記事で学べること

  • AWS上でClaudeを使う4つの経路（Bedrock / Claude Platform on AWS / Anthropic API / Claude Code）の役割の違い
  • 使い分けの軸: 「インフラ構築に使うのか、推論ランタイムに組み込むのか」という実装対象の軸と、「個人で契約するのか、エンタープライズの調達に乗せるのか」という調達形態の軸
  • 個人課金でClaude Codeを使う自分が、なぜ乗り換えを見送ったのかの判断軸（既存契約・料金体系・必要性の3点）
  • Claude Codeで完結する領域の判定: 「AWS上でClaudeを動かす」必要が本当にあるのか、手元のClaude Codeで足りるのかの見分け方

本記事のスタンス: Claude Platform on AWS は記事執筆時点（2026年4月末）で多くの情報が「今後公開」「サインアップして待機」段階のため、計測値やGA日付など確定していない数値は本記事では扱わない。むしろ、この未確定の段階だからこそ「今は乗り換えない」と判断した——というのが本記事の立場だ。発表内容と既存サービス（Bedrock経由のClaude / Anthropic API / Claude Code）から定性的に位置づけを整理し、自分が見送りを決めた判断軸を記録として残す。新サービスの紹介記事ではなく、いち個人開発者の選定・検討の記録として読んでほしい。

なお、このブログ自体は 2026年5月にCloudflare Pagesへ移行済み（移行前はS3 + CloudFront + Next.js構成でAWS上に置いていた）で、記事執筆や運用ツール作りには Claude Code（個人課金プラン）を使っている。「AWSでClaudeを使う」「Claudeでインフラを作る」という両方の立場を行き来した経験から、各経路の位置づけを整理する。

Claude Platform on AWSとは何か（現時点でわかっていること）

詳細仕様は公式ページに委ねるが、Anthropicの公式アナウンスやAWSの製品ページから読み取れる位置づけを要約すると、AWSの契約・請求体系の中でAnthropicのClaudeモデル群を直接利用できるようにする提供形態、と理解するのが近い。Anthropic API互換のインターフェースが提供され、セキュリティ・コンプライアンス面はAWS側のガバナンスに乗せられる、という方向性が読み取れる。

ただしGA時期、対象モデル、Anthropic API SDKとの完全互換性、AWS既存サービス（IAM・PrivateLink等）との連携の細かい仕様は、執筆時点では 未公表・未定 である。確定情報は公式ページで確認してほしい。本記事では推測可能な範囲の定性的な位置づけのみを扱い、具体的なGA日付や単価には踏み込まない。

業界の流れとして見ると、これは「クラウドベンダー経由で主要LLMを調達できるようにする」動きの一部だと捉えると分かりやすい。すでにBedrockがマルチモデルのマネージド提供を担っているが、Claude Platform on AWSは「Anthropicとの契約・アクセス経路をAWS側に統合する」ことに比重を置いた選択肢、という立ち位置になりそうだ。

まず最初に整理しておきたいこと：これは「構築用サービス」ではない

最も誤解しやすいのがこの点だと思う。

Claude Platform on AWSは「AWS上にClaudeを使ったAIシステムを構築するためのフレームワーク」ではない。あくまで 「AWSの契約・請求体系の中でClaudeモデルを呼び出せるようにする提供形態」 だと理解するのが正しい。

似たような名前で混同しやすいAWS製品が並んでいるので、自分の頭の整理として並べ直してみた。

名称 役割 向いているユースケース 調達形態 コスト・レイテンシの傾向（定性）
Amazon Bedrock AWS上で複数の基盤モデル（Claude含む）を呼び出せるマネージドサービス アプリケーション組み込み・RAG・エージェント基盤 AWSアカウントの従量課金 AWS他サービスと密結合する構成に向く。最新モデルはAnthropic直接よりリリースが遅れる傾向
Claude Platform on AWS AWS経由でClaudeモデル群を直接利用するプラットフォーム提供 既存のClaude API互換コードをAWS契約下で動かす AWS契約体系（Marketplace等、詳細未公表） 契約・請求をAWSに統合したい組織向け。具体的な単価・レイテンシは未公表のため未知数
Claude API（Anthropic直接契約） Anthropicと直接契約してClaude APIを呼び出す 個人・スタートアップ・小規模利用 Anthropicと直接契約（クレカ即日開始） 最新機能・モデルへのアクセスが早い傾向。手続きが軽い
Claude Code（CLI／IDE統合） 開発者の手元のエディタやCLIでClaudeを使う コード生成・リファクタリング・IaCコード生成 Anthropic個人/チームプラン 開発作業を手元で完結させる用途。本番ランタイムへの組み込みは対象外

「AWS上にClaudeを使ったエージェントを組む」という用途なら、Bedrock + Bedrock Agents や Claude Managed Agentsの方が手段として近い。Claude Platform on AWSは 「Claudeをどこで・誰と契約して使うか」の選択肢を増やすものであり、構築の中身を変えるものではない、という整理になる。

Bedrock経由のClaudeとの違い：使い分けの軸

すでにBedrockでClaudeは使えるのに、なぜ別の形態で提供するのか。これは明確に 用途・購買ルートが違うからと理解している。

Bedrockでのクロード利用が向いているケース

  • AWSの他サービス（Lambda・Step Functions・Knowledge Bases for Amazon Bedrock等）と密結合させたい
  • 複数モデル（Anthropic Claude, Amazon Nova, Cohere, Meta Llama等）を切り替えながら使う
  • IAMロールベースの権限管理に統合したい
  • リージョン制約・データ越境制約をAWS側のガバナンスで管理したい

Claude Platform on AWSが向いていそうなケース

  • 既にAnthropic API互換のコード資産がある（プロンプト、SDK呼び出し方法等）
  • 調達ルートとしてAWSの契約体系に統一したい（複数ベンダー契約を避けたい大企業）
  • Anthropicの最新モデル・最新機能をBedrockのリリース遅延を待たずに使いたい
  • セキュリティレビュー・購買プロセス上、AWSの既存契約に乗せた方が通しやすい

つまり「機能的な選択」というより「調達・運用上の選択」の比重が大きいサービスだろうと感じている。Bedrockがインフラ・モデルの抽象化なら、Claude Platform on AWSは 契約とアクセス経路の抽象化に近い。

その前に：「Claude Code + IaC」で完結する場面は意外と多い

経路の選定に入る前に、見落とされやすい前提を一つ整理しておきたい。「AWS上でClaudeを使う」という言葉には、実は2つの異なる意味が混ざっている。

  • (A) Claudeを使ってAWSのインフラを作りたい（IaCコードの生成・レビュー）
  • (B) AWS上のアプリから本番でClaudeの推論を呼びたい（推論ランタイムへの組み込み）

このうち (A) は、手元のClaude CodeでTerraformやCDKのコードを書いてもらうだけで大半のタスクが完結する。AWS上にClaudeを置く必要はない。

このブログの移行前の構成（S3 + CloudFront + OAC + Route53）を例に、どこまでClaude Codeで賄えるかを整理するとこうなる。

工程 Claude Code + 手元のCLIで可能か 備考
TerraformでS3バケット定義を生成 可能 プロンプトで要件を渡せばコード生成
OACの設定（バケットポリシーとの連携） 可能 ハマりポイントもClaudeに質問しながら解決
CloudFront Distributionの定義 可能 キャッシュTTL・OAC連携を含めて生成可能
Route53レコードの追加 可能 terraformのaws_route53_record
デプロイスクリプト（S3 sync + invalidation） 可能 bashで十分。移行前のAWS構成で実際に使用
terraform plan / apply の実行 手元のCLIで実行 Claude Codeはコード生成、実行は人間

移行前のこのブログのデプロイは、deploy.sh という小さなbashスクリプトで S3 sync → CloudFrontキャッシュ無効化を実行していた（現在はCloudflare PagesのGit連携に移行済み）。インフラの初期構築をTerraform化するとしても、コード自体はClaude Codeに生成させて、レビューと実行に専念すれば小規模なサイトなら短時間で済む規模感だ。

このブログ自体は今のところTerraform化していないが、Claude Codeを使えば「やる気になればすぐ移行できる」状態にある、というのが実感ベースの感覚。

つまり 「AWS上でClaudeを動かす」必要があるのは上記 (B) の場合に限られる。(A) のように「Claudeを使ってAWSのインフラを作りたい」だけなら、Claude Codeと手元のクレデンシャルで完結する。Bedrock や Claude Platform on AWS の検討に進むべきかどうかは、まずこの (A)/(B) の切り分けから始めるのがよい。

既存Claude課金ユーザー視点での懸念：プランが横移動できないかもしれない

ここからは、すでにClaudeに課金している個人ユーザーとしての所感を率直に書く。

自分は Claude Codeを個人で契約していて、ブログ記事の執筆補助、ツールページのTSXコンポーネント作成、コードレビューに活用している。月額の支払いはAnthropic側に直接行っている。

Claude Platform on AWSが提供される場合、想定される課金体系は 「AWSアカウント単位での従量課金」 あるいは 「AWS Marketplaceを介したサブスクリプション」になる可能性が高い。これがどう影響するかというと:

  • 個人で契約している既存のClaudeプランは、そのままAWS側に持ち越せない可能性がある
  • 仕事と個人で別AWSアカウントを使っている場合、それぞれ別途契約が必要になる可能性がある
  • 既存の使用履歴・プロンプト履歴・カスタム設定が引き継げるかどうかも不透明

「すでにClaudeに払っているのに、AWS経由で使うならまた別契約」となると、個人ユーザーとしては正直少し残念感がある。もちろん契約の主体・データの管理境界が変わるので技術的には別契約になるのは妥当なのだが、感覚的には「同じClaude」を二重に契約することになりかねない。

このあたりはGA後のドキュメントで明確化されるはずなので、利用を検討する人は 料金体系・既存契約との関係 を必ず公式に確認してから動いた方がいい。

では、Claude Platform on AWSは誰に向けたサービスか

ここまでの整理を踏まえての個人的な仮説。

おそらくこのサービスの主要な想定顧客は 「AWSと既に大型の包括契約を結んでいる中堅〜大企業」だと思う。理由はこんなところ:

  • 大企業は調達プロセス上、新規ベンダー契約のハードルが高い → AWS経由なら既存契約で通しやすい
  • セキュリティ・コンプライアンス審査もAWSの既存ガバナンスに乗る方が早い
  • 法務・購買・経理の手間がAWS請求一本に集約できる
  • 大量利用ならEDP（Enterprise Discount Program）的な割引交渉も期待できる

逆に、個人開発者・スタートアップにとってのメリットは現時点では薄い。Anthropic直接契約の方が:

  • 手続きが軽い（クレジットカード即日開始）
  • 最新機能・モデルへのアクセスが早い（Bedrockや新プラットフォームはローンチが遅れることが多い）
  • 既存のClaude Code等との一貫性がある

このため、当面は 「個人・小規模はAnthropic直接契約のまま、エンタープライズはAWS経由を選択肢に」 という棲み分けになるのではと予想している。

立場別・選定チェックリスト

ここまでの整理を、立場ごとの判断軸としてまとめておく。実体験に基づく断定ではなく、どの経路を検討すべきかを切り分けるための概念的なチェックリストとして使ってほしい。

個人開発者

  • やりたいのは (A) インフラ構築か (B) 推論の組み込みか。(A) なら Claude Code で完結する可能性が高い
  • (B) でも小規模なら、まずは Anthropic API 直接契約（クレカ即日開始）が手続き面で軽い
  • AWSの他サービスと密に連携する必要が出てきたら Bedrock を検討する

スタートアップ

  • 最新モデル・最新機能を早く使いたいなら Anthropic直接（API / Claude Code） が有利な傾向
  • 既にAWSにアプリ基盤がありRAGやエージェントを組むなら Bedrock が連携しやすい
  • 調達・契約の一本化が経営課題になっていない段階では、Claude Platform on AWS を急いで選ぶ動機は薄い

中堅企業

  • 複数ベンダー契約の管理コストが上がってきたら、AWS契約への統合（Bedrock / Claude Platform on AWS）を比較する価値がある
  • IAMロールベースの権限管理・データ越境制約をAWSガバナンスに乗せたいなら Bedrock が現実的な第一候補

大企業

  • 新規ベンダー契約のハードルが高い組織では、既存のAWS契約に乗せられるかが選定の主要軸になる
  • セキュリティ・コンプライアンス審査をAWSの既存プロセスで通せるかを確認する
  • Claude Platform on AWS は、まさにこの調達・ガバナンス要件にフィットする可能性がある選択肢

購買・調達担当

  • 課金が AWS請求一本に集約できるかを確認する（経理・法務の手間に直結）
  • 大量利用なら割引交渉（EDP的な枠組み）の対象になり得るかを確認する
  • 既存のClaude契約から横移動できるかは未公表のため、GA後の公式ドキュメントで料金体系を必ず確認する

結論：選び分けの整理

整理した結果、4経路の選び分けはこう考えるのが分かりやすい。

  • 個人のインフラ構築 (A): Claude Code + Terraform を手元で回すだけで完結する。AWS上にClaudeを置く必要はない
  • 個人・小規模の推論組み込み (B): Anthropic直接契約のAPIが手続き面で軽く、最新モデルへのアクセスも早い傾向
  • AWS基盤と密結合させたい場合: Bedrockが連携しやすく、IAM・ガバナンス統合の現実的な第一候補
  • 調達・契約をAWSに統合したい組織: Claude Platform on AWS を Bedrock と並べて比較する価値がある。ただし料金体系・既存契約との関係はGA後の公式ドキュメントで確認が必要

サービスの選択肢が増えること自体は歓迎すべきで、「AWS契約に統一できる」「セキュリティレビューが通しやすい」という価値を必要とする組織には刺さると思う。一方で 個人開発者として既にClaudeに課金している立場 なら、急いで経路を切り替える必然性は薄い、というのが現時点の整理だ。

まとめ

  • Claude Platform on AWSは 「AWS契約下でClaudeを使う」ための提供形態 であり、構築フレームワークではない
  • Bedrock経由のClaudeとは 機能ではなく購買ルート で使い分ける性格のサービス
  • 既存Claudeユーザーのプランがそのままスライドできるかは 不透明。AWSアカウント単位で別途契約になる可能性が高い
  • 個人開発者なら Claude Code + Terraform でAWSインフラ構築は手元で完結するため、「AWSでClaudeを使う」必要があるのは推論を本番ランタイムから呼ぶ場合に限られる
  • 主な想定顧客は 大企業の調達・コンプライアンス文脈 と推察。個人・小規模はAnthropic直接契約が引き続き合理的
  • 自分の結論: 検討した上で乗り換えはしていない。理由は3点——(1) 個人のインフラ構築は Claude Code + Terraform で手元完結しており「AWSでClaudeを動かす」必要がそもそもない、(2) 既存のClaude Code課金とAWS経由の課金が二重になりかねず、プランがスライドできるか不透明、(3) GA後の料金体系・既存契約との関係性がまだ未確定。この3つが解消されない限り、今の構成を変える動機が薄い

サービスが広がるのは良いことだが、「AWSで使えるようになった = 全員が乗り換えるべき」ではない。自分はこの検討を経て現状維持を選んだが、使い方・契約形態・組織の調達ルートが違えば結論は変わる。だからこそ、誰かの「おすすめ」ではなく自分の状況に照らして経路を整理することが、選定の第一歩になると思う。

関連記事

この記事で触れた各経路を、より具体的に掘り下げた記事を以下に整理した。読む順序の目安も添えておく。

関連記事

← 記事一覧に戻る