【ITニュース解説】Building an Internal AI Assistant on AWS with Amazon Bedrock and Managed RAG

この記事は、企業が内部向けにAIアシスタントを構築するプロジェクトについて説明している。多くの企業で日々の業務にAIが活用され始めているが、単にAIモデルを使うだけでなく、実際の業務で役立つAIアシスタントを作るためには、さまざまな技術的な課題を解決する必要がある。このプロジェクトでは、AWSの複数のサービスを連携させ、セキュアで信頼性の高い内部AIアシスタントを構築した過程が詳細に述べられている。

まず、このAIアシスタントが解決しようとした問題は、社内の情報が散在しており、従業員が特定の情報を見つけるのに手間がかかるという点だった。例えば、ブランドガイドライン、過去のスクリプト、クライアント提案書などがバラバラに存在し、手動で検索するのが難しい状況だ。このプロジェクトの目的は、従業員がAIアシスタントに質問することで、社内の既存の知識から関連情報を迅速に取得し、業務に活用できるようにすることだった。

この目的を達成するために採用されたのが、「Retrieval Augmented Generation（RAG）」というアーキテクチャである。RAGは、AIモデルが持つ一般的な知識だけでなく、組織固有の文書から関連情報を「検索（Retrieval）」し、その情報に基づいてより正確で関連性の高い回答を「生成（Generation）」する技術だ。このプロジェクトでは、Amazon Bedrock Knowledge BasesがRAGの中心的な役割を担った。具体的には、社内の文書（ブランドガイドライン、スクリプトなど）をAmazon S3に保存し、それをAmazon Bedrock Knowledge Basesにデータソースとして接続した。これにより、従業員が質問すると、まずKnowledge BaseがS3から関連する文書の情報を探し出し、その情報をコンテキストとしてAmazon Bedrockの基盤モデルに渡して回答を生成させる仕組みである。

しかし、RAGの仕組みだけでは、実用的なAIアシスタントは完成しない。このプロジェクトでは、以下のさまざまな要素をシステムに組み込む必要があった。

一つ目は「認証」だ。内部向けのAIアシスタントであるため、許可された従業員のみがアクセスできるようにする必要がある。ここではAmazon Cognito User Poolsを使って、従業員のログイン管理と認証を行った。

二つ目は「安全なAPI通信」だ。ウェブブラウザからAIアシスタントのバックエンドへ安全に通信するために、Amazon API GatewayをAPI層として使用した。API Gatewayは、Cognitoから発行された認証トークン（JWT）を検証することで、有効な認証情報を持つリクエストのみをバックエンドに転送するように設定された。これにより、未認証のアクセスをAPIの段階でブロックできる。

三つ目は「アプリケーションロジックの連携」だ。ユーザーからのリクエストを受け取り、RAG処理やAIモデルの呼び出しといった一連のワークフローを調整する中心的な役割として、AWS LambdaのPython関数が使われた。Lambdaは、フロントエンドが直接AIモデルや社内文書にアクセスすることなく、すべてのバックエンド処理をオーケストレーションする。

四つ目は「AIモデルの入出力制御」だ。AIアシスタントの悪用を防ぎ、不適切な内容の入力をブロックしたり、AIが生成する不適切な内容の出力を制限したりするために、Amazon Bedrock Guardrailsが導入された。これにより、AIとのやり取りに安全性が確保される。

五つ目は「監視とトラブルシューティング」だ。複数のサービスが連携するシステムでは、どこで問題が発生しているかを特定するのが難しい場合がある。Amazon CloudWatchは、Lambda関数のログ記録やシステム全体の監視に利用され、問題発生時に詳細な実行経路やエラーメッセージを提供することで、迅速なデバッグを可能にした。

六つ目は「インフラの管理」だ。Cognito、API Gateway、Lambda、S3、Bedrock Knowledge Bases、Guardrailsといった多数のAWSサービスを手動で設定するのは、手間がかかる上に再現性が低い。そのため、Terraformという「Infrastructure as Code（IaC）」ツールが導入された。Terraformを使うことで、必要なAWSリソースの設定をコードとして記述し、自動的かつ一貫性のある方法でデプロイ・管理できるようになった。これにより、インフラの変更履歴を追跡しやすくなり、テスト環境と本番環境で同じ設定を容易に再現できる。

七つ目は「権限管理」だ。AWS Identity and Access Management（IAM）は、各AWSサービスやユーザーが必要最低限の権限のみを持つように設定するために使われた。例えば、フロントエンドはBedrockモデルを直接呼び出す権限を持たず、Lambda関数のみがRAGに必要なBedrockサービスやS3ドキュメントへのアクセス権を持つように設計された。これは「最小権限の原則」に基づき、セキュリティを高める重要な設計方針である。

このプロジェクトを通じて、開発者は単にAIモデルを動かすだけでなく、その周辺に認証、セキュリティ、データ管理、監視、インフラ管理といった多岐にわたるクラウドエンジニアリングの要素を統合することの重要性を学んだ。AIモデルはシステム全体の一部に過ぎず、実際に企業で利用されるAIアプリケーションを構築するには、これらの周辺システムがセキュアに、かつ堅牢に連携することが不可欠だということが示されている。最終的に構築されたAIアシスタントは、認証された従業員が社内の独自情報に基づいてAIと対話できる、実用的で安全なシステムであり、最終的な出力は人間のレビューを介するという設計になっている。これは、AIが生成した内容を自動的に公開せず、人間の責任を維持するという重要な考慮事項だ。この経験は、個々のAWSサービスを単体で学ぶだけでなく、それらを組み合わせて一つのシステムとして機能させるための実践的なスキルを習得する上で非常に価値のあるものだったと締めくくられている。