7月24日、AWSが「Building trade assistant: How Jefferies optimized front office trading operations with AI」と題した記事を公開した。この記事では、米投資銀行JefferiesがStrands AgentsとMCPを活用してフロントオフィスのトレーダー向けAIアシスタントを構築した事例について詳しく紹介されている。

Jefferiesとこの取り組みの背景

Jefferiesは米国に本拠を置くグローバル投資銀行で、投資銀行業務・株式・債券・資産運用など幅広い金融サービスを展開している。フロントオフィスのトレーダーが直面する問題は明確だ。数百万行に及ぶ取引データが複数のシステムに散在し、リアルタイムで意思決定するために必要な分析を、コーディングスキルのないトレーダー自身が行うのは困難である。

加えて金融業界特有の事情として、データアクセスには行レベルの権限管理が必要であり、個人情報（PII）の取り扱いや会話ログの保存といったコンプライアンス要件も同時に満たさなければならない。従来はデータ分析の専門家やIT部門に依頼してカスタムダッシュボードを作成してもらう必要があり、結果が出るまで数日から数週間かかることもあった。

Jefferiesが構築したトレードアシスタントは、この問題をAIエージェントで解決するアプローチをとっている。トレーダーが自然言語で「米国のセクター別取引状況を教えてくれ」と入力すると、裏側でLLMがSQL文を生成し、該当データソースに対してクエリを実行、結果を円グラフや棒グラフで即座に返す。

技術スタックの構成

アーキテクチャの核となるのは以下の3要素だ。

Strands Agents
Strands AgentsはLLMによる推論・ツール呼び出し・マルチステップ実行をシンプルなコードで実現するエージェントSDKである。元記事ではAWSブログ上で紹介されているが、strandsagents.comが独立したドメインを持つプロダクトであることからも分かるとおり、AWSと密接に関連しつつも独立したオープンソースプロジェクトとして公開されている。プロンプトとツール一覧を定義するだけでエージェントを構築でき、ローカルでテストしてそのままクラウドにデプロイできる。

Model Context Protocol（MCP）
AIエージェントが複数のデータソースやツールに統一インターフェースで接続するためのオープン標準。Jefferiesの実装では、各データソース（インメモリグリッド、SQLデータベース、FIXメッセージファイル）をそれぞれ独立したMCPツールとして公開している。エージェントはクエリ内容に応じて動的に適切なツールを選択する。

Amazon Bedrock + Knowledge Bases
LLMとしてAnthropic Claude Sonnetを使用。Amazon Bedrock Knowledge Basesにはテーブルスキーマやカラム定義、クエリパターンをRAG（Retrieval-Augmented Generation：検索拡張生成。LLMが回答生成前に外部ナレッジベースを検索し、精度を高める手法）で格納しており、エージェントがSQL生成前にスキーマ情報を参照することで精度を高めている。

金融規制・セキュリティへの対応

金融エンジニアにとって特に重要な点が、コンプライアンス要件への対応だ。元記事で言及されている「認証・アクセス制御・PIIフィルタリング」の実装は以下のように整理される。

行レベルのデータアクセス制御により、トレーダーが参照できるデータの範囲をロールに応じて絞り込んでいる。個人情報（PII）のフィルタリングと会話ログの記録にはAmazon Bedrock Guardrailsを活用しており、LLMとのやり取りが規制要件の範囲内に収まるよう制御している。なお、元記事で言及されているAmazon EKSはコンテナオーケストレーション基盤として使用されているものであり、認証サービスそのものではない点に注意が必要だ。

これらのセーフガードをアーキテクチャに内包した上で自然言語分析を実現している点が、単なる社内ツールにとどまらず金融機関のプロダクションシステムとして成立している根拠といえる。

実装から得た教訓

Jefferiesチームが明かした実装上の知見は、同種のシステムを構築するエンジニアにとって具体的な指針になる。

LLMにビジュアライズさせない
ハルシネーション（LLMが事実と異なる内容を自信を持って出力してしまう現象）リスクを下げるため、LLMはあくまで自然言語理解とSQL生成のみを担当させ、グラフ描画は専用のビジュアライゼーションエンジンに任せた。マークダウンUIライブラリを使ってレンダリングする構成にすることで、データの正確性を保っている。

インメモリDBで応答速度を確保
トレーダーはリアルタイムの意思決定を迫られる。通常のディスクベースDBではレイテンシが許容範囲を超えるため、インメモリデータグリッドにデータを置くことで即応性を実現した。

ユーザー行動は予測できないと前提を置く
実際にトレーダーが使い始めると、想定外の使われ方が続出した。オブザーバビリティ（可観測性）とフィードバックループへの投資が、この変化への追従に不可欠だったという。

言語戦略の使い分け
LLMとのインタラクションと実験的な処理はPythonで実装し、高スループットが求められるビジネスロジックと既存システムとの統合はJavaで実装した。

ビジネス上の成果と今後の展開

ローンチ以降、グローバルのセールス・トレーディング部門でIT依存の削減が報告されている。IT部門が繰り返し対応していたダッシュボード作成業務が大幅に削減され、技術チームがより戦略的な開発に時間を使えるようになったとある。ただし元記事において具体的な数値指標は示されておらず、成果の報告は定性的な記述にとどまっている。

今後のロードマップとして、複数のプロダクトタイプ・デスクへのグローバル展開、NLPを活用したコード生成によるオーディット機能強化、Amazon Bedrock AgentCoreの統合が計画されている。

詳細はBuilding trade assistant: How Jefferies optimized front office trading operations with AIを参照していただきたい。