カクヤス「30年物の泥沼システム」をAIでどう解読？ 現場が思いついた“ある考え”

動いてはいるものの、誰もその中身を把握できない。多くの企業が直面する基幹システムの“老い”に、カクヤスは生成AIを使った。鍵となったのは、AIによる解析と現場の業務知見を組み合わせ、「AIを制御する技術」を確立したことだ。

[平 行男，キーマンズネット]

ひとまいる　石井伸明氏（筆者撮影）

　長年の改修を重ねた基幹システムは「動いている理由は分からないが、止めるわけにもいかない存在」となり、多くの企業で刷新を難しくする要因となっている。

　創業100年を超える酒類卸のカクヤスも例外ではなかった。既存システムを人手で解析すると約450人月を要すると試算され、現実的なスケジュールで刷新を進めることは難しかった。だが、同社は人手では長期間を要する解析作業を実質2カ月へと短縮し、約2200あった画面を約800まで整理した。人手では約450人月を要すると試算された基幹システムの解析に使われたのが、ある生成AIだ。

残されたのは、誰も分からない「30年物の基幹システム」

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

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

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

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

酒を運ぶ会社から、運ぶことで稼ぐ会社へ（出典：講演資料）

ただ「AI丸投げ」では破綻する　カクヤスが思い立った「ある考え」

　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が抽出したロジックを現場の業務に結び付けていった。営業や商品、店舗、物流、経理といった各部門の担当者が参加し、業務フロー単位でコードの意味を解釈することで、「何のために存在する処理なのか」を一つ一つ明確にしていく。その結果、システムに残る機能を「業務として今も必要なもの」と「既に役割を終えたもの」に仕分けることができた。

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へのプロンプトへと変換されていく。

業務を5W2Hで分解してプロンプトへ翻訳（出典：講演資料）

単なる刷新で終わらない　カクヤスが見据える「次の焦点」

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

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

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

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

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

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

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