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

受注を入れる、一覧で探す、ボタンで承認に回す。こうした画面なら、いまは AI に頼めば驚くほど早く形になります。それなのに、稼働してから行き詰まる例は後を絶ちません。難所は画面づくりではなく、日々の取引を何年も受け止め続けることにあるからです。

以下では、AI で組んだ仕組みが稼働後に崩れやすい所を順に挙げ、終わりに当社のやり方（Odoo Community の上に、日本の業務に要る部品を重ねる）を紹介します。

AI は手の速い相棒です。けれども取り決めが曖昧なまま走らせると、出来上がるのが早いぶん、ほころびも早く広がります。

先に要点

試しに動く物と、本番で使い続けられる物は、求められることが違う
頼まれるたびに機能を足すと、決まりがあちこちに散る
作った本人しか中を知らない仕組みは、その人がいなくなると止まる
導入の山に合わせて IT の人を抱えると、山が過ぎたあとに重くなる
コードやデータを誰がどこで扱うかを決めずに進めると、あとで困る

1. 試作では見えない、本番の重さ

デモを見せられると、もう一息で現場に出せそうに思えます。ところがデモの多くは、操作する人が一人だけで、伝票も教科書どおりの順に流れる前提で組まれています。

稼働後の現場では、こんなことが日常です。

一枚の伝票に何人もの手が入る。営業が数量を直している間に、倉庫は出荷を済ませ、経理は請求書を出している。どの操作を優先するかを決めていなければ、売上・在庫・請求の数字が食い違っていきます。

寄り道する取引がある。取消し、戻り品、分納、値引き、月を締めたあとの訂正。請求済みの注文で数が変わったら、売上と在庫のどちらを直し、差額をどう請求し、先に出した書類をどう扱うか。答えが用意されていなければ、担当者はそこで手が止まります。

記録が貯まるほど重くなる。デモの伝票は数十件でも、稼働すれば何年分も積み上がります。毎朝の出荷リストが開くまで待たされるようでは、現場は手元の表計算へ戻っていきます。

閲覧の線引きが無い。デモは全員を最上位の権限で動かすのが普通です。その設定のまま稼働すると、原価や利益の数字が、見せる予定の無い社員の画面にまで並びます。

書き換えの記録が無い。仕入の注文額がいつの間にか違っていても、手を入れた人と日時が分からなければ、原因もたどれず、手の打ちようもありません。

連携が途中で切れる。ネットショップの受注を取り込む処理が半ばで落ち、もう一度流すと、今度は同じ受注が重なって入る。途中で失敗したときの戻し先を設計していなければ、これはありふれた事故です。

元になる台帳を直すと、過去がずれる。品名や得意先、売値、作業の手順は年々改まります。値上げを登録したとたんに去年の見積書の金額まで変わるようでは、記録として意味を成しません。

見るべきは、デモの出来ではなく、例外の多い月末でも止まらずに回るかどうかです。

2. 足し続けると、決まりが散らばる

「ここに絞り込みを付けて」「この課は承認なしで」「この得意先だけ値段を下げて」。こうした注文に、AI はすぐ応えます。ただ、見取り図を持たずに継ぎ足していくと、しばらくして次のような姿になります。

同じ役目の機能が重複する。得意先を探す入口が3つあり、ある所は社名でしか引けず、別の所は取引をやめた先まで表に出る。正解がどれなのか誰も言えない
仮の対応が居座る。「今月限り」「この品番に限り」のはずの特例が、経緯を知る人がいなくなったあとも動き続ける
用語がそろわない。ある画面は「顧客」、別の画面は「得意先」。新人に教えるのも検索するのも手間になり、やがて意味そのものがずれる
似た欄が増殖する。進み具合を示す欄が承認用・出荷用・経理用と分かれ、どれを信じるかが画面ごとに違う。一つを直すと、無関係に見えた書類が崩れる
点検が間に合わない。作る速さに比べて、人が影響を調べる速さはほとんど変わらない。仕入の画面に手を入れたら倉庫と経理への引き渡しが止まっていた、と稼働後に知る

責めるべきは AI ではありません。見取り図を描く役を誰も持たないまま、足し算だけを続けることです。

3. 作った人しか分からない仕組み

手が速く進むほど、判断の理由は書き残されにくくなります。事情を知る人がいる間は、口伝えで何とかなります。「その計算は裏で動いている」「その取り込みはもう一度押すと重複する」。ところが本人が抜けると、中で何が起きているか誰も説明できなくなります。

基幹の仕組みは、部品どうしが絡み合っています。品目の欄の名前を一つ変えたら、見積書の印刷、取引先への書き出し、在庫の集計まで止まった、ということが起きます。行き着く先は「いっそ作り直そう」ですが、取り決めが曖昧なまま作り直しても、同じ所でまたつまずきます。

4. IT の人を抱えすぎない

IT に明るい社員が社内にいるのは強みです。自社の流れを知る人が自分で手直しできれば、改善の回りは速くなります。

ただ、基幹の入れ替えは、忙しさが一定ではありません。最初の数か月は、設計とデータの移し替えと業務の見直しが重なります。稼働して落ち着けば、手のかかる量は減ります。しかも AI の進歩で、要る技能そのものが年ごとに入れ替わります。

繁忙の頂点に合わせて採用すると、峠を越えたあとに、毎月の給与と「この人に何を任せるか」という問いが残ります。当社の考える内製化は、社内に全員をそろえることではありません。腕の要る場面で、外の専門家をすぐ呼べる関係を持っておくことです。小さく始めて、覚えたことを社内に貯め、社内で持ち続ける部分は後から選ぶ。技術の入れ替わりが速い今は、この順が無理がありません。

5. コードとデータの扱いを決めておく

一人でも短期間でアプリを組める時代になり、手元に置く物の扱いも、前より気を配る必要が出てきました。

プログラムと、その設計の記録
現場の段取りや、紙に書かれていない工夫
得意先・仕入先の名簿
原価や利益率のような、社外秘の数字

閲覧できる人、保管の場所、契約が切れたときの返し方、生成 AI のサービスへ貼り付けてよい範囲。基幹の仕組みには売上も仕入も原価も集まるので、ここを曖昧にしたまま手軽さを優先すると、取り返しがつかなくなります。当社は会社どうしの契約と秘密保持の取り決めを結んだうえで、お客様のプログラムとデータを預かります。

6. つまずきの元は、コードより手前にある

振り返ると、どの失敗も根は同じです。書いたコードの量や速さではなく、その前にある業務の取り決めが曖昧なことです。

仕組みに載せる仕事と、手元の表で続ける仕事の線
承認の印を押す人
在庫の数が確定する瞬間
締め後に誤りが見つかったときの直し方
連携が途中で落ちたときの戻し先
移行した週の問い合わせを受け止める人

こうした線引きは、コードを書かせる前に人が引くものです。たとえるなら AI は手の速い職人で、間取りや暮らし方を決めるのは施主の側です。

7. ゼロから作らない

では、どう作ればよいか。当社の答えは、すでに多くの会社で動いている ERP を土台にして、足りない所だけを足すことです。

閲覧の線引き、書き換えの記録、機能を重ねる作法。これらはどの会社の基幹にも共通する下地です。案件ごとに AI に一から組ませれば、毎回同じ落とし穴を掘り直すことになります。

Odoo Community は、この土台を最初から持っています。公式の配布物に入っているモジュールは 692 個（Odoo 19、当社が数えた数）。販売・購買・在庫・請求と会計・製造といった基幹の業務は、Community の範囲で揃います。

たとえば「誰が何を見てよいか」は、利用者ごとに、アプリごとの段階で決めます。販売なら「自分の書類だけ」「すべての書類」「管理者」の 3 段階です。

利用者のアクセス権のタブ。アプリごとに段階を選びます（画面は見本のデータです）

「誰がいつ何を変えたか」も、項目ごとに履歴に残す仕組みがあります。受注なら、顧客・金額・ステータス・販売担当者など 8 つの項目は、変えるとその記録の下に履歴として残ります。

8. Odoo Community に、日本向けの部品を足す

一方で、日本の会社がそのまま使うには足りない物があります。締め請求書、全銀協の形式の振込データ、日本の様式の帳票は、Community にも Enterprise にも入っていません。振込手数料の差額は標準でも手数料の勘定へ振り替えて請求ごとに消し込めますが、得意先ごとの手数料の負担の決まりや、まとめて振り込まれた入金の割り当ては入っていません。多段の承認も、Community の購買にあるのは「金額の基準を 1 つ決めて、基準以上の発注に管理者の承認を 1 段挟む」までで、承認のアプリ（approvals）は Enterprise 側です。

当社は、これらを日本向けの部品（アドオン）として足します。公式の Odoo には手を入れず、別の部品として重ねるので、版を上げても公式の部分はそのまま入れ替えられます。

足し方には決まりがあります。Odoo の拡張の道具はとても強く、使い方を誤ると、エラーも出ずにほかの部品の処理が消えます。当社は Odoo 19 Community で 11 の実験・28 項目を確かめ、そこから「やってはいけない」8 つの決まりを作って守っています。中身は次の記事にまとめました。

ここまでのつまずきのうち、仕組みの側で受け止められる物は、この形にすると次のようになります。

つまずき	出てきた節	受け止める所
見てよい範囲が決まっていない	1 節	Odoo の権限（アプリごとの段階と、行ごとのルール）
変えた履歴が残らない	1 節	Odoo の項目ごとの履歴。足りない項目は部品で足します
決まりが散らばる	2 節	日本の会社に共通の物は日本向けの部品へ、御社だけの物は御社ごとの部品へ、と置き場を分ける
作った人しか分からない	3 節	公式の Odoo と同じ作りのアドオンなので、Odoo を知る技術者なら読める
版を上げると壊れる	この節	公式には手を入れず、上の決まりを守って足す

4〜6 節（人の抱え方・コードとデータの扱い・業務の取り決め）は、仕組みではなく決め事の話なので、この表には入れていません。

9. 速く作れる時代こそ、土台を知る相手と組む

開発の速さは、AI でまちがいなく上がりました。その裏で、仕組みを理解しないまま稼働させてしまう危うさも大きくなっています。画面も登録も通知も動いている、だから大丈夫。そう見えても、同時の操作、例外、閲覧の線引き、書き換えの記録、連携、台帳の改定、引き継ぎのどれかが抜けていれば、稼働して早々に行き詰まります。

当社は AI を使う開発に反対していません。作るのが速くなった今だから、Odoo の標準に任せる所、部品で足す所、あえて作らない所の線引きを最初に引くことが効いてきます。Odoo Community の上に日本の業務に要る部品を重ね、御社が自分で持てる形でお渡しする。それが、一から迷わずに業務システムを立ち上げるための、当社のやり方です。