※本記事は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. はじめに：まずは「素のAI」の挙動を知ろう
こんにちは。AWSエンジニアのための生成AI入門、第2回です。
前回は、生成AIの基本用語とAmazon Bedrockの全体像、そして最大の強みである「強固なセキュリティ環境」について解説しました。
今回は、実際にAWSマネジメントコンソールを使ってBedrockに触れていきます。EC2を構築する前にマネジメントコンソールでポチポチと設定項目を確認するように、生成AIもまずは「プレイグラウンド」と呼ばれるテスト環境で挙動を確かめるのが一番の近道です。
あわせて、実運用で必ず壁になる「推論パラメータのチューニング」と、インフラエンジニアとして絶対に押さえておきたい「トークン課金とコスト見積もり」についても解説します。
2. コンソールで実践！Bedrockのモデルアクセスとプレイグラウンド
Bedrockはフルマネージドサービスであるため、サーバーのプロビジョニングは不要です。さらに最近のアップデートにより、事前の面倒な有効化作業も不要になりました。
ステップ1：モデルは「自動有効化」へ（最新アップデート）
以前のBedrockでは、利用したいモデルごとに「モデルアクセス（Model access）」画面から手動で利用申請（有効化）を行う必要がありました。
しかし現在、この画面は廃止され、AWSアカウントに対してすべてのサーバーレス基盤モデルがデフォルトで自動的に有効化される仕様に変わりました。
つまり、Bedrockに対する適切なIAM権限（bedrock:InvokeModelなど）さえ付与されていれば、コンソールからすぐにモデルを使い始めることができます。（※一部のサードパーティモデルで初回のみEULAへの同意ポップアップが出る場合があります）
【💡AWSエンジニア向けの構築Tips】
この「自動有効化（Subscribe-on-first-call）」は、裏側でAWS Marketplaceのサブスクリプションを自動作成する仕組みで動いています。そのため、Anthropicなどのモデルをアカウントで一番最初に呼び出すIAMユーザー（またはロール）には、bedrock:InvokeModel に加えて aws-marketplace:Subscribe の権限が必要になるケースがあります。もし初回実行時にAccessDeniedエラーが出た場合は、この権限をチェックしてみてください。
ステップ2：プレイグラウンドでプロンプトを試す
左側のメニューから「プレイグラウンド (Playgrounds)」の「チャット/テキスト (Chat/Text)」を開いてみましょう。ここが、API経由で投げるプロンプトをGUIでテストできる環境です。
モデルを選択（例：最新モデルであるAnthropic社のClaude 4.6 Sonnetなど）し、チャットボックスに以下のように入力して「実行 (Run)」を押してみてください。
ユーザー: AWS Lambdaの特徴を、小学生でもわかるように3行で説明して。
すぐにAIからの回答がストリーミングで返ってくるはずです。このプレイグラウンドでのやり取りを通じて、モデルごとのレスポンス速度や回答のトーンの違いを体感できます。
ステップ3：プレイグラウンドで画像生成も試してみよう
テキストだけでなく、画像生成もコンソールから簡単に試せます。左側のメニューから「プレイグラウンド」の「画像 (Image)」を開いてみましょう。
モデル（例：Amazon Titan Image Generator v2 など）を選択し、プロンプトに以下のように入力して「実行 (Run)」を押します。
プロンプト: サーバーラックが並ぶ近未来的なデータセンター。青と紫のネオンライト。高画質。
すると数秒で、プロンプトに沿った高品質な画像が生成されます。テキスト生成（トークン課金）とは異なり、画像生成モデルは**「生成した画像1枚あたり〇円（解像度やステップ数で変動）」**というシンプルな課金体系になる点も、アーキテクトとして覚えておきましょう。
3. 生成AIの出力をコントロールする「推論パラメータ」
プレイグラウンドの右側に、いくつかスライダーがあることに気づいたでしょうか？これが「推論パラメータ」です。AIの回答の「ブレ幅」を調整するための重要な設定項目です。
-
Temperature（温度）
- 意味: AIが次の単語を選ぶ際の「ランダム性」を制御します。0〜1（モデルによってはそれ以上）で設定します。
- AWSエンジニア向け翻訳: 「回答のクリエイティビティ・ダイヤル」。
- 使い方: 値を低く（0に近く）すると、常に無難で決定論的な回答を返します。ログ解析やJSONのパースなど、正確性が求められるシステムタスクでは「0」が基本です。逆にキャッチコピーの考案など、多様性が欲しい場合は高め（0.7など）に設定します。
-
Top P / Top K
- 意味: 次の単語の候補を、確率が高い順にどこまで絞り込むかの設定です。Temperatureとセットで使われることが多いです。
-
Maximum Length（最大長）
- 意味: AIが生成する出力トークン（テキスト）の最大量。
- 使い方: 暴走して不要な長文を生成し、コストが無駄にかかるのを防ぐための「リミッター」として機能します。
ハルシネーション（嘘）を抑え込むプロンプトのコツ
推論パラメータ（Temperature=0）に加えて、プロンプトの書き方でもAIの嘘を制御できます。業務システムに組み込む際の鉄則は、**「分からない場合は、分からないと答えさせる」**ことです。
良いプロンプトの例:
以下の[参考ログ]の内容だけに基づいて、エラーの原因を特定してください。
もし[参考ログ]の中に原因を特定できる情報が含まれていない場合は、「情報不足のため特定できません」とだけ出力し、推測による回答は絶対にしないでください。
4. 気になるコスト感：トークン課金の見積もり方
AWSエンジニアにとって最も気になるのが「いくらかかるのか？」です。Bedrockの課金モデルは、基本的に**「従量課金（オンデマンドスループット）」**です。
EC2が「稼働時間」、Lambdaが「実行時間×メモリ」で課金されるように、LLMは**「処理したトークン数」**で課金されます。
入力トークンと出力トークン
料金は以下の2つの合計で決まります。一般的に、出力を生成する方がコンピューティングリソースを食うため、出力トークンの単価が高く設定されています。
- 入力トークン (Input Tokens): ユーザーが送信したプロンプトや参考データの量
- 出力トークン (Output Tokens): AIが生成して返した回答の量
モデルによるコストの違い（例：Claude 最新の4.6ファミリー）
用途によってモデルの「賢さ」と「コスト」のトレードオフを選択するのがアーキテクトの腕の見せ所です。（※料金はus-east-1等の目安。2026年2月にリリースされた最新のClaude 4.6ファミリーでは、最上位モデルのOpusが大幅にコストダウンされ、より実運用に組み込みやすくなりました）
【💡注目機能：Adaptive Thinking（適応的思考）】
Claude 4.6系の最大の進化が「Adaptive Thinking」です。これは、簡単な質問には即答し、複雑なコーディングや論理パズルにはモデルが自律的にコンピュートリソースを割いて深く「熟考」してから回答を出す機能です。これにより、推論の精度が劇的に向上しています。
| モデル名 | 特徴とユースケース | 入力料金 (1,000トークン) | 出力料金 (1,000トークン) |
|---|---|---|---|
| Claude 4.5 Haiku | 【最速・最安】簡単なログ解析、分類、高速チャットに最適 | 約$0.001 | 約$0.005 |
| Claude 4.6 Sonnet | 【一番人気・高コスパ】高度なコーディング、RAG、Adaptive Thinkingを活用した複雑な推論の最適解 | 約$0.003 | 約$0.015 |
| Claude 4.6 Opus | 【最上位の推論力】1Mトークンの超長文処理、自律的なタスク遂行、極めて高度な論理的推論 | 約$0.005 | 約$0.025 |
コスト見積もりの具体例
「1日1,000件のエラーログ（1件あたり入力500トークン）を、Claude 4.5 Haikuを使って100トークンで要約させる」システムを作ったとします。
- 1日あたりの入力コスト: 500トークン × 1,000件 = 500,000トークン = 約$0.50
- 1日あたりの出力コスト: 100トークン × 1,000件 = 100,000トークン = 約$0.50
- 1日の合計: 約$1.00（150円前後）
用途に合ったモデルを選べば、高い性能を維持しながら1日わずか1ドル程度で強力なAIを既存システムに組み込むことができます。Lambdaのコスト計算と感覚はよく似ていますね。
5. 第2回のまとめと次回予告
今回は、Bedrockのコンソール画面でのプレイグラウンド体験と、推論パラメータ、そして最新のClaude 4.6モデル等を例にしたコストの見積もり方について解説しました。これで、BedrockのAPIを叩いてテキスト生成や画像生成を行う基本はマスターです。
しかし、実際の業務では「社内の社外秘マニュアルについて質問したい」「顧客データベースの最新情報に基づいた回答が欲しい」といったケースがほとんどです。AIは、学習していない最新の社内データを知りません。
そこで次回（第3回）は、 「自社データをAIに教える『RAG』とKnowledge Bases」 について解説します。モデルを再学習させることなく、S3に置いたPDFを検索して回答させる、今最もホットなアーキテクチャの全貌に迫ります。お楽しみに！