Amazon Web Services ブログ
ソニー銀行が勘定系システムの開発に AI エージェントを適用し基本設計から結合テストまでの開発期間を 30% 短縮
このブログ記事は、AWS ソリューションアーキテクト 小塚が執筆し、ソニー銀行株式会社および富士通株式会社に監修いただきました。
ソニー銀行株式会社（以下、ソニー銀行）は、2025 年 9 月より、本番稼働中の勘定系システムの開発プロセスへの生成 AI 適用を、製造・単体テスト工程を起点として開始しました。
開発を担う富士通株式会社（以下、富士通）とともに設計工程および結合テスト工程へ段階的に適用範囲を広げ、2026 年 7 月時点で、基本設計から結合テストまでの開発工数を 40% 削減、開発期間を 30% 短縮しています（詳しくは『ソニー銀行と富士通、勘定系システムの実開発に生成AIを本格適用』（ソニー銀行）、『ソニー銀行と富士通、勘定系システムの実開発に生成AIを本格適用』（富士通）をお読みください。）
ソニー銀行の勘定系システムは、可用性、セキュリティ、監査対応のいずれについても高い水準が求められるワークロードです。しかも今回の対象は、これから作るシステムではなく、すでに本番で顧客の預金と取引を扱っているシステムです。既存の資産と既存の品質基準を前提にしなければならないという点で、新規開発に生成 AI を使う場合より制約は多くなります。
本ブログでは、この条件のもとでソニー銀行と富士通の事例を紹介します。
勘定系のクラウド移行が開発を加速
ソニー銀行は 2025 年に勘定系システム全体を AWS へ移行し、富士通の「Fujitsu Core Banking xBank（クロスバンク）」（以下「Core Banking xBank」）を採用しました。Core Banking xBank は AWS 上のクラウドネイティブな構成を採り、マイクロサービスを前提としたアーキテクチャになっています。（詳しくは AWS ブログ『ソニー銀行が勘定系システム全体をAWSに移行 – 同行が管理する全てのシステムがクラウドに』をお読みください。）
本取り組みがスムーズに結果に到達できた理由として、移行に向けてアプリケーションの設計と規約が整理されていたことが挙げられます。勘定系システム全体のクラウド移行に際して、設計書は最新の状態に整えられ、コーディング規約や命名規則も整理されていました。インフラストラクチャは AWS CloudFormation でコード化され、CI/CD パイプラインも整備されていました。つまり、AI エージェントが読み書きできる対象としての開発資産が、取り組み開始時点ですでに構造化された形で存在しており、開発〜検証〜リリースの SDLC（ソフトウェア開発ライフサイクル）における自動化が整備されていました。
なぜ Claude Code on Amazon Bedrock を選んだのか
閉域環境から使え、既存の統制の仕組みをそのまま使える
2025 年の選定時、複数のコーディングエージェントを実際に試して比較したうえで、開発者の意図をより正確にコードへ落とし込めると判断したのが Anthropic の Claude Code でした。生成 AI の推論基盤は、複数の AI 企業の基盤モデルに単一の API からアクセスできるフルマネージドサービスである Amazon Bedrock を採用しました。
セキュリティ制約から、開発環境から閉域通信でのコーディングエージェント利用が条件となっていました。Amazon Bedrock ではその制約を満たし、入力と出力が、AWS やモデルプロバイダーのモデルの学習に使われることはありません。
また、認証・認可、ログ監視、AWS CloudTrail による API 呼び出しの記録など、いずれもすでに勘定系の運用で使っている統制の仕組みです。これらがそのまま適用できるため、導入開始までの期間を短くすることができました。
全員に同じ開発環境を整備する
開発者は、開発拠点の IDE から接続された Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上の Dev Container の中で Claude Code を使います。
狙いは、全員が同じ環境で安全に作業する状態を作ることです。コンテナイメージには開発に必要な環境設定、ツール、AI エージェント、Model Context Protocol (MCP) サーバー設定が同梱され、Amazon Elastic Container Registry (Amazon ECR) にプッシュされています。Skills や Steering ファイルは Dev Container を立ち上げた後に AWS CodeCommit からプルしてセットアップします。
これにより 3 つのメリットが得られます。
1 つ目は環境構築の手間がなくなることです。開発者は配布されたイメージ上で、必要なツールと Skills が揃った状態から作業を始められます。各自が自分の手元を整える作業も、その差異を後から吸収する作業も要りません。
2 つ目は出力品質の安定です。環境や Skills が開発者ごとに違えば、同じ指示を与えても成果物の品質は担当者ごとに振れます。全員が同じイメージ、同じ Skills、同じ MCP サーバーの構成で作業するため、担当者が違っても同じ指示から同等の水準の成果物が出ます。
3 つ目は統制です。どの機能を使い、どれを使わないかという線引きを、コンテナイメージという配布物として担保できます。統制の枠を文書で配るのではなく、作業する環境そのものに埋め込む形です。
図 1: Core Banking xBank の開発環境構成図
チーム内で品質を担保しながら AI エージェントを活用する
最初に決めたのは、AI エージェントをどうコントロールするかという原則となるコンセプトでした。どのタイミングで何をすべきか、どの層が何を保証するのか。これをチームで合意したうえで、個々のエージェント、Skills、MCP、Hooks などの仕組みをその原則にマッピングしました。生成 AI 関連のツールは仕様の変化が速く、ベストプラクティスの変化や新しい機能もありました。それでも、このコンセプトはほとんど変化していません。
既存資産への接続
AI エージェントは、MCP、Tools、Skills を通じて開発資産や外部システムと連携します。設計書、ソースコード、テスト資産といった既存の資産を参照しながら成果物を生成するため、既存資産の文脈に沿った出力になります。
接続先のひとつが、システム構成定義データベースです。アプリケーションの変数やドメイン定義を保持しているデータベースに MCP サーバー経由で接続しています。ドメイン定義には和名と英名の対応が定義されているため、自然言語で書かれた指示が実際にはどのクラスやドメインを指すのかを引き当てられます。
Skills の精度を測定し、各チームに配布する
Skills は CodeCommit で管理し、生成 AI タスクフォースが作成して業務チームに提供する体制を採っています。Skills をどういうルールで作るか（記述の構造、書くべき情報の粒度など）も文書として定義し、チーム内で育てています。
現状、開発者全員がそれぞれ Skills を作る形は採っていません。全開発チームに一斉に「自由に使ってよい」と開放した場合、成果物の品質はばらつき、何が起きているかを把握する術がなくなります。中央に生成 AI タスクフォースを置けたことが、統制が効いた状態で適用を広げられた要因になっています。
ただ、将来的には Skills の作り方の習熟度によって、各開発者自身が Skills を作る形へ広げることも視野に入れています。
One Shot で測り、精度が出てから広げる
精度は、シニアエンジニアが作った場合との比較で測っています。実装を担当するメンバーが自分で作ったものと、生成されたものを突き合わせ、出てきた差分を分析し精度を評価します。
適用を現場に広げる判断には明確な基準を置いており、精度が設定した基準値を超える場合、その手順を Skills として確定させ、各現場のリーダーや実装担当者に展開してよいと判断します。このとき、あえて追加の指示による作り直しをさせません。One Shot、つまり一度の指示に対する生成結果の精度です。何度も指示を重ねて完成度を上げていく運用にすると、指示の出し方が上手い担当者を前提とした成果物ができてしまい、担当者によって結果が振れるためです。
この運用を回した結果、シニアエンジニアが作成したものとほぼ同等の成果物が One Shot で得られるようになりました。
工程間で Human in the Loop によって品質を担保
生成された成果物に対する最終判断と品質保証は、すべて人が担っています。レビューを AI に委ねる形は採っていません。設計・製造・テストの各工程に対応する AI エージェントを用意し、コンテキストを適切なサイズに保つことで精度を高めており、AI の出力を人がレビューしてから次に進みます。
今後の展開
今まで開発工程で品質を保ちながら生成 AI で開発スピードを向上させてきました。今後はこの取り組みの適用範囲をソフトウェア開発ライフサイクル全体、また他システムへ拡大していきます。
1 つ目は要件定義工程です。適用は要件を受け取った後の開発工程から開始しました。要件定義の工程にはステークホルダーが多く、開発工程に比べて環境や情報ソースも多岐にわたります。ここを整備しながら現在検証・適用を進めています。
2 つ目は運用とセキュリティです。これらの領域ではフロンティアエージェントを積極的に活用することを検討しています。運用ではテレメトリ、コード、デプロイの情報を相互に関連付けてインシデントを調査し、根本原因を特定できる AWS DevOps Agent を検証しています。セキュリティでは、設計文書のセキュリティレビュー、コードレビュー、オンデマンドのペネトレーションテストを開発ライフサイクルの中で実行できる AWS Security Agent を検証しています。
さらに、本取り組みで得た知見と開発資産は勘定系システムだけでなく、周辺系システムにも活用していきます。開発・運用・セキュリティの全領域で AI を活用し、「AI ネイティブな銀行」の実現を推し進めていきます。
まとめ
本ブログでは、本番稼働中の勘定系システムの開発プロセスに生成 AI を適用した、ソニー銀行と富士通の取り組みをご紹介しました。ミッションクリティカルなシステムの品質基準を保ちながら、いかにして生成 AI を開発プロセスに組み込むか、それにより得られた効果についてより多くの方々に知っていただけると幸いです。