こんにちは。
じじグラマーのカン太です。
はじめに
以前、「Accessで作ったシステムをクラウドに移行する方法とコスト」や「MS Access を使ったシステムをクラウド化する一番簡単な方法（実体験）]」といった記事で、Accessの業務システムをクラウド化した体験をお伝えしてきました。
今回はその続編にあたる話です。あるお取引先で長年動いていた「在庫管理業務システム」（Access/VBA製）を、クラウド化にとどまらずRails + PostgreSQLへ丸ごと作り直すというプロジェクトに、AIコーディングツール「Claude Code」を使って挑戦しました。
この記事は、以下のような方に特に役立つ内容だと思います。
– Accessで作った業務システムの「その先」（クラウド化ではなく全面刷新）を考えている方
– Claude CodeなどのAIコーディングツールが、実際の業務システム開発でどこまで使えるのか知りたい方
– 自分自身はガチガチのエンジニアではないが、業務システムの面倒を見ている方
僕自身、専業のプログラマーではありません。それでも、Claude Codeという「相棒」を得たことで、ここまでのことができるようになったという実体験をシェアします。
Claude Codeとは何か
まず簡単に説明すると、Claude Codeは、Anthropic社が提供するAIの「Claude」を使ったコーディング支援ツールです。ChatGPTのように質問に答えてくれるだけでなく、実際にファイルを読み書きしたり、コマンドを実行したり、テストを走らせたりしながら、開発作業そのものを一緒に進めてくれるのが大きな特徴です。
以前このブログで「[ChatGPTが登場したことで、プログラム言語を学習することは無意味になるの？](https://jijigrammer.info/programming/2509/)」という記事を書きましたが、あれから状況はさらに進み、「AIに聞きながら書く」段階から「AIと一緒に、規模の大きいシステムそのものを作っていく」段階に来ていると感じています。今回の在庫管理システムの移植は、まさにその実例です。
今回のプロジェクトの全体像
前提として、今回の話は特定のお取引先を特定できないよう、業種や規模など細かい部分は一般化してお伝えします。
対象は、ある事業者様が長年Accessで運用してきた在庫管理業務システムです。商品の入庫・出庫の記録から、月次の請求・支払処理まで、日々の業務を支える基幹システムでした。ただ、以下のような課題を抱えていました。
– Access独特の「VBAで書かれた業務ロジック」がブラックボックス化しつつあった
– 複数拠点・複数人での同時利用に限界が来ていた
– クラウド化だけでは根本解決にならない規模まで来ていた
そこで、単純なクラウド移行ではなく、Rails（Webアプリケーションフレームワーク）+ PostgreSQL（データベース）への全面移植という、より踏み込んだ選択をしました。
進め方：いきなりコードを書かせない
Claude Codeを使うとはいえ、「移植して」と一言頼んで終わり、というわけにはいきません。実際に踏んだステップは、次のような順番でした。
1. 既存のAccess VBAソースを、まるごと監査してもらう（業務ロジックの正確な仕様と、危うい実装になっている箇所の洗い出し）
2. その監査結果をもとに、Rails側の設計方針をすり合わせる（ドキュメントとして合意事項を残す）
3. 合意した設計方針にもとづいて、実装を進める
いきなり「動くもの」を目指すのではなく、まず「今のシステムが何をしているか」を正確に洗い出すところから始めたのがポイントでした。長年運用されてきた業務システムには、画面には現れない細かい業務ルールが山のように埋め込まれているものです。ここを飛ばしてコードだけ移植すると、後になって「あの時のあの処理が再現できていない」という事故につながります。
設計面でも、地味ですが効いた判断がありました。たとえば、在庫の記録は「一度記録したら書き換えない、生ログ」として扱い、月次の締め処理で初めて「確定した請求明細」として固定する、という2段構えの設計にしたことです。こうしておくと、締め処理を後から取り消したくなった場合でも、元の記録を壊さずに安全に取り消せます。Access版では、締めのたびに元の作業テーブルを直接書き換えていた部分もあったため、ここは設計思想からの転換になりました。
実際にハマったところ
ここからは、実際に手を動かしていて「ハマった」ポイントを紹介します。このブログではおなじみの、実体験ベースの話です。
① データベースへの接続が、なぜか失敗する
開発環境を作ってPostgreSQLに接続しようとしたところ、`localhost`を指定しているだけなのに、接続がうまくいかない現象が発生しました。原因を探ってもらったところ、`localhost`がIPv6のアドレスとして解決されてしまい、PostgreSQL側の待ち受け設定と噛み合っていなかったことが判明しました。対応は単純で、`localhost`ではなく`127.0.0.1`と明示的にIPv4アドレスで指定するだけです。地味ですが、Windows環境の開発ではよくあるつまずきポイントだと思います。
② 画面のボタンを押すと「トークンが違う」と怒られる
実装したフォームを実際にブラウザで操作していると、特定のボタンを押したときだけ「CSRF token authenticity（不正なリクエストではないかのチェック）」に失敗するという現象が起きました。調べてみると、Railsのセキュリティ機構により、1つの画面の中に複数のフォーム（ログアウトボタンや、一覧の行ごとの取消ボタンなど）がある場合、それぞれのフォームに紐づく「認証トークン」が別物として扱われる仕様があることが分かりました。デバッグの際、画面のソースから機械的に最初に見つかったトークンを拾ってテストしていたのが原因で、狙ったフォーム用のトークンをきちんと使うようにしたところ解決しました。
③ 古いデータの「番号のつけ方」が2種類混在していた
長年運用されてきたAccessのデータを移行する段階で見つかったのが、同じ意味のはずの管理番号が、登録された経路によって2つの異なる形式で存在していたことです。片方は元の番号そのまま、もう片方は「元の番号＋枝番」という形式でした。これに気づかず移行すると、本来は同じ1件の記録のはずが、システム上は別の2件として二重登録されてしまいます。長年運用されたシステムには、こうした「表からは見えない歴史的経緯」が必ずと言っていいほど隠れているというのを、あらためて実感しました。
非エンジニアの実感として
正直に言うと、上に挙げたようなハマりポイントを、僕がゼロから自力で解決するのは相当に厳しかったと思います。ですが、Claude Codeは単に「コードを書いてくれる」だけでなく、
– 現象を再現・調査し、原因を切り分けてくれる
– なぜその設計にしたのか、判断の理由を言語化して残してくれる
– 一度踏んだ落とし穴を、プロジェクトの「引き継ぎメモ」のような形で記録し、同じ失敗を繰り返さないようにしてくれる
という部分まで含めて助けてくれたのが、以前のクラウド化作業のときとの大きな違いでした。Accessのクラウド化記事を書いていた頃は、正直「調べながら手探りで進める」という感覚が強かったのですが、今回はAIと一緒にプロジェクトを進めているという感覚に近かったです。
まとめ
Access業務システムの「その先」として、Claude CodeでRailsへの全面移植に挑戦した実体験をお伝えしました。
– クラウド化だけでは解決しない規模の課題には、全面的な作り直しという選択肢もある
– ただし、いきなり移植を始めず「既存システムが何をしているか」の洗い出しを先にやるのが重要
– Claude CodeのようなAIコーディングツールは、コードを書くだけでなく、調査・設計判断・引き継ぎ資料づくりまで一緒にやってくれる
長年使われてきた業務システムを抱えている方にとって、少しでも参考になれば嬉しいです。わからないことや、同じような悩みをお持ちの方は、ぜひお気軽にコメントください。
コメント