このノウハウで解決する課題
専門サービス会社では、クライアントの財務データや契約書データなど機微情報をAIに処理させる際、「外部APIに送信して大丈夫か」が常に論点になる。汎用ChatGPT・Claude APIは便利だがデータ送信先の統制が弱い。一方で完全自前ホストはGPU調達と運用負荷が大きい。
全体のイメージ
AWS Bedrock 経由で NVIDIA NIM のオープンモデル（Llama / Mistral / Gemma）を呼び出す構成にすると、以下の3条件を同時に満たせる。
- データはAWS環境から出ない: VPCエンドポイントで通信を閉域化、データ保持ゼロ設定でモデル提供側に学習用に残らない
- 運用は AWS 標準: CloudTrail で全API呼び出しを監査、KMSで暗号化、IAM でアクセス制御
- モデル選択肢が広い: OpenAI 一択ではなく、業務に応じてオープンモデルを選べる
必要な準備
- ツール: AWS アカウント / Bedrock 有効化済みリージョン（東京リージョン推奨）
- 想定環境: VPC・KMS・CloudTrail が整備済み
- 前提知識: AWS の基本概念（VPC / IAM / KMS）
手順
1. Bedrock コンソールで NIM モデルを有効化
AWS マネジメントコンソールの Bedrock → モデルアクセスから、利用したい NIM モデル（例: Llama 3.3 70B Instruct via NIM）を申請・有効化する。承認は通常24時間以内。
2. VPC エンドポイントを作成
VPC コンソールで com.amazonaws.{region}.bedrock-runtime のインターフェース型エンドポイントを作成。これにより Bedrock API への通信が閉域網（AWS バックボーン）経由になる。
3. KMS カスタマー管理キーで暗号化
Bedrock のリクエスト/レスポンスログを KMS カスタマー管理キーで暗号化する設定をオンにする。鍵ローテーションは年1回が目安。
4. データ保持ゼロを確認
NIM モデルは標準でデータ保持ゼロ。Bedrock の「データプライバシー」設定で「サービス改善のためのデータ使用」がオフになっていることを確認する。
5. アプリから呼び出し
boto3 で bedrock-runtime クライアントを生成し、invoke_model で NIM モデルを呼び出す。VPC 内のEC2/Lambda から実行すること。
もう少し詳しく（技術編）
import boto3
import json
bedrock = boto3.client(
"bedrock-runtime",
region_name="ap-northeast-1",
endpoint_url="https://vpce-xxxxxxxx-bedrock-runtime.vpce.amazonaws.com",
)
response = bedrock.invoke_model(
modelId="nvidia.llama-3-3-70b-instruct-nim",
body=json.dumps({
"messages": [{"role": "user", "content": "契約書の主要条項を要約してください"}],
"max_tokens": 1024,
}),
)
print(json.loads(response["body"].read()))CloudTrail で bedrock-runtime.amazonaws.com の InvokeModel イベントを抽出すると、誰がいつどのモデルを呼んだかが完全に追跡できる。組織内の AI 利用ガイドライン違反検知に活用できる。
実装で不明点があればお気軽にご相談ください。→ /contact
効果と限界
効果:
- データ送信先の統制が AWS 内に閉じる（オンプレ並みのガバナンス）
- 監査証跡が CloudTrail で自動取得される
- モデル切替が API パラメータ変更だけで完結
限界:
- レスポンス速度は OpenAI/Anthropic の専用APIに比べると若干遅い（リージョン・モデルサイズ依存）
- NIM 経由のモデルラインナップは AWS が承認したものに限定される
- 利用料金は通常のオンデマンド従量課金（Bedrock 標準）
応用・派生
- Microsoft 365 環境の事務所: 同等構成を Azure AI Foundry × NIM で実装可能（2026年4月発表）
- 完全自前ホスト: クライアントデータが極めて機微な場合、EC2 上で NIM コンテナを直接ホストする選択肢もある（運用負荷は高い）
|