ソニー銀行がClaude Codeで勘定系開発を変えた——コード生成率99％、工数40％削減の中身を読む
ソニー銀行が、本番稼働中の勘定系システムの開発にAIエージェントを全面適用し、基本設計から結合テストまでの開発期間を30％短縮、工数を40％削減したと発表した（2026年7月時点）。本番コードのAI生成率は99％に達しているという。
「生成AIで開発効率化」という話題は食傷気味になってきているが、この事例は少し別の文脈で読む必要がある。舞台は金融機関の最も神経質な領域——勘定系システムであり、PoCや社内ツールの話ではない。
どの工程で何が起きたか
まずは数字を並べておく。2026年7月時点でのソニー銀行と富士通の発表によれば、工程ごとの成果は以下の通りだ。
- 基本設計工程：影響調査工数を最大90％削減
- 詳細設計工程：設計書作成工数を最大40％削減
- 製造工程：ソースコード生成率99％を達成
- 結合テスト工程：テスト実行工数を最大90％削減
基盤として使われているのは、富士通の勘定系製品「Fujitsu Core Banking xBank」。これがAWS上で稼働しており、Amazon Bedrockを通じてAnthropicのClaudeおよびClaude Codeが呼び出される構成だ。生成AIの導入自体は2025年9月から始まり、段階的に適用範囲を広げてきた。
AIエージェントが設計書・ソースコード・テスト資産を工程横断で利用できるように仕組みが設計されている点が重要で、前工程の成果物が後続工程に渡り再利用される。設計書からソースコードを生成し、そのソースコードからテストケースを生成するというループ構造だ。AIエージェントが外部システムと連携するためのMCP（Model Context Protocol）やTools、Skillsも組み込まれている。
「PoCではなく本番」という一点の重さ
ここからは、この事例をどう解釈するかという話になる。
生成AIの開発適用事例は増えているが、多くは社内ツール・業務自動化・テストコード支援のような「外縁部」から始まる。勘定系は違う。オンライン取引処理とバッチ処理を含む銀行業務の根幹であり、バグが許されない領域だ。その本番開発に適用しているという点は、象徴的な意味を持つ。
加えて言えば、Core Banking xBankがクラウドネイティブかつマイクロサービスアーキテクチャを採用していたことが、この適用を可能にした大きな条件だ。モノリシックなレガシーシステムであれば、「機能単位で段階的に適用し評価する」という進め方はそもそも取れない。アーキテクチャの選択が、後からAI適用の余地を大きく左右する——この構造的な含意は、自社のシステム設計を考える人間にとって重要なメッセージだ。
99％という数字を正確に読む
「ソースコード生成率99％」という数字は、インパクトがある。が、「AIが全部書いてエンジニアは不要になった」という意味ではない。
発表では明確に「人による判断、承認、品質保証の下で開発を支援する」と書かれている。富士通の、金融業務とシステム開発の両方に精通した人材が、適切なタイミングで評価・改善を行うことで安全性と品質を確保した、とも述べられている。
99％は「AIが生成したコードの割合」であって、「人間が関与していない割合」ではない。ここの読み違いが、現場での期待値のズレを生む。実態はおそらく、AIが初稿を高速生成し、人間がレビューと判断を行い、品質を担保するという構造だ。
工数が40％削減されたということは、逆に言えば60％の工数は残っているということでもある。コーディングそのものよりも、設計判断・品質確認・例外ケースの処理といった「AIが苦手な部分」に人間のリソースが集中している可能性が高い。
開発現場と経営層が問うべきこと
この事例を受けて、実務的に何を考えるべきか。
まずアーキテクチャの前提を確認することだ。マイクロサービスかつクラウドネイティブという構成がAI適用の下地になったことは明確であり、「既存のモノリスにとりあえずAIをあてよう」という発想では同様の効果は出ない。AI適用を視野に入れるなら、アーキテクチャ刷新の優先順位が上がる。
次に、開発資産の整備から始まるという点を認識する必要がある。ソニー銀行と富士通は「設計書やソースコード、テスト資産といった開発資産をAIが活用できる仕組みを構築した上で」適用を広げた、と明記している。AIにコードを書かせる前に、AIが読める形で資産が整理されていなければ話にならない。ドキュメントが散逸していたり、ナレッジがベテランの頭の中だけにある状態では、同様のアプローチは取れない。
そして段階的な検証が前提であることも見落とせない。2025年9月から始め、2026年7月に30％短縮を確認、という時系列は約10ヶ月だ。一足飛びに全工程へ適用したわけではなく、工程ごとに適用・評価・拡大を繰り返している。「まずは影響調査から」「次に設計書作成へ」という順序だったことは、現場での導入計画に参考になる。
次に何が問われるか
ソニー銀行と富士通は今後、要件定義工程・セキュリティ領域・運用保守への適用を拡大する方針を示している。富士通はCore Banking xBankを採用する他の金融機関でも展開する予定だという。
ここで次の論点が浮かぶ。「要件定義」へのAI適用は、製造やテストとは性質が異なる。要件定義は、ビジネス側の意思と技術側の制約がぶつかる場所であり、「正解」が事前に存在しない。設計書→コード→テストという変換に近い製造工程と違い、何を作るべきかを確定するプロセスにAIをどう組み込むかは、まだ試行が少ない領域だ。
また、責任の所在も論点になる。AIが生成したコードがバグを含んでいた場合、銀行・富士通・Anthropicのどの責任がどう問われるか。金融当局との関係でこの点がどう整理されているかは、発表では触れられていない。金融業界でのAI適用が広がるにつれ、ここは必ず問われる。
「AIネイティブな銀行」を目指すというソニー銀行のビジョンは、目標として理解できる。ただ、AIの適用範囲が要件定義・運用保守・セキュリティへと広がるにつれ、「何をAIに任せ、何を人間が判断するか」という設計の難度も上がっていく。今回の成果は「製造工程における変換作業の自動化」として比較的クリアだったが、次の工程では判断の自動化になる。そこに同じアプローチが通じるかどうかは、まだ見えていない。
まとめにかえて
今回の事例が示すのは、「生成AIが銀行の勘定系開発で動いた」という話だけではない。クラウドネイティブなアーキテクチャ・工程横断での開発資産整備・段階的な検証プロセスという三つの条件が揃って初めて、このスケールの効果が出た、という構造だ。
どれか一つを切り取って「うちも同じことをやろう」とはならない。一方で、この三条件を自社でどう整えるかを考える出発点としては、十分に具体的な事例だ。次に同種の「AI開発効率化」記事を見るとき、「本番かPoCか」「アーキテクチャは何か」「人間の関与はどこか」という三点を確認する習慣をつけると、情報の質が変わってくる。
