Amazon Bedrockの全体構造: モデルはどこで動き、データはどこへ流れ、自前モデルはどう持ち込むか

対象 / ポイント

対象: AWS上で生成AI基盤を設計するAI導入推進担当、インフラ設計者、生成AIアプリケーション開発リード。

ポイント:

• Bedrockは複数モデルをAWSの統制面に載せるエンタープライズAI基盤
• データ主権はIn-Region、Geo、Global routingの選び方で変わる
• 自前モデルは持ち込めるが、オンプレGPUをBedrock推論基盤には直結できない

AWSを標準クラウドにしている企業では、生成AIの論点は「どのモデルが賢いか」だけでは終わりません。 社内データがどの経路を通るのか、監査ログをどこで取るのか、既存のIAMやVPC設計にどう載せるのかが同時に問われます。

この記事の問いは、Amazon BedrockをAIモデル選定ではなく、企業内AIの実行基盤としてどう理解するかです。

BedrockはモデルAPIではなく統制された入口

Bedrockは、複数の基盤モデルをAWSの単一の管理面から呼び出すためのサービスです。 AWS公式ドキュメントでは、Amazon、Anthropic、DeepSeek、Moonshot AI、MiniMax、OpenAIなどの100超の基盤モデルをサポートすると説明されています¹。

ChatGPT APIやClaude APIを直接使う場合と違うのは、モデルの賢さではありません。認証、課金、暗号化、ネットワーク制御、ログをAWS標準の運用に寄せられることです。

たとえば、既にAWS Organizations、IAM Identity Center、CloudTrail、VPC、KMSを使っている企業なら、 生成AIだけを別ベンダーの独立した統制面に置く必要が薄くなります。ここがBedrockの実務上の強みです。

データはどこを通るのか

Bedrockを呼び出す経路は、公開インターネット経由に限定されません。 AWS PrivateLinkを使うと、VPC interface endpoint経由でAmazon Bedrockへプライベート接続できます²。

単純化すると、企業内アプリケーションからBedrock推論までの構造はこうです。

flowchart LR
    subgraph onprem["オンプレ / 社内ネットワーク"]
        USER_APP["業務アプリケーション / RAGアプリケーション"]
    end

    subgraph vpc["顧客VPC"]
        APP["Lambda / ECS / EKS"]
        EP["VPC Interface Endpoint<br/>AWS PrivateLink"]
    end

    subgraph bedrock["Amazon Bedrock"]
        API["bedrock-runtime / Converse API"]
        GUARD["Guardrails / KMS / Logging"]
        ROUTER["モデルルーティング"]
    end

    subgraph compute["推論基盤"]
        TRAINIUM["AWS Trainium / Inferentia"]
        GPU["GPU基盤"]
    end

    USER_APP -->|"Direct Connect / VPN"| APP
    APP --> EP
    EP --> API
    API --> GUARD
    GUARD --> ROUTER
    ROUTER --> TRAINIUM
    ROUTER --> GPU

この図で見るべき点は3つです。顧客アプリケーションはVPC内に置けます。 Bedrock APIへの接続はPrivateLinkに寄せられます。推論基盤そのものはAWS管理領域に隠蔽されます。

つまり、ユーザーは「モデルが動くEC2」を直接管理しません。管理するのは、どのリージョンに投げるか、どのAPIを許可するか、どのログと鍵管理を組み合わせるかです。

リージョン主権はrouting方式で変わる

Bedrockのデータ所在地は、使うモデルとrouting方式で変わります。 AWSドキュメントは、Inference optionsとしてIn-Region、Geographic、Globalを分けています³。

routing方式	データ所在地の考え方	向いている場面
In-Region	指定した単一リージョン内で処理	規制・契約で単一リージョン処理が必要
Geographic	Japan、EU、USなど地理境界内で最適化	国内・域内に留めたいが単一リージョン固定ではない
Global	商用リージョン全体で最適化	性能・コスト優先で所在地制約が弱い

そのため、「東京リージョンを選べば常にすべて完結」とは書けません。 正確には、In-Regionを選び、使いたいモデルがそのリージョンで提供されている場合に、 単一リージョン処理として設計できるという話です。

日本企業でよく問われるのは、東京、またはJapan Geoで足りるかです。ここは法務・セキュリティ・クラウド基盤チームと、モデル別の可用性表を見ながら詰める必要があります。

モデルはどの計算基盤で動くのか

Bedrockの裏側では、AWSの自社AIチップであるTrainium系が重要な役割を持っています。 Amazon CEOのAndy Jassyは2026年の説明で、Bedrockの推論の多くがTrainium上で動いていると述べています⁴。

Trainium2については、AWSが2024年12月にTrn2 instancesの一般提供を発表しました。 GPUベースのEC2 P5e/P5enと比べて30〜40%よいprice performanceをうたっています⁵。 同じ発表では、AnthropicがClaudeをBedrockで提供するために大規模なTrainium2クラスタを使うことにも触れられています。

ここから読み取るべきことは、BedrockがNVIDIA GPUだけで成り立つサービスではない点です。 AWSはモデル提供の抽象APIだけでなく、推論コスト曲線そのものを自社シリコンで制御しようとしています。

企業側の設計判断では、この事実が2つの意味を持ちます。 ひとつは、推論単価や供給能力がAWSのチップ戦略に影響されること。 もうひとつは、モデルを「どのクラウドの計算基盤で動かすか」が調達・ロックインの論点になることです。

自前モデルを持ち込む3つのルート

自社で学習済みのモデルや、特定業務向けに調整したモデルを使いたい場合、 Bedrockにはいくつかの選択肢があります。重要なのは、自由度が高いほどAWSの外側、運用統合が強いほどBedrockの内側に寄ることです。

ルート	何をするか	向いている場合
Custom Model Import	S3上のカスタムウェイトをBedrockへ登録	SageMakerや外部環境で調整済みの対応モデルをBedrock APIで出したい
Bedrock内のカスタマイズ	Bedrock上でfine-tuningやcontinued pre-trainingを行う	AWS管理面に寄せて学習・推論を閉じたい
SageMakerで学習してBedrockへ戻す	学習はSageMaker、提供はBedrock	学習自由度と推論運用統合を両立したい

Custom Model Importは、サポートされるアーキテクチャのモデルをAmazon S3からインポートする機能です。 AWSドキュメントでは、Hugging Face形式やSafetensors形式のモデルファイルを使う流れが説明されています⁶。

最小イメージはこの形です。

aws bedrock create-model-import-job \
  --job-name my-llama3-import \
  --imported-model-name my-llama3-jp \
  --role-arn arn:aws:iam::123456789012:role/BedrockImportRole \
  --model-data-source '{"s3DataSource":{"s3Uri":"s3://my-model-bucket/llama3/"}}'

ただし、何でも持ち込めるわけではありません。対応アーキテクチャ、ファイル形式、推論方式、スループット要件を先に確認する必要があります。

オンプレGPUはBedrockの裏側にはならない

オンプレGPUを持っている企業ほど、「そのGPUをBedrockの推論基盤として使えないか」と考えがちです。 結論は、Bedrockのマネージド推論バックエンドとしてオンプレGPUを直接ぶら下げる設計はできません。

現実的な選択肢は、用途別にルーティングを分けることです。

• 高機密データはオンプレまたは専用環境の推論基盤へ送る
• 汎用業務や社内文書RAGはBedrockへ送る
• オンプレやSageMakerで学習したウェイトをS3経由でBedrockへ持ち込む
• Direct ConnectやVPNは通信経路として使い、推論実行場所とは分けて考える

この分離は地味ですが重要です。ネットワーク的にAWSとつながっていても、Bedrockの推論コンピュートが自社データセンターへ移動するわけではありません。

オンプレ資産を活かすなら、Bedrockに全部寄せる設計より、アプリケーション層で推論先を選ぶ設計のほうが現実的です。

採用前に潰すべき論点

Bedrockを選ぶ前に、モデル比較表だけを見ると判断を誤ります。 エンタープライズでは、次の順で確認したほうが堅いです。

• 使いたいモデルが対象リージョンとrouting方式で使えるか
• PrivateLink、KMS、CloudTrail、CloudWatchをどの単位で設計するか
• Guardrails、Knowledge Bases、Agentsなど付帯機能のリージョン差分は何か
• 自前モデルを使う場合、対応アーキテクチャとスループット課金を確認したか
• SageMaker、EKS、オンプレGPUとの責務分界を決めたか

ここで詰まる場合、問題はBedrockの機能不足とは限りません。 社内で「どのデータを、どのモデルへ、どの権限で渡すか」がまだ設計されていない可能性があります。

まとめ

Bedrockは「LLM APIのまとめ役」ではなく、AWSの統制面に生成AIを載せるための実行基盤です。 モデル選定、データ所在地、ネットワーク、監査、自前モデルの扱いを一体で設計する必要があります。

新しい示唆をひとつ加えるなら、Bedrock導入の成否はAIチームだけでは決まりません。 クラウド基盤、セキュリティ、法務、業務部門が同じアーキテクチャ図を見て、 どこをAWSに任せ、どこを自社責任として残すかを決められるかで決まります。

関連記事

• 企業内AI活用
• 企業AIの意思決定ループ
• RAG / Context Engineering
• AI業務適用設計

---

1. Overview - Amazon Bedrock ↩

2. Amazon Bedrock VPC / PrivateLink ↩

3. Regional availability - Amazon Bedrock ↩

4. Andy Jassy weighs in on the rapid growth of Amazon's chips business ↩

5. AWS Trainium2 Instances Now Generally Available ↩

6. Use Custom model import to import a customized open-source model into Amazon Bedrock ↩