販売管理システムの刷新は何から決めるか——20年もののVB6を抱えた食品卸で、誌上で移行計画を立ててみた

「今どきAI（Artificial Intelligence＝人工知能）を使えば、うちの古いシステムなんて丸ごと作り直せるんだろう？」——付き合いのある経営者からこの言葉を聞いたのは、今年の春のことでした。危機感はある。AIへの期待もある。それなのに、この会社の刷新は3年間、一歩も動いていません。

この記事の前半は、筆者がその会社で見聞きした話です。後半は、筆者からその社長への、誌上での提案書です。

本記事は、筆者が付き合いのある経営者とその会社について実際に見聞きした事例をもとにしています。守秘のため、社名・人物名は仮名とし、業種・規模・数値など特定につながる情報は変更して再構成しています。第5章のAI（Claude）との検討は筆者が実際に行ったやりとり、第6章以降の移行計画とデモはこの会社の決定ではなく、筆者からの提案（誌上シミュレーション）です。文末のデモは実際に動作します。

この記事でわかること

• 20年もののVB6製販売管理と「あの人しかわからない」担当者を抱えた会社が、危機感があるのに3年動けずにいる理由
• 社長の「AIで丸ごと」という期待をAI自身にぶつけたら、何と答えたか——「AI一括置き換え」「段階移行」「延命」3案の費用と得失
• 筆者が提案する移行計画の第一歩（受注のWeb化）で何が変わるか。実際に触れるBefore/Afterデモ付き

---

1. 相談を受けた会社——20年もののVB6販売管理を抱える食品卸

その会社は、地方都市で業務用の食品・資材卸を営んでいます。社員28名。サラダ油の一斗缶、業務用の米、冷凍食品、割り箸を、市内と近隣の飲食店や保育園・病院の給食室、あわせて約150軒に毎日届けています。

派手さはありません。でも、この会社の配送が止まれば、翌日から仕込みができない店が出ます。地域の「食」を足元で支える商売です。

販売管理システムは2006年、当時30代だった社員・井川さん（仮名）がVB6（Visual Basic 6＝四半世紀前に主流だった開発言語）で自作したものです。以来20年、消費税率の変更、軽減税率、インボイス制度——制度が変わるたびに井川さんが継ぎ足し、直し、育ててきました。

設計書はありません。仕様のすべては、井川さんの頭の中にあります。

業績は安定し、システムも多少の癖はあれど動いていました。「動いているものに触るな」で20年、困らなかったのです。では、なぜ丸谷社長（仮名）は筆者に相談を持ちかけたのでしょうか。

2. 基幹システムの刷新に踏み切れない理由——危機感はある。でも動けない

きっかけは、インボイス対応だったそうです。請求データに項目を追加したところ、翌月から納品書の印刷が時々失敗するようになった。井川さんが直すと、今度は月次の集計が合わない。1か所直すと別の場所が壊れる。社内では「もぐらたたき」と呼ばれています。

社長から聞いた現場の様子は、こうでした。

「月末の請求書発行は、事務の子がエラーが出ないことを祈りながらボタンを押してるんだよ」

「新しい商品を登録するのに2週間かかる。井川が悪いんじゃない。井川しかできないのが問題なんだ」

その井川さんは50代の正社員です。「あの人に聞けばわかる」の一言で20年、社内のITすべてを引き受けてきました。しかし今、井川さんの1日は障害対応だけで終わります。機能改修の依頼は20件以上溜まり、社員からの質問には数日返事ができない。社長の目には、井川さんの口数が年々減っているように映っています。

誤解のないように書いておきます。これは井川さんの意欲の問題ではありません。20年間、たった1人にすべてを背負わせる構造は、どれほど優秀な担当者からも余力と意欲を静かに削っていきます。 溜まる依頼、終わらない障害対応、答えられない質問。それでも代わりはいない。井川さんの静かさは本人の資質ではなく、構造の帰結です。

丸谷社長に危機感がないわけではありません。むしろ強い方です。ただ、口癖は冒頭のあの言葉でした。

「今どきAIを使えば、丸ごと作り直せるんだろう？」

実は3年前、刷新の検討が一度ありました。地元の開発会社が「段階的に移行しましょう」と提案してきた。しかし社長は「小出しに金を払うより、AIで一気に置き換えられるはずだ」と退けました。開発会社は「それは難しい」と答え、話はそこで止まりました。

以来3年、危機感とAIへの期待はあるのに、具体的な一歩は何もない——それがこの会社の現在地です。

更新できなかった本当の理由は、無関心ではありません。「全部やるか、やらないか」の二択で考えてしまい、「まず一部だけ」という選択肢を選べなかったからです。同じ構図の会社は、決して珍しくないはずです。

3. VB6販売管理システムの現状——仕様は井川さんの頭の中

「丸ごと作り直せないのか」を検討するには、まず「丸ごと」の中身を知る必要があります。下の図は、受注から請求までの業務の流れと、どこに手作業が挟まっているかを示しています。

FAXで届いた注文を事務員が目視で打ち込み、チェーン店の本部からはCSV（表計算ソフトで開ける形式のデータ）を毎朝手作業で取り込む。入力が終わるまで在庫の引当も出荷指示も始まらないので、朝の事務所はいつも時間との勝負です。

これはこの会社が特別に遅れているわけではありません。業務システム開発企業アイルの調査では、中堅・中小企業の85.8%がFAX・電話など転記を伴う方法で受注しており、FAXだけで37.2%を占めます（出典は文末）。「FAXを手で打ち込む毎朝」は、日本の中小企業のごく普通の風景です。普通であることと安全であることは別ですが。

システムを動かす機器の構成は、下の図の通りです。

要点は3つです。

• 設計書がない（増改築を繰り返した建物の、図面が存在しない状態）
• 開発環境が井川さんのPCにしかない（直せる場所も人も1つだけ）
• サーバは2008年設置で、基本ソフト（OS＝Operating System、機器を動かす土台のソフト）はサポートが切れたまま動いている

家に例えるなら、定期点検を受けられなくなった築古の建物に、金庫と帳簿を全部置いているようなものです。しかもVB6という言語自体、開発元のMicrosoftが開発ツールのサポートを2008年に終了しています（出典は文末）。「サポートが終わったVB6は、結局いつまで使えるのか」という疑問そのものへの答えは、VB6のサポート終了、いつまで使える？に整理しています。

つまりこの会社は、作った人・作った道具・動かす土台の3つが同時に寿命を迎えつつあるシステムで、毎日12億円分の商売を回しているのです。

4. 老朽化した基幹システムの経営リスク——「システムの寿命」より先に「人の限界」が来る

この状態を放置すると何が起きるのか。相談を受けた筆者が最初に整理したのが、この表です。煽るためではなく、投資判断には「やらなかった場合の値段」が必要だからです。

障害が起きたときの桁感も押さえておきます。IT企業サイオステクノロジーの調査では、過去3年に1時間以上のシステム停止を経験した企業が7割を超え、損失が最大だった障害では約25%の企業で損失額が1,000万円を超えたと報告されています（出典は文末）。「システム停止は珍しい事故ではなく、起きれば百万円単位では済まないことがある」という相場観としては十分です。

とくに表の1行目が要注意です。多くの経営者は「サーバが壊れたら」を心配しますが、この会社は機械より先に人が限界を迎える構図です。井川さんが明日入院したら、FAXの受注入力は続けられても、障害が起きた瞬間に誰も直せません。食品卸で納品が止まれば、翌日の給食や店の仕込みに影響が出ます。これは1社のシステムの話ではなく、BCP（Business Continuity Plan＝事業継続計画）、つまり「非常時にも商売を続けられるか」の問題です。

こうしたリスクは、この会社だけの特殊事情ではありません。経済産業省はDXレポート（DX＝Digital Transformation＝デジタルによる業務変革）で、約8割の企業が老朽化したシステムを抱え、放置すれば年間最大12兆円の経済損失が生じうると警告しました。「2025年の崖」と呼ばれた予測です（出典と鮮度注記は文末）。

崖は「ある日突然落ちる」ものではありません。この会社のように障害と属人化がじわじわ進む形で現実になるのです。IT人材も2030年に最大79万人不足と試算されており（出典は文末）、「辞めた井川さんの代わりを雇えばいい」は年々難しくなっていきます。

ここまでが、筆者が見聞きした実情の整理です。ここから先は筆者からの提案になります。最初にやってみたのは、社長のあの口癖を、そのままAIにぶつけてみることでした。

5. VB6を丸ごと変換できないか、AIに聞いてみた——Claudeの回答と限界

相談相手はAIアシスタントのClaude。社長の期待を、脚色せずそのまま質問にしました。これは筆者が実際に行ったやりとりです。

相談: 「VB6で20年内製してきた販売管理システムがあります。設計書はなく、仕様がわかる社員は1人だけです。AIでこれを丸ごと新しいシステムに変換できませんか？」

Claudeの答えの要点は、こうでした。

Claudeの回答（要約）: 技術的には、AIはVB6のコードを新しい言語へ変換できます。しかしこのケースで一括変換はお勧めしません。理由は3つです。

1. 正解を知る手段がありません。 設計書もテスト（動作確認の仕組み）もないため、変換後のシステムが「正しく」動いているかを判定できるのは担当者の記憶だけです。
2. ぶっつけ本番になります。 卸売業は業務を止められません。一括切替は、検証不十分なシステムに全業務を一晩で乗せる賭けになります。
3. コードには「なぜ」が書かれていません。 20年分の制度対応の意図——なぜこの計算式なのか、なぜこの例外があるのか——はコードから読み取れず、変換すると意図ごと失われる恐れがあります。

AIの得意分野は「丸ごと置き換え」ではなく「解読」です。VB6のコードを読んで失われた設計書を復元し、担当者の記憶を文書に変え、段階移行を速く・安くすることに使うべきです。

そのうえでClaudeは3つの選択肢を提示しました。

ここで鵜呑みにせず、筆者から2点、突っ込みを入れました。

指摘1: 「B案、チェーン本部との発注データ連携の切替時期が雑です。本部側のデータ形式は、こちらの都合では変えられません。」 → Claudeは連携部分を「旧システムの取込口をそのまま残し、新ポータル側が旧形式に合わせる」方式に修正。切替は本部側のシステム更新時期に合わせる計画に改めました。

指摘2: 「FAXを急に廃止すると、昔ながらの個人店は離れますよ。」 → 「FAX受注は当面残し、Web発注は"使いたい得意先から"任意で移行。FAX分の入力画面だけ新システムに寄せる」形に修正されました。

AIの初案は8割正しく、2割は現場を知らない甘さがある——実際にやってみた率直な感想です。AIに答えを出させるのではなく、たたき台を出させて人間が現場の事情で削る。 この使い方なら、AIは中小企業にとって強力な武器になります。

6. 販売管理システム刷新の経営判断——「全か無か」を降りる

この会社はまだ何も決めていません。決めるのは丸谷社長です。そのうえで、筆者が提案するならB案・段階移行の一択です。決め手は費用ではなく、時間です。

• B案を提案する理由: 設計書の復元は、井川さんが在職して質問に答えられる今しかできない。3年後では遅い。第1段階（受注のWeb化）だけなら、失敗しても旧システムが並走しているので商売は止まらない。
• A案を勧めない理由: AI自身が勧めませんでした。本気でやろうとすると、結局は設計書の復元と段階的な検証、すなわちB案の中身から始めることになります。
• C案を勧めない理由: 一番安く見えますが、井川さんの1日が障害対応で埋まる構造が何も変わりません。直せる人が1人である限り、リスクの時計は止まりません。

この判断で得るものは、属人化の解消（設計書＋誰でも触れる新基盤）、障害の減少、そして井川さんの時間です。失うものも正直に挙げます。並走期間の二重入力の手間、初期投資、そして「一気に新しくなる」という派手さ。段階移行は地味です。しかしその地味さは、業務を止めないことの対価です。

下のグラフは、3案の5年間の総コストの目安を比べたものです（障害による機会損失は含みません）。

A 一括変換

2800万円

B 段階移行

1600万円

C 延命

1100万円

C案が最安に見えますが、これは「事故が起きなければ」の数字です。キーパーソンの離脱や基幹停止が一度でも起きれば、順位は簡単に入れ替わります。第1段階の300万〜500万円に対しては、FAX入力・確認電話・障害対応に消えている工数の削減で年およそ250万〜350万円の効果、2年前後で回収と試算しました【仮定・詳細は第8章】。

7. 段階移行の進め方——最初の一歩は「受注のWeb化」から

提案書は言葉だけでは伝わりません。そこで筆者は、この提案の第1段階を実際に動くデモとして作ってみました。まず、3年計画の全体像です。

順番には理由があります。毎朝の手入力と判読ミスという「痛みが最も大きい業務」が受注であり、かつ失敗しても旧システムで受け直せるため、最初の実験台に最適だからです。逆に請求・帳票は金額に直結するため、設計書と検証の仕組みが揃う最後に回します。

Phase 0でAIが果たす役割こそ、社長の「AIで丸ごと」の願いの正しい回収先です。VB6の請求計算に相当するコード片をClaudeに読ませると、「この分岐は2019年の軽減税率対応。ただし2023年のインボイス対応で追加された処理と税額の丸め順序が矛盾しており、帳票印刷が失敗する条件はここにある」といった水準の解読が返ってきます。井川さんが記憶で説明していた仕様が、質問に答えるだけで文書になっていく。20年分の「頭の中」を、在職中に会社の資産へ変える作業です。

下の図は、Phase 1完了時点のシステム構成です。

サーバを持たないクラウド構成にしたのは、この規模の会社に「サーバの面倒を見る2人目の井川さん」を作らないためです。機械の保守から解放されることは、この規模では機能の新しさより価値があります。

扱うデータの構造はごく単純で、下の図の通り、得意先・商品・受注・在庫という4つの情報のつながり（ER図＝Entity Relationship Diagram、データの関係図）だけでPhase 1は成立します。旧システムの複雑さの大半は、この単純な構造の上に20年分の例外処理が積もったものでした。

実際に触れるデモ

このケースを再現したデモを用意しました。まずは新旧の画面を見比べてください。

下の画像は移行前の受注入力画面です。FAXを見ながら商品コードを手入力する、2006年当時のままの画面です。

そしてこちらが移行後、Phase 1のWeb受注ポータルです。Web発注・本部データ・FAXの受注が1つの画面に集まり、在庫引当もここから1クリックで行えます。

画像だけでは伝わらない「操作感」も体験できます。旧画面（Before）では、ぜひ「帳票印刷」ボタンを押してみてください。 この会社の日常が体験できます。

🖥️ デモを触ってみる: 新旧比較の入口 ／ 旧・受注入力画面（Before） ／ 新・Web受注ポータル（After）

※デモは実際のシステムの複製ではなく、聞き取った業務の流れを筆者が再現したものです。画面・データはすべて架空で、ブラウザ内でのみ動作します。

8. 刷新で見込める効果——井川さんの1日は何に変わるか

Phase 1で何がどう変わるのか。5つの観点で、BeforeとAfterを並べます。数字は【仮定】を含む筆者の試算です。

一方で、想定しておくべき「痛み」も書いておきます。並走期間は在庫・請求が旧システムに残るため、新旧の突き合わせ作業が月次で発生します。Web発注に移行してくれる得意先も初年度で3〜4割程度と見るのが現実的で【仮定】、FAXは当面なくなりません。

効果は階段状にしか出ません。それでも、井川さんの1日が「もぐらたたき」から「設計書のレビューと検収」に変わることが、この投資の本当のリターンです。

9. 経営者向けまとめ——この記事は、あの社長への提案書でもあります

5年後、この会社が「あの判断は成功だった」と言えるかどうかの物差しは、システムが新しくなったかではありません。「井川さんしかわからない」が消えているかです。設計書があり、標準技術で動き、外部にも頼める状態になっていれば、たとえ移行が3年計画より遅れても、この会社はもう崖の縁にはいません。

逆に、いま動かなければ——3年前と同じ「全か無か」の袋小路で、井川さんの残り時間だけが減っていきます。

同じ状況の会社の経営者に、順番だけお伝えします。

1. 今月やること（費用ゼロ）: 「システムの仕様を知っている人は誰か」「その人が明日入院したらどうなるか」を紙に書き出す。井川さんにあたる人の名前が1人しか出てこなければ、それが危険信号です。
2. 今期やること: AIも使いながら、動いているシステムの設計書の復元を始める。刷新を決める前でも無駄になりません。キーパーソンが在職しているうちにしかできない、期限付きの作業です。
3. やらなくていいこと: 「AIで丸ごと」に賭けること。AIは置き換えの魔法ではなく、解読と移行を速くする道具です。全か無かの二択に戻った瞬間、また3年止まります。

社長向け判断シート（筆者の評価）

タイトルの問い——「AIで丸ごと作り直せないのか」——への筆者の答えは、「作り直せます。ただし丸ごとではなく、順番に。そしてAIの一番の出番は、変換ではなく解読です」。

この記事は、読者のみなさんへのケーススタディであると同時に、丸谷社長への提案書でもあります。次にお会いするとき、「まず設計書の復元からやってみるか」と言っていただけたら、筆者としてこれほど嬉しいことはありません。

なお、この記事の「受注のWeb化」よりさらに小さな一歩——会社と会社の「あいだ」だけを、自社システムに触れずにデジタル化する実例——を、歯科向け卸のケーススタディとして書いています。あわせてどうぞ。

また、井川さんのように「あの人しかわからない」状態そのものへの診断・対処法は、属人化した基幹システム、担当者が倒れたら？にまとめています。

そして、この記事で描いた「まず一部だけ動かす」段階移行が、中小企業のDX推進全体のどこに位置する一歩なのか。困りごと別に入り口を整理した実用ガイドを中小企業のDX推進、何から始めるかとして書いています。

最後にもうひとつだけ。第7章のデモは、読むだけでなく実際に触れます。旧画面（Before）の「帳票印刷」ボタンを押してみてください。この会社の日常が、文章よりも早く伝わるはずです。

🖥️ 新旧比較の入口 ／ 旧・受注入力画面（Before） ／ 新・Web受注ポータル（After）

---

参考・出典

• 経済産業省「DXレポート 〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」(2018年) — 約8割の企業がレガシーシステムを抱える、放置時の経済損失は2025年以降最大12兆円/年との予測。https://www.meti.go.jp/policy/it_policy/dx/20180907_03.pdf（2026年時点では8年前の試算だが、レガシー放置リスクの方向感を示す代表的資料として引用）
• Microsoft「Support Statement for Visual Basic 6.0」(2024年12月更新) — VB6開発ツールのサポートは2008年4月に終了。最新技術への移行を推奨。https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy
• 経済産業省（みずほ情報総研受託）「IT人材需給に関する調査」(2019年) — 2030年にIT人材が最大79万人不足との試算。https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf（2026年時点では7年前の試算だが、人材確保が年々難しくなる方向感を示す数字として引用）
• 株式会社アイル調べ「中堅・中小企業の受注業務に関する調査」（2020年・受注業務担当者734人対象）／ネットショップ担当者フォーラム報道 — 85.8%がFAX・電話等のアナログ手段で受注、FAXは37.2%。https://netshop.impress.co.jp/node/8245（2026年時点では6年前の自社調査だが、中小企業の受注のアナログ依存を示す数字として引用）
• サイオステクノロジー株式会社「ITシステム障害と事業リスクに関する実態調査【2025】」(2025年・自社調査) — 過去3年に1時間以上の停止を経験した企業は7割超、最大損失が1,000万円超の企業は約25%。https://bcblog.sios.jp/system-failure-business-risk-management/
• 本文中の費用・工数・回収年数はいずれも【仮定】と明記した筆者の試算・一般的な目安であり、個別の見積もりに代わるものではありません。システム投資の判断にあたっては、複数の専門事業者への相談をお勧めします。