サーバーレスAI基盤としてのBedrock

Amazon Bedrockを選択する大きな理由の一つは、その「サーバーレス・フルマネージド」な特性にあります。従来の機械学習基盤では、GPUインスタンスの管理やモデルのデプロイメント環境の構築に多大な工数を費やしていました。しかしBedrockでは、Foundation Modelsへのアクセスから、RAG（Retrieval-Augmented Generation）システムの構築、Agentの実装まで、すべてマネージドサービスとして提供されています。（Bedrock は多くのコンポーネント（エージェント、ナレッジベース、プロンプト、ガードレール、推論プロファイルなど）をマネージドリソースとして扱えるように提供）

このサーバーレスアプローチの真価を最大限に引き出すためには、「Infrastructure as Code」による自動化が欠かせません。手動でコンソールから設定を行うのではなく、CloudFormationやCDKを使ってコード化することで、環境の再現性を担保し、デプロイメントの自動化を実現できます。

実際に私たちのチームでは、開発・ステージング・本番環境の3つの環境を完全にIaCで管理し、GitHubのPull RequestをトリガーとしたCI/CDパイプラインで自動デプロイを実現しています。この仕組みにより、新機能のリリースサイクルを従来の2週間から3日に短縮することができました。

CloudFormation/CDKによるBedrock構築の現状

IaC対応状況の全体像

BedrockのCloudFormation対応について調査を進めると、想像以上に多くのリソースタイプがサポートされていることがわかります。以下の表は、主要なBedrock機能のIaC対応状況をまとめたものです。

表 Amazon BedrockのIaC対応状況まとめ

この表を見てわかる通り、Foundation Models自体の作成や管理はできませんが、それ以外のほぼすべての機能がCloudFormationで定義可能です。特に注目すべきは「ApplicationInferenceProfile」で、これを使うことでクロスリージョンでのフェイルオーバーや負荷分散が実現できます。

IaCで解決できない課題と回避策

BedrockのIaC実装で直面する主な課題として、以下の2点が挙げられます。

Knowledge Baseのデータ同期

Knowledge Baseのデータ同期に関する課題が最も顕著です。CloudFormationでKnowledge BaseとData Sourceを作成できても、実際のデータ取り込み（インジェストジョブ）は自動実行されません。この問題に対しては、Lambda関数をカスタムリソースとして実装し、スタック作成後に自動でStartIngestionJob APIを呼び出す仕組みを構築しています。

// CDKでのカスタムリソース実装例
const syncKnowledgeBase = new cr.AwsCustomResource(this, 'SyncKB', {
  onCreate: {
    service: 'BedrockAgent',
    action: 'startIngestionJob',
    parameters: {
      knowledgeBaseId: knowledgeBase.ref,
      dataSourceId: dataSource.ref
    }
  },
  policy: cr.AwsCustomResourcePolicy.fromStatements([
    new iam.PolicyStatement({
      actions: ['bedrock:StartIngestionJob'],
      resources: ['*']
    })
  ])
});

ベクターストアのインデックス作成

も同様の課題があります。OpenSearch Serverlessのコレクションは作成できても、ベクターインデックスの作成は別途必要になります。これについても、AWS SDKを使ったカスタムリソースで対応することで、完全自動化を実現しています。

マルチ環境デプロイメント戦略

環境分離のベストプラクティス

エンタープライズ環境でBedrockを運用する場合、開発・ステージング・本番環境の適切な分離が重要です。私たちが採用している戦略では、各環境を「別々のAWSアカウント」で管理することで、完全な分離を実現しています。

環境ごとの設定差分は、CloudFormationのパラメータとして管理します。例えば、開発環境では低コストなClaude Instantを使用し、本番環境ではClaude 3 Sonnetを使用するといった切り替えが可能です。

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, staging, prod]

Mappings:
  EnvironmentConfig:
    dev:
      ModelArn: "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-instant-v1"
      DataBucket: "dev-knowledge-base-data"
    prod:
      ModelArn: "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"
      DataBucket: "prod-knowledge-base-data"

IAMロールとセキュリティの考慮事項

Bedrockのセキュリティ設計において、IAMロールの適切な設定は極めて重要です。特に「サービスロール」と「実行ロール」の違いを理解し、最小権限の原則に基づいて設計する必要があります。

各環境のBedrockサービスロールには、環境固有のリソースにのみアクセスできるよう、以下のような条件を付与しています。

{
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": "${AWS::AccountId}"
    },
    "ArnLike": {
      "AWS:SourceArn": "arn:aws:bedrock:*:${AWS::AccountId}:agent/*"
    }
  }
}

この設定により、誤って他環境のリソースにアクセスすることを防ぎ、セキュリティリスクを最小限に抑えています。

実践的な実装例：RAGシステムの構築

Knowledge BaseとAgentの統合実装

実際のプロジェクトで構築したRAGシステムの実装例を紹介します。このシステムは、社内ドキュメントを基にした質問応答システムで、完全にサーバーレスアーキテクチャで構築されています。

// CDKでのKnowledge Base定義
const knowledgeBase = new bedrock.CfnKnowledgeBase(this, 'DocumentKB', {
  name: `${props.environment}-document-kb`,
  roleArn: kbRole.roleArn,
  knowledgeBaseConfiguration: {
    type: 'VECTOR',
    vectorKnowledgeBaseConfiguration: {
      embeddingModelArn: 'arn:aws:bedrock:${AWS::Region}::foundation-model/amazon.titan-embed-text-v1'
    }
  },
  storageConfiguration: {
    type: 'OPENSEARCH_SERVERLESS',
    opensearchServerlessConfiguration: {
      collectionArn: opensearchCollection.attrArn,
      vectorIndexName: 'documents',
      fieldMapping: {
        vectorField: 'embedding',
        textField: 'content',
        metadataField: 'metadata'
      }
    }
  }
});

// Agentの定義
const agent = new bedrock.CfnAgent(this, 'DocumentAgent', {
  agentName: `${props.environment}-doc-agent`,
  agentResourceRoleArn: agentRole.roleArn,
  foundationModel: modelArn,
  instruction: 'あなたは社内ドキュメントに基づいて質問に答えるアシスタントです。',
  knowledgeBases: [{
    knowledgeBaseId: knowledgeBase.ref,
    description: '社内技術ドキュメント'
  }],
  autoPrepare: true
});

デプロイメントの自動化

AgentとAgentAliasの関係は、Lambda関数とエイリアスの関係に似ています。開発中は「DRAFT」バージョンで作業し、準備が整ったら「バージョン1」として固定し、AgentAliasでそのバージョンを公開します。

const agentAlias = new bedrock.CfnAgentAlias(this, 'AgentAlias', {
  agentAliasName: 'production',
  agentId: agent.ref,
  description: '本番環境用エイリアス',
  routingConfiguration: [{
    agentVersion: '1'  // 特定バージョンを指定
  }]
});

この仕組みにより、新しいバージョンのテストと本番環境への段階的なロールアウトが可能になります。

CI/CDパイプラインとの統合

GitHub ActionsによるBedrockデプロイ自動化

私たちのチームでは、GitHub ActionsとAWS CodePipelineを組み合わせて、完全自動化されたデプロイメントパイプラインを構築しています。

デプロイメントフローは以下の通りです。開発者がfeatureブランチを作成し、CloudFormationテンプレートを更新します。Pull Requestを作成すると、GitHub Actionsが自動的にテンプレートの検証とセキュリティスキャンを実行します。レビュー承認後、mainブランチへのマージをトリガーに、開発環境への自動デプロイが開始されます。

# .github/workflows/bedrock-deploy.yml
name: Deploy Bedrock Infrastructure
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Validate CloudFormation
        run: |
          aws cloudformation validate-template \\\\
            --template-body file://bedrock-stack.yaml

      - name: Security Scan
        run: |
          cfn-lint bedrock-stack.yaml
          cfn_nag_scan --input-path bedrock-stack.yaml

  deploy:
    if: github.ref == 'refs/heads/main'
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.DEPLOY_ROLE_ARN }}

      - name: Deploy to Dev
        run: |
          aws cloudformation deploy \\\\
            --template-file bedrock-stack.yaml \\\\
            --stack-name bedrock-dev-stack \\\\
            --parameter-overrides Environment=dev

環境昇格とロールバック戦略

本番環境へのデプロイメントには、より慎重なアプローチが必要です。開発環境でのテストが完了した後、ステージング環境で実際の本番データに近い条件でテストを実施します。その後、本番環境へは「Blue/Greenデプロイメント」方式を採用しています。

Blue/Green方式では、新しいバージョンのAgentを別のAliasとして作成し、一部のトラフィックから徐々に切り替えていきます。問題が発生した場合は、即座に旧バージョンにロールバックできます。

パフォーマンスとコスト最適化

サーバーレスアーキテクチャの利点を最大化

Bedrockのサーバーレス特性を活かすことで、従来の機械学習基盤と比較して大幅なコスト削減を実現できます。私たちの実測では、同等の性能を持つ自前のGPUクラスター運用と比較して、「約70%のコスト削減」を達成しました。

コスト最適化のポイントとして、以下の戦略を採用しています。

開発環境では低コストモデル（Claude Instant）を使用し、本番環境のみ高性能モデル（Claude 3 Sonnet）を使用することで、開発コストを抑制しています。Knowledge Baseのベクターストアには、オンデマンドのOpenSearch Serverlessを採用し、アイドル時のコストを最小化しています。Application Inference Profileを活用し、リージョン間での負荷分散によりコストパフォーマンスを最適化しています。

モニタリングとオブザーバビリティ

CloudWatchメトリクスを活用した詳細なモニタリング体制を構築することも重要です。特に以下のメトリクスは継続的に監視しています。

// CloudWatch Alarmの設定例
new cloudwatch.Alarm(this, 'HighLatencyAlarm', {
  metric: new cloudwatch.Metric({
    namespace: 'AWS/Bedrock',
    metricName: 'InvocationLatency',
    dimensionsMap: {
      ModelId: modelArn
    }
  }),
  threshold: 5000,  // 5秒以上のレイテンシでアラート
  evaluationPeriods: 2
});

これらのメトリクスを基に、自動スケーリングやリソース配分の最適化を行っています。

今後の展望と考察

Bedrockの進化とIaC対応の拡充

Amazon Bedrockは急速に機能拡張が進んでおり、IaC対応も同様のペースで改善されています。最近では、SageMaker Studio内でBedrockアプリケーションを構築し、そのままCloudFormationテンプレートとしてエクスポートできる機能が追加されました。

今後期待される機能拡張として、カスタムモデルのインポートやファインチューニングのIaC対応があります。現在はコンソールやAPIでの操作が必要ですが、近い将来CloudFormationリソースとして提供される可能性が高いと考えています。

エンタープライズ採用における課題と解決策

大規模組織でBedrockを採用する際の課題として、「ガバナンス」と「コンプライアンス」の確保があります。IaCを活用することで、これらの課題に対して以下のような解決策を提供できます。

すべてのリソース定義をGitで管理し、変更履歴を完全に追跡可能にすることで、監査要件に対応しています。CloudFormation Stack Policyを使用し、重要なリソースの削除や変更を制限しています。AWS Configルールと連携し、コンプライアンス違反を自動検知する仕組みを構築しています。

実装上の教訓とベストプラクティス

これまでの実装経験から得られた重要な教訓をいくつか共有します。

最初から完璧なIaCを目指すのではなく、段階的に自動化を進めることが重要です。特にKnowledge Baseのデータ同期のような手動操作が必要な部分は、まず手動運用から始め、徐々に自動化していくアプローチが効果的でした。

環境ごとの設定管理には、CloudFormationのMappingsよりもSystems Manager Parameter Storeを活用する方が柔軟性が高いことがわかりました。特に機密情報（APIキーなど）の管理には、Secrets Managerとの連携が不可欠です。

テスト戦略についても、通常のインフラテストに加えて、AIモデルの出力品質を検証するテストが必要です。私たちは、定型的な質問セットを用意し、各デプロイメント後に自動でレスポンス品質をチェックする仕組みを導入しています。

まとめ

Amazon BedrockとIaCの組み合わせは、エンタープライズにおけるAI活用の新たな可能性を開いています。「サーバーレス」という特性により、インフラ管理の負担から解放され、本来のビジネス価値創出に集中できるようになりました。

CloudFormationやCDKによる完全な自動化は、開発速度の向上だけでなく、セキュリティとコンプライアンスの観点からも大きなメリットをもたらします。特に、複数環境での一貫性のある運用や、監査証跡の完全な記録は、エンタープライズ要件を満たす上で不可欠な要素です。

今後もBedrockの機能拡張は続いていくでしょうが、IaCファーストのアプローチを維持することで、変化に柔軟に対応しながら、安定した運用を継続できると確信しています。サーバーレスAI基盤の構築を検討されている方々にとって、本記事で紹介した実践的なアプローチが参考になれば幸いです。