銀行勘定系システムにおける開発プロセス刷新 ×AIによる環境モダナイゼーション 2026年9月16日（水） Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

目次 1. はじめに p.3～4 2. なぜ、今モダナイゼーションなのか p.5 3. 銀行勘定系における技術的負債とは何か p.6 4. 今抱える負債を返し、新たな負債を生まない p.7 p.8 5. 既存の技術的負債を解消する取り組み p.9 6. 新たな技術的負債を生み出さない取り組み p.10～11 7. 継続的に負債を管理する仕組み p.12 8. 学びと今後の展望 p.13 生成AI活用の全体像:3つの生成AIで支える 2 

１．はじめに（自己紹介） 鎌田 礎彌（カマタ モトヤ） MUIT 流動性預金部 プロフェッショナル 2016年04月 生命保険会社 入社（情報システム部配属） 2024年10月 三菱UFJ銀行 入行（MUIT出向） 現在 3 新預為モダナイゼーションプロジェクトの推進 開発プロセス・生成AIチームのリーダー Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

１．はじめに（MUITってどんな会社?） 三菱UFJフィナンシャル・グループ（MUFG） 三菱UFJインフォメーションテクノロジー（MUIT） 三菱UFJ銀行、並びにMUFGグループ各社の IT・デジタル戦略を先導する、「金融×IT」のプロフェッショナル集団 4 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

２．なぜ、今モダナイゼーションなのか 現状のシステムは安定稼働している。しかし、”変え続ける能力”が失われつつある。 預為ホストは利用チャネル拡大の一方で、1987年の第3次オンライン時に構築したアプリケーション構造に大きな手は加えず、 継ぎ接ぎの改修を続けた結果、技術的負債が積み重なり複雑化・肥大化が進行している状況（約40年そのままの状態） 。 人材・環境の面でも制約が強まり、このままでは安全に変え続ける能力が完全に失われるリスクが高まっている状況。 時間が経つほどモダナイゼーション自体の難易度・コストは増大していく。有識者の知見を活用できる今のうちに、変え続けられる状態へと転換していく必要。 ①システムの複雑化・肥大化 ②ホスト領域のスキル継承機会の減少 ③インターフェース・開発ツールの陳腐化 ・継ぎ接ぎの機能追加により複雑化・肥大化 ・接続システム拡大により密結合 ・複雑化・肥大化により、変更難易度・コストが年々増加 ・安全に変えられなくなってきており、障害が増加傾向 ・ホスト領域の開発・保守は減少傾向 ・採用言語（PL/I）人口の低下（以下表参照） ・特定の有識者依存が高まり、近い将来にスキルロスの 可能性が高い ・インターフェースや開発ツールは⾧年変更なし ・分散では当たり前のサポートツールや自動化ツール等、 近代的な開発手法を取り入れることが困難 Python スマホ Web 店舗 利用チャネル拡大 依存関係増加 密結合 複雑化・密結合が進み、 変えるほど難しくなる モダナイゼーションの目的・本質 5 既存機能 Java 追加機能 COBOL 外部接続 アセンブリ 緊急対応・ 暫定対応 PL/I 127人(28.9%) 94人(21.4%) ⾧年変更なし TSO 旧来の開発環境 29人(6.6%) 15人(3.4%) 8人(1.8%) 表1:外部技術者の使用言語 (出典) 日経BP社 プログラミング言語実態調査2020 スキルロスが進み、 変えられる人がいなくなる 自動化 （CI/CD等） OSS活用 開発環境が陳腐化し、 変える力を進化させられない 単純に新しいシステム・技術に置き換えることではなく、 銀行勘定系を安全かつ継続的に変え続ける能力を、組織として確立すること Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 生成AI 

３．銀行勘定系における技術的負債とは何か 古いこと自体が負債ではない。 “変えるためのコストとリスク”を増大させるものが、技術的負債である。 ⾧年利用していること ＝ レガシー ✓ 安定稼働・高い信頼性 ✓ 業務ノウハウの蓄積 ✓ ⾧年の運用実績 変更を阻害する状態 ＝ 技術的負債 ・影響調査が膨大で時間がかかる ・特定の人しか変更できない ・テスト／リリースに多大な工数 ・不具合・障害リスクが高まる 技術的負債 ＝ 変更コスト・変更リスクを増大させる要因 合理的な判断も環境変化によって負債に変わる 当時 その後 （環境変化） 現在 （負債化） 業務要件への 迅速な対応が 最優先 チャネル・商品・ 接続先の拡大 複雑化・属人化・ 陳腐化が進行 預為システムで実際に起きていること（負債が絡み合う状況） ①アプリケーション構造の負債 ・機能追加、流用の積み重ね ・責務境界の曖昧化 ・デッドロジック ・機能間の繋がりが複雑化 システム構造が複雑 （影響範囲が読めない） ②技術・開発環境の負債 ・開発支援ツール・環境制約 ・自動化・標準化が困難 ・調査・開発が人手中心 効率的に対応できない （調査・変更に時間がかかる） ③知識・人材の負債 ・設計書情報・背景・意図不足 ・有識者の暗黙知に依存 ・スキル継承機会の減少 （ホスト修正機会の減少） なぜそうなっているのかわかる人がいない （理由・意図がわからない） 構造・環境・知識の負債が複雑に絡み合うことで、変更のたびに「調査・判断・テスト」という新たな負債が発生。 変更コスト・変更リスクを増大させている。 6 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 変更時に払う新たな負債 ・影響調査の⾧期化 ・設計・テスト範囲の拡大 ・有識者への確認が必須 ・手作業・証跡作成の増大 ・障害リスクの増大 

４．今抱える負債を返し、新たな負債を生まない 技術的負債への対応は、「今抱える負債を返す」だけでは終わらない。 既存負債を減らしながら、新たな負債を生み出さない仕組みへ転換する。 ① 既存の負債を返す（減らす） ② 新たな負債を生み出さない（増やさない） 構造・環境・知識の負債を解消し、変更しやすい状態へ 仕組みと文化を変え、負債を生まない開発を継続する 現状を理解する STEP １ 生成AI STEP 2 STEP ３ 開発プロセスに標準・品質管理を組み込む ・生成AIを活用した資産の可視化 ・資産・依存関係・業務ルールを可視化 ・影響範囲の把握にかかる時間を短縮 可視化AI 責務を整理する ・ホスト／分散、オンライン／バッチの線引き ・システム間の役割・責務を再定義 ・共通処理・インターフェース・データの境界を明確化 段階的に再構築する ・優先順位を付けて改善対象を選定 ・複雑な構造・デッドロジックを解消 どこを変えると、 どこまで影響するか どこに何を 持つべきか 運用中 ・Git／ブランチ運用、レビュー・証跡管理 ・VSCode、自動ビルド・テスト 一度きれいにする から “きれいな状態を 維持できる”へ 試行中 設計知識・根拠を明確に残す 対応中 ・設計意図・背景・判断理由を記録 ・コード・設計書・データ定義を一体管理 対応中 生成AIで標準・設計知識を開発に適用する ・標準・規定・設計知識に沿って成果物を作成 ・規定準拠・不整合等を生成AIで一次確認 負債を返済し、 システムを シンプルに 開発者AI 継続的に負債を計測する ・複雑度・テスト容易性・変更頻度等を計測 ・可視化し、閾値で検知・改善 変更コスト・変更リスクを減らす 計画段階 標準を仕組 みで担保 知識を資産 として蓄積・ 継承 標準・知識に 沿った開発を 継続 負債増加を 早期に検知・ 抑止 ③ 継続的に負債を管理する（PDCAを回す） 可視化・計測 負債の状態を定期的に 可視化・計測する 全体戦略 7 優先順位付け ビジネス価値・リスク・コス トで優先順位を決める 改善（返す／抑制する） 既存負債の返済と、新 規負債の抑制を並行 再計測・レビュー 効果を確認し、計画と施 策を継続的に見直し ガバナンス・組織体制 責務・意思決定・ルール を整え、全社で取り組む 「返す」と「増やさない」を両輪に、継続的に負債を管理できる開発能力へ転換する 変更を恐れず、価値を継続的に生み出せる預為ホストを実現する Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

生成AI活用の全体像:3つの生成AIで支える 生成AI活用は単独の施策ではなく、 モダナイゼーション（＋今後の預為開発）を加速させ成功させるための施策。 ①現状把握を支援するAI（可視化AI） ②知識継承を支援するAI（有識者AI） ③開発・レビューを支援するAI（開発者AI） 現状を理解する 知識を「判断に使える」ようにする 安全に「実装する」 ・設計書、過去の変更理由、障害対応、 FAQを検索・参照 ・有識者の判断根拠・経験知（暗黙知）を 再利用可能にする ・背景・関連・影響を踏まえた判断を支援 ・ソースコード、データ、ジョブ、設計書の 関係を解析 ・依存関係、業務ルール、変更影響を可視化 ・有識者の調査を置き換えず、調査の初速と 網羅性を高める 複雑な現行資産を、人が理解できる情報へ 預為知識基盤 ソースコード・データ 設計書、仕様書、 業務ルール、方針 ・影響範囲を調べて ・この実装経緯は? ・プログラム実装して 生成AIの活用目的 8 指示 修正経緯 変更履歴、理由、 バージョン情報 プログラム、データ、 バッチ、設定情報 設計思想、判断根拠 障害・トラブル事例 有識者の経験知 設計の背景、経緯、 判断理由、意図 障害対応・原因・ 再発防止策 ナレッジ、ノウハウ、 FAQ、Q&A 根拠をもとに回答 検索 預為AIポータル 生産性と品質を高め、新たな負債を生まない 暗黙知を形式知へ変換し、知識を継承・活用 仕様・設計 自然言語で依頼 ・コード、テスト、ドキュメントの作成を支援 ・アーキテクチャ標準・コーディング規約の準拠確認 ・資料フォーマット・記載内容の一次レビュー 理解 読む 預為AIエージェント群 判断 たどる つなぐ 実装 作る 期待効果 モダナイズの加速 保守迅速化 品質強化 属人化解消 AsIs分析→ToBe設計 の自動化 影響調査・分析の 大幅短縮 開発レビューの 効率最大化 暗黙知を組織知 として標準化 “人の判断を代替する”のではなく、“人がより早く・広く・深く理解し、良い判断をする”ための支援策。 モダナイゼーションを安全かつ迅速に遂行、“変え続ける能力”を取り戻す Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

５．既存の技術的負債を解消する取り組み 複雑な現行資産をAIで解析し、“人が理解・判断できる情報”へ変換する。 （有識者の調査・判断を置き換えるのではなく、調査の「初速」と「網羅性」を高める） インプット｜複雑な現行資産 預為知識基盤 人が一つひとつ読み解くには、 調査範囲が広く、関係性も複雑 ソースコード 大量のプログラム、共通機能が複雑に連携 データ ファイル、DB、項目定義、データ連携が多岐に存在 設計書・仕様書 設計意図・業務ルール・処理仕様が文書化されて いなかったり、あっても分散されていたりする 調査に時間がかかり、全体像をつかみにくい アウトプット｜人が理解できる情報に変換 現行資産・知識を吸収し、体系化して蓄積 仕様・設計 ソースコード 修正経緯 設計思想 調査結果を構造化・可視化し、人が理解できる状態にする 依存関係の可視化 プログラム等の依存関係を可視化 有識者の経験知 設計書、仕様書、 プログラム、データ、 変更履歴、理由、 設計の背景、経緯、 ナレッジ、ノウハウ、 判断理由、意図 業務ルール、方針 バッチ、設定情報 バージョン情報 FAQ、Q&A 業務ルールの可視化 業務ルール・条件・例外を整理して可視化 変更影響の可視化 ある変更がどこに影響するかを可視化 可視化AI 情報を読み解き、関係づけ、可視化する ①読む（解析） ②関連づける ③可視化する 現行資産を読み解く 依存関係やルールを抽出 人が理解できるよう変換 有識者AI・開発者AIとも同じ基盤を共有 処理フローの可視化 取引の流れ・条件分岐をシーケンス図で表現 全体像がつかめ、判断の質・スピードが向上 可視化AIの成果物例（既存取引のシーケンス図と処理説明）※現行保守資料には存在しないもの 可視化AIの役割 9 複雑なソースコードが、人が読める状態に Before（ソースコード） After（可視化後） ・関係性が見えない ・調査に時間がかかる ・見落とし、漏れが発生 ・全体感が一目でわかる ・判断精度、スピードが向上 有識者の調査・判断を置き換えるのではなく、 調査の「初速」と「網羅性」を高め、人が判断できる状態をつくる。 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

６．新たな技術的負債を生み出さない取り組み 新たな負債を生まないために、開発を「人の注意」に、設計知識を「人の記憶」に依存させない。 （開発プロセスの標準化・効率化と、設計意図・判断根拠の形式知化を一体で進める） ①変更を「仕組み」で守る 人の注意に依存した開発 → 仕組みによる品質確保 ②判断を「知識」として残す 人の記憶に依存した設計 → 判断根拠まで組織資産化 AsIs インプット ・開発環境・ツールの制約により、変更管理・自動化等を 仕組み化できていない ・変更内容・変更理由の記録が担当者に依存 ・レビュー観点・確認内容が担当者の知識・経験に依存 ・ビルド、テストが手作業前提 コード 設計書 ①共通環境 ②変更管理 ③レビュー ④自動確認 ⑤承認・リリース VSCode等 git （VSCode） マージリクエスト （レビュー依頼） ビルド・テスト・ 品質確認効率化 承認・証跡管理・ リリース ・なぜこの検討をしたのか ・なぜこの案を採用したのか なぜこの設計にしたのかが、 誰でも把握できる 10 設計判断 設計知識の一元管理 ToBe 目指す姿 アーキテクチャ ・検討案と各案のメリデメ ・採用した案は何か 次の案件で判断根拠の 再利用が可能となる “どう変えたか”と“なぜそうしたのか”を組織の資産として残し、再現可能で知識が蓄積される開発へ転換する ことで、新たな負債の発生を抑止する。 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

６．新たな技術的負債を生み出さない取り組み 生成AIをプロセスに組み込み、人は判断することに集中する。 そのため、生成AIの利用範囲・品質・責任を継続的に管理する。 ①生成AIを開発プロセスに組み込む ②安心して使うために、生成AI自体も管理する 開発の標準・知識（インプット） ①利用範囲と責任分解 何を生成AIに任せるか、人が担うか 設計書・保守文書 アーキテクチャ規定 Know （知識を参照） Create （AIと作る） 標準・設計知識・ 過去事例を参照し、 状況を理解する コード・テスト・ ドキュメントのドラフト を作成 生成AIが担うこと 作成・定型確認・一次レビュー支援 目指す姿 11 過去事例・ 変更履歴 開発標準・ コーディング規約 Check （一次確認） 資料フォーマット Judge （人が判断） 規約・規定への準拠、 設計・リスク・例外等 フォーマットの内容等を を確認し、最終的に 生成AIが確認 リリース・承認判断 人が担うこと ⑤変更時の再評価 ②データの取り扱い モデル・skills変更後も品質を 維持できるか確認 利用範囲を限定（必ずローカル） 外部AIの利用も禁止 生成AI活用 ④根拠・履歴管理 ③生成AI出力の評価 生成AIの入出力をログで管理し、 後から追える状態を作る 期待した品質かを評価し、基準に 満たない場合は改善 設計判断・リスク判断・最終承認 標準と蓄積した知識を生成AIでも活用し、「作る・確認する」を効率化。 人は判断・承認に集中することで、開発の生産性・品質を高め、新たな負債を抑止する。 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

７．継続的に負債を管理する仕組み 負債をゼロにするのではなく、負債を「把握し、判断し、コントロールできる」状態へ。 基本方針 技術的負債の管理サイクル アーキテクチャからの例外管理 見える化する どの負債が、どこにどの程度あるのか ①可視化する 優先順位を決める 例外が発生 例外申請 案件事情等で標準 理由、影響等を に準拠不可のケース 明確にして申請 ・負債の所在を把握 ・発生経緯、背景を記録 ビジネス影響、変更リスク等から判断 管理する 例外は台帳で 一覧管理 解消する 計画的に解消して 負債を返済する 改善する 開発案件内で改善、施策で改善 ④振り返る 振り返る 改善の効果をモニタリングし、評価 ・ビジネス影響（リスク等） ・変更リスク、コスト 負債を可視化し・ 判断でき、改善 生成AI利用 できる状態 ガバナンス ②優先順位を決める ・ビジネス影響（リスク等） ・変更リスク、コスト 記載項目例）  例外内容（どこがどう例外か）  例外理由（なぜ標準から逸脱するか）   承認者 承認者コメント 継続する 上記を繰り返し、負債をコントロール 開発案件と負債返済のバランス 日常の中で返済 常に意識して案件対応の中で返済 ③改善する ・ビジネス影響（リスク等） ・変更リスク、コスト 一定規模以上は案件化 案件のなかでついでにできないレベルであれば、 案件化して計画的に返済 目指す姿 12 誰が管理するか 開発チーム アーキテクト 管理者・責任者 ・日々の開発で負債を 発見・記録 ・例外を申請・説明 ・負債の影響を分析・評価 ・設計方針との整合判断 ・優先順位を判断 ・投資対効果を判断 ・案件とのバランス調整 ・優先順位の最終判断 “返す／生まない” を継続的な意思決定プロセスにする。 負債を把握し、適切に判断・改善し続けることで、変化に強く、⾧く価値を生み続けるシステムを実現する。 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

８．学びと今後の展望 モダナイゼーションは単なる“プロジェクト”ではなく、 銀行勘定系を安全かつ継続的に変え続ける能力を、組織として確立すること ①システムだけ新しくしても、負債はなくならない システム 技術 一体で 変える プロセス 知識 組織 ②生成AIは人を置き換えるものではない ③一度キレイにしても、新たな負債は発生する 人がより早く・広く・深く 理解し、判断するために、 “変える力”を拡張する システム・技術だけでなく、 プロセス・知識・組織を 一体で変える 負債をゼロにするのではなく、 把握・判断・コントロール し続ける 変え続けるための実践サイクル ①Understand（理解） ②Decide（判断） ③Change（変更・実装） ④Learn（学習と蓄積） 複雑な現行資産を、 人が理解できる状態へ あるべき設計を 判断できる状態へ 標準化されたプロセスで、 安全に変更できる状態へ 変更結果から学び、 次の変更へつなげる 開発プロセス／開発者AI 継続的な負債管理 可視化AI／有識者AI 設計方針／設計知識 既存負債を 返す 目指す姿 13 ＋ 新たな負債を 生まない ＋ 継続的に 管理・改善 負債をゼロにするのではなく、把握・判断・コントロールしながら、“変え続ける能力”を組織の力にする。 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

免責事項 本プレゼンテーションにより、視聴者と三菱UFJインフォメーションテクノロジー株式会社の間には何ら委任その他の契約関係が発生するものではなく、 当社が一切法的な義務・責任を負うものではありません。 本資料は信頼できると考えられる各種データに基づいて作成されていますが、当社はその正確性、完全性を保証するものではありません。 ここに示した全ての内容は、当社の現時点での判断を示しているに過ぎません。 また、本資料に関連して生じた一切の損害については、当社は責任を負いません。 その他専門的知識に係る問題については、必ず貴社の弁護士、税理士、公認会計士等の専門家にご相談のうえでご確認ください。 14 Copyright(C) 2026 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 

ご清聴ありがとうございました。 三菱UFJインフォメーションテクノロジー株式会社 流動性預金部 〒164-0001 東京都中野区中野4-10-2 中野セントラルパークサウス https://www.it.mufg.jp/