Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

AWS・生成AI・コンテナ連携ガイド アウトライン

本ドキュメントは、AWS（Amazon Web Services）におけるコンテナ関連サービス、生成AIサービス「Amazon Bedrock」、およびこれらとアプリケーション開発フレームワークである「LangChain / LangGraph」を連携させて動作させるための解説書です。

本書は「入門編」と「実施編」の2つのレベルに分かれています。

入門編

1. はじめに

  • 本書の目的と想定する全体像
  • AWS（Amazon Web Services）の概要と特徴

2. Docker関連サービスとコンテナ運用

  • ECR（Elastic Container Registry）の役割
  • ECS（Elastic Container Service）とFargateによるコンテナ実行
  • EKS（Elastic Kubernetes Service）の概要

実施編

3. Amazon Bedrockによる生成AIの活用

  • Amazon Bedrockの基本概念とメリット
  • boto3（Python用AWS SDK）を使用したモデル呼び出しコード

4. AWS上でのLangChain / LangGraphの構築と連携

  • LangChain / LangGraphとBedrockの接続方法
  • AWS環境（ECS / Lambda）におけるエージェントアプリケーションの配備構成
  • FastAPIの代替としてのASP.NET Coreとの連携構成

第1章 はじめに

1.1 本書の目的と想定する全体像

本書は、大手クラウドサービスであるAWS上でコンテナ技術を使ってアプリケーションを動かし、さらに最新の生成AI（人工知能）や自律的に動くAIエージェントの仕組みを組み込んで運用したいと考えている開発者を対象としています。

クラウドが持つ「システム規模を柔軟に変更できる強み」と、AI開発をサポートするフレームワーク「LangChain / LangGraph」を組み合わせることで、安定的でかつ賢く動作する次世代の業務アプリケーションを構築する手順を解説します。

1.2 AWS（Amazon Web Services）の概要と特徴

AWSは、Amazon社が提供している世界で最も広く利用されているクラウドサービスのプラットフォームです。インターネットを通じて、サーバー、データベース、ストレージ（ファイルを保存する場所）といったITリソースを必要な分だけ借りて使用することができます。

実物のサーバー機器を購入して管理する手間と初期コストが不要であり、使った分だけ料金を支払う「従量課金制」が特徴です。これにより、個人の小さな実験用システムから、大企業の数千万人規模が使うWebサービスまで、あらゆる規模のシステムを迅速に立ち上げて拡張させることができます。

第2章 Docker関連サービスとコンテナ運用

2.1 ECR（Elastic Container Registry）の役割

ECRは、自分で作成したDockerイメージ（コンテナを作るためのパッケージ）をAWS上で安全に保存・管理するための保管庫（プライベートレジストリ）サービスです。

自分のパソコンで開発したアプリケーションをDockerイメージとして書き出し、それをECRへ送信（プッシュ）して保存します。実際にAWS上でアプリケーションを動かす際には、後述するECSやEKSなどの実行サービスが、このECRから保存されたイメージを取り出してコンテナを起動する仕組みになっています。

2.2 ECS（Elastic Container Service）とFargateによるコンテナ実行

ECSは、AWS上で多数のDockerコンテナを効率よく整理し、起動や停止、監視を行うためのマネージドサービスです。

コンテナを動かす土台として「Fargate（ファーゲート）」という仕組みを組み合わせるのが一般的です。Fargateは、コンテナを実行するための仮想サーバーマシンの管理をすべてAWS側が裏で自動で行ってくれる「サーバーレス」の技術です。これにより、開発者はサーバー自体のアップデートやセキュリティ対策に頭を悩ませることなく、コンテナプログラムを配置するだけで安全に動かすことができます。

2.3 EKS（Elastic Kubernetes Service）の概要

EKSは、大規模なコンテナの群れを高度に連携させて動かすためのシステムである「Kubernetes（クバネティス）」を、AWS上で簡単に使えるように調整したマネージドサービスです。

EKSを使うことで、複数のコンテナ間で複雑な通信を行ったり、アクセス数に応じて自動でコンテナの数を数十倍に増やしたりする作業（オーケストレーション）が簡単になります。前述のECSに比べて設定が複雑ですが、業界標準のKubernetesの知識をそのまま活用できるため、他社クラウドとの連携や、極めて大規模なシステムにおいて選ばれます。

2.4 ECR・ECS・EKSの関係図

コンテナ開発におけるこれら3つのサービスの関係性は、以下のようになります。ローカル環境で作成したイメージをECRに保存し、それをECSやEKSが取り出して実行します。

graph TD
    subgraph Local ["ローカル開発環境"]
        PC["開発用PC (Dockerイメージ作成)"]
    end

    subgraph AWS ["AWSクラウド"]
        ECR["Amazon ECR (イメージ保管庫)"]
        
        subgraph Execution ["コンテナ実行環境"]
            ECS["Amazon ECS + Fargate (サーバーレスで実行)"]
            EKS["Amazon EKS (Kubernetesで実行)"]
        end
    end

    PC -->|1. イメージをプッシュ| ECR
    ECR -->|2. イメージをプル| ECS
    ECR -->|2. イメージをプル| EKS

第3章 Amazon Bedrockによる生成AIの活用

3.1 Amazon Bedrockの基本概念とメリット

Amazon Bedrock（アマゾン・ベッドロック）は、世界中の有名なAI開発会社（Anthropic、Meta、Mistral AIなど）が作成したさまざまな超高性能AIモデルを、共通の接続口（API）を通して簡単に利用できるサーバーレスサービスです。

自分たちで巨大なAIを動かすための高性能なサーバーを購入して管理する必要がなく、インターネット経由でAIに文字を送信し、返答を受け取ることができます。また、セキュリティ対策が非常に厳格であり、AIに送信した質問内容や社内データが、外部のAIの学習用データとして勝手に再利用されることがありません。これにより、企業の機密情報を扱う場合でも、安心して高性能な生成AIをシステムに組み込むことができます。

3.2 boto3を使用したモデル呼び出しコード

PythonプログラムからAmazon Bedrockを利用するには、AWSが公式に提供しているライブラリである boto3 を使用します。

以下は、推奨されている最新の converse（会話用）APIを使用して、高性能AIモデルである「Anthropic Claude 3.5 Sonnet」を呼び出してテキストを生成させるためのPythonコード例です。

import boto3

# 1. Amazon Bedrock用のクライアント（通信窓口）を初期化します
# ※AWSのクレデンシャル（認証情報）が設定されている環境を前提とします
client = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"  # Bedrockが利用可能な地域を指定します
)

# 2. 使用するAIモデルの識別番号（モデルID）を指定します
# ここではAnthropic社のClaude 3.5 Sonnetを指定しています
model_id = "anthropic.claude-3-5-sonnet-20240620-v1:0"

# 3. 送信するメッセージのリストを組み立てます
messages = [
    {
        "role": "user",
        "content": [{"text": "Amazon Bedrockのメリットを、中学生にもわかるように短く箇条書きで教えて。"}]
    }
]

try:
    # 4. モデルを呼び出して推論を実行します（Converse API）
    response = client.converse(
        modelId=model_id,
        messages=messages,
        inferenceConfig={
            "maxTokens": 500,     # 出力する最大のトークン数（文字量の目安）
            "temperature": 0.5    # 回答のランダムさ（低いほど実用的で安定します）
        }
    )
    
    # 5. 返ってきた応答データから回答文のテキストを取り出して表示します
    output_text = response["output"]["message"]["content"][0]["text"]
    print(output_text)

except Exception as e:
    print(f"エラーが発生しました: {e}")

このコードを実行することで、AWS上の安全な通信を経由して、最新のAIモデルからの的確な回答を取得することができます。

第4章 AWS上でのLangChain / LangGraphの構築と連携

4.1 LangChain / LangGraphとBedrockの接続方法

LangChainおよびLangGraphは、AWSとの連携をサポートするための専用パッケージ langchain-aws を提供しています。これを使用することで、前章で解説したAmazon Bedrock上の各種AIモデルを、他のLangChainコンポーネントと同じ方法で簡単に組み込むことができます。

以下は、ChatBedrock クラスを初期化し、LangGraphのグラフ構成ノード内で呼び出すためのPythonコード例です。

from typing import Annotated, Sequence, TypedDict
from langchain_aws import ChatBedrock
from langchain_core.messages import BaseMessage
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages

# 1. 状態（State）の定義
class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]

# 2. Bedrockを呼び出すLLMオブジェクトを初期化します
# langchain-awsで提供されている ChatBedrock クラスを使用します
llm = ChatBedrock(
    model_id="anthropic.claude-3-5-sonnet-20240620-v1:0",  # 利用するモデルID
    model_kwargs={"temperature": 0.5},                      # パラメータ設定
    region_name="us-east-1"                                 # リージョン
)

# 3. ノード関数の定義
def call_agent(state: AgentState):
    # ChatBedrockオブジェクトにメッセージ履歴を渡して呼び出します
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

# 4. グラフの構築
workflow = StateGraph(AgentState)
workflow.add_node("agent", call_agent)
workflow.add_edge(START, "agent")
workflow.add_edge("agent", END)

app = workflow.compile()

Ollama（ローカル）からBedrock（クラウド）へのスムーズな移行

開発中は自分のPC（ローカル環境）で Ollama を使ってテストを行い、本番運用時にクラウド上の Amazon Bedrock へ切り替える、という運用は極めて簡単に行えます。

LangChainでは、Ollama接続用の ChatOllama クラス（langchain-community パッケージ）と、Bedrock接続用の ChatBedrock クラスは、どちらも BaseChatModel という共通のインターフェース（仕様）を継承しています。そのため、初期化するクラスのみを環境に応じて切り替えれば、プロンプトの連結処理やLangGraphのグラフ構造といったアプリ本体のプログラムコードは1文字も変更する必要がありません。

以下は、環境変数 ENV の値に基づいて、接続先のAIモデルを動的に切り替える実装コード例です。

import os
from langchain_aws import ChatBedrock
from langchain_community.chat_models import ChatOllama

# 環境変数が "production"（本番）かどうかで切り替えます
IS_CLOUD = os.getenv("ENV") == "production"

if IS_CLOUD:
    # クラウド環境（AWS BedrockのClaude 3.5 Sonnetを使用）
    llm = ChatBedrock(
        model_id="anthropic.claude-3-5-sonnet-20240620-v1:0",
        region_name="us-east-1"
    )
else:
    # ローカル開発環境（OllamaのLlama 3を使用）
    llm = ChatOllama(
        model="llama3",
        base_url="http://localhost:11434"
    )

# ーーー これ以降の処理はローカル・クラウドで共通です ーーー
# どちらのLLMであっても、全く同じ記述で呼び出せます
response = llm.invoke("こんにちは")

移行時の注意点

  • AIの「賢さ」による動作の差: ローカルで動作する軽量モデル（Ollama）と、クラウドの高性能モデル（BedrockのClaude等）では、指示に従う能力に大きな差があります。特にLangGraphでツールの呼び出し判断をAIに任せる場合は、ローカル環境でも比較的性能の高いモデル（llama3.1:8b や qwen2.5:14b など）を選択することが推奨されます。
  • パッケージのインストール: ローカル開発とAWSデプロイの双方に備え、langchain-community と langchain-aws の両方のライブラリをプロジェクトにインストールしておきます。

4.2 AWS環境（ECS / Lambda）におけるエージェントアプリケーションの配備構成

作成したLangGraphのAIエージェントを実際に本番のAWS上で稼働させるための、代表的な配備構成を2パターン紹介します。

パターンA: ECS + FargateによるAPIサーバー構成（推奨）

ユーザーからのリクエストを受けて自律的に思考し、複数のツールを何度も呼び出すエージェントの場合、全体の処理が完了するまでに数十秒〜数分かかることがあります。この場合は、ECSとFargateを組み合わせてWeb APIサーバー（例: FastAPI）をコンテナとして常時起動させる構成が適しています。

  • 状態（State）の永続化: コンテナの再起動などで会話データが消えないよう、チェックポインタの保存先にはメモリ（MemorySaver）ではなく、AWSの高速なNoSQLデータベースサービスである「Amazon DynamoDB」などを指定して保存します。
  • セキュリティと認証: ECSのタスクに対して「IAMロール」を付与することで、プログラムコードの中にAWSのアクセスキーやAPIキーを直接書き込むことなく、安全にBedrockのAPIを呼び出せます。

以下は、一般的なECS + Fargateによる構成イメージです。

graph TD
    User([ユーザー]) -->|リクエスト| APIGW[Amazon API Gateway]
    
    subgraph VPC ["AWS VPC (セキュリティ境界)"]
        APIGW -->|ルーティング| ECS[ECS / Fargate<br>FastAPI + LangChain]
        ECS -->|1. 状態の保存・取得| Dynamo[Amazon DynamoDB<br>会話履歴の保存]
        
        %% 権限管理
        IAM[IAMロール<br>bedrock:InvokeModel] -.->|安全な認証| ECS
    end
    
    ECS -->|2. API呼び出し| Bedrock[Amazon Bedrock<br>Claude 等]

パターンB: AWS Lambdaによるサーバーレス構成

処理時間が15分以内に確実に収まるような、小規模な定型タスクを実行するエージェントの場合は、AWS Lambda（ラムダ）にDockerコンテナイメージをデプロイして動かす「サーバーレス構成」が費用を最も低く抑えられます。

  • メリット: リクエストが来た瞬間だけコンテナが立ち上がって処理を実行し、実行が終われば自動で停止するため、無駄な待機費用（基本料金）が一切発生しません。完全に使った分だけの従量課金になります。

以下は、一般的なAWS Lambdaによる構成イメージです。

graph TD
    User([ユーザー]) -->|API呼び出し| APIGW[Amazon API Gateway]
    APIGW -->|トリガー| Lambda[AWS Lambda<br>Python + LangChain]
    
    subgraph AWS ["AWS クラウド"]
        Lambda -->|API呼び出し| Bedrock[Amazon Bedrock]
        
        %% 権限管理
        IAM[IAMロール] -.->|権限付与| Lambda
    end

4.3 FastAPIの代替としてのASP.NET Coreとの連携構成

Python製のWebフレームワークである FastAPI の代わりに、C#製の ASP.NET Core をWeb APIサーバーとして採用する場合、LangChain / LangGraph（Python製）とどのように連携させるかによって、2パターンの設計構成が考えられます。

パターン1: マルチリンガル（APIとAI処理の分離）構成

既存のC#による業務システム、データベースアクセス、認証基盤などを ASP.NET Core で構築し、AIエージェント（LangGraph）のみを別の独立したPythonコンテナとして動作させ、VPC（プライベートネットワーク）内でgRPCまたはREST APIを用いて通信・連携させます。

  • メリット: LangGraphなどPythonでしか提供されていない最新のAIライブラリ資産を100%活用しつつ、既存の.NETエコシステムに統合できます。
  • 配備構成: ECSとFargate上に、ASP.NET Core用のコンテナとPythonエージェント用のコンテナの2つを配置します。

以下は、一般的なマルチリンガル連携の構成イメージです。

graph TD
    User([ユーザー]) -->|1. リクエスト| NET[ASP.NET Core<br>Web API サーバー]
    
    subgraph VPC ["AWS VPC (セキュリティ内)"]
        NET -->|2. gRPC / REST API| PyAgent[Python Fargate<br>LangGraph エージェント]
        PyAgent -->|3. 状態の保存| Dynamo[Amazon DynamoDB]
    end
    
    PyAgent -->|4. AI呼び出し| Bedrock[Amazon Bedrock]

パターン2: 完全.NET（C#によるAI構築）構成

Python環境をインフラ内に一切用意せず、C#のコードだけでAPIサーバーとAI処理のすべてを完結させる構成です。この場合、Microsoftがオープンソースで提供しているAIオーケストレーションフレームワークである「Semantic Kernel（セマンティック・カーネル）」を ASP.NET Core のアプリケーション内部に組み込んで使用します。

  • メリット: 起動するコンテナイメージがC#の1つだけで済むため、インフラのデプロイや保守管理が極めてシンプルになります。
  • 配備構成: 従来の .NET アプリケーションと同様に、ECS/FargateまたはAWS App Runnerなどにコンテナをデプロイして動かします。

以下は、完全.NET構成のイメージです。

graph TD
    User([ユーザー]) -->|1. リクエスト| NET[ASP.NET Core<br>Web API + Semantic Kernel]
    
    subgraph AWS ["AWS クラウド"]
        NET -->|2. AI呼び出し (AWS SDK)| Bedrock[Amazon Bedrock]
    end