金融機関のAI駆動開発から学ぶ 生成AIを開発工程に組み込むための統制とは
生成AIを使ったシステム開発が、試験的なコード生成から本番システムの開発工程へ広がり始めています。2026年9月14日、ソニー銀行と富士通は、生成AIを勘定系システムの実開発に本格適用したと発表しました。同日、かんぽ生命と日本IBMも、AI駆動開発を前提とする独自の開発標準を整備する取り組みを公表しています。
両事例に共通するのは、AIツールを導入するだけではなく、人による判断、品質確認、開発標準を同時に整えている点です。本記事では二つの発表を比較し、企業が生成AIを開発工程に組み込む際に必要となる統制を整理します。
1. 金融機関でAI駆動開発が本番段階に入った
AI駆動開発とは
AI駆動開発とは、設計書の作成、影響調査、プログラム生成、テストケース作成など、システム開発の複数工程をAIが支援する開発方法です。従来のコード補完との違いは、個人の作業を部分的に速くするだけでなく、設計からテストまでの成果物をつなぎ、開発プロセス全体へAIを組み込む点にあります。
金融機関のシステムでは、処理の誤りや停止が顧客取引や社会的信用に影響します。そのため、AIがコードを生成できるかだけではなく、生成物を誰が確認し、どの条件を満たせば次の工程へ進めるのかを定めなければなりません。
今回の二つの発表は、異なる段階にあります。ソニー銀行は、本番稼働中の勘定系システムの実開発で得られた効果を公表しました。一方、かんぽ生命は、今後のAI駆動開発を支える標準を整備し、工数削減と品質確保を目指す取り組みです。実績と目標を区別した上で見ると、AI駆動開発を本番化するために必要な要素が分かります。
2. ソニー銀行は勘定系システムの実開発へ生成AIを適用
工数40%削減、開発期間30%短縮を確認
ソニー銀行と富士通の発表によると、両社は2025年9月から、Amazon Bedrock上のClaudeやClaude Codeを中核とするAIエージェントを勘定系システムの開発へ適用しました。設計書、ソースコード、テスト資産をAIが工程横断で利用し、前工程の成果物を後続工程でも活用する仕組みです。
2026年7月時点で、基本設計から結合テストまでの工数を40%削減し、開発期間を30%短縮したとしています。工程別には、基本設計で影響調査工数を最大90%削減、詳細設計で設計書作成工数を最大40%削減、結合テストでテスト実行工数を最大90%削減しました。製造工程では、ソースコード生成率99%を達成したと報告されています。
ただし、ソースコード生成率99%は、生成されたコードが無確認で本番環境へ反映されたことを意味しません。公式発表では、設計、製造、テストのAIエージェントが開発を支援する一方で、人が判断・承認・品質保証を担うことが明記されています。
PoCではなく標準プロセスに組み込んだ
重要なのは、生成AIを一部の担当者が任意に使うツールではなく、実開発の標準プロセスへ組み込んだ点です。富士通の金融業務・システム開発の知見を持つ人材が、適切な段階で成果物を評価し、改善する運用も採用されています。
また、すべての工程へ一度に適用したのではありません。クラウドネイティブかつマイクロサービスを前提とした構成を利用し、機能単位で適用と評価を繰り返しながら対象を拡大しています。これは、高い信頼性が求められるシステムでAI活用を進める際に、影響範囲を限定しながら検証する方法として参考になります。
3. かんぽ生命はAIを前提とした開発標準を整備
経験者の判断基準まで文書化する
かんぽ生命と日本IBMは、「かんぽスペック駆動開発標準」を整備すると発表しました。既存の開発ルールや手順に加えて、経験豊富な社員が持つ知識や判断基準を、AIと人が利用できる形で整理・文書化するものです。
標準化の対象には、AIへの指示方法、成果物の作成方法、品質の確認方法、人とAIの役割分担が含まれます。日本IBMは、開発支援パートナー「IBM Bob」とAI駆動開発ソリューション「ALSEA」を使って取り組みを支援します。両社は、実際のプロジェクトで得た成果や知見を開発標準へ継続的に反映する方針です。
かんぽ生命が公表した開発工数50%削減は、現時点で確認済みの成果ではなく、取り組みを通じて目指す目標です。ソニー銀行の実績と同列に扱わないことが重要ですが、AI導入前に統制を設計しようとしている点に、この事例の価値があります。
開発標準が必要になる理由
同じAIモデルを使っても、指示の内容、参照させる設計書、確認する担当者が違えば、成果物の品質は変わります。担当者ごとに使い方が異なる状態では、不具合が発生した際に原因を追跡しにくく、品質保証も属人的になります。
そのため、プロンプトの例を共有するだけでなく、入力してよい情報、参照する正式文書、成果物の形式、確認観点、承認者まで定める必要があります。かんぽ生命の事例は、AI活用の標準化が効率化だけではなく、知識の継承と品質の再現性にも関係することを示しています。
4. 二つの事例から分かる5つの統制
1. AIへ任せる工程と利用範囲を定める
最初に、AIを使う工程、対象システム、利用できるデータとツールを定めます。「開発でAIを利用可」とだけ決めるのでは不十分です。影響調査、設計書作成、コード生成、テスト作成などに分け、工程ごとに許可範囲を設定します。顧客情報や機密情報を扱う場合は、入力制限、保存先、外部送信の有無も確認対象です。
AIエージェントがリポジトリや開発ツールを操作する場合は、閲覧、変更、実行の権限も分けます。検証環境で必要な権限を、そのまま本番環境へ引き継がないことが重要です。利用目的と期間を限定し、不要になった権限を取り消せる管理方法まで決めます。
2. 人の判断・承認・品質保証を工程へ組み込む
AIが生成した成果物の確認を担当者の注意力だけに依存させず、承認工程として明文化します。特に、要件の妥当性、業務ルールとの整合、セキュリティ、リリース可否は、責任を持つ人や会議体を定める必要があります。AIは成果物を作成できても、事業上の影響を引き受ける主体にはなりません。
3. 成果物ごとに品質基準を設ける
生成コードには静的解析、レビュー、単体テストを実施し、テストケースには要件の網羅性や異常系の確認を行います。AIがコードとテストの両方を生成する場合は、同じ誤解が双方へ反映される可能性があります。したがって、人によるレビューや既存基準との照合など、AIの出力だけで完結しない品質確認が必要です。
合格条件は「担当者が確認する」のような表現で終わらせず、重大な脆弱性がないこと、必須の業務シナリオを通過すること、既存機能の回帰テストに合格することなど、判定できる基準にします。AI生成物だけに緩い基準を適用せず、従来の開発基準と整合させます。
4. 入力・出力・承認の記録を残す
問題発生時に検証できるよう、使用したモデルとバージョン、参照資料、主要な指示、生成物、修正内容、テスト結果、承認者を記録します。金融庁の「AIディスカッションペーパー(第1.1版)」も、金融機関が判断の合理性を説明する観点として、参照データ、プロンプト、出力結果の記録とモニタリングを挙げています。
記録は保存するだけでなく、障害調査や監査の際に検索できる必要があります。保存期間、閲覧権限、案件や成果物とのひも付け方を決め、個人情報や機密情報を記録へ重複して残さない設計も求められます。
5. 開発標準を継続的に更新する
モデルや開発ツールは更新されるため、一度作ったルールを固定したままにはできません。障害、レビュー指摘、削減効果、現場からのフィードバックを集め、許可範囲や品質基準を見直します。金融庁も、環境・リスク分析、目標設定、運用、評価を繰り返すアジャイル・ガバナンスの重要性を示しています。
5. 企業への学び:小さな実証から本番統制へ移行する
金融機関以外の企業でも、いきなり全社共通のAI開発基盤を完成させる必要はありません。まず、影響範囲を限定しやすく、既存のテスト結果と比較できる工程を選びます。その上で、効率化と品質の両方を測定します。
導入時には、少なくとも次の事項を確認します。
- 対象工程:AIへ任せる作業と、対象外にする作業は何か
- 利用環境:ソースコードや設計書がどこへ送信・保存されるか
- 品質基準:どのテストとレビューを通過すれば次工程へ進めるか
- 責任者:誰が修正を判断し、誰が最終承認するか
- 記録:入力、生成物、変更、テスト、承認を追跡できるか
- 更新方法:指摘や事故、モデル変更をルールへ反映する担当と周期があるか
効果測定では、生成量だけを成果指標にしないことも重要です。作成時間が短くなっても、レビューや修正に時間が移っただけなら、全体の工数は削減されません。開発期間、手戻り、不具合、レビュー時間、テスト網羅率などを合わせて確認する必要があります。
また、開発者だけへのツール研修では不十分です。レビュー担当者にはAI生成物で起こりやすい誤りを、管理者には承認責任と例外時の対応を教育します。停止条件、利用を一時停止した場合の連絡先、従来の開発方法へ戻す手順まで決めることで、本番環境で問題が起きた際の対応が明確になります。
6. まとめ
ソニー銀行は、生成AIを勘定系システムの実開発へ組み込み、工数40%削減と開発期間30%短縮を確認しました。一方、かんぽ生命は、人とAIの役割分担や品質確認方法を含む開発標準を整え、工数50%削減を目標としています。
二つの事例が示しているのは、AI駆動開発の本番化には、AIモデルの性能だけでなく、利用範囲、人の承認、品質基準、記録、継続的な更新が必要だということです。企業はコード生成率などの数値だけを比較するのではなく、その成果を支える開発プロセスと責任分担まで確認する必要があります。
▶ [AIガバナンス支援サービスの詳細・お問い合わせはこちら]
参考文献
- ソニー銀行株式会社・富士通株式会社「ソニー銀行と富士通、勘定系システムの実開発に生成AIを本格適用」(2026年9月14日)
- 株式会社かんぽ生命保険・日本アイ・ビー・エム株式会社「かんぽ生命と日本IBM、AI駆動開発による新たなシステム開発の取り組みを開始」(2026年9月14日)
- 金融庁「AIディスカッションペーパー(第1.1版)」(2026年3月3日)

この記事の著者
花島一颯 (Hanajima Issa) | AI共創総研 コンサルタント・リサーチャー
東京大学工学部 機械工学科(熱エネルギー工学研究室)に所属。主に熱電変換技術を専門とし、新デバイスの開発研究に従事している。特に、デバイスの出力分析や、熱流体現象としての対流効果に着目した解析を行っている。日本伝熱学会での発表経験を有する。現在はAIリスク・セキュリティ分野での研究も行っており、コンサルティング業務を担当している。

-

OpenAIのAIエージェントはなぜ外部システムに侵入したのか――事件の経緯と企業が見直すべき管理体制
カテゴリー
-

生成AIの共有リスクにどう備えるか Claude事例から考える企業の利用ルール
-

AIエージェント時代のZero Trustを整理する -Anthropic “Zero Trust for AI Agents” を読んで-
-

【解説スライド掲載あり】AIレッドチーミングとは何か?AIセーフティの観点から実務的に解説
カテゴリー
-

AI事業者ガイドライン第1.2版の変更点
カテゴリー
-

【イベント開催】「AIガバナンスはブレーキだけではない、触媒である」― 技術×リスクを横断し、AI活用を加速させる人材の育て方 ―



