金融系エンタープライズでのBedrockを用いたAI駆動開発の課題と実践

金融系エンタープライズでのBedrock を用いたAI駆動開発の課題と実践 2026年9月17日 AWS Insurance Community 特別編

自己紹介 小泉 岳人 ニッセイ情報テクノロジー 主席スペシャリスト 趣味はコントラバス、社外登壇 横山 涼 ニッセイ情報テクノロジー 専門職 趣味は北海道旅行 スクリーンショット・写真撮影・SNS共有 大歓迎！ 2

持ち帰ってもらいたい内容 エンタープライズの実際の案件で AWSでAI駆動開発を実施した時の 課題や実践事例を持ち帰れる 3

案件の概要 ・保険のユーザー向けの付帯サービス(Webサービス)の構築 ・AI,AWS,アジャイル開発に慣れていない開発メンバーが多い ・要件面で未確定事項もあることからアジャイル開発での実施要望 4

開発スケジュール POINT①： 環境構築・機器調達に時間を要し、正式環境での開発は9月開始。 POINT②： AI駆動開発の実現性を確認するため、別環境で先行検証を行う。 POINT③： 本格環境の整備を待たず、最低限の環境でバイブコーディングを行い、要件の実現性を確認する。 3月 4月 5月 6月 7月 (バイブコーディングでの開 発) 9月 10-12月 ★正式開発環 境オープン POINT③ 要件調整 調整 8月 POINT② 環境準備 開発① (PoC環境) (PoC環境でAI駆動開発) 環境準備(正式環境) 移 行 1‐3月 ★プレ本番 ★本番 開発② (正式環境でAI駆動開発) POINT① イマココ 5

本日のテーマ ①.Kiroでのバイブコーディング ②.BedrockでのAI駆動開発 ③.品質を守るための取組 ④.AI時代の開発課題1(アジャイルの必要性) ⑤.AI時代の開発課題2(学習の必要性) 6

①.Kiroでのバイブコーディング 開発初期は要件に関しても技術に関しても開発者、POともに解像度が粗い。最初に主 要な要件部分について形にすることで解像度を高める(Amplifyとの組み合わせは爆速 でのモノ作りがやりやすい） MCP Figma Kiro Amplify 生成物とバック ログ自体の解像 度を上げる 7

①.Kiroでのバイブコーディングでの感想 ・こんなに簡単に動くものができるのか！ 横山 ・曖昧な指示でも試作品ができ、要件を 具体化する速さに驚いた ・動くものを見ながら話せるため、 POと開発者の認識合わせが進んだ 8

②.BedrockでのAI駆動開発（1/3） 本格開発においてはAI駆動開発の 事例が多いClaude Codeを採用。 Bedrockを用いて実現 9

②.BedrockでのAI駆動開発（2/3） インクリメント PBI Figma DoD/品 質計画 動作する システム スプリント 計画 スプリン トの実施 方法を見 直す AI駆動 開発 プロダクショ ンコード テストコード CLAUD E.mdに 反映させ る 課題/わからな い点/改善点 INPUT成果物 自体を見直す 検討 適宜バックロ グを起票し、 スプリントの 中で実施 わかった点/わからない点 10

②.BedrockでのAI駆動開発（3/3） Claude Codeで処理している開発フローの概要は下記の通り。現在は下記フェーズご とにAIと人で確認しながら開発を実施している フェーズ 目的 1. REQUIREMENT 要件を明確にする 2. PLAN 実装方法を決める 3. TEST テストを先に作る 4. IMPLEMENT 最小限の実装を行う 5. VERIFY 品質を確認する 6. REVIEW 実装をレビューする 7. MERGE READY マージ準備を整える 主な作業 要件・受け入れ基準・影響 範囲を整理 設計、テストケース、実装 手順を整理 Unit・Integrationテスト を作成 UI、API連携、状態管理な どを実装 テスト、型、lint、動作・ デザインを確認 ルール、設計、品質、セ キュリティを確認 差分確認、再テスト、変更 内容を整理 完了条件 左記記載された要件を合意 できている 設計・テストケース・実装 手順に合意済み 妥当な理由でテストが失敗 （Red） 全テストが成功（Green） 検証結果と証跡を記録 指摘解消後、レビュー通過 ユーザー承認後にコミット 可能 11

②.BedrockでのAI駆動開発での感想 ・規約・テスト方針・設計ルールを 事前に定めることで、品質を 個人任せにしない土台ができた 横山 ・AIが整理した仕様を人が 確認してから実装することで、 認識ズレや抜け漏れを早期に発見できた 12

③.品質を守るための取組 AI駆動開発であっても、品質については人の説明責任(Accountability)が必須。説明 責任を果たせるよう品質についての言語化を行いながら対応 【取組方針】 № 方針 内容 1 品質計画、テスト計画 品質特性ごとの確認方法と、AI/人の役割を定める 2 TDD(テスト駆動開発) TDDを基本とする。テストコードを生きた設計書になるよう目指しながら、基本品質を担保 自動チェック 3-1.CI/CD デプロイの前に必ず自動テストを実施しながら品質を担保 3-2.コードチェック コーディング規約への適合を自動確認する 3-3.セキュリティ DevSecOpsの基盤を構築しセキュリティチェックを実施。Biome,cdk-nag,npm audit ,OWASP ZAP※,security hub(Inspector)等でSAST,DASTのチェックを実施 Codeシリーズ ※OWASPZAPについてEventBridge経由で毎朝コンテナを起動し、チェック 3-4.アクセシビリティ axe-coreをベースにチェックを実施。 3-5.保守性 SonarQube※でのコードスメルの見える化やSkillsを作成して保守性の観点で独自レビューを実 施 ※EC2上のSonarQubeでチェック 4 有識者確認 最終的に有識者が確認する ※自動化が進むほど、学習の課題も顕在化（テーマ⑤） 13

③.品質を守るための取組についての感想 ・自動チェックで、人手の レビューへの依存を減らせた 横山 ・セキュリティや保守性の問題を 自動検知する仕組みの重要性を実感した 14

④.AI時代の開発課題1(アジャイルの必要性) ・AI自体も変化している中で、ベストプラクティスの導入ではなく、 素早い検査・適応が必須となっている ・そもそもAI-DLC等、現在のAI駆動開発の実施方法はアジャイル開発を ベースとしており、アジャイル開発を基本としたソフトウェアエンジニアリングの 理解が必須 手順を固定化し、効率化/拡大を実施してきた大規模開発のやり方、 SIerのマインドと相性が悪い 15

④.AI時代の開発課題1(アジャイルの必要性)についての感想 横山 ・開発中も、ライブラリの 脆弱性対応やAIモデルの世代交代への 対応が必要だった ・状況を確かめ、進め方を素早く 見直す姿勢が欠かせなかった 16

⑤.AI時代の開発課題2(学習の必要性) (1/2) AIで「作る」ことは速くなった。だが、理解が追いつかなければ、判断できないものが高速に積 み上がる。目指したかったのは、作るたびに理解と判断力も蓄積され、進むほどよくなる状態 実際の状況 1 目指したかった開発 2 1 AIで形にする(理解負債が増える) 1 AIで形にする(理解負債が増える) 2 動くもの・実例で理解/学びが進む 2 人の理解より先に成果物が増える 3 理解負債が返済される 3 理解負債が積みあがる 4 学びをAI/ルール/設計に戻す 4 判断・責任が曖昧になりAI依存が進む 5 開発が進むほど速く・良くなる 5 後半で手戻り・停滞が増える 人とAIがともに成長する開発 AIに判断を預ける開発 17

⑤.AI時代の開発課題2(学習の必要性) (2/2) AIにより、わからなくても開 発は進む。だからこそ、「わ からない」を意図的に表出し ないといけない 1 スキル不足 基礎スキルが不足。「わから ない」ことがわからない 2 文化・契約 3 受委託関係が複雑な中、 「わからない」を出せない アジャイル習熟不足 問題発見や学習がアジャイル の強みだが、「問題（わから ない）」に気づきにくい ワンチーム お客様 なぜか進む 会社1 会社2 再委託 再委託 問題はありません 18

⑤.AI時代の開発課題2(学習の必要性) についての感想 ・チーム全員で作業を進める中、 個人の「わからない」で 立ち止まりにくく、AIのコードを 理解しないまま進みがちになる 横山 ・AIが詰まりも解消するため、 試行錯誤から学ぶ機会も減りやすい。 だからこそ、受動的に進めず、 自主的に学ぶ姿勢が欠かせない 19

また、うまくいったらどこかで報告します！！！ Fin 20