大手の取引先から、数十項目のセキュリティチェックシートが届く。「アクセス権限の管理方法」「バックアップからの復旧手順」の欄で、担当者の手が止まる。
オープンソースのERPなら、社内から「ソースコードが公開されているのに大丈夫なのか」という声も出ます。心配は自然ですが、コードの公開は、それ自体が弱点ではありません。多くの目で検証されるという側面もあります。
Odoo（オドゥー：オープンソース由来の統合業務アプリ群）のセキュリティは、「責任分界点」から考えると整理できます。どこまでをOdoo側が担い、どこからが自社の責任になるかの境目です。
基盤の運用は、OdooオンラインとOdoo.shならOdoo側、オンプレミスなら自社です。いちばん下の「設定と運用」の層は、どの形態でも自社に残ります。実際の事故は、この層で起きることがほとんどです。
境目を押さえると、たとえば次のことが変わります。
- 権限を3層で設計し、他人の案件や人事情報を見せずに済む（アクセス制御の3層）
- 二要素認証を必須にし、「機能はあるが誰も使っていない」を防げる
- 復旧を一度試しておけば、チェックシートの復旧手順の欄に迷わず答えられる
Odooには、無料でオープンソースのCommunity版と、有償サブスクリプションのEnterprise版があります。Community版を自社サーバーで運用する場合は、すべての層が自社の責任です。両版の良い点と注意点は、Odooのセキュリティのメリットとデメリットに並べました。
では、取引先のチェックシートに迷わず答えられる体制とは、どういうものか。答えは監査や取引先から問われたときの点検リストにあります。
Odooのセキュリティ設計はどうなっているか
Odooは、データベースへの問い合わせを組み立てる仕組みを通じて、SQLインジェクションを標準で防ぐ設計です。Odoo公式のセキュリティページに、そう記載されています（出典：Odoo公式 セキュリティページ、2026年8月確認）。
SQLインジェクションとは、入力欄に不正な命令を紛れ込ませ、データベースを勝手に操作する攻撃です。
またOWASP（Webアプリケーションの代表的な脆弱性を整理している団体）が挙げる主要な項目について、それぞれの対応方針を公式に公開しています。
さらに、脆弱性の報告を受け付ける「責任ある開示」のプログラムを運用しています。独立したセキュリティ研究者のコミュニティが、ソースコードを継続的に確認しているとしています（出典：同上、2026年8月確認）。
オープンソースの利点は、ここにあります。
コードが公開されているため、外部の研究者が問題を見つけ、報告できます。報告の窓口と対応の手順が公開されていること自体が、透明性の裏付けです。
「オープンソースだから危険」は正確ではない
よく聞く心配は、次の4つです。
| よくある心配 | 実際のところ |
|---|---|
| コードが公開されているから攻撃されやすい | 公開されているのはOdooの共通部分。自社のデータや設定は公開されない |
| 誰でも中身を書き換えられる | 公式版への変更はOdoo社が管理する。自社環境に勝手に反映されることはない |
| 無料版はセキュリティ機能がない | 認証やアクセス制御の仕組み自体は共通。違いはサポートと保守の担い手 |
| 脆弱性が公表されると狙われる | 公表とあわせて修正が出る。問題は「更新を適用しないこと」 |
4つのうち、要になるのは最後の行です。
リスクの中心は、製品の設計ではなく運用にあります。更新を適用しない、権限を絞らない、退職者のアカウントが残っている。セキュリティ事故は、こうした場面で起きます。
Odooの権限設定：アクセス制御の3層
Odooの権限管理は、3つの層の組み合わせです。この仕組みを知っておくと、社内で権限の議論がしやすくなります。
第1層はグループ（役割）です。どのアプリ・どのメニューを使えるかを、役割ごとにまとめて決めます。たとえば、営業担当はCRMと販売、経理担当は会計と請求です。
第2層はアクセス権です。データの種類ごとに、参照・作成・更新・削除の可否を決めます。見積は作成できるが、削除はできない、といった設定です。
第3層はレコードルールです。同じ種類のデータでも、どの1件を見られるかを条件で絞り込みます。自分の担当顧客だけ、自部門の伝票だけ、という制御がここで決まります。下の層ほど、細かい制御になります。
多くの会社が、第1層だけで済ませてしまいます。機微なデータを扱うなら、第2層と第3層まで設計してください。
とくに次のようなケースでは、第3層が役に立ちます。
- 営業担当に、他人の案件を見せたくない
- 部門ごとに、他部門の経費や原価を隠したい
- 人事情報を、担当者以外に見せたくない
設計の原則は、「必要な人に、必要な範囲だけ」です。最初に広く与えて、あとから絞るのは難しくなります。職務分掌（担当を分けて誤りや不正を防ぐ考え方）から権限を組み立てる手順は、権限・ロール設計の考え方（NetSuiteの教科書）で解説しました。
Odooの二要素認証は「使えること」と「徹底すること」が違う
Odooには、二要素認証が備わっています。パスワードに加え、認証アプリが生成する使い捨てのコードで本人を確認する仕組みです。
方式は、スマートフォンの認証アプリに秘密情報を保存し、ログイン時にコードを入力するものです（出典：Odoo 19.0公式ドキュメント、2026年10月確認）。
一部の国のローカライゼーションでは、二要素認証を無効化できない設定になっています（同上）。
使えることと、徹底することは違います。
既定のままでは、二要素認証を使うかどうかは各ユーザーの設定に委ねられます。「機能はあるが、誰も使っていない」という状態がありうるわけです。設定アプリの「Enforce two-factor authentication」を使えば、従業員だけ、または全ユーザーに必須にできます（同上）。
少なくとも、管理者権限を持つアカウントでは必ず有効にしてください。
実務で押さえる5つのポイント
管理者権限を持つ人を絞る
もっとも効果が大きい対策です。管理者は、すべてのデータを見られ、設定を変更できます。
「便利だから」と管理者権限を配ると、統制が利かなくなります。名前を挙げられる範囲に限定してください。
退職者・異動者のアカウント処理を決める
放置されがちな領域です。退職したのにログインできる状態は、明確なリスクです。
いつ、誰が、どの手順でアカウントを停止するか。人事の手続きとつないだ運用ルールにしておいてください。
更新の適用を計画に入れる
セキュリティ修正は、適用して初めて意味を持ちます。
Odooの標準サポートは、各メジャーバージョンとも3年間です。古いバージョンにとどまり続けると、延長サポート（追加料金。Odoo.sh（一部の版）とオンプレミスのみ）を契約しない限り、修正の対象外になります。
バージョン管理の考え方は、Odooの運用・保守で押さえるポイントにまとめています。
追加モジュールを確認する
サードパーティ製のモジュールを入れる場合、そのコードもシステムの一部です。
提供元、更新の頻度、対応バージョンを確認してください。判断の考え方は、Odooのカスタマイズはどこまでやるべきかで扱っています。
外部連携の権限を最小にする
他システムと連携する場合、連携用のアカウントが必要です。
このアカウントに管理者権限を与えると、連携先が侵害されたときの被害が広がります。必要な範囲だけに絞ってください。AIツールにデータを渡す場合も考え方は同じで、AIに会社のデータを、どこまで渡すか（バーチャルブログ）で扱っています。
Odooのバックアップは「戻せるか」で考える
バックアップがセキュリティの文脈で欠かせないのは、「復旧できることが最後の防衛線」だからです。
確認すべき点は、次の6つです。
| 確認項目 | 決めておくこと |
|---|---|
| 取得の頻度 | どのくらいの間隔で取るか |
| 保管期間 | 何日前まで戻せるか |
| 保管場所 | 本番と同じ場所に置いていないか |
| 復旧の手順 | 誰が、どうやって戻すか |
| 復旧の所要時間 | 何時間で業務を再開できるか |
| 実際に試したか | 手順書だけでなく、復旧を実行したことがあるか |
抜けやすいのは、最後の項目です。
手順書があっても、実行したことがなければ、本番で通用するかは分かりません。年に一度は、検証環境で復旧を試してください。
クラウド環境を使う場合でも、操作ミスによるデータ削除は、基盤側のバックアップとは別の話です。誰が削除できるかの設計も、あわせて確認してください。
Community版とEnterprise版でセキュリティの何が変わるか
認証やアクセス制御の基本的な仕組みは、共通です。違うのは、担い手と対応の速さです。
| 観点 | Community版 | Enterprise版 |
|---|---|---|
| 価格 | 無料のオープンソース版 | 有償のサブスクリプション |
| ホスティング | 自社の責任 | Odooオンライン・Odoo.sh・自社サーバーから選べる |
| バックアップ | 自社で取得・保管・復旧 | 利用形態により提供される |
| 公式サポート | 対象外 | 対象 |
| 更新の適用 | 自社で判断・実施 | 公式のアップグレードサービスを利用可能 |
| 障害時の窓口 | 社内または委託先 | 公式サポート |
Community版は無料ですが、セキュリティ運用の負担はすべて自社に来ます。
分かれ目は、社内に対応できる技術者がいるか、外部に委託できるかです。詳細は、Odoo Community版とEnterprise版の違いをご覧ください。
Odooのセキュリティのメリットとデメリット
ここまでの内容を、良い点と注意点に分けて並べます。どちらの版に当てはまるかも添えました。
良い点は、次の5つです。
- 外部の目で検証される：コードが公開され、責任ある開示のプログラムで脆弱性の報告を受け付けている
- 権限を3層で細かく絞れる：グループ・アクセス権・レコードルールで、見せる範囲を設計する
- 二要素認証を必須にできる：従業員だけ、または全ユーザーに必須にできる。認証とアクセス制御の仕組みは両版で共通
- 変更の履歴を追える：各レコードに更新の履歴が残り、誰がいつ変えたかを追跡できる
- Enterprise版なら基盤を任せる形も選べる：OdooオンラインとOdoo.shなら基盤の運用はOdoo側。公式サポートも対象
注意点は、次の4つです。
- 設定と運用の層は必ず自社に残る：権限設計・アカウント管理・二要素認証の徹底・復旧の確認は、どの形態でも自社が担う
- 二要素認証は既定では各ユーザー任せ：必須にしなければ、使うかどうかは各ユーザーの設定に委ねられる
- Community版はすべての層が自社の責任：ホスティング・バックアップ・更新の適用を自社で担い、公式サポートの対象外
- 追加モジュールのコードもシステムの一部：提供元・更新の頻度・対応バージョンを確かめる必要がある
両方を1枚の図に並べました。
注意点の多くは、担当と手順を先に決めれば避けられます。その順番はベンチャーネットが権限と復旧の体制を固める順番にまとめました。
監査や取引先から問われたときに答えられるか
上場企業との取引や監査の場面では、体制について質問を受けることがあります。次の点検リストで、自社がいま答えられるかを確かめてください。
- □ 誰がどのデータにアクセスできるかを、役割ごとの一覧で示せる
- □ 管理者権限を持つ人の名前を、すぐに挙げられる
- □ 誰がいつデータを変更したかを、あとから追跡できる
- □ 退職・異動のとき、誰が何日以内にアカウントを止めるか決まっている
- □ 脆弱性情報を定期的に確認する担当者が決まっている
- □ バックアップからの復旧を、実際に試した記録がある
これらは、技術の質問ではなく体制の質問です。製品を問わず、経営の視点で対策を組み立てる進め方は基幹システムのセキュリティとは（NetSuiteの教科書）にまとめました。
Odooは各レコードに更新の履歴が残る仕組みを持つため、変更の追跡には対応できます。ただし、「誰が管理しているか」「どう運用しているか」は、自社で整理しておく必要があります。
□が半分以上埋まらない場合は、機能を足すより先に、担当と手順を決めてください。
ベンチャーネットが権限と復旧の体制を固める順番
ERP導入支援を手がけるベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。AIスクラッチ開発には、開発費・保守費が別途かかります。セキュリティの相談でも、製品の機能比較からは入りません。次の順で確認します。
- 責任分界点を自社に当てはめる：Odooオンライン、Odoo.sh、オンプレミスのどれを選ぶかで、自社が担う層は変わります。まず「基盤・更新・設定と運用」の各層を、社内の誰が担うかを表にします。形態の違いは、Odooの導入形態3つを比較にまとめています。
- 見せてはいけないデータを先に挙げる：人事情報、原価、他人の案件など、見せる範囲を絞るべきデータを経営側と洗い出します。そのうえで、標準の3層の仕組みで表現できるかを確かめます。
- 人の出入りに合わせた運用ルールを決める：管理者権限を持つ人、退職・異動時の停止手順、連携用アカウントの権限を文書にします。ここは製品ではなく、社内の手続きの問題です。
- 本番稼働の前に一度、復旧を試す：バックアップから検証環境に戻し、何時間で業務を再開できるかを実際に測ります。
社内に担い手がいないのに、Community版の自社運用を選ぶ計画は、そのまま進めることをお勧めしません。監査対応や拠点展開の要件が重い場合は、NetSuiteのほうが合うこともあります。合わないときは、合わないとお伝えします。
よくある質問
オープンソースのERPは、商用製品よりセキュリティが弱いですか？
弱いとは限りません。設計上の対策は公式に公開されており、外部の研究者による検証も受けています。
差が出るのは、運用です。更新の適用、権限の設計、アカウント管理をどこまで徹底できるかで、結果が変わります。
自社サーバーで運用するのと、クラウドを使うのはどちらが安全ですか？
どちらが安全かではなく、誰が担うかの違いです。
自社サーバーなら、OSの更新、ネットワークの防御、バックアップの取得まで自社の責任になります。対応できる体制があるかで判断してください。
二要素認証は全員に必須にすべきですか？
少なくとも、管理者権限を持つアカウントには必須にしてください。
全ユーザーに広げるかは、扱うデータの機微さと、現場の運用負担のバランスで判断します。
脆弱性の情報はどこで確認できますか？
Odooは責任ある開示のプログラムを公開しており、セキュリティに関する情報を公式サイトで案内しています。
あわせて、誰がこれを定期的に確認するかを決めておくことが重要です。情報があっても、見る人がいなければ意味がありません。
セキュリティ対策は、まず何から始めればよいですか？
管理者権限の絞り込み、退職者のアカウント処理、更新の適用、復旧の検証。この4つから着手すると、効果が大きいです。
どこまで厳しくするかは、扱うデータと事業への影響で決まります。すべての領域で、最も厳しい水準をめざす必要はありません。
Odooのセキュリティのメリットとデメリットは何ですか？
強みは外部の検証と細かな権限設計です。注意点は、運用が自社に残ることです。
コードが公開され、責任ある開示のプログラムで脆弱性の報告を受け付けています。権限は、グループ・アクセス権・レコードルールの3層で絞れます。一方、設定と運用の層は、どの形態でも自社の責任です。Community版では、すべての層を自社で担います。一覧はOdooのセキュリティのメリットとデメリットにあります。
まとめ：Odooのセキュリティは責任分界点から考える
Odooのセキュリティは、責任分界点から考えると整理できます。
- ソースコードの公開は弱点ではない。外部の検証を受けられる側面もある
- リスクの中心は、製品の設計ではなく運用にある
- アクセス制御は、グループ・アクセス権・レコードルールの3層で設計する
- 二要素認証は「使えること」と「徹底すること」が違う
- 管理者権限の絞り込みと、退職者のアカウント処理から着手する
- バックアップは「取っているか」ではなく「戻せるか」
- Community版を自社運用する場合、すべての層が自社の責任になる
どの形態を選んでも、設定と運用の層は必ず自社に残ります。ここを誰が担うかを決めることが、セキュリティ対策の出発点です。
1年後、取引先からセキュリティチェックシートが届いても、担当者は管理者権限の一覧と直近の復旧テストの記録を添えて、迷わず返送しています。退職者のアカウントは人事の手続きと同じ日に止まり、その運用が当たり前になっている状態です。
もう少し詳しく知りたい方へ
権限の線引きや復旧の手順を、自社の組織図に当てはめて整理したい方は、現状の体制のまま気軽にご相談ください。規模や要件によっては上位のNetSuiteやSAPが、パッケージに乗らない業務にはAIスクラッチ開発（開発費・保守費は別途）が適することもあります。
関連記事
