【第1回】AWSエンジニアのための生成AI基礎とAmazon Bedrockの全体像

※本記事はAIが書いて、人間が伴走しファクトチェックしています。
ちょっと大げさな表現がありますがAIの性格だと思って生暖かい目で見ていただければ幸いです。

📅 連載構成案（全6回）

全体の流れとして、まずは「生成AIの基礎」から入り、次に「自社データとの連携（RAG）」、そして「自律的なアクション（Agents）」、最後にそれを本番運用・拡張する「基盤（AgentCore）」へと、ステップアップしていく構成にしています。今回は第2回になります。

第1回：生成AIとAmazon Bedrockの基礎 〜まずは用語を整理しよう〜　 （今回はここ！！）

• 概要: 生成AIのバズワードをAWSエンジニアの視点で分かりやすく翻訳し、Amazon Bedrockの立ち位置を解説します。
• 解説する主な用語: LLM（大規模言語モデル）、プロンプト、トークン、基盤モデル（Foundation Model）
• Bedrockの解説ポイント: * 「複数メーカーのモデル（ClaudeやLlamaなど）を、1つのAPIで切り替えて使えるAWSのフルマネージドサービス」であること。
  • 【重要】 入力データがモデルの再学習に利用されないなど、AWSの強固なセキュリティ環境で生成AIを使えるメリット。

第2回：Amazon Bedrockを触ってみよう 〜コンソール体験とコスト感〜

• 概要: 実際にAWSマネジメントコンソールからBedrockのモデルを有効化し、プレイグラウンドで動かしてみる「手触り感」を伝える回です。
• 解説する主な用語: ハルシネーション（もっともらしい嘘）、推論パラメータ（Temperatureなど）
• Bedrockの解説ポイント:
  • コンソールからのモデルアクセス有効化の手順。
  • テキスト生成と画像生成の簡単なデモ。
  • 従量課金制（トークン課金）の仕組みと、コストの見積もり方の基本。

第3回：自社データをAIに教える「RAG」とKnowledge Bases

• 概要: 「社内規程について質問したい」といったよくあるニーズに対し、モデルを再学習させずに自社データと連携させる手法を解説します。
• 解説する主な用語: RAG（検索拡張生成）、ベクトルデータベース、エンベディング（Embedding）
• Bedrockの解説ポイント:
  • Knowledge Bases for Amazon Bedrockの紹介。S3にPDFを置くだけで、OpenSearch Serverlessなどと連携してRAG環境がマネージドに構築できる仕組みを解説します。

第4回：AIが自律的に動く！Bedrock Agentsとは？

• 概要: ここからが本番です。単に質問に答えるだけでなく、AI自身が考えて社内システム（API）を叩く「AIエージェント」の概念を解説します。
• 解説する主な用語: AIエージェント、Chain of Thought（思考の連鎖）、ツール呼び出し（Function Calling）
• Bedrock Agentsの解説ポイント:
  • ユーザーの曖昧な指示から、AIが「計画→API呼び出し（Lambdaなど）→結果の解釈」を自律的に行う仕組み。
  • Action Groups（エージェントが実行できるタスクの定義）の概念。

第5回：本番運用を支える新基盤「Amazon Bedrock AgentCore」の全貌

• 概要: 開発したエージェントを「安全に」「大規模に」本番環境で運用・デプロイするための最新プラットフォーム「AgentCore」の役割を解説します。
• 解説する主な用語: セッション分離、オブザーバビリティ（可観測性）、ガードレール
• Bedrock AgentCoreの解説ポイント:
  • Runtime: エージェントをサーバーレスかつセキュア（分離された環境）で実行する仕組み。
  • Memory: ユーザーごとの会話の文脈や長期記憶をインフラ管理なしで保持する機能。
  • Gateway / Policy: エージェントがアクセスできるツールや外部APIを安全に管理し、意図しない動作を防ぐガバナンス機能。
  • Evaluations: エージェントの回答品質を継続的に評価・モニタリングする仕組み。

第6回：まとめ 〜AWSで作る業務特化型AIエージェントのアーキテクチャ〜

• 概要: 連載の総まとめとして、AWSエンジニア向けに「社内向け業務支援エージェント」を構築する場合の全体アーキテクチャ図を提示します。
• 内容:
  • ユーザー（Cognito）→ AgentCore Identity → AgentCore Runtime → Bedrock Agents → 既存の社内API（Lambda）という具体的な連携フローの紹介。
  • これから生成AIに取り組むAWSエンジニアへのネクストステップの提示。

1. はじめに：なぜAWSエンジニアが生成AIを学ぶべきなのか？

「EC2やS3、Lambdaの構築はできるけど、生成AIはChatGPTをブラウザで少し触ったくらい…」
「業務で使いたいと言われたが、セキュリティや構築方法がよくわからない」

そんな風に感じているAWSエンジニアの方は多いのではないでしょうか？
生成AI（特に大規模言語モデル：LLM）は魔法の箱のように見えますが、システムアーキテクチャの観点から見れば 「テキスト（文字列）を入れると、いい感じのテキストを返してくれる強力なAPI」 に過ぎません。

本連載では、AWSエンジニアの皆様がこれまでに培ったインフラやサーバーレスの知識を活かし、安全で実用的なAIシステム（エージェント）を設計・構築できるようになることを目指します。第1回は、バズワードになりがちなAI用語の翻訳と、AWSの生成AIサービス「Amazon Bedrock」の全体像を解説します。

---

2. これだけは押さえたい！生成AIの基本用語（AWSエンジニア向け翻訳）

抽象的なAI用語を、私たちが普段使っているAWSの概念に例えて整理してみましょう。

• 基盤モデル（Foundation Model） / LLM（大規模言語モデル）
  • 意味: 膨大なデータで事前学習された、汎用的に使える強力なAIモデル。テキストに特化したものがLLMです。
  • AWSエンジニア向け翻訳: 「OSのベースイメージ（公式AMI）」。そのまま起動して汎用的に使うことも、自社用にカスタマイズ（後述のRAGなど）して使うこともできます。
• プロンプト（Prompt）
  • 意味: AIに対する指示や入力データのこと。
  • AWSエンジニア向け翻訳: 「SQL文」や「CLIコマンド」。AIというブラックボックスのAPIに対して、期待する出力を得るためのクエリです。書き方（プロンプトエンジニアリング）次第で結果が大きく変わります。
• トークン（Token）
  • 意味: AIがテキストを処理する際の最小単位（例：英語なら1単語、日本語なら1〜数文字で1トークン）。
  • AWSエンジニア向け翻訳: 「Lambdaの実行時間」や「データ転送料」と同じ、コスト計算のベースになる単位。入力（Inference）と出力（Generation）のトークン数で従量課金されます。
• コンテキストウィンドウ（Context Window）
  • 意味: AIが1回のやり取りで記憶・処理できる最大トークン数（テキスト量）。
  • AWSエンジニア向け翻訳: 「API Gatewayのペイロード制限」や「Lambdaのメモリ上限」。これをオーバーする大量のログやドキュメントを一度に投げ込むとエラーになります。
• ハルシネーション（Hallucination）
  • 意味: AIが事実とは異なる「もっともらしい嘘」を出力する現象。
  • AWSエンジニア向け翻訳: 「仕様を誤解して書かれた、一見正しそうなバグコード」。AIは「確率的に正しい文字列」を繋げているだけなので、息を吐くように嘘をつくことがあります。これをどう制御するかがアーキテクトの腕の見せ所です。
• ファインチューニング（Fine-tuning）
  • 意味: 既存のモデルに独自のデータを追加学習させ、特定のタスクに特化させること。
  • AWSエンジニア向け翻訳: 「Packer等を使ったカスタムAMIのビルド」。強力ですが、学習データの準備やコストのハードルが高いです。最近は、モデル自体は弄らずに外部データだけを検索して回答させる「RAG（第3回で解説）」が主流です。
• クロスリージョン推論（Cross-region inference）
  • 意味: 特定のリージョンでAPIの制限（スロットリング）が発生した際、自動的に別のリージョンにリクエストをルーティングして処理を継続する仕組みです。
  • AWSエンジニア向け翻訳: 「Route 53のフェイルオーバールーティング」や「マルチAZ構成」。生成AIのAPIはリソース不足でエラーになりやすいですが、AWS側で可用性をマネージドに高めてくれます。

---

3. Amazon Bedrockとは？選ばれる最大の理由は「セキュリティ」

Amazon Bedrockは、AWS上で生成AIを利用するためのフルマネージドサービスです。Bedrockの最大の特徴は以下の2点です。

1. 1つのAPIで複数メーカーのモデルを使える
   Anthropic社の「Claude 3」やMeta社の「Llama 3」、Amazon独自の「Titan」など、様々な基盤モデルを同じAPIインターフェースで利用できます。用途やコストに合わせて、EC2のインスタンスタイプ（Compute Optimized, Memory Optimizedなど）を切り替えるような感覚でAIモデルを選択できます。
2. 【重要】強固なセキュリティとガバナンス
   企業がChatGPTなどのパブリックなAIを業務導入する際、「入力した機密情報がAIの学習に使われてしまうのでは？」という懸念が必ず出ます。
   Bedrockを利用する最大のメリットはここです。Bedrockに入力したプロンプトや自社データが、基盤モデルの再学習に利用されることは絶対にありません。
   さらに、HIPAA、GDPR、ISOなどの各種コンプライアンス要件にも準拠しています。エンタープライズ企業が「社内稟議」を通す際、この強力なコンプライアンスとデータ保護の仕組みが最大の武器になります。
   また、VPCエンドポイント（AWS PrivateLink）を経由して閉域網でAPIを叩けるため、データがインターネットに晒されることなく、IAMによる緻密なアクセス制御も可能です。

---

4. Bedrockの具体的なユースケース（業務活用例）

「で、結局何に使えるの？」という疑問に対し、インフラエンジニアに身近な例を1つ紹介します。

【ユースケース：CloudWatch Logsのエラーログ自動要約とトラブルシューティング支援】

• 課題: アラートが鳴った際、大量のスタックトレースやログから原因を特定するのに時間がかかる。
• 解決策（アーキテクチャ）:
  1. EventBridgeで特定のエラーを検知し、Lambdaを起動。
  2. Lambdaが直近のエラーログを取得し、Bedrock（Claude 3 Haikuなど、高速・低コストなモデル）に渡す。
  3. プロンプト：「あなたは熟練のSREです。以下のエラーログの原因と、考えられる解決策を日本語で3行で要約してください。[ログデータ]」
  4. Bedrockの回答（要約結果）をSlackに通知する。

このように、既存のAWSリソースと組み合わせることで、 「高度なテキスト処理ができるLambda関数」 のような位置づけで業務を自動化できます。

---

5. 触ってみよう：Bedrockの画面とコードの雰囲気

「環境構築が大変そう…」と思うかもしれませんが、GPUインスタンスを立てる必要は一切ありません。

マネジメントコンソールでの準備

Bedrockのコンソール画面を開き、左下の「モデルアクセス（Model access）」を選択します。使いたいモデルのチェックボックスをオンにして「変更を保存」するだけです。数分でステータスが「アクセス付与済み」になり、すぐに使い始められます。

Boto3（Python）での呼び出しイメージ

いつも使っているAWS SDK（Boto3）で、わずか数行で生成AIを呼び出せます。
ここでは、モデルごとの仕様の違いを吸収してくれる便利な 「Converse API」 を使った例を紹介します。

import boto3

# Bedrockクライアントの初期化
bedrock = boto3.client(service_name='bedrock-runtime', region_name='us-east-1')

# モデルIDの指定（例：軽量で高速な Claude 3 Haiku）
# ※ ここを「Llama 3」などの別のモデルIDに変えても、下のコードはそのまま動きます！
model_id = 'anthropic.claude-3-haiku-20240307-v1:0'

# Converse APIの呼び出し（モデル共通のインターフェース）
response = bedrock.converse(
    modelId=model_id,
    messages=[
        {
            "role": "user",
            "content": [{"text": "AWS LambdaとBedrockを連携させるメリットを教えてください。"}]
        }
    ],
    inferenceConfig={
        "maxTokens": 500 # 出力トークンの上限（コスト制御）
    }
)

# 結果の出力
print(response['output']['message']['content'][0]['text'])

いかがでしょうか？各モデル独自のペイロード構造（JSONの書き方）を気にする必要がなく、APIキーの管理も不要で、IAMロールベースで安全に実行できます。

---

6. 第1回のまとめと次回予告

今回は、生成AIの基本用語をAWSエンジニアの視点で翻訳し、Amazon Bedrockの全体像とエンタープライズで使うメリット（セキュリティ・コンプライアンス・IAM統合）を解説しました。生成AIは決して魔法ではなく、私たちのシステムに組み込める強力なコンポーネントです。

次回（第2回）は、 「Amazon Bedrockを触ってみよう 〜コンソール体験とコスト感〜」 と題して、コンソールの「プレイグラウンド」を使った実践的なプロンプトの試し方や、気になる「トークン課金とコストの見積もり方」について深掘りします。お楽しみに！