自然言語 → LLM → MCP/API → Odoo
検索・作成・更新の入口を提供。既存の業務処理があれば呼び出せますが、独自業務の定義や検証・承認は別途設計が必要です。
ODOO 20 TRANSITION & RE-ARCHITECTURE · SYNAPSE
まだ、画面とボタンを
開発しているのですか。
その開発自体が、もう必要ないかもしれません。
「今月の請求書をまとめて作って」。利用者の要望は、それだけです。画面の追加を前提にせず、必要な業務処理と事前検証を設計するERPへ。
Odoo 20への移行を、単なるコードの移植で終わらせない。不要な画面・追加モジュール・Enterprise依存を見直し、自然言語で業務を進める基盤へ。
開発すべき機能から見直すEnterprise → Communityの可能性外部モジュールの依存整理AIの事前検証と承認
※ 個別査定前に移行費用やコスト削減額を保証するものではありません。Odoo 20への対応範囲は対象機能ごとに検証します。
01 / STOP BUILDING WHAT USERS NEVER ASKED FOR
まだ、画面とボタンを
開発しているのですか。
その開発自体が、もう必要ないかもしれません。
利用者が求めたのは「締日を入力する画面」ではありません。正しい合計請求書を作成することです。AI時代のERP開発で最初に考えるべきなのは、何を速く作るかではなく、何を作らずに済ませられるかです。
同じ業務要件を、2つの体験で比較
SCREEN-FIRST ERP人間がシステムに合わせる
● ● ● 請求管理 / 操作イメージ
01 対象取引先と設定を確認
02 請求メニューを探す
03 締日・対象期間を入力
04 集計ボタンを操作
05 内容を別画面で照合
設定・操作の確認中…
個別画面・操作・設定の理解が利用者側に求められがちです。
INTENT-FIRST ERP · SYNAPSEシステムが業務を理解する
取引先別の締日・対象期間を照合
請求済み・未確定・例外を検証
税額・会計ルール・承認条件を確認
PREVIEW · NOT WRITTEN作成予定を提示 → 利用者の承認を待つ承認後に、許可された処理だけを実行
依頼は一言。判断が必要なときだけ人間が確認します。
※ アニメーションは業務設計の概念デモです。実際の請求書生成・Odooへの書き込みは行いません。必要な業務ルールや計算機能は、対象環境に応じて実装・検証します。
THE ESSENCE「AIで画面を自動生成」することさえ、
「AIで画面を自動生成」することさえ、
最終目的ではない。
画面がなくても安全に遂行できる業務は、画面を作らない。必要な業務機能は作る。しかし、人がボタンを押すためだけの開発は減らす。
02 / CONNECTING TO ERP IS NOT THE SAME AS UNDERSTANDING WORK
MCPでつながる。
では、誰が業務の正しさを担保するのか。
Odoo標準のMCP/APIは検索や更新の重要な接続手段です。ただし、接続だけで企業固有の締日、原価、承認、例外、管理会計の定義がそろうわけではありません。接続方式ではなく業務を実行するための設計の有無を比較します。
自然言語 → 業務構造・検証 → 承認 → Odoo
Synapseは業務の意味・関連データ・変更影響を明示し、実行前に検証。既存の処理で足りれば専用画面を増やさず、必要なロジックのみ実装します。
重要：ナレッジグラフだけで事故がなくなるわけではありません。整合性を検証するコード、権限、承認ゲート、監査、テストを組み合わせ、誤処理のリスクを下げる仕組みです。
03 / CURRENT COST STRUCTURE
そのOdoo運用、当たり前だと思っていませんか？
Enterprise費用を、ずっと払い続けますか。
今使っている機能を棚卸しし、Communityで代替できる部分と、Enterpriseを継続すべき部分を分けて判断します。
その追加モジュールと画面、本当に必要ですか。
OCA・サードパーティ・独自コードを出所だけで判断せず、利用実態、依存、保守状態から評価。不要な移植を減らします。
APIがつながった。それで業務は任せられますか。
自然言語で更新できることと、承認・原価・後続処理の整合性を守れることは別です。実行前の確認を仕組みに組み込みます。
04 / JAPANESE BILLING — A CONCRETE CASE
「20日締めの合計請求書を作りたい。」
その業務、次のバージョンでも継ぎ足しますか？
Odooで日本の締め請求や合計請求書を扱うため、OCAでは目的の異なる複数の追加モジュールが公開されています。個々のモジュールは価値のある成果です。しかし、企業が必要とするのはモジュールの数ではなく、正しい締め請求という一つの業務です。
顧客の依頼
「A社の20日締め分を集計して、合計請求書を準備して」
締日、対象期間、未確定伝票、税額と端数、承認・発行権限まで考慮する必要があります。
関連するOCA拡張の例
- account_payment_term_cutoff_day
- account_billing
- account_billing_from_cutoff
- l10n_jp_summary_invoice
支払条件、請求書グループ化、締日を起点とした一括処理、日本式合計請求書など、役割の異なる機能を組み合わせる。
Synapseが提案する再設計
現行の拡張の利用実態と依存を調査し、残す・統合する・置き換える機能を選別。
業務定義・検証・承認・実装の対応を維持し、自然言語から同じ処理を安全に呼び出せる仕組みを設計します。
※ これは関連モジュールの用途を示した概念図です。すべてのモジュールが同時に必須、相互に直接依存、あるいはSynapseで自動的に廃止できることを意味しません。各システムで実際の依存・会計要件・データを確認します。
次期Odooで各モジュールの互換性・保守状況・関連する変更を、どこまで再検証する必要があるか。既存コードを移すこと自体を目的にしていませんか。
締日、対象取引、税額、除外条件、発行承認を定義すれば、より簡潔な実装や運用に置き換えられないか。「準備」と「確定」を分けて実行できないか。
機能を追加するたびに、次の移行費用まで増やしていませんか。
OCAの成果を否定するものではありません。実際に役立つ機能は活用しつつ、外部コードの継続利用・標準化・再実装のどれが最善かを業務要件と複数年TCOで判断する、という提案です。
05 / TWO APPROACHES
単なるバージョンアップと、再設計を伴う移行。
すべての従来型導入に当てはまる比較ではありません。設計情報が維持されず、カスタマイズをそのまま移植する場合と、Synapseを利用して業務から再設計する場合を比較しています。
| 論点 | カスタマイズの移植を中心とする方式 | Synapseによる再設計を含む方式 |
|---|---|---|
| 開発対象 | 個別画面・ボタン・追加モジュールで要求を満たす設計になりやすい | 業務の実現手段から再検討。既存処理で足りるなら専用画面を作らず、必要な業務ロジックだけを開発 |
| ライセンス | Enterprise継続を前提に検討しやすい | Community移行の可否を先に査定。可能ならEE利用料の解消を検討 |
| 追加モジュール | 既存機能・コードの互換性や依存を個別確認 | 利用実態と依存関係を棚卸しし、廃止・代替・維持を選別 |
| 自然言語操作 | MCP/APIを接続し、許可された操作を実行 | 業務構造と承認条件を設計し、実行前の検証を追加 |
| 管理会計 | 独自KPIや集計条件を個別実装・保守 | 指標の意味・粒度・計算関係を定義し、自然言語の取得にも再利用 |
| 将来の更新 | 修正が必要な箇所を都度調査 | 設計とコードの対応を維持し、差分分析と検証の再利用を目指す |
| 総保有コスト | 継続ライセンス＋移行・保守・運用費 | CE移行・再設計費を含む複数年TCOで損益分岐を提示 |
06 / CORE INNOVATIONS
Synapseが目指す、2つの構造転換。
① 業務構造から考える、EE → CE移行
現行モジュール、DB、業務ルール、利用画面を調べ、Enterprise固有機能の依存を特定。継続・代替・再実装を比較したうえで、Community移行の実現性を判断します。
Enterpriseのコードを無断流用するのではなく、適切なライセンスと独立した実装を前提にします。
② 事前検証と承認を組み込むAI
Odoo 20のMCP/API接続自体は強力です。その上で、予算変更・発注・原価・承認・例外処理など、業務ごとの不変条件を明示し、プレビューと承認を通して更新します。
ナレッジグラフだけで安全を保証するのではなく、権限・検証・状態遷移・監査ログを実行側で組み合わせます。
05 / TOTAL COST OF OWNERSHIP
見るべきなのは、初年度だけではない。
ライセンス削減で浮いた費用より再構築費が高ければ意味がありません。移行費だけでなく、次のバージョンアップ、保守、運用、ホスティングまで含めて比較します。
Enterprise継続モデル
移行費 ＋ EE利用料 ＋ 保守 ＋ インフラ ＋ 次回更新費
ライセンスの継続コストとカスタマイズ保守を含む総額で評価。
Community再設計モデル
CE再構築費 ＋ 保守 ＋ インフラ ＋ Synapse運用費 ＋ 次回更新費
EE利用料をなくせる場合も、CEで代替するための開発・運用費が発生します。試算により比較します。
現行環境を確認
Odoo版・EE機能・モジュール・カスタム画面・利用業務を棚卸し。
再構築案と費用を比較
残す機能・廃止する機能・CE移行可否・AI化対象を具体化。
移行と検証を設計
承認や管理会計まで含めた受入条件を定義し、段階的に実施。
06 / FOR ODOO PARTNERS
導入パートナーの皆様へ。
移行案件を、価値ある再提案へ。
「Odoo 20への移植費用を見積もる」だけでなく、
「この機会に不要な構造を捨て、自然言語ERPへ変えませんか」と提案する。
「この機会に不要な構造を捨て、自然言語ERPへ変えませんか」と提案する。
RAQQAは業務構造の解析、再設計、自動化技術の面から協業を検討します。既存顧客との関係や現場の導入支援を担うパートナーと、役割を分けて案件ごとに進める考え方です。
07 / FREE ASSESSMENT
Odoo移行・TCO削減の
無料相談を受付中。
今のOdooバージョン、利用形態、相談したい課題をお知らせください。
回答内容をもとに、初回の相談方法をご案内します。
メールでのご相談：info@rakka.co.jp