もう一つの課題は、検証環境が本番環境と一致していないことだった。本番環境は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年企業が選んだのは完成ではなく、変化そのものを前提とする経営だった。