ソニー銀行が、稼働中の勘定系システムの実開発に生成AIを適用し、開発期間を30%短縮したと発表しました。この記事では、生成AIでシステム開発の期間短縮はどこまで現実的か、何が前提条件になるのかを、受託開発とAIエージェント事業を手がける立場から読み解きます。
要点(事実のみ)
- ソニー銀行は2025年9月から富士通とともに、稼働中の勘定系システムの実開発に生成AIを適用している。
- Amazon Bedrock上で、ClaudeとClaude Codeを中核とするAIエージェントを使っている。設計書・ソースコード・テスト資産をAIが工程横断で使える仕組みを作り、前工程の成果物を後工程で再利用する(設計書からソースコードやテストケースを生成するなど)。
- 2026年7月時点の成果は、開発期間30%短縮・工数40%削減。工程別では、基本設計の影響調査工数が最大90%削減、詳細設計の設計書作成工数が最大40%削減、製造工程のソースコード生成率が99%、結合テストのテスト実行工数が最大90%削減。
- 人が最終判断と品質保証を担う体制である。勘定系は「Fujitsu Core Banking xBank」で、AWS上のマイクロサービス構成のため生成AIサービスと連携しやすい。
- 今後は要件定義を含む開発工程全体、セキュリティや運用・保守などの非機能要件、周辺系システムへの展開を予定している。
徐 聖博の見解
大事なのは「PoCではない」こと
私がこの発表で最も重く見ているのは、数字の大きさより「本番稼働中の基幹システムの実開発」で出た数字だという点です。生成AIで開発が速くなるという話は、デモや新規の小さなアプリでは珍しくありません。止められない勘定系で、人が最終判断と品質保証を持ったまま工程に組み込み、工程別の削減率まで開示した事例は、評価の質が違います。研究出身の人間として言うと、「何を分母にした削減率か」「どの条件で再現するか」まで示されてはじめて、意思決定に使える数字になります。
90%は「AIが賢いから」ではなく「成果物がつながっているから」
影響調査90%減、コード生成率99%という数字だけを持ち帰ると、読み違えます。記事が書いている仕組みは、設計書・ソース・テスト資産をAIが工程横断で参照でき、前工程の成果物がそのまま後工程の入力になる、というものです。加えて、基盤はAWS上のマイクロサービスで、AIとつなぎやすい構成だと明記されています。
ここからは私の推測ですが、影響調査が大きく縮んだのは、既存の設計書とコードの対応関係をAIが引ける状態にあったからです。設計書が古い、ソースと食い違っている、テスト資産が個人のExcelに散らばっている——受託の現場でよく見るこうした状態では、同じツールを入れても同じ数字は出ません。設計書が無い基幹システムをAIで解析したカクヤスの事例が示すように、AIは資産の復元にも使えますが、それは期間短縮より手前の工程です。自社でAIによる開発改善を始めるなら、ツール選定より先に、成果物をAIが横断して読める形に揃えるのが順番です。この点はAI駆動開発の主戦場は組織の知見の体系化だという話ともつながります。
工程単位ではなく、プロセス全体を組み直している
もう1つ注目したいのは、特定工程にAIを足したのではなく、基本設計から結合テストまでを「成果物が流れる1本のプロセス」として組み直している点です。工程ごとに別のAIツールを入れると、各工程は速くなっても、工程の間の受け渡しで人手が残ります。私はこの型を、銀行に限らず製造業のERP/MES刷新など、既存資産が大きい基幹システムにも持ち込める再現可能な型だと考えています。「既存成果物とデータをAIが横断で使えるようにする」「工程単位ではなくプロセス全体を再設計する」「最終判断と品質保証は人に残す(Human-in-the-loop)」の3点です。レガシー刷新でClaude Codeを使ったパイプラインの事例でも、最後に効いていたのは人間が責任を持つ場所の設計でした。
開発会社・SIerの事業判断にどう効くか
SIerや開発会社の経営者にとって、この事例は技術ニュースではなく、収益モデルの話です。工数40%減は、人月で見積もり人月で請求する契約では、そのまま売上40%減を意味します。発注側がこの数字を知った状態で見積もりを見るようになれば、「AIを使っても使わなくても同じ人月」という見積もりは説明できなくなります。
私が考える論点は3つです。
- 契約と価格の単位を見直す。 工数ではなく成果物や期間で価格を置く、あるいは準委任で「AI込みの体制」を売る。どちらにしても、削減分を誰の利益にするのかを発注側と先に合意しておく必要があります。工程別に工数がどう動くかはAI時代の開発工数の変化を工程別に整理した記事にまとめています。
- ボトルネックは上流とレビューに移る。 コードの99%をAIが書いても、その正しさに責任を持つのは人です。書く人より、設計の意図を定義する人と、生成物を検証できる人が不足します。ソニー銀行が次の対象に要件定義を挙げているのも、そこが残る難所だからだと私は読んでいます。要件定義の進め方は現場理解・あるべき姿・PoCで最適値を探す進め方も参考になります。
- 既存顧客の資産整備が次の受注ポイントになる。 「AIで開発を速くしたい」という相談の多くは、実際には設計書とテスト資産の整備から始まります。ここを地味な作業ではなく、AI適用の前提工事として提案できるかどうかで差がつくと考えています。
なお、今回の数字は富士通のパッケージとAWS上のマイクロサービスという条件のもとで出たものです。メインフレームを含む巨大な基幹システムでは前提が変わります。MUFGのメインフレームモダナイゼーションのように、AIを入れる前に基盤の刷新が必要なケースも多いはずです。「30%短縮」を自社の見積もりにそのまま当てはめないでください。
まとめ
- ソニー銀行の事例は、稼働中の勘定系で工程横断のAI適用と工程別の定量成果を示した、PoCではない事例である。
- 大きな削減率を支えているのは、成果物をAIが横断で使える仕組みとAIにつなぎやすい基盤であり、ツールそのものではない(推測を含む)。
- 開発会社にとっては、人月の価格モデル・上流人材の不足・資産整備の提案という3点で事業判断を迫るニュースである。
出典: ソニー銀行、勘定系システムの実開発に生成AIを適用、開発期間を30%短縮(IT Leaders, 2026-09-14)
