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

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

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

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

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

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

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

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

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

| 型を作る 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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