大規模金融系保守開発における AI 適用への挑戦 ── ニッセイ情報テクノロジーが AI-DLC v2 と内製ツールで進める、個人保険基幹系システムの AI 駆動開発

AWS では、AI を開発ライフサイクル全体に組み込み、人が意思決定と承認を担う開発の方法論「AI-DLC（AI-Driven Development Life Cycle）」を提唱しています。2026 年 9 月、日本生命保険相互会社様、ニッセイ情報テクノロジー株式会社様とともに、AI-DLC を実践するためのワークフローの最新版「AI-DLC Workflows 2.0」（以下、v2）を使った 3 日間のワークショップ「AI-DLC Unicorn Gym」を開催しました。

本記事では、まず 1 章で、対談の前提となる AI-DLC、AI-DLC Workflows、AI-DLC Unicorn Gym を紹介します。2 章では、内製の AI エージェントツールと v2 を組み合わせて個人保険の基幹系システムの保守開発に取り組まれた、ニッセイ情報テクノロジー株式会社の横井 拓磨 氏との対談をお届けします（聞き手：AWS 山根）。

1. AI-DLC と AI-DLC Workflows、AI-DLC Unicorn Gym

AI-DLC とは

AI-DLC は、AWS が 2025 年に提唱した開発の方法論です。AI を補助的な道具として後から組み込むのではなく、開発の中心に据えます。AI が作業の計画を立て、不明点を質問し、重要な判断は人に委ねます。人の確認を得てから AI が実行する、という進め方を開発のあらゆる工程で繰り返すことで、品質を保ちながら開発を速めることを目指しています。また、業務部門と開発部門がチームとして集まり、AI の提案をその場で検証しながら進めることを重視しています。

AI-DLC Workflows とは

AI-DLC Workflows は、AI-DLC をコーディングエージェント上で実践するためのワークフローで、AWS が GitHub でオープンソースとして公開しています。2025 年 11 月に公開された最初の版（以下、v1）は、各コーディングエージェントに読み込ませるルールとして提供され、案件に応じて必要なステージだけを実行する考え方を取り入れていました。一方で、各ステージの成果物を人が確認する必要があり、人の処理速度が開発全体の速さの上限になりやすいという課題がありました。また、次に何をするかの判断も AI がルールを解釈して行うため、進め方が AI の判断に左右されることがありました。

2026 年 7 月に一般提供が始まった v2 は、方法論はそのままに、ワークフローの仕組みを作り直したものです。大きな変化は 2 つあります。

1 つ目は、ワークフローの進行や承認ゲートを AI の解釈に任せず、コードで実装したエンジンとフックで決定論的に制御するようにしたことです。次に進むステージはエンジンが決め、承認ゲートでは人の応答が記録されてから次へ進みます。

2 つ目は、人の判断を少しずつ機械に移していく考え方です。v2 の仕様書では、人が判断や検証に費やしている労力の多くは、判断のパターンを機械が実行できる形に落とし込む（仕様書では「蒸留」と表現）ことで減らせる、としています。作業中に人が行った修正を、人の確認を経てルールや自動チェックとして蓄積し、検証できる範囲を段階的に広げることで、人は本当に判断が必要な場面に集中できるようになります。

v1 と v2 の違いは、「AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化」（AWS Builder Center）でも詳しく解説しています。

AI-DLC Unicorn Gym とは

AI-DLC Unicorn Gym は、参加企業が自社の実際のテーマを持ち込み、AI-DLC を数日間で実践する AWS のプログラムです。今回は、日本生命様で業務を所管する部門（以下、所管部門）とニッセイ情報テクノロジー様から 54 名が参加し、7 チームがそれぞれの担当案件（進行中の実案件を含む）を題材に、所管部門と開発部門が同じチームで v2 を使って取り組みました。アンケートでは、満足度 4.35、「AI-DLC は働き方を変える可能性がある」4.52（いずれも 5 点満点）の評価をいただきました。

2. 対談：個人保険の保守開発に AI-DLC を取り込む

ここからは、横井 氏との対談です。AI-DLC に取り組んだきっかけ、内製の AI エージェントツールの仕組み、AI-DLC Unicorn Gym での取り組みと気づき、その後の PoC と社内展開について伺いました。

AI-DLC に取り組んだきっかけ

山根（AWS）：AI-DLC に取り組まれたきっかけを教えてください。

横井：当事業部では、個人保険の販売・新契約から保険金・給付金の支払までを支える、大規模でミスが許されない基幹系システムを保守・開発しています。当社は 1999 年の設立以来、高い品質要求という「壁」に真摯に向き合い、堅牢な開発工程と高い品質力を培ってきました。今後は、その壁を守るだけでなく、品質という強みを活かしながら、開発のあり方そのものを進化させていきます。

生成 AI は、開発そのものを担いうる技術として、その壁を越えてきます。我々にとって避けて通れない変革ですが、いち早くプロセスを見直すことで、むしろ新たな競争力を獲得する好機にもなります。そこで今年度の初めから AI-DLC の適用を研究し、AI-DLC Unicorn Gym をその研究と内製ツールが実案件で通用するかを確かめる場と捉えて参加しました。

内製の AI エージェントツールの仕組み

山根（AWS）：内製された AI エージェントツールについて教えてください。

横井：LLM も AI-DLC Workflows も急速に進化していますが、業務に使うには、業務ドメイン知識の取り込みと、社内の開発環境や業務プロセスへの適応が欠かせません。そこを自分たちで作り込むために、AI エージェントツールを内製しました。

ブラウザから使う Web アプリケーションにしたのは、チームでの共同作業をブラウザでできるようにするためです。業務端末にソフトウェアを導入してもらうより、ブラウザで使えるほうがハードルが低く、社内に展開しやすいという利点もあります。画面は React で作っており、ファイルツリー、文書やコードを表示・編集するビュー、AI とのチャットの 3 つの領域で構成しています。フォルダごとのアクセス制御や、作業中であることを示す編集ロックを備えているので、チームで同じ作業場を共有しながら進められます。公衆インターネットには接続せず、AI の推論には国内リージョンの Amazon Bedrock 経由で Anthropic の Claude モデルを使い、社内のシステムとはプライベートな経路で接続しています。

山根（AWS）：AI エージェントとツールは、どのように動いているのですか。

横井：AI エージェントは Claude Agent SDK で作っています。チャットで依頼を受けると作業を計画し、必要なツールを呼び出して実行します。複雑な作業はサブエージェントに分担させます。ツールは TypeScript で実装した自作の MCP サーバーで、主に次のような機能があります。

• 文書・図の可視化：Office 文書や PDF の Markdown への変換、図の描画、HTML 化、帳票イメージの生成などで、レビューする人が内容を理解しやすい形に整える
• ソースの取得・ビルド・実行：社内のソース管理環境からのソースの取得（依存するソースもまとめて取得できる）、構文チェック、ビルド、テストの実行と項目ごとの結果の判定を、作業ごとに実行する
• 規約・コード表の参照：社内のコーディング規約やコード表（区分値などのコードの一覧）を、社内で管理している正本のまま AI エージェントに参照させる。一般的な知識や記憶で代用させず、規約に沿ってコードを生成・レビューできるようにする
• 作業フォルダとリポジトリの同期：画面のファイルツリーに表示される作業フォルダのファイルを、AWS CodeCommit の作業用リポジトリと同期する
• チケットの操作：Redmine（オープンソースのプロジェクト管理ツール）のチケットを起票し、資料を添付する
• 成果物の登録：Redmine の文書管理プラグイン DMSF に成果物を登録し、版を管理する
• 業務知識の検索：Amazon Bedrock Knowledge Bases を検索する自作のアプリケーションを呼び出し、蓄えた業務知識を検索する

これらのツールは、AI エージェントから呼び出せるだけでなく、画面の右クリックメニューから直接実行することもできます。ソースの取得やビルドのような機械的な作業は、AI を介さずに決まった手順で実行したほうが速く確実で、AI の利用料もかかりません。判断が必要な作業は AI に任せ、決まった作業は直接実行する、という使い分けができるようにしています。

業務ドメイン知識は、Excel などで作られてきた業務ドキュメントを、ドキュメントの形式に応じたプロンプトのテンプレートを使って Markdown に変換し、内製の専用エディタで人が修正して整えたうえで、作業用とは別の業務知識用のリポジトリ（AWS CodeCommit）に登録しています。Push をきっかけに Amazon Bedrock Knowledge Bases への取り込みが実行され、ベクトル化されて意味で検索できるようになる仕組みを、自分たちで作りました。案件で承認を経て確定した成果物も同じリポジトリに登録するので、案件を重ねるほど業務知識が蓄積されていきます。

承認や進捗の管理には、Redmine のチケットと DMSF を使います。承認が必要になると、所管部門にチケットで承認依頼が届きます。毎朝の進捗も、エージェントが Redmine に自動で投稿しています。業務側と開発側の拠点が離れていても、承認や進捗の確認が滞らないようにするためです。

AI-DLC Unicorn Gym で、保守開発の実案件に AI-DLC を使う

山根（AWS）：AI-DLC Unicorn Gym には、どのような題材と準備で臨まれたのでしょうか。

横井：金融機関の開発は、その大半が既存システムの保守開発です。「保守開発でも AI-DLC は使えるのか」という問いに、内製ツールを含めた開発プロセスとして答えることが目的でした。題材には、法人のお客様向けの通知帳票を作成するシステムを選びました。機能が単一のシステムで完結し、結果が帳票として目に見えるためです。

準備は 3 つです。業務ドメイン知識を事前に構造化し、内製ツールから参照できるようにしたこと。ソースコードとテストデータから帳票イメージを出力するツールを用意したこと。そして、33 のステージ（2026 年 9 月実施時）から保守開発に必須のものを選び、独自のスコープとして登録したことです。

題材の案件は、この通知帳票に新しい項目や文言を加える改修です。契約内容の欄や、保険の仕組みを図で示す欄への項目の追加、内容確認用の帳票への反映など、7 つの改修に分かれており、それぞれを 1 つの Intent（v2 で開発を進める単位）としました。前の改修が後の改修の前提になるため、1 つずつ順に進めます。3 日間で、このうち 2 つの Intent を終えることができました。

山根（AWS）：v2 が標準で対応しているコーディングエージェントとは別の、内製ツールの上で v2 を動かしたわけですね。そのために、どのような工夫をしたのですか。

横井：内製ツールの AI エージェントが作業のたびに読み込むルールファイル（以下、指示ファイル）に、この環境での v2 の使い方をまとめました。工程の順番や承認の状態、監査記録は v2 のエンジンが管理するので、エージェントには「v2 のエンジンに次の作業を確かめ、その作業だけを実行して、結果をエンジンに報告する」という手順を繰り返させました。そのうえで、主に次のことを教えました。

• コーディング規約や命名規則は、v2 の一般的な基準よりも、規約・コード表の参照ツールで引いた社内の正本を優先する
• v2 の「既存のコードを調べる」「ビルドしてテストする」といった作業は、内製ツールのソース取得やビルド・実行のツールで行う
• 構文チェックやテストの成否は、推測で書かず、ツールが返した結果をもとに書く
• 標準の対応環境で自動的に働く一部の仕組み（フックなど）は使えないため、その部分は指示ファイルの決まりとして守る。承認ゲートは省略せず、必ず人に確認してから進める

AI-DLC Unicorn Gym の後も、ここで得た経験をもとに、保守開発の現場に合わせてワークフローの改良を続けています。

AI-DLC Workflows 2.0 の評価

山根（AWS）：以前から AI-DLC に取り組まれてきた立場から、v2 をどうご覧になりましたか。

横井：v2 は、エンタープライズの現場で回すことを前提に作られていると感じます。大きくは 3 つです。

1 つ目は、スコープの選択とステージのカスタマイズです。v1 は一本の流れとしての分かりやすさがあった反面、「全部の工程は要らないが、ここだけは絶対に外せない」という保守開発にあてはめるには、こちらで読み替えが必要でした。v2 では案件の性質に応じてスコープを選び、ステージを取捨選択できるので、保守開発に絞った独自のスコープを用意できました。

2 つ目は、承認ゲートです。v2 では承認ゲートが仕組みとして組み込まれていて、人が承認するまで次のステージに進みません。「誰が、いつ、何を見て承認したのか」が明確になることは、説明責任が強く求められる金融業界と相性が良いと感じました。「どこで承認するか」はワークフローが定めます。我々は、承認のやり方を自分たちのプロセスに合わせるため、Redmine のチケットにつなぎました。

3 つ目は、意思決定の記録で、個人的に最も参考になった部分です。内製ツールではここが弱く、何を残すべきかの知見もありませんでした。経緯が自然に記録される仕組みは、監査を重視する業界のカルチャーとも合います。

総じて v2 は、AI で速く作るだけでなく、説明できる形で作るためのワークフローだという印象です。現場に合わせて調整できる余地があらかじめ用意されていたことも、我々が金融の現場で取り込むうえで助けになりました。

3 日間で得られた気づき

山根（AWS）：3 日間で得られた気づきを教えてください。

横井：大きく 3 つあります。1 つ目は、AI-DLC が前提としているとおり、開発の速さを左右するのは人の判断だと、実案件で確かめられたことです。2 つの Intent を終えられたのは、作業の速さ以上に、所管部門と開発部門が同じチームで AI の成果物をその場で判断し、確認待ちの時間がなくなったからでした。AI が速くなるほど、改善すべき課題は人の意思決定や待ち時間に移ります。

2 つ目は、業務ドメイン知識の整備の重要性です。知識が整った領域では、AI の提案の精度が明らかに高く、手戻りも少なく済みました。一方で、長年の改修の中で暗黙知になっている部分は AI には知りようがなく、人が補う必要がありました。AI が既存の資産を理解できるかどうかは、AI の性能以上に、我々がどれだけ知識を言語化・構造化できているかにかかっていると実感しています。案件で承認を経て確定した成果物を業務知識として登録しているのも、こうして人が補った知識を、次の案件で AI が使えるようにするためです。

3 つ目は、人がどこで何を見て判断するかの設計です。今回は帳票をイメージで出力し、所管部門が最終的な出力物を目で見て判断できるようにしました。設計書を読み解くよりも判断しやすく、確認のスピードと確かさの両方が上がったと感じています。

こうした気づきをもとに、AI-DLC Unicorn Gym の後に精査し、通常は 6 名で 6 か月ほどかかるこの案件を、4 名で 3 か月ほどで終えられると見込んでいます。

既存の仕組みを活かしながら、働き方そのものも変えていく。その両方が必要だというのが、3 日間の学びでした。

個人保険システム事業部が先行した理由

山根（AWS）：AI-DLC Unicorn Gym の後、個人保険システム事業部が、社内で AI-DLC の導入に先行して取り組むことになった理由を教えてください。

横井：1 つは、個人保険が当社のお客様にとって最重要のビジネスドメインの一つであり、全社のアプリケーション開発でも大きな割合を占めることです。AI 駆動開発の効果が最も大きく出る領域なので、最初に成果を示すべきだと考えました。もう 1 つは、私が 5 年ほど前に立ち上げた、社内業務の効率化とクラウド人材の育成を目的とする有志の組織で、AWS を使った社内向けの Web アプリケーションを作ってきた土壌があったことです。

また、個人保険だけの特殊な事例にしないよう、同じ技術と開発プロセスを持つビジネスソリューション事業部にも、同じ AI-DLC Unicorn Gym に参加してもらいました。

現在進めている PoC

山根（AWS）：現在進めている PoC について教えてください。

横井：AI-DLC Unicorn Gym と同じ帳票システムで、残りの Intent も含めて完走できるかを、体制、開発期間、品質、開発プロセス、開発環境の観点で検証しています。同じ案件を通常のウォーターフォールとも並走させて比較しています。

進め方も変えました。成果物ごとに 1 週間ほどのレビュー期間を取ることはせず、できたものをすぐに見せて、追加の要望は次の計画の場（プランニング）で取り込みます。また、承認の責任を持つ課長層は多忙で、AI-DLC のすべての工程に参加し続けることはできません。そこで、課長層の判断が本当に必要な箇所に絞って承認いただき、それ以外の承認は現場に任せるようにプロセスを整理し、ワークフローに組み込みました。課長層に承認いただくのは、Inception（要件を固め、作業単位に分解するフェーズ）で作成したバックログと、後続のテスト工程への引き渡しの 2 か所です。承認の際は成果物について AI に質問しながら判断できるので、私も Inception の承認では、成果物のフォルダを指定して AI に質問しながら内容を確認しました。現時点では順調に進んでいます。

ほかの事業部への展開

山根（AWS）：社内にはどのように展開されていますか。

横井：社内の AI-CoE である AI・データ戦略企画推進部からお声がけいただき、企業保険ソリューション事業部や年金ソリューション事業部などへの展開を計画しています。ただ、ツールややり方をそのまま配って「この通りにやってください」と展開するつもりはありません。組織ごとに業務や開発プロセスの事情が違うので、それぞれの組織が自分たちのプロセスに合わせて、自分たちにとって良い形で AI-DLC を取り込んでいくことが大切だと考えています。経験は苦労も含めて伝えつつ、各組織には一度は同じ道のりをたどってもらう方針です。その過程で人が育つと考えています。

3. おわりに

v2 を内製ツールとつなぎ、自分たちの開発プロセスとして取り込む横井 氏の取り組みを、AWS は引き続きご支援してまいります。AI-DLC Workflows は GitHub（awslabs/aidlc-workflows） で公開しており、ドキュメントから v2 の詳細をご覧いただけます。

ありがとうございました。

本記事は、2026 年 9 月 14 日〜16 日に開催した AI-DLC Unicorn Gym、および 2026 年 10 月 14 日に実施したインタビューをもとに構成しました。

著者

山根 英彦
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト