PoCで作成したAIシステムを本番運用へ～生成AIレンズで見えた「やるべきこと」～

平井周

はじめに

こんにちは。NRIの平井です。AWS・Azureの技術支援を担当しています。

ChatGPTやAmazon Bedrockの登場以降、「まずは試してみよう」と、チャットボットやRAG（Retrieval-Augmented Generation）システムを構築するケースが増えてきました。実際、私自身AWS上でAI環境を提案・導入支援を担当する機会が多くあります。

AWSからもAIに関するマネージドなサービスも多く出ており、AIそのものの知識やパブリッククラウドに詳しくなくてもPoCが進められるようになりました。しかし、PoCから本番運用への移行となると、何から検討すればよいか迷う場面もあるのではないでしょうか。「安定して動く本番システム」を実現するには、想像以上にハードルがあるのではと考えています。

セキュリティは大丈夫？
プロンプトインジェクション攻撃を受けたらどうなる？
エージェント利用により想定よりコスト高騰したらどうすればよいか？
回答精度を継続的に改善するにはどうしたらよいか？

私の所属するチームが提供するサービスQUMOAでも、RAGを用いたAIヘルプデスクサービスの運用において上記のような課題に直面しました。こうした課題に対応するために、AWSは2025年4月に「AWS Well-Architected Generative AI Lens」（以下、生成AIレンズ）というガイダンスフレームワークを展開しました。本記事では実際に生成AIレンズを活用して、PoCから本番運用に向けた取り組みをご紹介します。

AWSに関するソリューション・事例はこちら

生成AIレンズとは

AWSには、クラウド上でシステムを設計・運用する際のベストプラクティスを体系化したAWS Well-Architected Frameworkがあります。「運用上の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」「サステナビリティ」という6つの柱から構成されています。

このフレームワークには、特定のワークロードに特化した「レンズ」が用意されており、SaaSレンズなどさまざまな領域向けのベストプラクティスが提供されています。
生成AIレンズは、Amazon Bedrock、Amazon Q、Amazon SageMaker AIを使用した生成AIアプリケーション向けのベストプラクティス集です。

Generative AI Lens - AWS Well-Architected Framework.

生成AIには、従来のシステムにはない特有の考慮点があります。たとえば、ハルシネーション（もっともらしい嘘をつくこと）、プロンプトインジェクション（悪意ある入力による意図しない動作）、モデルの出力品質の評価方法などです。生成AIレンズでは、こうした生成AI特有の課題に対するベストプラクティスが、6つの柱それぞれに整理されています。

制御された自律性の設計
AIの動作範囲を明確に定義し、ガードレールで制御します。システムが「どこまで自律的に動けるか」の境界を設定することで、安全かつ効率的な運用を実現します。

包括的な可観測性の実装
システム全体を監視・測定し、問題を早期に発見します。ユーザーフィードバック、モデルの動作、コスト、セキュリティイベントなど、あらゆる観点から可視化することが重要です。

リソース効率の最適化
実際の要件に基づいて適切なモデルとリソースを選択します。過剰なスペックを避け、パフォーマンスとコストのバランスを最適化します。

分散レジリエンスの確立
障害に強いシステム設計で、継続的なサービス提供を実現します。冗長性と自動復旧の仕組みにより、一部の障害が全体に影響しない構成を目指します。

リソース管理の標準化
プロンプト、モデル、権限などを一元管理し、ガバナンスを効かせます。バージョン管理と集中カタログにより、変更の追跡と再現性を確保します。

安全な相互作用の境界
アクセス制御と入出力の検証でセキュリティを確保します。最小権限の原則と、プロンプトインジェクション対策などの入出力フィルタリングが鍵となります。

生成AIライフサイクル

生成AIレンズでは、AIシステムのライフサイクルを以下の6つのフェーズで定義しています。

PoCは「モデル選択」から「開発・統合」あたりまでをカバーしていることが多いですが、本番運用には「デプロイメント」と「継続的改善」の観点が欠かせません。生成AIレンズでは、これまで見落とされがちだったこれらの観点を体系的に洗い出すことができます。

実際のシステムに生成AIレンズを適用してみる

ここからは、実際に運用している「ヘルプデスク用AIサービス」を題材に、生成AIレンズを適用した取り組みをご紹介します。
以下のブログでもご紹介していますが、私のチームでは、「QUMOA」の利用者向けに、AIを活用したヘルプデスクサービスを提供しています。

atlaxblogs.nri.co.jp

当初はシンプルなRAG構成（WebSocket API + Lambda + Amazon Bedrock Knowledge Base）で運用していました。社内のサービス仕様書やFAQ、過去のQA応対履歴をナレッジベースに格納し、利用者からの質問に回答する仕組みです。
しかし、運用・改善を続ける中で課題も見えていましたので、ここでは生成AIレンズで推奨されているベストプラクティスを踏まえ、実施した改善内容をご紹介します。

MCPサーバによる外部知識の活用（パフォーマンス効率）

生成AIレンズの「GENPERF05: Improve data retrieval performance」では、外部知識ソースの効果的な活用が推奨されています。実際に、社内ドキュメントだけでは「AWSのこの機能の最新仕様は？」といった質問に対応できない課題がありました。
この課題に対し、AWS Knowledge MCPサーバやMicrosoft Learn MCPサーバとの連携を実装しました。これによりクラウドサービスの公式ドキュメントを動的に参照できるようになり、社内ドキュメントでカバーしきれない範囲を、公式の最新情報で補完できるようになっています。

Lambda → ECS Fargate へのコンテナ化によるスケーラビリティ向上

MCP統合を実現するにあたり、アーキテクチャの見直しを実施しました。当初のLambdaベースの構成では15分の実行時間制限があり、外部MCPサーバを呼び出しながら複雑な調査を行う可能性があるエージェント処理では、この制限に引っかかるリスクがありました。
生成AIレンズの「GENREL04: Handle throughput requirements」では、生成AIワークロードの特性に応じた適切なコンピューティングリソースの選択が推奨されています。この観点から、ECS Fargateへの移行を決定しました。
既存システムへの影響を最小化しつつ段階的に機能拡張できるよう、「ALB + Fargate」構成を採用して、既存のSimple RAG機能を保持しながら、新しいエージェント機能を独立して追加しました。実行時間の制限がなくなったことで、より複雑なエージェント処理にも対応できるようになりました。

SSEによるリアルタイム進捗表示（運用上の優秀性）

生成AIレンズの「GENOPS02: Observability in workloads」では、ユーザーに対する処理状況の可視化が推奨されています。MCPサーバを活用したエージェント処理は時間がかかることがあり、ユーザーが「動いているのか？」と不安になるケースがありました。
この課題に対し、Server-Sent Events（SSE）でエージェントの処理状況をリアルタイムに表示する機能を実装しました。「今、何を調べているのか」が可視化されることで、ユーザーの不安を解消し、体感の待ち時間を短縮できています。

今後実装したいこと

生成AIレンズによって見えてきた「まだできていないこと」も整理しており、ここではその一例をご紹介します。

運用上の優秀性：トレーサビリティの確保
現状、エージェントがどのツールを呼び出し、どのような思考プロセスで回答を生成したのかを詳細に追跡する仕組みがありません。生成AIレンズの「GENOPS03: Observability in workloads」では、生成AIシステム特有のメトリクス収集とトレーシングの重要性が述べられています。
そこで、Langfuseなどのエコシステムツールを導入し、MCPサーバのツール呼び出しを含む全工程をトレースできる仕組みを構築する予定です。問題が発生した際の原因究明が容易になるだけでなく、「どのツールが回答精度に貢献しているか」といった分析も可能になります。
セキュリティ：プロンプトインジェクション対策
生成AIシステムには、従来のWebアプリケーションとは異なるセキュリティリスクがあります。その代表例がプロンプトインジェクションです。悪意あるユーザーが巧妙なプロンプトを送信することで、システムに意図しない動作をさせたり、機密情報を引き出したりする攻撃です。生成AIレンズの「GENSEC02: Mitigate risks of harmful outputs」や「GENSEC04: Secure prompts」では、こうしたリスクへの対策が詳細に記載されています。
今後は、Amazon Bedrock Guardrailsを導入し、入出力のフィルタリングを強化することで特定のトピックへの応答拒否や、個人情報の出力ブロックなどをより堅牢に設定できます。
信頼性：クォータ管理
LLMの呼び出しには、APIのレート制限とコストの両面でリスクがあります。エージェントが想定以上にLLMを呼び出してしまった場合、サービス停止やコスト増大につながる可能性があります。生成AIレンズの「GENREL04: Handle throughput requirements」では、スループット要件の管理とクォータ制御の実装が推奨されています。
アプリケーションとしてのケアを想定しており、ユーザー単位のレート制限や、1リクエストあたりのLLM呼び出し回数の上限設定などの制御機構の実装が検討されます。
コスト最適化：コスト可視化と効率化
Amazon Bedrockの利用コストを詳細に把握する仕組みが未整備です。「どのエージェントがどれくらいコストを使っているか」「どのユーザーの利用が多いか」といった分析ができていません。生成AIレンズの「GENCOST02: Balance cost and performance of inference」や「GENCOST03: Engineer prompts for cost」では、推論コストの最適化とプロンプト効率化が推奨されています。
AWS Cost Explorerや先述したLangfuseなどを導入しつつ、プロンプトキャッシュの活用など、コスト効率化の施策を進めていきたいと考えています。

いかがでしたでしょうか。今回は一部のご紹介になりますが、生成AIレンズを活用することで、PoCと本番運用の間にある「やるべきこと」を体系的に整理できたかと思います。AIシステムはすべてを一度に実装する必要はなく、リスクの大きさと実装コストを踏まえて優先順位をつけ、段階的に取り組むことが現実的と考えています。

最後に

本記事では、AIシステムを本番運用できるようにするためのフレームワークとして、生成AIレンズを使用した方法をご紹介しました。生成AIを利用してPoCでシステムを作ったものの本番化に踏み切れない方、すでに本番運用しているが改善点が整理できていない方に本フレームワークはとても参考になると思います。
また、弊社も生成AIに関するご支援やレビューを通して自社だけでは気づきにくい観点からのフィードバックをさせていただくことも可能です。
本記事が、皆さまの生成AIシステムの本番運用に向けた一助となれば幸いです。