金融サービス向けAIエージェント構築の教訓

金融サービス向けAIエージェントの構築において、私は2年以上にわたって多くの経験を積んできました。この記事では、サンドボックスから監視に至るまで、体系的な教訓を共有します。

金融サービスの厳格さ

この分野ではミスは許されません。数字が全てです。誤った収益数値、ガイダンス声明の誤解、誤ったDCF仮定は、プロの投資家に100万ドル単位の誤った判断を下させる可能性があります。ユーザーは最も賢く、最も時間に追われる金融のプロフェッショナルであり、彼らは即座に誤りを見抜きます。このため、私はほぼ偏執的なまでに細部に注意を払うことを強いられています。すべての数字を再確認し、すべての仮定を検証し、すべてのモデルをストレステストする。間違いへの恐怖が、私たちの最大の武器となっています。

LLMの活用において、私たちは早期に大胆なインフラストラクチャの選択を行い、その多くが正しかったと確信しています。例えば、Claude Codeがファイルシステム優先のエージェントアプローチを発表したとき、私たちはすぐに採用しました。当時、業界全体（Fintool自身も含む）がベクターデータベースと埋め込みを用いた複雑なRAGパイプラインを構築していました。情報検索の将来について熟考した後、私は「RAGの死亡記事」を書き、Fintoolは完全にエージェント検索に移行し、貴重な埋め込みパイプラインを廃止しました。人々は私たちが非常識だと思いましたが、今では多くのスタートアップがこれらのベストプラクティスを採用しています。

サンドボックスは必須

2023年にFintoolを開始した当初、私はサンドボックスはやりすぎだと考えていました。「Pythonスクリプトを実行するだけだ」と自分に言い聞かせていました。結果は、すべてが間違っていました。LLMが初めてサーバー上でrm -rf /を実行しようとしたとき（「一時ファイルをクリーンアップする」ため）、私は真の信者になりました。

エージェントは多段階操作を実行する必要があります。プロの投資家がDCF評価を依頼するのは、単一のAPI呼び出しではありません。エージェントは企業を調査し、財務データを収集し、Excelでモデルを構築し、感応度分析を実行し、複雑なチャートを生成し、仮定を繰り返す必要があります。これは数十のステップであり、各ステップでファイルの変更、パッケージのインストール、スクリプトの実行が発生する可能性があります。コード実行なしでは実現不可能ですが、サーバー上で任意のコードを実行するのは無謀です。すべてのチャットアプリケーションにはサンドボックスが必要です。

現在、各ユーザーには独自の隔離環境が与えられています。エージェントはその中で自由に行動できます。すべてを削除しても、奇妙なパッケージをインストールしても構いません。アーキテクチャは3つのマウントポイントで構成されています：/private（読み書き、ユーザーの個人ファイル）、/shared（読み取り専用、組織ファイル）、/public（読み取り専用、全リソース）。鍵はクレデンシャルです。AWS ABAC（属性ベースのアクセス制御）を使用して、特定のS3プレフィックスにスコープされた短期クレデンシャルを生成し、ユーザーAは物理的にユーザーBのデータにアクセスできません。また、サンドボックスのプリウォーミングを実装しています。ユーザーが入力を開始すると、バックグラウンドでサンドボックスが起動し、エンターキーを押す頃には準備が整っています。

コンテキストが製品

エージェントの性能はアクセス可能なコンテキストに依存します。本当の作業はプロンプトエンジニアリングではなく、数十のソースからの混乱した金融データを、モデルが実際に使用できるクリーンで構造化されたコンテキストに変換することです。これにはエンジニアリングチームの深いドメイン知識が必要です。

金融データはあらゆる形式で提供されます：SEC提出書類（HTML、ネストされたテーブル）、決算説明会記録（話者分割テキスト）、プレスリリース、調査レポート（PDF）、市場データ（データベース）、ニュース、代替データ（衛星画像、ウェブトラフィック）、ブローカー調査、ファンド提出書類など。各ソースは異なるスキーマ、更新頻度、品質レベルを持ちます。エージェントが必要とするのはたった一つ：推論可能なクリーンなコンテキストです。

私たちはすべてを3つの形式に統一します：ナラティブコンテンツにはMarkdown、構造化データにはCSV/テーブル、検索可能性にはJSONメタデータ。チャンク戦略は重要です：10-Kファイルは規制構造（Item 1、1A、7、8...）ごとに、決算説明会は話者ターンごとに、プレスリリースは通常1チャンク、ニュース記事は段落ごとにチャンク化します。チャンク戦略がエージェントの取得コンテキストを決定します。悪いチャンクは悪い回答を生みます。テーブルは特別です。LLMはMarkdownテーブルでの推論が得意ですが、HTMLタグや生のCSVダンプでは苦手です。そのため正規化レイヤーがすべてのテーブルをクリーンなMarkdownテーブルに変換します。メタデータにより検索が可能になります。ユーザーが「Appleの前回決算説明会でサービス収益について何を言ったか？」と尋ねた場合、システムはティッカーを解決し、文書タイプをフィルタリングし、時間的フィルタリングを行い、セクションを特定する必要があります。これが、すべての文書にmeta.jsonが存在する理由です。構造化メタデータなしでは、検索は干し草の山の中でのキーワード検索に過ぎません。誰でもLLM APIを呼び出せますが、何十年分もの金融データを検索可能でチャンク化され、適切なメタデータを持つMarkdownに正規化できる人は多くありません。データレイヤーこそがエージェントを実際に機能させるものです。

解析の難問

金融データの正規化は作業の80％を占めます。SEC提出書類は敵対的です。機械読み取り用ではなく、法的コンプライアンス用に設計されています。テーブルは複数のページにわたり、ヘッダーが繰り返し現れ、脚注が他の脚注を参照し、数字がテキスト、テーブル、付属書類に（時には矛盾して）現れ、XBRLタグは誤っているか不完全で、フォーマットは提出者によって大きく異なります。既製のPDF/HTMLパーサーを試しましたが、委任状の多段階レイアウト、MD&Aセクションのネストされたテーブル、透かしやヘッダーがコンテンツに侵入する問題、スキャンされた付属書類、Unicode問題で失敗しました。

Fintoolの解析パイプラインは以下を含みます：生ファイル → 文書構造検出 → テーブル抽出（セル関係の保持） → エンティティ抽出（企業、人物、日付、金額） → 相互参照解決 → 会計期間正規化 → 品質スコアリング。テーブル抽出それ自体が価値ある話題です。金融テーブルは意味が詰まっています：マージされたヘッダーセル、脚注マーカー、負の数の括弧、混合単位、前期遡及修正。抽出されたすべてのテーブルをスコアリングします：セル境界の正確性、ヘッダー検出、数値解析、単位推論。信頼度90％未満のテーブルは確認のためフラグが立てられます。会計期間の正規化は重要です：「Q1 2024」は曖昧です。暦Q1（2024年1-3月）、Appleの会計Q1（2023年10-12月）、Microsoftの会計Q1（2023年7-9月）の可能性があります。10,000社以上の会計カレンダーデータベースを維持し、すべての日付参照を絶対日付範囲に正規化しています。これはユーザーには見えませんが、正確性には不可欠です。

スキルが全て

スキルが製品の中核です。Markdownベースのスキル（ReadFile、WriteFile、Bashツールによるファイルシステム操作）により、エージェントは複雑な金融ワークフローを実行できます。これらのスキルはモデルに依存しないように設計されており、モデルの改善に伴って進化します。私たちのアーキテクチャは将来を見据えています：現在のモデルは特定のタスクが得意でも、次世代モデルはさらに優れているでしょう。そのため、「モデル能力」ではなく「スキル」で製品を構築しています。

S3優先アーキテクチャ

ユーザーデータはデータベースではなくS3に保存されます。S3はファイルストレージにおいてデータベースよりもはるかに優れています：無限のスケーラビリティ、強い一貫性（新しいオブジェクトに対して）、強力なアクセス制御（ABAC）、サンドボックス環境とのシームレスな統合。各ユーザーの作業ディレクトリはS3プレフィックスに直接マッピングされ、ファイル操作をシンプルかつ安全にします。

Temporalとリアルタイムストリーミング

Temporalは長期実行タスクを管理します。ユーザーが複雑な分析（例：1000銘柄のスクリーニング）を開始すると、Temporalはタスクの確実な実行、一時停止、再開、キャンセルをサポートします。キャンセルはクリーンで、ゾンビプロセスを残しません。リアルタイムストリーミングはデルタ更新によって実現されます：エージェントは結果を段階的に生成し、ユーザーインターフェースは徐々に表示され、すべてが完了するのを待つ必要はありません。これによりスムーズなインタラクションが実現します。

評価と監視

評価はオプションではありません。ドメイン固有の評価フレームワークを構築しました：例えば、DCFモデルの計算が正しいか、テーブルデータが原文と一致するか、法的免責事項が誤って削除されていないかをチェックします。これらの評価はユーザーが発見する前にエラーを捕捉します。本番監視はログ、メトリクス、アラートシステムに依存しています。各ツール呼び出しのレイテンシ、成功/失敗率、ユーザーフィードバック（例：ユーザーがエージェントの出力を削除したかどうか）を追跡し、迅速な改善を可能にします。

まとめると、金融AIエージェントの構築は、データパイプライン、インフラストラクチャ、ユーザーエクスペリエンス、リスク評価を深く統合したシステムエンジニアリングです。これらの教訓が、多くの開発者の助けとなることを願っています。