8,900万ドルのバグ:AppleとGoldman Sachsが金融AIで見誤ったもの

昨年10月のある火曜日の夜、私は自宅のオフィスに座っていました。そのとき、CFPBのプレスリリースがフィードに流れてきたのです。AppleとGoldman Sachsが、Apple Cardの異議申し立て対応における構造的な不備を理由に、8,900万ドル超の支払いを命じられたのです。私は同意命令を二度読みました。そして三度目を読みました。目にしているものが信じられなかったからです。

根本的な失敗は、風変わりな金融工学が暴走した類のものではありませんでした。差別的な与信判断を下す暴走アルゴリズムでもありませんでした。原因は、一つのボタンでした。Apple Walletアプリの二次フォーム——消費者がこれを未完了のまま放置すると、請求に関する異議申し立てはデジタルの虚空へと消えてしまったのです。数万人もの人々が不正な請求を報告しましたが、システムはただ…それを飲み込みました。調査もなし。受領の通知もなし。解決もなし。消費者は請求書を抱えたまま取り残されました。

私は生業としてAIシステムを構築しています。私の会社Veriprajnaが注力しているのは、私たちが「ディープAI」と呼ぶもの——大規模言語モデルの柔軟性と形式検証の数学的な厳密さを組み合わせた、ニューロシンボリックなアーキテクチャです。あの同意命令を読んだとき、私は溜飲を下げたりはしませんでした。気分が悪くなったのです。Apple Cardで起きたことは、すべて防げたことだったからです。より良いテストによってではありません。より多くのエンジニアによってでもありません。規制産業向けのAIシステムをどう構築すべきかについて、根本的に異なる考え方によって、です。

Apple Cardの異議申し立てに、実際には何が起きたのか?

この失敗を順を追って説明させてください。見出しの数字よりも、細部のほうがずっと重要だからです。

AppleとGoldman Sachsが提携契約を結んだのは2017年でした。Appleは消費者体験——洗練されたWalletのインターフェース、メッセージングの仕組み、フロントエンドのすべて——を担う。Goldman Sachsは幕の裏側の銀行として、与信を行い、取引を処理し、問題が起きたときには異議申し立てを調査する。

2020年6月、Appleは「問題を報告(Report an Issue)」のワークフローに更新を加えました。更新前は、不審な取引をタップして「Report an Issue」を押せば、Goldman SachsとのMessagesベースのチャットに転送されました。単純明快です。更新後、Appleは二次フォームを追加しました。最初のメッセージを送ったあとに消費者が完了することになっていた、追加のステップです。

破綻したのはここです。Messages経由で異議を申し立てたものの二次フォームを完了しなかった場合、システムはその異議申し立てを未完了として扱いました。苦情はGoldman Sachsに一度も送信されなかったのです。規制の観点から見れば、これらのメッセージの多くは、貸付真実法(Truth in Lending Act)上の有効な請求エラー通知(Billing Error Notice)に該当していました。法的には、定められた期限内に調査が開始されるべきものでした。ところが、それらは消えてしまったのです。

法的に有効な数万件の消費者の異議申し立てが、誰一人として形式的に検証していないステートマシンに飲み込まれたのです。

私はその一節を読みながら、自社のシステムは「実戦で鍛えられている」と語る金融サービスの経営幹部たちとの会話をすべて思い出していました。何に対して鍛えられているのでしょうか。UIの変更が分散ワークフローにデッドステートを持ち込む、というあの特定のシナリオに対して?それは、ユニットテストとQAスプリントで捕まえられる類のものではありません。

すべてを壊した2,500万ドルの条項

同意命令のなかに埋もれた、私が何度も立ち返ってしまう一節があります。AppleとGoldman Sachsの契約には、Apple CardのローンチについてGoldmanが90日遅延させるごとに2,500万ドルの予定損害賠償額を支払うという条項が含まれていたのです。

2,500万ドル。四半期ごとに。遅れたことに対して。

商業的な圧力がエンジニアリングの判断を歪める場に、私は何度も居合わせてきました。準備ができていないと分かっていながら出荷するチームを見てきました。遅延のコストのほうが、失敗のコストよりも具体的に感じられるからです。しかし、インセンティブ構造がここまで明示的に書き下されているのを見たことはありません。Goldman Sachsは、慎重であることに対して、あらかじめ罰金を科されていたようなものです。

Apple Cardは2019年8月20日に稼働しました。Goldmanの内部チームは、システムの準備状況について懸念を提起していました。WalletアプリとGoldmanのバックエンドのあいだのメッセージキューは、テストが不十分でした。同期プロトコルは脆弱でした。しかし計算は単純です。いま出荷して後で直すか、2,500万ドルを払って先に直すか。

彼らは出荷しました。そして1年以上にわたり、外からは誰にも見えない穴を抱えたまま、システムは走り続けたのです。

なぜVeriprajnaがデプロイ前の形式検証にこだわるのかと尋ねられるとき、私はこのことを考えます。「それでは遅くなりませんか?」と彼らは言います。「本番環境で監視して、問題を捕まえればいいのでは?」もちろん、できます。ブレーキなしで運転して、障害物を避けながら進む計画を立てることもできます。うまくいくうちは、うまくいくのです。そして金融サービスでうまくいかなくなったとき、傷つくのは生身の人間です。

なぜ誰もこれに気づかなかったのか?

これこそ、私を悩ませ続けている問いです。地球上で最も技術的に洗練された企業のうちの二社——伝説的なエンジニアリング文化を持つAppleと、定量分析力を持つGoldman Sachs——が、何千件もの異議申し立てがブラックホールに落ちていることに、どちらも気づかなかった?

答えは、アーキテクチャにあると私は考えています。このシステムはリレーとして設計されていました。Appleがフロントエンドを扱い、Goldmanがバックエンドを扱い、メッセージが両者を行き来します。しかし、誰も所有していない場所がありました。二つのシステムのはざまです。異議申し立てが状態A(「メッセージ送信済み」)に入りながら状態B(「フォーム完了」)に決して到達しなかったとき、何が起きるべきなのか——その形式的なモデルを、誰も持っていませんでした。よく設計されたステートマシンであれば、それは明示的に考慮すべき遷移です。Apple Cardのシステムでは、それは誰も仕様化しなかった空白であり、だからこそ誰も監視していなかったのです。

1年ほど前、私は深夜まで仕事をしていました。チームとともにクライアント向けのコンプライアンス・ワークフローを構築していたのですが、エンジニアの一人、プリヤが似たような問題を指摘したのです。彼女は文書レビュー・プロセスの状態遷移をモデル化していて、サードパーティのAPIがタイムアウトした場合に、提出物が「エンリッチメント待ち」の状態に無期限に留まってしまう経路を見つけました。それはコードのバグではありませんでした。コードは指示されたとおりに正確に動いていたのです。バグがあったのは設計でした——仕様が想定していなかった状態です。

私たちがそれを捕捉できたのは、形式検証ツールを使っているからです。具体的には、ワークフローをステートマシンとしてモデル化し、考えうるすべての経路を網羅的に検査するSMTソルバーにかけます。ソルバーはプリヤのデッドステートを数秒で見つけました。Apple Cardのシステムでは、そのデッドステートが本番環境で何か月も走り続けたのです。

Apple Cardの失敗は、コードのバグではありませんでした。コードは指示されたとおりに正確に動いていました。バグがあったのは設計です——誰も仕様化しなかった状態、だからこそ誰も監視しなかった状態です。

GPTを使えば済む話ではないのか?

この質問は絶えず受けます。あるピッチミーティングでは、投資家がほぼそのままの言葉で私に言いました。「TILAの規制でGPT-4をファインチューニングして、異議申し立てを処理させればいいのでは?」

私は一呼吸置いて、こう尋ね返しました。「GPT-4が消費者に『あなたの異議申し立ては解決しました』と告げたのに、実際には銀行に一度も送信されていなかったとしたら、責任は誰が負うのですか?」

彼は答えを持っていませんでした。他の誰も持っていません。なぜならこの問いは、規制産業におけるAIについて私が「メガプロンプト」型と呼ぶアプローチの、根本的な問題を露呈させるからです。大規模言語モデルを用意し、関連する規制をコンテキストウィンドウに詰め込んで、すべてを正しく処理してくれることを祈る。ガバナンス層はなし。形式検証もなし。システムの出力が法に整合しているという数学的な保証もなし。

Apple Cardのケースでは、失敗は分散ステートマシンにおける論理エラーでした。LLMのラッパーではこれを直せなかったでしょう——むしろ悪化させたかもしれません。実際には異議申し立てがAppleのサーバーから一歩も出ていないのに、LLMが自信満々に「あなたの異議申し立ては送信され、調査中です」と消費者に告げる場面を想像してみてください。これは仮定の話ではありません。金融の文脈におけるハルシネーションとはこういうものであり、それは恐ろしいことです。

銀行業におけるAIについて、人気の金融解説サイトや広く共有されているコンテンツは、ほぼ例外なくこの区別を見落としています。彼らはAIがコンプライアンスを「自動化」すると語り、あたかも難所は規制を読むことであるかのように扱います。難しいのは読むことではありません。難しいのは、証明することです。まだ思いついてもいないものを含め、考えうるあらゆるシナリオにおいて、自分のシステムが規制に従っていることを証明しなければならないのです。

Apple・Goldmanの失敗が具体的にどの規制違反とアーキテクチャ上の欠落に対応するのかをより深く見たい方のために、私はインタラクティブな分析を執筆しました。同意命令を詳細にたどっています。

「証明可能に正しい」とは実際に何を意味するのか

Veriprajnaが「証明可能に正しい」コンプライアンス・システムを構築していると言うとき、私は「入念にテストされている」という意味で言っているのではありません。数学的に証明されている、という意味です。両者には違いがあり、その違いは決定的に重要です。

テストは特定のシナリオを検査します。「ユーザーが異議を申し立ててフォームを完了したら、それがGoldman Sachsに届くことを検証する」というテストを書きます。そのテストは通ります。結構です。しかし、ユーザーが異議を申し立てながらフォームを完了しないというシナリオは、テストしていません。あるいは、フォームを完了したのにネットワークがパケットを取りこぼす場合。あるいは、二つの異議申し立てが同時に到着し、一方が他方を上書きしてしまう場合。

形式検証はシナリオを検査しません。検査するのはプロパティです。プロパティ——「申し立てられたすべての異議申し立ては、最終的に調査状態に到達しなければならない」——を定義すると、数学的なソルバーが、システムの考えうるすべての実行においてそのプロパティが成り立つことを網羅的に証明します。あらゆる経路。あらゆるエッジケース。あらゆる競合状態。反例が一つでも存在すれば、ソルバーはそれを見つけ出し、システムがどのように失敗しうるのかを正確に示してくれます。

私たちはImandraのようなツールを使っています。これによって、コンプライアンス・ロジックの実質的なデジタルツインを構築できます。ツインは本番システムと並走し、本番コードが検証済みモデルから逸脱する動作——たとえばUIのステップが未完了だからという理由で異議申し立てを破棄する、といった動作——を試みれば、システムはそれをリアルタイムで捕捉します。

これこそ、消費者が一人も影響を受ける前にApple Cardのバグを捕捉できたはずのアプローチです。設計段階で、SMTソルバーは「CompletedFormB」変数がTILA上の必須項目ではないことを即座に特定したはずです。送信ロジックはそれを要求していましたが、法は要求していませんでした。この不一致は証明可能な欠陥であり、デプロイ前に指摘されていたはずなのです。

私たちが実際に構築しているアーキテクチャ

「ディープAI」のコンプライアンス・システムが実際にどのようなものかを、具体的に語りたいと思います。「AI搭載コンプライアンス」といった曖昧な主張こそが、問題の一部だからです。

Veriprajnaはマルチエージェント・アーキテクチャを採用しています。一つの巨大なAIがすべてをこなそうとするのではなく、役割と境界が定義された専門エージェントを配置します。一人の天才を雇うというより、全員に明確な職務があり、その仕事を監督者が確認するチームを編成するイメージです。

インテーク・エージェントは、雑然とした人間的な部分——自然言語で書かれた異議申し立ての解析——を担当します。誰かが「シアトルでこんなコーヒーを買った覚えはない。その日はロンドンにいた」と書いたとき、エージェントは主要なエンティティを抽出します。取引、加盟店、日付、主張の性質。ここはLLMが真に力を発揮する領域です。

しかしその次が——私がこれまで見てきたラッパー型のアプローチすべてと袂を分かつのがここです——抽出された情報が渡される先は、記号的ポリシーエンジンです。このエンジンは予測も推測もしません。連邦法を一階述語論理でエンコードしたものに照らして、異議申し立てを評価します。このメッセージは、TILA上の有効な請求エラー通知(Billing Error Notice)を構成するのに十分な情報を含んでいるか。エンジンは推定しません。証明します。

ワークフロー・エージェントは処理の順序を強制します。検証エージェントはリアルタイムの数学的チェックを走らせます。監査エージェントは、私たちが「グラスボックス」と呼ぶ仕組みのなかで、すべてのやり取りを記録します——規制当局に対する完全な透明性です。

そして決定的に重要なのが、センチネル・エージェントです。これは、Apple Cardのシステムを殺したのとまさに同じ種類のデッドステートを監視します。異議申し立てが「申し立て済み、ただし未送信」の状態に定められた閾値を超えて留まっていれば、センチネルは人間が気づくのを待ちません。既存の情報だけで先に進むのに十分かどうかを自律的に判断し、それをパッケージ化して、検証済みのチャネル経由で送信します。

絶対的コンプライアンスのために作られたシステムでは、異議申し立てが有効かどうかを決めるのは法であって、UIではありません。消費者が身に覚えのない請求についてあなたに伝えたのなら、フォームが完了していないことはあなたの問題であって、消費者の問題ではありません。

タイミングがパフォーマンス指標ではなく法的要件である理由

これには、ほとんどの技術的な議論が完全に見落としているもう一つの次元があります。金融コンプライアンスにおいて、時間は法である。Regulation Zは、異議申し立てを調査しなければならないと言っているだけではありません。特定の期間内にその受領を通知し、60日以内に解決しなければならないと定めています。Goldman Sachsが制裁を受けた一因は、こうした期限内に受領通知を送れなかったことにあります。

私のチームは何か月もかけて、シンボリック・レイテンシ解析と呼ぶ手法を開発しました。分散システムが最悪ケースの条件下でも規制上の期限内に処理を完了することを、数学的に証明する方法です。平均的な条件ではありません。「95パーセンタイル」でもありません。最悪ケースです。

従来のモニタリングが教えてくれるのは、あなたのシステムが遅かったかどうかです。シンボリック・レイテンシが教えてくれるのは、あなたのシステムが遅くなりうるかどうかです。UIコードの変更によって最悪ケースの処理時間が60日の規制期限を超えるなら、そのデプロイは自動的に拒否されます。事後に判明するのではありません。出荷する前に分かるのです。

この水準の厳密さが本当に必要なのかをめぐって、社内で交わした議論を覚えています。私のエンジニアの一人——大手クラウドプロバイダーで長年を過ごした非常に優秀な人物——が強く反対しました。「起きないかもしれないシナリオのために、デプロイのサイクルに何週間も足している」と彼は言いました。私はApple Cardの同意命令を指し示しました。「起きたんだ」と私は言いました。「Appleに。Goldman Sachsに。そして、何一つ悪いことをしていない数万人の消費者に。」

そのあと、彼はもう反論しませんでした。

レイテンシ上限のためのPerformal方法論を含む、私たちの形式検証アプローチの完全な技術的解説については、私たちの研究論文をご覧ください。

「でも、それでは構築に時間がかかりすぎる」

この点については、いつも反論されます。その理由も分かります。Apple Cardは数か月でローンチしました。形式的に検証されたコンプライアンス・アーキテクチャは、レガシーの重い環境で完全に最適化するには18〜36か月かかります。競合が週次で出荷している世界では、それは永遠のように感じられるでしょう。

しかし、計算を組み直させてください。AppleとGoldman Sachsは、Apple Cardの構築とローンチに何年も費やしました。そしてその後始末——内部調査、規制当局の検査、法務コスト、レピュテーションの毀損、そして最終的に8,980万ドルの制裁金と消費者への救済——にも何年も費やしたのです。「速い」アプローチは速くありませんでした。前倒しのスピードと、後ろ倒しの大惨事だったのです。

私たちの段階的なデプロイ・アプローチは、現実を直視しています。銀行の基幹システムを引き剥がすことはできません。1980年代から動き続けているCOBOLメインフレームは、一夜にして消えたりしません。ですから私たちは、レイヤーを重ねる形で段階的に統合していきます。既存アーキテクチャを監査し、インテリジェントなAPIゲートウェイを構築し、AIシステムをシャドーモードで動かしてレガシーシステムの出力を検証し、形式的な証明が積み上がるにつれて、意思決定の権限を段階的に移していきます。

第一フェーズ——アセスメントと形式的モデリング——には14〜20週かかります。それが終わる頃には、Apple Cardを苦しめたようなデッドステートのバグを捕捉できる、コンプライアンス・ロジックの数学的モデルが手に入ります。36か月ではありません。根本的により安全なシステムまで、5か月足らずです。

私の考え方を変えた瞬間

何度も立ち返ってしまう、ある特定の瞬間があります。8か月ほど前のことです。私たちは金融サービスのクライアント向けに概念実証を走らせていました。彼らの異議申し立て解決ワークフローを分散ステートマシンとしてモデル化し、形式検証スイートを実行していたのです。

ソルバーは11個のデッドステートを見つけました。

消費者の苦情が、解決もアラートもないまま行き詰まる可能性のある、システム内の11本の経路です。クライアントのエンジニアリング・チームは、このシステムを3年間運用してきました。何百万件もの取引を処理してきました。監視ダッシュボードも、アラートの仕組みも、四半期ごとの監査もありました。それでも、この11個の穴はどれ一つ捕捉できていなかったのです。

結果を見せると、部屋は静まり返りました。同社のコンプライアンス責任者——銀行規制の世界で20年を過ごしてきた女性——は、画面を見つめてこう言いました。「その状態に落ちた消費者は、何人いたのですか?」

私たちには分かりませんでした。彼らにも分かりませんでした。分散システムにおけるデッドステートとは、そういうものです。誰も見張っていなければ、それは目に見えません。影響を受けた消費者は、カスタマーサービスに電話をかけ、たらい回しにされ、最終的に諦めたのかもしれません。あるいは、いまも身に覚えのない請求を払い続けているのかもしれません。

Apple Cardの失敗を内側から見ると、そういう姿をしています。劇的な爆発ではありません。規制当局がブラックボックスをこじ開けるまで誰にも見えない、ゆっくりとした、静かな被害の蓄積です。

これからの5年はどうなるのか

AppleとGoldman Sachsに対するCFPBの措置は、孤立した出来事ではありません。テクノロジー企業が金融インフラをどう扱うかをめぐる、規制上の清算の始まりです。銀行機能がより深く埋め込まれるにつれて——スマートフォンのなかに、アプリのなかに、もともと金融サービスとして設計されたわけではないプラットフォームのなかに——「たいていの場合は動く」と「常に動くことが証明されている」のあいだの隔たりは、数億ドル単位で測られる法的責任になります。

私が最もよく耳にする反論について考えます。「ほとんどの金融システムにとって、形式検証はやりすぎではないか?」私の答えは、時間とともにより単純になりました。Apple Cardは世界で最も人目に触れる消費者金融商品の一つであり、事実上無限のエンジニアリング資源を持つ二社によって構築されました。もし彼らが、従来のテストと監視では異議申し立てワークフローのデッドステートを捕捉できなかったのだとしたら、自分たちのシステムは違うと考える根拠はどこにあるのでしょうか。

業界は、私が絶対的コンプライアンスと呼ぶものへと向かっています。チェックボックスを埋める作業としてのコンプライアンスではなく、アーキテクチャ上の性質としてのコンプライアンスです。法への適合が、事後に検証するものではなく、デプロイ前に証明するものであるシステム。UIと規制のあいだの隔たりが、人間の警戒心ではなく、数学的な確実性によって埋められるシステムです。

「速く出荷して後で直す」の時代は、「お金を動かし、人を守る」というグローバル金融の要件とは相容れません。Apple Cardがそれを証明しました。問題は、業界が次の8,900万ドルの制裁金の前に学ぶのか、後に学ぶのか、です。

私たちはVeriprajnaで、その未来を築いています。簡単だからではありません——分散型金融システムの形式検証は本当に難しく、そうでないと言う人は何かを売りつけようとしています。しかし、そうしなかった場合に待っているのが、2024年10月に私たちが目にしたものだからです。世界で最も強力な企業の二社、壊れた一つのボタン、そして身に覚えのない請求を抱えたまま取り残された数万人の人々。

これはテクノロジーの問題ではありません。エンジニアリング倫理の問題です。そして解決策は、より良い監視でも、より速いパッチでもありません。構成上正しい(correct by construction)システムを作ること——消費者の異議申し立てが虚空へ消えることは決してないと数学が保証するシステムを作ることです。

8,900万ドルの制裁金はすでに支払われました。本当のコストは、壊れた信頼です。それを立て直すには、約束以上のものが必要です。証明が必要なのです。