稼働から1年が過ぎたころ、担当者から相談が来ます。「Odooの新しい版が出ました。上げたほうがいいですか」。
聞けば、導入時に作り込んだ画面や帳票が、新しい版でそのまま動くか誰も分からない。導入の検討中には、ほとんど話題にならない場面です。
Odooは原則として年1回、メジャーバージョンが上がります。毎年、新しい機能を受け取れるということです。Odoo.shやオンプレミスでも、Odoo 20に上げれば19.1〜19.4の新機能をまとめて受け取れます（バージョンと機能の更新）。
一方で、サポートの対象は直近の数世代に限られます。毎年やってくる宿題を抱えることになり、その重さを決めるのはOdooではありません。自社がどれだけ作り込んだかです（カスタマイズの量）。
段取りを知ると、たとえば次のことが変わります。
- 作り込みの種類ごとに、毎年の負担を見積もれる
- 検証環境と業務側の確認で、本番を壊さずに上げられる
- 時期・担当・費用を、年間計画に先に入れておける
- ホスティング形態ごとに、新機能を受け取る時期が分かる
公式のアップグレード支援や版ごとの機能更新は、有償のEnterprise版が前提です。無料・オープンソースのCommunity版では、作業も検証も自社で担います。
では、担当者の「上げたほうがいいですか」に、どう答えればよいのか。答えは、毎年の段取りを最初から計画に入れているかどうかで変わります（「上げない」という選択）。良い点と注意点はバージョンアップのメリットとデメリットにまとめました。
Odooのバージョンアップとサポート期間：まず押さえる3つの前提
年1回のメジャーリリース
Odooは、原則として年1回メジャーバージョンをリリースします。バージョン番号が1つ上がる更新です。
これは速いペースです。国産の業務パッケージと比べると、更新の頻度が高い部類に入ります。
サポートされるのは新しい数世代
Odooのサポート対象は、直近の数バージョンに限られます。
古いバージョンを使い続ければ、いずれはサポートの対象外です。セキュリティの修正も受けられなくなるおそれがあります。
標準サポートは、各メジャー版のリリースから3年間です。 対象は直近3つのメジャー版です（出典：Odoo公式ドキュメント「Standard and extended support」、2026年10月確認）。検討するときは、必ずOdoo公式の情報をご確認ください。
アップグレードの支援には条件がある
Odoo公式は、アップグレードに関するサービスを提供しています。ただし、その対象や範囲には契約上の条件があります。 標準アプリと、Studioでの調整（Studioの契約が有効な間）は対象です。保守契約のない自社開発・第三者のモジュールは対象外です（出典：Odoo公式ドキュメント「Upgrade」、2026年10月確認）。
Community版を自社で運用している場合、公式のアップグレード支援は受けられません。
エディションの違いは Odoo Community版とEnterprise版の違い をご覧ください。
Odooのバージョンアップのメリットとデメリット
良い点も注意点も、Community版かEnterprise版か、どれだけ作り込んだかで当てはまり方が変わります。メリットは、次の5つです。
- 毎年新しい機能を受け取れる：原則年1回メジャー版が上がる。Odooオンラインなら、19.1〜19.4のようなマイナー版も順次受け取れる
- Enterprise版は公式のアップグレード支援がある：標準アプリと、Studioでの調整（Studioの契約が有効な間）が対象
- 設定で対応した部分は基本的に引き継がれる：アプリの選択や項目の設定が中心なら、負担は軽い
- Odoo.shなら3つの環境で試せる：開発・ステージング・本番の環境が用意されている
- 毎年少しずつ上げれば軽く済む：時期と担当と一覧を先に用意すれば、判断は「いつ上げるか」になる
デメリットと注意点は、次の4つです。
- サポートの期間に限りがある：標準サポートは各メジャー版のリリースから3年間。対象は直近3つのメジャー版
- 独自開発は毎年の確認が要る：作り直しになることもある。保守契約のない自社開発・第三者のモジュールは、公式のアップグレードの対象外
- Community版は公式の支援がない：作業と検証は、自社または委託先で行う
- 公式のダウングレードはない：公式のアップグレードは、前の版へのダウングレードを対象にしていない。戻す前提で、バックアップと戻す判断の基準を先に決めておく
両方を並べると、次の図のとおりです。
注意点の多くは、段取りで手を打てます。事故を防ぐ手順はバージョンアップの進め方に、時期・担当・費用の決め方は年間計画に組み込んでおくべきことにまとめました。
Odooのバージョンアップの重さを決めるのは、カスタマイズの量
バージョンアップの負担は、Odooの都合では決まりません。自社がどれだけ独自の作り込みをしたかで決まります。
同じ「カスタマイズ」でも、中身によって負担は3段階に分かれます。設定で対応した部分は、基本的に引き継がれるので軽い。Studio（ノーコードの画面・項目の調整ツール）での追加は、動作の確認が要る中程度。独自開発のモジュールやコードの改変は、作り直しになることもあるほど重くなります。
なぜ③が重いのか
Odooの本体が変われば、それにつながっていた独自の部分も影響を受けます。
- 参照していた機能の仕様が変わる
- 画面の構造が変わる
- 前提にしていた項目がなくなる
これを毎年確かめる作業が続きます。 問題が見つかれば、直す作業が発生します。
導入時の判断が、毎年の負担を決める
導入時に「これくらいなら作り込んでもいいだろう」と判断した内容は、その後ずっと自社に返ってきます。
カスタマイズの判断を慎重に行うのは、そのためです。考え方は Odooのカスタマイズはどこまでやるべきか と OdooとFit to Standard にまとめています。AIを前提にした線の引き方は、どこを標準に合わせ、どこを自社流で残すか も参考になります。
自社の宿題は重くなりそうか：会議で使うチェックリスト
次の項目に当てはまる数が多いほど、毎年の確認は重くなります。導入前の方も、稼働中の方も使えるリストです。
- □ 自社開発のモジュールや、外部から入れた第三者モジュールがある
- □ Odoo本体のソースコードに、直接手を入れた箇所がある
- □ 何を・なぜ作り込んだのか、一覧にした資料がない
- □ 作り込みの中身を説明できる人が、社内に1人しかいない
- □ 本番とは別に、試せる検証環境を持っていない
- □ 前回のバージョンアップから、2世代以上離れている
当てはまる項目が多い会社は、まず一覧づくりと体制づくりから始めるのが近道です。
Odooのバージョンアップの進め方
作業は4段階で進めます。影響範囲を洗い出し、検証環境で試し、業務側で触って確かめ、最後に本番へ反映する。どの段階でも、本番にいきなり当てることはしません。
③を飛ばさないでください
技術的な検証だけで済ませて、業務側の確認を省く。いちばん多い失敗が、これです。
技術的に動くことと、業務が回ることは別です。
画面の並びが変わっただけで、現場の作業手順は変わります。帳票の見た目が変われば、取引先から指摘が入ることもあります。
現場の人が実際に触る時間を、必ず計画に入れてください。 本番に反映する前には、バックアップを取り、戻す判断の基準も決めておきます。
検証環境があるかで、安全性が変わる
検証環境とは、本番を壊さずに試すための、本番とは別の環境です。これがあるかどうかで、作業の安全性は大きく変わります。
Odoo.shには、開発・ステージング・本番の3環境が用意されています。詳しくは Odoo.shとは？3つの環境で「壊さずに変える」仕組み をご覧ください。
オンプレミスの場合は、自社で検証環境を用意する必要があります。
バージョンアップを年間計画に組み込んでおくべきこと
バージョンアップは、思い出したときにやる作業ではありません。最初から年間の計画に入れておくものです。
(1) 実施時期を決めておく
繁忙期を避けた時期に、あらかじめ枠を取ってください。決算期や、業界の繁忙期は外します。
(2) 独自部分の一覧を維持する
何を作り込んだのか、なぜ作ったのか。この記録がないと、毎回ゼロから調べることになります。
記録は、作った時点で残してください。半年後の自分は、他人です。
(3) 担当と体制を決めておく
誰が作業し、誰が確かめ、誰が実行の判断をするのか。
担当者が1人しかいなければ、その人が動けない時期には実施できません。 体制の考え方は Odooの運用・保守で押さえるポイント と 一人情シスのためのOdoo運用術 にまとめています。
(4) 費用を見込んでおく
独自開発がある場合、バージョンアップのたびに確認と修正の費用がかかります。
これは「予想外の出費」ではなく、最初から見込んでおくべき運用費用です。総費用の考え方は Odoo導入にかかる費用の構造 をご覧ください。
「上げない」という選択について
バージョンアップを見送り続ける会社は、実際にあります。
短期的には、合理的に見えます。作業も費用も発生しないからです。
しかし、時間が経つほど選択肢が減ります。
- サポートの対象外になり、修正を受けられなくなる
- 一気に複数世代を上げることになり、作業が重くなる
- 新しい機能を使えない
- 対応する技術者を見つけにくくなる
Odooに限った話ではありません。古いシステムを使い続けた会社で、よく起きることです。 経営の側から見た整理は、基幹システムの保守切れリスク が詳しいです。
同じ流れは、脱・大型ERPを検討する中堅企業の進め方 や Odoo導入の失敗パターンと回避策 でも扱っています。
毎年少しずつ上げるほうが、結果的に軽く済みます。 担当者の「上げたほうがいいですか」にも、これで答えられます。上げる前提で、時期と担当と一覧を先に用意しておく。そうすれば、毎年の判断は「上げるか」ではなく「いつ上げるか」になります。
作り込む前に、ベンチャーネットが確かめる4つのこと
バージョンアップの負担は、稼働後の努力より、導入時の設計で大きく変わります。ベンチャーネットが作り込みの範囲を決めるのは、次の順で確かめてからです。
- 3〜5年後の姿から、ホスティング形態を決める
新機能をいち早く使いたいのか、自社で管理したいのか。この優先順位で、Odooオンラインか、Odoo.sh・オンプレミスかが分かれます。 - 要望を①設定・②ノーコード・③独自開発に仕分ける
まず標準機能に業務を合わせられないか（Fit to Standard）を検討します。③に回すのは、「毎年の確認費用を払ってでも必要か」を経営者と確かめたものだけです。 - ③に回したものは、理由と一緒に一覧にする
稼働前の時点で、何を・なぜ作ったかを記録します。これが、毎年の影響範囲の洗い出しの出発点になります。 - 年間計画に「時期・担当・判断者」を先に入れる
繁忙期を外した実施枠と、作業・確認・実行判断の担当を、稼働前に決めておきます。
仕分けの結果、③がどうしても膨らむ会社もあります。その場合は、Odooが合わない可能性も正直にお伝えします。
規模や要件によっては、NetSuiteのほうが無理なく収まることがあります。パッケージに乗らない固有業務が中心なら、AIスクラッチ開発も選択肢です。ただしAIスクラッチ開発は、ライセンスが要らない代わりに、開発費と保守費が別途かかります。
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。どの製品でも、「毎年の宿題の重さ」を比べたうえで選ぶ。この順番は変えません。NetSuite側の更新への備え方は、NetSuiteのバージョンアップ（年2回リリース）への備え方 で比べられます。
バージョンと機能の更新について
Odoo 19.0は、2025年9月にリリースされました。標準サポートの終了は2028年9月（予定）と、公式に記載があります。
その後、19.1（2026年1月）・19.2（2026年3月）・19.3（2026年5月）・19.4（2026年7月）が順に提供されています。
注意したいのは、19.1〜19.4がOdooオンラインで先に提供されたことです。Odoo.shとオンプレミスは対象外でした（公式のサポート表にN/Aと明記）。
2026年9月には、次のメジャー版のOdoo 20が公開されました。Odoo.shやオンプレミスの会社も、Odoo 20に上げれば、19.1〜19.4の新機能をまとめて受け取れます。
違うのは、新機能を受け取る時期です。早く使いたいならOdooオンライン。自社で管理したいならOdoo.shかオンプレミスで、年1回のメジャー版に合わせます。Odoo 20の変更点はOdoo 20の新機能まとめにあります。
19.0からの4つのマイナー版で何が更新されたか
公式リリースノートに記載された更新は、次のとおりです。
| バージョン | 提供時期 | 主な内容（公式リリースノート記載分） |
|---|---|---|
| 19.0 | 2025年9月 | メジャーリリース（標準サポート終了は2028年9月予定） |
| 19.1 | 2026年1月 | 社内向けプッシュ通知（Discuss）、カレンダーの改善（Appointments）、AIへのファイルについての質問 |
| 19.2 | 2026年3月 | 作業指図のカンバン表示（製造）、Field ServiceのPlanningへの統合、外貨換算レートの表示（会計） |
| 19.3 | 2026年5月 | 勘定科目グループを「Parent accounts」に置換（会計）、AIエージェントがレコードを作成・更新できるようになった |
| 19.4 | 2026年7月 | 説明のみの受注明細（販売）、ウェブサイトビルダーの刷新、外部のAIエージェントをMCP（Model Context Protocol、AIモデルが外部のデータやツールとやりとりするための規格）でOdooに接続 |
この一覧は、公式リリースノートに記載がある範囲にとどめています。 各機能の詳しい挙動までは、公式に記載がありません。
なぜ「Odooオンライン専用」が論点になるのか
この4版は、すべてOdooオンラインという1つのホスティング形態にしか届きませんでした。
ホスティング形態を選んだ時点で、新機能を受け取る時期が決まるということです。
| ホスティング形態 | 19.1〜19.4の受け取り | 備考 |
|---|---|---|
| Odooオンライン | 対象 | マイナー版を順次受け取れる |
| Odoo.sh | 対象外（N/A） | 公式のサポート表にN/Aと明記 |
| オンプレミス | 対象外（N/A） | 公式のサポート表にN/Aと明記 |
Odoo.shとオンプレミスを選んだ場合、次のメジャーリリース（20.0）まで、これらの新機能には触れられませんでした。
その20.0は、2026年9月に公開されました（出典：Odoo 20 Release Notes、2026年9月確認）。Odoo.shやオンプレミスの会社は、20.0に上げることで19.1〜19.4の更新をまとめて受け取れます。
新機能を追いたいのか、自社で管理したいのか。 どちらを優先するかが、ホスティング選びの実質的な分かれ目です。形態ごとの違いは Odooの導入形態3つを比較｜Online・Odoo.sh・オンプレミスの選び方【2026年版】 にまとめました。
なお、この更新の流れはEnterprise版に関するものです。Community版は、このバージョン間の機能更新の対象になりません。
※2026年9月時点、Odoo公式のリリースノートおよびドキュメントの記載による
よくある質問
Q1. バージョンアップは必須ですか？
形態によって違います。オンプレミスなら、上げずに使い続けることもできます。Odooオンラインは、決められた期限が来ると上げることが必須です。Odoo.shも、サポート3年の後は2年以内に上げる必要があります（出典：Odoo公式ドキュメント「Upgrade」、2026年10月確認）。また、サポートの対象期間には限りがあります。
対象外になると、不具合やセキュリティの修正を受けられなくなるおそれがあります。対象期間は、必ずOdoo公式でご確認ください。
Q2. 作業にどのくらいかかりますか？
カスタマイズの量で、大きく変わります。
標準機能と設定だけで運用しているなら、比較的軽く済みます。独自開発が多い場合は、確認と修正に相応の時間が必要です。
Q3. Community版でもアップグレードできますか？
できます。ただし、公式のアップグレード支援は受けられません。
作業と検証は、自社または委託先で行います。
Q4. 何年も上げていません。まとめて上げられますか？
構成によっては上げられます。ただし、確かめる範囲が広がります。
離れているほど変更点が多くなり、独自部分への影響も大きくなります。できるなら、毎年上げるほうが安全です。
Q5. 上げたあとで問題が出たら、前のバージョンに戻せますか？
公式のアップグレードは、前の版へのダウングレードを対象にしていません。だからこそ、戻す前提で計画してください。 バックアップを取り、戻す判断の基準を事前に決めておくことをおすすめします。
「戻れない」状態で実行するのは避けるべきです。
Q6. 19.1〜19.4はどのホスティング形態でも使えますか？
いいえ。19.1〜19.4として届くのは、Odooオンラインだけです。 Odoo.shとオンプレミスは、公式のサポート表でN/Aと明記されています。
ただし、2026年9月に公開されたOdoo 20に上げれば、Odoo.shやオンプレミスでもこれらの新機能を受け取れます。違いは、受け取る時期です。
Q7. Odooのバージョンアップのメリットとデメリットは？
毎年新しい機能を受け取れる一方で毎年の宿題になります。
Enterprise版なら、標準アプリとStudioでの調整は公式のアップグレード支援の対象です。一方、標準サポートはリリースから3年間で、独自開発が多いほど毎年の確認と修正が重くなります（メリットとデメリット）。
まとめ
Odooは原則として年1回、メジャーバージョンが上がります。サポートの対象は新しい数世代に限られ、古いまま使い続けると、いずれ修正を受けられなくなります。対象期間は必ず公式でご確認ください。
バージョンアップの重さは、Odooの都合ではなく、自社がどれだけ作り込んだかで決まります。
設定で対応した部分は軽く済みます。ノーコードでの追加は中程度。独自開発は重く、毎年の確認が要ります。導入時のカスタマイズの判断が、その後ずっと自社に返ってきます。
加えて、19.1〜19.4のようなマイナー版は、Odooオンラインにだけ先に届きます。Odoo.shやオンプレミスは、Odoo 20のようなメジャー版で受け取ります。ホスティング形態の選択が、機能更新の受け取り方まで左右します。
進め方の原則は3つです。影響範囲を洗い出す。検証環境で試す。そして、業務側の確認を飛ばさない。 見送り続けるほど選択肢は減るので、毎年少しずつ上げるほうが、結果的に軽く済みます。
1年後、次のメジャー版の公開を知らせる案内が届いても、社内は慌てません。担当者が独自部分の一覧を開き、閑散期に押さえておいた枠で、現場が検証環境の新しい画面を触り始めています。
もう少し詳しく知りたい方へ
「作り込んだ部分が、次の版で動くか分からない」「毎年の段取りをどう組めばいいか」。そうした状況を、そのままお聞かせください。
ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。
導入時から「毎年のバージョンアップをどう回すか」を織り込んだ設計をご提案しています。作り込む前に、その判断が将来どれだけの負担になるかを一緒に見積もることを大切にしています。
あわせて読みたい記事
