結論：「解析だけで数億円」で止まっていた刷新計画は、前提を再計算すべき段階に入った
酒類販売のカクヤスが、約30年動き続けた基幹システム——設計書はなく、ソースコードの一部も紛失し、「触れない、読めない、直せない」状態——の解析を生成AIで実質2カ月に短縮した事例が、2026年7月3日にITmedia NEWSで報じられました（出典：ITmedia NEWS「“開かずの基幹システム”、450人月→実質2カ月で解読 創業100年のカクヤス、生成AIで挑む『転生』」、2026年7月3日閲覧）。人手で解析した場合の試算は450人月。この数字が実質2カ月に縮んだと講演で語られたことの意味は、一つの成功譚にとどまりません。「中身が分からないから見積もれない」「解析だけで数億円かかる」を理由に刷新を凍結してきた企業にとって、その凍結判断の前提数字が古くなったということです。
影響を受けるのは、ドキュメントが失われた基幹システムを抱え、保守ベンダー依存が常態化している中堅企業の経営者と情報システム部門です。次に確認すべきことは3つ——(1) 自社の「開かずのシステム」のソースコード・DB定義など解析対象資産が手元にあるか、(2) 外部AIにコードを読ませる際の機密区分とAI利用ポリシーが整理されているか、(3) 解析結果を業務の言葉に翻訳できる現場メンバーを出せるか、です。本記事では報道された事例の構造を分解し、自社でやる場合の前提条件と、ベンダーに依頼する場合の見積もり確認点に翻訳します。
なお、本記事の数字はAWS Summit Japan 2026での講演内容を報じたITmedia NEWSの記事（二次情報）に基づきます。450人月・実質2カ月はいずれも同講演で語られた試算・実績値であり、第三者検証された数値ではない点を明記しておきます。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
何が起きたのか：30年物・画面2,200の基幹システムを「両輪」で解読
報道によれば、カクヤスの基幹システムは約30年前に当時のVisual Basic（現VB.NET）とOracleデータベースで構築され、増改築を重ねた結果、2025年には保守ベンダーへの依存が常態化していました。VMwareの契約が2027年7月に切れるという動かせない期限もあり、親会社ひとまいる（2025年7月にカクヤスグループから社名変更し、酒類卸から物流業への転換を宣言）のグループシステム部門特命担当・石井氏がプロジェクトの舞台裏をAWS Summit Japan 2026で語りました。
規模と成果の要点を整理します。
| 項目 | 報道された内容 |
|---|---|
| システム年数 | 約30年（VB＋Oracleで構築） |
| 操作画面 | 2,200 |
| テーブル | 3,000 |
| ストアドプロシージャ | 1,200本 |
| ドキュメント | 設計書なし・コード一部紛失・本番同等の検証環境なし |
| 人手解析の試算 | 450人月 |
| AI解析の実績 | 実質2カ月（Amazon Bedrock上のClaude Codeで1,200本のストアドを解析） |
| 抽出した業務ロジック | 6つ（テーブル間データ移動・在庫評価額計算・売価計算・与信計算・在庫引当・空容器回収） |
| 画面の凝縮 | 2,200 → 業務に必要な約800へ |
（出典：前掲ITmedia NEWS記事、2026年7月3日閲覧）
注目すべきは、AIが単独で解決したのではない点です。講演では「AI駆動開発」と「業務駆動開発」の2本立てだったと説明されています。前者はBedrock上のClaude Codeによるストアドプロシージャ解析と、本番Oracle環境をAWS上に再現して挙動を突き合わせる検証基盤の整備。後者は営業・商品・店舗・物流・経理の各部門から人を集め、AIの解析結果を現場の業務の言葉に翻訳し、使われない画面・似て非なる画面を仕分けて2,200画面を約800に凝縮する作業です。石井氏はこれを「AIだけでも現場だけでも進まなかった。両輪がかみ合って初めて前に進めた」と語ったと報じられています。
独自分析：短縮されたのは「解読」——だからこそ刷新の意思決定構造が変わる
この事例を「AIで刷新が225分の1になった」と読むのは誤りです。450人月→実質2カ月に縮んだのは**解析（システムの中身を読み解く工程）**であり、刷新プロジェクト全体は報道時点でも「道半ば」で、新旧システムの比較による段階的な切り替えとデータ基盤の整理が進行中とされています。
それでもこの短縮が経営判断を変えるのは、レガシー刷新において解析工程が特有のボトルネックだったからです。従来のレガシー刷新は「まず現行調査に膨大な費用と期間を払わないと、刷新の要件も総額も決められない」という構造を持っていました。つまり解析コストは、刷新の意思決定そのものを塞ぐ「入口の壁」でした。カクヤスの例でも「1年たっても地図すら描けず、期限は2年後に迫っていた」と語られています。ここがAIで大幅に圧縮できるなら、「調査に数億円かけるか否か」ではなく「まず低コストで地図を描き、そのうえで刷新範囲と投資額を決める」という順序に意思決定を組み替えられる——これがこの事例から導ける実務上の含意です。
もう一つ見落とせないのは、画面2,200→約800への凝縮が示すことです。解読の目的は「全部を新環境に移す」ことではなく、業務に本当に必要な機能を選り分けることでした。解析コストの壁が下がると、「現行踏襲でそのまま作り直す」しかなかった刷新が、「棚卸しして6割を捨てる」刷新に変えられます。開発対象が減れば、刷新本体の費用・期間・リスクも連動して下がる。解析工程の短縮は、それ自体の費用削減以上に、後続工程の総額を左右する起点だと言えます。
従来手法とAI駆動解析の違いを整理すると次のとおりです。
| 観点 | 従来の人手解析 | AI駆動解析（本事例の構造） |
|---|---|---|
| 期間・工数 | 数百人月規模になり得る（本事例の試算450人月） | 大幅短縮の可能性（本事例で実質2カ月と報道） |
| 前提資産 | 有識者へのヒアリング・設計書が頼り | ソースコード・DB定義そのものが解析対象（設計書がなくても着手可能） |
| 検証方法 | 有識者の記憶と突き合わせ | 本番同等環境を再現し挙動を突き合わせ |
| 業務部門の役割 | ヒアリング対象 | 解析結果を業務の言葉に翻訳し、要否を仕分ける主体 |
| 弱点 | 属人化・退職で頓挫 | AIの出力を検証する体制がないと誤読が混入する |
自社でやる場合の前提チェックリスト
AIによるレガシー解析は「ツールを入れれば動く」ものではありません。講演でも、AIの制御に試行錯誤があったこと（記憶の補強・ルールの外部化・人格の付与・プロンプトを作るためのプロンプトという2段階方式）が語られています。自社適用を検討する前に、次を確認してください。
- ソースコード・DB定義・ストアドプロシージャが手元にあるか——資産が保守ベンダー側にしかない、契約上取り出せない、という状態ではAI解析は始められない。まず資産の所在と権利関係の確認から
- 機密区分とAI利用ポリシーが整理されているか——基幹システムのコードには取引条件や与信ロジックが埋まっている。どの環境（クラウドリージョン・学習利用の有無）でなら読ませてよいかの社内基準が要る
- 解析結果を検証する足場を作れるか——本事例では本番Oracle環境をAWS上に再現し挙動を突き合わせている。AIの読み解きを「正しいと確認する手段」がないと、誤った理解の上に刷新を積むことになる
- 業務部門から人を出せるか——本事例は営業・商品・店舗・物流・経理の各部門が解析結果の翻訳と画面の要否判断を担った。情シス単独では2,200→800の凝縮はできない
- 期限が明確か——VMware契約切れのような「動かせない期限」は推進力になる。自社のEOL・契約期限を先に棚卸しする
ベンダーに解析を依頼する場合は、見積もりの確認点が変わります。「現行調査◯◯人月」という一式見積もりに対しては、(1) AI活用を前提とした工数か、人手前提の従来型か、(2) 解析結果の検証方法（再現環境での突き合わせがあるか）、(3) 成果物が「業務ロジックの言語化」まで含むか、コードの構造図までか——を確認してください。人手前提の解析見積もりとAI前提のそれでは、本事例が示すとおり桁が変わり得ます。相見積もりの比較軸として、この3点は必ず揃えるべきです。
こうした資産の棚卸しから解析、刷新範囲の設計までを一気通貫で進めたい場合は、GXOのレガシーシステムのAI解析・モダナイゼーション支援で対応しています。また、ベンダー撤退リスクを含めた刷新の外部環境は、同日公開のメインフレーム撤退マップとBIPROGY報道の整理も併せてご覧ください。
よくある質問
Q1. 基幹システムのソースコードを外部のAIに読ませて大丈夫か？
A. 利用形態によります。本事例で使われたAmazon Bedrockのようなクラウド上のマネージドAI基盤は、入力データをモデルの学習に使わない契約形態を選べるのが一般的ですが、自社の機密区分・業界規制（金融・医療等）との突き合わせは必須です。「どのデータを・どの環境で・どの契約条件なら読ませてよいか」を先に定義することが、AI解析プロジェクトの実質的な第一工程です。判断に迷う場合はAI導入可否のアセスメントで、セキュリティ・ガバナンス要件を含めて整理できます。
Q2. 450人月→実質2カ月という数字はそのまま自社に当てはまるか？
A. 当てはめるべきではありません。この数字は講演で語られた一社の試算と実績であり、システムの構造（ストアドプロシージャ中心か、画面ロジック中心か）、資産の残存状況、検証体制によって短縮率は大きく変わります。重要なのは倍率ではなく、「解析コストが刷新可否の判断を塞ぐ時代は終わりつつある」という構造変化のほうです。
Q3. AIで解析すれば、刷新自体も短期間で終わるのか？
A. いいえ。本事例でも刷新プロジェクト全体は進行中で、段階的な切り替えとデータ基盤整理が続いていると報じられています。AIが縮めたのは「中身を読み解き、地図を描く」工程です。ただし地図が早く安く手に入ることで、刷新範囲の絞り込み（本事例では画面6割減）が可能になり、結果として刷新全体の費用・リスクも下げられる、という間接効果が本質です。
Q4. 社内にAIを使いこなせる人材がいない場合は？
A. 本事例でも、AIの制御には「記憶の補強」「ルールの外部化」など試行錯誤の末の技術が必要だったと語られており、ツール導入だけで再現できるものではありません。社内に経験者がいない場合は、AI駆動開発の経験を持つ外部人材が社内チームと並走する形が現実的です。GXOでは伴走型のプロ人材アサイン（FDE+）で、解析の内製化とスキル移転を含めた体制づくりを支援しています。
「うちの開かずのシステム」の解析コスト、再見積もりしませんか
過去に「現行調査だけで数億円」「解析に2年」という見積もりを受けて刷新を凍結した——そうした企業こそ、この事例を機に前提を再計算する価値があります。GXOでは、ソース資産の所在確認と機密区分の整理から、AIを使った資産棚卸し・業務ロジックの解読、刷新範囲の設計、そして段階的な刷新計画の策定までを伴走支援しています。「まず自社のシステムがAI解析に向くかだけ知りたい」という段階でも構いません。お問い合わせフォームから、現状のシステム構成と過去の見積もり経緯をお聞かせください。
出典
- ITmedia NEWS「“開かずの基幹システム”、450人月→実質2カ月で解読 創業100年のカクヤス、生成AIで挑む『転生』」（2026年7月3日公開、AWS Summit Japan 2026講演レポート・2026年7月3日閲覧）https://www.itmedia.co.jp/news/articles/2607/03/news050.html
