· updated

AWS Bedrock は本当に必要か｜Anthropic 直API と実費比較

会社で Claude を業務利用しようとすると、Anthropic 直 API と AWS 経由 Bedrock（ベッドロック）のどちらを選ぶか、料金差はあるのか、AgentCore のような新ワードまで出てきて迷っていませんか。実際、ラッコキーワードの実測（2026 年 5 月時点）でも「AWS Bedrock」は月 4,400 人が検索しており、12 ヶ月で +147% の伸び方をしています。私自身、業務本番運用のメインは直 API、Bedrock 経由 Claude は PoC・検証レベルで触っています。

結論から言うと、Bedrock は AWS 経由で複数 LLM を一括で叩ける統合 API、迷ったらまず直 API、IAM 連携や VPC 内通信など組織要件が出てから Bedrock を検討するのが筋です。本記事では主要モデル・料金・直 API との使い分け・Claude Code 連携・AgentCore・5 UC・失敗パターンまで整理します。

とりあえず最短で「自分は Bedrock 経由を選ぶべきか」を知りたい方は、セクション 1「結論」と セクション 6「直 API vs Bedrock 経由」、セクション 10「エンタープライズでの選択軸」から読み始めると、5 分で判断材料が揃います。

01 — 結論：Bedrock は「AWS 経由で複数 LLM を一括で叩ける統合 API」、迷ったらまず直 API という一行マップ

📖 この章で使う用語

  • AWS Bedrock（ベッドロック）：AWS 経由で Claude / Llama / Mistral / Titan など複数の LLM を一括で叩けるマネージド型の統合 API。「商社経由の購買」のたとえ。
  • Anthropic 直 API：Anthropic 社（Claude の開発元）が直接提供する API 窓口。Bedrock を介さない直販ルート。
  • LLM（Large Language Model：大規模言語モデル）：ChatGPT / Claude / Gemini などの「中身」を動かす、文章を予測する装置。詳しくは LLM とは で扱っています。

まず結論から書きます。AWS Bedrock を使うかどうかで迷ったら、まずは Anthropic 直 API（または OpenAI / Google の直 API）で 1〜2 ヶ月触ってみる、そして IAM 連携や VPC 内通信、監査ログ集約といった組織要件が現実に出てきた段階で Bedrock を検討する——これが、業務で両方を触っている私のいちばん実用的な答えです。

3 行で覚えていただきたいのは、次の住み分けです。

  • 個人検証・小規模 PoC ＝ Anthropic 直 API（API キー 1 本で 5 分で始められる）
  • 業務本番運用（少人数・スタートアップ） ＝ Anthropic 直 API + 自前のキー管理でも回る
  • エンタープライズ・コンプラ要件 ＝ Bedrock 経由（IAM・VPC・監査ログ・契約が AWS に集約）

営業時代の身近なたとえで書くと、Bedrock は 「商社経由の購買」 に近い存在です。直で仕入れた方が安いケースもありますが、与信・伝票・コンプラ書類が分散してしまう。商社経由だと手数料が乗ることはあっても、与信枠も契約書も伝票も 1 本にまとまる。社内稟議が通りやすくなる、というメリットが「料金差」以上に効いてきます。私は通信機器商社で約 7 年法人営業をしていましたが、「直販ルート vs 商社経由」の選び方とまったく同じ構図が、Bedrock と直 API の間にもあります。

ここで本記事の立ち位置と、既存記事との役割分担を明示しておきます。本記事は 「エンタープライズ AI 基盤軸」——Bedrock そのものをどう選ぶか、Anthropic 直 API とどう使い分けるか、Claude Code をどう Bedrock で動かすか、Bedrock Agents と AgentCore はどう位置づけるか——に焦点を絞ります。RAG（社内ドキュメント検索）の概念は RAG とは、AI エージェントの概念は AIエージェント とは、Claude プロダクト全体の使い方は Claude 使い方、Claude のモデル選び（Opus / Sonnet / Haiku）は Claude Opus と Claude 料金プラン で、それぞれ別記事として整理済みです。本記事は「Bedrock そのものの選定地図」に絞ります。

私自身の立ち位置もお伝えしておきます。業務本番運用のメインは Anthropic 直 API、Bedrock 経由 Claude は PoC や検証で部分的に使用、業務本番運用での運用経験はありません（プロフィール記述に合わせます）。本記事で語れる範囲は、Bedrock の「概念と選定の整理レベル」——直 API との違い、料金の見比べ方、IAM / VPC / 監査ログのメリット、Claude Code 連携の派生、Bedrock Agents と AgentCore の位置づけ——までです。業務本番運用の細部（PrivateLink の具体的な構成例、Provisioned Throughput の最適予約タイミング、リージョン別のコスト最適化など）は、AWS 公式ドキュメントと大手 SI のブログを「公開情報からの整理」として参照しながら、本記事では深掘りしません。この立ち位置を冒頭で正直に書くのは、SERP 上位の記事には少ない差別化軸だと思っています。

最後に重要なメタ宣言を 1 つ。本記事では、「絶対 Bedrock 経由が安全」「絶対 直 API が安い」とは申し上げません。料金もモデルもリージョン提供状況も時期で変動しますし、組織要件は会社によって振れ幅が大きいです。本記事の各セクションで述べる判断軸は「2026 年 5 月時点・私の業務観察と公開情報からの整理」であり、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。

02 — AWS Bedrock とは——「ベッドロック」の読み方と AWS の生成 AI 統合プラットフォームの位置づけ

📖 この章で使う用語

  • マネージド型：AWS が裏側のインフラ運用・スケーリングを引き受けてくれる提供形態。「お任せ運用」のイメージ。
  • LLM プロバイダ：LLM（大規模言語モデル）を開発・提供する企業群。Anthropic / Meta / Mistral / Amazon / Cohere / AI21 / Stability AI など。
  • IAM（Identity and Access Management）：AWS の権限管理サービス。誰が何にアクセスできるかを一元管理。「会社の入館証システム」のイメージ。

ここからは、AWS Bedrock の 「読み方」「正体」「Anthropic 直 API / OpenAI API / Google AI Studio との関係」 を順に整理します。

02-1. 読み方は「ベッドロック」——bedrock は英語で「岩盤・基盤」

「AWS Bedrock」は 「エーダブリューエス ベッドロック」 と読みます。bedrock は英語で「岩盤・基盤・土台」を意味する単語で、地質学では「地表の下にある固い岩盤」を指します。AWS が生成 AI 時代の「基盤」になることを狙って命名したのだろう、というのが業界では一般的な受け止め方です。出典は本記事末尾の「出典」セクション、AWS 公式の Bedrock ページをご参照ください。

営業時代の私の癖で、初対面のお客様の社名がカタカナ／英字混じりだったとき、まず読み方を確認してから商談に入るようにしていました。読みが分からないまま会話を進めると、社内稟議でも提案でも、必ずどこかで気まずさが残るからです。AWS サービス名も同じで、「ベッドロック」と声に出して読めるようになるだけで、情シスや上長との会話がぐっと楽になります。

02-2. Bedrock の正体——マネージド型の LLM 統合 API

AWS Bedrock の正体を 1 行で書くと、AWS が裏側で複数の LLM プロバイダ（Anthropic / Meta / Mistral / Amazon / Cohere / AI21 / Stability AI など）と契約してくれていて、利用者は AWS との 1 本の契約・1 つの IAM だけで全プロバイダのモデルを叩けるマネージド型の統合 API です。出典は AWS 公式の Bedrock ページ（本記事末尾の「出典」セクションを参照）。

整理すると、生成 AI を業務で使う窓口は大きく 2 系統あります。

  • 直販ルート：Anthropic 直 API / OpenAI API / Google AI Studio など、各プロバイダの公式窓口
  • AWS 経由ルート：AWS Bedrock が代理販売してくれる窓口（複数プロバイダを一括）

営業時代のたとえで書くと、これは 「メーカー直販店」と「大手商社経由」 の関係そのものです。直販店は安いし最新モデルも早いけれど、複数メーカーの製品を買おうとすると、与信・伝票・契約書がメーカー数だけ増えてしまう。商社経由は手数料が乗ることはあっても、与信・伝票・契約書が 1 本にまとまる。「Bedrock = 商社経由」のたとえは、本記事で何度か登場します。

Bedrock の管理コンソール（AWS Management Console）の入り口は、AWS にログインして「Bedrock」とサービス名検索する、または「生成 AI」カテゴリから入ります。コンソール画面で「Model access」「Playgrounds」「Knowledge Bases」「Agents」などのメニューが並んでおり、ここから使いたいモデルへのアクセス申請、試し打ち、社内 RAG 構築、エージェント構築まで一通り行えます。

02-3. Anthropic 直 API / OpenAI API / Google AI Studio との関係

「じゃあ、Anthropic 直 API は要らなくなるのか？」という質問をよくいただきますが、答えは 「いいえ、用途で住み分ける」 です。

  • Anthropic 直 API：Anthropic 社の公式窓口。Claude 専門、最新モデル・最新機能が最も早く出る、API キー 1 本で開始できる
  • OpenAI API：OpenAI 社の公式窓口。GPT 専門、ChatGPT 系の最新機能はここが先
  • Google AI Studio / Vertex AI：Google 社の公式窓口。Gemini 専門
  • AWS Bedrock：上記 3 社（+ Meta / Mistral / Amazon / Cohere / AI21 / Stability）を AWS の 1 つの IAM・1 つの契約で叩ける統合窓口

私の業務感覚としては、新機能をいち早く試したいときは直 API、組織内で IAM・VPC・監査ログを統合したいときは Bedrock、という使い分けです。実際、Anthropic の新モデルがリリースされると、まず直 API で利用可能になり、Bedrock 側で利用可能になるのは数日〜数週間遅れる、という傾向が（2026 年 5 月時点までの私の観察では）あります。出典は Anthropic 公式の News ページ（本記事末尾の「出典」セクションを参照）。

03 — Bedrock で使える主要モデル一覧——Claude / Llama / Mistral / Titan / Cohere / AI21 / Stability

📖 この章で使う用語

  • フロンティアモデル：各 LLM プロバイダの最上位・最新モデル。Claude Opus / GPT-4o / Gemini Ultra など。「車種で言うと最上位グレード」。
  • モデル ID：Bedrock 上で各モデルを識別する一意の文字列。例：anthropic.claude-3-5-sonnet-20240620-v1:0。
  • モデル系列：同じプロバイダの中で世代やサイズが異なるモデル群。Claude 3.x / Llama 3.x のような括り。

ここでは、2026 年 5 月時点で Bedrock から叩ける主要モデルを 業務でどこまで触っているか とセットで並べます。最新のモデル提供状況は AWS 公式の Bedrock ページで必ず事前確認してから判断してください。本記事の数字も時期によっては変わっている可能性があります。

03-1. Bedrock のモデル一覧（業務利用範囲とセット）

プロバイダ主なモデル用途私の業務利用範囲
AnthropicClaude Opus / Sonnet / Haiku（3.x / 4.x 系列）汎用高性能 LLM、長文要約、コード生成、エージェント直 API は業務常用、Bedrock 経由は概念と選定の整理レベル
MetaLlama 3 / Llama 4 系列汎用 LLM、OSS ベース業務本番運用なし、個人検証レベル
MistralMistral Large / Mixtral 系列汎用 LLM、OSS ベース業務本番運用なし、個人検証レベル
AmazonTitan Text / Titan EmbeddingsAWS 純正 LLM、テキスト + 埋め込み業務本番運用なし、公開情報から整理
CohereCommand R / R+検索拡張に強い LLM業務本番運用なし、公開情報から整理
AI21 LabsJamba 系列長文向け LLM業務本番運用なし、公開情報から整理
Stability AIStable Diffusion 系列画像生成業務本番運用なし、画像生成は別記事 AI 画像生成 無料 で扱い

私が業務で常用しているのは、上の表のうち Anthropic Claude（Opus / Sonnet / Haiku）の 3 モデル系列だけです。それも、業務本番運用のメインは Anthropic 直 API 経由で、Bedrock 経由はあくまで PoC・検証で部分的に触っているレベル。Llama / Mistral / Titan / Cohere / AI21 などのプロバイダは、業務本番運用での利用経験はなく、公開情報と個人検証ベースの整理にとどまります。本記事でこれらを並べているのは「Bedrock の網羅性」を伝えるためであり、「これらをすべて私が使いこなしている」という意味ではありません。

03-2. AWS 公式ドキュメントの読み方——英語が一次情報、日本語版の追従ペース

Bedrock の最新仕様を追うとき、私が業務で実際に開くのは AWS 公式の Bedrock User Guide（英語版） です。日本語版も整備が進んでいますが、新機能（AgentCore など）のリリース直後は英語版のみが先行する傾向があり、日本語訳の追従までに数日〜数週間のラグが出ます。出典は AWS 公式の Bedrock ページ（本記事末尾の「出典」セクションを参照）。

英語の AWS docs に苦手意識のある方は、ブラウザの翻訳機能や DeepL の活用も一つの選択肢です。私自身も、最初のうちは Chrome の翻訳機能で粗読みしてから、技術的な細部だけ英語の原文を読み直す、という使い方をしていました。詳しくは AI 翻訳 おすすめ で扱っています。

03-3. 「どのモデルを選ぶか」の判断軸 3 つ（コスト・用途・実体験ベース）

Bedrock で複数モデルから選ぶとき、私が判断軸として置いているのは次の 3 つです。

  1. 用途とのフィット：汎用な長文整理・コード生成は Claude Opus / Sonnet、OSS ベースでオンプレ移行も視野に入れたいなら Llama 系、AWS 内で完結したいなら Titan、というざっくりの目安
  2. コスト：per-token 単価（100 万トークンあたりの $）と、自分の月間トークン量を掛け算してオーダー感を掴む
  3. 実体験ベースで語れるか：本番投入する前に、自分か社内の誰かが、その特定モデルを実際の用途で触ってみた経験があるか

3 つ目の「実体験ベースで語れるか」は意外と効きます。社内導入の意思決定をするとき、「公開情報では性能が良さそう」だけで決めると、本番投入後に細かい癖（応答の長さの傾向、日本語の自然さ、特定タスクでの誤答パターン）でハマることがある。「触ってみた感覚を持っている人」が社内に 1 人いるかどうかで、稟議の通りやすさも違ってきます。

04 — なぜ Bedrock 経由で Claude を使うのか——IAM 連携・VPC 内通信・監査ログ・コンプラ要件

📖 この章で使う用語

  • VPC（Virtual Private Cloud）：AWS 内に作る仮想的なプライベートネットワーク。「社内 LAN を AWS 内に持つ」イメージ。
  • PrivateLink：VPC 内から AWS サービスへ、インターネットを介さず直接通信する仕組み。「公道を通らない社用車専用通路」のイメージ。
  • CloudTrail：AWS の操作ログ記録サービス。「監視カメラの録画」のイメージ。
  • CloudWatch：AWS のメトリクス・ログ監視サービス。「メーター盤と通知センター」のイメージ。
  • BAA（Business Associate Agreement）：医療系の業務委託契約。HIPAA など医療情報の法令準拠で必要。
  • SOC 2 / ISO 27001：情報セキュリティの国際認証規格。

ここからが、Bedrock を選ぶ「実質的な理由」になります。Bedrock 経由 Claude のメリットを、私のこれまでの選定整理の経験から 4 軸で並べます。なお、本セクションの 4 軸はあくまで「概念と選定の整理レベル」での記述です。各機能の具体的な構成例や設定手順は、AWS 公式の Bedrock User Guide および各機能（PrivateLink / CloudTrail / CloudWatch / IAM）のドキュメントを参照する「公開情報からの整理」として扱います。

04-1. IAM 連携——既存 AWS の権限管理で一括統制

Bedrock の最大のメリットは、既存 AWS の IAM（権限管理）でユーザー・ロール・ポリシーを一括管理できることです。Anthropic 直 API では API キーを個別に発行し、誰がどのキーを持っているか、どのキーがいつから無効か、をすべて自前で管理する必要があります。エンタープライズ環境では、これが運用負荷の大きな割合を占めます。

Bedrock 経由なら、AWS の IAM で「このロールの人は Claude Sonnet を呼べる」「このグループは Opus も呼べる」「このユーザーは Bedrock そのもののアクセス権がない」という権限制御を、既存の AWS 権限管理体系の中に組み込めます。営業時代のたとえで書くと、Anthropic 直 API は 「個別のお客様カードを 10 種類持ち歩く」 イメージ、Bedrock は 「会社の入館証 1 枚で全フロアに通れる」 イメージです。

04-2. VPC 内通信（PrivateLink）——インターネット経由を避けたい要件

エンタープライズ環境では、「機密情報を含む API リクエストをインターネット経由で送りたくない」 という要件が強く出るケースがあります。Anthropic 直 API は、原則としてインターネット経由（HTTPS over public internet）で叩く前提です。一方、Bedrock は AWS の VPC（仮想プライベートネットワーク）内から PrivateLink 経由で叩くことができ、通信がインターネット公道を一切通らない構成を組めます。

これは金融・医療・公共系での「データの域外流出リスク」を最小化したいケースで特に効きます。「公道を通らない社用車専用通路を使う」イメージです。詳細な構成手順は AWS 公式の VPC エンドポイント / PrivateLink ドキュメントをご参照ください（本記事末尾の「出典」セクションを参照）。私自身は業務本番運用でこの構成を組んだ経験はないため、公開情報からの整理レベルでの記述になります。

04-3. 監査ログ（CloudTrail / CloudWatch）——既存基盤での一括取得

Bedrock の API 呼び出しは、AWS CloudTrail（操作ログ）と CloudWatch（メトリクス・ログ）に自動で記録されます。「誰が・いつ・どのモデルを・どの IAM ロールで・どのリージョンから叩いたか」が、既存 AWS の監査基盤に集約されます。

Anthropic 直 API でも自前でログを集約することは可能ですが、その場合は別途ログ収集基盤を組む必要があります。Bedrock 経由なら、社内の SIEM（セキュリティ情報イベント管理）製品が既存の AWS CloudTrail を参照している場合、追加実装ゼロで AI 利用ログまで集約されます。営業時代のたとえだと、「監視カメラを 1 か所にまとめて見られる管理室がある」 イメージです。

04-4. コンプラ・契約（BAA / SOC 2 / ISO 27001）——AWS 既存認証の継承

Bedrock は AWS のサービスなので、AWS が既に取得している各種認証（SOC 2 / ISO 27001 / FedRAMP（米国政府機関向け）など）を継承します。医療系で必要な BAA（Business Associate Agreement）も AWS と 1 本の契約で締結できる、というのが大きい。

Anthropic 直 API も独自に各種認証を取得していますが、エンタープライズ環境で「既存の AWS 契約と統合される方が稟議が通りやすい」という現実的な事情があります。営業時代の表現で言えば、「商社経由なら、与信・契約書・コンプラ書類が既存の取引枠の中で処理される」 という構図そのものです。

ただし、ここでも一つ強調しておきたい点があります。「Bedrock 経由なら自動でコンプラ適合する」とは申し上げません。AWS のインフラ部分は認証を取得していても、「プロンプトに何を入れるか」「データ保持期間をどう設定するか」「社内ポリシーとどう整合するか」は別途自前で整える必要があります。詳細は セクション 10「エンタープライズでの選択軸」と セクション 12「失敗パターン」で改めて扱います。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

05 — Bedrock の料金構造——On-demand と Provisioned Throughput の 2 軸

📖 この章で使う用語

  • On-demand 課金：使った分だけ後払いで請求される従量課金方式。
  • Provisioned Throughput：一定の処理能力を事前予約する月額制。「タクシーの相場運賃 vs 月極専属契約」のイメージ。
  • TPS（Tokens Per Second）：1 秒あたりに処理できるトークン数（処理速度の指標）。
  • トークン：LLM が文章を分割する単位。日本語 1 文字 ≒ 1〜1.5 トークンが目安。
  • リージョン：AWS のデータセンター地理（us-east-1 = 米国東部バージニア、ap-northeast-1 = 東京 など）。

ここで料金構造を整理します。Bedrock の料金は時期・モデル・リージョンで変動するため、最新の数字は AWS 公式の Bedrock pricing ページと Anthropic 公式の pricing ページで必ず事前確認してください（本記事末尾の「出典」セクションを参照）。本セクションの記述は 2026 年 5 月時点の構造的な整理であり、具体的な単価は時期で変わります。

なお、本セクションは私の業務本番運用ベースではなく、Anthropic 直 API との料金比較を業務でコスト最適化判断したときの経験 + AWS 公式 pricing ページの公開情報からの整理です。Provisioned Throughput の具体的な予約タイミング・Inference Profiles の活用テクニックなど、料金最適化の細部は業務本番運用の経験がないため、AWS 公式と大手 SI ブログを参照する公開情報からの整理として扱います。

05-1. On-demand（per-token 課金）——使った分だけ課金

Bedrock の標準的な課金は On-demand（per-token）方式 です。Anthropic 直 API とまったく同じ「100 万トークンあたり $X」のモデルで、月末にまとめて使った分だけ請求されます。

たとえば 2026 年 5 月時点、AWS 公式 pricing ページに掲載されている Claude 3.5 Sonnet の Bedrock 経由 On-demand 料金は、Anthropic 直 API の公式料金とほぼ同等水準です。出典は AWS 公式 / Anthropic 公式の pricing ページ（本記事末尾の「出典」セクションを参照、最新は必ず公式で事前確認）。

営業時代のたとえだと、On-demand は 「タクシーの相場運賃」 に近い感覚です。乗った分だけ請求される。短時間・少量利用なら一番素直な選択肢です。

05-2. Provisioned Throughput（時間単位の予約枠）——大量バッチ向け

もう 1 つの課金体系が Provisioned Throughput です。「常時 N TPS（1 秒あたり N トークン）を処理できる枠を、1 ヶ月・6 ヶ月単位で予約する」という時間契約型の課金です。

これが活きるのは、大量バッチ処理を高負荷で走らせる業務本番運用シナリオ——たとえば「毎日 100 万件のドキュメントを Claude に要約させる夜間バッチ」のようなケースです。On-demand で走らせるとリクエスト数で見積もりが立てづらく、Provisioned Throughput なら月額固定の予算枠として稟議に通しやすい、という現実的な事情もあります。

営業時代のたとえで書くと、Provisioned Throughput は 「月極の専属タクシー契約」 のイメージです。毎月使うのが分かっているなら月極の方が単価は下げられる。ただし、使わない月でも料金は発生します。

05-3. Anthropic 直 API の料金との比較（2026 年 5 月時点）

両者の料金を比較すると、2026 年 5 月時点では Bedrock の On-demand と Anthropic 直 API の公式価格は、ほぼ同等水準です。AWS の上乗せはほぼゼロ〜小幅、というのが業界の一般的な観察と一致します（出典は AWS 公式 / Anthropic 公式の pricing ページ、本記事末尾の「出典」セクションを参照）。

私が業務でコスト最適化判断をしたときの感触としては、**「料金差で Bedrock を選ぶ理由は薄い、選ぶ理由は料金外のメリット（IAM・VPC・監査ログ・契約集約）」**でした。「Bedrock の方が安いから乗り換える」ではなく、「組織要件で Bedrock の方が運用が楽になるから乗り換える」が、現実的な判断軸だと思います。

05-4. 「絶対こちらが安い」とは申し上げない理由——変動と運用差

最後にメタ宣言を 1 つ。料金は時期・モデル・リージョン・利用量・契約形態で振れます。「絶対 Bedrock の方が安い」「絶対 直 API の方が安い」とは申し上げません。

判断軸として置きたいのは、次の 3 点です。

  • 単価：100 万トークンあたりの $（公式 pricing ページで最新確認）
  • 運用コスト：自前で IAM・監査ログ・キー管理を組む工数 vs Bedrock の AWS 統合
  • 将来の負荷見込み：大量バッチが固定的に走るなら Provisioned Throughput が効く

最新の料金は aws.amazon.com/bedrock/pricing/ と anthropic.com/pricing で必ず事前にご確認ください。半年経つと変わっている可能性が高い領域です。

06 — Anthropic 直 API vs Bedrock 経由 Claude——5 シーン別の使い分け

📖 この章で使う用語

  • PoC（Proof of Concept）：本番投入前の概念実証。「試作品で動くかを確かめる段階」。
  • キー管理：API キーを誰が持つか・どこに保管するか・どう失効するかの運用ルール。
  • マルチプロバイダ運用：複数の LLM プロバイダ（Claude + Llama + Mistral など）を併用する構成。

ここからが、SERP 上位がほとんど書いていない独自軸です。Bedrock 経由 Claude と Anthropic 直 API を、5 つのシーン別に使い分ける——私のこれまでの選定整理の経験から、シーンごとに「どちらを選ぶか」を並べます。

なお、本セクションの判断は私個人の業務観察 + 公開情報からの整理であり、組織の状況によって振れ幅があります。「絶対これ」とは申し上げません。最終判断はチームの状況・要件・予算でご判断ください。

06-1. シーン 1：個人検証・小規模 PoC——直 API で 5 分スタート

「ChatGPT API や Claude をまず触ってみたい」「PoC を社内で 1 週間で動かしたい」というシーンでは、Anthropic 直 API の方が圧倒的に始めやすいです。

理由はシンプルで、API キーを 1 本発行してプログラムに貼るだけで動くからです。AWS アカウントの IAM ユーザー作成、ロール設計、Bedrock の Model access 申請、リージョン選択といった事前準備が一切要りません。私の業務でも、新機能の手触りを確認するときは、まず Anthropic 直 API で動かして感触を掴んでから、本番投入の検討に入ります。

営業時代のたとえだと、「サンプル品を 1 個だけ取り寄せる」 イメージです。商社経由だと与信書類が必要だけど、メーカー直販なら 1 個だけ買える。

06-2. シーン 2：業務本番運用（少人数 / スタートアップ）——直 API + 自前キー管理で回る

「自社プロダクトに Claude を組み込みたい」「5〜10 人規模のチームで本番運用したい」というシーンでも、Anthropic 直 API + 自前のキー管理 + Slack 通知で十分回ります。私自身、業務本番運用のメインはこのルートです。

このシーンでは、Bedrock の IAM 統合や監査ログ集約のメリットが、運用負荷に対して過剰になりがちです。AWS アカウントの設計を一からやるコストよりも、Anthropic 直 API キーを 1 password で管理して、利用量を Anthropic ダッシュボードで監視する方が、運用が軽くなります。

ただし、チームが 20 人以上になり、IAM 統制が必要になった段階で、Bedrock 移行の検討に入る——という分水嶺の感覚は持っておいた方が安全です。チームが大きくなってから「やっぱり Bedrock にすればよかった」と移行するコストの方が、最初から Bedrock で組んでおくコストより重いケースもあります。

06-3. シーン 3：エンタープライズ（既存 AWS 環境あり）——Bedrock 経由で IAM 統合

「自社が既に AWS をメインクラウドとして使っている」「IAM 統制・VPC・CloudTrail 監査ログがすべて AWS で組まれている」というエンタープライズ環境では、Bedrock 経由が現実的です。

このシーンでは、Bedrock の IAM 連携・VPC 内通信・監査ログのメリットが、既存資産として活きます。Anthropic 直 API を別ルートで導入すると、AI 利用だけのために別系統の権限管理・ログ集約・契約書を整備する必要が出てきて、運用が重くなる。

営業時代のたとえだと、「既に商社と取引があるなら、新製品もその商社経由で買った方が稟議が早い」 という、極めて実務的な判断軸です。

06-4. シーン 4：コンプラ要件（金融 / 医療 / 公共）——Bedrock 経由で AWS 既存認証

「金融機関で生成 AI を導入したい」「医療情報を扱う業務に Claude を組み込みたい」「公共系の事業で AI を使いたい」というシーンでは、Bedrock 経由が選択肢として強く効きます。

理由は セクション 4-4 で書いた通り、AWS の BAA / SOC 2 / ISO 27001 などの認証が継承される点と、VPC 内通信で「データの域外流出」を最小化できる点です。Anthropic 直 API でも独自に認証は取得していますが、組織のセキュリティ部門との会話のしやすさで、Bedrock 経由の方が稟議が通りやすい傾向があります。

ただし、ここでも繰り返しメタ宣言を入れます。「Bedrock 経由なら金融・医療・公共で必ず安全」とは申し上げません。インフラ部分の認証だけでは、業界ガイドライン（金融庁・個人情報保護法・医療情報ガイドライン等）への適合は完結しません。詳細は セクション 10 で扱います。

06-5. シーン 5：マルチプロバイダ運用——Bedrock 経由でモデル間切替

「Claude を主軸にしつつ、特定用途で Llama / Mistral を併用したい」「将来の OSS LLM への移行可能性も視野に入れたい」というマルチプロバイダ運用のシーンでは、Bedrock 経由が一括で扱えて楽です。

Bedrock 上では、モデル ID（例：anthropic.claude-3-5-sonnet-20240620-v1:0、meta.llama3-1-70b-instruct-v1:0）を切り替えるだけで複数プロバイダのモデルを呼べます。Anthropic 直 API ＋ OpenAI API ＋ Google AI Studio を並列で組むよりも、AWS の 1 つの SDK・1 つの認証で完結します。

ただし、各モデルの細かい癖（応答の長さ・日本語の自然さ・特定タスクでの誤答パターン）は実際に触らないと分かりません。マルチプロバイダ運用は「設計上の柔軟性」のメリットが大きく、「実運用で全モデルを毎日切り替える」ことは稀、というのが私の選定整理の経験からの感覚です。

07 — Bedrock 経由で Claude Code を動かす——v6 急成長 +2,300% の派生需要

📖 この章で使う用語

  • Claude Code（CLI）：Anthropic 公式の AI コーディング CLI ツール。コマンドラインからフォルダ単位で AI に作業を任せる。詳しくは Claude Code 使い方 で扱っています。
  • 環境変数：プログラム実行時に外部から与える設定値。API キー・モード切替などに使う。
  • AWS 認証情報：AWS リソースにアクセスするためのアクセスキー / シークレットキー / IAM ロール。

ここからは、サジェスト 5 位「claude code」を吸収する派生需要です。Claude Code（Anthropic 公式の AI コーディング CLI）を Bedrock 経由で動かす——v6 ラッコ実測で +2,300% の急成長を示している、SERP がまだ薄い領域です。

最初にメタ宣言です。Bedrock 経由で Claude Code を動かすのは、私の場合は個人検証レベルで触っているにとどまり、業務本番運用ではありません。本セクションは「公開情報からの整理 + 概念レベルでの触り心地」までです。具体的なセットアップ手順や本番投入時の注意点は、Anthropic 公式と AWS 公式の最新ドキュメントを必ずご参照ください。

07-1. 「Bedrock 経由で Claude Code」の意味と位置づけ

Claude Code は、ターミナルでフォルダ単位の作業を AI に任せる CLI ツールです（詳しくは Claude Code 使い方 で扱っています）。標準では Anthropic 直 API 経由で動きます。

「Bedrock 経由で Claude Code を動かす」というのは、Claude Code の認証バックエンドを Anthropic 直 API から AWS Bedrock に切り替えることを指します。意味は次の通りです。

  • 個人開発：Anthropic 直 API で十分。個人の API キー 1 本で動く
  • 組織導入：Bedrock 経由のメリットが活きる。IAM 統制で「エンジニアごとに Claude Code 利用権限を制御」「全エンジニアの Claude Code 利用ログを CloudTrail に集約」できる

組織で複数エンジニアに Claude Code を配るとき、Anthropic 直 API キーを個別に発行・管理するのは運用負荷が大きい。Bedrock 経由なら、既存 AWS の IAM ロールで「このチームは Claude Code を使える」「このユーザーは Opus も Sonnet も呼べる」と一括統制できる、というのが導入意義です。

07-2. セットアップの概念（環境変数・AWS 認証情報・モデル ID）

具体的なセットアップ手順は Anthropic 公式の最新ドキュメントで必ず確認していただきたいのですが、概念レベルでは次の 4 ステップです（2026 年 5 月時点）。

  1. AWS アカウントと IAM 認証情報の準備：aws configure でアクセスキー / シークレットキー / リージョンを設定
  2. Bedrock の Model access 申請：AWS Management Console > Bedrock > Model access から、使いたい Claude モデル（Opus / Sonnet / Haiku）を「Request access」で申請
  3. Claude Code の Bedrock 経由モード切り替え：環境変数（Anthropic 公式仕様の最新版を必ず確認）で Bedrock 経由を指定
  4. リージョン指定とモデル ID 指定：Bedrock 用のモデル ID（例：anthropic.claude-3-5-sonnet-20240620-v1:0）を指定

具体的なコマンドのイメージは次のようになります（最新仕様は Anthropic 公式で必ず確認）。

# AWS 認証情報の準備
aws configure
# AWS Access Key ID / Secret Access Key / Default region / Output format を入力

# Bedrock 経由モードの環境変数（Anthropic 公式仕様の最新版を必ず確認）
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export ANTHROPIC_MODEL=anthropic.claude-3-5-sonnet-20240620-v1:0

# Claude Code を起動
claude

繰り返しになりますが、上記は概念レベルでの説明です。実際の環境変数名・モデル ID・リージョン提供状況は時期で変わるため、Anthropic 公式の Claude Code ドキュメントを必ず最新で参照してください。

07-3. 個人開発（直 API）vs 組織導入（Bedrock 経由）の差

観点個人開発（直 API）組織導入（Bedrock 経由）
始めやすさ◎ API キー 1 本で 5 分△ AWS IAM 設計が前提
権限統制△ 個別キー管理◎ IAM で一括統制
監査ログ△ 自前で組む◎ CloudTrail 自動集約
コスト統合△ Anthropic 個別請求◎ AWS 既存請求に統合
新機能の反映速度◎ 即時△ Bedrock 側の追従待ち

個人開発と組織導入で住み分け、というのが私の選定整理の経験からの感覚です。組織で 10 人以上のエンジニアに Claude Code を配るタイミングで Bedrock 経由を検討する、というのが現実的な分水嶺だと思います。

Claude Code の基本的な使い方やセットアップ全般は Claude Code 始め方 と Claude Code 使い方 で詳しく扱っているので、本記事と並行して読んでいただくと、Bedrock 経由の位置づけが立体的に見えてきます。

08 — Bedrock Agents と AgentCore——エンタープライズ向け AI エージェント基盤の最新動向

📖 この章で使う用語

  • Bedrock Agents：Bedrock 上で動く AI エージェント構築サービス。ツール呼び出し・Knowledge Bases・Action Groups を統合。
  • AgentCore：Bedrock Agents の発展形として AWS が打ち出している、エンタープライズ向け AI エージェント基盤の最新動向（2026 年 5 月時点）。
  • Knowledge Bases：Bedrock の社内 RAG（社内ドキュメント検索）機能。詳しくは RAG とは で概念を扱っています。
  • Action Groups：Bedrock Agents で外部 API を呼び出すための機能群。「エージェントが使える道具箱」のイメージ。

ここではサジェスト 9 位「agentcore」を吸収します。Bedrock Agents と AgentCore——エンタープライズ向け AI エージェント基盤として AWS が打ち出している最新動向を整理します。

最初にメタ宣言です。**Bedrock Agents は私の場合は概念整理レベルまで、AgentCore は最新動向把握程度（業務本番運用なし）**です。本セクションの記述は、AWS 公式ドキュメント・re:Invent などの公開情報からの整理に、私のエージェント業務利用（直 API ベース）の経験を重ねたものです。

08-1. Bedrock Agents——既存機能の整理

Bedrock Agents は、Bedrock 上で動く AI エージェント構築サービスです（出典は AWS 公式の Bedrock Agents ページ、本記事末尾の「出典」セクションを参照）。

主な構成要素は次の 3 つです。

  • ツール呼び出し：エージェントが特定の関数・API を呼び出して結果を取得する仕組み
  • Knowledge Bases：社内ドキュメント・PDF・FAQ などをベクトル DB に取り込み、RAG で検索できる機能
  • Action Groups：外部 API（社内システム / SaaS）を呼び出すための機能群

整理すると、Bedrock Agents は 「AWS が用意するエージェント構築フレームワーク」 という位置づけです。エージェント構築の他のルート（Python + LangChain/LangGraph / ノーコード / Microsoft Copilot Studio / Claude Projects + GPTs）は、AIエージェント 作り方 で 4 ルート全体を扱っています。Bedrock Agents は「AWS ネイティブの 5 つ目のルート」のような位置づけです。

私が業務でエージェントを組むときのメインルートは、Python + LangChain/LangGraph + Anthropic 直 API です。Bedrock Agents は概念整理レベルまで、業務本番運用での利用経験はありません。本記事の記述は AWS 公式ドキュメントと業界の公開情報からの整理になります。

08-2. AgentCore——2026 年 5 月時点の最新動向（公式参照前提）

AgentCore は、Bedrock Agents の発展形として AWS が打ち出している エンタープライズ向け AI エージェント基盤の最新動向 です（2026 年 5 月時点）。主な狙いは、エージェントのライフサイクル管理（記憶・状態管理）、複数エージェントの協調、エンタープライズグレードのセキュリティ・スケーラビリティ・監査機能を統合的に提供することと観察しています。

ただし、AgentCore は 2026 年 5 月時点で動向把握中の最新領域であり、本記事では「概念上どんなものとして打ち出されているか」のレベルにとどめます。具体的な仕様・利用方法・料金体系は、AWS 公式の最新発表（re:Invent や AWS Blog）を必ず参照してください。SERP 上位もまだ薄い領域で、半年経つと状況が大きく変わる可能性が高いです。

サジェスト 9 位に「agentcore」が入っていることからも、エンタープライズ層の関心が高い領域だと感じます。本記事ではあくまで「Bedrock の中にこういう発展領域がある」というポインタの提示にとどめ、深掘りは公式ドキュメントへ送ります。

08-3. 既公開「AIエージェント とは」「作り方」との役割分担

ここで既公開記事との役割分担を明示しておきます。

  • AIエージェント とは：AI エージェントの概念ハブ。エージェントとは何か、なぜ必要か、どんな種類があるか
  • AIエージェント 作り方：構築 4 ルート全体（Python + LangChain/LangGraph / ノーコード / Microsoft Copilot Studio / Claude Projects + GPTs）
  • 本記事の セクション 8：Bedrock Agents と AgentCore、つまり「AWS ネイティブのエージェント構築基盤」

エージェントの概念が新しい方は、まず AIエージェント とは で全体像を掴んでから本記事に戻っていただくと、Bedrock Agents の位置づけが見えやすくなります。

最後にもう一度メタ宣言を。「Bedrock Agents や AgentCore を使えば、エージェントが必ず動く」とは申し上げません。エージェント構築は、ルートに関わらず、設計・実装・運用のすべてで難易度の高い領域です。最新仕様は AWS 公式で必ず事前確認、本番投入前に PoC で動作検証、を強くおすすめします。

09 — Bedrock の基本的な使い方——コンソールから Python SDK の最小サンプルまで

📖 この章で使う用語

  • boto3：AWS の公式 Python SDK。AWS の全サービスを Python から叩ける。「AWS への注文票を Python から出すための道具」。
  • アクセスキー / シークレットキー：AWS の認証情報のペア（パスワードに相当する文字列）。
  • Anthropic SDK on Bedrock：Anthropic 公式の Python SDK の中で Bedrock 経由の認証情報を渡せる機能。

ここでサジェスト 10 位「使い方」を吸収します。Bedrock を「最小の試運転」で触る 3 ステップを整理します。

本セクションの記述は、私が概念と選定の整理レベルで触っている範囲です。業務本番運用に必要な認証情報のセキュア管理（Secrets Manager / IAM ロール）、エラー処理、リトライ、コスト監視、ログ集約などは別途自前で整える必要があり、本セクションの最後でその点も明示します。

09-1. ステップ 1：AWS アカウントとモデルアクセスの有効化

まず、AWS アカウントを準備します。既に持っている方はそのまま、初めての方は AWS の無料利用枠で作成します（クレジットカード登録が必要、本人認証あり）。出典は AWS 公式の Getting started ページ（本記事末尾の「出典」セクションを参照）。

次に、Bedrock の Model access 申請を行います。AWS Management Console にログインし、Bedrock サービスを開き、左メニューの「Model access」から、使いたいモデル（例：Anthropic Claude 3.5 Sonnet）を選んで「Request access」をクリックします。

AWS Console → Bedrock → Model access
  → 使いたいモデル（Claude 3.5 Sonnet 等）を選択
  → Request model access
  → 申請理由を入力
  → 承認待ち（モデルによっては自動承認、人間レビューが必要なものもあり）

一部の高性能モデルは事前申請・承認制で、承認まで数時間〜数日かかる場合があります。最新の承認プロセスは AWS 公式で必ず確認してください。

09-2. ステップ 2：AWS 認証情報の準備（aws configure）

ローカル PC から Bedrock を呼び出すには、AWS の認証情報が必要です。AWS CLI をインストール後、aws configure コマンドで認証情報をローカルに保存します。

# AWS CLI のインストール（macOS / Homebrew の例）
brew install awscli

# 認証情報の設定
aws configure
# AWS Access Key ID [None]: AKIA...（IAM ユーザーのアクセスキー）
# AWS Secret Access Key [None]: ...（シークレットキー）
# Default region name [None]: us-east-1
# Default output format [None]: json

ここで使う アクセスキー / シークレットキー は、AWS IAM Console で発行した IAM ユーザーのキーです。本番運用では IAM ユーザーのアクセスキーをローカルに置きっぱなしにせず、IAM ロール（EC2 / ECS / Lambda 等のサービス側）または AWS Secrets Manager 経由で管理するのが基本です。本セクションは「最小の試運転」用なので、アクセスキー直書きの簡易版を載せていますが、本番投入時は別途設計が必要です。

09-3. ステップ 3：Python SDK（boto3）の最小サンプル（コード例）

ここで Python boto3 で Claude Sonnet を呼び出す最小サンプルを載せます。出典は AWS 公式の Bedrock User Guide（本記事末尾の「出典」セクションを参照）。

# bedrock_minimal.py — Bedrock 経由で Claude Sonnet を呼び出す最小例
import boto3
import json

# Bedrock Runtime クライアントを作成（リージョンを指定）
client = boto3.client("bedrock-runtime", region_name="us-east-1")

# Claude 3.5 Sonnet を呼び出す（モデル ID は時期で変わるため最新を要確認）
response = client.invoke_model(
    modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 1024,
        "messages": [
            {"role": "user", "content": "こんにちは、自己紹介してください。"}
        ],
    }),
)

# レスポンスを JSON でパース
result = json.loads(response["body"].read())
print(result["content"][0]["text"])

このコードを python bedrock_minimal.py で実行すると、Claude Sonnet が日本語で自己紹介を返してくれます。**動いた瞬間が、Bedrock 体験の「最初の一歩」**です。

なお、Anthropic 公式の Python SDK でも Bedrock 経由を扱えます。boto3 直叩きとの違いは、Anthropic SDK の方が「メッセージ構造の扱い・チャット履歴の管理・型ヒントによる開発体験」が手厚い点です。具体的なコード例は Anthropic 公式の SDK ドキュメントをご参照ください（本記事末尾の「出典」セクションを参照）。

09-4. 業務本番運用に進む前に必要なもの（Secrets / ログ / コスト監視）

ここでメタ宣言を再度入れます。上記の最小サンプルは「概念整理レベルの最小例」であり、業務本番運用にはこのままでは使えません。本番投入の前に、最低限以下を別途整える必要があります。

  • 認証情報のセキュア管理：アクセスキーをコードに直書きしない、AWS Secrets Manager または IAM ロールで管理
  • エラー処理とリトライ：API レート制限・ネットワークエラー・モデル側の一時障害への対応
  • タイムアウト設定：長いプロンプトでハングしないよう適切なタイムアウト
  • コスト監視：CloudWatch アラーム / AWS Cost Explorer で月次予算を超えそうな場合に通知
  • ログ集約：CloudTrail / CloudWatch Logs で利用状況を集約、社内 SIEM への連携
  • 入力データの運用ルール：機密情報・個人情報をプロンプトに含めない運用設計

このあたりは「公開情報からの整理」のレベルで、AWS 公式の Bedrock ベストプラクティスや大手 SI ブログを参照しながら設計するのが現実的です。最終判断は社内の情シス・SRE・セキュリティ部門との協議でご判断ください。

10 — エンタープライズでの選択軸——金融・医療・製造業・公共での Bedrock 採用判断

📖 この章で使う用語

  • 金融庁ガイドライン：金融機関のシステム運用に関する金融庁の指針（FISC 安全対策基準など）。
  • 個人情報保護法：日本の個人情報の取り扱いを定める法律。
  • 個人番号法（マイナンバー法）：マイナンバー（個人番号）の取り扱いを定める法律。
  • 自治体情報セキュリティポリシー：地方自治体の情報セキュリティ対策の指針（総務省ガイドラインに準拠）。

ここからは、エンタープライズ層、特に 金融・医療・製造業・公共 の業界別に、Bedrock 採用の判断軸を整理します。SERP 上位がほとんど書かない独自軸で、本記事のペルソナ（企業利用検討の現役・志望エンジニア + 社内で Bedrock 採用を検討する技術リード層）に直接届く内容を狙います。

最初に 三段階のメタ否定 を発動します。

  1. 「Bedrock 経由なら金融・医療・公共で必ず安全」とは申し上げません
  2. 「AWS の認証だけで業界ガイドライン適合が完結する」とは申し上げません
  3. 最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください

本セクションは私の業界 SE としての守秘義務の範囲内で、概念と選定の整理レベルまでの記述です。業界別の具体事例・最新の認証状況は、AWS 公式・業界団体・大手 SI のブログを参照する公開情報からの整理として扱います。

10-1. 金融——金融庁ガイドラインと VPC 内通信・監査ログ要件

金融機関で生成 AI を導入する場合、金融庁の各種ガイドライン（FISC 安全対策基準など）への適合が前提になります。特に重視されるのは次の論点です。

  • データの域外流出防止：顧客情報・取引情報がインターネット経由で社外に出ない構成
  • 監査ログの完全性：誰が・いつ・どの情報を AI に渡したかの完全な記録
  • アクセス権限の最小化：必要最低限のロールのみ AI 利用権限を持つ
  • データ保持期間の制御：AI ベンダー側でのデータ保持期間の明示

Bedrock 経由なら、VPC 内通信（PrivateLink）でインターネット経由を回避でき、CloudTrail で監査ログを既存基盤に集約でき、IAM で権限統制でき、AWS と直接 SLA を結べる、という点で要件適合性が高い、というのが一般的な観察です。

ただし、金融庁ガイドラインへの適合は AWS のインフラだけでは完結しません。プロンプトに何を入れるか、どの情報を AI に渡すか、データ保持期間をどう設定するか、社内の情報管理規程とどう整合させるかは、別途設計が必要です。出典は金融庁公式の各種ガイドラインページ（本記事末尾の「出典」セクションを参照）と、AWS 公式の金融機関向け事例ページをご参照ください。

10-2. 医療——個人情報保護法・BAA・機密患者情報の取り扱い

医療系で生成 AI を導入する場合、個人情報保護法（特に要配慮個人情報）と医療情報ガイドラインへの適合が前提です。

Bedrock では、医療系の業務委託契約である BAA（Business Associate Agreement） を AWS と直接締結できるモデルがあります（出典は AWS 公式の HIPAA 対応ページ、本記事末尾の「出典」セクションを参照）。これにより、米国 HIPAA 等の医療法令準拠が必要なシステムでも、AWS 経由で Claude を利用する選択肢が開けます。

ただし、日本の医療情報ガイドライン（厚生労働省・経済産業省・総務省の 3 省 2 ガイドライン）への適合は別途設計が必要です。患者情報をプロンプトに含める運用、データ保持期間、第三者提供の同意取得など、業界固有の論点が積み重なります。最終判断は医療情報管理者・法務・専門の弁護士の方へご相談ください。

10-3. 製造業——設計図・特許情報・サプライチェーンの機密性

製造業では、設計図・特許情報・サプライチェーン情報の機密性が論点になります。グローバル製造業の場合は、各国の輸出管理規制・地政学的なデータ越境制限も視野に入ります。

Bedrock の リージョン選択——どの国のデータセンターで処理するか——が重要な判断軸になります。「設計データは国内リージョン（ap-northeast-1 = 東京）に限定」「特許関連の情報は米国リージョンを経由しない」といった要件設定が、本番投入前の設計段階で必要です。

なお、競合他社情報・社外秘情報を AI に渡す運用は、AWS のインフラ部分の認証だけでは安全性が担保されません。「設計図を AI に渡して要約させる」運用は、社内の情報管理規程と整合するかを必ず事前確認してください。

10-4. 公共・自治体——個人番号法・自治体情報セキュリティポリシー

公共・自治体での生成 AI 導入は、個人番号法（マイナンバー法）・自治体情報セキュリティポリシーへの適合が前提です。住民情報・税情報・社会保障情報の機密性は最高レベルで保護される必要があります。

Bedrock では、AWS の政府機関向け認証（米国の FedRAMP など）を保持しているリージョンがありますが、日本の自治体情報セキュリティポリシー（総務省ガイドライン）への適合は、AWS 認証とは別系統で整える必要があります。

公共・自治体での生成 AI 導入は、特に最新の総務省ガイドライン・自治体クラウド検討部会の動向を追う必要があります。最終判断は自治体の情シス・情報管理担当・住民情報保護担当・専門の弁護士の方へご相談ください。

10-5. 全業界に共通する三段階の安全網

業界を問わず、以下の三段階を本番投入前に必ず確認してください。

  1. AWS / Anthropic の最新 SLA・利用規約・セキュリティホワイトペーパーの確認：契約段階で詳細を読む
  2. 社内ポリシーとの整合確認：情シス・法務・コンプライアンス部門との事前協議
  3. PoC 段階での運用テスト：本番投入前に小規模で運用してリスクを洗い出す

「Bedrock を採用すれば必ず安全」「業界ガイドラインに必ず適合する」とは申し上げません。安全は AWS のインフラ部分とアプリケーション側の運用設計が両輪で揃ったときに成立する、というのが現役エンジニアの正直な感触です。

11 — Bedrock を、エンジニアでない人がどう関わるか——非エンジニア 5 ユースケース

📖 この章で使う用語

  • 稟議：社内で意思決定を得るための申請プロセス。「社内の決裁ルート」。
  • 比較表：選択肢を並べて評価する社内資料の定型フォーマット。
  • 情シス：情報システム部門。社内 IT インフラ・セキュリティ・調達を管轄。

Bedrock は API 基盤のサービスなので、非エンジニアの方が直接コードを書いて触る場面は限定的です。一方、組織導入の意思決定・周辺業務・社内提案では関わる場面が確かにあります。本セクションでは 5 つの職種別の関わり方を整理します。

なお、本セクションの 5 ユースケースは私が営業 7 年・エンジニア 6 年弱の経験から「こういう関わり方があり得る」と整理したもので、「これをすれば必ず成果が出る」「Bedrock を提案すれば必ず受注できる」とは申し上げません。

11-1. 営業職（IT 営業・コンサル系）

Before：顧客企業の IT 部長に「ChatGPT API を使った社内ボットを作りたい」と相談されたが、Anthropic 直 API と AWS Bedrock の違いが説明できず、概要だけ話して持ち帰り検討にした。 After：「個人検証は直 API で 5 分、組織導入で IAM・VPC・監査ログを統合したいなら Bedrock 経由」と一行で説明でき、IT 部長から「うちは AWS をメインで使っているから Bedrock の方向で検討したい」と前向きな反応を引き出せた。 所要時間：本記事を 30 分読む。AWS 公式の Bedrock ページを 30 分眺める。合計 1 時間。 最初の壁：AWS の専門用語（IAM / VPC / PrivateLink / CloudTrail）への馴染みのなさ。営業時代の私自身、エンジニアに切り替わったときは「IAM って何ですか」を毎日聞いていました。

私自身が営業時代だったら、IT 部門への提案で必ず Bedrock 経由の選択肢を最初から並べていたと思います。「お客様の既存環境を踏まえた選択肢提示」は、商談での信頼度に直結します。

11-2. 事務職（情シス補助・部門 IT 担当）

Before：社内の AI 導入検討の比較表を作るよう情シスから依頼されたが、Anthropic 直 API と Bedrock の違いを 1 行でまとめられず、「両方ありますね」とだけ書いた。 After：「直 API = 個人検証・小規模向け、Bedrock = 組織導入・コンプラ要件向け」と比較表の 1 列目で整理でき、稟議資料に「組織導入は Bedrock 経由を推奨」の提案を入れられた。 所要時間：本記事 1 時間 + AWS 公式 Bedrock ページ 1 時間。合計 2 時間。 最初の壁：稟議資料への落とし込み——技術用語を「上層部にも分かる日本語」に翻訳すること。

事務職の方が情シス補助で AI 導入比較表を作る場面では、本記事 セクション 6「5 シーン別の使い分け」をそのまま比較表のテンプレートとして使っていただけると思います。

11-3. 個人事業主（士業・コンサル）

Before：クライアント企業から「生成 AI を導入したい、相談に乗ってほしい」と依頼があったが、技術選定（直 API か Bedrock 経由か）の助言ができず、技術選定は別のベンダーに任せる形になり、提案範囲が狭くなった。 After：「クライアントの既存環境が AWS なら Bedrock 経由を検討」「初回検証は直 API で 1 ヶ月触ってから決める」と段階的なアドバイスができ、技術選定段階から関わって提案範囲を広げられた。 所要時間：本記事 1 時間 + AWS / Anthropic 公式の pricing と docs を週末 2 時間。合計 3 時間。 最初の壁：AWS の最新動向の追従——AgentCore など新興機能のキャッチアップにかかる時間。

個人事業主の方は、クライアント企業の意思決定に同席する場面で「直 API or Bedrock」の選択肢を整理できると、技術ベンダーへの丸投げを避けられます。

11-4. 副業ライター（IT 系記事執筆）

Before：IT 系メディアから「AWS Bedrock の入門記事を書いてほしい」と依頼があったが、Anthropic 直 API との違いを整理できず、AWS 公式ドキュメントを翻訳するだけの記事になってしまった。 After：「直 vs Bedrock」「5 シーン別の使い分け」「料金構造」「Claude Code 連携」「AgentCore」など独自切り口で記事を書けるようになり、リライトの精度が上がって編集者の評価も高まった。 所要時間：本記事 30 分 + AWS / Anthropic 公式ドキュメント 1 時間。合計 1.5 時間。 最初の壁：AWS 専門用語（IAM / VPC / Bedrock Agents / AgentCore）の追加学習。

副業ライターの方は、本記事の構造（セクション 1 結論 → セクション 2 概念 → セクション 6 直 vs Bedrock → セクション 10 業界別）を「IT 記事の骨格テンプレート」として再利用できると思います。

11-5. 銀行員・社内 IT 担当（金融系企業）

Before：自社で生成 AI 導入を検討したいが、社内ポリシーで「インターネット経由で社外 API を叩く」のが原則 NG。Anthropic 直 API は社内で却下され、議論が止まっていた。 After：「Bedrock 経由なら VPC 内通信（PrivateLink）でインターネット経由を回避でき、CloudTrail で監査ログも既存基盤に集約できる」と情シスに説明でき、PoC 段階での導入検討が動き始めた。 所要時間：本記事 + 金融庁ガイドライン確認 + 情シス相談で合計 5〜10 時間。 最初の壁：社内ポリシーの最新確認——半年単位で更新される金融機関のセキュリティガイドラインの追跡。

ペルソナ・シュウヘイ（24 歳・地銀員）のような方が、社内で生成 AI 導入の検討を進める初動として、本記事の セクション 10-1 と セクション 6-4 を情シスとの会話の起点に使っていただけると思います。最終判断は社内の情シス・コンプライアンス部門・専門の弁護士の方へご相談ください。

12 — Bedrock 採用でハマる失敗パターン 5 つ——「Bedrock 経由なら全部安全」を避けるために

📖 この章で使う用語

  • Model access：Bedrock コンソールで使いたいモデルへのアクセスを申請する仕組み。
  • リージョン別モデル提供表：各モデルがどのリージョン（us-east-1 / ap-northeast-1 など）で利用可能かの対応表。
  • AWS Cost Explorer：AWS の料金分析ダッシュボード。
  • CloudWatch アラーム：監視メトリクスが閾値を超えたら通知する仕組み。

ここでは、Bedrock 採用でハマりがちな 5 つの失敗パターン を整理します。出典は私の業務観察と AWS 公式の Bedrock ベストプラクティス、大手 SI ブログの公開情報からの整理です。「これに気をつければ必ず成功する」とは申し上げませんが、いずれも初動でつまずきやすいポイントです。

12-1. モデルアクセス申請を忘れる

最初に多い失敗が、Bedrock の Model access 申請を済ませず、いきなり SDK でモデルを叩いてエラーになるケースです。AWS Management Console > Bedrock > Model access で「Request access」を行わないと、SDK 側でアクセス拒否（AccessDeniedException）が返ります。

対策は コンソールでの事前申請の手順を最初の 1 回でマニュアル化しておくこと。複数モデルを使う場合は、全モデルの申請状況を一覧で確認できるドキュメントを社内に残しておくと、新しいエンジニアが入ったときの立ち上がりが楽になります。

12-2. リージョン選択を間違える

次に多いのが、us-east-1 で叩いたつもりが ap-northeast-1（東京）にしていて、モデルが未提供エラーになるケースです。Bedrock の各モデルは、リージョンによって提供状況が異なります。

対策は リージョン別のモデル提供表を AWS 公式で必ず事前確認すること。「東京リージョンで使えるモデル / 米国東部で使えるモデル」を最初に整理してから設計を始めると、後から「リージョン跨ぎでデータ転送料金が上乗せされた」事故も避けられます。

12-3. 「Bedrock 経由なら自動でコンプラ適合」と思い込む

これが組織導入で最も致命的な失敗パターンです。AWS のインフラ部分は SOC 2 / ISO 27001 などの認証を取得していても、プロンプトに入れる情報の運用ルール・データ保持期間・社内ポリシーとの整合は別途自前で整える必要があります。

「AWS が認証取ってるから大丈夫」だけで本番投入すると、後から情シスや法務に「機密情報をプロンプトに入れた」運用で指摘を受けるケースが出てきます。対策は 社内の情シス・法務・コンプライアンス部門との事前すり合わせを必ず行うこと。本セクションでも繰り返しになりますが、最終判断はそれらの部門と専門の弁護士の方へご相談ください。

12-4. コスト監視を後回し

On-demand 課金で大量バッチを走らせて、月末に高額請求に気づく——これも実体験として身近な失敗です。生成 AI の利用量はトークン換算で見積もりが立てづらく、油断していると 1 日で予算月額分を使い切るケースもあります。

対策は AWS Cost Explorer と CloudWatch アラームの設定を初期段階で行うこと。「月次予算の 50% / 80% / 上限到達のタイミングで通知」のような段階アラームを組んでおくと、暴走バッチを早期に検知できます。私自身、AWS の他サービスでも CloudWatch アラームの設定は本番投入時の必須項目として組み込んでいます。

12-5. Provisioned Throughput を不要に予約

最後の失敗パターンは、負荷が安定する前から Provisioned Throughput の大きな予約枠を取って、稼働率が低いまま固定費だけ払い続けるケースです。Provisioned Throughput は時間単位の固定契約なので、使わない時間帯も料金が発生します。

対策は 最初の 1〜3 ヶ月は On-demand で実測してから Provisioned Throughput の検討に入ること。実測ベースでないと「常時 N TPS が必要かどうか」が判断できません。営業時代のたとえで書くと、月極の専属タクシー契約を結ぶ前に、まず数ヶ月のタクシー利用実績を見てから判断する、という発想です。

12-6. 5 つに共通する考え方——「自動で安全になる魔法はない」

5 つの失敗パターンに共通するのは、「Bedrock 経由にすれば自動で全部解決」という思い込みです。Bedrock は強力なエンタープライズ AI 基盤ですが、運用設計・コスト監視・社内ポリシー整合・最新仕様のキャッチアップは、別途自前で整える必要があります。

営業時代の私が学んだのは、「商社経由でも、与信は別途自分で確認しないと痛い目に合う」 ということでした。商社が間に入っているからといって、与信判断や納期管理をすべて商社任せにすると、必ずどこかで歪みが出る。Bedrock と AWS の関係も、同じ構図だと感じています。

13 — 学習・検討の最初の一歩——Bedrock を試す前にやっておきたい 3 ステップ

📖 この章で使う用語

  • 無料利用枠：AWS が新規アカウントに提供する 12 ヶ月限定の無料枠（一部サービス対象）。
  • 写経：サンプルコードを 1 行ずつ自分の手で打って動かすこと。「習字の写経と同じく、手で覚える」。
  • CTA（Call To Action）：読者に次の行動を促す案内。本記事末尾の関連記事リンクも CTA の一種。

最後に、Bedrock の検討・学習を始める方への 3 ステップの最初の一歩 を整理します。

ステップ 1：まずは Anthropic 直 API で Claude を 1 週間触る

Bedrock を検討する前に、まず Anthropic 直 API で Claude を 1 週間触ることを強くおすすめします。Claude そのものの感触（応答の長さの傾向、日本語の自然さ、得意な用途・苦手な用途）を掴まないと、Bedrock 経由に切り替えるべきかの判断がそもそも立ちません。

Claude.ai の Free / Pro / Max プラン全般は Claude 使い方 で、料金プランの比較は Claude 料金プラン で、最上位モデル Claude Opus の詳細は Claude Opus で、それぞれ別記事として整理しています。並行して読んでいただくと、Claude の輪郭が立体的に立ち上がります。

ステップ 2：AWS アカウントを作って Bedrock のコンソールを開く

次に、AWS アカウントを作って Bedrock のコンソール画面を開きます。既に AWS を使っている方はそのまま、初めての方は無料利用枠で AWS アカウントを作成します。

Bedrock の Model access 画面を開き、「Anthropic Claude 3.5 Sonnet」を Request access する——ここまでで AWS の「世界観」がだいぶ掴めます。コンソール画面のスクリーンショットを 5 枚ほど撮って、社内の検討資料に貼っておくと、稟議資料の説得力が上がります。

ステップ 3：本記事の最小サンプルを写経して Sonnet を 1 回呼ぶ

最後に、本記事 セクション 9-3 の Python boto3 最小サンプルを写経して、Claude Sonnet を 1 回呼ぶところまでやっていただきたいです。

実際に動かすと、「Bedrock の Sonnet と Anthropic 直 API の Sonnet は同じ応答を返す」ことが体感できます。ここまで来れば、「組織導入で Bedrock 経由を採用するかどうか」の判断材料が揃ってきます。

ステップ 4：「絶対これ」とは申し上げない最後のメタ宣言

最後にもう一度メタ宣言を入れます。「絶対 Bedrock 経由がベスト」「絶対 直 API のままで良い」とは申し上げません。組織の規模・業界・既存環境・チーム構成で振れます。最終判断は、本記事の整理を出発点にして、社内の情シス・法務・コンプライアンス部門との対話の中でご判断いただくのが筋です。

本記事を読んでいただいた次の一歩として、関連スポーク記事の中で気になるところから読み進めていただけると、Bedrock を含む「企業向け生成 AI 基盤」の全体像が立体的に見えてきます。

よくある質問

Q1: 「AWS Bedrock」は何と読みますか？ どんなサービスですか？

A. 「ベッドロック」と読みます。bedrock は英語で「岩盤・基盤」を意味し、AWS が生成 AI 時代の「基盤」を狙って命名したマネージド型の LLM 統合 API です。Anthropic Claude / Meta Llama / Mistral / Amazon Titan / Cohere / AI21 / Stability AI など複数の LLM プロバイダを、AWS の 1 つの IAM・1 つの契約で叩けるのが最大の特徴です。詳しくは セクション 2 と セクション 3 をご参照ください。

Q2: Bedrock の料金は Anthropic 直 API と比べてどれくらい違いますか？

A. 2026 年 5 月時点、Bedrock の On-demand（per-token）課金は、各プロバイダの公式価格とほぼ同等水準（AWS の上乗せはほぼゼロ〜小幅）です。「絶対こちらが安い」とは申し上げません。Bedrock は別途 Provisioned Throughput（時間単位の予約枠）を選べる点と、IAM 統合・VPC 内通信・監査ログのメリットが料金以外の判断軸として大きく効きます。最新の料金は aws.amazon.com/bedrock/pricing/ と anthropic.com/pricing で必ず事前にご確認ください。詳しくは セクション 5 と セクション 6 をご参照ください。

Q3: Bedrock 経由で Claude を使うメリットは何ですか？

A. 主に 4 軸あります：(1) IAM 連携で既存 AWS の権限管理を継承できる、(2) VPC 内通信（PrivateLink）でインターネット経由を避けられる、(3) CloudTrail / CloudWatch で監査ログを既存基盤に集約できる、(4) BAA / SOC 2 / ISO 27001 など AWS 既存の認証がそのまま継承できる——の 4 つです。組織要件（金融・医療・公共・大企業のコンプラ）が出てから Bedrock を検討するのが現実的、というのが私のこれまでの選定整理の経験からの感覚です。詳しくは セクション 4 をご参照ください。

Q4: Bedrock で Claude Code（CLI）を動かすには何が必要ですか？

A. 概念レベルでは、(1) AWS アカウントと IAM 認証情報（aws configure 等）、(2) Bedrock の Model access 申請（Anthropic Claude モデルの利用権限）、(3) Claude Code 側で Bedrock 経由モードに切り替える環境変数（Anthropic 公式仕様の最新版を必ず確認）、(4) リージョン指定とモデル ID の Bedrock 用フォーマット——の 4 つです。私自身は個人検証レベルで触っており、業務本番運用ではないため、具体的な手順は Anthropic 公式・AWS 公式の最新ドキュメントで必ずご確認ください。詳しくは セクション 7 をご参照ください。

Q5: 金融・医療・公共系で Bedrock を採用すれば必ず安全ですか？

A. 「絶対安全」とは申し上げません。AWS のインフラ部分は BAA / SOC 2 / ISO 27001 等の認証を取得していますが、(1) プロンプトに入れる機密情報の運用ルール、(2) 社内セキュリティポリシーとの整合、(3) データ保持期間の設定、(4) 業界ガイドライン（金融庁・個人情報保護法・医療情報ガイドライン等）への適合、(5) 最新の SLA・利用規約の確認——これらは別途自前で整える必要があります。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。詳しくは セクション 10 をご参照ください。

訂正・お問い合わせ

本記事の内容に誤り・古い情報・追記すべき観点を見つけられた場合は、サイトお問い合わせフォーム（send@bon-bon-tools.com）までお知らせください。確認のうえ、本文末に「訂正履歴」を追記して透明性を保ちます。料金・利用規約・モデルの仕様・リージョン提供状況などの一次情報は、AWS 公式（aws.amazon.com/bedrock/）と Anthropic 社の公式ページ（anthropic.com）が最も信頼できるソースですので、本記事と公式情報に差がある場合は公式情報を優先してご判断ください。

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）