
三菱UFJインフォメーションテクノロジー株式会社
R&D部
尾根田 倫太郎さん
2011年にMUITに新卒入社。インフラ部門を経て、16年から現部署。生成AI、ブロックチェーン、XRなどの幅広い新技術の銀行業務への適用リーダーを担当
【PR】 ITニュース
日本は技術で勝って、ビジネスで負けるーーそう言われるように、技術開発では先行しつつも、事業化で遅れを取り海外企業の後塵を拝した例は少なくないだろう。
また、現実世界の課題に直結しない研究開発(R&D)はビジネスとして成り立たず、企業としての競争力を示しづらい。
そんな中、高いセキュリティーレベルが求められる金融業界で、新技術のビジネス実装を可能としている集団がいる。三菱UFJインフォメーションテクノロジー(以下、MUIT)のR&Dチームだ。
同部署では、まだ世界的にも例の少ない「ソフトウエア開発の結合テスト工程での生成AI活用」を実現。独自のプロンプトを編み出し、特許申請に至るまでの技術を確立した。
一体どのようにして、最新技術の研究とビジネス実装を両立しているのだろうか。その環境で働くことで、エンジニアにはどのような影響がもたらされるのか。部門リーダーの尾根田 倫太郎さんと清宮佑太さんに聞いた。
三菱UFJインフォメーションテクノロジー株式会社
R&D部
尾根田 倫太郎さん
2011年にMUITに新卒入社。インフラ部門を経て、16年から現部署。生成AI、ブロックチェーン、XRなどの幅広い新技術の銀行業務への適用リーダーを担当
三菱UFJインフォメーションテクノロジー株式会社
R&D部
清宮佑太さん
2024年にMUITに中途入社。流通系(小売、卸)のユーザー系IT企業でシステム開発やシステム保守を経験後、MUITのR&D部に着任。「生成AIを活用したEnd to End(E2E)テストコードの自動生成」を担当
ーーR&Dの成果で事業貢献できている企業は、決して多くない印象です。その理由は何だと考えますか?
尾根田:そもそも、新技術は全てが良いものとは限らず、活用すべきものもあれば手を付けるべきでないものもあります。その見極めが難しいことが、一因ではないでしょうか。
加えて「この新技術は新機能の実装に活用した方が良い」と思ってPoC(概念検証)を進めても、その過程で課題が発覚することは少なくありません。たとえPoCが成功しても、本番利用を想定した開発段階で新技術の導入が難しくなるケースもあります。
ーーそのハードルを越えられる技術を「目利き」することが難しい、と。
尾根田:はい。PoCの範囲では本番環境の課題を全て洗い出せませんからね。
PoCはスモールスケールのデータや限定的な環境での動作確認が中心ですが、本番環境はデータ量やトランザクションの規模が大きいため、処理性能が足りなくなることがあります。銀行システムのように1秒間に何千件もの処理が必要な環境では、PoCで問題なく動いていた技術が本番ではスケールしないことがよくあるんです。
清宮:技術の評価にはビジネス視点が不可欠であることも、目利きを難しくしている要因だと思います。R&Dの成果で事業貢献するためには、運用コストやスケーラビリティー、組織への影響、さらには法規制といった要素まで考慮する必要があるからです。
例えば、「銀行がパブリックブロックチェーンを活用できるか?」といった議論では、技術的には可能でも法律や業界規制が障壁となる場合があります。「個人や企業の信用リスク評価へのAI活用」を目指すケースでも、アルゴリズムの透明性や公平性が法規制の基準を満たさなければなりません。単に「精度が高いから使おう」という発想では、実際のビジネスの中で問題が発生する場合があるのです。
ーーエンジニア視点で見れば『良いもの』でも、ビジネス全体で見ると『使えない』こともあるわけですね。
尾根田:その通りです。だからこそMUITのR&D部では、「手を付けるべきではない新技術」もあると考えています。「新しい技術だからどんどん適用しよう」とR&Dを進めてしまうと、むしろ事業に悪影響を及ぼしかねません。
それこそ「ブロックチェーンが金融業界を塗り替える」と言われて久しいですが、われわれがリサーチしPoCをした結果、現時点では適用が難しいと判断しました。
ブロックチェーンは高い信頼性を持つ一方で、データの書き込みに時間がかかるため、リアルタイム処理が求められる金融業務には適さないケースがあります。また、分散型の仕組みを維持するために膨大なサーバ台数が必要となり、従来の中央集権型システムと比べて運用コストが大幅に増大することも分かりました。
ところが、市場では「とにかくブロックチェーンを活用しよう」という流れがまだまだ続いていますよね。技術が好きな人ほど、新しい技術が登場すると「これは使えそうだ」とすぐに本番適用を想定しがちです。 しかし、むやみに適用された新技術は技術的負債にもなりやすく、将来的な開発や運用のコストを引き上げる要因になり得えます。
技術に対する色眼鏡を外し、「新しいから反射的に本番適用する」のではなく、自分たちでPoCを行い技術の本質を見極めて「本当に自社の事業にとって価値があるのか」を徹底的に分析することが、真に価値あるR&Dへの第一歩だと思います。
ーー色眼鏡を外して技術を見極めるために、MUITのR&D部ではどのような取り組みを行っていますか?
尾根田:PoCで判断すべき項目を洗い出し、各項目に明確な基準を設けてスコアリングできる「評価チェックリスト」を作成しています。「新規ビジネスへの貢献度」「本番化後の効率化効果」「他技術と比較した優位性、持続性」「他企業での利用度、緊急度」「仮説、検証のゴールの明確度」「会社としての開発・運用の継続性」「実用化までの予想期間」の7項目があり、属人的な判断に頼らず、統一された基準で技術の評価が行えるようになっています。
【評価基準】 | 【評価観点】 |
---|---|
新規ビジネスへの貢献度 | 新たなビジネスの開拓による価値創出や、先細り技術からの脱却によりシステム都合で困難であった要件への対応が可能となるかなど、価値貢献の度合いを評価する。 | 本番化後の効率化効果 | ユーザー部門の業務やシステム開発・運用等に対するコスト削減、在籍人数削減、生産性向上などへの寄与度を評価する。 |
他技術と比較した優位性、持続性 | 従来技術と比較した技術的な優位性や、その技術が長期に渡り世の中で使われるかどうかを判断する。 | 他企業での利用度、緊急度 | 他の企業にてPoCや本番環境で利用されている普及度合いを評価。後から他社に追いつくことができないと予想される緊急性があるか否かについても確認を行う。 | 仮説、検証のゴールの明確度 | 何が不確定要素で何を検証・証明できれば本番利用が可能と判断できるか、本番化に向けたゴール基準の明確度を評価する。 | 会社としての開発・運用の継続性 | 開発部と協業・引継ぎを行うことで、会社としてその技術の適用・利用をスケールアウトしていくことができる可能性の度合いを評価する。 | 実用化までの予想期間 | 本番システムへ適用できるまでに、検証に必要と思われる期間を評価する。 |
このフレームワークが生まれた背景には、MUITのR&D部門が10年以上にわたって試行錯誤を重ねてきた歴史があります。
三菱UFJ銀行の前身となる三行の合併以前から存在していた研究開発チームがルーツとなっており、当初は技術に精通した有識者たちが、それぞれの専門知識に基づいて新技術の検証を行っていました。しかし、研究開発部門が拡大するにつれ、技術評価の基準や視点にばらつきが出始めたのです。
最初は5人ほどだったチームが10人、20人と増えていく中で、「この技術の検証は本当に必要だったのか?」「この観点で見れば明らかに使えないのに、なぜPoCを始めてしまったのか?」などの課題と直面するケースが増えてしまって……。
ーー技術の評価が不十分なまま「新しい技術を●●に適用すること」自体が目的になってしまったんですね。
尾根田:そうなんです。ディープラーニングが注目され始めた頃、「何としてもAIを適用しなければならない」という空気が先行し、本来不要な場面で無理にAI技術を導入してしまったプロジェクトがありました。
こうした反省から「技術評価の質」を向上させる必要があると考え、全員が同じ基準でPoCの判断を行えるようにする仕組みを作り上げました。
清宮:ただし、冒頭で尾根田が申したように、PoCが成功したからといってそのまま本番環境で運用できるとは限りません。PoCが終わった後も、「ビジネス環境での検証作業」を継続することが不可欠です。その際には「データ量」「トランザクション負荷」「可用性」の三点を特に注視しています。
【対象】 | 【確認点】 |
---|---|
データ量 | PoCの規模感では問題なく動作していた技術でも、本番環境の膨大なデータ量に耐えられるかを確認する。 | トランザクション負荷 | 処理速度や並列処理能力を本番環境レベルで試し、遅延やボトルネックが発生しないかを検証する。 |
可用性 | 特にAI技術は可用性が低いと本番環境での運用が難しくなるため、継続的な安定動作を確保できるかを確認する。 |
ーーでは、MUITのR&D部の代表的な研究開発事例を教えてください。
清宮:直近の代表的な事例としては、「生成AIを活用したEnd to End(E2E)テストコードの自動生成」 があります。
テスト工程は、どの企業でも非常に工数がかかる部分ですが、品質を担保するためには削ることができません。そこで、テストコードを生成AIに作らせることができるかを検証し、品質の維持と工数削減の両立を目指しました。その結果、これまで人力で行っていた作業の約半分を自動化できることが確認されたんです。
プロンプトの作成には特に力を入れており、まだ世の中に出ていないような独自のプロンプト手法を編み出すことに成功したので、現在は特許申請を進めています。
尾根田:テストコードを生成する際の指示文や注意点をまとめたガイドラインを行内の公式ドキュメントとして統一することで、属人化したノウハウを解消し、複数のプロジェクトで活用できる仕組みも確立しました。
近年、生成AIを活用してソフトウエア開発を効率化する試みは増えていますが、その多くはコーディング作業を支援するもの。テスト工程に生成AIを適用する取り組みは世界的にも事例が少ないので、一歩先を行くアプローチができたといえるでしょう。
ーーとりわけ高い堅牢性が求められる金融システムで、テストコードの自動生成を実現するには、多くの課題があったのではないでしょうか?
尾根田:はい。日本の金融システムは、海外のそれと比べても特に高い信頼性を求められます。例えば、海外では「システムが一日落ちる」ことも珍しくありませんし、毎朝銀行の入出金明細をチェックして自分の口座からお金が盗まれていないかを確認するのが一般的な国もあるようです。
しかし、日本では「銀行のシステムは常に安定していて当たり前」という意識が根付いていますよね。その信頼に応えるため、日本の金融システムではエラーや誤送金を極限まで防げるような耐障害性を追求する必要があります。
ーー今回のプロジェクトには、その「システム品質」に対する姿勢が表れているわけですね。
尾根田:システムのあらゆる画面に対して「ユーザーが意図しない操作をした場合どうなるか」「ここに変なデータが紛れ込んだらどう動くか」など、さまざまなケースを想定したテストを繰り返し実施しており、場合によってはテストだけで2~3年をかけることもあります。
まだ人の手による修正が必要な部分もありますが、一定の品質をAIで担保できるようになったことは大きな成果です。中には、人が作成するよりも品質の高いテストコードが作成できる領域も出てきました。高い信頼性が求められる金融システムの中で、生成AIの活用がここまで進んでいること自体が、非常に意義のある取り組みだと考えています。
ーー「研究」にとどまらず「実装」にもつなげられているR&D部があることは、企業にとって大きな強みとなりそうですね。
尾根田:研究から実装までワンストップで手掛けるチームが社内にあると、自社の業務やシステムに適した技術かどうかを冷静に判断できます。技術的負債を最小限に抑え、適用すべき技術を適切に見極めることができ、結果的に開発のスピードアップや効率化を実現できる可能性が高まります。
一方で、新技術をリサーチ・研究・開発するチームが社内にない企業では、技術の新陳代謝を外部からの提案に頼るしかありません。 自社の業務ドメインや既存システムのアーキテクチャを考慮した適用ができず、技術のミスマッチが起こるリスクが高くなります。適切な技術選定ができず、結果的にシステムが負債を背負ってしまい、市場競争力を失いかねません。
ーー事業貢献につながるR&Dを経験することで、エンジニアのキャリアはどう好転するとお考えでしょうか。
清宮:エンジニアにとっての最大のメリットは、「自分の研究成果がビジネスに貢献していることを実感できる」ことだと思います。
大学や研究所では、論文を書いたら研究が完了することも多く、「自分が研究している技術が具体的に何の役に立つのか分からないまま進める」というケースもあります。 しかしMUITでは、新技術の適用先が明確で、研究成果が実際にお客さまに使われるアプリケーションへとつながっていく。それを感じられることは、エンジニアにとって大きなやりがいです。
今の時代は、技術をただ知っているだけでは不十分で、「その技術をどう適用するのか?」を考えられるエンジニアが求められています。技術だけを追求するエンジニアは、AIの発展に伴って今後どんどん価値が低くなってしまうでしょう。そういった意味でも、MUITのR&D部での経験は今後のキャリアにおける大きな財産になると感じています。
尾根田:MUITのR&Dには、新技術をどう活用すべきかを徹底的に考えながら、実際に手を動かして試行錯誤できる環境があります。
また私たちは特定の技術ベンダーに依存せず、多様な技術を比較・検討しながら、グローバルな視点で最適な選択を行います。そのため「所属企業がソフトウエアAを推奨しているから、それしか知らない」といった偏りは生まれません。競合となるソフトウエアBやCにも触れながら、広い知見を持ち、技術全体を理解できるエンジニアへと成長できます。
単に知識を蓄えるだけでなく、その技術をどう活かすかを考えて実践することが求められる時代です。新しい技術に触れ、それを使って何ができるのかを模索する。その試行錯誤の中でこそ、エンジニアは本質的に成長していくのではないでしょうか。
撮影/竹井俊晴 取材・文・編集/今中康達(編集部)
NEW!
タグ