MRH Trowe、400人の従業員に統制されたセルフサービスAIエージェントへのアクセスを付与

ドイツのMRH Troweは、約400人の従業員向けに統制されたセルフサービスAIプラットフォームを本番稼働させ、AWSのインフラとオープンソースソフトウェアを活用して、金融サービスに求められるセキュリティとデータレジデンシーの要件に対応した。

商業・産業保険ブローカーである同社の最初の本番エージェントは、Microsoft Teamsの会議を構造化された議事録に変換する。従業員はドイツ語で、ある参加者を含む最近の会議を尋ねることができ、エージェントはカレンダーの予定を見つけ、文字起こしを取得し、参加者、議題、議論のトピック、フォローアップ項目を含む要約を作成する。

AWSはこの導入をMachine Learning Blogのケーススタディで紹介した。したがって、このアカウントはベンダー管理であり、導入状況、コスト、予測節約額の数値は、独立検証された市場データではなくAWSの報告として扱うべきである。それでも、この実装は、規制対象企業が汎用チャットから、社内システムに接続された一元管理のAIエージェントへ移行していく具体例を示している。

個別の実験から統制されたプラットフォームへ

AWSによると、MRH Troweは主にドイツ、スイス、オーストリアで事業を展開し、有機的な拡大と買収によって成長してきた。同社は、AWSを優先クラウドパートナーとして採用し、ドイツの保険ブローカーの中でもいち早くクラウドベースのITインフラのみで運用した企業の一つだった。

生成AIに対する従業員の需要が高まるにつれ、各チームが個別にツールの試行を始めた。AWSによると、これにより、断片化した導入や、機微な顧客・保険情報が露出する潜在的なリスクが生じた。同社は、各チームが独自の技術スタックを構築することなく、従業員がAIエージェントを作成し利用できるようにしたかった。

この要件は、従来のチャットインターフェースを超えるものだった。MRH Troweは、社内情報に基づいた応答、複数ステップの作業を実行できるエージェント、社内システムへの安全な接続、アクセスと支出の一元監視を必要としていた。同社の明示的な目標は、定型的な質問を人間が介入する前にAIが回答し、以前その作業を行っていた従業員が反復作業を自動化できるようにすることだ。

このプラットフォームは3つの要素で構成される。開発者は、エージェントのワークフローを作成するためのオープンソースSDKであるStrands Agentsを使用する。Amazon Bedrock AgentCoreは、エージェントの接続、運用、スケーリングのための本番環境を提供する。LibreChatは、認証、会話管理、ブランド設定、トークン予算、複数モデルのサポートを備えた従業員向けインターフェースを提供する。

ID、レジデンシー、インフラの制御

会議議事録のワークフローは、要求を行う従業員のIDを中心に設計されている。LibreChatはMicrosoft Entra IDを通じてユーザーを認証し、そのIDをサーバー側でエージェントに渡す。IDはチャットプロンプトで提供または変更できず、エージェントはそのユーザー自身のカレンダーと会議文字起こしへのアクセスに限定される。

AWSによれば、エージェント、モデル、データはAWS Europe (Frankfurt)リージョン、別名eu-central-1で稼働する。このリージョン配置は会議データと顧客データをドイツ国内に保つことを意図しているが、AWSはサービスとモデルの利用可否はリージョンによって異なると述べている。

この導入は、仮想プライベートクラウド内の単一AWSアカウントで実行される。従業員は、パブリックインターネット経由でトラフィックを送るのではなく、Transit Gatewayとゼロトラストプロバイダーを通じて社内ネットワークから接続する。内部Application Load Balancerが、プライベートサブネット内のアプリケーション層へリクエストを振り分ける。

AWSは、セッション分離がMRH TroweがAmazon Bedrock AgentCoreを選んだ重要な理由だと述べている。このサービスは、計算リソースとファイルシステムの両レベルでエージェントセッションを分離し、Strands Agentsのようなオープンソースフレームワークをサポートする。規制対象のブローカーにとって、この組み合わせは開発者の柔軟性を保ちながら、あるエージェントセッションが別のセッションのデータにアクセスできるリスクを下げることを意図している。

何が示され、何が示されていないか

AWSは、展開が本番稼働の最初の1か月で約400人の従業員に পৌঁ達したと報告している。また、その月の初期コストは1席あたり約14ドルで、適正サイズ化とスケジュールされたスケーリングにより、インフラコストを約40%削減できる見込みだとしている。

これらの数値は、導入の経済性を示す有用な指標ではあるが、独立したベンチマークではない。提供されたケーススタディでは、従業員ごとの利用状況、モデル消費量、エージェント実行回数、あるいは予測削減の正確な根拠について詳細な内訳は示されていない。また、400人の従業員全員が定期的にシステムを使っているのか、議事録エージェントが手作業と比べて精度、遅延、エラー率でどの程度かも明らかではない。

ただし、このケーススタディは、MRH Troweが採ったとする技術的設計判断を示している。つまり、プライベートなネットワーク経路、リージョン内処理、IDに紐づくリクエスト、トークン予算、複数モデルを支援するオープンなインターフェースである。また、最初の本番ユースケースが比較的限定的であることも示している。会議の取得と要約は、記録を変更したり、外部通信を送信したり、ビジネス上の意思決定を行ったりするワークフローに比べて、エージェントの権限を抑えつつ即時の価値を提供できる。

この導入がAIチームにとって重要な理由

開発者にとって、MRH Troweのアプローチは、IDとインフラをエージェント設計の一部として扱う重要性を示している。認証済みユーザーのコンテキストをインターフェースからエージェントへ渡すことでアクセス制御を明示的にし、セッション分離はマルチユーザー導入における別のリスク層に対応する。

このアーキテクチャはまた、実験と本番運用を分けている。開発者はStrands Agentsを使ってワークフローを構築でき、基盤インフラのすべてを自前で実装する必要はない。一方、AgentCoreは管理されたランタイムと従量課金型モデルを提供する。LibreChatは、ブローカーに商用チャット製品を唯一のインターフェースとして採用させることなく、なじみのあるフロントエンドを企業に提供する。

企業の買い手にとって、複数モデルの利用は単一モデルプロバイダーへの依存を減らし、チームが特定タスクに合わせてモデルを使い分けることを可能にする。トークン予算は基本的なコスト管理手段にはなるが、品質、遅延、データアクセス、エージェント障害の監視を置き換えるものではない。これらの運用上の課題は、エージェントが要約から保険システム全体でのアクションへ進むにつれて、より重要になる。

この導入はまた、規制環境におけるエンタープライズAIの実践的な進め方も示している。つまり、有用で、内部的に限定され、監査可能なワークフローから始め、ユーザーレベルの権限を徹底し、処理を承認済みリージョン内に維持し、部門ごとの未管理ツールではなく中央プラットフォームを通じてアクセスを拡大することだ。

今後注目すべき点

次の注目点は、MRH Troweが会議議事録を超えて、保険および顧客記録の取得や更新を行うワークフローに拡大するかどうかだ。そのようなユースケースは、エージェントが影響の大きい行動を取れる場合でも、プラットフォームのID制御とセッション分離が十分かどうかを試すことになる。

導入の質は、報告された従業員数と同じくらい重要だ。アクティブ利用、タスク完了率、人によるレビュー、エラー処理、節約された作業時間に関する追跡証拠があれば、初月のアクセス数だけよりもビジネス価値をより明確に示せる。

コスト報告も監視すべき分野だ。約40%の削減は適正サイズ化とスケジュールされたスケーリングに依存するため、最適化後の実支出は、利用が拡大しても従量課金型インフラが予測可能かどうかを買い手が判断する助けになる。モデル選択と地域別の利用可能性に関する詳細が増えれば、ワークロードや法域をまたいだアーキテクチャの移植性も明確になる。

Creati.aiの見解

MRH Troweの導入が注目に値するのは、単にチャットボットを従業員の前に置いたからではなく、セルフサービスAIを統制された内部プラットフォームとして扱っている点にある。従業員に紐づく権限、プライベート接続、リージョン処理、制御されたエージェント実行の組み合わせは、規制対象組織が実験から本番へ進む際に躊躇する複数の理由に対処している。

ただし、証拠はベンダーのケーススタディにとどまるため、導入とコストに関する主張は独立した検証が必要だ。それでも、この設計は金融サービスAIの短期的に妥当なパターンを示している。まずは範囲の狭い、監査可能なエージェントから始め、より広い自動化は、実証された信頼性、明確な認可境界、そして企業が測定できる運用コストに依存する、というものだ。