re:Invent 2025: Fidelity InvestmentsのText-to-SQLによるエンタープライズ規模データ分析基盤
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 -Fidelity Investments: Text-to-SQL for data analytics at enterprise scale-IND3323
この動画では、Fidelity Investmentsが実装したエンタープライズスケールのText-to-SQLソリューションが紹介されています。Manish WorlikarとRay Zhangが、ユーザー観察から始まり、データアクセスの民主化を目指した技術実装までを解説します。システムは3つの柱で構成されます。AI-ready dataでは一貫した命名規則と明示的なリレーションシップを定義し、セマンティックレイヤーではビジネス言語をデータベース用語に変換、ダイナミックワークフローでクエリリライトからSQL生成までを管理します。コンテキストエンジニアリングでは、質問固有のスキーマ、教育用の例、エンティティ検索を活用し、コンテキストウィンドウを90%圧縮しながら100%の関連性を維持します。Anthropic Claudeモデルを使用し、実行精度93-95%、結果セット比較89-92%、平均応答時間28秒を達成しています。決定論的なワークフロー、明確なスキーマ、外科的な教育例の使用が成功の鍵となりました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Fidelity Investmentsが直面したデータアクセスの課題とText-to-SQLソリューションの必要性
皆さん、AWS re:Invent 2025の4日目へようこそ。このライトニングトークでは、Fidelity Investmentsが自然言語を正確なクエリに変換し、実用的なインサイトを導き出すことができる、エンタープライズスケールのText-to-SQLソリューションをどのように実装したかをご紹介できることを大変嬉しく思います。ここに来られて興奮しています。それでは、Fidelity Investmentsチームをご紹介させていただきます。
ありがとうございます、Vikram。私の名前はManish Worlikarと申します。FidelityのビジネスユニットのひとつであるFidelity InstitutionalのAI Center of Excellenceを統括しています。Ray、自己紹介をお願いできますか？はい、皆さんおはようございます。私の名前はRay Zhangです。Text-to-SQLの実装をリードしています。
それでは本日は、ビジネス課題の特定と確認から、後ほどRay Zhangがカバーする実際の技術的な詳細まで、私たちの旅をご紹介します。 まず旅から始めましょう。私たちのアプローチはよりユーザー中心的なものです。私たちが行ったのは、ユーザーを観察し、彼らがデータとどのようにインタラクションしているかを見ることでした。彼らは複数のアプリケーションを使用していることがわかりました。CRM、ダッシュボード、Excelなどを考えてみてください。そしてデータをつなぎ合わせているのです。また、多くの場合、友人や他のチームメンバーに電話をかけて、データの理解を得ようとしています。
私たちが発見したのは、これはデータの問題や課題ではないということです。私たちが発見したのは、データへのアクセスこそがより大きな課題だということでした。また、私たちが直面しているこの問題は、ユニークなものでも孤立したものでもないことも理解しています。これは、データが散在し複雑な複数のエンタープライズに、より広く当てはまるものです。SQLは強力な言語ですが、問題は技術チームへの技術的な依存があるということです。一方で、ビジネスは非常に直感的なデータアクセスを必要としています。 迅速で、より速いデータドリブンなインサイトをです。
それでは、中央にあるこの図は、なぜこの課題が持続しているのかを理解するのに役立ちます。ご覧のように、下部にあるデータが、ユーザーに向かって移動していく様子を考えてみてください。データが複数のレイヤーを通過していくことを考えてください。レイヤーとは、データの準備、データの変換といったものを考えてください。そして最終的にUIチャネルを介してユーザーに提供されます。ダッシュボード、アプリケーションのUIなどを考えてください。データがレイヤーに沿ってユーザーに向かって移動するにつれて、より固定的で、より硬直的で、テンプレート化されていきます。しかし一方で、ユーザーの質問はスマートで柔軟なのです。
ここで少し立ち止まって、皆さんにお聞きしたいと思います。これは皆さんにとって聞き覚えがありますか？皆さんの企業でもこのような状況が見られますか？見られる方は手を挙げてください。ええ、確かに見られますね。そこで私たちが考えたのは、このようなやり方ではなく、ユーザーの質問を直接データに届けるということをしたらどうだろうか、ということです。そしてそれが、自然言語からSQLクエリへの変換機能へと繋がりました。私たちは、この機能を構築する必要があると考えたのです。
これが何に役立つかというと、私たちのアプローチ方法を完全に変えるものです。データへのアクセスを民主化します。また、SQLエキスパートへの依存を減らします。組織内の複数の人員が実際にこのデータアクセスを使えるようになることを想像してみてください。データからのインサイトという点で、組織の底上げが図れるのです。また、ビジネスは今や迅速にデータドリブンなインサイトを得て、情報に基づいた意思決定を行い、ビジネスインパクトを生み出すことができます。それでは、Ray Zhangに技術的な詳細についてお話しいただきます。
3つのインテリジェンスの柱：AI-ready data、セマンティックレイヤー、ダイナミックワークフロー
私からはText-to-SQLシステムの技術的な実装についてお話しします。私たちが構築したアーキテクチャについて詳しく説明します。私たちの実装は3つのインテリジェンスの柱に基づいています。1つ目はAI-ready dataです。AI-ready dataは基盤となるものです。これは、人間と大規模言語モデルの両方が理解できるようにデータを構造化する方法です。2つ目はセマンティックレイヤーです。セマンティックレイヤーは、ビジネス言語をデータベース用語に変換するトランスレーターです。そして最後がダイナミックワークフローで、これは自然言語でのユーザー入力から実行可能なクエリまでのプロセス全体を管理します。つまり、これら3つのコンポーネントがシームレスに連携することで、ユーザーは一行もコードを書くことなく必要なデータを取得できるのです。
それではデータとセマンティックレイヤーの基盤について見ていきましょう。データをAI-readyにするために、私たちは4つの原則に従っています。1つ目は一貫した命名規則を使用し、より強固なリレーションシップの基盤を使用することです。念のため、これはどういう意味でしょうか？すべてのテーブルにはアイデンティティが必要です。主キーを明示的に定義する必要があり、外部キーは暗黙的ではなく明示的である必要があります。これにより、LLMはリレーションシップを使用してデータ内を移動できるようになります。
2つ目の原則は単一の真実の情報源です。最後は自然な階層構造の活用です。例えば、投資家アカウントとホールディングスがあり、この設計を反映させれば、このデータはLLMによって即座に理解されます。ユーザーが「この投資家のポートフォリオの総額はいくらですか」といった質問をした場合、LLMは複雑な集計SQLを生成する代わりに、事前に集計されたデータを使用して投資家ホールディングテーブルと投資家プロファイルテーブルにクエリを向けるべきです。
これらのAI対応データ原則は、セマンティックファイルに直接フィードすることができます。私たちのセマンティックレイヤーでは、データが表現されており、この情報はセマンティックファイルで表現されています。ご覧のように、投資マネージャーの例を使うと、3つのテーブルがあります。資金情報、投資家プロファイル、そして投資家保有情報です。各テーブルには列のリストがあり、各列には属性のリストがあります。すべての情報が、LLMが理解するための追加のコンテキストを加えています。ビジネス記述があることがわかりますが、これは言語のギャップを埋めるものです。サンプル値により、モデルは実際のデータの形状を見ることができます。シノニムも同様に言語のギャップを埋めます。
これらのディメンショナル列については、個別値も持っています。なぜなら、フィルタを実行する際に、フィルタロジックを正しく実行できるように、値をそのまま保持したいからです。最後に、リレーションシップもエンコードしています。ここでは、投資家プロファイルと投資家保有情報という2つのテーブルが、1対多のリレーションシップを持っています。これにより、LLMがjoin句を正しく書くことができます。
さて、 これらのセマンティックファイルを手動で作成するのは、面倒な作業でエラーも起こりやすいです。そこで、実際にセマンティックファイルを自動化して生成するツールを構築しました。これは全体のワークフローを示すブロック図です。1つ指摘したいのは、最後のステップです。これは非常に重要で、ビジネス記述とシノニムの人間によるレビューが必要になります。これは反復的なプロセスです。生成されたSQLが正しくないことがわかった場合は、戻ってセマンティックファイルを微調整する必要があります。場合によっては、スキーマを更新する必要さえあるかもしれません。
自然言語クエリの処理プロセスとコンテキストエンジニアリングによる高精度SQL生成の実現
これで基礎ができました。自然言語クエリをどのように処理するかについて話す準備が整いました。最初のステップは、 クエリリライトを見ることです。ユーザーは常に完璧な質問をするわけではありません。クエリリライトは、曖昧なユーザーの意図と実行可能で正確なクエリとの間のギャップを埋めます。ユーザーの質問が入ってくると、クエリリライトは質問が明確かどうかを判断します。この質問に答えるためのデータはあるか？この質問に答えるためにデータのどの部分が必要か？これらの結果に基づいて、受け入れ、拒否、または明確化という3つの決定を行います。
例えば、投資プロファイルの例に基づいて、ユーザーが「次の四半期にどのファンドがアウトパフォームするか」のような質問をした場合、これらは予測的な質問です。私たちは過去のデータしか持っておらず、システムは応答して早期に停止すべきです。しかし、ユーザーが「最高のファンドは何か」という質問をした場合、これは質問に曖昧さがあります。システムは「AUMで言っているのか、それとも特定のアセットクラスで言っているのか」と応答します。
クエリリライトを使うことで、ユーザーは基礎となるカラム名を理解する必要がなくなります。自然に話すだけで、システムが翻訳してくれるんです。基本的には、ユーザーとシステムがより良くコミュニケーションできるように教えているわけです。では、質問が明確になったところで、ワークフローの中で最も複雑で重要な部分であるコンテキストエンジニアリングについてお話しします。
コンテキストエンジニアリングは、結果を出すAIと推測するだけのAIの違いを生み出します。私たちの実装では、ユーザーの質問は6つのセマンティックコンポーネントと組み合わされます。それには、システムプロンプト、質問固有のスキーマ、教育用の例、エンティティ値、出力フォーマット、つまりLLMにどのように応答してほしいかというレスポンス、そして使用するツールが含まれます。コンテキストアセンブリは、これらのコンポーネントを組み立てて正確なプロンプトを作成し、SQL生成に使用するだけです。
コンテキストエンジニアリングにおける重要な課題の一つは、コンテキストウィンドウのサイズ管理についてです。エンタープライズデータベースでは、数百のテーブル、数千のカラムがある場合があります。結果として得られるセマンティックファイルは簡単に100Kを超える可能性があります。この情報すべてをコンテキストウィンドウに注入することは不可能です。そこで実際のステップを行い、それらを圧縮されたフォーマットでLLMに送信し、これらの質問に答えるためにどのテーブルとカラムが必要かをLLMに教えてもらいます。そして、それ以外のすべてをフィルタリングします。これにより、次のようなペイロードが得られ、ペイロードの結果は90%小さくなりますが、100%関連性があります。
他に私たちが知っていることとして、LLMはin-context learningを通じて教育用の例から学習します。そこで、検証済みのSQLと質問-SQLペアのインメモリストアを用意しています。そして、ユーザーの質問が来るたびに、ユーザーの質問に基づいて最も類似した3つの質問を評価し、それをコンテキストに挿入します。LLMがこれを例として受け取ると、ベストプラクティスに沿ったSQLを生成できるはずです。そして、ユーザーとシステム間のすべてのインタラクションをキャプチャするための監視システムも配置しています。そして、LLMを使ってそれらのクエリを評価し、疑わしいものがないかを判断します。
そして、人間の専門家に定期的に問題がありそうな質問をレビューしてもらいます。実際にエラーがあれば、例を修正してストアに挿入します。ご覧のように、これは継続的な学習ループです。要するに、書いたすべてのクエリを覚え、犯したすべてのミスから学ぶSQL専門家がいるようなものです。時間とともに、彼らは知識を拡大していきます。つまり、将来のクエリが常に過去よりも賢くなることを保証する組織的なメモリを構築しているのです。
それでは、私たちが使用しているもう一つの重要なテクニックは、エンティティ検索です。なぜなら、ユーザーはショートカットや略語を使うことを好むからです。では、これをどのように活用するのでしょうか？先ほどディメンショナルカラムのところでお話ししましたが、私たちはすべての値、データベースの値をディスティンクトバリューに格納しようとしています。しかし、エンタープライズデータベースでは、多くのエンティティがあり、それぞれが何千もの値を持つ可能性があります。そこで私たちが行っているのは、追加のステップとして、これらすべてのエンティティ値をベクトルストアに入れて、セマンティックマッチを実行することです。上位にマッチしたものだけがコンテキストウィンドウに挿入されます。これで最終ステップに到達しました。
これでコンテキストの準備が整いました。これをLLMに送ってSQL生成を行います。私たちはいくつかのセキュリティガードレールを設けており、select構文のみを生成するようにしています。delete、insert、updateはありません。また、16ポイントの指示を用意しており、LLMにjoinの実行方法、where句の作成方法、その他のルールを伝えています。LLMからSQLが返ってきたら、構文チェックも実行します。構文にエラーがある場合でも、エラーメッセージを元の質問と一緒にLLMに送り、最大3回までリトライします。
ご覧のように、検証済みで構文的に正しいSQLのみがデータベースに到達します。 私たちのプロセスは健全ですが、一つ直感に反することを発見しましたので、皆さんと共有したいと思います。実は、サンプルが多いほどパフォーマンスが低下することがわかりました。当初は100以上のサンプルを含むサンプルセットから始めましたが、精度はそれほど良くありませんでした。わかったことは、これらのサンプルの多くが不要だったということです。言語モデルは、それらなしでも正しいSQLを生成することが完全に可能なのです。
そこで、サンプルを30個だけに絞り込みましたが、残ったサンプルはすべて存在する理由があります。特定のエッジケースに対処するか、ビジネスルールを教えるかのいずれかです。これは、ノイズが少なく、シグナルの高いガイダンスを持つようなものです。これらのサンプルは基本的にモデルに考え方を教えているのです。また、私たちは テストスイートの構築にかなりの時間を費やしました。これは品質ゲートを提供するため、同じくらい重要です。モデルのバージョンをアップグレードしたり、新しいデータソースを追加したりするたびに、リグレッションがないことを確認するために、このテストを繰り返す必要があります。これらは、モデルが機能することを証明するテストの例です。
それでは、現在のパフォーマンスがどのようになっているか見ていきましょう。 私たちはAnthropic Claudeモデルを使用しています。パフォーマンスは3つの次元で測定しています。1つ目は実行精度で、ターゲットSQLと生成されたSQLの間の行数を測定します。現在、93から95パーセントに達しています。結果セットの比較では、LLMジャッジを使用してターゲットと実行されたSQLの最初の500行を比較しており、約89から92パーセントです。平均応答時間は28秒です。応答時間は、ユーザーエクスペリエンスの測定だけでなく、トークンスペースとトークン使用量をどれだけ効率的に使用しているかも測定しています。
これがパフォーマンスが時間とともにどのように進化してきたかです。この数字は初日から得られたものではありません。継続的な改善を行い、モデルが学習を続け、知識を拡大し続けることで、現在の状態に到達しました。これで、私たちが学んだ教訓についてお話しします。私たちはさまざまなことを試してきましたので、皆さんはその必要がありません。私たちが効果的だと分かったのは、決定論的なワークフローを使用することです。これは予測可能なワークフローであり、初日からより信頼性が高く、本番環境に対応できます。また、明確なスキーマを使用することです。スキーマが構造化され、十分に文書化されていることを確認してください。これにより解釈エラーを防ぐことができます。
外科的な教育例を使用し、すべての例が理由を持って存在することを確認してください。量よりも質が重要です。また、コンテキストを最適化し、言語モデルに十分な情報だけを送信し、余分なものは送らないようにしてください。結論として、シンプルで適切に設計されたシステムは、派手で複雑なシステムを上回るということです。これで終わりに近づきました。皆さん、お時間とご注目をいただきありがとうございました。私たちは外にいますので、ご質問があればお気軽にお越しください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion