カクヤス、30年物の基幹システムを生成AIで解析 現場の業務知見を組み合わせた革新手法

多くの企業が抱える基幹システムの老朽化に、酒類卸のカクヤスが生成AIを活用した解決策を見出した。動いているが中身が誰にも把握できない「泥沼システム」を、AIによる解析と現場の業務知見の融合で攻略したという。

長年にわたる改修を重ねた基幹システムは、動く理由は不明ながら停止できない存在となり、刷新の大きな壁となっている。

創業100年を超える同社も例外ではなかった。既存システムの人手解析には約450人月が必要と試算され、現実的なスケジュールでの刷新は困難を極めた。しかし同社は、解析作業を実質2カ月に短縮し、約2200あった画面を約800に整理した。鍵は生成AIだった。

刷新対象の基幹システムは約30年前に構築され、機能追加や改修を繰り返すうちに設計書やソースコードの一部が失われ、全体を把握できる人材もいなくなった。保守・改修は特定ベンダーに依存し、新たな機能追加や刷新の妨げとなっていた。

プロジェクトを率いる石井伸明氏（グループシステムサービス部 特命担当）は、「システムが動いていることと、健全に運用できていることは別です。30年間使い続けた結果、誰も中身を十分に理解できず、手を入れにくいシステムになっていました」と振り返る。

こうした状況を受け、同社は基幹システム刷新と同時に事業の軸そのものを見直す決断をした。従来の酒類卸では商品マスターや取引マスターが中核だったが、物流業では配車や倉庫運営、在庫管理などの物流データが競争力の源泉となる。新たな事業を支えるには、それに適した基幹システムが必要だった。

その決意を象徴するのが2025年の社名変更だ。持株会社のカクヤスグループは「ひとまいる」へと改称した。石井氏は「社名を変えたことで、もう後戻りはできません。会社として物流業へ転換する覚悟を形にしたのです」と語る。

VB.NETで作られた画面は約2200あり、社内で全容を説明できる担当者はもういない。「Oracle Database」のテーブルは約3000に上り、命名規則は時代ごとにばらつきがある。同じ意味のデータが複数存在し、業務ロジックの多くはストアドプロシージャ約1200本に分散していた。人手による解析工数は約450人月と試算され、到底終わらない規模だった。

もう一つの課題は、検証環境が本番環境と一致していないことだ。本番環境は24時間365日稼働し、30年の改修で複雑化していた。一方、検証環境は本番の完全な再現にはなっておらず、外部システムとの連携も制限されていた。そのため、システム全体の動作再現テストは不可能で、部分確認にとどまっていた。

本来なら検証環境で動作を再現しながら挙動を理解できるが、実際にはできない。石井氏は「本番に近い形でテストできない以上、推測でしか判断できない場面が多くなっていました。テストすれば分かるはずのことが、そもそもテストできない。この状態こそが、30年の積み重ねが生んだ負債だと思っています」と話す。

カクヤスが採ったのは、AI駆動開発と業務駆動開発の2つを組み合わせる方法だ。石井氏は、どちらか一方では進まず、両者がかみ合うことで初めて基幹システムの全体像に到達できたと説明する。

AI駆動開発では、約1200本のストアドプロシージャ解析を人手ではなくAIに委ねた。「Claude Code on Amazon Bedrock」を使ってコードを解析し、業務ロジックを抽出。さらに「Amazon Web Services」に再現した検証環境と本番環境の挙動を突き合わせ、システムの実態を確認していった。これにより、約450人月の解析作業を実質2カ月で完了したという。

業務駆動開発では、AIが抽出したロジックを現場の業務に結び付けた。営業や商品、店舗、物流、経理など各部門の担当者が参加し、業務フロー単位でコードの意味を解釈。何のために存在する処理なのかを一つ一つ明確にし、システムに残す機能を「業務として今も必要なもの」と「既に役割を終えたもの」に仕分けた。

この過程で同社は、不要な機能を削りながら業務に必要な要素だけを残すアプローチを採った。2200あった画面の多くは、実際に使われていないものや類似機能の重複、担当者自身も把握していないものが含まれていた。AIと現場の精査で、新基幹システムに残す画面は約800、業務は約200のフローとして再定義された。石井氏は「単なる機能削減ではなく、物流業として動くために必要な構造へ組み替える作業だった」と位置付ける。

こうした処理を支えたのが「Claude Code on Amazon Bedrock」とクラウド基盤の組み合わせだ。高いセキュリティ要件のもとで生成AIを活用し、プロンプトや分析手法をチーム内で共有できる仕組みを整備。個人の試行錯誤を組織の知見として積み上げていった。

並行して、AWSに本番環境と同等の検証基盤を構築。「Amazon Elastic Compute Cloud」（Amazon EC2）や「Amazon Relational Database Service」（Amazon RDS）を使ってOracle Database環境を再現し、本番のストアドプロシージャの挙動を検証環境で突き合わせた。これにより従来困難だったシステム全体の挙動確認が可能になり、約1カ月で解析・検証の足場が整った。

基幹刷新の核心となったAI駆動開発について、石井氏は「正解のない開発だった」と振り返る。初期は手探りの連続で、外部の知見を参考にしようとした時期もあったが、思うような成果にはつながらなかったという。

開発を進める中で直面したのは、AIの“特性”だった。当初は「AIは全てを覚えている」という前提で設計していたが、実際にはそうではなかった。そこで同社は、情報を保持させるのではなく、常に参照できる形で外部化する設計へと切り替えた。ルールや前提条件も人の記憶ではなく、AIが参照するファイルとして管理するようにした。

こうした蓄積の先に生まれたのが、AIを“制御するための設計”だった。単にコードを生成させるのではなく、生成した内容をAI自身に説明させて検証するプロセスを組み込んだ。さらに、役割や前提条件を与えることで思考の基盤を定める「人格設計」や、業務要件から直接プロンプトを作るのではなく、そのプロンプトを生成するためのプロンプトを設計する「二段階プロンプト方式」も導入した。

AIがコードを書く時代において、品質を左右するのは実装そのものではなく、何を作るかをどれだけ正確に言語化できるかに移りつつある。指示が曖昧であれば、生成される成果物もまた曖昧になる。つまり、要件定義の精度がそのまま開発品質を決める構造だ。

そこで同社は、曖昧さを排除するための共通フレームとして5W2H、つまり「誰が、何を、なぜ、いつ、どこで、どのように、いくらで」というように依頼内容を分解し、空欄となる項目をそのまま確認事項として抽出する仕組みを整えた。さらに整理された要件は、目的と機能、入出力、制約といった要素に分解され、最終的にAIへのプロンプトへと変換されていく。

ここまでの成果について石井氏は、「まだ道半ばだ」と語る。プロジェクトは進んでいるものの、楽観はしていないという。

現在の取り組みは、経営と基幹、現場の三層で進んでいる。経営層は社名変更によって物流業への転換を明確に打ち出し、既に後戻りできない段階に移行している。基幹システムでは、約2200画面から800画面、200業務フローへの再構築が進行中だ。一方で現場では変革への協力が広がりつつあるものの、その浸透はまだ局所的にとどまっている。

石井氏は、経営の先行と現場・システムの追随との間に生じる「時間差」こそが、変革を前に進める力にもなるとみている。

これまでに同社は、約1200本のストアドプロシージャを業務言語へと翻訳し、約2200あった画面を800へと整理することで、ブラックボックス化したコードを読み解く手法を確立してきた。現在は現場主導で200の業務フローの再構築が進められており、システムの段階的な切り替えとデータ基盤の整備も並行して進行している。

次の焦点は、物流データそのものの活用だ。単なる基幹システム刷新にとどまらず、データを新たな価値としてどう捉え直すかが問われている。同社は、AIを「使う組織」から「AIとともに考える組織」への転換を視野に入れている。

石井氏は最後に、「一度変わって終わりではなく、変化を続ける組織でありたい」と語る。100年企業が選んだのは完成ではなく、変化そのものを前提とする経営だった。

本稿は、2026年6月25～26日に開催された「AWS Summit Japan 2026」（主催：アマゾンウェブサービスジャパン）の講演「創業100年の酒屋カクヤスが挑む、生成AIで実現するシステム革命」を基に編集部で再構成した。