AIでERPを作れる時代に、なぜ業務システムは失敗するのか

AIを使うと、業務システムの試作品は驚くほど早く作れます。

顧客を登録する。注文を入力する。一覧を見る。承認ボタンを押す。こうした「画面として動くもの」は、以前よりずっと短い期間で作れるようになりました。

ただし、ERPや基幹システムで本当に難しいのは、画面を作ることではありません。

難しいのは、毎日の仕事に乗せても壊れないようにすることです。

• 複数人が同時に使う
• キャンセルや返品など、例外が起きる
• 見てよい情報と見てはいけない情報を分ける
• 誰が何を変更したか、あとから追えるようにする
• Excelや他のシステムとつなぐ
• 担当者が変わっても保守できるようにする

AI開発時代には、「動くものが早くできる」からこそ、こうした本番運用の難しさが見えにくくなります。

この記事では、AIで業務システムを作るときに起きがちな失敗を、システムに詳しくない方にも分かるように整理します。

---

この記事で伝えたいこと

この記事の全体像は、次の5つです。

1つ目は、試作品と本番運用は別物だということです。
1人で触って動く画面でも、営業、経理、現場、管理者が同時に使うと問題が出ます。

2つ目は、AIで機能を足し続けると、ルールが散らばりやすいということです。
要望のたびに画面を直すと、半年後には「どれが正しいルールなのか」が分からなくなります。

3つ目は、作った人しか分からないシステムは長く使えないということです。
詳しい担当者が退職した瞬間に、直せない、調べられない、引き継げない状態になります。

4つ目は、IT人材を急いで抱えすぎるリスクです。
導入期だけ忙しいからと正社員を増やすと、安定後に固定費や役割設計が重くなることがあります。

5つ目は、開発資産の管理リスクです。
AIで誰でも作れる時代だからこそ、ソースコード、設計情報、顧客データ、運用ノウハウを誰がどう扱うかが重要になります。

では、順番に見ていきます。

---

1. 試作品は動く。でも本番では崩れる

AIを使うと、1〜2ヶ月で「それっぽく動く業務システム」を作れることがあります。

デモ画面だけを見ると、「これならもう少し整えれば本番でも使えそうだ」と感じます。

しかし、本番の仕事はデモよりずっと複雑です。

1人なら動くが、複数人で使うと壊れる

デモでは、1人が1件ずつ登録するだけです。

本番では、営業、経理、現場、管理者が同じデータを同時に触ります。すると、上書きや二重登録、状態の食い違いが起きます。

たとえば、次のようなことです。

• 「承認済み」の注文が、別の人の更新で「下書き」に戻る
• 出荷済みの注文に、営業が後から数量変更を入れる
• 経理が請求書を出したあとに、現場側で在庫数が変わる

画面上は小さなズレに見えても、売上、在庫、請求金額に影響します。

例外業務に耐えられない

試作品では、「注文 → 出荷 → 請求」というまっすぐな流れだけを作りがちです。

しかし実際の仕事では、キャンセル、返品、分納、値引き、数量変更、締め後の修正、請求書の再発行が普通に起きます。

たとえば、請求書を出したあとに数量変更が入ったとします。

このとき、売上を直すのか。在庫を直すのか。請求金額を直すのか。差額だけ請求するのか。過去の帳票はそのまま残すのか。

この決めごとがないと、画面はあっても、現場は判断できません。

件数が増えると急に重くなる

デモデータが10件なら、一覧画面も検索画面も速く動きます。

しかし本番で10万件になると、急に重くなることがあります。毎朝の出荷一覧を開くたびに30秒待つようになれば、現場はすぐExcelに戻ります。

「動く」と「毎日ストレスなく使える」は別です。

権限が雑で、本番に出せない

試作品では、全員が管理者のような強い権限で使うことがあります。

本番では違います。誰が何を見てよいのか。誰が直してよいのか。誰が承認できるのか。部署ごとに見せる範囲を変えるのか。

ここを決めないと、一般社員が原価、粗利、給与単価まで見えてしまうことがあります。

権限とは、かんたんに言えば「見える範囲」と「直せる範囲」の交通整理です。

変更の足あとが残らない

本番では、「今どうなっているか」だけでなく、「誰が、いつ、何を変えたか」が重要です。

これを監査ログと呼びます。難しく聞こえますが、要するに変更の足あとです。

たとえば、発注金額が変わっていたとします。誰が変更したのか分からないと、原因も責任の所在も分かりません。再発防止もできません。

外部連携の失敗を考えていない

ECサイト、会計ソフト、配送システムなど、別のシステムと自動でつなぐことがあります。

これを外部連携と呼びます。成功すると便利ですが、失敗時の設計が必要です。

たとえば、EC注文の取り込みが途中で止まり、半分だけ登録済みになる。もう一度実行すると、今度は同じ注文が二重に登録される。

こうしたことは、実際の運用では起こり得ます。

マスタ変更に弱い

マスタとは、商品名、取引先、単価、工程、部署など、仕事の土台になる情報です。

デモでは固定でも、本番では商品名変更、廃番、単価改定、部署変更、工程追加が起きます。

過去の見積まで新しい単価で計算し直されてしまうと、当時の金額が壊れます。今の変更が、過去の証拠まで壊してしまうのです。

---

2. AIで機能を足し続けると、ルールが散らばる

AIは機能追加が得意です。

「この画面にも検索を付けて」
「この部署だけ承認ルートを変えて」
「この条件だけ特別価格にして」
「この一覧もCSVで出せるようにして」

こう頼むと、それらしい機能をすぐ作れます。

しかし、全体の整理をしないまま機能だけ増えると、半年後にはルールが散らばります。

同じような機能が何個もできる

たとえば「顧客検索」が3か所にできたとします。

• A画面は名前だけで検索できる
• B画面はメールアドレスでも検索できる
• C画面は削除済みの顧客まで表示される

どれが正しい仕様なのか、後から分からなくなります。

一時対応が正式ルールになる

「とりあえず、この取引先だけ特別価格にする」
「今月だけ、この部署は承認なしで通す」
「この商品だけ、在庫を見ないで出荷できるようにする」

こうした一時対応が、いつの間にか本番の正式ルールとして残ることがあります。

半年後に見返しても、なぜその特例があるのか誰も説明できません。

画面ごとに言葉が違う

同じ意味なのに、画面によって「顧客」「取引先」「得意先」「会社」と呼び方が違う。

これだけでも、現場は迷います。検索もしづらくなり、教育もしづらくなります。

ERPでは、言葉の統一がとても大切です。言葉がずれると、業務のルールもずれていきます。

項目が増えすぎる

「状態」という項目があるのに、「承認状態」「表示状態」「出荷状態」「会計状態」が増えていく。

どれを見れば正しいのか、画面ごとに違う。

こうなると、直す側も使う側も混乱します。1つの項目を変えただけで、思わぬ帳票や連携が壊れることもあります。

確認が追いつかない

AIは機能追加を速くします。

しかし、人間が「壊れていないか」を確認する速度は、そこまで急には上がりません。

購買画面を直したら、在庫画面、会計連携、帳票出力が壊れていた。でも気づくのは本番後。

これは珍しい話ではありません。

---

3. 担当者が辞めると、誰も分からないシステムになる

AI開発で怖いのは、作業が速いぶん、判断理由が残らないまま進みやすいことです。

詳しい担当者が1人いるうちは、何とか回ります。

• あの処理はこの画面の裏側にあります
• この項目は昔の例外対応です
• この連携は再実行すると二重登録になるので注意してください
• この帳票は、この取引先だけ特別です

しかし、その担当者が退職した瞬間、システムはブラックボックス化します。

ブラックボックスとは、外から見ても中身が分からない箱のような状態です。動いている理由も、直し方も、影響範囲も分からない。

ERPでは、1つの変更が広い範囲に影響します。

商品マスタの項目名を変えただけで、見積、発注、CSV出力、外部連携、PDF帳票、在庫集計が連鎖的に壊れることがあります。

こうなると、保守するよりも作り直した方が早い、という判断になりがちです。

しかし、作り直しても業務の決めごとが整理されていなければ、同じ失敗を繰り返します。

---

4. IT人材を“固定費化”しすぎる

AI時代のERP導入では、「すべてを自社だけで作る」ことが必ずしも正解ではありません。

もちろん、社内にITの知見を残すことは大切です。自社の業務を理解し、自分たちで改善できる力は、これからますます重要になります。

ただし、基幹システムの導入や刷新には、仕事量の波があります。

• 導入初期は、開発、データ移行、業務整理が一気に増える
• 安定後は、必要な作業量が落ち着く
• AIの進化で、必要なスキルが短期間で変わる
• 何人雇えばよいか、最初は読みにくい
• 雇ったあとに、その人の仕事を作る必要が出る

導入期の一時的な山に合わせて正社員を増やすと、あとで固定費と役割設計が重くなることがあります。

固定費とは、売上や仕事量に関係なく毎月かかる費用です。人件費は代表的な固定費です。

基幹システムは、最初の数ヶ月から1年ほどは大きな力が必要です。しかし、安定運用に入ると、毎日大人数で開発し続けるとは限りません。

そのため、AI時代の内製化は「全部自社で抱えること」ではなく、必要な技術を、必要な時期に、必要なだけ使える体制を持つことだと考えています。

正社員を急いで増やす前に、まずは外部パートナーと組んで小さく始める。業務に合う形で作り込み、必要な知見を社内に残す。そのうえで、本当に内製化すべき部分を見極める。

この進め方の方が、変化の速いAI時代には現実的です。

MY HATCHは、AI時代の「持たない情シス部門」として活用できます。

基幹システムの導入、ERPNextのカスタマイズ、業務画面の改善、AI活用まで。必要なときに必要な分だけ、実装まで伴走する外部ITチームです。

自社にノウハウを残しながら、IT人材を過剰に固定費化しない。これも、AI時代のERP導入で見落としがちな大切な視点です。

---

5. 開発資産の管理があいまいになる

AI時代は、個人でも短期間でサービスや業務アプリを作れるようになりました。

これは大きな進歩です。一方で、業務システムでは管理すべきものも増えています。

• ソースコード
• 設計情報
• 業務の運用ルール
• 顧客データ
• 取引先データ
• 原価や粗利などの重要情報
• 現場だけが知っている運用ノウハウ

これらは、会社にとって大切な資産です。

コード生成AIやクラウド開発環境を使えば、作ること自体は速くなります。しかし、誰がその情報に触れてよいのか。どこに保存してよいのか。退職後や契約終了後にどう扱うのか。外部サービスに入力してよい情報はどこまでか。

こうしたルールがあいまいなまま進めると、あとで大きな問題になります。

特に基幹システムには、売上、仕入、在庫、原価、請求、顧客情報など、会社の重要情報が集まります。便利だからという理由だけで、管理ルールのない場所に情報を置くのは危険です。

MY HATCHは、法人としての契約、守秘義務、運用ルールのもとで、お客様の業務資産を扱います。

属人的な開発ではなく、責任ある外部パートナーとして、安心して協力できる体制を重視しています。

AIで作れる時代だからこそ、「誰が責任を持って扱うのか」を明確にすることが大切です。

---

6. 失敗の原因は「コード」より前にある

ここまでの失敗には、共通点があります。

問題は、コードの量や開発スピードだけではありません。もっと手前にある、業務の決めごとが整理されていないことです。

たとえば、次のようなことです。

• どの仕事をERPに乗せるのか
• どこはExcelに残すのか
• 誰が承認するのか
• 在庫はどの時点で確定するのか
• 締め後の修正をどう扱うのか
• 外部連携が失敗したら、どこまで戻せるのか
• 切替直後の現場の混乱を、誰がどう支えるのか

これらは、AIにコードを書かせる前に、人間が決めるべきことです。

AIは強力な道具です。

ただし、道具は設計図の代わりにはなりません。家づくりで言えば、AIは腕のよい職人のような存在です。けれど、どんな家にするか、どこに柱を立てるか、家族がどう暮らすかは、人間が決める必要があります。

業務システムも同じです。

---

7. では、ゼロから作るべきか

では、AI時代の業務システムはどう作るべきでしょうか。

答えは、すべてをゼロから作ることではありません。

むしろ、検証されたERPを発射台にし、その上で自社に必要な部分を整える方が現実的です。

ERPNextは、販売、購買、在庫、会計、製造など、会社の基幹業務に必要な仕組みを持つオープンソースERPです。

その土台であるFrappeは、ERPNextを動かすための仕組みです。権限、承認の流れ、変更履歴、レポート、外部連携など、業務システムに必要な基本機能を支えています。

つまり、ERPNext / Frappeを使う意味は、「最初から画面がある」ことだけではありません。

業務システムに必要な考え方が、すでに土台として組み込まれていることにあります。

---

8. 自社実装に寄り添う — ERPNext.JPという選択肢

ERPNext.JPは、ERPNextを日本企業の実務に合わせて活用するための発射台です。

MY HATCHの価値は、単にソースコードを届けることではありません。

大切なのは、ソースコードより一段上にある、業務・運用・切替・保守の設計を一緒に整えることです。

たとえば、次のような領域です。

• システム外に残っている現場の工夫を、どう取り込むか
• Excelや既存システムと、どこまで連携し、どこからERPに寄せるか
• 工場現場の要件を、画面、帳票、入力の流れにどう落とし込むか
• 新旧システムの切替を、どの順番で、どのデータから進めるか
• 切替後の混乱期に、現場をどう支えるか
• AIや内製開発で増え続ける要望を、どの順番で整理するか

こうした領域は、コードだけでは解決できません。

ERP導入では、現場の言葉、仕事の順番、例外処理、権限、変更の足あと、既存運用との折り合いを、細かく見ていく必要があります。

ここに、導入実績とFrappe / ERPNextへの深い理解が効いてきます。

AI時代のERP導入では、いきなりIT社員を増やすより、外部パートナーを使って小さく始める方が安全な場面があります。

必要なときに必要な専門性を使いながら、自社にノウハウを残す。過剰な固定費を持たずに、基幹システムを育てていく。

ERPNext.JPは、そのための発射台です。

---

9. AI開発時代だからこそ、土台を理解した伴走者が必要になる

AIによって、業務システム開発は確実に速くなりました。これは大きなチャンスです。

しかし同時に、「理解しないまま本番へ出す危険」も増えています。

動く画面がある。登録もできる。通知も飛ぶ。だから大丈夫。

そう見えても、複数人利用、例外業務、権限、変更の足あと、外部連携、マスタ変更、保守体制まで見えていなければ、本番運用ではすぐに限界が来ます。

MY HATCHは、AI開発を否定しているわけではありません。

むしろ、AIで開発が速くなる時代だからこそ、何を標準機能で受け止め、何を拡張し、何を作らないかを整理する力が重要だと考えています。

Frappe / ERPNextを深く理解し、設計・権限・証跡・保守まで見据えて伴走する。

AI時代の内製化は、「全部自社で抱えること」ではありません。

必要な技術を、必要な時期に、必要なだけ使える体制を持つことです。

ERPNext.JPは、AI開発時代の自社実装にとって、ゼロから迷わず始めるための現実的な発射台になります。