はじめに

2026年4月、AWS と OpenAI のパートナーシップ拡大により Amazon Bedrock Managed Agents に OpenAI モデルが統合されました（限定プレビュー）。これにより、GPT-5.x などのフロンティアモデルを AWS のインフラ上で本番稼働させることが現実的になりました。

「OpenAI の API を直接叩けばいいのでは？」という疑問は当然です。本記事では、なぜ Bedrock 経由で使うのか、どんな設計をすべきかを掘り下げます。

1. Amazon Bedrock Managed Agents とは

Bedrock Managed Agents は、AI モデルに Tools（関数呼び出し）・メモリ・ガードレールを組み合わせ、マルチステップのタスクを実行できるエージェントをマネージドで動かすサービスです。

Bedrock Managed Agents の主要コンポーネント:

┌─────────────────────────────────────────────────┐
│ Amazon Bedrock Managed Agents                    │
│                                                  │
│  ┌──────────┐   ┌──────────┐   ┌─────────────┐ │
│  │ Foundation│   │ Action   │   │  Knowledge  │ │
│  │  Model   │◀──│  Groups  │   │    Base     │ │
│  │(GPT-5.x) │   │(Lambda)  │   │ (RAG/S3)   │ │
│  └──────────┘   └──────────┘   └─────────────┘ │
│                                                  │
│  ┌──────────┐   ┌──────────┐   ┌─────────────┐ │
│  │Guardrails│   │  Memory  │   │   Trace /   │ │
│  │          │   │(Session) │   │  Observ.   │ │
│  └──────────┘   └──────────┘   └─────────────┘ │
└─────────────────────────────────────────────────┘

これまで Anthropic Claude や Amazon Titan などのモデルに限定されていましたが、今回の統合で OpenAI モデルが Bedrock Managed Agents の Foundation Model として選択可能になりました。

2. なぜ OpenAI API を直接叩かないのか

2.1 OpenAI API 直接呼び出しの課題

直接呼び出しの構成:

Application
    │
    ▼
OpenAI API (api.openai.com)
    │
    ├── 認証：OpenAI API Key（シークレット管理が必要）
    ├── ガバナンス：なし（コンテンツフィルタはOpenAI任せ）
    ├── コスト追跡：OpenAI ダッシュボードで別管理
    ├── 可用性：OpenAI のインフラに依存
    └── データ残留：米国のOpenAIインフラ上

エンタープライズ環境では以下が問題になります：

規制対応：金融・医療など規制業種では社外へのデータ送信に制約がある
コスト管理：AWS の一括請求（Consolidated Billing）に含められない
モデル切り替え：OpenAI → Claude → Llama の切り替えにアプリ改修が必要
監査：誰が何をモデルに送ったか追跡できない

2.2 Bedrock 経由で得られるもの

観点	OpenAI API 直接	Bedrock Managed Agents
認証	API Key	AWS IAM（既存の認証基盤）
コスト管理	OpenAI 請求	AWS 請求に統合
ガードレール	OpenAI 標準のみ	独自ルール設定可
監査ログ	OpenAI 側	CloudTrail + Bedrock ログ
モデル切り替え	API 改修	エージェント設定変更のみ
VPC 内処理	不可	VPC エンドポイント利用可
データ残留リージョン	米国（OpenAI）	指定 AWS リージョン

3. アーキテクチャパターン

3.1 基本パターン：シングルエージェント

最もシンプルな構成。1つのエージェントが複数のツールを呼び出してタスクを完了します。

ユーザー / アプリ
    │
    ▼
API Gateway
    │
    ▼
Lambda（エントリポイント）
    │
    ▼
Bedrock Managed Agent
    ├─── Foundation Model: GPT-5.x (via Bedrock)
    ├─── Action Group 1: Lambda（社内 DB 検索）
    ├─── Action Group 2: Lambda（外部 API 呼び出し）
    └─── Knowledge Base: S3（社内ドキュメント RAG）

3.2 マルチエージェントパターン（Orchestrator + Sub-agents）

複雑なタスクを複数の専門エージェントに分割する構成です。Bedrock Managed Agents は エージェント間の呼び出し（Agent-as-a-tool） をサポートしています。

Orchestrator Agent（GPT-5.x）
    │
    ├──▶ Research Agent（Claude 3.7）
    │         └── Web 検索・文書要約に特化
    │
    ├──▶ Code Agent（Codex on Bedrock）
    │         └── コード生成・レビューに特化
    │
    └──▶ Data Agent（Claude 3.7 Haiku）
              └── データ変換・集計に特化

なぜモデルを使い分けるのか：

Orchestrator は判断に強いモデル（GPT-5.x）
コーディングタスクは Codex が最適
軽量なタスク（分類・変換）はコスパの良いモデル

これによりコストとパフォーマンスのバランスが取れます。

3.3 設計上の重要な考慮点：エージェントのステートレス化

Managed Agents のセッションメモリは session_id ごとに管理されます。長期記憶が必要な場合は、外部ストレージへの明示的な読み書きを Action Group として実装することを推奨します。

# Action Group の Lambda 実装例（長期記憶の読み書き）
import boto3
import json

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('agent-memory')

def lambda_handler(event, context):
    action = event['actionGroup']
    api_path = event['apiPath']
    
    if api_path == '/memory/read':
        user_id = event['requestBody']['content']['application/json']['properties'][0]['value']
        response = table.get_item(Key={'userId': user_id})
        memory = response.get('Item', {}).get('memory', '')
        return {
            'messageVersion': '1.0',
            'response': {
                'actionGroup': action,
                'apiPath': api_path,
                'httpMethod': 'GET',
                'httpStatusCode': 200,
                'responseBody': {
                    'application/json': {
                        'body': json.dumps({'memory': memory})
                    }
                }
            }
        }

4. ガバナンスとセキュリティ設計

4.1 Guardrails の設計

Bedrock Guardrails は、モデルへの入出力にフィルタリングルールを適用します。OpenAI モデルを使う場合でも Guardrails は Bedrock レイヤーで適用されます。

入力 → [Bedrock Guardrails（入力フィルタ）] → GPT-5.x → [Bedrock Guardrails（出力フィルタ）] → 出力

実装例：機密情報のマスキング

import boto3

bedrock = boto3.client('bedrock')

# Guardrail の作成
response = bedrock.create_guardrail(
    name='enterprise-guardrail',
    sensitiveInformationPolicyConfig={
        'piiEntitiesConfig': [
            {'type': 'EMAIL', 'action': 'ANONYMIZE'},
            {'type': 'PHONE', 'action': 'ANONYMIZE'},
            {'type': 'CREDIT_DEBIT_CARD_NUMBER', 'action': 'BLOCK'},
        ]
    },
    contentPolicyConfig={
        'filtersConfig': [
            {'type': 'VIOLENCE', 'inputStrength': 'HIGH', 'outputStrength': 'HIGH'},
            {'type': 'HATE', 'inputStrength': 'HIGH', 'outputStrength': 'HIGH'},
        ]
    },
    topicPolicyConfig={
        'topicsConfig': [
            {
                'name': 'internal-systems',
                'definition': '社内システムの詳細な構成情報や認証情報',
                'examples': ['パスワードを教えて', 'サーバーのIPアドレスは'],
                'type': 'DENY'
            }
        ]
    }
)

4.2 IAM 設計：最小権限の原則

エージェントが使用する IAM ロールは、必要な Action Group の Lambda 呼び出し権限のみに絞ります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockAgentLambdaInvoke",
      "Effect": "Allow",
      "Action": "lambda:InvokeFunction",
      "Resource": [
        "arn:aws:lambda:ap-northeast-1:123456789012:function:search-internal-db",
        "arn:aws:lambda:ap-northeast-1:123456789012:function:write-memory"
      ]
    },
    {
      "Sid": "BedrockModelAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/openai.gpt-4*"
    }
  ]
}

4.3 コスト管理：リクエストレベルのコスト帰属

2026年5月の新機能 「リクエストレベル使用状況帰属」 を使うと、エージェントの呼び出しをチーム・用途・実験単位でタグ付けできます。

import boto3

bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock_runtime.invoke_model(
    modelId='openai.gpt-4-turbo',
    body=json.dumps({
        'messages': [{'role': 'user', 'content': prompt}],
        'max_tokens': 1000
    }),
    # コスト帰属タグ
    performanceConfigLatency='standard',
    # カスタムタグ（AWS Cost Allocation Tags に反映）
    tags={
        'team': 'platform-engineering',
        'use-case': 'customer-support-agent',
        'environment': 'production'
    }
)

5. 実装時の注意点

5.1 OpenAI Harness（OpenAI ハーネス）とは

Bedrock Managed Agents の OpenAI 統合では「OpenAI Harness」と呼ばれる実行フレームワークが使われています。これは OpenAI モデルの特性に合わせて実行時間を最適化し、長期タスクの制御を行います。

重要な違い：Claude ベースのエージェントと比べて、長時間タスクの途中経過を InvokeAgentWithToken API で取得する際の挙動が異なります。OpenAI モデルはトークン単位のストリーミングが細粒度であるため、ストリーミング処理の実装に注意が必要です。

5.2 現時点での制約（プレビュー段階）

利用可能リージョン：現在 us-east-1 のみ（2026年5月時点）
利用には Bedrock モデルアクセスの申請が必要
Knowledge Base との統合は一部機能が未対応

5.3 モデル切り替えの設計指針

Managed Agents でモデルを抽象化する最大のメリットは切り替えの容易さです。

# エージェントの Foundation Model を変更する例
import boto3

bedrock_agent = boto3.client('bedrock-agent')

response = bedrock_agent.update_agent(
    agentId='ABCDEF1234',
    agentName='my-enterprise-agent',
    # ここを変えるだけでモデルを切り替え可能
    foundationModel='anthropic.claude-3-7-sonnet-20250219-v1:0',
    # foundationModel='openai.gpt-5-turbo',  # OpenAI に戻す場合
    instruction='あなたは社内の問い合わせを処理するエージェントです...'
)

6. まとめ

Bedrock Managed Agents への OpenAI 統合で実現できる主なことをまとめます：

課題	解決策
OpenAI API の管理コスト	AWS IAM・一括請求に統合
コンプライアンス・データ残留	指定 AWS リージョン内で処理
監査・ガバナンス	CloudTrail + Guardrails
モデル選択の柔軟性	エージェント設定で切り替え
コスト最適化	マルチモデル構成 + コスト帰属タグ

OpenAI の能力と AWS のエンタープライズ基盤を組み合わせることで、本番環境で動かすための要件（セキュリティ・監査・コスト管理）を満たしながらフロンティアモデルを活用できます。今後 GA になった際には積極的に評価することをおすすめします。