ガバメントクラウド環境での生成 AI の活用事例として Amazon Bedrock を使ったアーキテクチャのお話をいくつか伺う機会があったのですが、実際に自治体がガバメントクラウドの閉域環境から Bedrock の API を使うためにはどんなインフラ構成になるのか気になったので、ガバクラを模した閉域の AWS マルチアカウント環境を個人で用意し、検証してみました。
ガバメントクラウド環境で Bedrock を使うときの注意点
Bedrock API には VPC エンドポイント経由でアクセスする
Bedrock に限らない話ですが、自治体が使うガバメントクラウド環境は基本的に閉域の VPC となるため、VPC のプライベートサブネットに Bedrock のインターフェース型 VPC エンドポイントを作成し、VPC エンドポイント経由で Bedrock の API へアクセスする必要があります。
自治体アカウントでは Third-Party Model を使えないため、ガバクラ外のアカウントへクロスアカウントアクセスする
ガバメントクラウドの自治体 AWS アカウントには Bedrock のモデルの使用に制約があり、Anthropic の Claude など Third-Party Model を使用できないとのことです。
また、ガバメントクラウドでは特有の制約が多く、AIを導入するためにはそれらの制約のクリアが必要だったとのことです。
具体的にはガバメントクラウド上のアカウントでは、契約やポリシーの関係で直接Amazon Bedrockを使用できません。
導入するためには自治体の許可を得た上で、ガバメントクラウドのアカウントと同等のセキュリティレベルを担保し、クロスアカウント構成でBedrockを利用することでした。
そのため、自治体アカウントから Bedrock の Third-Party Model を利用するためには、以下の方法になるようです。
- ガバメントクラウドではない AWS アカウントを用意（以下、便宜上「事業者アカウント」とします）
- 事業者アカウントの Bedrock で Third-Party Model を有効化
- これにアクセスを許可した IAM ロールを事業者アカウントに作成
- 自治体アカウントからこの事業者アカウント IAM ロールに Assume Role して Bedrock へクロスアカウントアクセス
東京・大阪リージョン以外へクロスリージョン推論できないようにする
ガバメントクラウドでは日本国内リージョン以外使用できない制約があるため、Bedrock のクロスリージョン推論も国内に閉じる必要があります。
そこで、今回の検証ではモデルに Anthropic の Claude Haiku 4.5 を選択し、推論プロファイルを JP Claude Haiku 4.5 とすることでクロスリージョン推論を東京・大阪リージョンに限定します。
それでは以上の制約事項を踏まえて早速検証してみます。
閉域 VPC から Bedrock へのクロスアカウントアクセス検証の概要
今回の検証では、自治体アカウントを模したアカウントと、事業者アカウントを模したアカウントの 2 つのアカウントを使用し、自治体アカウントのプライベートサブネットから Bedrock の API へアクセスし、事業者アカウントのモデルをクロスアカウントアクセスで使えるところまでをゴールとします。
事業者アカウント側のポイントは、Bedrock で Third-Party Model を有効化することと、自治体アカウントからクロスアカウントアクセスさせるための IAM ロールを作成することです。
そして自治体アカウントでは、EC2 (Amazon Linux 2023) に Python の SDK である boto3 をインストールし、boto3 のクライアントから Bedrock にアクセスできるかを確認します。（なお、Bedrock を使った実践的な開発については、SB Creative から出版されている AIエージェント開発 / 運用入門 がお勧めです。）
検証環境の構成図は以下のとおりです。
最初に自治体アカウント、事業者アカウント双方の作業の概要から整理し、その後に具体的な作業の手順を解説していきます。
事業者アカウントでの作業の概要
まずは事業者アカウントでの作業の概要です。
先に事業者アカウントの IAM ロールから Bedrock のモデルへアクセスできる状態にしておく必要がある都合上、上記の構成図と異なり、最初に事業者アカウントから Bedrock にアクセスするよう、事業者アカウントにも EC2 や VPC エンドポイントをデプロイしています。
既に事業者アカウント側で Bedrock へアクセスできる準備ができている場合は不要であり、自治体アカウントからクロスアカウントする際も事業者アカウント側に VPC エンドポイントがある必要はないので、上記の構成図には記載していません。
モデルアクセスの有効化
- 事業者アカウントの Bedrock で Anthropic の Claude Haiku 4.5 を有効化
初回モデルアクセスに必要な VPC エンドポイントの作成
- Bedrock Runtime のインターフェース型 VPC エンドポイントを作成（初回モデルアクセス後は削除して OK）
Bedrock へアクセス権限のある IAM ロールの作成
- 事業者アカウントに Bedrock へのアクセスと自治体アカウントからの Assume Role を許可する IAM ロールを作成
Bedrock クライアントの準備（boto3 のインストール）
- S3 のゲートウェイ型 VPC エンドポイントを作成（dnf で python3-pip をインストールするため）
- CodeArtifact のインターフェース型 VPC エンドポイントを作成（pip で boto3 をインストールするため）
- 閉域 VPC に EC2 インスタンスをデプロイして IAM ロールをアタッチ
- IAM ロールに一時的に CodeArtifact の読み取りアクセスを許可するポリシーをアタッチ（boto3 インストール後は削除して OK）
- dnf で python3-pip をインストール
- CodeArtifact にアップストリームリポジトリを PyPi Store とするリポジトリを作成
- pip で boto3 をインストール
Claude Haiku 4.5 モデルへの初回アクセス
- EC2 で Bedrock Converse API にアクセスする Python コードを作成して実行することで、作成した IAM ロールでの初回アクセスが完了し、当該 IAM ロールでのモデルへのアクセスが許可される
自治体アカウントでの作業の概要
次に自治体アカウントの作業の概要です。
基本的に事業者アカウント側と同じような作業をしますが、異なるポイントは Assume Role のために STS のリージョナルエンドポイントが必要になることです。
Bedrock の VPC エンドポイントの作成
- 事業者アカウントと同じ作業を実施
STS リージョナルエンドポイントの作成
- STS のインターフェース型 VPC エンドポイント（リージョナルエンドポイント）を作成
Assume Role 用の IAM ロールの作成
- 事業者アカウントで作成した IAM ロールへ Assume Role するための IAM ロールを作成
Bedrock クライアント (boto3) の準備
- 事業者アカウントと同じ作業を実施
Claude Haiku 4.5 モデルへクロスアカウントアクセス
- 事業者アカウントへ Assume Role して Bedrock Converse API にアクセスする Python コードを実行して結果が返ってくることがゴール
それでは具体的な作業手順を説明していきます。
事業者アカウントの設定
Claude Haiku 4.5 のモデルアクセスの有効化
2025/10/26 現在、個別にモデルアクセスを有効にする必要はなくなったようで、マネジメントコンソールの画面もリタイアと表記されていました。
しかし、Anthropic のモデルを使う場合は、従前どおり申請が必要でした。申請せずに API にアクセスすると以下のようなエラーが返ります。
モデルの初回使用時に申請フォームが現れるようなので、マネジメントコンソールの「モデルカタログ」から「Claude Haiku 4.5」を選択し、プレイグラウンドを開くことにします。
申請フォームが表示されるので、適当に使用目的などを入力して利用申請します。
利用申請が承認されると AWS からメールが通知されます。
Bedrock API 用のインターフェースエンドポイントの作成
Bedrock の API へプライベートサブネットの EC2 からアクセスできるようにするため、プライベートサブネットにインターフェース型 VPC エンドポイントを作成します。
今回は InvokeModel API と Converse API が使えることまでを確認する検証なので、以下の一つで大丈夫です。
- com.amazonaws.ap-northeast-1.bedrock-runtime
Claude Haiku 4.5 モデルをクロスアカウントアクセスで使用するための IAM ロールを作成
Claude Haiku 4.5 モデルを使用できるよう、必要な権限を付与した IAM ロールを作成します。
この IAM ロールには自治体アカウントから Assume Role できるようにもしておきます。
先に事業者アカウント側でこの IAM ロールから Bedrock のモデルへのアクセス許可を得ておくことで、自治体アカウントからは Assume Role するだけでモデルアクセスができる状態になります。
基盤モデルと推論プロファイルへのアクセスを許可する IAM ポリシーを作成
IAM ロールへアタッチする許可ポリシーとして、以下のような IAM ポリシーを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel"
],
"Resource": [
"arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-haiku-4-5-20251001-v1:0",
"arn:aws:bedrock:ap-northeast-3::foundation-model/anthropic.claude-haiku-4-5-20251001-v1:0",
"arn:aws:bedrock:ap-northeast-1:事業者アカウントの ID:inference-profile/jp.anthropic.claude-haiku-4-5-20251001-v1:0"
]
}
]
}
東京リージョンと大阪リージョンの Claude Haiku 4.5 の基盤モデルの ARN から bedrock:InvokeModel の実行を許可します。また、今回は国内リージョンに閉じたクロスリージョン推論を使うため、この推論プロファイルの ARN も許可するようにしています。
推論プロファイルの ARN はマネジメントコンソールの「推論プロファイル」から確認できます。
Bedrock API への許可ポリシーを追加
今回は Bedrock の API へアクセスするところまでの検証なので、AWS 管理ポリシーの「AmazonBedrockLimitedAccess」を許可ポリシーに追加します。
Marketplace への初期アクセスを許可するための許可ポリシーを追加
モデルに初めてアクセスする時は、Marketplace への読み取りアクセスが必要でした。この権限がない状態で API へアクセスすると以下のエラーが返ります。
そこで、IAM ロールの許可ポリシーに「AWSMarketplaceRead-only」の AWS 管理ポリシーも追加しました。
自治体アカウントから Assume Role させる信頼ポリシーの設定
自治体アカウントの IAM ロールから Assume Role できるように信頼ポリシーを以下のように設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::自治体アカウントの ID:role/自治体アカウントの IAM ロール ARN"
},
"Action": "sts:AssumeRole"
}
]
}
IAM ロールの設定は以上です。
初回モデルアクセス作業用の EC2 インスタンス、VPC エンドポイント等の設定
プライベートサブネットに EC2 をデプロイして IAM ロールをアタッチ
プライベートサブネットに Amazon Linux 2023 の EC2 インスタンスを起動し、作成した IAM ロールをアタッチします。
S3 ゲートウェイエンドポイントの作成
プライベートサブネットの Amazon Linux 2023 から dnf で pip をインストールできるようにするため、プライベートサブネットに S3 ゲートウェイエンドポイントをデプロイします。
S3 経由で dnf がパッケージをインストールできるようになります。
CodeArtifact のインターフェースエンドポイントを作成
pip パッケージをプライベートサブネットの EC2 でインストールできるようにするため、プライベートサブネットに CodeArtifact のインターフェース型 VPC エンドポイントを作成します。
必要なエンドポイントは以下のとおりです。boto3 のインストールが終わったら消しても大丈夫です。
- com.amazonaws.ap-northeast-1.codeartifact.api
- com.amazonaws.ap-northeast-1.codeartifact.repositories
python3-pip のインストール
dnf で python3-pip をインストールします。
$ sudo dnf install python3-pip
IAM ロールに CodeArtifact の読み取りアクセス権限を一時的に追加
IAM ロールに AWS 管理ポリシーの「AWSCodeArtifactReadOnlyAccess」を一時的に追加しておきます。
boto3 のインストールが終わったら不要なので許可ポリシーから削除しても大丈夫です。
CodeArtifact に PyPi Store をアップストリームとするリポジトリを作成
インターネット接続のできないプライベートサブネットにある EC2 から pip で boto3 をインストールするため、CodeArtifact に PyPi Store をアップストリームとするリポジトリを作成します。
マネジメントコンソールから「リポジトリの作成」に進み、アップストリームリポジトリに「pypi-store」を選択します。
適当なドメイン名を設定します。
リポジトリが作成できたら、マネジメントコンソールから当該リポジトリを選択し、「接続手順の表示」に進みます。
表示されているコマンドを確認します。
boto3 のインストール
先ほど確認したコマンドを EC2 のコンソールで実行します。
$ aws codeartifact login --tool pip --repository 作成したリポジトリ名 --domain 作成したドメイン名 --domain-owner 事業者のアカウント ID --region ap-northeast-1
これにより一時的に PyPi Store から pip でパッケージをインストールできるようになります。
次に pip で boto3 をインストールします。
$ pip install boto3
Claude Haiku 4.5 モデルへ初回アクセスの実行
Bedrock のテストを兼ねて、以下の Python コードから Claude Haiku 4.5 モデルへ初回アクセスしてみます。
import boto3
client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
response = client.converse(
modelId="jp.anthropic.claude-haiku-4-5-20251001-v1:0",
messages=[
{
"role": "user",
"content": [
{
"text": "こんにちは"
}
]
}
]
)
print(response)
ポイントはモデル ID の箇所で、今回クロスリージョン推論を国内に閉じた推論プロファイルとするため、Claude Haiku 4.5 のモデル ID ではなく JP Claude Haiku 4.5 推論プロファイルの ID (jp.anthropic.claude-haiku-4-5-20251001-v1:0) を指定します。
response を標準出力に出すだけのコードですが、成功すれば以下のような出力が返ります。
これで作成した IAM ロールから Claude Haiku 4.5 モデルへアクセスできるようになりました。
事業者アカウントで作成した EC2 インスタンスや VPC エンドポイントは削除して大丈夫です。
あとは自治体アカウントに STS と Bedrock-Runtime の VPC エンドポイントを作成し、この事業者アカウントで Bedrock API を実行した IAM ロールに Assume Role するだけです。
自治体アカウントの設定
Bedrock API 用のインターフェースエンドポイントの作成
事業者アカウント側で作成したのと同様に、以下のインターフェース型 VPC エンドポイントを作成します。
- com.amazonaws.ap-northeast-1.bedrock-runtime
STS リージョナルエンドポイントの作成
同様に、boto3 クライアントとなる EC2 インスタンスのあるプライベートサブネットへ以下のインターフェース型 VPC エンドポイントを作成します。
- com.amazonaws.ap-northeast-1.sts
事業者アカウントへクロスアカウントアクセスするための IAM ロールを作成
事業者アカウントへの Assume Role を許可
以下のような、事業者アカウントへの Assume Role を許可する IAM ポリシーを作成して IAM ロールへアタッチします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"事業者アカウントに作成している IAM ロールの ARN"
]
}
]
}
Bedrock API へのアクセスを許可
今回は Bedrock の API へアクセスするところまでの検証なので、AWS 管理ポリシーの「AmazonBedrockLimitedAccess」を許可ポリシーに追加します。
モデルアクセス用の EC2 インスタンス、VPC エンドポイント等の設定
事業者アカウント側の作業と同じです。S3 ゲートウェイエンドポイントを作成して Amazon Linux 2023 に pip をインストールし、CodeArtifact のリポジトリ経由で boto3 をインストールしてください。
閉域 VPC からクロスアカウントアクセスで Claude 4.5 Haiku モデルへアクセスできることを確認する
以上で自治体アカウントから事業者アカウントの Bedrock Claude Haiku 4.5 モデルを使う準備はできました。
確認するため、以下のような Python コードを実行してみます。
import boto3
# 事業者アカウントの IAM Role へ Assume Role してクレデンシャルを取得する
sts_client = boto3.client(
"sts",
region_name="ap-northeast-1",
endpoint_url="https://sts.ap-northeast-1.amazonaws.com"
)
assumed_role = sts_client.assume_role(
RoleArn="事業者アカウントの IAM ロールの ARN",
RoleSessionName="assume_role_session"
)
assume_role_session = boto3.session.Session(
aws_access_key_id=assumed_role["Credentials"]["AccessKeyId"],
aws_secret_access_key=assumed_role["Credentials"]["SecretAccessKey"],
aws_session_token=assumed_role["Credentials"]["SessionToken"],
)
# 取得したクレデンシャルで Bedrock へ接続する
bedrock_client = assume_role_session.client("bedrock-runtime", region_name="ap-northeast-1")
response = bedrock_client.converse(
modelId="jp.anthropic.claude-haiku-4-5-20251001-v1:0",
messages=[
{
"role": "user",
"content": [
{
"text": "こんにちは"
}
]
}
]
)
print(response)
レスポンスが返ってきました。
これでガバメントクラウドのような閉域 VPC からでも Bedrock が使えること、別アカウントの Bedrock モデルをクロスアカウントアクセスで使用できることが確認できました。
閉域 VPC から Bedrock を使ってみた感想
Bedrock はほとんどインフラを意識することなく様々なモデルを簡単に利用できて驚きました。
また、検証したとおり、閉域環境でも簡単にアクセスできるので、エンタープライズ環境でも安心して使えそうです。
今回別アカウントの Bedrock のモデルにクロスアカウントアクセスする検証をしたきっかけが大崎コンピューターエンヂニアリングさんの生成 AI 活用のブログを改めて読み直して、インフラ観点でどのような実装になっているか確かめたかったからなのですが、こういった仕組みを思いつくのがすごいと思いました。
検証したことで、ガバメントクラウドで生成 AI を使いたい！と言われてもすぐに PoC 環境を作れる自信がつきました。
次は AI エージェントに挑戦してみたいです。
参考 URL