0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS AI Practitioner超入門 #2: 生成AI・Bedrock

0
Posted at

はじめに

この記事は、前回の記事の続きです。

今回は、生成AIの基礎用語や活用方法、それらに対応するAWSサービスを取り上げます。

目次

想定読者

  • AI活用に興味がある非エンジニアの方(ビジネスアナリスト、プロダクトマネージャーなど)
  • AWS Certified AI Practitionerに興味はあるが、少しハードルが高いと感じている方
  • 生成AIやAWSの用語にまだ自信がない方

この記事のゴール

  • 生成AIの基礎用語と、対応するAWSサービスを知る
  • 参考書や問題集に取り組む前のハードルを下げる

生成AIの基礎用語

まずは、AIプラクティショナー試験に関係なく、生成AIの基礎となる用語を解説します。

基盤モデル
大量データで事前学習された、いろいろな用途の土台になるモデル全般を指します。
LLM(大規模言語モデル)もその1つで、GPT、Gemini、Claude、Amazon Novaなども基盤モデルです。

推論(inference)
モデルを実行して結果を得ることです。生成AIでは文章や画像の生成、機械学習モデルではデータの分類や予測など、とにかくモデルを実行し、結果を得ることを指します。

トークン/チャンク
トークン:生成AIがテキストを処理する際の基本単位です。単語や文字の一部などに分割されます。
チャンク:長い文書を、検索や処理がしやすい大きさに分割した単位です。トークン数、段落、見出しなどを基準に分割します。

埋め込み(Embedding)
自然言語や画像などの意味・特徴を、AIが理解しやすいベクトルデータ等に変換・表現することです。意味の近い文章を検索する際などに使われます。

マルチモーダルモデル
1つのモデルで、テキスト、画像、音声など複数種類のデータを扱えるモデルです。

以前のLLMは主にテキストを扱っていましたが、現在ではテキストと画像などを同時に入力できるモデルも一般的になっています。

たとえば、画像を渡して「この画像について説明して」と指示できるのは、マルチモーダルモデルだからです。

Amazon Bedrock

さまざまな基盤モデルをAWS上で利用できるマネージドサービスです。

  • 複数の企業が提供する基盤モデルから、用途に合ったモデルを選べる
  • モデルを動かすインフラを自分で構築せず、APIから利用できる

生成AIの応用・活用方法

モデルを賢く使う

推論パラメータ

モデルの推論時に使用する設定です。追加学習を行わずに、出力のランダム性や最大出力長などを調整できます。利用できる項目や値の範囲はモデルによって異なります。代表的なものは次のとおりです。

temperature(温度)

出力のランダム性を調整します。一般的に、値を高くすると多様で創造的な回答が生成されやすくなり、低くすると一貫性のある回答が生成されやすくなります。

ただし、値を低くしても、必ず毎回同じ回答になるとは限りません。

maxTokens(最大出力トークン数)

モデルが1回の応答で生成できるトークン数の上限を指定します。値を小さくすることで、長すぎる回答を防ぎ、レイテンシーや推論コストを抑えられる場合があります。

これは回答の長さを厳密に指定する設定ではなく、あくまで最大値です。回答が完了した場合は、上限に達する前に生成が終了します。

プロンプトエンジニアリング/コンテキストエンジニアリング

モデルに対して与える指示や質問を、プロンプトと呼びます。

プロンプトの内容や構成を工夫し、基盤モデルからより適切な出力を得るための手法を、プロンプトエンジニアリングといいます。

近年では、より広い概念としてコンテキストエンジニアリングという用語も使われています。

コンテキストエンジニアリングでは、プロンプトの書き方だけでなく、モデルに渡す情報全体を設計します。たとえば、次のような情報が対象になります。

  • 外部のドキュメントやWeb検索結果
  • RAGで取得した情報(RAGについては後述)
  • ユーザーとの対話履歴
  • ユーザーやセッションに関する情報
  • 利用可能なツールと、その実行結果
  • エージェントが保持するメモリ(エージェントについては後述)

つまり、プロンプトエンジニアリングが主に「どのように指示を書くか」を扱うのに対し、コンテキストエンジニアリングは「モデルに何を、いつ、どのような形で渡すか」まで扱います。

プロンプトエンジニアリングの代表的な手法には、次のようなものがあります。

Zero-shot Prompting

回答例を与えず、指示だけでタスクを実行させる方法です。

次の文章を、技術に詳しくない人にも分かるように要約してください。

Few-shot Prompting

モデルにいくつかの入力例と回答例を与え、期待する回答形式や判断基準を理解させる方法です。

入力: とても使いやすかった
評価: ポジティブ

入力: 操作方法が分かりにくい
評価: ネガティブ

入力: デザインはよいが、動作が遅い
評価:

Chain of Thought Prompting

問題をいくつかの手順に分けて、順番に考えさせる方法です。

次のレビューがポジティブかネガティブか判定してください。

「デザインは気に入りましたが、動作が遅くて使いにくいです。」

次の順番で考えてください。
1. 良い点を抜き出す
2. 悪い点を抜き出す
3. 全体としてポジティブかネガティブか判定する

単に「判定してください」と指示するよりも、考える手順を指定することで、複数の要素を整理した回答を得やすくなります。

Prompt Template

プロンプトの一部を変数として定義し、同じ形式のプロンプトを繰り返し利用する方法です。

あなたは{role}です。
次の文章を{audience}向けに要約してください。

文章:
{text}

プロンプトをテンプレートとして管理することで、アプリケーション内での再利用やバージョン管理がしやすくなります。

Amazon Bedrock Prompt Management

Amazon Bedrock Prompt Managementは、プロンプトを保存・再利用・バージョン管理するための機能です。

プロンプトテンプレートや使用するモデル、推論パラメータをまとめて管理でき、複数のプロンプトの出力を比較することもできます。

作成したプロンプトをアプリケーションから呼び出せるため、コードに直接埋め込むよりも管理や改善がしやすくなります。

RAG(Retrieval-Augmented Generation)

RAG(検索拡張生成)は、基盤モデルが持っていない外部の情報を検索して渡し、回答の品質を高める手法です。

モデルそのものを追加学習するのではなく、質問に関連するリファレンスをその都度渡し、必要な箇所を参照しながら回答させるイメージです。

たとえば、社内規程や製品マニュアル、専門的な業界知識などを参照させることで、それらの情報に基づいた回答ができるようになります。また、回答の根拠となる情報を与えることで、ハルシネーションを抑える効果も期待できます。

RAGの基本的な仕組み

  1. ユーザーが質問する
  2. 質問に関連する文書を検索する
  3. 検索結果とユーザーの質問をモデルに渡す
  4. モデルが検索結果を参考に回答する

これが最も基本的なRAGの流れで、ナイーブRAGと呼ばれることもあります。

より高度なRAGでは、検索前に質問を書き換えたり、検索結果を並べ替えたり、複数回検索したりすることで、回答の精度を高めます。このような手法は、まとめてAdvanced RAGと呼ばれることがあります。

AI Practitionerの範囲からはかなり発展的ですが、さらに深掘りしたい方には、次のサイトも参考になります。シンプルなナイーブRAG以外にも、さまざまなRAGの改善方法を学べます。

Amazon Bedrock Knowledge Bases(legacy)

Amazon Bedrock Knowledge Basesは、Amazon BedrockでRAGを構築するための機能です。(本記事では、Managed Knowledge Baseと区別するため、以前から提供されているAmazon Bedrock Knowledge Basesを便宜上「legacy」と表記します。)

これ単体ですべてを処理するというより、データソース、埋め込みモデル、ベクトルデータベースなど、RAGに必要な構成要素を連携させる役割を持ちます。検索結果から回答を生成する場合は、さらに基盤モデルを使用します。

主な登場人物は次のとおりです。

基盤モデル

検索によって取得した情報を参考に、最終的な回答を生成するモデルです。

Amazon NovaやAnthropic Claudeなど、Amazon Bedrockで利用できる基盤モデルを使用できます。

データソース

回答の根拠となる元データを保存する場所です。

社内規程、製品マニュアル、業務資料など、人間が読める形式の文書が格納されています。この時点では、まだ検索用のベクトルデータには変換されていません。

該当するAWSサービスの例:Amazon S3

埋め込みモデル

データソースにある文章などを、意味や特徴を表すベクトルデータに変換するモデルです。Embedding Modelとも呼ばれます。

該当するモデルの例:Amazon Titan Text Embeddings

ベクトルデータベース

埋め込みモデルによって変換されたベクトルデータを保存する場所です。

ユーザーから質問を受けると、質問もベクトルに変換し、意味の近い文書をベクトルデータベースから検索します。

文字列が完全に一致する文書を探すのではなく、意味の近さを使って検索できることが、ベクトル検索の特徴です。

該当するAWSサービスの例:Amazon OpenSearch Service

ざっくりとした仕組み

データソースに文書を保存しただけでは、すぐにRAGで検索できるわけではありません。

まず、文書を適切な大きさのチャンクに分割し、埋め込みモデルでベクトルデータに変換して、ベクトルデータベースに保存します。この一連の処理を、一般に同期(Sync)や取り込み処理と呼びます。

Amazon Bedrock Knowledge Basesは、こうした文書の取り込みや検索、基盤モデルとの連携をまとめて管理し、RAGを構築しやすくする機能です。

Amazon Bedrock Managed Knowledge Base

先述のAmazon Bedrock Knowledge Basesを、さらにマネージドにしたサービスです。

標準では、埋め込みモデルやベクトルデータベースを自分で用意する必要がなく、データソースを接続することで文書の取り込みや検索を始められます。

内部の構成は簡単になりますが、チャンク化、埋め込み、検索というRAGの基本的な考え方は同じです。

AIエージェント

AIエージェントは、生成AIがツールを使いながら、目的の達成に向けて処理を進める仕組みです。

通常の生成AIは、質問に対して文章を返すことが中心です。AIエージェントは、検索や予約などのツールを使い、その結果を見て次の行動を決めます。

ホテルを予約する場合は、次のように動きます。

  1. 希望条件を確認する
  2. 空室を検索する
  3. 候補を提示する
  4. ユーザーの確認後に予約する
  5. 予約結果を伝える

このように、判断、ツールの実行、結果の確認を繰り返す仕組みを、エージェントループと呼びます。

AIエージェントに決まった構成はありません。用途に応じて、ツール、RAG、メモリなどを組み合わせます。

エージェント関連の用語

ツール

ツールは、AIエージェントが外部の情報を取得したり、処理を実行したりするための機能です。

Webを検索する、データベースを参照する、メールを送る、ホテルを予約するといった機能がツールにあたります。

エージェントは、依頼の内容に応じて、どのツールを使うかを判断します。

MCP(Model Context Protocol)

MCPは、AIと外部のツールやデータを接続するための共通ルールです。

ツールそのものではなく、AIからツールを操作するためのリモコンのようなものです。より正確には、さまざまなツールを共通の方法で扱うための「リモコンの規格」に近いイメージです。

「Webを検索する」「ファイルを読む」といった個別の機能がツールで、それらをAIから使いやすくする接続方法がMCPです。

メモリ

メモリは、過去の会話やユーザーに関する情報を覚えておく仕組みです。

メモリには、大きく短期メモリと長期メモリがあります。

  • 短期メモリ:現在の会話の流れを覚えておく
  • 長期メモリ:会話をまたいで、ユーザーの好みや目標などを覚えておく

ChatGPTでたとえると、短期メモリは同じスレッド内の会話履歴、長期メモリは別のスレッドでも利用されるユーザー情報に近いイメージです。

エージェントシステムの構成

マルチエージェント

複数のエージェントが役割を分担し、協力して1つの目的を達成する構成です。

たとえば、情報を調査するエージェント、文章を作るエージェント、内容を確認するエージェントに役割を分けられます。

ワークフローオーケストレーション

ワークフローオーケストレーションは、あらかじめ決めた手順に沿って処理を進める仕組みです。

たとえば、申請、確認、承認、登録、通知という順番を事前に決めて実行します。

エージェントは状況に応じて次の行動を判断しますが、ワークフローは処理の順番や分岐をあらかじめ決めておく点が異なります。実際のシステムでは、ワークフローの一部にAIエージェントを組み込むこともあります。

AWSでエージェントを構築する選択肢

AWSでエージェントを作る方法はいくつかあります。ここでは、試験やAWSのドキュメントで目にしやすいものを紹介します。

Amazon Bedrock Agents Classic

AWSの設定画面 (マネジメントコンソール)を中心にエージェントを構築できます。

プロンプトやKnowledge Bases、外部APIなどを設定してエージェントを構築します。

2026年7月30日以降は新規顧客向けの提供が終了しており、現在はメンテナンスモードです。既存の利用者は引き続き利用できますが、これから構築する場合はAmazon Bedrock AgentCoreが主な選択肢になります。

Strands Agents

AIエージェントの処理をコードで実装するためのオープンソースSDKです。

Strands Agentsでは、モデルへの指示やツール、処理の流れなどをPythonやTypeScriptで記述します。
コードを書く必要はありますが、エージェントの動きを細かく調整したり、独自の処理を組み込んだりしやすいのが特徴です。

SDKという名前ですが、エージェント開発用のフレームワークに近いものと考えてもよいでしょう。作成したエージェントは、AgentCore Runtimeなどで動かせます。

Amazon Bedrock AgentCore

Amazon Bedrock AgentCoreは、AIエージェントの構築、実行、運用に必要な機能をまとめたAWSのマネージドプラットフォームです。

AgentCoreでエージェントを構築する方法は以下の2つです。

Managed harness

モデル、指示、ツールなどを設定すると、エージェントループをAgentCore側が実行してくれます。

自分でエージェントの処理を細かくプログラムしなくても、設定を中心に構築できます。Bedrock Agents Classicに近い使い方をしたい場合はこちらです。

Code-based agent

Strands AgentsやLangGraphなどのフレームワークを使い、エージェントの処理をコードで実装する方法です。

作成したエージェントは、AgentCore Runtimeにデプロイして動かします。

コードを書く必要はありますが、処理の流れを細かく調整したり、独自の処理を組み込んだりしやすい方法です。

AgentCoreには、このほかにも、会話やユーザー情報を記憶するMemory、ツールとの接続を管理するGateway、認証を管理するIdentity、動作や品質を確認するObservabilityやEvaluationsなどがあります。

位置づけの整理

サービス・ツール 役割
Amazon Bedrock Agents Classic 設定を中心にエージェントを構築する従来のサービス
AgentCore (Managed harness) 設定を中心にエージェントを構築する現在の選択肢
AgentCore(Code-based agent) エージェントをコードで実装し、Runtimeで動かす方法
Strands Agents エージェントの処理をコードで実装するSDK
AgentCore Runtime コードで作ったエージェントを実行する環境

たとえば、Strands Agentsでエージェントを実装し、Code-based agentとしてAgentCore Runtimeにデプロイできます。

Strands Agentsが「エージェントの中身を作るもの」、AgentCore Runtimeが「作ったエージェントを動かす場所」という関係です。

ガードレール

ガードレールは、生成AIへの入力や出力をチェックし、不適切な内容を制御する仕組みです。

たとえば、有害な内容、扱ってはいけない話題、個人情報、プロンプトインジェクションなどを検出できます。

Amazon Bedrock Guardrails

Amazon Bedrock Guardrailsは、使用する基盤モデルに関係なく、生成AIアプリケーションへ共通の安全対策を設定できる機能です。

生成AIの評価

生成AIにも、目的に応じたさまざまな評価方法があります。

人間にも学校の試験や適性検査があるように、生成AIも1つの点数だけですべての性能を評価することはできません。

モデルの評価指標

モデルが生成した文章を、正解や模範回答と比較して評価します。

代表的な評価指標には、次のようなものがあります。

  • ROUGE:主に文章の要約を評価する
  • BLEU:主に機械翻訳を評価する
  • BERTScore:文章同士の意味の近さを評価する

LLM-as-a-judge

LLM-as-a-judgeは、LLMが生成した回答を別のLLMに評価させる方法です。

正確さや分かりやすさなど、単純な文字列の比較では判断しにくい内容を評価できます。

Amazon Bedrockの評価機能

Amazon Bedrockでは、モデルとRAGを評価できます。

モデル評価

評価指標を使った自動評価や、LLM-as-a-judgeによる評価ができます。

RAG評価

RAGが適切な情報を検索できたか、その情報を使って適切に回答できたかを、LLM-as-a-judgeで評価します。

Amazon Bedrock AgentCore Evaluations

AgentCore Evaluationsは、AIエージェントを評価するための機能です。

回答だけでなく、目的を達成できたか、適切なツールを使ったかといった、エージェントの一連の動きを評価できます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?