Odoo.sh は、Odoo社が提供する PaaS（Platform as a Service：アプリを動かす基盤を提供するサービス）です。
よく「Odoo Onlineとオンプレミスの中間」と説明されます。間違いではありませんが、その説明では本質が伝わりません。
Odoo.shの本体価値は、環境が3つあることです。
開発、ステージング、本番。この3つが分かれていることに、どんな意味があるのか。この記事ではそこを説明します。
導入形態全体の比較は Odooの導入形態3つを比較 をご覧ください。
なぜ環境を分けるのか
まず、環境が1つしかない場合に何が起きるかを見てください。
左の状態の本当の問題
環境が1つだと、変更のたびに業務が止まるリスクを負います。
すると、どうなるか。誰も変更したがらなくなります。
「触ると危ないから、今のままでいい」。この状態が続くと、システムは業務に合わなくなっていきます。改善が止まるのです。
3つの環境を持つことは、変更し続けられる状態を保つための投資です。
Odoo.shの3つの環境
Odoo公式のドキュメントによれば、Odoo.shには開発・ステージング・本番の環境があるとされています。役割ごとにアクセス権を分けることもできると案内されています（2026年8月確認）。
| 環境 | 役割 | 誰が使うか |
|---|---|---|
| 開発（Development） | コードの修正を試す場所 | 開発者 |
| ステージング（Staging） | 本番データの複製で受入テスト | テスター・業務担当 |
| 本番（Production） | 実際の業務が動く場所 | 全ユーザー |
権限も分かれています
Odoo公式によれば、役割ごとに次のような制限があるとされています。
- テスター：ステージングと開発の環境にアクセスできる。本番データベースにはアクセスできない
- 開発者：開発環境のみにアクセスできる。本番とステージングにはアクセスできない
これは内部統制の観点でも重要です。 開発者が本番データを直接触れない構造になっています。
ステージング環境は追加できる
Odoo公式は、追加のステージングブランチによって、複数の機能を同時に開発・テストできると案内しています。
ただし、追加するとサブスクリプションに同期されるとも記載されています。つまり、増やせば費用の構造に反映されます。
GitHub連携という考え方
Odoo.shのもうひとつの特徴が、GitHub との連携です。
コードの変更履歴が残るため、「誰が、いつ、何を変えたか」が追えます。
そして問題が起きたとき、前の状態に戻せます。これは口頭で「元に戻して」と頼む世界とは、まったく違います。
Odoo公式は、ステージングと本番のビルド状態がテストのステータスとして記録されるとも案内しています。
費用の構造
Odooの価格表記ルールに従い、具体的な金額はここには書きません。 必ずOdoo公式の料金ページで最新をご確認ください。
そのうえで、構造としてお伝えできることがあります。
(1) Customプランが前提です
Odoo公式によれば、Odoo.shでのホスティングは カスタムプランで選べる選択肢として案内されています。
つまり、スタンダードプランではOdoo.shを使えません。 上位のプラン契約が前提になります。
プランの構造は Odooの料金体系を解説 をご覧ください。
(2) ホスティング費用は別枠です
ここは見落とされやすい点です。
Odoo公式の料金ページには、Odoo.shのホスティングコストは（プランの料金に）含まれていないという趣旨の注記があります。
一方で、Odooオンラインでのホスティングは追加費用なしとされています。
つまり、Odoo.shを選ぶと、ユーザー単価に加えて基盤の費用が発生します。
(3) 使う量で変わる構造
Odoo.shは基盤サービスなので、処理能力や保存容量といった使用量に応じた構造を持ちます。追加のステージング環境も同様です。
見積もりの段階で、この部分を含めて総額を確認してください。
総費用の考え方は Odoo導入にかかる費用の構造 にまとめています。
【正直に】Odoo.shには体制が要ります
ここは、はっきりお伝えします。
Odoo.shは、開発を行う体制があってはじめて価値が出ます。
3つの環境も、GitHub連携も、コードを書く人がいることを前提にした仕組みです。
必要になるもの
- カスタムモジュールを開発・保守できる技術者（社内または外部）
- 変更を本番へ反映する判断を行う人
- バージョンアップ時に独自部分を確認する体制
社内に技術者がいない会社が、手軽さを求めてOdoo.shを選ぶと、持て余します。
その場合は Odoo Onlineとは？ を検討してください。
カスタマイズは増やすほど重くなる
もうひとつ。3つの環境があるからといって、カスタマイズを自由に増やしてよいわけではありません。
独自に作り込んだ部分は、バージョンアップのたびに確認が必要です。増えるほど、その作業が重くなります。
考え方は Odooのカスタマイズはどこまでやるべきか と Odooのバージョンアップとサポート期間 にまとめています。
Odoo.shが合わないケースもあります
ベンチャーネットは、SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っています。
| 状況 | 検討したい選択肢 |
|---|---|
| 標準機能と設定で足りる。社内に技術者がいない | Odoo Onlineとは？ を参照 |
| カスタム開発が必要で、開発体制がある | Odoo.sh が現実的な選択肢 |
| データを自社内に置く方針がある | Odooをオンプレミスで運用する を参照 |
| 作り込みが大半を占め、Odooの標準をほとんど使わない | AIスクラッチ開発という選択肢 |
最終行について補足します。Odooをほとんどカスタマイズで覆ってしまうなら、そもそもパッケージを選ぶ意味が薄れます。
その場合、必要な機能だけを自社資産として作るほうが、結果的に扱いやすいことがあります。ただしライセンス費用がかからない代わりに、開発費と保守費が別途かかります。判断材料は パッケージERPかスクラッチ開発か に整理しました。
よくある質問
Q1. Odoo Onlineとの違いを一言で言うと？
カスタムモジュールを入れられるかどうかです。
Odoo Onlineでは入れられません。Odoo.shでは入れられます。その代わり、開発と保守の体制が必要になります。
Q2. オンプレミスとの違いは？
サーバの面倒を誰が見るかです。Odoo.shではOdoo側の基盤の上で動きます。オンプレミスでは自社が用意します。
詳しくは Odooをオンプレミスで運用する をご覧ください。
Q3. 開発者がいなくても使えますか？
技術的には使えますが、価値の大部分を活かせません。
3つの環境もGitHub連携も、開発を前提とした仕組みです。設定だけで足りるなら、Odoo Onlineのほうが合っています。
Q4. 費用はどのくらいですか？
金額はOdoo公式の料金ページでご確認ください。構造としては、カスタムプランの契約に加えて、Odoo.shのホスティング費用が別途発生します。
導入支援や開発の費用も別に必要です。
Q5. あとからOdoo Onlineに移れますか？
カスタムモジュールを使っている場合、そのままでは移れません。独自部分をどうするかを決める必要があります。
移行の可否は構成によって変わるため、事前に確認してください。
まとめ
Odoo.shを「OnlineとオンプレミスのAB中間」と理解すると、本質を外します。
本体価値は、開発・ステージング・本番という3つの環境が分かれていることです。
環境が1つしかないと、変更のたびに業務が止まるリスクを負います。すると誰も変更しなくなり、システムは業務に合わなくなっていきます。
3つの環境は、変え続けられる状態を保つための仕組みです。GitHub連携によって、誰がいつ何を変えたかも記録として残ります。
一方で、費用の構造には注意が必要です。カスタムプランが前提で、Odoo.shのホスティング費用は別枠と案内されています。金額は必ず公式の料金ページで確認してください。
そして、いちばん大事な点をもう一度書きます。Odoo.shは、開発体制があってはじめて価値が出ます。
社内に技術者がおらず、標準機能と設定で足りるなら、Odoo Onlineのほうが確実に合っています。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っているため、特定の製品に偏らない立場でご提案できます。
「Odoo.shが必要な要件なのか、Onlineで足りるのか」の切り分けからご相談を承っています。
あわせて読みたい記事
