MUFGのAI PoCを再建したオントロジー×ナレッジグラフ活用 非IT部門が2万件の知見をデータ化
マニュアルの言葉を“AI-Readyなデータ”に。あいまいさを排除した次世代コンテキスト構築
難航するPoCプロジェクト……停滞中に見つけた突破口
当初、AIフローチャートを利用した標準化への期待は大きかった。浮いた時間を関係者協議に使えるだけではない。手作業では1対1の比較しかできなかったが、本部と拠点および拠点間の「1対n」の比較が可能になる。
2024年9月に行われた部内の生成AI活用ブレーンストーミングで、PoC立ち上げ第1号案件として採択された。2025年1月からPoCを開始し、プロトタイプを構築するまでは順調だったが、早くも3月ごろから先行きが危ぶまれるようになってきた。プロンプトや各拠点の手続きの記述内容を誤って理解したり、不正確なフローチャートができたりといった品質不良に悩まされるようになったのだ。
これでは拠点間の比較に利用できない。出力品質を担保するための突破口を探して複数のコンサルティング会社に相談したものの、ほとんどが難しいという結論になったという。しかし、唯一可能性を示したのがAWSだった。
溝口氏は「最初はちょっとした会話から始まり、AWSから具体的な計画を提案してくれた」と話す。同氏はこの時にオントロジーやナレッジグラフの存在を知ったという。
生成AIのみを用いた標準化から方向転換し、「オントロジー×ナレッジグラフ」を取り入れたPoCを開始したのが、2025年6月のことであった。オントロジーといえば、パランティアの中核的テクノロジーとして知られるようになってきたが、三菱UFJ銀行での理解は図2に示すようなものだ。
[クリックすると拡大します]
「オントロジーはデータの設計図で、ナレッジグラフは実際のデータベースと私たちは解釈している」と溝口氏は説明する。取り組みが比較的スムースに進んだのは、本部の事務マニュアルの内容がオントロジー、各拠点の事務マニュアルの内容がナレッジグラフとそれぞれ望ましい粒度だったことも幸いした。本部と拠点間の事務マニュアルのギャップが標準化をする上での長年の壁だと考えてきたが、実はLLMに与えるコンテキストエンジニアリングの材料として理想的な状態だったのだ。
これらを“設計図”として標準化し参照することで、拠点間の比較ができるだけでなく、以前はできなかった拠点同士の手続きの比較も容易になる。また、この2つを利用すれば、拠点固有の手続きの中から設計図をアップデートする材料も得られる可能性が見えてきた。
6ステップで「オントロジー×ナレッジグラフ」を構築
方向転換後のPoCプロジェクトで最初に行ったのが、事務マニュアルに書かれている文章を「SPOトリプル(以降、トリプル)」と呼ばれるデータモデルに変換することだ。トリプルとは、文章を主語(Subject)、述語(Predicate)、目的語(Object)の3つの要素に分解し、AIやデータベースで情報を管理・検索しやすくするデータモデル。たとえば、「担当者は送金データを登録する」という文章は、「S:担当者」「P:登録する」「O:送金データ」というトリプルに変換できる。この例では、英文法の「SVO」構造に似ているが、トリプルの3要素の意味は以下のように文法用語とは異なることに留意したい。
- 主語:概念
- 述語:主語と目的語の関係性を表す矢印的なもの
- 目的語:概念あるいは具体的な値
トリプルはどのような文章でも厳格に3つの要素に分解できるため、AIにとって曖昧さがなく、正確な推論が可能になる。これはAWSのエキスパートによるアイデアを採用したもので、英語で書かれたドキュメントをインプットとし、トリプルの案をAIに作成してもらったという。
しかし、その結果をそのままオントロジー構築に流用はできない。たとえば、「All payment information must be input as per the applicant’s application without any omission」という文章をトリプルに変換すると、AIは2つのトリプルを出力する。1つは「Payment information」「Be put as per」「Application」、もう1つは「Payment information」「Without」「Omission」である。前者のトリプルは問題ないが、後者のトリプルの主語「Payment information」は、人間が読む文章の主語としては正しくてもトリプルの主語としては誤りとなる。このトリプルの主語は「Application」に修正する必要があるのだ。
修正だけでなく、場合によっては空欄も補充しなくてはならない。たとえば、「Booking entries must be completed before authorization of the payment order…」という別の文章をAIに与えるとする。AIが「Booking entries」「空欄」「Payment order」というトリプル案を出力した場合は、空欄のPを「Precede」で補う。述語の選び方は重要で、ちょっとしたコツが必要になるという。
さらに、例ではPだけがないが、SPOの3つ全てがないこともあるという。こうした情報は専門家にとっては当たり前のもので事務マニュアルに書かれてはいないが、組織として共有するべき知見である。こうした場合は、新しいトリプルを書き起こして追加することで、2万件のトリプル準備に約1ヵ月を費やした。
このようにAIが出した案を精査していった結果、できたトリプルは約2万件に上る。行内だけで整備したすべてのトリプルを集約し、AWSのサポートを得てオントロジー構築とナレッジグラフへの展開を行ったという。特筆すべき点は、図3の6つのステップのうち、2番、3番、5番を三菱UFJ銀行だけでやり切ったことだ。
[クリックすると拡大します]
この記事は参考になりましたか?
- 冨永裕子の「エンタープライズIT」アナリシス連載記事一覧
-
- MUFGのAI PoCを再建したオントロジー×ナレッジグラフ活用 非IT部門が2万件の知見...
- 画面を譲っても主導権は渡さないセールスフォースの戦略 「AIハーネス」に見出した勝ち筋とは
- AIforceだけでない、「Dreamforce 2026」で明かされたAgentforc...
- この記事の著者
-
冨永 裕子(トミナガ ユウコ)
IT調査会社(ITR、IDC Japan)で、エンタープライズIT分野におけるソフトウエアの調査プロジェクトを担当する。その傍らITコンサルタントとして、ユーザー企業を対象としたITマネジメント領域を中心としたコンサルティングプロジェクトを経験。現在はフリーランスのITアナリスト兼ITコンサルタン...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア

