Anthropicが、ファイナンス向けエージェントの新リリースを発表しました。今回公開された機能のひとつに、KYCスクリーナーがあります。
もしあなたがKYCを仕事にしているなら、あの大きな見出しを目にしたはずです。かなり話題になりました。でも私は、それをただ拡散するだけでなく、もっと役に立つことがしたいのです。
この投稿には2つの目的があります。1つ目は、報道のされ方とは切り離して、Anthropic が実際に何をリリースしたのかを説明すること。2つ目は、彼らがリリースしたものが、あなたが解決しようとしている問題に合っているのか、それとも別のものが必要なのかを見極める手助けをすることです。
要点を一言で言うと：Anthropic のリリースは朗報です。これは、私たちがすでに予想していた「金融犯罪対策はエージェント型AIと非常に相性が良い」ということを裏付けるものです。現時点で問題になっているのは、KYCでAIを使うかどうかではありません。それはもう決着がついています。今問われているのは、「どの形態のAIが自社のオペレーションに本当に適しているのか」という点です。かどうかKYCでAIを使うかどうか、ということではありません。それはもう決着がついています。今問われているのは、「どの形態のAIが自社のオペレーションに本当に適しているのか」という点です。
さっそく始めましょう。
Anthropic が実際に公開したもの
これは完成品ではなく、あくまで出発点にすぎません。アーキテクチャの話を取り払ってしまえば、中身はこういうものです。
その能力
これは、すべてのオンボーディングレコードに対して4つのステップからなるワークフローを実行します。まずドキュメントリーダーが、KYCパケットから構造化されたフィールドを抽出します。次にルールエンジンが、抽出されたフィールドに対して貴社のKYCルールを適用します。その後のスクリーニングステップでは、制裁リスト、PEP（要人）、ネガティブニュースなどを含め、記載されているすべての当事者を、貴社が接続したスクリーニングMCPを通じて照合・確認します。
エスカレーターは、人の確認が必要なあらゆる事項をコンプライアンス用のパケットにまとめます。出力はリスク評価、処理結果、不足書類、エスカレーション理由、ルール判定結果などを含む構造化されたJSONで、レビューキューにそのまま投入しやすい形式になっています。
どのように導入するか
同じテンプレートから生まれた2つの形態。1つは、Microsoft Office 上で動作し、人間のレビュー担当者を支援するアナリスト向けプラグイン。もう1つは、認証情報の保管庫、範囲が限定されたツール権限、完全な監査ログを備え、自律的に動作するサーバーサイドのマネージドエージェントです。同じプロンプトで、実行環境は2種類。その点は本当によく設計されています。
まずは人間の監督のもとで運用し、自信がついたらエージェントを書き換えることなく自律運用へと移行できます。
以上がリリース内容です。既存のどんなスタックにも組み込めるように設計された、クリーンな出力契約を持つ推論レイヤーです。ただし、その文の「既存のどんなスタックにも」という部分には、かなり多くの意味が詰め込まれています。
同梱されていないもの
KYCのために専用ツールが必要となるあらゆるもの。
このテンプレートには、文書鑑識の機能は一切含まれていません。フォント解析、ホログラム検証、マイクロテキストのチェック、不正なレンダリングの検出といったID改ざんの検知は、それ専用の学習データを必要とする、特殊な機械学習の問題です。Anthropicのエージェントは、基盤モデルの画像認識とOCRを使って文書を読み取ります。これは「この文書には何が書いてあるか」を知るには十分ですが、「これは本物のパスポートか、それともPhotoshopで作られた偽物か」を見分けることとは別物です。
ライブネス検知、ディープフェイク検知、自撮りリプレイ対策、3Dマスクチェック？そういったものは一切ありません。もしあなたが一般消費者のオンボーディングをしていて、ディープフェイクが正面から入ってきても、基盤モデルではそれを見抜くことはできません。
デバイスインテリジェンスも欠如しています。行動バイオメトリクスから実際のIP、実際のOS、実年齢に至るまで、このテンプレートはそれらを一切把握できるように設計されていません。ユーザーがレジデンシャルプロキシ上のエミュレーターからアクセスし、3つの別アカウントとデバイスを共有していたという事実も？そのようなシグナルは、この仕組みの中にはそもそも存在していないのです。
KYB なし。UBO なし。州務長官による確認なし、EIN/TIN なし、住所分析なし、業種分類なし、ウェブ上での存在確認もなし。事業体のオンボーディングは別の課題であり、このテンプレートが扱うのは個人の本人確認です。
KYC ルールスキルは自社のポリシーを形式化するためのものであり、あらかじめ用意された CIP ルールライブラリや、30/60/90 日の期間でバックテストを実行できるフレームワークが同梱されているわけではありません。自分で用意したものだけが、そのまま結果として反映されます。
また、ケース管理用のUIもありません。このテンプレートは「エスカレーションをまとめて」引き渡すだけです。どこに？ それは、あなたがすでに構築しているレビューシステムです。もしまだ持っていないなら、これから構築することになります。
さらにオンボーディング以外を見ると、顧客ライフサイクル全体をカバーするものが何もありません。再スクリーニングもなければ、リスク評価の更新もなく、継続的なモニタリングもありません。コンソーシアムデータもなければ、数十億のデバイスや消費者をまたいだ接続関係を示すグラフもありません。
これはリリースへの批判ではなく、そのリリースが何であるかを明確にするための説明です。Anthropic が提供しているのは「推論レイヤー」です。銀行、あるいは銀行が利用している業界特化型のKYCベンダーが、データやシグナル、フォレンジクス、そしてその推論が動作するためのオペレーション基盤を提供します。
能力 | Anthropic 本人確認スクリーナー | Sardine Doc KYC エージェント |
フォームファクター | リファレンスアーキテクチャ：プラグインまたはマネージドエージェント | Sardine プラットフォーム上の製品化されたエージェント |
文書鑑識 | ファウンデーションモデルによるOCRと画像認識 | ID改ざんを検知するための専用設計 |
ライブネス／ディープフェイク | 対象外 | ネイティブ |
デバイスと行動シグナル | ネイティブ対応なし | TrueIP、TrueOS、行動バイオメトリクス |
ウォッチリスト（OFAC／PEP／SDN） | 同梱なし | 組み込みスクリーニング＋制裁リスクの再スクリーニング＋アラートの自動解消。 |
KYB / UBO（企業顧客の審査 / 実質的支配者） | 対象外 | バンドル済み |
あらかじめ用意されたルールライブラリ | 持ち込み | 数百種類のCIPルールとバックテスト機能 |
ケース管理 | 未提供 | 統合された |
自動解像度 | 企業依存の | 88％が申告済み；あるスポンサー銀行では95％以上が自動化された制裁スクリーニング |
推論レイヤーはあくまで土台にすぎない
これだけは率直に言っておきたい。というのも、ほとんどの報道がこの点をさらっと流してしまっているからだ。
推論モデルは急速にコモディティ化しつつある。
5年前には、エンティティファイルを読み込み、5つのルールと照合し、その結果を流暢な英語で説明できるモデルは大きな参入障壁でした。ところが今では、それができるものを出荷している研究所が3つあり、トップと3番手の差は、顧客が乗り換えてしまうほど小さくなっています。
このモデルはKYCの判断材料の一つにすぎません。システムそのものではありません。
たとえ Opus 4.7 のような優れた LLM を使ったとしても、何の調整もせずに大量の顧客書類にそのまま適用すると、すぐに気づくことがあります。それは「怪しく見えるものがやたら多い」とモデルが判断しがちだということです。書類の品質のばらつき、独特な音訳になっている名前、米国以外の形式で書かれた日付、珍しい形式の部屋番号を含む住所など、こうしたものはすべて、その顧客基盤における“普通”がどういうものかを学習していないモデルには異常値として映ってしまいます。このテーマについては、最近のブログ記事で取り上げました。
私自身、これまで3つの国に住んだことがあるので、PayPalアカウントを3つ持っています。文脈のないモデルからすると、これはかなり怪しいシグナルです。でも、この仕事をしていて顧客層を理解している人間からすれば、ごく普通のことです。
解決策はキャリブレーションです。実運用環境から集めた真のポジティブ例と真のネガティブ例を、厳密にラベリングしたうえでモデルに与え、詐欺そのものと「詐欺っぽく見えるだけのもの」をきちんと区別できるように学習させることを指します。私たちはこれを中心にしたエージェント型オーバーサイト・フレームワークを構築しており、ホワイトペーパーではその検証ループについて詳しく説明しています。重要なのは、「それができるのは私たちだけだ」ということではありません。重要なのは、これこそが本来やるべき仕事であり、優れた基盤モデルを手に入れたからといって自動的についてくるものではない、という点です。
監督に関する問題
KYC 業務に自律エージェントを投入して、あとは放置というわけにはいきません。Anthropic はそれを理解しているからこそ、Managed Agents にはツールごとの認証情報ボールト、スコープが明確な権限設定、そして完全な監査ログが備わっています。これは本物であり、従来の自律エージェント向けインフラに対する意味のある前進です。
しかし、監査ログはケース管理ツールではありません。
ケースマネージャーは、エージェントの判断、アナリストによる上書き、顧客からの証拠、コミュニケーションのタイムライン、エスカレーション経路、そして次のモデルバージョンへのフィードバックループがすべて集約される基盤です。規制当局が「この顧客をクリアすると判断したプロセスを見せてください」と求めたときに、指し示す先となるのがここです。
Sardine では、私はこの部分のことを一番よく考えています。私たちは大手フィンテック企業も利用している一流のスポンサー銀行と提携しており、そこでエージェントが制裁スクリーニングのアラートの95％以上を自動で処理しています。アラートを解決し、その理由をケースマネージャーにコメントとして残し、本当に人間の判断が必要な案件だけをエスカレーションします。人間はエージェントの推論を確認し、賛成か反対かを判断して自分のコメントを残します。すべてにタイムスタンプが付きます。意見が食い違ったケースはすべて、次回のエージェントの学習とチューニングのサイクルにフィードバックされます。
そのループこそがプロダクトです。ループの中で推論を行うモデルは、その一部のコンポーネントに過ぎず、入れ替えや改良が可能です。コンプライアンスチームや規制当局が重視するのは、まさにそのループそのものなのです。
Anthropic のテンプレートには、このループは含まれていない。彼らが対応しているのは、監査可能な実行部分――つまりクレデンシャル・ボールト、ツールごとの権限設定、長時間実行セッションのログまでだ。ケース管理用の UI やアナリストによる手動介入、意見の相違を学習データに戻すためのパイプラインを作るのは、購入側の仕事になる。
顧客データにパブリックAIを接続する前に答えるべき問い
こういうことは十分に語られていない。
顧客のオンボーディングのプロセスにパブリックなファウンデーションモデルを組み込もうとしているなら、まず4つの問いに対して明確な答えを持つ必要があります。「ベンダーが大丈夫だと言っていたから」ではいけません。CISOとコンプライアンス担当者が署名できる、文書化された明確な回答が必要です。
- エージェントが顧客の PII やトランザクションデータを処理するとき、そのデータはどこへ行くのでしょうか？ テナント単位でスコープされていますか、それとも共有の推論経路を通過しますか？ ログはどこに保存されていますか？
- 顧客データをグローバルで公開されたAIプラットフォームにアップロードしていますか？ もしそうであれば、契約書にはデータの保存期間、アクセス権限、および漏えい時の責任についてどのように定められていますか？
- 国内保管義務（オンソイル・ジュリスディクション要件）にはどのように対応していますか？ もし規制当局が「データを国外に出してはならない」と定めている一方で、推論処理が別の国で行われている場合、その点について説明できる必要があります。あなたの説明は何ですか？
- そのプラットフォームはあなたのデータで学習しますか？あなた自身のデータ、競合他社のデータ、そして将来流れてくるあらゆるデータで学習するのでしょうか？もし「しない」という答えなら、そのことは文書で明記されていますか？もし条件付きで「する」という答えなら、その条件は何ですか？
これらは意地悪な突っ込みではありません。顧客データに触れるあらゆるベンダーに対して、調達担当がごく普通に行う質問です。ただ、そのベンダーが基盤モデルの研究開発を行うラボでもある場合、話は難しくなります。さらに、そのモデル自体が競争力の源泉となる資産であり、学習データから利益を得る性質を持つ場合は、いっそう難しくなります。
Managed Agents のアプローチは、これらの疑問に対して部分的な答えにはなりますし、クレデンシャル・ボールトや長時間実行セッションのモデルも、この種の精査を想定して設計されています。しかし、部分的な答えがそのまま「解決済み」という意味にはなりません。このルートを取るのであれば、正式な調達プロセスを本格的に踏むつもりで計画してください。
では、これは一体誰のためのものなのでしょうか？
さて、ここからが本題です。
Anthropic のテンプレートは、特定のタイプの購買者向けに作られています。社内に強力なエンジニアリング体制があり、既存のデータスタック（KYC ベンダー、市場データ、社内 CRM など）、既存の審査・レビュー業務を持ち、推論レイヤーをエンドツーエンドで自社保有したいというニーズがある購買者です。発表の中で Anthropic が名前を挙げている Citadel、BNY、Carlyle といった顧客は、まさにそのプロフィールにぴったり当てはまります。彼らが必要としているのは、すぐに使える KYC 製品ではなく、自社のワークフローに組み込める柔軟な推論レイヤーなのです。
その購入者にとって、KYC スクリーナーは、これまで使っていたものより大きなグレードアップになります。彼らが得られるものは次のとおりです。
- Vals AI Finance Agentベンチマークをリードする推論モデル。
- アナリストが日常的に使っている Excel、Word、Outlook などの Microsoft 365 の各種ツールと深く統合されています。
- クリーンでコンポーザブルなアーキテクチャ。スキル、コネクタ、サブエージェントをそれぞれ独立して入れ替え可能。
- 同じテンプレートから、デスクトップ用とサーバーサイド用の両方のデプロイパスを利用できます。
- 各ツール専用の認証情報ボールトと、マネージドエージェントによる完全な監査ログ。
もしあなたがそのようなバイヤーであるなら、正しい行動は、おそらくそのテンプレートを真剣に受け止め、自社の既存スタックに対してきちんとしたPoC（概念実証）を行い、不足している要素（フォレンジック、デバイス、ウォッチリスト、ケースマネージャー）について、どれをベスト・オブ・ブリードのコネクタで補うのか、どれを自社開発するのか、どれをパートナーと組んで補うのかを見極めることだ。
Sardine は、これまでとは異なるタイプの顧客向けに作られています。エンジニアチームを雇って独自スタックを組み上げる前提ではなく、来年ではなく「次の四半期までに」本番環境で KYC を稼働させる必要がある顧客です。具体的には、フィンテック企業、ネオバンク、大手銀行、決済プロセッサー、暗号資産取引所といったプレイヤーが該当します。彼らが重視するのは、オーケストレーションレイヤーを自前で持つことよりも、（自動解決率、誤検知率、承認までの時間）といった成果そのものです。
その購入者には、Sardine が次のものを発送します：
- ID改ざんに特化して設計されたドキュメント鑑識ソリューション
- ライブネスおよびディープフェイク検出
- ドキュメントの審査判断に反映される、デバイスインテリジェンスと行動バイオメトリクス
- しきい値設定と継続的モニタリングを伴うウォッチリストスクリーニング
- オンボーディング時の単発チェックだけでなく、継続的な制裁スクリーニング
- KYB/UBO と KYC の一括確認
- ノーコードで編集でき、30・60・90日間のバックテストにも対応した、あらかじめ構築済みのCIPルールライブラリ
- アナリストとエージェントの協働のために設計され、意見の相違を監査可能な形でフィードバックループとして扱えるケースマネージャー
- 数十億のデバイスと消費者にまたがるSonarコンソーシアムのデータ
これらは仮想的な能力ではありません。私たち自身の暗号資産オンランプにおいては、IDVエージェントが同じスタック上で稼働しており、本人確認で約95％を自動化しています。これは、自動制裁スクリーニングを行っているあのスポンサー銀行の顧客で見られる自動化率と同じ水準です。
実はもうひとつ、かなりおもしろい第3の選択肢があります。それは「両方を動かす」ことです。推論モデルの強みが最も効いてくるケース――たとえば複雑なエンティティの扱い、物語性の強いエスカレーション、規制関連文書のドラフト作成など――では、オーケストレーション層にAnthropicのテンプレートを使い、データ、フォレンジック、デバイス層については MCP コネクタ経由で Sardine を呼び出す、という形です。これは正面からの競合ではなく、パートナーシップです。こうした使い方をする顧客が、1年以内に出てくると見ています。
これが意味すること
発表があったときにチームのみんなに伝えた言葉で、締めくくりたいと思います。
これは朗報です。Claude を開発しているラボが、金融犯罪対策がエージェント型 AI にとって自然な適用分野であることを公に裏付けました。過去 2 年間にわたって私たちが主張してきた「AI エージェントは誤検知を減らし、調査のスピードを上げ、人間のアナリストを本当に判断が必要な業務に専念させられる」という議論が、いまや業界で最も影響力のあるモデルラボのコンセンサスとなったのです。
推論レイヤーはこれからもどんどん良くなり、どんどん安くなっていくでしょう。それで問題ありません。KYCプロダクトにおいて本当に防御力の源泉になる部分が「うちのモデルが一番優れていること」になることは、最初からあり得なかったのです。そうではなく、価値の源泉になるのはデータであり、シグナルであり、ルールライブラリであり、ケース管理であり、規制当局との関係であり、そして実際の顧客を相手に本番環境で大規模に運用してきたことで得られた、オペレーション上の“傷跡”なのです。
もしあなたが購入者なら、「どのモデルが一番良いか」が正しい問いではありません。なぜなら、その競争は6か月ごとにリセットされてしまうからです。正しい問いはこうです。「1年後に自分のシステムはどのような姿になっていて、その姿に最速で到達できるのは、どのフォームファクター（コンポーザブルなプラットフォーム、垂直特化型プロダクト、あるいはその両方）なのか？」
それに合わせて構築しましょう。
