AWS」タグアーカイブ

【AWS SAM×Bedrock】社内用セキュア生成AIチャットAPIの構築

はじめに

業務で生成AI(Amazon Bedrock)を活用したいけれど、「APIキーを直接開発者に配りたくない」「利用状況をログに残して管理したい」「特定のモデルだけを使わせたい」といった悩みはありませんか?
Bedrockを直接クライアントから叩くのではなく、API GatewayとLambdaを経由させる「プロキシAPI」を構築することで、これらのガバナンスやセキュリティの課題を解決できます。

今回は、AWS SAM (Serverless Application Model) を使って、この構成を最速・最小構成で構築する方法を紹介します。

以前の記事「AWS SAMを使って最もシンプルにLambda × APIGatewayのWebAPIを構築する」の応用編になりますので、SAMの基礎を知りたい方はそちらも合わせてご覧ください。

アーキテクチャ構成

作るものは非常にシンプルです。

User/App -> API Gateway -> Lambda -> Amazon Bedrock (Claude 3)

  • API Gateway: エンドポイントの公開、認証(将来的な拡張)
  • Lambda: リクエストの整形、Bedrockへのアクセス、ログ出力
  • Bedrock: 生成AIモデル (今回は Claude 3 Sonnet を使用)

IAMロールの権限管理により、LambdaだけがBedrockにアクセスできるようにするため、非常にセキュアです。

事前準備

  • AWS CLI と SAM CLI がインストールされていること
  • Amazon Bedrock のコンソールで、Claude 3 Sonnet のモデルアクセス許可が有効になっていること(これ重要です!有効化していないとエラーになります)

参考書籍

本記事の執筆にあたり、またはBedrock/SAMを深く学ぶために、2026年時点で最新の以下の書籍がおすすめです。特に『深掘りガイド』シリーズは実務で非常に役立ちます。

  • Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガイド]
    • Bedrockの基本からRAG、エージェントまで網羅された決定版。
  • AIエージェント開発/運用入門 [生成AI深掘りガイド]
    • LangGraphやBedrockを使った自律型エージェントの開発・運用(LLMOps)に特化した一冊。2025年の「AIエージェント元年」を象徴する良書。
  • TECHNICAL MASTER はじめてのAWSモダンアプリ開発入門
    • AWS Amplify Gen2とBedrockを組み合わせた最先端のモダンアプリ開発手法が学べます。

ディレクトリ構成

今回は既存のテンプレートを使わず、ゼロから作ります。最終的に以下の構成になります。

bedrock-sam-chat
│  template.yaml
└─hello_world
      app.py

実装ステップ

1. SAMテンプレート (template.yaml)

まずはインフラ定義です。
たったこれだけの記述で、API Gateway、Lambda関数、IAMロール(Bedrockへのフルアクセス権限付き)が作成されます。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  Secure GenAI Chat API with Bedrock & SAM

Resources:
  ChatFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.9
      Architectures:
        - x86_64
      Timeout: 120 # 生成AIはレスポンスに時間がかかる場合があるため長めに設定
      Policies:
        - AmazonBedrockFullAccess # 最小権限にする場合は絞ってください
      Events:
        ChatApi:
          Type: Api
          Properties:
            Path: /chat
            Method: post

Outputs:
  ChatApi:
    Description: "API Gateway endpoint URL for Prod stage for Chat function"
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/chat/"

ポイント:

  • Timeout: 120: デフォルトの3秒だと、生成AIの回答待ちでタイムアウトする可能性が高いため、長めに設定しています。
  • Policies: - AmazonBedrockFullAccess: LambdaにBedrockへのアクセス権限を付与しています。

2. Lambdaコード (hello_world/app.py)

次にアプリケーションロジックです。Pythonの boto3 を使ってBedrockを呼び出します。

import json
import boto3
import os

# クライアントの初期化はハンドラの外で行う(再利用のため)
bedrock = boto3.client('bedrock-runtime')

def lambda_handler(event, context):
    try:
        # リクエストボディからプロンプトを取得
        body = json.loads(event.get('body', '{}'))
        prompt = body.get('prompt', 'Hello')

        # 使用するモデルID (Claude 3 Sonnet)
        model_id = "anthropic.claude-3-sonnet-20240229-v1:0"

        # Bedrockへのリクエストペイロード作成
        # Claude 3向けのフォーマット (Messages API)
        request_body = json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 1000,
            "messages": [
                {
                    "role": "user",
                    "content": [{"type": "text", "text": prompt}]
                }
            ]
        })

        # Bedrock呼び出し
        response = bedrock.invoke_model(
            modelId=model_id,
            body=request_body
        )

        # レスポンスの解析
        response_body = json.loads(response.get('body').read())
        content = response_body.get('content')[0].get('text')

        return {
            "statusCode": 200,
            "body": json.dumps({
                "message": content
            }),
            "headers": {
                "Content-Type": "application/json"
            }
        }
    except Exception as e:
        print(f"Error: {str(e)}")
        return {
            "statusCode": 500,
            "body": json.dumps({
                "error": str(e)
            })
        }

デプロイと動作確認

デプロイ

プロジェクトのルートディレクトリで以下のコマンドを実行します。

sam build
sam deploy --guided

対話形式でスタック名などを聞かれますが、基本はデフォルト(Enter連打)でOKです。
デプロイが完了すると、Outputs セクションにAPIのURLが表示されます。

動作確認

curl コマンドでAPIを叩いてみましょう。

curl -X POST https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/chat/ \
     -H "Content-Type: application/json" \
     -d '{"prompt": "AWS SAMについて3行で教えて"}'

実行結果(例)

{"message": "AWS SAMは、サーバーレスアプリケーション構築のためのオープンソースフレームワークです。\nCloudFormationを拡張したシンプルな構文でリソースを定義できます。\nLambda、API Gateway、DynamoDBなどを簡単にデプロイ・管理できます。"}

無事、Claude 3からの回答が返ってくれば成功です!

さらなる拡張アイデア

この構成をベースに、以下のような機能を付け足していくと、立派な社内AIプラットフォームになります。

  1. VPCエンドポイント (PrivateLink): 以前の記事「AWS BedrockでVPCエンドポイント...」と組み合わせることで、社内ネットワークから閉域網でアクセス可能にできます。
  2. ログ保存: Lambda内でプロンプトと回答をDynamoDBやS3に保存すれば、誰がどんな使い方をしているか監査できます。
  3. ストリーミングレスポンス: 今回は簡易化のため待ち受け型(一括返信)にしましたが、LambdaのResponse Streamingを使えば、ChatGPTのように文字が少しずつ表示されるUIも実現可能です。

まとめ

AWS SAMを使えば、Bedrockを利用したチャットAPIがあっという間に構築できます。
まずはこの最小構成から始めて、プロジェクトの要件に合わせて育てていってみてください。
Happy Serverless Life!

AWS Amazon Lightsailなら固定IPも無料!Lightsailを使って運用料金最安値?でWordPress(ブログ)を運用する

概要~LightsailでWordPress構築・固定IPアドレス設定~

いろいろ調べたところWordPressを使ったブログ運用にはAWSのAmazon Lightsailを利用するのが最安値で最も簡単なのではないか?という結論に達したためAmazon LightsailでWordPressを構築する手順を投稿します。

運用料金

月額 $3.5 安い!
しかも今なら最初の3か月間は無料!

構築時間

15分

できるようになること

  • WordPressにログインできる
  • ブログが公開できる

作業手順

  1. インスタンス作成
  2. WordPressログインパスワードの確認
  3. 静的IPの設定
  4. WordPressログイン確認

たったの4手順作業時間15分でWordPressが構築できブログが公開できます!
それでは詳細手順を見ていきましょう。

1.インスタンス作成

まずはWordPressを構築するインスタンスを作成します。
AWSコンソールでAmazon Lightsailのサービスメニューを開き、インスタンスの作成をクリックします。

作成するインスタンスの種類を選択する画面に遷移します。
特にこだわりがなければすべてデフォルトの設定のままで良いと思います。
今回はWordPressの構築なので設計図の選択でWordPressが選択されていることを確認しましょう。

インスタンスプランの選択で月額料金が決定します。
人気ブログになったら変更しないといけないかもしれませんが、初期構築は最小で十分だと思うので、月額$3.5を選択します。
以上で設定は完了のため最後にインスタンスの作成をクリックします。簡単ですね。

無事に作成されると以下のように作成されたインスタンスが確認できる画面になります。

2.WordPressログインパスワードの確認

それでは次の手順に移ります。
次は作成されたインスタンスのWordPressにログインするためのパスワードを確認します。
パスワード確認にはインスタンスにsshでログインする必要がありますが、Amazon Lightsailの場合、ブラウザから簡単にログインできます。
具体的には以下の接続用ボタンを押します。(ちょっとわかりにくいですが、赤枠で囲んでいるオレンジの■部分です)

自動的にログインされ、以下のターミナルがブラウザで表示されます。

パスワードはファイルに記載されているため以下のコマンドを実行します。

cat $HOME/bitnami_application_password

ここではpasswordと表示されたとして手順を進めます。

3.静的IPの設定

設定としては最後の手順になります。
今のままでもWordPressにアクセスでき、ブログ公開もできるのですが、IPアドレスが変わってしまう可能性があり、不便なので固定の静的IPを設定します。
この静的IPアドレスは追加料金無し無料で設定できます。

それでは設定していきます。
まずはAmazon Lightsailのホーム画面に戻りネットワーキングをクリックします。

ネットワーキングのサービスメニューから静的IPの作成をクリックします。

インスタンスへのアタッチで作成したインスタンスを選択し、

作成ボタンで完了です。

完了画面に静的IP(18.XXX.XXX.XXX部)が表示されます。(画像はマスクしています)

4.WordPressログイン確認

準備は全て整いました!
後はログインするだけです。
ログイン用アクセスURLは以下になります。

http://{18.XXX.XXX.XXX(静的IP)}/wp-login.php

WordPressのログイン画面が表示されるので、WordPressの初期ユーザ(user)と、前の手順で確認したパスワードを入力してログインします。

無事にダッシュボードが表示されれば作業完了です。
お疲れ様でした!
後はWordPressを使ってサクッとブログを公開してしまいましょう。

まとめ

作業手順は4手順で作業完了です。
具体的な手順としてもコマンド1つだけであとは画面操作だけなので非常に簡単だったのではないでしょうか。
しかも月額$3.5です。Amazonさん凄いです。
しばらくこれで運用して様子を見ようと思います。(このブログもAmazon Lightsailで運用しています)

補足

最後補足としてAmazon Lightsailのさらに便利なところを紹介していきます。
それは管理画面からいろいろ確認できるところです。
管理画面は以下からアクセスします。

管理画面にアクセスすると以下のサービスメニューが表示されます。
ここでは、便利そうなものをいくつか紹介します。

まずはメトリクス。いろいろ見れるようです。

CPUの概要はこんなグラフです。

送信ネットワークトラフィックだとこんな感じ。

ネットワーキングでファイアフォール設定も確認できました。

履歴でインスタンスの変更履歴が確認できるようです。

削除も簡単にできそうです。

以上!Amazon Lightsailかなり簡単!便利!!安い!!!のではないでしょうか。

AWS ECSでDocker環境を試してみる

概要

AWS資格取得に向けて利用してみたAWSサービスの具体的な利用方法についての投稿です。
今回はAWS上でのDocker利用、 Amazon ECS(Amazon Elastic Container Service)を利用してみる編です。15分程度でDockerを利用したWebアプリケーションが公開できます。
勉強していてコンテナ、タスク、サービス、クラスターと言った用語に混乱してきたので実際にやってみました^^;

資格試験の勉強法は記事は以下を参照。

AWS初心者がAWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法
AWS初心者がAWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に合格した時の勉強法

想定読者

  • AWSでコンテナと言えばECSって気がするけど実際どうやってECS上でコンテナを動かすか知りたい人
  • ECSのコンテナ、タスク、サービス、クラスターをAWSコンソールで確認して理解を深めたい人

できるようになること

  • Amazon ECSでのWebアプリケーションの公開

およその作業時間

  • 15分
  • ECSの「今すぐ始める」メニューをやってみます
  • すべてデフォルト値でも構築できその場合、5クリック5分で完了します^^;

必要な知識

  • Docker
  • Amazon ECS

予想料金

残念ながら無料ではありません。今回利用するのはAmazon ECSのFargate起動タイプになるので以下の料金がかかります。

image.png
参照元:https://aws.amazon.com/jp/fargate/pricing/

CPUのvCPU単位とメモリのGB単位で料金がかかります。あと、ポイントなのはコンテナイメージのダウンロードを開始した時点からということですね。コンテナの起動有無に関わらず作成したら途中でコンテナ停止しても料金がかかっていることになります。(と言っても後述の必要なタスクの数で定義したコンテナが常時起動するので停止はあまり意味がないようです^^;)

今回の作成サンプルでざっくり計算するとCPU:0.25 vCPU(256)、メモリ:0.5GB(512)を利用するので、仮に一週間起動し続けたとすると

  • CPU:0.05056USD x 0.25vCPU x 24時間 x 7日 = 約2.12USD
  • メモリ:0.00553USD x 0.5GB x 24時間 x 7日 = 約0.46USD

合計 約2.58USD となります。
お試しであれば1日24時間も起動することはないと思うので安い!のではないでしょうか。
(もちろん他のサービス同様、使用用途によってはデータ転送量やCloudWatch利用料とかが追加されることはあるのでご注意ください)

手順の概要

ではやってみましょう。
とは言うものの、ECSの「今すぐ始める」メニューのウィザードに従って入力するだけです。
最初に全体像だけ説明すると、ECSの概念としては、

image.png

図のように、Container definitionTask definitionServiceClusterの4つがあり、こらをウィザードに従って3画面で設定してきます。

これがAmazon ECS理解の最初のハードルと思ったコンテナ、タスク、サービス、クラスターといった用語による混乱です。
それぞれの説明は以下のブラックベルト資料が分かりやすいと思いますが、なんとなく画面を進めながら設定値を眺めながらやっていくと理解できるようになると思います。

image.png
参照元:https://www.slideshare.net/AmazonWebServicesJapan/20200422-aws-black-belt-online-seminar-amazon-elastic-container-service-amazon-ecs

では、始めます。
ECSの初期画面、またはクラスターの今すぐ始めるをクリックして開始します。

image.png
または
image.png
今すぐ始めるをクリックして開始します。(クリック1回目)

Container definition/Task definition設定

最初の画面でContainer definitionとTask definition設定を行います。
コンテナ定義では、デフォルトでhttpd、nginx、tomcatが用意されています。(今回はhttpdを選択)
コンテナ定義、タスク定義いずれも右上に編集ボタンが用意されており、一部パラメータのカスタマイズは可能です。
料金の所で書いたようにCPUとメモリは料金に関係してくれるの編集でカスタマイズしても良いと思います。
とりあえず今回はデフォルトのままをクリック。(クリック2回目)

image.png

Service設定

次はサービス設定です。ロードバランサーとしてALBを組み込めるようですが、とりあえずなしを選択。
この画面も編集ボタンで料金に関係する必要なタスクの数をカスタマイズできます。ただデフォルト値の1から減らすことはできないので、最小限という意味ではこのままをクリック。(クリック3回目)

image.png

Cluster設定

最後にクラスター設定です。と言ってもクラスター名だけなのでデフォルトのままをクリック。(クリック4回目)

image.png

確認画面

確認画面が表示されるので、確認して作成をクリック。
以上!クリック5回で作成完了です!!

image.png

作成画面

内部的にはCloudFormationを使っているようなので、頑張ってVPCから作ってくれていて問題がなければ2,3分後に作成されます。

image.png
2,3分後、、、
image.png

サービスの表示をクリックしてみましょう。
作成されたVPCやサブネット、セキュリティグループの情報が確認できす。

image.png

タスクタブから作成されたタスクをクリックすると

image.png

パブリックIPが割り当てられているので、
http://{割り当てられていたパブリックIP}/
でアクセスしてみます。

image.png

↓が表示されていれば問題なく作成できています。
AWS ECSでのWebアプリケーションの公開完了です!

image.png

実体としては、コンテナ定義の中に定義されている以下のようです。

image.png

はい、クリック5回完了です。
あとはコンテナ定義などいじくり倒しましょう^^

コンテナ確認

ここからは作成されたものを1つ1つ見てみます。まずはコンテナから。
タスク定義のなかにコンテナ定義があります。

image.png

ポートマッピングやマウントポイントなど、コンテナ定義の名前そのままと言ってしまえばそれまでですが、Dockerfileの内容に関連する定義があることがわかります。

タスク確認

次はタスク定義です。

image.png

まず、タスク定義の中にコンテナ定義が含まれています。それに加えて、ネットワークモード、ロールやタスクサイズ(メモリやCPU)がタスク定義として役割のようです。(ブラックベルト資料の具体的定義がこの画面で確認できます)

サービス確認

次はサービスです。クラスターメニューから具体的なサービス名をクリックして確認します。

image.png

まずは必要数(必要なタスクの数)があって、加えてロードバランシング設定、VPCやサブネットといったネットワークアクセス設定があります。

image.png

タスクタブに移動するとタスク定義があり、この画面から複数タスク定義設定が可能なことがわかります。

クラスター確認

最後はクラスターです。

image.png

複数サービスを定義できる画面構成です。
ブラックベルト資料では、実行環境、IAM権限の境界と表現されています。
サービス定義、タスク定義でどのコンテナ定義をまとめるかにも依存すると思いますが、ロードバランシングがサービス定義にあることから、Webサーバ群のサービスとAPサーバ群のサービスの2つのサービスを1つのクラスター配下に定義する。といった使い方がイメージしやすいかなと思います。

補足1:自作Webアプリケーションのコンテナイメージの設定

Container definitionのcustom設定ボタンで自分で作成した今回のようなhttp(80ポート)のWebアプリケーションのコンテナイメージを指定するだけで簡単にWebアプリケーションの公開ができそうですね。

image.png
開いた画面でコンテナのイメージを設定
image.png

コンテナイメージの作成には以下の記事も投稿しているので参考までに。

Windowsで構成情報をDockerfileに定義してイメージを作成してみる

補足2:作成したタスクの停止

試しにタスクタブから停止してみても、、、

image.png

1,2分で再PROVISIONINGされ

image.png

すぐにRUNNING状態になります。

image.png

補足3:作成したWebアプリケーションの削除

クラスターメニューのクラスターの削除から簡単にできます。
CloudFormationを使っているのでVPCからコンテナのタスク定義までまるっと削除されます。
残しておくと料金がかかり続けるので不要になったら必ず削除しましょう。

image.png

まとめ

想像したよりずっと簡単に作成できました。
誰かのコンテナ、タスク、サービス、クラスター理解に役立てればと思います。
今のままだとデフォルト設定のままなので今後は設定内容等、もう少し詳しくみてみる。。。かもしれません(^^;)