設計書なし・コード一部消失の基幹システムを、AIが2カ月で解析——カクヤスの事例から見えること
創業100年の酒類販売会社カクヤスが、誰も読めなくなった30年前の基幹システムをAIで解析し、450人月の作業を2カ月に短縮した。この話はフィクションではなく、AWS Summit Japan 2026で語られた実例だ。
出典: 老舗酒販の基幹システム、450人月かかる分析を2カ月で完了 創業100年のカクヤス、難解AIで読む「遺産」：AWS Summit Japan 2026
要点 (事実のみ)
- カクヤスの基幹システムは約30年前にVisual Basic（現VB.NET）とOracleで構築。設計書がなく、ソースコードの一部も消失した状態だった
- 2025年に保守ベンダーへの依存が限界に達し、VMwareのサポート終了（2027年7月）も重なりマイグレーションが急務となった
- 人手で分析した場合の見積もりは450人月。Amazon BedrockおよびClaude Codeを活用し、2カ月に短縮
- 業務フェーズでは営業・商品・在庫・仕入・配送などの部門から担当者を集め、AIの分析結果を業務知識と照合。2,200画面を業務に必要な800に絞り込んだ
- 本番環境はOracleからAWSへ再構築し、問い合わせで検証可能な仕様として整理している
徐 聖博の見解
この事例を読んで最初に感じたのは、「AIがコードを書いた」話ではなく「AIがコードを読んだ」話である、という点だ。設計書がなく、仕様を知る人間も社内に残っていない——これはカクヤスに限らず、日本中の中小・中堅企業の基幹システムが直面している構造問題だ。私がXincereで受託案件を受ける中でも、同様の状況は珍しくない。
注目したいのは、AI活用を「AI稼働フェーズ」と「業務稼働フェーズ」に明確に二分している点だ。AIがコードから業務ロジックを抽出し、人間がそれを業務知識と照合して正解を確定する。この役割分担は正しい。AIは「ブラックボックスの中身を言語化する速度」において圧倒的だが、「それが本当に正しいか」の判断は、業務を知っている人間にしかできない。2,200画面を800に絞り込む判断も、機能削減ではなく「業務とともに生きるための構造の再設計」と説明されているのは誠実だと思う。
一方で、私が実装・運用視点から気になるのは、再構築後のAWS上の構成がどの程度のテスト密度で担保されているかだ。旧システムからの移行では、暗黙の業務ロジックがデータの持ち方に埋め込まれていることが多く、AIが抽出した仕様と実際の振る舞いの間にギャップが生じやすい。「問い合わせで検証可能な仕様」という表現は方向性として正しいが、そこに至るまでの検証設計がどれほど厳密かが、プロジェクト成否を決める。
発注側の企業にとって取り組みの本質的な示唆は一つだ。レガシー問題の本質は技術の古さではなく、「誰も全体を知らない」状態になっていることにある。AIはその状態を打破する有力な手段だが、業務担当者が結果を検証できる体制を並走させなければ、AIが生成した"もっともらしい仕様"が新たなブラックボックスになりかねない。
(編集レンズ: 実装・運用視点 / 発注側・中小企業への含意)
