近年、深刻な人手不足や顧客対応の高度化を背景に、チャットボットを導入する企業が増えています。特にAWSのチャットボットでは強固なセキュリティ基盤と最新の生成AIを柔軟に組み合わせられ、24時間対応のカスタマーサポートや業務自動化を低コストで実現できる有力な手段です。

本記事では、AWSでチャットボットを作成する代表的な構成パターンや、生成AIを活用した最新の導入フロー、費用の考え方をわかりやすく解説します。開発が必要な構成からノーコードで導入できるサービスまで整理しているため、自社の課題に合った最適な構成と導入手順、コストの目安を具体的に把握できます。

AWS環境にチャットボットの導入をご検討の際は、さまざまな業種業態のニーズに沿った多くの実績がある株式会社テクノプロへご相談ください。それぞれの目的に合ったAWS環境化における生成AIの構築・運用をご提案いたします。

AWSでチャットボットを作る代表的な2つの構成パターン

AWS環境にチャットボットを構築するには、大きく分けて対話型AIチャットボットと運用・通知向けチャットボットの構成パターンがあります。

対話型AIチャットボット	顧客対応や問い合わせ自動化で使用される
運用・通知向けチャットボット	AWSリソースの監視や運用通知で使用される

2つの構成を理解することで、自社の課題に適した導入形態を明確にできます。

対話型AIチャットボット ｜Amazon Lex・Amazon Bedrock

対話型AIチャットボットは、ユーザーの質問や入力に対して、会話形式で応答することを目的とした仕組みです。

AWSでは、この対話型チャットボットを構築するために、シナリオ制御に強いAmazon Lexと、生成AIによる柔軟な応答を実現するAmazon Bedrockという、役割の異なる2つのサービスが提供されています。

Amazon Lex

Amazon Lexは、自然言語理解（NLU）を用いてユーザーの意図を解析し、あらかじめ定義したシナリオに沿って応答する、AWS提供のチャットボットサービスです。

予約受付やFAQ対応などの定型業務を会話形式で自動化できます。

Lexの特徴は以下の通りです。

対話方式	シナリオ型で確実な対話制御が可能で、予約受付やFAQ対応などの定型業務を、あらかじめ定義したフローに沿って自動化できる
構築方法	GUIによるノーコード設計に対応しており、インテントやスロットを設定しながらビジュアルビルダーで直感的に会話フローを構築できる
応答の安定性	高い応答確実性を持ち、生成AIと比べて制御性が高く、意図しない回答が発生しにくい
AWS連携	AWSサービスとの高い統合性を備えており、LambdaやAmazon Connectと容易に連携でき、音声応答ではAmazon Pollyも利用できる
コスト体系	コストが予測しやすい料金体系で、トークン課金ではなくリクエスト数課金のため運用コストを見積もりやすい

Lexは、定型業務の自動化や確実な応答制御が求められるケースに優れたチャットボットです。ノーコードで実装できるため、開発リソースが限られた企業にも向いています。

Amazon Bedrock

Amazon Bedrockは、AWS上で複数の高性能な基盤モデル（Foundation Model）を利用できる生成AIプラットフォームです。

LexやAmazon Connectと組み合わせることで、生成AIによる柔軟な対話や知識活用を担い、チャットボットの「思考・回答生成」を担当します。

Bedrockの特徴は以下の通りです。

モデル選択	複数の基盤モデルを用途に応じて選択可能で、ClaudeやTitanなどを目的やコスト要件に合わせて使い分けられる
応答の柔軟性	高度な自然言語処理能力を持ち、曖昧な質問や文脈を含む長文入力にも柔軟に対応できる
ナレッジ活用	ナレッジベース連携（RAG）に対応しており、社内ドキュメントやFAQを参照した根拠ある回答を生成できる
拡張性	LexやAmazon Connectと組み合わせて利用できる高い拡張性を持ち、生成AIを組み込んだ高度な対話フローを構築できる
安全性	ガードレール機能による制御が可能で、不適切なコンテンツや特定トピックの出力を抑制できる

Bedrockは柔軟性と知識活用力に強みがあります。これにより、社内ナレッジを活用した高度な対話や、曖昧な質問への自然な応答を実現できます。

運用・通知向けチャットボット ｜Amazon Q Developer in chat applications

Amazon Q Developer in chat applications (旧：AWS Chatbot) は、AWSで発生したアラートや運用通知を、SlackやMicrosoft Teamsなどのビジネスチャットツールに連携するためのAWS提供サービスです。

セキュリティアラートやリソース異常、コスト超過などの通知をリアルタイムに受信でき、

チャット画面から状況把握や初動対応を行えます。

Amazon Q Developer in chat applicationsの特徴は次の通りです。

・CloudWatchやSecurity Hub、BudgetsなどのAWSサービスから通知を自動で取得できる ・SlackやTeamsのビジネスチャットにリアルタイムで通知を送信できる ・SlackやTeamsからAWS CLIコマンドを実行し、EC2インスタンスの再起動やLambda関数の呼び出しなどができる ・オンコール対応やインシデント管理の効率化を実現できる ・複数サービスの通知を一元管理できるため、情報の見落としを防げる

Amazon Q Developer in chat applicationsは監視から対応までをチャット上で完結できる運用効率化ツールとして、DevOpsや運用チームの生産性向上に役立ちます。

AWSチャットボットの作成フロー｜Lex × Bedrock × Connect

AWSで高度なチャットボットを作成するには、Amazon Lex・Amazon Bedrock・Amazon Connectの3つを組み合わせた構成が一般的です。

本章では、これらのサービスを連携させてチャットボットを作成するための具体的な手順を、役割分担から公開まで段階的に解説します。

手順1 | 役割分担と権限設定 (Connect・Lex・Bedrock)

手順1では、各サービスの役割を明確にして連携の基盤を整えます。

3つのサービスは次のように分担されています。

処理順	サービス	主な役割	具体的な機能
受信	Connect	接点 (フロントエンド)	・ユーザーがアクセスする窓口 (エントリーポイント)・電話 (音声) やWebチャットウィジェットで問い合わせを受け付ける・Lexへリクエストを転送する
理解	Lex	理解 (言語処理・対話制御)	・入力文を自然言語理解で解析・インテントに応じてフローを実行・シナリオ型制御とBedrock連携の両方に対応
生成	Bedrock	思考 (生成AI・知識応答)	・曖昧な質問にも柔軟に対応・ナレッジベースを参照して回答・文脈を考慮した自然な応答を生成

ユーザーの指示をConnectで受け取り、Lexで自然言語として理解したうえで、Bedrockが回答する流れを確立します。この仕組みを機能させるためには、サービス間の安全な連携設定が必要です。

サービス間の安全な連携は、IAM権限の設定・リージョンの統一・ネットワーク構成の3点を正しく設計することで実現します。
これらの設定は、前述した 「Connect → Lex → Bedrock」 の処理フローを実際に動作させるための前提条件 となります。

▼ サービス間連携を成立させるための基本設定

IAMロールの設定	・Amazon Connectにはサービスリンクロールが自動作成され、Lexボットへのアクセス権限が付与される・LexとBedrockの連携は、QnAIntentによるノーコード連携またはLambda経由の連携を選択できる・Lambdaを使用する場合、実行ロールに bedrock:InvokeModel などの権限が必要
リージョンの統一	・3サービスを同一リージョンに配置することで、レイテンシーを抑え、運用を簡素化できる・QnAIntent機能を使用する場合は、利用可能なリージョンの制限に注意が必要となる
ネットワーク設定	・Lex・Bedrock：PrivateLink (interface VPC endpoint) で各サービスのAPIへプライベート接続が可能・Connect：PrivateLinkに対応するエンドポイントは一部に限られるため、設計時には事前の確認が必要

これらの設定を行うことで、サービス間の認証と通信が正しく機能します。その結果、Connect・Lex・Bedrockが安全に連携します。

手順2 | Lexでの組み込みインテント設定とBedrock連携 (QnAIntent)

Lexには、生成AIを用いた対話を簡単に実現できる組み込みインテント「AMAZON.QnAIntent」が用意されています。これは、Lexボットが事前に定義したインテントに該当しないユーザー発話に対してBedrockナレッジベースを検索し、自然言語で回答を返す仕組みです。

QnAIntentを使うことで、LexとBedrockをノーコードで連携し、社内ナレッジを活用した生成AI応答を簡単に実装できます。ただし、現時点ではUS Englishのみの対応となっており、利用には制限があります。日本語で実現する場合は、Lambda経由でBedrockを呼び出す等の対応が必要です。

LexボットにQnAIntentを追加する

最初にLexへQnAIntentを追加します。

手順は次の通りです。

1.Lexコンソールにログインし、対象のボットを選択する 2.言語 (ロケール) を選択後、左側メニューの [インテント] を開く 3.インテントを追加して「組み込みインテントを使用」を選ぶ 4.リストから「AMAZON.QnAIntent」を選択して追加する

ここまでで、Lex側でQnAIntentが有効になります。ただし、スロット値を引き出す際の発話がインテントと一致しない場合は、このインテントではなくFallbackIntentが動作します。

QnAIntentの設定を行う

次は、追加したQnAIntentに次の設定を行います。

基盤モデルの選択	・Bedrockで利用するモデルを選択する ・利用可能なモデルはClaudeやTitanなどがあり、回答品質・応答速度・コストを考慮して選択する
Knowledge Storeの指定	・回答の根拠となるデータソースとして、Bedrockナレッジベース・Kendraインデックス・OpenSearch Service ドメインのいずれか1つを指定する

Knowledge Storeには、社内FAQやマニュアルデータをあらかじめ登録・インデックス化します。Bedrockはこの情報を基に関連性の高いドキュメントを検索し、回答生成に活用できます。

権限の確認と付与

QnAIntentを使用するには、以下のIAM権限が必要です。

・コンソールで設定を行う場合、ユーザーに bedrock:ListFoundationModels 権限を付与する ・LexボットのIAMロールに bedrock:InvokeModel 権限を付与する使用するKnowledge Storeに応じて、サービスごとに異なる権限体系を設定する 　- Kendraを利用する場合：kendra:Queryなど検索実行に必要な最小権限を付与する 　- OpenSearch Service domain を利用する場合：ドメイン側のアクセス制御ポリシーや認証方式に基づいて接続権限を設定する

IAM権限を適切に設定することで、LexとBedrockナレッジベースの連携が自動的に行われ、ノーコードでの生成AI応答が実現します。

手順3 | Bedrock ナレッジベースの設定と構築 (RAG)

Bedrockでは、社内ドキュメントやFAQをナレッジベースとして登録し、RAG（検索拡張生成）により根拠を示した回答を生成できます。

ナレッジベースの作成はAWSマネジメントコンソール上で完結し、コーディングは不要です。

手順は次の通りです。

1.Bedrockコンソールにアクセスし、[Knowledge bases] を開く 2.[Create knowledge base] をクリックする 3.ナレッジベース名と説明を入力し、IAMロールを選択する ・通常は「新しいサービスロールを作成して使用」を選択する ・ロールには、S3バケットへのアクセス権限 (s3:GetObject、s3:ListBucket) と基盤モデルへのアクセス権限 (bedrock:InvokeModel) が自動的に付与される 4.データソースを設定する ・データソースは Amazon S3 が推奨。FAQやマニュアル、仕様書などをアップロードしておく 5.埋め込みモデル (Embedding model) を選択する ・Titan Text Embeddings V2 (推奨) またはTitan Embeddings G1を選択する ・V2は多言語対応や精度が向上しており、ベクトルサイズ (256・512・1024) を用途に応じて選択できる 6.ナレッジベース作成後、データソースの同期を実行する ・作成されたナレッジベースのデータソース一覧からデータソースを選択する ・「同期」ボタンをクリックしてS3内の文書をベクトル化し、ナレッジベースに反映する 7.テストで精度を確認する ・[Test knowledge base] でサンプル質問を入力し、回答の品質を確認する

また、設定時は以下のポイントに注意します。

リージョンの一致	・S3バケットとBedrockナレッジベースは同一リージョンに配置する必要がある・Lex・Connectも同一リージョンに配置することでレイテンシーを最小化できる
モデルアクセス権限	・使用するモデルに対して bedrock:InvokeModel を必ず付与する
データ同期の実施	・S3のファイルを更新した場合は再同期を行い、最新情報を反映する・Lambda関数とEventBridgeを使用して同期を自動化することも可能
テストによる精度検証	・登録後は曖昧な質問や複数表現でテストし、回答精度を確認する

ナレッジベースの設定が完了すると、Lexがユーザーの質問を受け取り、Bedrockがナレッジベース内の文書を検索します。続いて、関連情報をもとに生成AIが自然言語の回答を作成し、Lexを経由してユーザーに返します。

この流れにより、AIが根拠を持って回答する仕組みが実現し、応答の信頼性が大幅に向上します。

手順4 | Amazon Connect の設定とチャットボットの公開

Amazon Connectは、AWSが提供するクラウド型コンタクトセンターサービスです。LexやBedrockと連携することで、チャットや音声による問い合わせ対応を自動化し、ユーザーが利用できる実運用チャネルとしてチャットボットを公開できます。

ここでは、LexとBedrockを組み込んだチャットボットを、Connect上に統合して公開するまでの手順を説明します。

Connectインスタンスの準備

まず、チャットボットを稼働させるためのConnectインスタンスを用意します。

1.Amazon Connect コンソールにアクセスし、[Create instance] をクリックする 2.アクセスURL・管理者アカウント・認証方法 (IAMまたはSAML) を設定する 3.作成後、[Overview] 画面から Contact flow (コンタクトフロー) を編集できる状態にする

既存のインスタンスがある場合は、このステップを省略できます。

Lexボットとの連携設定

ConnectにLexチャットボットを接続し、問い合わせフローで利用できるようにします。

1.Connectコンソールの左メニューから[Flows]を選択する 2.「Amazon ConnectでLex Bot Managementを有効にする」チェックボックスにチェックを入れ、[保存]をクリックする 3.ナビゲーションメニューに[Lex bots]が表示されるようになる 4.[Lex bots]メニューを開き、[ボットを追加]をクリックする 5.使用するLexボット (リージョン・ボット名・エイリアス) と言語ロケール (例 : en-US) を選択する 6.[保存]をクリックして登録する

登録後、Connectフロー内でLexボットを呼び出せるようになります。この時点で、Lexボット内部に組み込まれた QnAIntent (Bedrock連携)  がそのまま動作します。

チャット用コンタクトフローの作成

チャットボットとしての入出力処理を制御するため、コンタクトフローを作成します。

1.左メニューの[Flows]を選択し、[Create flow]をクリックする 2.フロー名を入力し、フロータイプを選択する (チャットと音声両方で使用する場合は「Contact flow」を選択) 3.[Create] をクリックしてフローエディタを開く 4.フローエディタで以下のブロックを配置する ・Entry point : 処理の起点 ・Get customer input : Lexボットを呼び出し、顧客入力を受け取るブロック ・Play prompt：応答内容を出力  (任意) 5.Get customer input ブロックの設定画面で、以下を指定する ・Lexボットを選択 (先ほど追加したLexボット名) ・使用するインテントを追加 (例 : 特定の業務インテントとAMAZON.QnAIntent) ・タイムアウト時間を設定 (デフォルト : 5秒、長めの会話の場合は300秒程度に調整) ・プロンプトテキストを入力 (例: 「どのようなご用件でしょうか？」) 6.保存後は、[Publish]をクリックしてフローを有効化する

この設定により、Connect上でLex＋Bedrock連携ボットが会話できるようになります。

チャットウィジェットの公開設定

最後に、ConnectチャットをWebサイト上に公開する設定を行います。

1.Connectコンソールの左メニューから [Channels] → [Chat widget] (またはコミュニケーションウィジェット) を開く 2.[Create communication widget] をクリック 3.ウィジェット名と説明を入力 4.[コミュニケーションのオプション] でチャットを選択し、使用するコンタクトフローを指定する ・必要に応じて「メッセージの受信を許可」にチェックを入れると、非同期メッセージングが可能になる ・設定後、[保存]をクリック 5.デザイン・言語・タイトルなどをカスタマイズ 6.ウェブサイトのドメインを許可リストに登録する (最大50個まで登録可能) 7.[コードスニペットを表示] をクリックしてHTMLコードを取得 8.自社サイトの任意のページ (例：問い合わせページ) にコードを貼り付け

この設定により、Webサイト訪問者が直接チャットボットに質問できるようになります。必要に応じて、Amazon Connect APIを利用し、独自UIやカスタムチャネル (Slackなど) に拡張することも可能です。

運用開始後、Bedrockのナレッジベースに登録したドキュメントを更新した場合は、「データソース」タブから「同期 (Sync) 」を実行して最新状態に反映させる必要があります。反映を行わないと、チャットボットが古い情報を参照して回答を生成する可能性があるため、注意が必要です。

Amazon Q Developer in chat applications (旧：AWS Chatbot) の活用例と使い方、導入フロー

ここまでは、LexやBedrockを用いた「対話型AIチャットボット」の構築について解説してきました。

本章では、AWSの監視・運用情報をSlackやTeamsに集約し、通知と初動対応を連動させるツールである Amazon Q Developer in chat applicationsの代表的な活用例と使い方、導入フローを説明します。

Slack / Teamsと連携した代表的な使い方

Amazon Q Developer in chat applicationsは、SlackやTeamsと連携することで、監視・対応・調査をチャット画面上に集約できます。

その活用方法は、以下のように「通知」「操作」「調査・自動化」の3つに大別されます。

代表的な使い方	内容	連携サービス・機能	得られる効果
アラート通知	監視アラートや異常をリアルタイムに受信	・CloudWatch・Security Hub・Budgets	障害や異常をいち早く検知できる
チャット操作	チャット画面からAWS操作を実行 (診断取得・EC2再起動・Lambda実行など)	Amazon Q Developer in chat applications (チャット画面からのコマンド操作)	初動対応・復旧作業の効率化
自然言語操作	自然言語で調査・操作を指示	他のサービスと連携したAmazon Q Developer in chat applications (チャット上の対話・操作インターフェース) ※	高度な調査・自動化を実現

※自然言語による高度な調査や自動操作は、Amazon Q Developer in chat applications単体の機能ではありません。別途、Bedrock AgentsやLambda等を用いてワークフローを設計・実装 (アプリ側実装) し、それらをチャットツールから呼び出すことで実現が可能です。
Amazon Q Developer in chat applicationsを別のサービスと組み合わせることで、運用における初動対応のスピードが向上し、作業効率が高まります。

Amazon Q Developer in chat applicationsの導入フロー

Amazon Q Developer in chat applicationsは、AWS管理コンソールを起点に各種設定を行います。設定により、SlackやTeamsと安全に連携し、アラート通知とチャット操作が可能です。ここでは一般的な導入手順を説明します。

手順1 | チャットツールとの連携設定

まず、Amazon Q Developer in chat applicationsとSlackまたはTeamsのワークスペースを紐づけます。

1.AWS管理コンソールでAmazon Q Developer in chat applicationsを開く 2.[Configure new client]を選択し、SlackまたはMicrosoft Teamsを指定する 3.対象のワークスペースへリダイレクトされるため、接続を許可する 4.投稿先のチャンネルを選択し、連携を完了させる

この設定により、Amazon Q Developer in chat applicationsが指定チャンネルへメッセージを送信できる状態になります。

手順2 | 通知集約用のSNSトピック作成

次に、各種アラートをまとめて受け取るためのSNSトピックを作成します。

1.Amazon SNSコンソールで新しいトピックを作成する 2.トピックの種類を「標準」に設定し、名称を付与する 3.作成したトピックをAmazon Q Developer in chat applicationsの通知先として登録する 4.CloudWatchアラームやSecurity Hubの通知先に同じSNSトピックを設定する

これにより、複数サービスの通知を1つの経路に集約できます。

手順3 | IAMロール設定とテスト確認

最後に、最小権限のIAMロールを設定し、動作確認を行います。

1.Amazon Q Developer in chat applications用のIAMロールを作成し、必要な読み取り権限のみ付与する 2.ロールをAmazon Q Developer in chat applicationsの設定に紐づける 3.CloudWatchアラームを一時的に発報させ、SlackやTeamsへ通知が届くことを確認する

これにより、実運用に耐える安全な連携が完了します。なお、SlackやTeamsからコマンド操作を許可する場合、EC2やLambdaなど操作対象サービスの権限もIAMロールに必要最小限で追加が必要です。

以上の設定により、AWSの監視通知と簡単な運用操作をSlackやTeams上で安全に行える環境が整います。

ノーコードで導入できるチャットボット｜Amazon Q Business

ここまでは、Amazon Lex や Amazon Bedrock などを組み合わせてチャットボットを「作る」構成 を解説してきました。

本章では、設計や開発を行わずに導入できる「作らない選択肢」 として、Amazon Q Businessを紹介します。

Amazon Q Businessの概要と向いているケース

Amazon Q Business は、企業が保有する膨大な社内データを安全に活用し、業務を支援する SaaS型のAIチャットボットサービス です。

プログラミングやサーバー構築を行うことなく、ノーコードで 社内専用のチャットボットを短期間で導入できます。

Amazon Q Businessの特徴は以下の通りです。

特徴	・SaaS型サービスで社内専用AIチャットボットを即時構築できる・サーバー構築や開発の必要はなく、コンソール設定のみで利用できる・社内文書を取り込み、検索・要約・回答を一体的に提供できる・IAM Identity Centerと連携し、利用者・部署単位にアクセス制御ができる・S3・SharePoint・Google Drive・Salesforceなど、幅広いサービスと連携できる
導入ケース	・開発コストを抑えてチャットボットを導入したい・社内FAQやマニュアル検索を自動化したい・膨大な既存資料をそのまま活用したい・部署ごとに閲覧権限を分けたい・短期間でチャットボットを全社展開したい

Amazon Q Businessを使うことで、開発工数を最小化しながら、安全に社内データを活用できます。とくに、精度の高い社内用AIチャットボットを短期間で構築したい企業に向いています。

Lex・BedrockとAmazon Q Businessのメリットと注意点を比較

Lex・BedrockとAmazon Q Businessは、どちらもAWS上でチャットボットを構築する手段です。ただし、設計思想と適用範囲が異なるため、用途に応じた選択が大切です。

それぞれの違いを、導入目的の観点から整理します。

項目名	Lex・Bedrock	Amazon Q Business
実装方式	開発＋設定が基本	ノーコードが基本
カスタマイズ	高度に可能	限定的
外部連携	自由度が高い	標準コネクタ中心
社内文書活用	RAG設計が必要	標準機能として提供
生成AIモデル	自由に選択	原則プリセット
業務ロジック	複雑な制御が可能	複雑な制御は不得意
導入スピード	中〜長期	短期
運用負担	やや高い	低い

LexとBedrockは自由度と拡張性が高く、Amazon Q Businessは導入スピードと運用の容易さに優れています。

LexとBedrockを組み合わせた構成は、対話フローや分岐条件・外部API連携・業務システムとの統合などを細かく設計できます。一方で、プロンプト調整やLambda実装・IAM設計・テストなどの開発工数が必要です。そのため、高度な自動化や独自ロジックを組み込みたい場合に向いています。

Amazon Q Businessはコンソール設定のみで社内データ活用環境を構築できます。S3やSaaSアプリケーションを接続するだけで検索・要約・質問応答が可能となり、運用負担が小さい点が強みです。一方で、基盤モデルの細かな選択や、複雑な対話分岐、業務ワークフローの高度な自動化には制限があります。

Lex・BedrockとAmazon Q Business選定基準は次のとおりです。

Lex・Bedrockの採用ケース	自由な対話フローや外部連携を設計したい
Amazon Q Businessの採用ケース	社内文書の検索・要約を中心に、短期間でAI活用を始めたい

それぞれの違いを理解することで、自社の目的に合ったアプローチを選択できます。

Amazon Q Businessの導入フロー

Amazon Q Businessは、コンソール操作だけで社内データを取り込み、検索・対話できる環境を短期間で構築できます。ここでは、一般的なAmazon Q Businessを導入する流れを紹介します。

手順1 : データソースの接続と同期設定

回答の元となる社内データを取り込むために、データソースの接続と同期の設定を行います。

1.Amazon Q Businessコンソールでアプリケーションを作成する 2.データソースとしてS3・SharePoint・Google Drive・Salesforceなどを選択して接続する 3.同期スケジュール (例 : 毎日1回・平日夜間など) を設定し、定期的に最新データを反映させる

これにより、社内ドキュメントが自動的に取り込まれ、検索対象として準備されます。

手順2 : インデックス作成と精度確認

取り込んだデータを検索可能にし、回答品質を確認するためにインデックス作成とテストを行います。

1.取り込んだデータから自動的に検索インデックスが作成される 2.コンソールのプレビュー画面でサンプル質問を入力する 3.回答の根拠文書・関連度・表現の妥当性を確認する 4.必要に応じて不要ファイルの除外やフォルダ整理を行い、再同期する

これにより、実運用前に検索性と回答精度を検証できます。

手順3 : Web対話画面の公開とアクセス制御

社内ユーザーが安全に利用できるよう、対話画面の公開と権限管理を設定します。

1.Amazon Q Businessの標準Webチャット画面を生成する 2.公開用URLを取得し、社内ポータルや業務サイトに掲載する 3.IAM Identity Centerと連携し、利用者や部署ごとにアクセス権限を設定する 4.不要な閲覧権限がないかロール設定を最終確認する

これにより、認証済みユーザーのみが社内AIアシスタントを利用できる体制が整います。

AWSチャットボットの料金体系

AWS環境でチャットボットを運用する際は、構成によって料金の考え方が大きく異なります。

利用するサービスごとに、従量課金モデル・サブスクリプションモデル・追加料金なしで使えるサービスが存在するため、事前に料金体系を理解しておくことが重要です。

ここでは、AWSにおける主要なチャットボット構成サービスの料金モデルをわかりやすく整理します。

リクエスト数・トークン単位の「完全従量課金」モデル (Lex・Bedrock)

LexとBedrockはどちらも利用量に応じて変動する完全従量課金モデルです。

項目名	Lex	Bedrock
課金単位	ユーザー発話 (リクエスト) 単位	処理したトークン量 (入力 ＋ 出力)
対象	テキスト発話・音声発話それぞれに単価が設定される	利用する基盤モデルごとに単価が異なる
初期費用	なし	なし
特徴	会話回数が増えるほどコストが増加する一方、閑散期は低コストに抑えられる	長文回答・高頻度利用・高性能モデルほどコストが上昇しやすい

Lexは会話回数、Bedrockはトークン量に応じてコストが発生するため、想定利用量を踏まえた事前見積りが重要です。

ユーザー単位の「サブスクリプション」モデル (Amazon Q Business)

Amazon Q Businessは、利用ユーザー数に応じた月額サブスクリプションを基本とする料金モデルです。利用量 (質問回数や回答トークン量) に比例して課金が増える仕組みではないため、運用コストを比較的予測しやすい点が特徴です。一方で、実運用では検索用インデックスの維持費用が別途発生する点に注意が必要です。

Amazon Q Businessでは、次のようなサブスクリプションプランが用意されています。

項目名	Amazon Q Business Lite	Amazon Q Business Pro
ユーザー料金	ユーザー1人あたり $3 / 月	ユーザー1人あたり $20 / 月
インデックス料金	別途発生 (Starter Index：$0.140 / 時間 / ユニット)	別途発生 (Enterprise Index：$0.264 / 時間 / ユニット)
内容	基本的な質問応答や許可付きの安全なレスポンス (約1ページ分まで) など社内データへのアクセスが可能	Liteの機能に加えて、より長い回答 (約7ページ分まで) 、アプリケーション作成機能など

Amazon Q Businessの総コストは、「ユーザー数に基づく月額料金 + インデックス維持費用」の合計で決まります。見積り時には想定ユーザー数と取り込むデータ量の両方を考慮することが大切です。

追加料金なしで利用できる「Amazon Q Developer in chat applications (旧：AWS Chatbot) 」と関連サービスのコスト

Amazon Q Developer in chat applicationsは、追加料金なしで利用できるサービスです。一方で連携するSNS・CloudWatchといった基盤サービスの利用分は課金対象となります。

具体的には、次のような関連サービスのコストが発生します。

Amazon SNS	通知を中継するトピックの送信回数に応じた従量課金
AWS Security Hub	有効化した場合の検出結果に応じた課金
CloudWatch	メトリクスの収集やアラーム設定、ログ保存に関する料金
Budgets	通知回数や使用状況データの処理に伴う関連コスト

Amazon Q Developer in chat applicationsは無料で使える運用のフロント機能です。ただし、実運用コストは連携先サービスの利用量に依存する点に注意が必要です。

AWSチャットボットは安全？導入前によくある不安と対策

企業がAWSチャットボットを導入する際、回答の信頼性やデータの安全性、運用の持続性などへの不安が生じることがあります。

本章では、よくある懸念点を整理し、AWSの標準機能を用いた現実的な対策を解説します。

生成AIは信用できる？ハルシネーションと回答品質の考え方

生成AIは高度な会話能力を持つ一方で、事実とは異なる回答を生成してしまうハルシネーション (誤回答) のリスクがあります。とくに社内ルールや専門的な業務情報を扱う場合、生成AIの回答をそのまま利用すると誤回答につながる可能性があります。

ハルシネーションの典型的な特徴は次のとおりです。

・一見自然だが事実と異なる説明をする ・出典が不明確な情報を断定的に提示する ・社内独自ルールや最新変更を反映できない

生成AIを業務で使う場合、出力をそのまま信じる前提ではなく、制御と検証の仕組みを組み込む設計が必要です。

ハルシネーションのリスクを低減するために有効なのがBedrock Guardrailsです。Bedrock Guardrailsは、チャットボットの出力をポリシーで制御する安全機能であり、企業のガバナンスに沿った回答を実現します。

Bedrock Guardrailsでは、企業のガバナンス要件に応じて次のような出力制御を行うことができます。

・有害・不適切コンテンツのブロック ・個人情報のマスキングや漏えい防止 ・機密情報の出力制限 ・特定トピックへの回答制御 (社内ルールに基づく制限)

これにより、答えてはいけない内容を体系的に遮断でき、リスクの高い発言を防止できます。

さらに、回答内容そのものの信頼性を高める手段として、RAGを活用する方法があります。RAGでは、Bedrockナレッジベースに登録した社内ドキュメントや公式マニュアルを優先的に参照しながら回答を生成します。
Guardrailsが「答えてはいけない内容を防ぐ仕組み」であるのに対し、RAGは「答える内容の根拠を正しく限定する仕組み」です。

RAGの効果は次のとおりです。

・回答の根拠を社内データに限定できる ・関連ドキュメントやページ番号を提示できる ・利用者が回答の妥当性を確認できる ・最新情報を反映しやすい (データ同期が前提)

この結果、推測に基づく回答ではなく、社内の公式情報を根拠とした業務利用に耐える回答を実現できます。

入力データはAIの学習に使われる？プライバシーとデータ保護の考え方

Bedrockでは、ユーザーが送信したプロンプトや生成結果が基盤モデルの再学習に利用されることはありません。Amazon Qでも顧客コンテンツが基盤モデルのトレーニングに使用されないポリシーが採用されています。
そのため、BedrockやAmazon Qを適切に設定して利用することで、企業は機密情報や個人情報の取り扱いに配慮しながら生成AIを活用できます。

生成AIのデータ利用ポリシーに加えて、チャットボットを業務で利用する場合はインフラレベルでのデータ保護設計も重要です。

AWSでは責任共有モデルに基づき、AWSが基盤インフラを保護し、利用企業がデータやアクセス制御を管理します。

主な保護の考え方は、通信・保存・アクセス・認証の観点から整理できます。

通信の暗号化	TLSによるデータ転送の保護
保存データの暗号化	KMSを用いたサーバーサイド暗号化
アクセス制御	IAMによる最小権限管理
ネットワーク分離	VPCやVPCエンドポイントによる隔離
認証強化	IAM Identity Centerや多要素認証の活用

これらを適切に設定することで、社内の機密情報や個人情報を安全に取り扱うことが可能になります。

さらに、データガバナンスを維持するためのログ記録と監査も必要です。AWSでは操作履歴やアクセス状況を可視化し、監査可能な形で管理できます。

主な仕組みは次のとおりです。

CloudTrail	誰がいつどのリソースにアクセスしたかを記録
CloudWatch Logs	アプリケーションやシステムのログを集約
AWS Config	リソース設定の変更履歴を追跡
監査証跡の保管	証跡を長期保存し、コンプライアンスに対応

これにより、不正アクセスの検知や内部統制の強化、監査対応が容易になります。

一度構築したら安心して使い続けられる？精度モニタリングと運用について

チャットボットは一度構築して終わりではなく、業務で使い続けるためには継続的なモニタリングと改善運用が欠かせません。

業務ルールや社内ドキュメントが変われば回答品質も変化するため、例えば以下のように運用プロセスをあらかじめ設計しておく必要があります。

継続的な回答精度の評価	・実際の問い合わせログから代表的な質問を抽出して目視確認する・想定Q&Aセットに対する回答の妥当性を定期的に測定する・無回答・誤回答・的外れ回答の頻度をモニタリングする・障害対応や法務関連の回答を重点に確認する
フィードバックを活用した改善	・チャット画面に「いいね／よくない」ボタンを設置する・低評価の回答を一覧化し、原因を分析する・誤りがナレッジ不足の場合はドキュメントを追加・修正する・フロー問題の場合はLexのインテントや分岐条件（対話シナリオ）を見直す・改善後に再テストし、精度の変化を確認する
業務ルールの変化に合わせた定期更新	・新しいマニュアルや仕様書はBedrockナレッジベースに追加し同期する・廃止ルールはデータソースから削除または修正する・Lexの対話シナリオは四半期ごとに棚卸しを行う・重大変更時はリリース前にテスト環境で検証する

継続的なモニタリングと改善には、「精度モニタリング → ユーザーフィードバック → ナレッジ更新」を循環させる運用モデルを確立することが大切です。

これにより、チャットボットを長期的に信頼できる業務ツールとして運用できるようになります。

まとめ

AWSのチャットボットは、用途に応じて「Lex + Bedrock」「Amazon Q Developer in chat applications」「Amazon Q Business」を使い分けることで、運用自動化・社内検索・通知対応を効率化できます。高度な対話制御が必要なら「Lex + Bedrock」・運用連携ならAmazon Q Developer in chat applications・社内文書活用を素早く始めたいならAmazon Q Businessが有効です。

AWSにおけるチャットボットの導入は、スモールスタートで効果を検証しながら進めることがポイントです。自社のビジネスを効率化する新たな一手として、Bedrockの活用をご検討してはいかがでしょうか。

AWSの生成AI導入なら、国内25,000人以上 (*1) の技術者を擁し、大手企業を中心に2,555社との取引実績 (*2) を持つ株式会社テクノプロにお任せください。最適な運用設計から監視・障害対応・コスト最適化まで、一括して任せることができます。
*1： 2024年6月末時点
*2： （株）テクノプロ及び（株）テクノプロ・コンストラクション 2024年6月末時点