Odoo(オドゥー)は、ベルギーのOdoo S.A.が開発するオープンソースのERPです。販売・在庫・会計・CRM・製造などを「アプリ」として必要な分だけ入れて使います。2026年9月に最新メジャー版のOdoo 20が公開され、10月には公式Dockerイメージも20.0に切り替わりました。この記事では、Odooの機能構成、無償のCommunity版と有償のEnterprise版の違い、料金、3つの提供形態、日本の会計への対応状況、ERPNextなど他のオープンソースERPとの違い、カスタムモジュールの書き方を、公式ドキュメントとソースコードで確認した内容に絞って解説します。
まとめ:Odooの要点
- 何者か:ベルギーのOdoo S.A.が開発するERP。公称ユーザー数は2,800万人超。
- 最新版:Odoo 20(2026年9月公開)。メジャー版の標準サポートは3年間で、20.0は2029年9月まで(予定)。17.0は2026年9月で標準サポートを終えた。
- エディション:Community版はLGPLv3で無償。Studio・ヘルプデスク・給与計算・会計レポートなどはEnterprise版だけにある。
- 料金:1アプリだけなら無料。日本から見た公式料金は、全アプリを使うスタンダードが年払いで1ユーザー月28.50米ドル、カスタムが51.90米ドル(最初の12か月は割引あり)。価格は地域で異なる。
- 提供形態:Odoo Onlineではカスタムモジュールを使えない。自社開発のコードを載せるならOdoo.shかオンプレミスを選ぶ。
- 日本対応:画面は日本語で使える。Odoo 19で全銀フォーマット、Odoo 20で中小会計要領とe-Taxの科目コードに合わせた勘定科目表と消費税申告書が入った。一方、給与計算の公式ローカライズ一覧に日本は無い。
- 他のオープンソースERPとの違い:ERPNextには日本向けの地域モジュールが無く、iDempiereは国内企業が日本の商習慣向けの配布版(JPiere)を出している。Odooは本体に日本の会計ローカライズを持つ。
Odooの読み方・提供元・沿革
読みは「オドゥー」です。開発元のOdoo S.A.はベルギーの企業で、創業者はFabien Pinckaers氏です。公式の会社概要では、オンプレミス利用を含めた利用者数を「28,000,000人超」、規模は1ユーザーの新興企業から大企業までとしています。
前身は、Pinckaers氏が2005年に開発を始めたTinyERPです。その後OpenERPに改称し、2014年5月に会社名と製品名をOdooへ変えました。同氏の公式ブログでは、2014年6月の版8でCMS・eコマース・POSを加えたことを挙げ、「ERPの機能に縛られない名前」が必要になったと説明しています。検索で「OpenERP」を見かけたら、同じ製品の古い名前です。
Odooの機能:アプリを足して広げる構成
Odooは1つのデータベースの上に業務別のアプリを載せる構成です。顧客や製品のマスタを全アプリで共有するので、見積・受注・出荷・請求・入金の記録が互いに関連付き、どの段階からでも前後の記録をたどれます。公式サイトのアプリ一覧は次の分野に分かれています。
| 分野 | 主なアプリ |
|---|---|
| 財務 | 会計・請求書・経費・電子署名・スプレッドシート |
| 販売 | CRM・販売・サブスクリプション・POS・レンタル |
| Webサイト | Webサイトビルダー・eコマース・イベント・eラーニング |
| サプライチェーン | 在庫・製造・保守・PLM・品質・購買 |
| 人事 | 従業員・給与・採用・休暇・評価・車両 |
| サービス | プロジェクト・タイムシート・計画・ヘルプデスク |
| 生産性 | AI・ディスカス・ドキュメント・ナレッジ・IoT |
アプリは後から追加できます。まずCRMと販売だけで始め、在庫や会計を後で足す、という段階導入がしやすい作りです。ただし、上の表のアプリがすべて無償版に入っているわけではありません。どこまでが無償かは次の章で整理します。
ERPという製品分類そのものの説明や、基幹システム・CRMとの違いは「ERPとは?基幹システム・CRMとの違いと主な機能・導入の進め方を解説」にまとめています。
Community版とEnterprise版の違い
Odooのソースは2系統あります。GitHubの odoo/odoo で公開されているのがCommunity版で、ライセンスはLGPLv3です。Enterprise版は、Community版の上に有償モジュールを重ねたもので、ライセンスはOdoo Enterprise Edition Licenseです。Odoo Onlineで1アプリだけ無料で使う場合を除き、全アプリを使うにはスタンダードかカスタムの契約が要ります。
Odoo 20.0のCommunity版リポジトリには、販売・CRM・購買・在庫・製造・会計(請求書)・プロジェクト・従業員・Webサイト・eコマース・POSが入っています。一方、次のアプリは同リポジトリに存在せず、Enterprise版でしか使えません。
| Enterprise版だけのアプリ | 困る場面 |
|---|---|
| Studio | 画面や項目をノーコードで変えたい |
| 会計レポート | 貸借対照表・損益計算書を標準で出したい |
| ヘルプデスク | 問い合わせをチケットで管理したい |
| 給与計算 | 給与明細をOdoo内で作りたい |
| ナレッジ・ドキュメント | 社内文書をOdooに集約したい |
| 電子署名・計画・品質・PLM | 契約締結や製造品質までOdooで回したい |
| サブスクリプション・フィールドサービス | 定期課金や訪問作業を扱いたい |
| AI | AIエージェントを業務に組み込みたい |
Community版は「無料のERP」として紹介されがちですが、請求書の発行はできても、貸借対照表や損益計算書を出す会計レポートのモジュール(account_reports)は入っていません。Community版で始める場合は、決算帳票をどこで作るかを最初に決めておくべきです。Community版からEnterprise版への切り替え手順は公式ドキュメントにあり、データベースをバックアップしてから web_enterprise モジュールを入れ、サブスクリプションコードを登録します。
料金プランと見落としやすい費用
日本からアクセスした公式料金ページ(2026年10月24日取得)の表示は次のとおりで、通貨は米ドルです。Odooの料金は地域ごとに設定されており、米国など別の地域から見ると金額が変わります。海外の記事に載っている金額をそのまま予算に使わず、自社の所在地で表示される料金ページを確認してください。同じページから15日間の無料体験を始められます。
| プラン | 年払い(1ユーザー/月) | 月払い(1ユーザー/月) | 主な条件 |
|---|---|---|---|
| シングルアプリ無料 | 0ドル | 0ドル | 1アプリ・ユーザー数無制限・Odoo Online |
| スタンダード | 28.50ドル(割引時22.80ドル) | 36.00ドル(割引時28.80ドル) | 全アプリ・Odoo Online |
| カスタム | 51.90ドル(割引時40.90ドル) | 65.40ドル(割引時51.90ドル) | 全アプリ・Studio・エージェンティックAI・マルチカンパニー・外部API |
| ライトユーザー | – | 8.90ドル | 従業員向けの限定機能のみ |
割引は「最初に契約したユーザー数に対して12か月間有効」と注記されています。2年目以降の予算は割引前の価格で組んでください。カスタムプランはOdoo Onlineに加えてOdoo.shとオンプレミスでも使えます。
プランの境目で注意したいのは次の3点です。
- スタンダードにStudioを入れる、または会社を追加すると、自動でカスタムプランに切り替わる(料金ページのFAQに明記)。
- 有償プランで外部システムからOdooの外部APIを呼ぶにはカスタムプランが必要。Odooから決済・配送・銀行同期などの外部サービスを呼ぶ場合は、スタンダードの範囲です。
- AIエージェントを業務に組み込むならカスタムプラン。料金ページはエージェンティックAIをカスタムプランの項目に挙げ、AIによる仕入先請求書や経費のスキャンなどはプランに含まれないアプリ内課金としています。
ライセンス以外の費用には、公式に価格が公開されているOdoo.shのホスティング費用と、作業範囲に応じて個別見積もりになる導入・開発費用があります。見積もりでは次の5つを分けて確認してください。
- 導入支援:要件定義・業務設計・初期設定(導入パートナーに支払う)
- データ移行:顧客・品目・残高などの移行と検証
- カスタマイズ:Studioの設定作業とカスタムモジュールの開発
- ホスティング:Odoo.shはワーカー数・ストレージ容量(GB)・ステージング環境数などに応じた費用が別途かかる。オンプレミスはサーバーと運用の費用
- 教育・保守:利用者研修と、カスタムコードの保守(料金ページはカスタムコードの保守をプラン外としている)
国内の主要ERPパッケージの価格帯と比べたい場合は「ERPパッケージ製品とは?主要6製品の比較・価格公開状況とSAP保守期限」が参考になります。
Odoo Online・Odoo.sh・オンプレミスの選び方
同じOdooでも、どこで動かすかによって使える機能と運用負担が変わります。
| 項目 | Odoo Online | Odoo.sh | オンプレミス |
|---|---|---|---|
| 運用主体 | Odoo社 | Odoo社(PaaS) | 自社 |
| カスタムモジュール | 不可 | 可 | 可 |
| Apps Storeのモジュール | 不可 | 可 | 可 |
| 中間版(SaaS版) | 利用可 | 対象外 | 対象外 |
| 延長サポート | なし | 一部の版のみ | 全版 |
| 必要なプラン | 無料〜カスタム | カスタム+Odoo.sh費用 | カスタム(Community版は不要) |
判断の分かれ目は自社でコードを書くかどうかです。公式ドキュメントは、Odoo Onlineはカスタムモジュールにも、Odoo Apps Storeのモジュールにも対応しないと明記しています。Studioで済む範囲の変更ならOnlineで足ります。Pythonでモジュールを作る予定があるなら、最初からOdoo.shかオンプレミスを選んでください。途中で移るとホスティングの移行作業が発生します。
Odoo.shはGitHubアカウントでプロジェクトを作り、リポジトリの開発・ステージング・本番のブランチをそれぞれホストする継続的インテグレーション基盤です。サーバーを持たずにカスタムモジュールを運用したい場合の標準的な選択肢になります。
オンプレミスでソースから動かす場合、Odoo 20の要件は Python 3.12以上(3.14まで)・PostgreSQL 16以上です(odoo/release.py の定義値)。Odoo 19はPython 3.10以上・PostgreSQL 13以上だったので、既存サーバーのOSやDBが古いと20へ上げる前に基盤の更新が要ります。
Odoo 20の変更点とサポート期間
Odoo 20は2026年9月にリリースされ、公式のNightlyビルドのページでは推奨版(Odoo 23の登場までサポート)とされています。GitHubの既定ブランチも 20.0 に切り替わりました。Docker公式イメージは公開直後は19.0が最新でしたが、2026年10月には odoo:20.0 が公開され、latest も20.0と同じイメージを指すようになっています。
リリースノートから、導入判断に影響する変更を挙げます。
- AI機能はすべてクレジット制:「All AI features now need credits」とあり、IAP(アプリ内購入)でクレジットを買う必要があります。AIエージェントがレコードを作成・更新したり、自動アクションから呼び出されたりするようになりました。
- MCP接続:データベースにMCP(Model Context Protocol)で接続できるようになり、外部のAIツールからOdooのデータを扱えます。
- 日本の会計ローカライズ強化:詳しくは次の章で扱います。
- 技術面:プッシュ通知がFirebaseからOdoo自社の仕組みへ移り、変更履歴(tracking values)の保存方式が作り直されました。変更履歴を直接読んでいるカスタムモジュールは改修対象になります。アクセス権の定義が
ir.model.accessからir.accessへ移った点の書き換え手順は「Odooカスタマイズの実装手順」で扱っています。 - 外部API:Odoo 20の外部APIのドキュメントはJSON-2 APIを中心に書かれ、従来のXML-RPC・JSON-RPCは非推奨です。データベース操作のdbサービスはOdoo 20で削除され、残りのcommon・objectサービスもOdoo 22(2028年秋)で削除予定とされています。既存の連携プログラムは、20へ上げる前にJSON-2 APIへの書き換えを計画してください。
サポート期間は、メジャー版ごとにリリースから3年間の標準サポート(ヘルプデスク・不具合修正・セキュリティ更新)です。その後は追加料金が必須の延長サポートになり、セキュリティ更新は止まります。延長サポートを受けられるのはオンプレミスと、一部の版に限ったOdoo.shだけで、Odoo Onlineにはありません。Odoo 20.0のドキュメントにあるサポート表(2026年10月24日時点)は次のとおりです。
| 版 | リリース | 標準サポート終了 | 現在の状態 |
|---|---|---|---|
| 20.0 | 2026年9月 | 2029年9月(予定) | 標準サポート |
| 19.0 | 2025年9月 | 2028年9月(予定) | 標準サポート |
| 18.0 | 2024年10月 | 2027年9月(予定) | 標準サポート |
| 17.0 | 2023年11月 | 2026年9月 | 延長サポートのみ(Online不可) |
| 16.0 | 2022年10月 | 2025年9月 | 延長サポートのみ(Online不可) |
17.0で稼働している環境は、すでにセキュリティ更新の対象外です。同じページには「どの版からでも、標準サポート中、または標準サポート終了から6か月未満のメジャー版へアップグレードできる」とあり、17.0からも18.0を経由せず19.0か20.0へ直接上げられます。ただし公式のアップグレードの説明では、カスタムモジュールを含むデータベースは、そのモジュールの移行先版が用意できるまでアップグレードできないとしています。
なお、Odoo Onlineには2〜3か月ごとに「SaaS 19.4」のような中間版が出ます。中間版はOnline専用で、延長サポートの対象外です。
日本語対応と日本の会計・税制への対応
画面は言語設定で日本語に切り替えられます。日本向けのモジュールとして、Community版には l10n_jp(勘定科目表と税の雛形)と l10n_jp_ubl_pint(Peppolの国際標準PINTに基づく日本の電子インボイス形式)の2つがあります。l10n_jp の作者は国内のOdooパートナーであるQuartile Limitedです。
Odoo 20のリリースノートでは、日本の会計について次の3点が追加されました。
- 貸借対照表と損益計算書が「中小企業の会計に関する基本要領(中小会計要領)」に準拠
- 勘定科目表を主要な取引に合わせて更新し、中小会計要領とe-Taxの科目コード体系に対応
- 一般課税と簡易課税の消費税申告書(積上げ・割戻し等の計算方式に対応)を追加
ただし、l10n_jp 自身の説明文には「必要な勘定科目をすべて網羅しているとは限らない。雛形をもとに追加・削除・修正する前提」と書かれています。顧問税理士が使う科目体系とのすり合わせは、導入時の作業として見込んでおくべきです。
銀行まわりでは、Odoo 19で全銀フォーマットによる一括支払と銀行取引明細の取り込みに対応しています。
もう1つの注意点は給与計算です。Odoo 20の公式ドキュメントにある給与計算ローカライズの一覧は24か国・地域で、日本は含まれていません(会計のローカライズ一覧には日本がある)。社会保険料や年末調整を含む日本の給与計算は、国内の給与ソフトで行い、結果の仕訳だけをOdooに取り込む分担が現実的です。
他のオープンソースERP・商用ERPとの比較
ERPNext・iDempiere・Dolibarr・Apache OFBizとの違い
「オープンソースのERP」で比較されることが多い製品を、各プロジェクトのGitHubリポジトリで確認した内容で並べます(2026年10月24日時点)。
| 製品 | ライセンス | 主な言語 | 最新の版 | 日本向けの対応 |
|---|---|---|---|---|
| Odoo | LGPLv3(Community版) | Python | 20.0 | 本体にl10n_jp(科目・消費税) |
| ERPNext | GPLv3 | Python(Frappe) | v16.52.1 | 地域モジュールに日本なし |
| iDempiere | GPLv2 | Java | 13系 | 国内企業の配布版JPiere |
| Dolibarr | GPLv3 | PHP | 24.0.2 | 日本語の翻訳ファイルあり |
| Apache OFBiz | Apache 2.0 | Java | 24.09.08 | – |
違いが最も出るのは日本の会計への対応です。ERPNextの地域別モジュール(erpnext/regional)はオーストラリア・イタリア・南アフリカ・トルコ・UAE・米国の6つで、日本はありません。iDempiereには、国内のOSS ERP SolutionsがJPiereという「iDempiereを日本の商習慣に対応させたディストリビューション」を公開しています。Odooは開発元が日本向けの会計機能を本体で提供しています。選定時は、必要な帳票への対応範囲、制度変更時の更新方針、問い合わせ先を比較してください。
ライセンスの違いは、カスタマイズしたコードを配布するときに効きます。GPLのERPNextやiDempiereを改変して他社へ配布する場合は、適用されるGPLに従い、配布先が改変を含む対応ソースコードを入手できるようにする必要があります。不特定多数への一般公開が一律に必要なわけではありません。OdooのCommunity版はLGPLv3で、Odoo社自身もこの上に独自ライセンスのEnterprise版を載せています。社内で使うだけならどれも公開義務は生じないので、受託開発で作ったモジュールを他社へ再販する予定があるかどうかで確認してください。
技術の選び方では、社内やパートナーの開発者の言語が決め手になります。PythonならOdooかERPNext、JavaならiDempiereかOFBiz、PHPならDolibarrです。Odooはこの中でGitHubのスター数が約5.5万と最も多く、モジュールや情報を探しやすい点も選定材料になります。
NetSuite・SAP Business Oneなど商用ERPとの分かれ目
OdooとNetSuiteやSAP Business Oneのような商用ERPを比べるときの軸は、ソースコードを自社側で持ちたいかと料金を公開価格で積み上げたいかの2つです。Odooは料金ページで1ユーザー単価を公開し、Community版ならソースを改修できます。一方、国内の導入実績や日本の給与・帳票への対応、パートナーの数を重く見るなら商用ERPが候補に残ります。
各製品の詳細は「NetSuiteとは?機能・料金構造とIPO準備企業に選ばれる理由を解説」「SAP Business Oneとは?機能・ライセンス・S/4HANAとの違いとアドオン開発の範囲」で、クラウドERP全体の比較は「クラウドERPとは?オンプレミスとの違い・種類・費用比較と選び方を解説」で扱っています。
Odooのカスタマイズ3段階:設定・Studio・カスタムモジュール
変更の重さで3つの方法を使い分けます。軽いものから検討し、必要な場合だけ次の段階へ進むのが保守費用を抑えるコツです。
| 方法 | できること | 必要な条件 |
|---|---|---|
| 設定 | ワークフロー・承認・帳票ロゴなどの切り替え | 全プラン |
| Studio | 項目追加・画面レイアウト・自動アクション・帳票編集 | カスタムプラン(Studio単独なら無料プラン) |
| カスタムモジュール | 新しいモデル・業務ロジック・外部連携 | Odoo.shかオンプレミス |
カスタムモジュールは、既存のコードを書き換えずに「継承」で差分だけを足すのが原則です。継承の学習例として、販売オーダーに「顧客注文番号」の項目を追加するモジュールを示します。Odoo 20には標準の顧客参照項目 client_order_ref があるため、実務では既存項目で要件を満たせるかを先に確認してください。構成は次の5ファイルです。
sale_customer_po/
├── __init__.py
├── __manifest__.py
├── models/
│ ├── __init__.py
│ └── sale_order.py
└── views/
└── sale_order_views.xml
__manifest__.py で依存先と読み込むファイルを宣言します。author を省くと、読み込みのたびにログへ警告が出ます。
{
"name": "Sale Customer PO Number",
"version": "1.0.0",
"depends": ["sale"],
"data": ["views/sale_order_views.xml"],
"author": "Example Inc.",
"license": "LGPL-3",
}
__init__.py は from . import models、models/__init__.py は from . import sale_order の1行ずつです。モデルは _inherit で既存の sale.order に項目を足します。
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = "sale.order"
customer_po_ref = fields.Char(string="顧客注文番号", copy=False)
画面は、販売オーダーのフォーム(sale.view_order_form)を継承し、顧客欄の直後に項目を差し込みます。
<odoo>
<record id="view_order_form_customer_po" model="ir.ui.view">
<field name="name">sale.order.form.customer.po</field>
<field name="model">sale.order</field>
<field name="inherit_id" ref="sale.view_order_form"/>
<field name="arch" type="xml">
<field name="partner_id" position="after">
<field name="customer_po_ref"/>
</field>
</field>
</record>
</odoo>
Odoo 20.0のソースでは、このフォームの中に partner_id が1か所だけあるため、差し込み位置は一意に決まります。
見落としやすいのが version の書き方です。Odooはマニフェストの版を検査し、系列が合わないモジュールを警告付きで「インストール不可」にします。1.0.0 と書けば実行中の系列が自動で前に付き、Odoo 20では 20.0.1.0.0 として登録されます。一方、20.0.1.0.0 と書いたモジュールは19.0では読み込まれません。複数の版で検証するなら系列を付けずに書くのが無難です。ただし版番号の検査を通ることと、コードがその版で動くことは別なので、インストール・画面表示・保存は版ごとに確かめてください。
手元で試すなら、公式Dockerイメージにモジュールのフォルダをマウントします。イメージは /mnt/extra-addons を追加モジュールの置き場として用意しています。次の内容を compose.yaml として保存し、同じ場所に addons フォルダを作って、その中に上の sale_customer_po フォルダを置きます。Odoo 20はPostgreSQL 16以上が必要なので、DBのイメージも16にします。
services:
db:
image: postgres:16
environment:
POSTGRES_USER: odoo
POSTGRES_PASSWORD: odoo
POSTGRES_DB: postgres
web:
image: odoo:20.0
depends_on:
- db
ports:
- "8069:8069"
environment:
HOST: db
USER: odoo
PASSWORD: odoo
volumes:
- ./addons:/mnt/extra-addons
docker compose up -d の後、コマンドラインでデータベースの作成とモジュールのインストールまで済ませられます。
docker compose run --rm web odoo -d odoo_test -i sale_customer_po --stop-after-init
イメージの起動スクリプトが接続先DBの引数(HOST・USER・PASSWORD の値)を自動で足すので、odoo の後にはデータベース名とモジュール名だけを書けば動きます。この構成は2026年10月24日に公式イメージ odoo:20.0(20.0-20261015)でインストールまで通り、販売オーダーに保存した顧客注文番号が複製時には引き継がれない(copy=False)こと、フォームの顧客欄の直後に項目が出ることを確認しています。画面から入れる場合は http://localhost:8069 でデータベースを作り、開発者モードを有効にしてアプリ一覧を更新し、「アプリ」フィルターを外してから「Sale Customer PO Number」を検索します。
カスタムモジュールはメジャー版を上げるたびに互換性を検証し、移行先の仕様変更に影響される部分を改修する必要があります。上に書いたOdoo 20の変更履歴の作り直しのように、コアの内部仕様は版ごとに変わります。標準サポートが3年なので、サポート内の版に留まるには少なくとも3年に1度の移行が必要です。移行費用はカスタムモジュールの量と、触っているコア機能が次の版でどれだけ変わったかで決まるため、作り込みは最小限に抑えるほど後が楽になります。
継承によるモデル・ビューの拡張、アクセス権の定義、テストと移行スクリプトまでの実装手順は「Odooカスタマイズの実装手順:継承モジュールの書き方とOdoo 20への追従」でコード付きで解説しています。
導入事例と評判の調べ方
Odoo社は公式サイトに顧客事例(References)のページを持っており、国や業種で絞り込めます。国を「日本」にすると国内企業の事例だけが並びます。業種の近い事例が見つからない場合は、公式サイトのパートナー検索で国を「日本」にし、各パートナーが公開している導入事例を当たってください。国内の利用者の声は、ITreviewのOdoo製品ページのような法人向けレビューサイトでも読めます。
評判を読むときは、どのエディション・どの提供形態・どの版での評価かを確認してください。「無料で使える」という評価なら、Community版の自社運用とOnlineのシングルアプリ無料プランのどちらの話かを確かめます。「カスタマイズしにくい」という評価なら、Onlineのカスタムモジュール制限を指すのか、開発・保守の負担を指すのかを確かめます。同じOdooでも前提が違えば結論は逆になります。
ERPの導入が失敗する典型的な原因は製品を問いません。判例や開示資料で確認できる失敗例は「ERP導入の失敗事例と原因|判例・開示資料で確認できる4件と回避策」で扱っています。
開発会社の視点:Odooが向く会社・向かない条件と依頼先の見極め方
Odooが向く会社の条件
- 販売・在庫・会計・CRMを別々のツールで回していて、1つのデータベースに寄せたい中小〜中堅企業:アプリ間でマスタと伝票がつながるのがOdooの本領です。
- 小さく始めて広げたい:1アプリなら無料で始められ、全アプリの料金は定額なので、使うアプリを増やしてもユーザー単価は変わりません。
- 海外拠点と同じシステムを使いたい:会計ローカライズが国ごとに用意され、複数社の管理はカスタムプランで扱えます。
- 標準機能に業務を合わせる方針を取れる:設定とStudioで収まる範囲が広いほど、版上げの負担が小さくなります。
Odooを選ぶべきでない条件
- 日本の給与計算・年末調整までERP内で完結させたい:公式の給与ローカライズ一覧には日本が無いため、日本向けの給与計算・年末調整まで標準機能で完結することを前提にはできません。
- 社内にもパートナーにも保守要員がいないのに、作り込みが多い:3年ごとの版上げのたびにカスタムモジュールの互換性の検証と改修が発生し、止まった時点でサポート切れの版に取り残されます。
- Odoo Onlineの料金で、コード開発が必要な要件を満たしたい:Onlineはカスタムモジュール不可です。この前提で見積もると、後からOdoo.shの費用とホスティング移行が追加になります。
- 日本固有の帳票様式を大量に求める:請求書や納品書の様式をすべて国内の慣習どおりに作るなら、QWebテンプレートの作り込みが帳票の数だけ必要です。
開発会社に提案段階で聞くべき4つの質問
- Studioで済ませる範囲とカスタムモジュールにする範囲を、どういう基準で分けるか
- カスタムモジュールのソースコードの著作権と、リポジトリの所有者はどちらになるか
- 次のメジャー版への移行を、過去にどの版からどの版で経験しているか
- Odoo.shとオンプレミスのどちらを勧めるか、その理由は何か
この4点に具体的な答えが返ってこない会社は、導入後の版上げで行き詰まる可能性があります。既存の会計ソフトや販売管理システムとOdooをつなぐ場合の方式選定は「ERP連携とは?連携先別の設計とAPI上限から決める方式選定・失敗条件」で詳しく扱っています。弊社でもOdooの業務分析からカスタマイズ開発、他システム連携、保守までを「Odoo導入支援サービス」として提供しています。
よくある質問
Odooはどこの国の会社が作っていますか?
ベルギーのOdoo S.A.が開発しています。日本語で相談できる導入パートナーは、公式サイトのパートナー検索で国を「日本」にすると一覧できます。
Odooは無料で使えますか?ライセンス料はいくらですか?
無料で使う方法は2つあり、Community版を自社サーバーで動かす方法と、Odoo Onlineのシングルアプリ無料プランで1つのアプリをユーザー数無制限で使う方法です。無料プランで選ぶアプリはEnterprise版のものでもよく、公式FAQではStudioも選べるとしています。選択したアプリに必要な依存アプリは無料に含まれますが、それ以外のアプリを追加すると有料プランへの切り替えになり、日本から見た料金はスタンダードが年払いで1ユーザー月28.50米ドル、カスタムが51.90米ドルです。
Odooの読み方は?
「オドゥー」と読みます。旧称はOpenERPで、2014年に現在の名前になりました。
Odooの競合になるオープンソースERPは何ですか?
よく比べられるのはERPNext(GPLv3・Python)、iDempiere(GPLv2・Java)、Dolibarr(GPLv3・PHP)、Apache OFBiz(Apache 2.0・Java)です。日本の会計への対応では、本体に勘定科目表と消費税申告書を持つOdooと、国内企業の配布版JPiereがあるiDempiereが候補になります。
Odoo 19からOdoo 20へはすぐ上げるべきですか?
急ぐ必要はありません。19.0の標準サポートは2028年9月まで(予定)続きます。先に対応が要るのは17.0の環境で、2026年9月に標準サポートが終わり、セキュリティ更新が止まっています。20へ上げる場合は、Python 3.12以上・PostgreSQL 16以上への基盤更新と、カスタムモジュールの改修を見込んでください。