powered by TechFeed
表示モード
Deep Dive

三菱UFJ銀行がフローチャート作成を10人日→0.5人日に短縮 — LLM単体では「使い物にならなかった」ためオントロジーで知識グラフを構築

10月9日、AWSが「How MUFG Bank aims to cut flowchart work by up to 90% with ontology-grounded AI on Amazon Neptune and Amazon Bedrock」と題した記事を公開した。三菱UFJ銀行がAmazon NeptuneとAmazon Bedrockを活用したオントロジーベースのAIシステムにより、海外拠点の業務フローチャート作成工数を最大90%削減した事例だ。LLM単体では品質が「使い物にならなかった」という出発点から、なぜ知識グラフが解決策になったのか——その設計思想と実装の詳細が丁寧に解説されている。

10月9日、AWSが「How MUFG Bank aims to cut flowchart work by up to 90% with ontology-grounded AI on Amazon Neptune and Amazon Bedrock」と題した記事を公開した。三菱UFJ銀行がAmazon NeptuneとAmazon Bedrockを活用したオントロジーベースのAIシステムにより、海外拠点の業務フローチャート作成工数を最大90%削減した事例だ。LLM単体では品質が「使い物にならなかった」という出発点から、なぜ知識グラフが解決策になったのか——その設計思想と実装の詳細が丁寧に解説されている。


LLM単体では「使い物にならなかった」——なぜオントロジーが必要だったか

三菱UFJ銀行は約30カ国に海外拠点を持ち、1日あたり約20万件のトランザクションを処理している。そのうち送金業務が**全体の86%**を占める最大ワークロードだ。

問題は、20年以上にわたる海外展開の過程で、業務手順が拠点ごとにバラバラに育ってしまったことにある。本社標準手順が存在しながら、米国・英国・アジアの各大拠点はそれぞれ異なる手順を運用しており、標準化できていた業務は全体の約10%にとどまっていた。

標準化を進めるには、まず各拠点の手順をフローチャートに起こし、他拠点や本社標準と比較し、関係者と調整し、修正する——というサイクルが必要だった。このフローチャート作成だけで1拠点・1手順あたり約10人日、比較・修正を加えると合計11人日かかっていた。さらに関係者調整に1〜2人月が積み上がる構造で、数百の拠点×手順の組み合わせを前に、バックログは解消不可能な状態だった。

加えて、日本が直面する「2030年問題」が状況に拍車をかけている。2030年前後には団塊世代の大量退職と少子化による生産年齢人口の急減が重なり、金融機関を含む多くの業種で深刻な人手不足と属人化した業務知識の喪失が懸念されている。海外拠点ごとに散在する業務ノウハウを人海戦術で移転・標準化し続けることは、もはや持続可能な選択肢ではない。金融業界においてナレッジグラフや構造化された知識表現への関心が高まっている背景には、こうした構造的課題がある。

LLMだけを試したら「使えない品質」だった

2024年末から2025年初頭にかけて、MUFGチームはまずLLM単体で手順書からフローチャートを自動生成するPoC(概念実証)を試みた。結果は芳しくなかった。実行のたびに品質がばらつき、モデルが存在しない手順を「無言で捏造」する問題が頻発した。MUFG自身の言葉を借りれば、LLMだけで生成したフローチャートは「使い物にならなかった(unusable)」。


解決策:オントロジー+知識グラフでAIを「業務の文法」に縛る

2025年1月、MUFGはAWSスペシャリストおよびAWS Professional Servicesと共同で、LLMの下に2層を追加する設計を提案した。

  • オントロジー(ドメインの設計図):業務概念・関係・ルールを定義する構造モデル。「支払情報 → 必須項目を入力」「担当者 → 送金を実行」といった三つ組(トリプル)として表現し、RDFとOWLでエンコードする。
  • 知識グラフ(拠点ごとのインスタンス):各拠点の実際の業務手順をオントロジーに照らしてマッピングし、Amazon Neptuneに格納する。設計図(オントロジー)に対して、各拠点の知識グラフは「その設計図から建てた建物」にあたる。

AIエージェントはフローチャートを生成する前に、まずNeptuneから関連サブグラフを取得する。たとえば国際送金フローを生成する場合、エージェントは「Payment Request → Cross-Border Payment → Mandatory Field Validation → Sanctions Screening → Authorization」というノードとエッジの連鎖、および閾値条件やポリシー参照を先に引き出す。LLMはその制約の中でしか出力を生成できないため、ハルシネーション(幻覚)が大幅に減少する。

推論エンジンにはHermiT(OWL推論器)を採用し、NeptuneとAIエージェントの間でOWLが意味する暗黙の関係を導出する役割を担わせている。

重要な前提として、このオントロジーは「業務手順を標準化するもの」ではない。標準化の判断はあくまでMUFGの業務専門家と各地域の関係者が行う。オントロジーが加速するのは、その判断の「前工程」——フローチャートの作成・比較・修正——だけだ。


アーキテクチャ概要

AI Flowchartはサーバーレス構成で動作する。主なコンポーネントは以下のとおりだ。

  • フロントエンド:オントロジーWebアプリケーション
  • API・認証:Amazon API Gateway + Amazon Cognito
  • 取り込み:AWS Lambda(文書アップロード、S3プリサインURL、前処理)
  • オントロジーデータ作成:Amazon BedrockのFMがRDF/OWL形式でオントロジーを推論・生成
  • データストア:Amazon Neptune(オントロジーと拠点別知識グラフ)
  • 推論:HermiT(OWL 2 DL)
  • エージェント:Strands AgentsベースのエージェントがBedrockとHermiTを統合オーケストレーション

結果:フローチャート作成が10人日→0.5人日

ステップ 導入前 導入後 改善率
フローチャート作成 10人日 0.5人日 95%削減
フローチャート比較(拠点ペアごと) 0.5人日 数分 人日→分
フローチャート修正 0.5人日 数分 人日→分
合計(拠点手順1件あたり) 11人日 1人日 90%削減

さらに見逃せない副次効果がある。従来は「1拠点 vs 1拠点」のペア比較しかできなかったが、AI Flowchartでは1拠点をN拠点と同時比較できる。オントロジーが各拠点の手順を共通表現に正規化することで、従来は不可能だったポートフォリオ規模の分析がデフォルトの視点になった。

業務専門家の役割も「フローチャートを作成・比較する人」から「AIの出力をレビューする人」に移行する。この変化が90%削減を一時的な数字ではなく、新規拠点・新手順ファミリーごとに積み重なる継続的な効果にしている。

MUFGはすでに同パターンをUATテストケース作成(2026年3月開始)、要件定義書生成、知識移転自動化、M&Aデューデリジェンス、新拠点開設にも展開し始めている。


詳細はHow MUFG Bank aims to cut flowchart work by up to 90% with ontology-grounded AI on Amazon Neptune and Amazon Bedrockを参照していただきたい。