「触れない基幹システム」をAIエージェントで刷新する——海外事例と千葉銀行グループに見る現実的な進め方
「触るとどこが壊れるか分からないので、誰も手を入れていません」——ある中堅企業の情シス担当者からそう伺ったことがあります。仕様書はなく、書いた本人はすでに退職している。この記事では、そんな「触れない基幹システム」にAIエージェントで向き合った海外・国内の実例から、私たちが中堅企業の現場で実践している刷新の進め方までをお伝えします。
- 01「触れない基幹システム」を抱えているのは大企業だけではない
- 02アルバータ州政府が示した数字——巨大な行政システム群を20時間で評価した中身
- 03なぜ「6.5年」が「20時間」になるのか——4段階プロセスの中身
- 04日本にも同じ動きがある——千葉銀行グループの「12.5人月が2.0人月」
- 05人間のオーナーシップをどう設計するか——「AI任せ」が招く手戻り
- 06「50体のエージェント」を中堅企業のスケールに翻訳する
- 07レッドチーム・ブルーチームの発想を、専任チームがない会社でどう実装するか
- 08「塩漬け」の本当のコスト——放置している企業が見落としているもの
- 09コンサル・SIer・FDEでレガシー刷新はどう違うか
- 10AI-Pathの見解——FDE伴走モデルでのレガシー刷新プロセス
- 11よくある質問
- 12まず試すなら
- 13参考リンク
「触れない基幹システム」を抱えているのは大企業だけではない
読者のなかにも、心当たりのある方がいらっしゃるかもしれません。20年、30年と稼働し続けている基幹システム。作った人はすでにいない。仕様書もない。自動テストもない。それでも毎日の業務はそのシステムの上で回っている——だから誰も手を出せません。
正直に申し上げると、この状況は珍しいものではありません。私たちが商談で伺う中堅製造業の7割以上が、似たような悩みを抱えています。ある製造業のDX推進担当者は、社内開発の停滞について「個別にプログラミングで作ったシステムの運用・管理が昔からの課題」と話してくれました。加えて「設計側がなかなか進まない」とも打ち明けています。生成AIの利用が情報システム部門に限定される一方、経営層からは「なぜアウトプットが出てこないのか」というプレッシャーがかかる。板挟みになっている担当者は、私たちが思う以上に多いというのが実感です。
「レガシーシステム 刷新 AI」「Claude Code レガシー」「基幹システム モダナイゼーション AI」といった言葉で検索してこの記事にたどり着いた方は、すでに「本当にAIエージェントで刷新できるのか」という懐疑と、「できるとしてどう進めるのか」という実務的な関心の両方をお持ちのはずです。この記事では、海外の大規模事例と国内の実例を材料に、その両方にお答えします。
アルバータ州政府が示した数字——巨大な行政システム群を20時間で評価した中身
この状況に変化の兆しを与えたのが、Anthropicが公開したカナダ・アルバータ州政府の事例です。同州の技術革新省は、27の州政府部門にまたがる約1,280のアプリケーション、3,400のコードリポジトリを抱えていました。合計コード量は4億6,600万行。従来の手法であれば、セキュリティレビューだけで約6.5年を要する規模だったといいます(Anthropic公式発表より)。
同州はここにClaude(OpusとSonnetの複数モデル)を投入し、約50のエージェントを自律的に並行稼働させました。ルールエンジンで既知の脆弱性パターンを抽出したうえで、各パスごとに約95のセキュリティ管理項目を詳細レビューする。この体制により、6.5年規模の作業を約20時間で完了させたとAnthropicは報告しています。技術的負債の規模は数十億ドル相当と試算されており、それだけの負債が積み上がるまで「触れない」状態が放置されていたことになります。象徴的なのは、25年前にJavaで5ヶ月かけて開発されたシステムのプロトタイプを、同じくAnthropicの発表によればわずか4〜5日で再構築できたという事例です。つまり、レガシーの「読み解き」にかかる時間そのものが、桁違いに圧縮されつつあるということです。
なぜ「6.5年」が「20時間」になるのか——4段階プロセスの中身
数字だけを見ると魔法のように感じられますが、実際の進め方はいたって地道です。報告されているプロセスは大きく4段階に分かれています。まず静的ルール分析で既知の脆弱性パターンを機械的に抽出する。次にAIエージェントが該当ファイル・該当行・問題内容を人間が読める形でレビューする。そのうえで修正コードを生成し、テストとビルドを回し、最後に人間が確認する。複雑なケースでは、新しい言語での再構築にまで踏み込みます。
ここで重要なのは、AIが「全部読んで、全部直した」わけではないという点です。機械的に判定できる一次スクリーニングと、人間が確認する工程が明確に分離されています。これは私たちが以前の記事でお伝えした「並列実行のボトルネックはAIの数ではなくレビュー速度である」という結論とも重なります。台数を増やす前に、どこまでを機械に任せ、どこから先を人間が見るかを設計しておく——アルバータ州の事例は、その設計をセキュリティレビューという最もシビアな領域で実践した例だと私たちは捉えています。
日本にも同じ動きがある——千葉銀行グループの「12.5人月が2.0人月」
海外の大規模事例だけでは、「うちには関係ない話」と感じる方もいらっしゃるでしょう。ですが同種の動きは、すでに日本の金融機関でも起きています。千葉銀行グループのIT企業では、既存システムをVB.NETで再構築するプロジェクトにAI駆動開発を組み合わせました。AI開発エージェント「Devin」がプログラム生成と技術的検証を担い、生成AIがドキュメント参照を支援する体制です(@ITの報道より)。
その結果、新規システム開発は当初見込みの12.5人月から2.0人月へ、率にして約82%の工数削減が@ITの報道で伝えられています。既存システムの更新作業についても、4.0人月から1.5人月へと半分以下に圧縮されました。もちろんプログラム言語間の変換プロセスには複雑さが残り、レガシーシステム特有の技術的制約も指摘されています。金融業界は規制・監査の要求が厳しく、システム変更に最も慎重な業界のひとつです。その業界でここまでの数字が出ているという事実は、レガシー刷新がもはや一部の先進企業だけの取り組みではないことを物語っています。
私たちがこの事例から注目しているのは、削減率の大きさそのものよりも、AIエージェントが「新規開発」と「既存システムの更新」の両方で成果を出している点です。ゼロから作るシステムでAIが速いのは当然としても、すでに動いている複雑なシステムの更新でも半分以下に工数が縮んでいる。これは、レガシーコードを読み解く負担こそがAIエージェントの得意領域であることを裏づけていると私たちは考えています。
人間のオーナーシップをどう設計するか——「AI任せ」が招く手戻り
一方で、率直な失敗談も共有しておく必要があります。ある個人開発者は、身元不明のレガシーシステムをClaude Codeで刷新する過程で「理解が浅いまま AI に任せた」「チケットの要件をそのまま実装した」という失敗を重ねたと振り返っています(Zennの記事より)。AIに全部任せて放置した結果、ドメイン知識が抜け落ちたまま実装が進んでしまったといいます。
この方が最終的に導入したのは、「自分が完全に理解できるまで実装に進まない」というルールと、設計レビュー・修正判断・最終チェックという複数の人間介入ポイントでした。これは私たちの現場経験とも完全に一致します。AIは壁打ち相手であり、判断は人間がする——この原則は、エージェントが1体でも50体でも変わりません。台数が増えるほど「とりあえず任せて、あとでまとめて確認すればいい」という発想に流されやすくなりますが、レガシー刷新のような後戻りしにくい領域では、この誘惑にこそ注意が必要です。
「50体のエージェント」を中堅企業のスケールに翻訳する
ここで正直にお伝えしておきたいことがあります。アルバータ州政府の事例をそのまま中堅企業に持ち込むことはできません。50体のエージェントを同時に動かす体制も、専任のセキュリティチームも、多くの中堅企業には存在しないからです。
私たちがFDEとして現場に入るときに実践しているのは、この設計思想を規模に合わせて縮小することです。実際の進め方は、まず1つ目のエージェントに影響範囲の小さい周辺モジュールを読ませ、依存関係の地図を作らせるところから始めます。次に2つ目のエージェントが、その地図をもとに変更候補に優先順位をつける。最後の1体が、実際の修正コードを小さな単位で提示し、テストを回します。合否を機械的に判定できる単体テストとシナリオテストの領域を先に仕分け、実際に画面を触らないと分からない部分だけを人間の確認に残す。これは私たちが自社のプロダクト開発で徹底している役割分担そのものです。台数の規模は違っても、「機械に任せる範囲」と「人間が見る範囲」を先に決めるという設計原則は、規模に関わらず同じだというのが私たちの実感です。
レッドチーム・ブルーチームの発想を、専任チームがない会社でどう実装するか
アルバータ州の事例では、レッドチーム(攻撃者視点での調査)とブルーチーム(国際セキュリティ基準との照合)のエージェントが継続的に稼働していました。専任チームを置けない中堅企業では、この発想をどう小さく実装すればよいのでしょうか。
私たち自身がAIPLA(自社の業務基盤)で実践しているのは、機能単位でのアクセス権分離と、顧客の自社環境へ移行する前の攻撃テストです。本番環境にはIP制限を入れ、AIが作るコードの品質は単体テスト(Vitest)とシナリオテスト(Playwright)で自動的に担保します。ただしユーザー受け入れテスト(UAT:実際にユーザーが触って合否を判断する工程)だけは、AIが苦手とするUXの観点を含むため、あえて人が担う工程として残しています。Claude Codeを社内導入する際のガードレールとして、機密ファイルを.claudeignoreで除外し、危険なコマンドをHooksで事前にブロックし、本番データベースの変更には人間の最終承認を必須にするという実践も報告されています(Qiitaの記事より)。専任チームがなくても、設定と運用ルールでかなりの部分をカバーできるということです。
「塩漬け」の本当のコスト——放置している企業が見落としているもの
レガシーシステムを刷新しない理由として最もよく聞くのは、「今動いているから」という消極的な現状維持です。ですが、この判断には見落とされているコストがあります。ある中堅の製造業では、生産管理のノウハウが特定の担当者の頭の中にしかなく、その方が異動や退職をすると業務が止まりかねないという不安の声を、私たちは複数回耳にしてきました。属人化は、システムが古いこと自体よりも、システムを理解している人がいなくなることのほうがはるかに大きなリスクです。
誤解のないように申し上げると、私たちは「古いシステムは今すぐ全部作り直すべきだ」と主張しているわけではありません。むしろ逆です。全面刷新を急ぐと、かえって手戻りが増えることのほうが多いというのが実感です。大切なのは、影響範囲が大きく緊急度の低い箇所から少しずつ着手し、機械的に判定できる部分から仕分けていくことです。塩漬けにし続けるコストと、小さく始める刷新のコストを、一度きちんと比較してみる価値はあります。
比較の軸は3つあると私たちは考えています。ひとつ目は、担当者が異動・退職したときの業務停止リスク。二つ目は、新しい機能を追加するたびに調査だけで数週間かかる機会損失。三つ目は、セキュリティパッチが当てられないまま放置される脆弱性リスクです。この3つは、決算書には載らない「見えないコスト」ですが、放置するほど静かに膨らんでいきます。私たちが業務プロセス診断(BPR)で最初に確認するのも、実はこの見えないコストの棚卸しです。
コンサル・SIer・FDEでレガシー刷新はどう違うか
レガシー刷新をどこに相談すべきか、選択肢を整理しておきます。3者は役割も責任範囲も異なります。
| 得意なこと | 弱点 | 責任範囲 | |
|---|---|---|---|
| コンサル | 現状分析・改善提案書の作成 | 提案書止まりで実装は別発注になりやすい | 提案まで |
| SIer(システムインテグレーター) | 大規模な要件定義・発注管理 | 見積もりが数年単位になりがち、AI活用のノウハウが薄い | 契約範囲の実装 |
| FDE(フォワードデプロイドエンジニア:現場に入り込んで実装まで担うエンジニア) | 現場に入り込み、AIエージェントを使いながら実装から定着まで | 大規模一括受注のような契約形態には向かない | 定着化まで |
私たちがFDEとして選ばれる理由は、提案と実装が分離しないことにあります。コンサルが「刷新すべきです」と報告書を出しても、実際にコードを書き、テストを整備し、現場に定着させるところまでは別の担当になってしまうことが少なくありません。レガシー刷新のように「触ってみないと分からない」領域では、提案と実装の間に人が変わること自体が手戻りの原因になります。
AI-Pathの見解——FDE伴走モデルでのレガシー刷新プロセス
私たちの現場経験では、レガシー刷新で最も差が出るのは技術力ではなく、進め方の設計です。コンサルが提案書を書いて終わるのに対し、私たちFDEは現場に入り込み、実際に本番コードを書きながら移行まで責任を持ちます。まず影響範囲を洗い出し、テストのない箇所から自動テストを先に整備する。そのうえでAIエージェントに小さなモジュール単位で修正案を出させ、人間が確認する範囲を段階的に広げていきます。
この進め方は、私たちが日頃取り組んでいる業務プロセス診断(BPR)とも地続きです。私たちは代表自作の業務整理ツールを使い、ヒアリングから業務フロー・改善案・投資対効果までをたたき台として一気に可視化するところから始めます。全社で一気にシステムを刷新する前に、まずどの業務にAIが効くのかを棚卸しする。レガシーシステムについても同じで、「全部を今すぐ作り直す」のではなく、「どこから着手すれば手戻りが少ないか」を先に見極めることが、遠回りに見えて最も確実な進め方だと私たちは考えています。中小企業であれば、省力化補助金・AI活用補助金を使って初期負担を抑えながら進める選択肢もあります。
よくある質問
Q. AIにレガシーコードを読ませるだけで、本当に安全なのでしょうか。 A. 読ませる段階と、直させる段階を分けて考える必要があります。アルバータ州政府の事例でも、修正コードの生成後にテスト・ビルド・人間の確認という工程を経てから本番に反映しています。「読ませて終わり」ではなく、「読ませたあとに誰が確認するか」の設計が安全性を左右します。
Q. 仕様書もテストもない状態からでも始められますか。 A. むしろそこが出発点です。私たちが現場に入るときも、まず現状の業務フローと処理を洗い出し、最低限のテストを整備するところから着手します。仕様書がないことは刷新を諦める理由にはなりません。
Q. どのくらいの規模の会社でも現実的ですか。 A. 私たちが実際に伴走しているのは、従業員300〜5,000名規模の中堅・中堅上位の製造業が中心です。50体のエージェントは必要なく、2〜3体規模から始めて実績を積み重ねる進め方で十分に効果が出ています。
Q. コンサルにすでに現状分析を依頼しています。今から相談する意味はありますか。 A. 十分にあります。現状分析の報告書があるなら、私たちはその続きから着手できます。むしろ分析済みの状態から入れるほうが、私たちにとっても現場にとっても手戻りが少なく進められます。
まず試すなら
- 触れていない基幹システムを1つ、具体的に思い浮かべる——「なぜ誰も触っていないのか」を書き出すだけで、着手すべき優先順位が見えてきます
- 仕様書がない箇所から、最低限のテストを整備する——AIエージェントに任せる前に、合否を機械的に判定できる土台を作ります
- 無償の業務プロセス診断(BPR)を活用する——AI-Pathでは、どの業務・どのシステムにAIが効くのかを無償で診断しています。まずは現状の棚卸しから始めることをお勧めします
関連記事: AIエージェントを並列実行する「エージェントマネージャー」という働き方 関連記事: FDE・コンサル・SIer——AI導入パートナーの選び方と、3者の根本的な違い
参考リンク
櫻井 文雄（さくらい ふみお） 株式会社AI-Path 代表取締役CEO
関西大学法学部法律学科卒業。財務コンサルティング会社（エフアンドエム）、外資系生保営業（Prudential）でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング（Big4）、ABEJA（AI研究開発の国内リーディングカンパニー）にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発（VibeCoding）と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
経営層がAIを使わないと現場は動かない——「腹落ち」をどう作るか
代表・役員の85.7%がAIの方針も体制も持たないまま「使わない」企業。この構造を、私たちがFDEとして現場に入ってきた経験から読み解き、経営層の『腹落ち』をどう作るかを具体的に整理します。
AIエージェントの運用体制をどう作るか——「新入社員」として迎える発想の落とし穴
「AIエージェントを新入社員として迎えよう」という提案が広がる一方、2026年5月のハーバード・ビジネス・レビューはこの発想に警鐘を鳴らしました。AI-PathがFDEとして製造業の現場で見てきた、AI運用体制が定着する組織と崩れる組織の分かれ目をお伝えします。
AIで成果を出す組織の設計——人材採用より先に整えるべき3つの仕組み
「AI人材が欲しい」という相談が急増しています。しかしAI活用で本当の成果を出している企業はわずか6%。差は人材の数ではなく、仕組みにあります。BPRと連動した「採用より先に整えるべき3つの仕組み」をAI-Pathの現場経験からお伝えします。