---
title: 「AIツールを使える状態にするだけでは、開発現場には広がらなかった」 〜CCIグループ 北國銀行のインターネットバンキングシステム開発でのAI活用実践〜 - AI Dev Day 2026
tags:  #aidevday #チーム開発 #開発効率化 #digitalvalue  
author: [株式会社デジタルバリュー](https://www.docswell.com/user/digitalvalue)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/P7XQY8G3EX.jpg?width=480
description: 2026/7/24 AI Dev Day 2026 の登壇資料です https://aidevday.com/sessions/kakemizu-yuki 株式会社デジタルバリュー https://www.digitalvalue.co.jp/
published: July 31, 26
canonical: https://www.docswell.com/s/digitalvalue/Z4NLRG-2026-07-31-084216
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/P7XQY8G3EX.jpg)

AIツールを使える状態にするだけでは、
開発現場には広がらなかった
CCIグループ 北國銀行のインターネットバンキングシステム開発でのAI活用実践
Yuki Kakemizu / DigitalValue
AI Dev Day 2026 Sponsor Session
2026.07.24
Digital Value

# Page. 2

![Page Image](https://bcdn.docswell.com/page/37K93K4N7D.jpg)

掛水 優輝 Yuki Kakemizu
DigitalValue - シニアデベロッパー
CCIグループ 北國銀行向けインターネットバンキング開発
Webフロントエンド領域のリード
開発現場でのAI活用推進
最近は Microsoft Foundry を使った AI Agent 開発にも取り組んでいます
Digital Value

# Page. 3

![Page Image](https://bcdn.docswell.com/page/LJ3WGZLZJ5.jpg)

| はじめに
会社紹介 & 対象プロダクト
DigitalValue は、CCIグループのシステム会社として、
北國銀行向けシステムをはじめ、さまざまなプロダクト開発に取り組んでいます。
金融領域で培った開発力を活かし、内製開発・アジャイル・AI活用を進めています。
北國クラウドバンキング
北國銀行 個人向けインターネットバンキング
2019年 提供開始 利用者40万人 内製開発 & アジャイル
いつでも、どこでも、あなたの窓口
北國クラウドバンキング
振込・残高 24時間 確認可能
北國銀行あて 手数料 0円
専用アプリで かんたんアクセス
今日は、この北國クラウドバンキングの開発現場で、
AI駆動開発をどう定着させていったかを話します。
Digital Value

# Page. 4

![Page Image](https://bcdn.docswell.com/page/8JDK1RN4EG.jpg)

| はじめに
プロダクトの開発体制
北國クラウドバンキングの機能開発には、4つの開発チームが関わっている。
※ ほかに PO チームや技術支援チームもある。今日は開発チームに焦点を当てる
北國クラウドバンキングの開発
開発チーム
8名
開発チーム
8名
振込・残高照会などを行う、個人のお客さま向けサービス
バックオフィスシステムの開発
開発チーム
7名
開発チーム
8名
顧客対応・照会などを行う、担当者向けの社内システム
Digital Value

# Page. 5

![Page Image](https://bcdn.docswell.com/page/VEPKQW5V78.jpg)

生成AIは会社として導入され、誰もが使ってよい状態だった。
これで開発は加速する、はずだった。
ところが利用は、生成AIに関心の高い一部にとどまり、
チームには定着せず、開発は加速しなかった。
Digital Value

# Page. 6

![Page Image](https://bcdn.docswell.com/page/27VV58PR7Q.jpg)

| はじめに
なぜ、チームに定着しなかったのか
⚠ 使い方、個人の工夫に依存していた
➶ 開発工程の中で、いつ・何に・どう使うかが未整理だった
▧ チームの基準をAIに渡す方法がなかった
▤ 良い使い方をためて、共有する場所がなかった
課題は、AIツールを使える状態から、開発プロセスで使われる状態へどう変えるかだった。
Digital Value

# Page. 7

![Page Image](https://bcdn.docswell.com/page/5JGL65P67L.jpg)

| はじめに
この課題に、どう取り組んだか
状況を打破するため、トップダウンの方針として、
バックオフィス側で先にAI駆動開発の型を作り、北國クラウドバンキングの開発を行う各チームへ広げることになった。
※ 以降、型を作ったバックオフィス側の2チームを「先行チーム」、広げた先の2チームを「展開先チーム」と呼ぶ
2025年5月〜 小さな実案件で、AI駆動開発の型を作る
2025年10月〜 各チームへ広げる - やってみると、3つの課題が見えた
2025年12月〜 AI推進定例と4つの取り組みで、定着させる
現在 成果は、チーム全体の開発ペースに表れた
先に、結果 開発ペースは、平均で約1.5倍に
どうやって、ここまで辿り着いたのか - 今日は、その過程を話します。
Digital Value

# Page. 8

![Page Image](https://bcdn.docswell.com/page/47QY4Z22EP.jpg)

| 型を作る
まず小さく、AI駆動開発の型を作る
2025年5月、北國クラウドバンキング向けの
バックオフィスシステム開発（先行チームの2チーム）から始めた。
※ 北國クラウドバンキングより規模・影響範囲が小さく、最初に型を作るのに適した案件だった
AIに任せるといっても丸投げではなく、工程ごとに3つを設計する必要がある。
何を渡すか
AIに渡すコンテキスト
何をださせるか
AIに期待する出力
人がどこを判断するか
レビュー・承認のポイント
ここでの「AI駆動開発」= この3つを設計しながら、実案件を進めること
Digital Value

# Page. 9

![Page Image](https://bcdn.docswell.com/page/KE4WQ3LPJ1.jpg)

| 型を作る
GitHub Copilot Chat の prompt files を作業ごとに整備
この3つの設計を、個人の頭の中に置かず、チームで共有できる形にする。
2025年当時、その形として選んだのが GitHub Copilot Chat の prompt files (以降 prompts)。
※ 再利用可能な指示テンプレート。Claude Code の slash commands や Codex の custom prompts に近い仕組み
設計資料作成
APIインターフェース検討
実装
単体テスト生成
統合テスト設計
何を渡し、何を出させ、どこを人が判断するか - 3つの設計を、prompts で共通の型に落とし込む
Digital Value

# Page. 10

![Page Image](https://bcdn.docswell.com/page/L71YP1LXJG.jpg)

| 型を作る
設計資料の作成から始め、実装・テストへ広げた
最初の適用先は、人がレビューで確かめやすい設計資料の作成。
使い方の型が見えた後、API層・Service層の実装、単体テスト生成へ広げた。
設計資料
画面項目定義書
バリデータ仕様書
API URL / IF設計
→
実装
API実装
Service実装
Factory
→
テスト
API単体テスト
Service単体テスト
統合テスト観点
レイヤー×工程ごとの prompts が揃い、AI駆動開発の基本形が見え始めた
Digital Value

# Page. 11

![Page Image](https://bcdn.docswell.com/page/G7WG28VKE2.jpg)

| 詳細事例
代表例：単体テスト生成 prompts に足りなかったもの
最初の prompts は、当時の一般的なプロンプト設計に沿ったものだった。
それでも、実案件では期待どおりの出力にならなかった。
※ これは単体テスト固有の話ではなく、チームの合格基準をAIに渡す進め方の代表例
書き方が揃わない
テストメソッド名や属性の書き方が揺れる
観点が足りない
enum 分岐などのパターンが網羅されない
余計なものを作る
分岐していない値だけを変えたテストデータが増える
頼んでいないことまでやる
本来のタスク範囲を超えて別のコードまで生成する
足りなかったのは、一般的なベストプラクティスではなく、チーム固有の合格基準だった
Digital Value

# Page. 12

![Page Image](https://bcdn.docswell.com/page/4JZLD84NE3.jpg)

| 詳細事例
4つの改善で、prompts は workflow になった
実案件でうまくいかない点を直し続け、prompts はAIと人間の役割分担を含む workflow へ育った。
実案件での4つの改善
書き方が揃わない →
① 既存の類似テストを参照させる
観点が足りない →
② 生成前に、人が設計を承認する
余計なものを作る →
③ 失敗を良い例・悪い例として固定する
頼んでいないことまでやる →
④ タスク範囲を明示する
→
---
agent: agent
description: 単体テスト生成
tools: [編集, 実行, 検索, ナレッジ参照MCP, コード検索MCP]
---
# 目標
対象クラスの単体テストを、チームの標準形式で作成
# 手順
1. 既存の類似テストを取得し、参考にする (①)
2. テスト設計だけを出力し、人の承認を待つ (②)
3. 承認後にテストコードを生成する
4. ビルドとテスト実行で検証し、結果を報告する
# ルール・制約
- 良い例・悪い例 (実際の失敗を固定) (③)
- タスク範囲外の実装は禁止 (④)
強い命令を書くのではなく、チームの合格基準をAIに渡すことが重要だった
Digital Value

# Page. 13

![Page Image](https://bcdn.docswell.com/page/YE6W1P39EV.jpg)

| 基盤の全体像
prompts だけではなく、参照フローも整える
workflow の手順には「既存の類似テストを取得する」と書いた。
AIが必要な情報にたどり着けなければ、この workflow は動かない。
prompts / workflow
手順の中から参照
→
MCP
→
設計書・仕様書
社内 Wiki
既存コード・既存テスト
リポジトリ・テスト計画
API 異常系設計
Excel
MCPで、prompts からこれらの文脈へたどり着ける状態にした
Digital Value

# Page. 14

![Page Image](https://bcdn.docswell.com/page/GE5M4KLDE4.jpg)

| 基盤の全体像
私たちのAI駆動開発基盤：3つの設計が、仕組みになった
何を渡すか
コンテキスト・実例・規約
MCPで参照する設計資料・既存コード
良い例・悪い例
常時参照されるコーディング・テスト規約
何をださせるか
作業ごとの prompts
期待する出力と手順を
テンプレート化して共有
人がどこを判断するか
workflow の承認ポイント
設計 → 承認 → 生成 →
ビルド・テスト実行 → 結果確認
最初から設計し切れたわけではなく、実案件でうまくいかない点を直しながら、この形にたどり着いた
Digital Value

# Page. 15

![Page Image](https://bcdn.docswell.com/page/9729VW3MJR.jpg)

ここまでは、先行チームが
小さく型を作った話。
先行チームの中では、AI駆動開発が回る状態になった。
ただしこれは、まだ先行チームに閉じた話でもあった。
複数のチームで再現できて初めて、開発プロセスの型と言える。
ここからは、その型を
展開先チーム - 北國クラウドバンキングの開発を行う2チーム - へ広げた話です。
Digital Value

# Page. 16

![Page Image](https://bcdn.docswell.com/page/DJY43L1P7M.jpg)

| チームへ広げる
配るのではなく、伴走して広げる
展開先チームにとって、AI駆動開発は初めての進め方。prompts を渡すだけでは、使い方までは伝えられない。
そこで、先行チームのメンバーが各チームに入り、ペアプロ・モブプロで一緒に開発しながら広げることを試みた。
先行チーム
メンバーが各チームに入る
→
① 約1か月 (2 Sprint) 伴走
→
展開先チーム1
ペアプロ・モブプロで一緒に開発
② 約1か月 (2 Sprint) 伴走
→
展開先チーム2
ペアプロ・モブプロで一緒に開発
※ 説明会ではなく、実案件のタスクを題材に
AI駆動開発の進め方を、
実際の開発タスクの中で一緒に体験してもらった。
Digital Value

# Page. 17

![Page Image](https://bcdn.docswell.com/page/V7NYV42ME8.jpg)

| チームへ広げる
伴走で見えた、3つの課題
課題1
インプットの差
チームごとに、ドキュメントの粒度や参照する
補足資料が違う。同じ prompts でも、出
力が揺れる。
課題2
AIを使う習慣
一緒にやれば、その場では使える。でも、普
段の開発の中で使う習慣としては定着し
らない。
課題3
prompts を調整するスキル
実際の開発では、タスクに合わせて
prompts を調整する場面がある。そのス
キルは、伴走だけでは身につききらない。
先行チームの型をそのまま渡すだけでは、各チームで再現できなかった
Digital Value

# Page. 18

![Page Image](https://bcdn.docswell.com/page/YJ9P6Q1W73.jpg)

| 定着させる
課題を解消する場として、AI推進定例を始めた
一緒にやって見せるだけでは、普段の利用は定着しきらなかった。
だから、各チームとコミュニケーションを取り続けるアプローチを選んだ。
場の設計
毎週開催 - 利用が定着するまで
各チームから1〜2名が参加
開発者・チームリーダー
毎週決めること
課題にどう対応するかと、その優先度
作る prompts と担当
各チームで試すこと
※ AI利用を前提にしたタスクアサインなど、まず「AIを使う場面」を普段の開発に作る工夫も重ねた
決めて終わりではなく、翌週に結果を持ち寄って、また決める - この繰り返しで課題を解消していった
Digital Value

# Page. 19

![Page Image](https://bcdn.docswell.com/page/GJ8DZG4RJD.jpg)

| 定着させる
定例で検討を重ねながら、4つの取り組みを進めた
目的は、各チームがAIを普段の開発で使い、課題を自分たちで改善できる状態を作ること。
① インプットを整理し、粒度を揃える - チーム間の「インプットの差」を解消
② AI駆動開発を進める優先度を定める - 効果の出る工程から順に
③ 各チームが、担当工程の prompts を作る - 使う側から、作る側へ
④ 共通基盤と改善ループを回す - 作った prompts を全チームの資産に
ここからは、この4つの取り組みを順に見ていく
Digital Value

# Page. 20

![Page Image](https://bcdn.docswell.com/page/LJLMDG62ER.jpg)

| 定着させる
取り組み①：AI駆動開発に必要なインプットを整理する
開発工程ごとに「AIに何を渡すか」を洗い出し、
どの設計書を・どの粒度で用意するかを、各チームと合意しながら揃えていった。
画面項目定義書
画面イベント設計
URL設計
バリデータ仕様
エラー設計
ロバストネス図
APIインターフェース
Serviceインターフェース
テスト設計
※ 資料は各工程の代表例。ほかに既存コード（見本コード）・Figma・OpenAPI 定義などもインプット
prompts を揃えるだけでなく、インプットの粒度も揃える必要があった
アジャイルでも設計資料を残し、メンテナンスする文化がAIへ文脈を渡す土台になった。
Digital Value

# Page. 21

![Page Image](https://bcdn.docswell.com/page/47MYPQ597W.jpg)

| 定着させる
取り組み②：AI駆動開発を進める優先度を定める
導入フェーズは、効果が出やすい領域から。
一次リソース - AIに渡せる設計書や既存コード - があるかで優先度を定めた。
優先度 1
実装
設計資料・見本コードが揃って
いる
2
詳細設計
前段の設計資料から作れる
3
テスト
設計資料と実装コードが入力
になる
4
基本設計
前段の資料が薄く、検討の比
重が大きい
※ 一次リソースのない新規の検討タスクや、作図系・効果の薄い定型作業は、優先度を下げた
優先度を定め、効果が出るところから早く見せることで、広げる足場を作った
Digital Value

# Page. 22

![Page Image](https://bcdn.docswell.com/page/P7R91839E9.jpg)

| 定着させる
取り組み③：各チームが、担当工程の prompts を作る
有識者が作って配るのではなく、
工程ごとに担当チームを決め、各チームが作る体制にした。
担当割り当ての例（チーム名は説明用）
APIインターフェース検討
統合テストケース作成
API実装
展開先チーム1
展開先チーム2
狙い
使い方を“受け取るだけ”にしない
自分たちの工程に合わせて考える
チームごとの違いを自分たちで吸収する
使う側から、作る側へ - 作る過程で「prompts を調整するスキル」がチームに育つ
Digital Value

# Page. 23

![Page Image](https://bcdn.docswell.com/page/PJXQY8437X.jpg)

| 定着させる
取り組み④：共通基盤に集め、使いながら改善する
各チームが作った prompts・規約・使い方ガイドは、共通基盤に集約。
作って終わりではなく、使って見えた課題を反映し続ける運用にした。
使う
実案件で prompts を利用
→
記録する
課題・改善要望を残す
→
反映する
共通 prompts に反映
反映された prompts を、次の実案件でまた使う
実際に挙がった改善の例：
「設計書内のリンク先も参照してほしい」
→ 参照手順を prompts に追加
「単体テストのテストデータで配列生成が苦手」
→ 実装済みコードを参考例として追加
先行チームに閉じていた「使いながら直す」が、チームを跨いだ改善ループになった
Digital Value

# Page. 24

![Page Image](https://bcdn.docswell.com/page/3JK93KZNJD.jpg)

| 成果
成果：開発ペースは、平均で約1.5倍になった
生成AIを使う前提の開発が各チームへ広がり、開発ペースは平均で約1.5倍になった。
約1.5倍
導入前後倍率の平均（開発ペース=スプリントあたりのポイント消化量）
チーム差は残っている - だから、共通基盤と改善ループを回し続けている
Digital Value

# Page. 25

![Page Image](https://bcdn.docswell.com/page/LE3WGZDZE5.jpg)

| 成果
バーンダウンで見ると、開発期間は約1年の短縮見込み
スプリント単位では約1.5倍。プロダクト全体のバーンダウンで見ると、
導入前のペースでは2028年10月頃だった完了見込みが、約1年前倒しの見込みになった。
残りポイント（目盛りは非表示）
実績
AI駆動開発 導入
現在
導入前のペースでの見込み
現在のペースでの見込み
約1年前倒し
2025
2026
2027
2028
2028年10月頃
2027年 秋頃
Digital Value

# Page. 26

![Page Image](https://bcdn.docswell.com/page/8EDK1RP47G.jpg)

| 成果
「使える状態」は、「使われる状態」になったか
始める前 - なぜ、定着しなかったのか
使い方が、個人の工夫に依存していた
いつ・何に・どう使うかが未整理だった
チームの基準をAIに渡す方法がなかった
良い使い方をためて、共有する場所がなかった
→
→
→
→
いま
使い方を、チームの誰もが再現できる
工程ごとに prompts があり、使いどころが決まっている
workflow が、合格基準ごとAIに渡す
共通基盤にたまり、使いながら改善され続ける
利用も生成AIに関心の高い一部にとどまらず、多くの開発者が普段から利用。PMOにも広がった。
Digital Value

# Page. 27

![Page Image](https://bcdn.docswell.com/page/V7PKQWNVJ8.jpg)

| 展望
今後の展望：時代に合わせて、型をアップデートし続ける
ツールに依存しない形式へ
prompts を skills 化し、開発者が成果を出しやすいAIツールを選べるようにする
共通基盤の配布を自動化する
今は各リポジトリへ手作業で反映している。APMでパッケージとして配布・更新できる形へ
改善ループの対象を広げる
各チームから生まれる効率化系の skills も、共通基盤へ統合していく
設計・生成・検証を、より自律的に回す
workflow を Agent Loop へ進化させ、生産性をさらに引き上げる
一定の成果は出た。それでもまだ道半ば - 開発を加速させ続ける
Digital Value

# Page. 28

![Page Image](https://bcdn.docswell.com/page/2JVV58KRJQ.jpg)

一緒に働く仲間を募集しています
今日お話ししたAI駆動開発の基盤づくりに、完成はありません。
AIの進化に合わせて、開発のやり方もこれからも進化していきます。
だからこそ、この続きを一緒に進める仲間を探しています。
AI駆動開発の基盤づくり
金融システムの内製開発
開発プロセス改善
チームでのものづくり
アジャイル・スクラムでのチーム開発
AI Agent を取り入れた開発環境
この続きが気になった方は、ぜひお声がけください。
DigitalValue 採用ページ
Digital Value