資産管理の顧客オンボーディングは、すべてのシステムがそれぞれの役割を果たした後でも停滞することがある。文書は収集され、スクリーニング結果は返され、ワークフロータスクは完了した。しかし、何が変更されたか、どの証拠が最新か、誰が例外を担当するかを誰かが判断する必要があるため、ケースはまだ待機している。
顧客にとって、これらの境界は見えない。彼らは一つの旅を経験し、自分の情報と進捗がそれに伴って移動することを期待する。しかし、企業内部では、その旅は顧客関係管理（CRM）、文書、顧客確認（KYC）、スクリーニング、カストディ、ワークフローシステムを横断し、それぞれがケースの異なる部分を保持している。
企業はこれらの個々のステップを迅速化するために投資しており、AIはそれらをさらに加速している。しかし、次のチームがまだケースを再構築し、証拠を照合し、完了したように見える作業を再開する必要があるなら、より迅速な抽出、スクリーニング概要、ルーティング決定はほとんど役に立たない。
オンボーディングはこれらの引き継ぎで時間を失い続けている。現代のプラットフォームは、システム間でケースを接続し、条件が変化するにつれて作業を調整し、プロセスが依存する統制と人間の判断を保持する必要がある。そうでなければ、コストはシステム間で蓄積される。
なぜ資産管理の顧客オンボーディングにはそんなに時間がかかるのか？
最初のコストは、顧客が最も直接的に感じるものである：時間だ。シンガポールでは、プライベートバンキング口座の開設には約6週間かかり、複雑なケースではさらに長くなる。2026年5月、シンガポール金融管理局（MAS）は、MASと業界が共同で主導する口座開設ワーキンググループの取り組みにより、その中央値が1か月以内になると予想されると述べた。
企業内部では、それはスタッフの時間に現れる。キャップジェミニの「ワールド・ウェルス・レポート2026」は、144人の資産管理幹部のうち60％が統一された顧客ビューを欠いていることを発見した。同じ報告書は、16市場の1,317人のリレーションシップマネージャーが、運用業務が彼らの時間の41％を消費していると述べたことを発見した。この数字はオンボーディングだけでなく、広く資産管理業務をカバーしているが、日常的な調整がどれだけの能力を吸収できるかを示している。
オンボーディングの旅自体は多くのチームにまたがる。2024年のEYの十数社のグローバル資産運用会社による報告書は、半数以上がオンボーディングに少なくとも10のチームを関与させていることを発見した。しかし、CRMシステムとの強力な統合を報告したのはわずか15％だった。
2024年のKPMGとプライベート・ウェルス・マネジメント・アソシエーションによる香港の35のプライベートウェルス機関の調査は、オンボーディングの要求がコスト上昇と顧客体験の悪化の要因として引用された。
これらの調査結果は市場、人口、監督体制にまたがり、それぞれを文脈で読む必要がある。それらを横断するパターンは一貫している——顧客情報の断片化であり、多くのチームが旅を縫い合わせている。
企業はその調整をスタッフの時間、繰り返される証拠検索、手動の照合、例外処理、統制履歴の準備で吸収している。統合、保守、変更テストはさらにコストを追加し、口座開設と資金供給は待機する。
より迅速なタスクが常により迅速なオンボーディングの旅を生み出すわけではない。システムは時間通りに作業を完了しても、次の引き継ぎでケースを停滞させたままにすることがある。AIは各タスクをさらに加速できるが、システム間の摩擦を自動的に取り除くわけではない。
なぜタスクレベルのAIはオンボーディングの旅を加速しないのか？
AIはすでに資産管理および資産運用に進出している。2025年のEYの100人の意思決定者を対象とした調査では、資産管理と資産運用会社が均等に分かれており、95％の企業が複数のユースケースで生成AIを拡大していると報告し、78％がエージェントAIを模索していた。しかし、この勢いを測定可能なビジネス価値に変換することは依然として課題であり、経営幹部の27％だけが生成AIから実質的なビジネス影響を報告している。
仕事自体を調べることで、このギャップが説明できる。AIは文書フィールドを抽出し、スクリーニング結果を要約し、次のワークフローアクションを推奨することができる。各機能は単一のアプリケーション内のタスクを改善するかもしれないが、引き継ぎは依然として現在の証拠と何が変更されたかの明確な記録に依存している。チームはまた、以前の作業を再検討する必要があるかどうかを知る必要がある。
AIエージェントは、専門エージェントと承認されたツール間で作業をルーティングするには共有ケース状態が必要であるため、その依存関係をより重要にする。その状態は、何が完了し、何が古くなり、どの例外が次のステップを妨げているかを示す必要がある。それがなければ、より迅速なオーケストレーションは、それが削減するはずだった断片化を再現する可能性がある。
顧客オンボーディングにおけるガバナンスされたケースコンテキストとは何か？
ガバナンスされたケースコンテキストは、各顧客オンボーディングケースの現在の、バージョン管理された、ソースにリンクされたビューである。それは証拠、ケース状態、完了した統制、未解決の例外、エージェント活動、および意思決定履歴をまとめる。コンテキストはバージョン管理されているため、チームは何が変更され、その変更が何に影響し、以前の作業を再検討する必要があるかどうかを確認できる。
オンボーディングの異なる部分は異なる場所に存在することがある。コア顧客およびカストディ記録は割り当てられたシステムに残り、証拠処理、統制、モデル、ケースワークフローはDatabricksデータ+AIプラットフォームで実行できる。ガバナンスされたケースコンテキストは、記録の所有権と意思決定権限を保持しながら、これらの作業を一つのガバナンスされたビューで接続する。Databricksでは、Unity Catalogがこのコンテキストのアクセス制御、リネージ、監査性を集中化し、Delta LakeやApache Icebergなどのオープンテーブル形式が信頼性の高いデータ管理とシステム間の相互運用性をサポートする。
ガバナンスされたケースコンテキストは、次のエージェントまたはレビュー担当者がケースを理解し前進させるのに役立つ場合にのみ有用である。実用的なテストは、履歴を再構築せずに4つの質問に答えられるかどうかである：
どの証拠が最新で、どのソースとバージョンがそれをサポートしているか？
どの作業が完了し、何が変更され、どの結果が古くなった可能性があるか？
何が未解決で、次に許可されるアクションは何か？
どの作業をエージェントまたは承認されたツールが実行でき、どこで権限のあるレビュー担当者が決定する必要があるか？
これらの答えが一か所にあれば、ガバナンスされたスーパーバイザーエージェントは現在のケース状態から作業を再開できる。独立したタスクを専門エージェントに割り当て、承認されたツールを呼び出し、判断が必要なときにレビュー担当者を関与させることができる。また、矛盾する証拠にフラグを立て、レビュー用の完全なパッケージを組み立てることができ、そのパッケージの背後にある証拠、変更、アクションはケースに添付されたままである。
価値は、このコンテキストを旅全体で活用することから生まれる。現代のプラットフォームは、それを最新に保ち、その周りでエージェントと人々を調整し、最初の証拠から最終決定まで可視性とガバナンスを維持する必要がある。
エージェント対応のオンボーディングプラットフォームには何が必要か？
ガバナンスされたケースコンテキストを活用するには、4つのプラットフォーム機能が必要である。それらは共に、以前に特定された摩擦に対処する：各引き継ぎでケースを再構築すること、手動で作業を調整すること、機密データへのアクセスを統制すること、そして旅全体を見ずにタスクを測定すること。
ケースの現在のビューを維持する：証拠が到着し、統制が実行され、決定が下されるにつれて、プラットフォームはガバナンスされたコンテキストを更新し、基礎となるソースへのリンクを保持する必要がある。特定の記録に割り当てられたシステムは権威を持ち続けることができ、エージェントとチームは同じバージョン管理されたコンテキストから作業する。Databricksでは、Lakeflow Connectがサポートされているソースシステムからの変更をプラットフォームに取り込み、Databricks AI Functionsが新しい証拠を抽出および分類し、Lakebaseがオンボーディングアプリケーションで使用されるライブトランザクション状態を維持する。
人々が権限を保持しながらエージェント作業を調整する：ガバナンスされたスーパーバイザーエージェントは、現在のケース状態に基づいて次の許可されたアクションを選択し、定義されたタスクを専門エージェントまたは承認されたツールに送信し、判断が必要なときに資格のあるレビュー担当者を関与させる必要がある。人々は例外、オーバーライド、オンボーディング承認の責任を保持する。Databricksでは、Supervisor Agentsがガバナンスされた企業データ上で専門エージェントと承認されたツール（Unity Catalog関数、MCPサービス、Genie Agents（旧Spaces）を含む）を調整できる。
データ、ツール、アクションを統治する：オンボーディングには個人識別情報（PII）やその他の機密記録が含まれる。各エージェントはそのタスクに必要なデータとツールにのみアクセスすべきであり、機密フィールドは適切にマスクまたは保留されるべきである。エージェント活動はトレーサブルでレビュー可能であるべきである。Databricksでは、Unity CatalogがガバナンスされたデータとAI資産全体にきめ細かいアクセス制御、マスキング、リネージ、監査性を提供し、Unity Gatewayがそのガバナンスをエージェントランタイムに拡張し、各エージェントが呼び出せるモデルとMCPツールを制御し、ガードレールを適用し、モデル間でリクエストをルーティングし、予算とレート制限を実施し、すべてのリクエストをログに記録する。
エンドツーエンドで測定する：チームはエージェントの品質、レイテンシ、信頼性、エスカレーションを、サイクルタイム、手動タッチ、手戻り、例外、承認から資金供給までの時間とともに監視する必要がある。運用状況には、統合の変更、重複するデータ移動、統制証拠を準備するために必要な労力も含めるべきである。Databricks Appsは、キューとケースワークスペース内にDatabricks AI/BIダッシュボードを埋め込み、運用およびコンプライアンスリーダーに、アクティブなケースと並んで旅のパフォーマンスの統合ビューを提供できる。
まとめると、これらの機能はガバナンスされたケースコンテキストを運用モデルに変える。アーキテクチャは、コンテキスト、監督されたエージェント、人間のレビューが実際にどのように連携するかを示している。
監督されたAIエージェントはどのように顧客オンボーディングを調整するのか？
アーキテクチャは、4つの機能を各ケースの周りの反復的な運用ループに入れる。情報はソースシステムから到着し、証拠処理、統制、リスクモデル、オンボーディングワークフローはプラットフォームで実行される。各結果はソース参照と履歴を添えてガバナンスされたケースコンテキストに戻り、次のエージェントまたはレビュー担当者にケースの現在の状態を提供する。
ガバナンスされたスーパーバイザーエージェントはそのコンテキストを読み、次の許可されたアクションを選択する。ケースに応じて、承認されたツールを呼び出したり、専門エージェントに作業を割り当てたり、レビュー担当者を関与させたりできる。新しい証拠が以前の結果を古くする場合、ケース全体を再開するのではなく、影響を受ける作業を再開できる。また、完了と鮮度を監視し、ケースが前進する前に欠落または矛盾する統制結果にフラグを立てる。
簡単な例でループがどのように機能するかを示す。必要な文書を待っているケースを考えてみよう。スーパーバイザーはギャップを特定し、レビュー用の顧客アウトリーチメールを準備し、欠落した証拠に依存する作業を一時停止できる。レビュー担当者がアウトリーチを承認し、文書が指定されたチャネルを通じて到着すると、ケースコンテキストが更新される。スーパーバイザーはその後、文書処理をトリガーし、影響を受けるチェックのみを再実行し、ケースを次の許可されたステップにルーティングできる。