「今どきAI（Artificial Intelligence＝人工知能）を使えば、うちの古いシステムなんて丸ごと作り直せるんだろう？」——付き合いのある経営者から、この言葉を聞いたのは今年の春のことです。危機感はある。AIへの期待もある。それなのに、この会社のシステム刷新は3年間、一歩も動いていませんでした。この記事の前半は、筆者がその会社で見聞きした話です。そして後半は、筆者からその社長への、誌上での提案書です。
本記事は、筆者が付き合いのある経営者とその会社について実際に見聞きした事例をもとにしています。守秘のため、社名・人物名は仮名とし、業種・規模・数値など特定につながる情報は変更して再構成しています。第5章のAI（Claude）との検討は筆者が実際に行ったやりとり、**第6章以降の移行計画とデモはこの会社の決定ではなく、筆者からの提案（誌上シミュレーション）**です。文末のデモは実際に動作します。
この記事でわかること
- 20年もののVB6製販売管理と「あの人しかわからない」担当者を抱えた会社が、危機感があるのに3年動けずにいる理由
- 社長の「AIで丸ごと」という期待をAI自身にぶつけたら、何と答えたか——「AI一括置き換え」「段階移行」「延命」3案の費用と得失
- 筆者が提案する移行計画の第一歩（受注のWeb化）で何が変わるか。実際に触れるBefore/Afterデモ付き
1. 相談を受けた会社——株式会社マルタニ食品（仮名）
その会社は、地方都市で業務用の食品・資材卸を営んでいます。社員28名。サラダ油の一斗缶、業務用の米、冷凍食品、割り箸。市内と近隣の飲食店や保育園・病院の給食室、あわせて約150軒に毎日届けています。派手さはありませんが、この会社の配送が止まれば、翌日から仕込みができない店が出る。地域の「食」を足元で支える商売です。
| 項目 | 内容 |
|---|---|
| 業種 | 業務用食品・資材卸 |
| 社員数 | 28名（営業7・配送8・倉庫5・事務5・その他3） |
| 売上規模 | 約12億円 |
| 対象システム | 販売管理（受注・在庫・請求・帳票）。2006年に社内で開発、稼働20年 |
| IT体制 | システム担当は正社員1名のみ。外部の保守契約なし |
販売管理システムは2006年、当時30代だった社員・井川さん（仮名）がVB6（Visual Basic 6＝四半世紀前に主流だった開発言語）で自作したものです。以来20年、消費税率の変更、軽減税率、インボイス制度——制度が変わるたびに井川さんが継ぎ足し、直し、育ててきました。設計書はありません。仕様のすべては、井川さんの頭の中にあります。
業績は安定していました。システムも、多少の癖はあれど動いていました。「動いているものに触るな」——この20年、それで困らなかったのです。では、なぜ丸谷社長（仮名）は筆者に相談を持ちかけたのでしょうか。
2. 社長から聞いた悩み——危機感はある。でも動けない
きっかけは、インボイス対応だったそうです。請求データに項目を追加したところ、翌月から納品書の印刷が時々失敗するようになった。井川さんが直すと、今度は月次の集計が合わない。1か所直すと、別の場所が壊れる。社内では「もぐらたたき」と呼ばれているそうです。
社長から聞いた現場の様子は、こうでした。
「月末の請求書発行は、事務の子がエラーが出ないことを祈りながらボタンを押してるんだよ」
「新しい商品を登録するのに2週間かかる。井川が悪いんじゃない。井川しかできないのが問題なんだ」
その井川さんは50代の正社員です。「あの人に聞けばわかる」の一言で20年、社内のITすべてを引き受けてきました。しかし今、井川さんの1日は障害対応だけで終わります。機能改修の依頼は20件以上溜まり、社員からの質問には数日返事ができない。そして社長の目には、井川さんの口数が年々減っているように映っています。
ここは誤解のないように書いておきます。これは井川さんの意欲の問題ではありません。20年間、たった1人にすべてを背負わせる構造は、どれほど優秀な担当者からも、余力と意欲を静かに削っていきます。 溜まる依頼、終わらない障害対応、答えられない質問——それでも代わりはいない。筆者には、井川さんの静かさは本人の資質ではなく、構造の帰結に見えました。
丸谷社長に危機感がないわけではありません。むしろ強い方です。ただ、口癖は冒頭のあの言葉でした。
「今どきAIを使えば、丸ごと作り直せるんだろう？」
実は3年前、刷新の検討が一度あったそうです。地元の開発会社が「段階的に移行しましょう」という提案を持ってきた。しかし社長はこれを退けました。「小出しに金を払うより、AIで一気に置き換えられるはずだ」。開発会社は「それは難しい」と答え、話はそこで止まりました。以来3年、危機感とAIへの期待はあるのに、具体的な一歩は何もない——それがこの会社の現在地です。
この会社が20年システムを更新しなかった本当の理由は、無関心ではありません。「全部やるか、やらないか」の二択で考えてしまい、「まず一部だけ」という選択肢を選べなかったからです。同じ構図の会社は、決して珍しくないはずです。
3. 現状システム——仕様は井川さんの頭の中
社長の「丸ごと作り直せないのか」を検討するには、まず「丸ごと」の中身を知る必要があります。聞き取った内容から、この会社の1日の流れを描くとこうなります。
下の図は、受注から請求までの業務の流れと、どこに手作業が挟まっているかを示しています。
FAXで届いた注文を事務員が目視で打ち込み、チェーン店の本部からはCSV（表計算ソフトで開ける形式のデータファイル）を毎朝手作業で取り込む。走り書きのFAXは電話で確認します。入力が終わるまで在庫の引当も出荷指示も始まらないので、朝の事務所はいつも時間との勝負です。
ちなみに、これはこの会社が特別に遅れているわけではありません。業務システム開発企業アイルの調査（2020年時点）では、中堅・中小企業の85.8%がFAX・電話など転記作業を伴う方法で受注しており、FAXだけで37.2%を占めます（出典は文末）。つまり**「FAXを手で打ち込む毎朝」は、日本の中小企業のごく普通の風景**です。普通であることと、安全であることは別ですが。
システムの構成はこうなっています。下の図は、この仕組みがどんな機器で動いているかを示したものです。
要点は3つです。設計書がない（増改築を繰り返した建物の、図面が存在しない状態です）。開発環境が井川さんのPCにしかない（直せる場所も人も1つだけ）。そしてサーバは2008年設置で、基本ソフト（OS＝Operating System、パソコンやサーバを動かす土台のソフト）はメーカーのサポートが切れたまま動いています。家に例えるなら、定期点検を受けられなくなった築古の建物に、金庫と帳簿を全部置いているようなものです。
なお、VB6という言語自体、開発元のMicrosoftが開発ツールのサポートを2008年に終了し、新しい技術への置き換えを公式に強く推奨しています（出典は文末）。つまりこの会社は、作った人・作った道具・動かす土台の3つが同時に寿命を迎えつつあるシステムで、毎日12億円分の商売を回していることになります。
4. 経営リスク——「システムの寿命」より先に「人の限界」が来る
この状態を放置すると何が起きるのか。相談を受けた筆者が最初に整理したのが、この表です。煽るためではなく、投資判断には「やらなかった場合の値段」が必要だからです。
| リスク | いま起きていること | 3年後 | 起きたときの影響 |
|---|---|---|---|
| 井川さんの離脱（退職・病気・消耗） | 依頼の滞留、口数の減少という兆候 | 定年が視野に。転職・離職も現実味 | 改修も障害対応も完全停止。納品業務の継続が困難に |
| もぐらたたき障害 | 帳票印刷が週次で失敗 | 制度対応のたびに悪化 | 請求遅延・誤請求。取引先の信頼喪失 |
| 基盤の老朽化 | サポート切れOS・18年物のサーバ機 | 部品も後継機も入手困難 | 故障したら復旧の当てがない |
| FAX・手入力依存 | 入力ミス・毎朝の残業 | 取引先の発注電子化に取り残される | チェーン系の大口取引先の離脱 |
「起きたときの影響」の桁感も押さえておきます。IT企業サイオステクノロジーの独自調査（2025年）では、過去3年に1時間以上のシステム停止を経験した企業が7割を超え、損失が最大だった障害では約25%の企業で損失額が1,000万円を超えたと報告されています。一民間企業の調査ではありますが、「システム停止は珍しい事故ではなく、起きれば百万円単位では済まないことがある」という相場観としては十分です。
とくに表の1行目が要注意です。多くの経営者は「サーバが壊れたら」を心配しますが、この会社の場合、機械より先に人が限界を迎える構図になっています。井川さんが明日入院したら、FAXの受注入力は続けられても、障害が起きた瞬間に誰も直せません。食品卸で納品が止まるということは、翌日の給食や店の仕込みに影響が出るということです。これは1社のシステムの話ではなく、BCP（Business Continuity Plan＝事業継続計画）、つまり「非常時にも商売を続けられるか」の問題です。
こうしたリスクは、この会社だけの特殊事情ではありません。経済産業省は2018年のDXレポート（DX=Digital Transformation＝デジタルによる業務変革）で、約8割の企業が老朽化したシステムを抱え、放置すれば2025年以降、国全体で年間最大12兆円の経済損失が生じうると警告しました。「2025年の崖」と呼ばれた予測です。2026年の今から見れば8年前の試算ですが、崖が「ある日突然落ちる」ものではなく、この会社のように障害と属人化がじわじわ進む形で現実になることを示す代表的な指摘として、いまも参照する価値があります。IT人材の側も、経済産業省の2019年の試算で2030年に最大79万人不足と予測されており（これも7年前の試算ですが、不足の方向感を示す数字として引用します）、「辞めた井川さんの代わりを雇えばいい」が年々難しくなっていくのは確かです。
ここまでが、筆者が見聞きした実情の整理です。ここから先は、筆者からの提案になります。最初にやってみたのは、社長のあの口癖を、そのままAIにぶつけてみることでした。
5. AIへ相談——「丸ごと変換できないのか」をClaudeに聞いてみた
相談相手はAIアシスタントのClaude。社長の期待を、脚色せずそのまま質問にしました。これは筆者が実際に行ったやりとりです。
相談: 「VB6で20年内製してきた販売管理システムがあります。設計書はなく、仕様がわかる社員は1人だけです。AIでこれを丸ごと新しいシステムに変換できませんか？」
Claudeの答えの要点は、こうでした。
Claudeの回答（要約）: 技術的には、AIはVB6のコードを新しい言語へ変換できます。しかしこのケースで一括変換はお勧めしません。理由は3つです。
- 正解を知る手段がありません。 設計書もテスト（動作確認の仕組み）もないため、変換後のシステムが「正しく」動いているかを判定できるのは担当者の記憶だけです。
- ぶっつけ本番になります。 卸売業は業務を止められません。一括切替は、検証不十分なシステムに全業務を一晩で乗せる賭けになります。
- コードには「なぜ」が書かれていません。 20年分の制度対応の意図——なぜこの計算式なのか、なぜこの例外があるのか——はコードから読み取れず、変換すると意図ごと失われる恐れがあります。
AIの得意分野は「丸ごと置き換え」ではなく**「解読」**です。VB6のコードを読んで失われた設計書を復元し、担当者の記憶を文書に変え、段階移行を速く・安くすることに使うべきです。
そのうえでClaudeは3つの選択肢を提示しました。
| 案 | 内容 | 概算費用【仮定・一般的な目安】 | 期間 | 主なリスク |
|---|---|---|---|---|
| A. AI一括変換（社長の当初案） | VB6全体を新技術へ変換し一斉切替 | 変換自体は安く見えるが、検証・手戻りで総額1,500万〜3,000万円 | 12〜18ヶ月 | 「正しく動くか」が本番当日までわからない |
| B. 段階移行 | AIで設計書を復元しつつ、受注周りから順にクラウド化。旧システムと並走 | 第1段階300万〜500万円＋月額数万円。全段階で計900万〜1,500万円 | 3年（第1段階は3〜4ヶ月） | 並走期間は新旧の二重運用の手間 |
| C. 延命＋文書化 | 現状維持。サーバ仮想化と担当者の知識の文書化のみ | 年150万〜250万円 | — | もぐらたたきと属人化の構造は残る |
ここで鵜呑みにせず、筆者から2点、突っ込みを入れました。
指摘1: 「B案、チェーン本部との発注データ連携の切替時期が雑です。本部側のデータ形式は、こちらの都合では変えられません。」 → Claudeは連携部分を「旧システムの取込口をそのまま残し、新ポータル側が旧形式に合わせる」方式に修正。切替は本部側のシステム更新時期に合わせる計画に改めました。
指摘2: 「FAXを急に廃止すると、昔ながらの個人店は離れますよ。」 → 「FAX受注は当面残し、Web発注は"使いたい得意先から"任意で移行。FAX分の入力画面だけ新システムに寄せる」形に修正されました。
AIの初案は8割正しく、2割は現場を知らない甘さがある——これが実際にやってみた率直な感想です。AIに答えを出させるのではなく、たたき台を出させて人間が現場の事情で削る。 この使い方なら、AIは中小企業にとって強力な武器になります。
6. 筆者の提案する経営判断——「全か無か」を降りる
繰り返しますが、この会社はまだ何も決めていません。決めるのは丸谷社長です。そのうえで、筆者が提案するならB案・段階移行の一択です。決め手は費用ではありません。時間です。
- B案を提案する理由: 設計書の復元は、井川さんが在職していて質問に答えられる今しかできない。3年後では遅い。そして第1段階（受注のWeb化）だけなら、失敗しても旧システムが並走しているので商売は止まらない。
- A案を勧めない理由: 社長が3年間温めた案ですが、AI自身が勧めませんでした。「変換はできます。ただし正しく動く保証は、検証の仕組みを作ってからです」——つまりA案を本気でやろうとすると、結局は設計書の復元と段階的な検証、すなわちB案の中身から始めることになります。
- C案を勧めない理由: 一番安く見えますが、井川さんの1日が障害対応で埋まる構造が何も変わりません。文書化だけ進めても、直せる人が1人である限り、リスクの時計は止まらない。
この判断で得るものは、属人化の解消（設計書＋誰でも触れる新基盤）、障害の減少、そして井川さんの時間です。失うものも正直に挙げます。並走期間の二重入力の手間、初期投資、そして「一気に新しくなる」という派手さ。段階移行は地味です。しかし地味さは、業務を止めないことの対価です。
下のグラフは、3案の5年間の総コストの目安を比べたものです（障害による機会損失は含みません）。
C案が最安に見えますが、これは「事故が起きなければ」の数字です。キーパーソンの離脱や基幹停止が一度でも起きれば、順位は簡単に入れ替わります。
投資判断としては、第1段階の300万〜500万円に対し、FAX入力・確認電話・障害対応に消えている工数の削減で年およそ250万〜350万円の効果、2年前後で回収と試算しました【仮定・詳細は第8章】。
7. 提案を形にしてみた——最初の一歩は「受注」から
提案書は言葉だけでは伝わりません。そこで筆者は、この提案の第1段階を実際に動くデモとして作ってみました。まず、3年計画の全体像です。
下の図は、移行を4段階に分けた進め方を示しています。
順番には理由があります。毎朝の手入力と判読ミスという「痛みが最も大きい業務」が受注であり、かつ受注は失敗しても旧システムで受け直せるため、最初の実験台に最適だからです。逆に請求・帳票は金額に直結するため、設計書と検証の仕組みが揃う最後に回します。
Phase 0でAIが果たす役割こそ、社長の「AIで丸ごと」の願いの正しい回収先です。実際に、VB6の請求計算に相当するコード片をClaudeに読ませると、「この分岐は2019年の軽減税率対応（食品8%と資材10%の混在処理）。ただし2023年のインボイス対応で追加された処理と税額の丸め順序が矛盾しており、帳票印刷が失敗する条件はここにあります」といった水準の解読が返ってきます。井川さんが記憶を頼りに説明していた仕様が、質問に答えるだけで文書になっていく——20年分の「頭の中」を、在職中に会社の資産へ変える作業です。
Before / After
| 観点 | Before | After（Phase 1） |
|---|---|---|
| 画面 | 灰色のVB6画面。商品コード表は壁に掲示 | ブラウザで開く受注ポータル。スマホでも見られる |
| 受注 | FAX約20件/日を目視で手入力 | 得意先が自分で発注。FAX分のみ新画面で入力 |
| 在庫引当 | 入力完了後にまとめて処理 | 受注一覧から1クリック。担当者を待たない |
| 基盤 | 事務所のサーバ機（2008年設置） | クラウド（サーバを自社で持たず、借りて使う方式）。サーバ室ごと不要に |
下の図は、Phase 1完了時点のシステム構成です。
サーバを持たない構成にしたのは、この規模の会社に「サーバの面倒を見る2人目の井川さん」を作らないためです。機械の保守から解放されることは、この規模の会社では機能の新しさより価値があります。
実際に触れるデモ
このケースを再現したデモを用意しました。旧画面（Before）では、ぜひ「帳票印刷」ボタンを押してみてください。 この会社の日常が体験できます。
🖥️ デモを触ってみる: 新旧比較の入口 ／ 旧・受注入力画面（Before） ／ 新・Web受注ポータル（After）
※デモは実際のシステムの複製ではなく、聞き取った業務の流れを筆者が再現したものです。画面・データはすべて架空で、ブラウザ内でのみ動作します。
デモ（＝Phase 1システム）の設計概要も載せておきます。自社で検討する際のたたき台にしてください。
画面一覧
| 画面 | 使う人 | 役割 |
|---|---|---|
| 発注画面 | 得意先（飲食店・給食室） | いつもの品を選んで発注。FAXの代替 |
| 受注一覧 | 社内（事務・営業） | Web・本部データ・FAXの受注を1画面に集約。在庫引当もここから |
| 在庫一覧 | 社内 | 在庫数と発注点の見える化（Phase 2で本移行） |
| 取込管理 | 社内 | チェーン本部の発注データの自動取込と結果確認 |
下の図は、このシステムが扱うデータ同士の関係（ER図＝Entity Relationship Diagram、データの関係図）です。
得意先・商品・受注・在庫という4つの情報のつながりだけで、Phase 1は成立します。旧システムの複雑さの大半は、この単純な構造の上に20年分の例外処理が積もったものでした。
API一覧（API＝Application Programming Interface、システム同士をつなぐ窓口。チェーン本部の発注システムや将来の会計ソフト連携がこの窓口を使います）
| 窓口 | 何をするか |
|---|---|
| 受注の登録・照会 | 発注画面・本部データ取込からの受注を受け付け、一覧に返す |
| 在庫の照会・引当 | 在庫数の確認と、受注への引当処理 |
| 本部発注データ取込 | チェーン本部の従来形式ファイルをそのまま受け取り変換する |
| 旧システム同期 | 在庫・請求のため、当面は旧システムへ毎時データを渡す |
8. 見込める効果——井川さんの1日は何に変わるか
Phase 1の効果を5つの観点で見積もります。数字は【仮定】を含む筆者の試算です。
| 観点 | Before | After（Phase 1） | 変化 |
|---|---|---|---|
| コスト | FAX入力・確認電話に約2時間/日、障害対応に担当者の大半 | 手入力は残FAX分のみ。障害対応が激減 | 工数換算で年250万〜350万円の削減【仮定】 |
| 保守 | 井川さん1人。設計書なし | 設計書あり。標準技術なので外部にも頼める | 「1人だけ」リスクの解消が始まる |
| セキュリティ | サポート切れOSのサーバに全データ | クラウド側で常時更新 | 点検切れの建物から引っ越し |
| BCP | サーバ故障・担当者不在で業務停止 | 受注はどの端末からでも継続可能 | 納品を止めない体制へ |
| 業務改善 | 朝は入力が終わるまで出荷が始まらない | 受注は即時反映、引当は1クリック | 出荷開始が平均1時間前倒し【仮定】 |
一方で、想定しておくべき「痛み」も書いておきます。並走期間は在庫・請求が旧システムに残るため、新旧の突き合わせ作業が月次で発生します。また、Web発注に移行してくれる得意先は初年度で3〜4割程度と見るのが現実的で【仮定】、FAXは当面なくなりません。効果は階段状にしか出ない——それでも、井川さんの1日が「もぐらたたき」から「設計書のレビューと検収」に変わることが、この投資の本当のリターンです。
9. 経営者向けまとめ——この記事は、あの社長への提案書でもあります
5年後、この会社が「あの判断は成功だった」と言えるかどうかの物差しは、システムが新しくなったかではありません。「井川さんしかわからない」が消えているかです。設計書があり、標準技術で動き、外部にも頼める状態になっていれば、たとえ移行が3年計画より遅れていても、この会社はもう崖の縁にはいません。逆に、いま動かなければ——3年前と同じ「全か無か」の袋小路で、井川さんの残り時間だけが減っていきます。
同じ状況の会社の経営者に、順番だけお伝えします。
- 今月やること（費用ゼロ）: 「システムの仕様を知っている人は誰か」「その人が明日入院したらどうなるか」を紙に書き出す。井川さんにあたる人の名前が1人しか出てこなければ、それが危険信号です。
- 今期やること: AIも使いながら、動いているシステムの設計書の復元を始める。これは刷新するかどうかを決める前でも無駄になりません。キーパーソンが在職しているうちにしかできない、期限付きの作業です。
- やらなくていいこと: 「AIで丸ごと」に賭けること。AIは置き換えの魔法ではなく、解読と移行を速くする道具です。全か無かの二択に戻った瞬間、また3年止まります。
社長向け判断シート（筆者の評価）
| 項目 | 評価 | 根拠 |
|---|---|---|
| 緊急度 | ★★★★☆ | 基幹停止はまだ起きていないが、障害は週次。人の限界が先に来る |
| ROI（Return on Investment＝投資対効果） | ★★★★☆ | 第1段階は2年前後で回収見込み【仮定】。属人化解消の価値は数字以上 |
| 投資規模 | ★★☆☆☆ | 段階移行なら初期300万〜500万円から。★が少ないほど着手しやすい |
| 難易度 | ★★★☆☆ | 山は技術より「並走期間の運用」と「得意先の巻き込み」 |
| おすすめ | ★★★★☆ | キーパーソン在職中という時限条件があるため、検討の先送りだけは勧めない |
タイトルの問い——「AIで丸ごと作り直せないのか」——への筆者の答えは、「作り直せます。ただし丸ごとではなく、順番に。そしてAIの一番の出番は、変換ではなく解読です」。この記事は、読者のみなさんへのケーススタディであると同時に、丸谷社長への提案書でもあります。次にお会いするとき、「まず設計書の復元からやってみるか」と言っていただけたら、筆者としてこれほど嬉しいことはありません。
参考・出典
- 経済産業省「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（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/
- 本文中の費用・工数・回収年数はいずれも【仮定】と明記した筆者の試算・一般的な目安であり、個別の見積もりに代わるものではありません。システム投資の判断にあたっては、複数の専門事業者への相談をお勧めします。