Solutions

銀行・金融サービス

銀行のための AI プラットフォーム。

定型的な作業は AI に、判断はバンカーに。銀行水準のコンプライアンスを満たす統一プラットフォームにより、各事業部門は土台を作り直すことなく、自分たちの AI を本番に投入できます。

営業担当に相談する

本番環境に導入。

ある世界有数の銀行（アジア全域で事業展開）

この銀行は国際的な銀行業界の賞を幾度も受賞しており、Dify Enterprise を Red Hat OpenShift 上で六つの事業部門にわたり運用しています。

最大規模の単一導入は国際金融業務です。約 3,000 名のリレーションシップマネージャーが 80 以上の Dify ワークフローを使い、顧客ドシエ、アカウントプラン、与信審査、競合分析、リアルタイム業務データの取得を処理しています。

プラットフォームは五つの環境（Dev・SIT・UAT・Test・Production）で稼働しており、リリースとガバナンスの基準は同行の基幹システムと揃えてあります。データベースのチューニングとマイクロサービスアーキテクチャにより、同時処理能力は当初の 5 から 50 超へ引き上げられました。

事例の全文を読むグローバル大手銀行が Dify Enterprise で 6 事業部門に AI を展開した方法

営業担当に相談する

6
事業部門が一つの Dify プラットフォームを共有
80+
本番ワークフロー（国際金融業務のみ、3,000 名の RM を支える）
3,000
名のリレーションシップマネージャーが Dify ワークフローを活用
5
つのリリース環境（Dev→Prod）、基幹システムと同水準

出典：ある世界有数の銀行における Dify Enterprise の導入事例

なぜ今、
この業界に AI が必要か。

制約

銀行には動かせない三つの前提があります。第一に、顧客データも取引も監査証跡もすべてが規制の対象であり、AI を片手間のツールとして出すことはできません。第二に、変更管理が徹底しています。本番リリースはフラグ一つの切り替えではなく、正規の DevOps プロセスを最後まで通します。第三に、AI を最も必要とする人々が、法人・ウェルス・マーケット・リテール・リスクと異なる現場に分かれ、それぞれ固有の業務フローを持ちます。部門ごとにチャットボットを買っても、この三つには答えられません。問われるのは、その土台となるプラットフォームそのものです。

AI の役割

だから銀行において AI は、もう一つのアシスタントではなく、プラットフォームの選択になります。Dify が担うのは三つです。全行で一つの環境を動かし、中央のエンジニアリングがランタイム・ガバナンス・インフラを担い、各事業部門は自分たちのワークフローを構築・運用します。顧客ドシエ、アカウントプラン、与信メモといった銀行業務の反復的な部分をワークフローに変え、判断はバンカーの手に残します。そして銀行がすでに築いた DevOps に寄り添い、セルフホストの Kubernetes 上でマルチ環境のリリースパイプラインを最後まで通します。

よく見られるパターン。

全行で一つのプラットフォーム、事業部門ごとの自律: 事業グループごとに AI プロジェクトを別々に立てるのではなく、一つのプラットフォームがそのすべてを支えます。法人・ウェルス・マーケット・リテール・リスクの各チームは最も得意なワークフローを自ら持ち、中央のプラットフォームエンジニアリングが土台のランタイム・ガバナンス・インフラを担います。プラットフォームを共有するため、取り組みは単一チームの枠を超えて広がります。
高頻度のドキュメント業務: 顧客ドシエ、アカウントプラン、与信メモ、マーケットコメント、リサーチ。銀行は構造が反復的で中身は一件ごとに異なる文書で回っており、これはまさにワークフローが得意とする境界線です。Dify が定型の部分を引き受け、リレーションシップマネージャーは顧客との関係を支える判断に専念します。
銀行水準の DevOps、セルフホストで: 銀行が求めるのは Dev・SIT・UAT・Test・Production まで揃った完全なリリース体系であり、Kubernetes（多くは Red Hat OpenShift）上でのセルフホストまたはソブリンクラウド、そして自行の ID・監査システムとの連携です。Dify ではこれらが後付けの飾りではなく、初日から備わるプラットフォームの前提であり、銀行が基幹システムを運用するのと同じ水準にあります。