OpenAI APIをAWS上の業務システムに組み込むと、社内データを使った自動化やAIエージェント開発が進めやすくなります。一方で、APIキーの漏洩、ログへの機密情報混入、権限過多、外部送信データの管理など、通常のWebシステムとは違う注意点があります。
この記事では、AWSでOpenAI APIを安全に扱うための基本設計を、実装前に確認すべき観点として整理します。
基本構成は「直接呼ばない」ことから始める
アプリケーションからOpenAI APIを直接呼ぶ構成は、実装は簡単ですが、監査・制御・マスキングが難しくなります。業務システムでは、API GatewayやLambdaを挟み、認証、入力チェック、ログ設計、レート制限を一元管理する構成が安全です。
API Gateway、Lambda、Secrets Manager、CloudWatchを組み合わせて安全にAI APIを扱います。
- フロントエンドからOpenAI APIキーを直接使わない
- API GatewayやLambdaを経由して呼び出す
- 入力データを事前に検査・マスキングする
- リクエスト量や失敗率をCloudWatchで監視する
- 機密情報をログに残さない
APIキーはSecrets Managerで管理する
OpenAI APIキーはAWS IAMで直接管理できるものではありません。コード、環境変数、Dockerfile、共有ドキュメントに書くのではなく、AWS Secrets Managerなどで保管し、必要なLambdaやECSタスクだけが取得できるようにします。
- 本番・開発・検証でAPIキーを分ける
- GetSecretValueの対象SecretをARNで絞る
- 定期的なローテーション手順を決める
- CloudTrailでSecret取得イベントを確認できるようにする
よくある危険な構成
フロントエンドにAPIキーを埋め込む、GitHubに.envを置く、全Lambdaに同じ広い権限を付ける、プロンプト全文をログ保存する、といった構成は避けるべきです。
ログは「追えるが、漏れない」設計にする
AI連携では、障害調査や監査のためにログが必要です。ただし、プロンプト全文や顧客情報をそのまま保存すると、ログ自体が漏洩リスクになります。保存する情報は、ユーザーID、処理種別、トークン量、ステータス、エラー概要、マスキング済み要約などに絞ります。
本番前チェックリスト
- APIキーがSecrets Managerにある
- IAM権限が最小権限になっている
- OpenAIへ送るデータの種類が整理されている
- ログに機密情報が残らない
- レート制限と異常検知がある
- 失敗時のリトライ・停止条件が決まっている
- 利用料金の上限やアラートがある
- 運用担当者が設定変更の影響を理解している
Liberta Structureで支援できること
AWS上でのAI API連携、Amazon Bedrockとの比較、Secrets Manager設計、CloudWatch監視、API Gateway構成、AIエージェントの権限設計まで、実装前のレビューから構築まで支援できます。
Consultation
AIを安全に導入する設計から相談できます。
記事の内容を自社に当てはめると、どこから手を付けるべきか分からない場合があります。AI利用ルール、権限設計、クラウド構成、実装方針まで整理します。