設計書なし・コード一部消失の基幹システムを、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が生成した"もっともらしい仕様"が新たなブラックボックスになりかねない。
(編集レンズ: 実装・運用視点 / 発注側・中小企業への含意)
発注側が同じことをやる場合の進め方
「450人月が2カ月」という数字だけを持ち帰ると、たいてい失敗する。この事例が成立した条件を分解すると、再現に必要なのは次の4つである。
1. 解析対象を先に絞る。 カクヤスは2,200画面を業務に必要な800に絞り込んでいる。全部を解析対象にすると、使われていない画面の仕様まで復元することになり、コストが跳ね上がる。着手前に「今も使っている業務」を業務部門と確定させるほうが早い。
2. 業務部門を巻き込む体制を先に作る。 AIが抽出した仕様の正誤を判定できるのは業務担当者だけである。営業・商品・在庫・仕入・配送から担当者を集めた体制が先にあったからこそ、AIの出力が検証可能になった。ここを情シスだけで進めると、検証待ちで止まる。
3. 検証の設計を実装より先に決める。 旧システムには、暗黙の業務ロジックがデータの持ち方に埋め込まれていることが多い。「新旧で同じ入力に対して同じ出力になるか」を機械的に比較できる仕組みを、移行実装より先に用意する。ここを後回しにすると、リリース後に差分が出たときの切り分けができない。
4. 期限から逆算する。 カクヤスの場合、VMwareのサポート終了（2027年7月）という外部要因が意思決定を後押ししている。逆に言えば、期限が無いレガシー刷新は永久に始まらない。保守ベンダーの契約更新やOS・ミドルウェアのEOLを、着手の締切として使うのが現実的だ。
刷新全体の進め方はシステム刷新の進め方｜検討・計画から移行までの方法、体制と契約の考え方は要件定義は準委任契約が基本にまとめている。
「AIが読める」ことで何が変わり、何が変わらないか
変わるのは現状把握のコストである。設計書が無いシステムの仕様を人間が読み解く作業は、これまで見積もりの大部分を占めていた。ここが桁で圧縮されると、レガシー刷新の意思決定そのものが変わる。「調査だけで数千万円」が理由で塩漬けにされていた案件が、検討テーブルに戻ってくる。
変わらないのは業務をどうしたいかを決める工程である。2,200画面を800に絞る判断は、AIには出せない。どの業務を残し、どれをやめるかは経営判断だからだ。この構造は「言われた問題」を疑い、開発しない選択肢まで考えるDXの進め方や「使われないシステム」が生まれる要件定義の失敗と同じである。
つまり、AIによって短縮されるのは工程の前半であり、判断の総量は減らない。レガシー刷新の見積もりを取るときは、解析工数の削減幅だけでなく、業務側の意思決定にどれだけ時間を割く前提になっているかを確認したほうがいい。
よくある質問
Q. 設計書が無い基幹システムでも、AIで解析できるか。
A. ソースコードが残っていれば解析の出発点にはなる。ただし、AIが出すのは「コードがこう書かれている」という事実であって、「業務としてそれが正しい」ではない。業務担当者による検証を並走させられるかが、実施可否の分かれ目になる。
Q. どのくらいの期間・費用を見ておけばよいか。
A. 対象システムの規模と、コード・データの残存状況で大きく変わるため一律の数字は出せない。判断材料になるのは、見積もりが「解析」「業務確定」「移行実装」「検証」に分かれているかどうかである。解析工数だけが安く、業務確定と検証の工数が薄い見積もりは、発注側の負担が見えていない可能性が高い（システム開発の見積もり完全ガイド）。
