Odoo.shとは?3つの環境で「壊さずに変える」仕組みと費用・メリット

「受注画面に項目を1つ足したいだけなのに、担当者が『触ると止まるかもしれない』と渋る」。

システムを入れて数年たつと、こうした場面がよく起こります。変えたいのに変えられない。

Odoo.shは、この「変えられない」を仕組みで解くためのサービスです。本番を止めずに試し、確かめたものだけを反映できます。

Odoo.shとは、Odoo社が提供する PaaS(Platform as a Service:アプリを動かす基盤を提供するサービス)です。中身は、開発・ステージング・本番の3つの環境です。

GitHub連携で「誰が、いつ、何を変えたか」が残り、問題が起きたときは前の状態に戻せます(GitHub連携という考え方)。

Odoo.shを使うと、たとえば次のことが変わります。

  • 開発者は、本番データに触れずに修正を試せる
  • 業務担当が、本番データの複製で受入テストをしてから反映できる
  • カスタムモジュールで、標準機能では回らない業務を補える

ただし、どの会社にも合うわけではありません。費用はカスタムプランが前提で、ホスティング費用は別枠です。力を出すかどうかは、社内外に開発の体制があるかで分かれます。

なお、Odoo.shは有償のEnterprise版のカスタムプランで選ぶホスティングです。無料・オープンソースのCommunity版は、ホスティングと保守を自社で担う前提の版です。

では、自社にその体制はあるか。見分け方は自社に当てはまるかのチェックリストに、良い点と注意点はOdoo.shのメリットとデメリットにまとめました。導入形態全体の比較は Odooの導入形態3つを比較 をご覧ください。

目次

Odoo.shはなぜ環境を分けるのか

Odoo.shはよく「Odoo Onlineとオンプレミスの中間」と説明されます。間違いではありません。けれど、それだけでは本質を外します。

Odoo.shの本体価値は、開発・ステージング・本番という環境が3つあることです。

環境が1つしかない会社では、変更のたびに何が起きるか。3つに分かれた会社と並べると、違いがはっきりします。

環境が1つの場合と3つある場合の違い 環境が1つだと本番で直接変更するため、失敗すると業務が止まり、誰も変更したがらなくなる。環境が3つあれば、開発環境で試し、ステージング環境で本番データの複製を使って検証し、検証済みのものだけを本番に反映するため、業務を止めずに変えられる。 環境が1つか、3つか 環境が1つの場合 本番環境で直接変更 試すこと=業務を触ること 失敗すると業務が止まる 結果、誰も変更したがらなくなる 環境が3つある場合 ① 開発環境 自由に試す。壊してもよい ② ステージング環境 本番データの複製で検証 ③ 本番環境 検証済みのものだけを反映 業務を止めずに変えられる
環境が1つの場合と3つある場合の違い

環境が1つのときの本当の問題

環境が1つだと、変更のたびに業務が止まるリスクを負います。本番で直接試すしかないからです。

すると、誰も変更したがらなくなります。 「触ると危ないから、今のままでいい」。この状態が続くと、システムは業務から少しずつずれていきます。改善が止まるのです。

環境が3つあれば、開発で試し、ステージングで確かめ、検証済みのものだけを本番に移せます。3つの環境を持つことは、変更し続けられる状態を保つための投資です。

Odoo.shの3つの環境

Odoo.shには、開発・ステージング・本番の環境があります。役割ごとにアクセス権を分けることもできます(出典:Odoo公式ドキュメント、2026年10月確認)。

環境役割誰が使うか
開発(Development)コードの修正を試す場所開発者
ステージング(Staging)本番データの複製で受入テストテスター・業務担当
本番(Production)実際の業務が動く場所全ユーザー

権限も分かれています

Odoo公式によれば、役割ごとに次のような制限があるとされています。

  • テスター:ステージングと開発の環境にアクセスできる。Odoo.shのツールから本番データベースにはアクセスできない
  • 開発者:開発環境のみにアクセスできる。本番とステージングにはアクセスできない

開発者が本番データを直接触れない構造です。内部統制の面でも効きます。 監査や社内規程の説明がしやすくなります。

ステージング環境は追加できる

追加のステージングブランチを使えば、複数の機能を同時に開発・テストできる、というのがOdoo公式の案内です。

ただし、追加は購入の手続きを経てサブスクリプションに反映されるとも記載されています。増やせば、その分が費用の構造に反映されます。

Odoo.shのGitHub連携という考え方

Odoo.shのもうひとつの特徴が、GitHub との連携です。GitHubは、プログラムの変更履歴を管理するサービスです。

GitHubのブランチ(コードの置き場所の枝分かれ)が、Odoo.shの開発・ステージング・本番の環境にそれぞれ対応します。

GitHubのブランチとOdoo.shの環境の対応 GitHubのリポジトリにある開発用・ステージング用・本番用のブランチが、Odoo.shの開発環境・ステージング環境・本番環境にそれぞれ対応する。テストの結果としてビルドの状態が記録され、誰が、いつ、何を変えたかが残る。 コードの置き場所と環境が対応する GitHubのリポジトリ Odoo.shの環境 開発用ブランチ 開発環境 ステージング用ブランチ ステージング環境 本番用ブランチ 本番環境 テストの結果 ビルドの状態が記録として残る 誰が、いつ、何を変えたかが 記録として残る
GitHubのブランチとOdoo.shの環境の対応

コードの変更履歴が残るため、「誰が、いつ、何を変えたか」が追えます。

問題が起きたときは、前の状態に戻せます。口頭で「元に戻して」と頼み、担当者の記憶に頼る世界とは別物です。

Odoo公式は、ステージングと本番のビルド状態がテストのステータスとして記録されるとも案内しています。

Odoo.shの費用の構造

金額は、Odoo公式の料金ページで最新をご確認ください。見積もりを読み違えないために、構造として押さえておきたい点は3つです。

(1) Customプランが前提です

Odoo公式によれば、Odoo.shでのホスティングは カスタムプランで選べる選択肢として案内されています。

つまり、スタンダードプランではOdoo.shを使えません。 上位のプラン契約が前提になります。

プランの構造は Odooの料金体系を解説 をご覧ください。

(2) ホスティング費用は別枠です

見落とされやすいのが、この点です。

Odoo公式の料金ページには、Odoo.shのホスティングコストは(プランの料金に)含まれていないという趣旨の注記があります。一方、Odooオンラインでのホスティングは追加費用なしとされています。

Odoo.shを選ぶと、ユーザー単位の料金に加えて基盤の費用が発生します。

(3) 使う量で変わる構造

Odoo.shは基盤サービスです。処理能力や保存容量といった使用量に応じた構造を持ちます。追加のステージング環境も同様です。

本番データベースが契約の容量を超えると、プランは自動で調整されます。公式ドキュメントにも、そう書かれています(出典:Odoo公式ドキュメント「Settings」、2026年10月確認)。見積もりの段階で、この部分を含めて総額を確認してください。導入支援や開発の費用も、これとは別にかかります。

総費用の考え方は Odoo導入にかかる費用の構造 にまとめています。

【正直に】Odoo.shには開発の体制が要ります

Odoo.shは、開発を行う体制があってはじめて価値が出ます。

3つの環境も、GitHub連携も、コードを書く人がいることを前提にした仕組みです。書く人がいなければ、分かれた環境は使われないまま費用だけが残ります。

自社に当てはまるかのチェックリスト

経営会議で、次の5項目を確かめてみてください。当てはまるものが3つに届かないなら、Odoo.shはまだ早い可能性があります。

  • □ 標準機能と設定だけでは回らない業務が、具体的に挙がっている
  • □ カスタムモジュールを開発・保守できる技術者がいる(社内または外部の契約先)
  • □ 変更を本番に反映してよいかを判断する人が、業務側に決まっている
  • □ 年1回のバージョンアップのたびに、独自部分を確認する時間と予算を見込める
  • □ 変更のたびにステージングで受入テストをする業務担当を出せる

社内に技術者がいない会社が、手軽さを求めてOdoo.shを選ぶと、持て余します。

その場合は Odoo Onlineとは? を検討してください。

カスタマイズは増やすほど重くなる

3つの環境があるからといって、カスタマイズを自由に増やしてよいわけではありません。

独自に作り込んだ部分は、バージョンアップのたびに確認が必要です。増えるほど、その作業が重くなります。どこを標準に合わせ、どこを作り込むかの線引きは、AIで変わった、ERP実装の線の引き方が参考になります。

考え方は Odooのカスタマイズはどこまでやるべきか と Odooのバージョンアップとサポート期間 にまとめています。

Odoo.shのメリットとデメリット

Odoo.shは、有償のEnterprise版のカスタムプランで選ぶホスティングです。良い点も注意点も、その前提の上にあります。メリットは、次の5つです。

  • 本番を止めずに変えられる:開発で試し、ステージングで確かめ、検証済みのものだけを本番に移す
  • 本番データの複製で受入テストができる:業務担当が、ステージング環境で反映前に試せる
  • 権限を役割ごとに分けられる:開発者は本番データを直接触れない。監査や社内規程の説明がしやすい
  • 変更履歴が残り前に戻せる:GitHub連携で、誰が、いつ、何を変えたかを追える
  • カスタムモジュールを入れられる:Odoo Onlineでは入れられない独自の機能を足せる

デメリットと注意点は、次の4つです。

  • 開発の体制が要る:コードを書く人がいなければ、環境は使われないまま費用だけが残る
  • カスタムプランが前提でホスティング費用は別枠:処理能力や保存容量といった使用量に応じた構造を持つ
  • 19.1〜19.4の機能更新は届かない:新機能は、Odoo 20に上げたときにまとめて受け取る
  • 作り込むほど更新が重くなる:バージョンアップのたびに、独自部分の確認が要る

両方を並べると、次の図のとおりです。

Odoo.shのメリットとデメリット 良い点は、本番を止めずに変えられる、本番データの複製で受入テストができる、権限を役割ごとに分けられる、変更の履歴が残り前に戻せる、カスタムモジュールを入れられること。注意点は、開発の体制が要る、カスタムプランが前提でホスティング費用は別枠、19.1〜19.4の機能更新は届かない、作り込むほど更新が重くなること。 Odoo.shのメリットとデメリット 良い点 本番を止めずに変えられる 開発・ステージング・本番の3つの環境 本番データの複製で受入テスト 業務担当が反映前に確かめられる 権限を役割ごとに分けられる 開発者は本番データを直接触れない 変更履歴が残り、前に戻せる 誰が、いつ、何を変えたかを追える カスタムモジュールを入れられる Odoo Onlineでは入れられない 注意点 開発の体制が要る 書く人がいないと費用だけが残る カスタムプランが前提 ホスティング費用は別枠・使用量で変わる 19.1〜19.4の機能更新は届かない Odoo 20に上げてまとめて受け取る 作り込むほど更新が重くなる 版を上げるたびに独自部分を確認する
Odoo.shのメリットとデメリット

注意点の多くは、選ぶ前に知っておけば避けられます。費用はOdoo.shの費用の構造で、選ぶ順番はOdoo.shを選ぶ前の順番で説明しています。

Odoo.shを選ぶ前に、ベンチャーネットが確かめる順番

ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。だから「Odoo.shありき」では話を始めません。次の順番で確かめます。

  1. 標準で回るかを先に試す:Fit to Standard(標準機能に業務を合わせる考え方)で、主要業務を標準機能に当てはめます。作り込みが要る箇所を、この段階で洗い出します
  2. 作り込みの理由を経営の言葉で確かめる:「他社との違いを生む業務か」「慣れの問題か」を分けます。慣れの問題なら、業務のほうを変える提案をします
  3. 3〜5年後から逆算する:拠点や事業が増える予定、外部システムとの連携の計画を聞きます。外部APIを使う連携はカスタムプランでのみ使えるため、ここで要否が変わります
  4. 体制と更新の速さを天秤にかける:自社に当てはまるかのチェックリストで体制を見ます。あわせて、バージョンと機能の更新で触れる新機能の受け取り時期の違いを許容できるかを確かめます
  5. 合わないなら、合わないと伝える:結果によっては、Odoo.shを勧めない判断もお伝えします

判断の目安は次の表のとおりです。

状況検討したい選択肢
標準機能と設定で足りる。社内に技術者がいないOdoo Onlineとは? を参照
カスタム開発が必要で、開発体制があるOdoo.sh が現実的な選択肢
データを自社内に置く方針があるOdooをオンプレミスで運用する を参照
作り込みが大半を占め、Odooの標準をほとんど使わないAIスクラッチ開発という選択肢

表の最後の行は、誤解されやすいところです。Odooをほとんどカスタマイズで覆ってしまうなら、パッケージを選ぶ意味が薄れます。

その場合、必要な機能だけを自社資産として作るほうが扱いやすいことがあります。ただしライセンス費用がかからない代わりに、開発費と保守費が別途かかります。判断材料は パッケージERPかスクラッチ開発か に書きました。「作れる」提案を受けたときの見方は、AIでスクラッチ開発とERP、どちらを選ぶべきかにまとめています。

Odoo.shとバージョン・機能の更新

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と明記されています。

Odoo.shを選ぶと、新機能を受け取る時期が変わる。ホスティング形態の選び方が、そのまま更新の速さを決めます。

形態19.1〜19.4
Odooオンライン提供される
Odoo.sh対象外(N/A)
オンプレミス対象外(N/A)

Odoo.shはカスタムモジュールを入れられる代わりに、こまめな機能更新の流れからは外れます。カスタマイズの自由と、更新の速さは両立しません。 ここはトレードオフとして受け止めてください。

19.1〜19.4には、AIエージェントのMCP接続やウェブサイトビルダーの刷新などが含まれます。

2026年9月には、次のメジャー版のOdoo 20が公開されました。Odoo.shでも、Odoo 20に上げれば、これらの新機能をまとめて受け取れます。変更点はOdoo 20の新機能まとめにあります。

なお、この節はEnterprise版の話です。Community版はこの更新の流れに乗りません。

(出典:Odoo公式のリリースノートおよびドキュメント、2026年9月確認)

Odoo.shについてよくある質問

Q1. Odoo Onlineとの違いを一言で言うと?

カスタムモジュールを入れられるかどうかです。

Odoo Onlineでは入れられません。Odoo.shでは入れられます。その代わり、開発と保守の体制が必要になります。

Q2. オンプレミスとの違いは?

サーバの面倒を誰が見るかです。Odoo.shではOdoo側の基盤の上で動きます。オンプレミスでは自社が用意します。

詳しくは Odooをオンプレミスで運用する をご覧ください。

Q3. 開発者がいなくても使えますか?

技術的には使えますが、価値の大部分を活かせません。

3つの環境もGitHub連携も、開発を前提とした仕組みです。設定だけで足りるなら、Odoo Onlineのほうが合っています。

Q4. 費用はどのくらいですか?

カスタムプランの契約に、Odoo.shのホスティング費用が別途加わる構造です。

金額は、Odoo公式の料金ページでご確認ください。導入支援や開発の費用も別に必要です。

Q5. あとからOdoo Onlineに移れますか?

カスタムモジュールを使っている場合、そのままでは移れません。独自部分をどうするかを決める必要があります。

移行できるかは構成によって変わります。事前に確認してください。

Q6. Odoo.shのメリットとデメリットは?

本番を止めずに変えられる一方で開発の体制と別枠の費用が要ります。

開発・ステージング・本番の3つの環境で、試してから反映できます。変更の履歴も残ります。一方、カスタムプランが前提で、Odoo.shのホスティング費用は別にかかります。Odoo 19のままでは、19.1〜19.4の機能更新も届きません(メリットとデメリット)。

まとめ:Odoo.shは開発体制のある会社の選択肢

Odoo.shを「Onlineとオンプレミスの中間」と理解すると、本質を外します。

本体価値は、開発・ステージング・本番という3つの環境が分かれていることです。 変えても業務を止めない仕組みがあるから、システムを業務に合わせ続けられます。GitHub連携で、誰がいつ何を変えたかも残ります。

費用は、カスタムプランが前提で、Odoo.shのホスティング費用は別枠です。金額は必ず公式の料金ページで確認してください。

そして、Odoo.shは開発体制があってはじめて価値が出ます。 技術者がおらず、標準機能と設定で足りるなら、Odoo Onlineのほうが合っています。

1年後、現場から「この項目を足してほしい」と頼まれた翌週には、ステージングで試した画面を担当者が確かめている。「触ると止まる」という言葉が、社内の会話から消えている。Odoo.shが合う会社なら、そんな変化が起きています。

もう少し詳しく知りたい方へ

ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。

「Odoo.shが必要な要件なのか、Onlineで足りるのか」の切り分けからご相談を承っています。作り込みたい業務の一覧があれば、それを見ながらお話しするのがいちばんの近道です。

あわせて読みたい記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

持田 卓臣(もちだ たくおみ)
株式会社ベンチャーネット 代表取締役

ヒューレット・パッカード社でITコンサルタントとして従事した後、2005年に株式会社ベンチャーネットを設立。
Oracle NetSuite Solution Provider Partner として、中堅・中小企業向けクラウドERP「NetSuite」の導入・運用支援を提供しています。
SEO・広告・SNS・ウェブ・MA・SFAと一気通貫で培ってきたデジタルマーケティング領域の業務知見を活かし、NetSuiteを軸とした経営DXを支援しています。
著書:『普通のサラリーマンでもすごいチームと始められる レバレッジ起業「バーチャル社員」があなたを救う』(KADOKAWA、2020年)

目次