生成AIで互換性の調査時間を約65%削減した三井住友銀行の実証実験

生成AIの担当範囲を、技術文書から非互換の情報を拾い出す工程に絞り込んだ設計が、まず効いていると考えられます。バージョンアップ対応は、情報の抽出、影響範囲の判断、修正、動作確認と、性質の異なる作業が連なる仕事です。そのうち文書の読み込みは、量が膨大なわりに探すものの型が定まっている部分であり、機械に向いた領域を先に切り出した格好になります。担当範囲が明確であれば、人がAIの出力を確かめるときの観点も、抜けと誤りの有無という一点に定まります。

抽出した非互換情報を、C言語とbashシェルで書かれた約380キロステップ規模のアプリケーションに突き合わせ、影響箇所の特定まで一続きの工程として扱った点も見逃せません。一般的な変更点の一覧を手にしても、それが自社のどのコードに刺さるのかが分からなければ、結局は人が全量を追うことになります。自社の資産に接地させて初めて調査が前に進むという順序を、工程の組み立てに反映させた設計だと読み取れます。

検証と実行を分け、抽出の品質を見極めてからソースコード修正へ適用範囲を広げる段取りも、この領域では理にかなっています。止められないシステムを相手に、いきなり修正まで任せる進め方は取りにくい。加えて、システム開発を担う日本総合研究所と、生成AIを組み込んだ独自システムを開発した富士通が組む体制は、業務側が持つ勘所とAI側の作り込みを一つの検証の中で突き合わせられる形になっています。