導入
Odoo のデータモデルにはあまり話題に上らないが便利な仕組みがある。それが「会社ごとに値を持てるフィールド（会社依存フィールド）」だ。マルチカンパニー環境で使い始めると、その小さな設定が運用の負担を大きく減らしてくれることに気づく。
通常、Odoo のレコード上のフィールドは一つの値を持ち、全ユーザーが同じ値を見る。だが複数の法人で同じ製品を共有しつつ、それぞれ固有の社内コードやデフォルト勘定科目を持ちたい場面がある。そうした要件に対応するための仕組みが必要になる。
そのニーズに応えるのが company_dependent 属性だ。カスタマイズや開発、設計段階でこの概念を押さえておけば、マルチカンパニー運用での設計ミスを防ぎやすくなる。
Odoo における「会社別フィールド」とは何か
会社依存フィールドとは、同じレコード上で法人ごとに別々の値を保持できるフィールドを指す。ある法人のユーザーが参照するとその法人用の値が返り、別の法人のユーザーが同じレコードを見れば別の値が返る。
見た目は普通のフィールドと変わらない。ユーザー操作やUI上の振る舞いに差はなく、違いは Odoo の ORM が裏側でどう値を扱うかにある。
UI 上での見え方
Odoo の画面上は通常フィールドと同じ表示で、会社依存であることを直接示す目印はない。これは設計上の仕様で、利用者には透過的に振る舞うのが狙いだ。
開発者視点では、この属性は Char や Boolean、Integer、Float、Many2one といった複数の基本フィールドに付与できる。フィールド宣言で company_dependent=True とすることで ORM 側の特別な取り扱いが有効になる。
Odoo Studio の標準モデルには、製品関連の会計フィールドなど、すでに会社依存として扱われているものが存在する。カスタムで同様のフィールドを追加することも可能だが、Studio のバージョンによっては属性の設定が限定されることがある。
フィールドの仕組み
内部の動作は通常フィールドとまったく異なるため、仕組みを知らないとカスタマイズやデバッグで戸惑う原因になる。実装の違いを理解しておくと安心だ。
保存方法（ir.property を使う仕組み）
Odoo 16 以前では、会社依存フィールドの値はそのモデルのテーブルには直接保存されない。代わりにシステム共通のテーブル ir.property に格納される。
ir.property の各レコードは次の組み合わせを紐付ける。
- ・対象のレコード（例：ID 42 の product）
- ・対象フィールド（例：property_account_income_id）
- ・対象会社（company）
- ・そしてその組み合わせに対する実際の値
このため ORM は現在の会社コンテキストに応じて ir.property を自動参照し、ユーザーからは透過的に見える振る舞いになる。
Odoo 17 以降の変化
Odoo 17 からは保存方式が改められ、会社別値はモデルのテーブル内に用意された jsonb カラムに JSON 辞書として保存されるようになった。これにより検索や集計のパフォーマンスが向上し、実装も単純化された。
ユーザー向けのインターフェースや API の使い方自体は変わらないが、大量データでのクエリ速度は大幅に改善されている。
デフォルト値の扱い
会社依存フィールドは会社ごとのデフォルト値に対応している。特定の会社でまだ値が設定されていない場合は、フィールド定義側にあるデフォルトや会社単位のデフォルトにフォールバックする。Odoo 16 以前は ir.property、17+ はモデル上の取り扱いで指定できる。
ORM とのやり取り
Odoo の ORM では、会社依存フィールドへのアクセスは常に環境の現在会社（self.env.company）を尊重する。つまり、
- ・フィールドの読み取りは現在の会社に紐づく値を返す
- ・書き込みは現在の会社の値だけを更新する
- ・特定の会社の値を操作したい場合は record.with_company(company) を使って対象会社のコンテキストで読書きする、という挙動になる。
業務での利用例
この機能は技術的な興味だけでなく、実務上の典型的な課題を解決する場面で威力を発揮する。ここでは代表的なユースケースを紹介する。
1. 会計：会社別の売上・費用勘定設定
Odoo 標準でよく使われる例がこれだ。製品の property_account_income_id や property_account_expense_id は会社依存フィールドになっている。
実務では、A 社と B 社が同じ製品を販売していても勘定科目体系が異なることが多い。製品レコードを複製せずに、それぞれの法人で別の会計設定を持たせられるのが利点だ。
2. 営業・CRM：会社別の値引き・価格表設定
グループ内で複数の販売会社がある場合、会社ごとに価格戦略を変えたいことがある。共有の顧客レコードに対して会社別のデフォルト価格表を持たせれば、営業プロセスは中央化しつつ商習慣は分離できる。
こうして CRM のデータは共有しつつ、各社の商流ルールを反映できる。
3. 在庫：会社別の在庫評価方法
海外拠点や法的主体ごとに在庫評価のルールが異なる場合、製品やカテゴリに会社依存フィールドでコスト計算方法を持たせると、製品カタログを分割する必要がなくなる。
4. 製造：会社別の推奨仕入先
同じ製品でも会社ごとに利用する仕入先が異なるなら、res.partner を参照する Many2one の会社依存フィールドで法人ごとの推奨先を管理できる。画面上は同じ製品だが、各社は自分の仕入先情報を見る。
5. 法規対応のためのカスタムフィールド
多国籍グループでは、国ごとに異なる税分類や HS コードなどを同一レコードに保持したい場面がある。会社依存の Char フィールドを使えばレコードの重複を避け、法令対応情報だけ会社別に保存できる。
フィールドの作り方・カスタマイズ方法
会社依存フィールドの作り方は主に Studio を使う方法と、Python でモジュールを作る方法の二通りがある。
Odoo Studio を使う場合
Studio はコードを書かずにフィールドを追加できるが、すべてのバージョンで company_dependent を明確に切り替えられるわけではない。Odoo 16/17 の一部環境では標準フィールド追加時にオプションが出るが、柔軟性は限定される。
より細かい制御が必要なら開発でフィールドを定義するのが確実だ。Studio は単純な要件の迅速な対応に向くが、複雑なカスタマイズでは限界があると認識しておこう。
技術的アプローチ：Python でのフィールド定義
カスタムモジュールで宣言する際はシンプルだ。典型的なパターンは次のようになる。
（例）モデル継承してフィールドを追加する場合、fields.Char や Many2one に company_dependent=True を付けるだけで有効になる。
フィールド宣言に company_dependent=True を書き加えるだけで、ORM が自動的に会社別の取り扱いを行ってくれる。
会社ごとのデフォルト値を設定する方法
Odoo 16 以前では ir.property を使って会社ごとのデフォルトを設定することができる。これによりレコード単位で値を入れて回る手間を減らせる。
（例）ir.property の _set_default を使って特定会社のデフォルトを登録することで、該当会社の新規レコードに期待する値を反映できる。
Odoo 17 以降ではデフォルト値の管理がモデル側でより直接的に行われるようになった。
Studio と運用上の注意点
カスタムフィールド名は x_ プレフィックスが必要だ。Studio の UI から会社依存設定が見えにくい場合でも、開発者モードの技術メニューから設定を確認・編集できる。
運用上のベストプラクティス
運用を楽にするための実務的なルールを押さえておけば、トラブルを未然に防げる。ここでは実践的なコツを並べる。
1. 本当に会社ごとに違う値が必要な場合だけ使う
会社依存フィールドは設計の複雑さを増す。全社共通の値なら通常フィールドで十分だ。必要性が明確な箇所のみに限定して使うのが肝心だ。
2. マルチカンパニー環境で必ずテストする
機能開発やテストは最低でも二つの会社を有効にした状態で行う。単一会社で正常でも、他社コンテキストで問題が発生するケースがある。
3. 他社の値を扱うときは with_company() を使う
別会社の値を読み書きする必要がある処理では record.with_company(target_company) を用いる。環境の company を安易に書き換えて戻し忘れるとバグを招くので注意。
4. エクスポート／インポートの挙動を理解する
エクスポート時の値はエクスポートを実行したユーザーの会社に紐づく。別の会社で同じファイルをインポートするとその会社の値として登録される。移行やデータ投入時はこの挙動を明示して運用する。
5. どのフィールドが会社依存なのかを文書化する
利用者はどのフィールドが会社別になっているか分からないことが多い。内部ドキュメントや導入時の説明に短い注記を入れておくと混乱を防げる。
6. 構造化データは可能な限り Many2one を使う
会社ごとの値が別レコード（勘定科目や価格表、取引先）を指すなら、文字列で持たず Many2one の会社依存フィールドにする方が集計や参照の面で有利だ。
よくある落とし穴
会社依存フィールドは便利だが、経験あるエンジニアでも運用ミスでハマるポイントがある。以下の落とし穴を把握しておこう。
落とし穴1：自動処理時の会社コンテキストを見落とす
スケジュールアクションやサーバーアクションは、想定した会社ではなくデータベース内の最初の会社で動作することがある。会社依存フィールドを扱う処理では明示的に with_company() を使うなどして会社コンテキストを保証する。
落とし穴2：計算フィールドと同じ振る舞いだと誤解すること
会社依存フィールドは compute を持つ計算フィールドではない。値の差分はストレージ側の扱いによるもので、compute= と併用すると期待通りに動かないことがある。
落とし穴3：会社横断検索の扱い
通常の ORM 検索は現在の会社コンテキストに限定される。全社分を横断して検索したい場合は Odoo 16 以前では ir.property を直接調べるか、Odoo 17+ では jsonb の内容を適切に扱う必要がある。レポートやデータ抽出で混乱しやすい点だ。
落とし穴4：全会社に対するデフォルト未設定
既存運用中に会社依存フィールドを導入すると、明示的に値が入っていない会社ではフィールドが False/None を返す。業務ロジックがデフォルトを前提にしていると不具合になるため、導入時に全会社分の初期値を設定する移行作業が推奨される。
落とし穴5：アクセス権と混同すること
会社依存フィールドは「どの値が見えるか」を制御するものであって、フィールドそのものを非表示にするものではない。ある会社やユーザーから完全に見えないようにするなら、レコードルールやフィールドレベルのアクセス制御を使う必要がある。
まとめ
会社依存フィールドは、必要な時に初めてその有用性が分かるタイプの機能だ。共有レコード上で法人ごとに異なる設定を持たせたい場面――会計設定、価格、法令対応情報など――に対して無駄なく使える適切な道具である。
ORM の内部動作やバージョンごとの保存方式の違い、運用上の注意点を理解するだけで、マルチカンパニー案件での手戻りを大幅に減らせる。標準ドキュメントや実運用で遭遇する問題の両方で、このフィールドの理解は実務力の証となる。
マルチカンパニーのデータをきれいに扱いたいなら、company_dependent=True を活用することが最も適した解決策になることが多い。
Odoo の導入支援が必要ですか？
私たち Dasolo は、複雑なマルチカンパニー構成を含む Odoo の導入・カスタマイズ・最適化を支援している。データモデルの設計、カスタムフィールド戦略、全社展開まで、実務に即した対応が可能だ。
会社依存フィールドや Odoo 全般の設計でお悩みなら、お気軽にご相談ください。 お問い合わせはこちらから あなたのプロジェクトについてお話ししましょう。