既存業務システムの保守現場では、AIによるコード生成を試すだけでなく、既存のコーディング規約、テストの実行結果、業務部門による確認や承認、成果物の版管理といった一連の流れにどう組み込むかが課題になります。2026年11月、Amazon Web Services（AWS）はニッセイ情報テクノロジーにおけるAI駆動開発の取り組みを紹介する記事を公開しました。2026年9月に開催されたワークショップ「AI-DLC Unicorn Gym」と同年10月のインタビューをもとに、個人保険基幹系システムの帳票改修へAIを適用した構成と、その後の検証状況が報告されています。
単一システムで完結する通知帳票改修から試行
ニッセイ情報テクノロジーの個人保険システム事業部では、AIを開発ライフサイクル全体に組み込む手法「AI-DLC（AI-Driven Development Life Cycle）」の実践に向け、内製ツールと「AI-DLC Workflows 2.0（v2）」を組み合わせた検証を進めています。最初の題材として選ばれたのは、法人向け通知帳票を作成するシステムの改修でした。機能が単一システムで完結し、改修結果が帳票イメージとして目に見えることが選定理由として挙げられています。
この帳票案件は、契約内容欄や図で示す欄への項目追加など、前後の依存関係を持つ7つの改修（Intent）に分割されました。3日間のワークショップでは、前の改修を前提としながら順に進め、そのうち2つの改修を完了したと報告されています。横井氏は、作業自体の速さ以上に、所管部門と開発部門が同じチームでAIの成果物をその場で判断し、確認待ちの時間をなくせたことが2つの改修を終えられた要因だったと振り返っています。
業務知識の正本参照と内製ツールによる実行結果の担保
改修の精度を高めるため、同社は業務知識の扱いとツールの実行方法に独自の工夫を施しています。Excelなどで作成されてきた業務文書はMarkdownへ変換したうえで、人が内製エディタで修正して整え、作業用とは別の業務知識用リポジトリに登録しています。確定した成果物も同リポジトリに蓄積され、検索可能な知識として後続の案件で再利用される設計です。こうした成果物の蓄積は、計画や要件、設計成果物をリポジトリに保存してセッションをまたいで文脈を維持するという、AWSが提唱するAI駆動開発ライフサイクルの方法論とも方向性を同じくしています。
また、コーディング規約や区分値などのコード表は、社内で管理されている正本をそのままAIエージェントに参照させています。ソース取得や構文チェック、ビルド、テストといった定型作業は内製ツールで実行し、推測ではなくツールが返した実際の結果をもとに成否を記録する指示です。これらのツールはAI経由だけでなく、ブラウザ画面の右クリックメニューからも直接呼び出せる構成になっており、機械的な作業は決まった手順で確実に処理する切り分けが行われています。
帳票イメージによる業務確認と承認ゲートの設計
保守開発の実務では、業務部門による確認と承認のプロセスが大きなハードルとなります。今回の試行では、ソースコードとテストデータから帳票イメージを出力する仕組みを用意し、業務を所管する部門が最終的な出力物を目で見て判断できるようにしました。横井氏は、設計書を読み解くよりも判断しやすく、確認のスピードと確かさの両方が上がったと感じたと述べています。
承認依頼や進捗管理にはRedmineのチケットが用いられ、成果物は文書管理プラグインのDMSFに登録して版が管理されています。内製環境ではv2が標準で備える自動フックなどの一部機能が使えなかったため、指示ファイル（ルールファイル）の決まりとして遵守させ、人の承認ゲートを省略せずに進める運用が採られました。
現在進められているPoC（概念実証）では、同じ案件を従来のウォーターフォール開発と並走させて比較検証が行われています。多忙な課長層がすべての工程に参加し続けることは容易ではありません。そのため課長層の承認箇所は、要件を固めて作業単位へ分解するInceptionフェーズで作成したバックログと、後続のテスト工程への引き渡しの2か所に絞り込まれました。それ以外の承認は現場に任せるようにプロセスを整理し、責任範囲を明確にしながら進行を滞らせない工夫を図っています。
国内の保守現場に応用する際の検討手順
この取り組みは大規模基幹システムの事例ですが、得られる知見は中堅・中小企業の業務システム保守にも応用できます。たとえば、国内の卸売会社が既存の納品書に新しい確認欄を追加するような場面が一例です。
まずは対象帳票の仕様書、コード表、テスト用データの正本がどこにあるかを特定し、現在の改修で発生している作業時間と確認待ちの時間を整理します。次に、帳票のレイアウト、印字される計算値、他の出力への影響を誰がどのような形で確認するかを明確にします。既存のビルドやテスト環境が外部ツールから安全に実行できるかを確認したうえで、小さな改修を一つ選び、AIによるコード生成案と既存テストの実行結果、帳票のプレビュー確認、チケットによる承認記録までを一連の流れとして試行・評価してみる進め方が現実的です。
なお、事例で採用されているような内製ツールや指示ファイルによる連携は、一般的な開発環境の設定だけでそのまま再現できるとは限りません。自社で利用可能なAIモデルのセキュリティ条件、チケット管理ツールのAPI仕様、既存システムのテスト実行権限などを個別に確認しながら、必要な連携を検討することが大切です。
既存保守へのAI組み込みと連携のご相談
社内の業務システムやWebシステムの保守において、「AIを活用したいが、テストや承認フローをどうつなげばよいか分からない」とお悩みの場合は、ぜひデノフにご相談ください。デノフのサービス案内でもご紹介している通り、弊社では帳票出力をはじめとする業務システムの設計・開発・運用保守から、業務の整理、AIを活用する領域の選定、導入後の定着支援までを一貫して手がけています。
お客様の保守現場に合わせて、既存のコードやテスト環境、チケット管理ツールとAI支援をどのように接続するか、まずはどの帳票改修を対象に小さな試作を行うべきかといった要件整理から支援いたします。具体的な進め方や導入範囲の検討については、お問い合わせ窓口よりお気軽にお問い合わせください。
