Kepler が Claude で金融サービス向けの検証可能な AI を構築した方法
シリーズ How startups build with Claude では、スタートアップが AI で業界をどう変革しているかを紹介しています。この記事では、Kepler が金融サービスにおける AI のための信頼と検証のレイヤーをどのように構築したかを共有します。
| The quick pitch | |
|---|---|
| Name | Kepler |
| Founded | 2025 |
| Founders | Vinoo Ganesh (CEO) と John McRaven (CTO) |
| Stack | AWS、Rust、Python、オーケストレーション用コンテナ |
| Growth | 3か月足らずで、SEC 提出書類 2,600 万件以上、公開文書 5,000 万件以上、非公開文書 100 万件以上、世界 27 市場の 14,000 社以上をインデックス化。 |
金融機関は規制の厳しい環境で事業を行っており、レポーティングは監査可能で説明責任を果たせるものでなければなりません。規制当局への提出書類、ディールのピッチ資料、リサーチレポートに含まれるすべての数値は、ソース文書に対して検証可能である必要があります。
金融業界が従来から頼ってきたツールはデータを引き出すことはできますが、その検証プロセスにはアナリストが必要です。アナリティクスシステムは自由形式の質問を解釈したり、ステップに分解したり、ある単一の指標を求めるには特定の会計期間にわたって 3 つの異なる項目を引き出す必要があると判断したりすることはできません。AI システムはその解釈を行うことができますが、計算と同じステップで処理してしまうため、出力される数値はモデル自身が生成したものになり、間違いが起こり得ます。
Vinoo Ganesh と John McRaven は、Palantir で長年にわたり防衛、エネルギー、金融機関向けのデータシステムを構築してきました。その経験は、回答が検証可能でなければならない環境における信頼の捉え方を形作りました。Kepler を創業する前、二人はプライベートエクイティ、ヘッジファンド、投資銀行を含む 147 社の金融機関と対話し、ほぼすべての企業から同じ声を聞きました。誰もが AI をリサーチに使いたがっているが、その出力を信頼している人はいない、ということです。あるマネージングディレクターは「監査できないものを、どうやって信頼しろというんだ?」と語りました。
二人の答えは、AI のための信頼と検証のレイヤーとして機能する決定論的なインフラを構築することでした。そのインフラと、推論および解釈レイヤーとしての Claude を組み合わせて動かしているのが Kepler Finance です。これは金融サービス向けのリサーチプラットフォームで、アナリストが平易な英語で質問を投げ、即座に検証可能な回答を受け取るために使われています。
長い複数ステップのタスクを扱い、曖昧さをフラグする
金融分析には複雑で多段階の計算、密度の高いデータ、多義的な用語が伴い、誤りが許されません。それを踏まえ、Kepler には長い計画を逸脱なく保持し、曖昧さをフラグできるモデルが必要でした。
例えば、アナリストがある企業の直近 8 四半期の在庫日数 (inventory days outstanding) を尋ねた場合、モデルはその回答に何が必要かを把握する必要があります。すなわち、正しい計算式、正しい会計期間、そして数値に影響する可能性のあるリステートメント (修正再表示) です。
チームはすべてのフロンティアモデルでベンチマークを行いました。シンプルなクエリではどのモデルも同程度の性能を示しましたが、相互依存関係を含む長い多段階の計画になると、Claude を除くすべてのモデルが 4〜5 ステップ目あたりからショートカットを取るか、制約を見失い始めることが分かりました。「私たちのワークロードでは、Claude が一貫して計画を保ち続けることのできた唯一のモデルでした」と Ganesh は語ります。「他のモデルは強くスタートしたものの、5 ステップ目には黙って制約を 1 つ落としていきました。」
最も明確な違いは、各モデルが不確実性をどう扱い、どのように人間をループに残すかでした。例えば、ある用語に 2 つの異なる意味があり得る状況で、ほとんどのモデルは一方の意味を選んで進めました。Claude は立ち止まり、アナリストに判断を求めました。「その振る舞いは、どのベンチマークスコアよりも重要です」と Ganesh は語ります。「金融分析の早い段階で 1 つでも誤った前提を置くと、その後すべてが壊れてしまうのです。」
Claude を取り巻くコンテキストをエンジニアリングする
Kepler チームは、Claude が、構造化されたドメイン知識、定義、解決すべきものとエスカレートすべきものを切り分ける明確な境界によって強化された、精密に定義されたタスクを与えられたときに、より良い結果を生み出すことを発見しました。「金融では、モデルがシステム全体になることはできません。私たちはモデルをパイプラインの 1 ステージとして扱い、そのステージで成功するために必要なものを正確に手渡すのが役割だと考えています」と McRaven は語ります。「プロンプトエンジニアリングは 1 回の呼び出しを最適化しますが、コンテンツエンジニアリングはその周囲のシステムを最適化するのです。」
チームは、比率の計算や会計期間の解決のように、証明可能に正しくなければならないあらゆる操作について、Claude が呼び出せる決定論的な実行環境を構築しました。金融概念を厳密な定義と計算式にマッピングする独自オントロジーも開発し、ユースケースごとにカスタマイズ可能にしています。セキュリティとアクセス制御の制約はすべてのステップで強制され、各ユーザーがどのデータソースから取得できるかが制御されます。その上に、複雑な資本構成にまたがる企業価値計算 (例えば優先株、転換社債、少数株主持分の扱い) や、報告期間変更にまたがるセグメント収益のウォーターフォール調整など、パイプラインで最も一般的なワークフロー向けに、再利用可能でカスタマイズ可能なスキルを構築しました。これらのスキルは決定論的ステージと非決定論的ステージの間を調整し、設計上べき等です。同じ入力に対しては常に同じ出力が返ります。
次に、彼らはワークフローを多段パイプラインに分解し、それぞれのステージに異なる Claude モデルを割り当てました。意図の分解、曖昧さの解消、構造化された実行プランの生成といった複雑な推論には Opus 4.7 を、タスクがより制約されたスループット重視のステージには Sonnet 4.6 を用います。さらに、リコール用に独自の特化モデルも訓練しており (一部は Claude を基盤とし、一部は Kepler の独自モデル)、財務諸表のラベルを標準化された分類コードにマッピングするタスクで 94% の精度を達成しました。これは他のモデルが達成した 38〜46% の精度を上回るものです。
チームはすべてのプロンプト変更、モデルアップグレード、コンテキストの修正を、本番投入前に数千件のケースに対してテストしています。Claude の出力を既知の正解と各ステージで比較する自動評価パイプラインを構築し、構造化されたプランと最終的な計算結果の両方をチェックします。テストが失敗したときには、問題が Claude の推論にあったのか、提供されたコンテキストにあったのか、下流の実行にあったのかを追跡できます。Anthropic が新しいモデルバージョンをリリースすると、Kepler は数時間以内にベンチマークを行い、どのステージが改善し、どこが後退し、どこにプロンプト調整が必要かを正確に把握します。
Claude とともにスケールする
Kepler Finance は、世界 27 市場にまたがる 14,000 社以上について、SEC 提出書類 2,600 万件以上、公開文書 5,000 万件以上、非公開文書 100 万件以上をインデックス化しました。Claude はこの規模の非構造化データを使えるものに変え、コーパス全体に対して質問を解釈し、企業や時期によって異なる用語の差異を調整します。Kepler のリトリーバルレイヤーがその後、検証済みの SEC 提出書類から数値を取り出し、計算結果を組み立て、デスクの Excel テンプレートに集約します。アナリストはワンクリックで、各数値をソース文書の中で該当箇所がハイライトされた正確な項目までさかのぼって追跡できます。
Claude の推論と Kepler の決定論的インフラの分離により、小さなチームでもこの規模で構築できます。Claude は、本来であれば多数のドメイン特化型 NLP エンジニアを必要とする解釈レイヤーを担い、Kepler のインフラがそれ以外を担当します。大規模チームが数か月かけてリリースするような新機能を、Kepler は数週間で構築できます。アーキテクチャがモジュール化されているため、パイプラインのほかの部分に手を入れることなく、あるステージの推論だけを改善できるからです。
金融機関はエンゲージ前にコンプライアンスインフラを必須としているため、Kepler は当初からフルの監査ロギング、サイロ化された顧客環境、エンドツーエンドのプロビナンス (来歴) を構築しており、SOC 2 Type II 認証を取得済みで、ISO 27001 認証も進行中です。
Kepler のプラットフォームは設計上ドメイン非依存です。チームが意図的に金融から始めたのは、それが密度の高いデータ、多義的な用語、複雑な計算、誤りの許容度ゼロといった、AI にとって最も厳しい環境の 1 つだからです。その精査に耐えるために構築されたアーキテクチャは、専門家が大規模な文書コレクションから検証可能な回答を必要とするあらゆる場面に応用できます。臨床試験データを治療プロトコルと照合する医療プロバイダーから、数十年にわたる判例を横断して先例を追跡する法務チームまで、パターンは同じです。Claude が質問について推論し、インフラが回答を保証します。
「Kepler Finance は私たちの最初のプロダクトです」と Ganesh は語ります。「最後にはなりません。」
| Kepler チームのベストプラクティス | |
|---|---|
| Claude に正しい仕事を与える | リトリーバルはクエリエンジンの仕事。計算は計算式エンジンの仕事。Claude には解釈、分解、推論を求めましょう。 |
| ステージにモデルを合わせる | 複雑な推論には Opus、制約された高スループットのタスクには Sonnet を使う。すべてを 1 つのモデルで動かすと、品質かコストのいずれかをテーブルに置き去りにすることになります。 |
| プロンプトより先に評価に投資する | Claude の出力を、既知の正解に対して各ステージでテストする自動パイプラインを構築しましょう。各ステージを独立にテストし、パイプライン全体をエンドツーエンドでもテストします。金融では、サイレントなリグレッションが顧客を永久に失う原因になります。 |
| 初日からプロビナンスを前提に構築する | 専門家はあらゆることを検証するように訓練されています。プロビナンスは後付けではなく、システム全体を形作るものでなければなりません。 |
Claude Platform の上にあなたのスタートアップを築こう。