業種や業務フローは企業ごとに異なり、標準パッケージだけでは追いきれない情報が必ずあります。そんなときに役立つのがOdooのカスタムフィールドです。
Odooでは、顧客、見積、製品、請求書などほとんどのレコードに対して独自の項目を追加できます。既存のワークフローを無理に変えずに、必要なデータをそのレコードに紐づけて管理できます。
本稿では、カスタムフィールドの基本概念、内部でどう動くか、コードあり／なしでの作成方法、そして運用をシンプルに保つための考え方までを網羅します。
Odooのカスタムフィールドとは何か
カスタムフィールドとは、Odooの標準モデルに後から追加するデータベース列のことです。1つのレコードに紐づく特定の情報を保存する点では標準フィールドと変わりません。
Odooの慣習ではカスタムフィールド名にx_プレフィックスを付けます。Studioで作成するとx_studio_系の名前になり、プログラム側で追加する場合はプロジェクト固有のプレフィックス（例：x_yourcompany_cost_center）を使うことが多いです。
ユーザーインターフェース上では、カスタムフィールドは標準フィールドと見た目も操作感も同一です。フォーム、リスト、フィルタ、グループ化、レポートに表示でき、非技術ユーザーからは区別がつきません。
利用できるフィールド型
Odooは多彩なフィールド型をサポートしており、一般的な業務要件はほぼカバーできます。
- 短文（Char）: 参照コードやラベルなど短い文字列
- 長文（Text）: 備考や詳細説明のための複数行テキスト
- 整数（Integer）: カウントやスコアなどの整数値
- 小数（Float）: 測定値やレートの小数値
- 金額（Monetary）: 通貨単位を考慮する金額（通貨フィールドと連動）
- 真偽（Boolean）: チェックボックスでのはい/いいえ
- 日付 / 日時（Date / Datetime）: カレンダー日付やタイムスタンプ
- 選択（Selection）: 事前定義された選択肢のドロップダウン
- Many2one: 別モデルの単一レコードへの参照
- One2many: 別モデルの関連レコード一覧
- Many2many: 複数レコードの関連付け
- バイナリ（Binary）: ファイル添付
- HTML: リッチテキストコンテンツ
可能な値が明確に決まっている場合は最初から適切な型を選ぶことが重要です。例えば選択肢が決まっているなら自由記入よりもSelectionにしておけば、入力のばらつれによる集計ミスを防げます。
フィールドの仕組み
Odooは内部でORM（Object-Relational Mapping）を使っており、画面に見える各レコードはPythonのモデルクラスとデータベース表の対応で成り立っています。カスタムフィールドを追加すると、ORMのメタデータとデータベース側に必要な列が自動的に登録されます。
これによりOdooのデータモデルは柔軟になります。ソースコードを書き換えるのではなく、メタ情報（ir.model.fieldsテーブル）に拡張情報を保存し、起動時にその定義を読み込んで動的にフィールドを生成します。
コード定義フィールドとDB定義フィールドの違い
標準的なOdoo開発では、フィールドはPythonのモデルクラス内で定義されます。フレームワークの仕組みに従った記述が基本です。
（例示）典型的なPythonでのフィールド定義は次のようになります：
一方で、UIやAPIから作成されるカスタムフィールドはir.model.fieldsにstate='manual'として保存され、実行時にロードされます。どちらの方法でもデータベース列は作られ、ユーザーから見れば同じように動作します。
リレーションフィールドと相互関係
Many2oneで他モデルを参照する場合、ORMは反対側に対応するOne2manyを期待します。これは単なる慣習ではなく、Odooのリレーション操作が両方向の関連付けを前提にしているためです。
例えば見積書（sale.order）にx_project_id（project.projectへのMany2one）を追加したら、プロジェクト側にx_sale_order_ids（sale.orderへのOne2many）を用意しておくと、プロジェクト画面から関連する見積を辿れるようになります。片側だけだと標準画面からの遷移ができません。
計算式（Computed）フィールド
計算フィールドは他のフィールドの値から自動的に算出されるフィールドです。技術的にはPythonの計算メソッドを定義してcompute属性で紐付けます。通常は読み取り専用で、依存先が変わると自動更新されます。
計算フィールドは強力ですが、コードが必要です。Odoo Studioだけで手軽に作れるものではなく、開発者モードやPythonの知識が必要になるケースがほとんどです。
業務での利用シーン
当社Dasoloが手がける案件でも、ほぼ全プロジェクトにカスタムフィールドが登場します。以下は実務でよくある5つの用途例です。
1. CRM：リードの精緻な判定
標準のリード情報に加えて業界分類や市場セグメントなどを選択肢として持たせると、営業はリードを素早く評価でき、経営側はセグメント別のパイプラインを可視化できます。SelectionやMany2oneでの補助モデル化が有効です。
2. 営業：社内プロジェクトコードの管理
プロジェクトごとに請求する企業では、見積や受注に社内コードを紐づけたいことが多いです。sale.orderに短いCharフィールド「プロジェクトコード」を追加すれば、帳票に印字したり集計で絞り込んだりできます。大規模なPM連携が不要な場面に有効です。
3. 在庫：製品固有の属性管理
業界特有の仕様を追跡するために、例えば「保証期間（月）」（Integer）や「認証規格」（Selection）、「原産国」（Many2one→res.country）といったフィールドを製品に追加することがあります。これらは在庫や製品表に自然に馴染み、レポートでも利用可能です。
4. 会計：コストセンターや予算の紐付け
請求書や仕訳に対してコストセンターを付与したい場合、account.moveにカスタムのCost CenterモデルへのMany2oneを用意すると便利です。分析会計の仕組みを変えずに詳細な配賦ができ、ピボットやエクスポートでもすぐに扱えます。
5. 人事：オンボーディング固有データ
雇用契約の種類や社内スキルカテゴリ、車両割当てなど、従業員に紐づく国や企業特有の情報はhr.employeeにカスタムフィールドで追加しておくと、別スプレッドシートを使わずにOdoo内で検索・集計できます。
フィールドの作り方・カスタマイズ方法
カスタムフィールドの作成方法は大きく2つに分かれます。選択は技術力と必要な機能によって決めましょう。
選択肢1：Odoo Studio（ノーコード）
Odoo Studioは非開発者でも最短でフィールドを追加できる手段です。Studioを使った手順は簡単です。
- 対象のアプリ・レコード（例：見積書フォーム）を開く
- 鉛筆アイコンでStudio編集モードに入る
- 左パネルからフィールド型をドラッグしてフォーム上に置く
- ラベル、技術名、各種プロパティを設定する
- 保存してStudioを終了する
Studioはフィールドをir.model.fieldsにx_studio_プレフィックスで登録し、ビューにも即反映します。サーバ再起動やデプロイは不要です。単純なフィールド追加には最も手早い方法です。
選択肢2：API／コードによる技術的なカスタマイズ
開発プロジェクトではXML-RPCやPythonモジュールでプログラム的にフィールドを作ることがあります。計算フィールドや複雑なドメイン指定、コード管理下に置きたい変更はこの方法が適しています。
APIを使うと、例えばsale.orderにカスタムのSelectionフィールドを作る処理は次のようになります：
（サンプル）モデルIDを取得してir.model.fieldsへ作成リクエストを送る例。自動化スクリプトやリモート設定に便利です。
このやり方はソースファイルを直接編集せずにフィールドを追加する標準的な開発フローの一部で、遠隔設定や自動デプロイの際に役立ちます。
より本格的には、Pythonモジュール内でフィールドを定義し、通常のOdooモジュールとして読み込む方法があります。アップグレード対応やバージョン管理が必要な場合はこれが最も保守的です。
フィールドをビューに表示する方法
フィールドを作っても自動で画面に出るとは限りません。Studioなら同時追加しますが、コードベースではビューXMLに追記するか、継承ビューで挿入位置を指定して表示させる必要があります。
運用上のベストプラクティス
カスタムフィールドは作成自体は簡単ですが、設計を誤ると後で手直しが大変になります。以下の実践ルールを守るとシステムを綺麗に保てます。
可能な限り選択（Selection）を使う
候補が決まっている項目はCharなどの自由入力にせずSelectionを使いましょう。表記ゆれがなくなり、フィルタや集計が確実になります。
名前付けは明確かつ一貫して行う
技術名（例：x_project_type）は何を表すかを示すべきで、フォーム上の位置で命名してはいけません。意味のないx_field_1のような名前は数ヶ月後の保守を困難にします。命名規則を決めて記録しておきましょう。
安易にネイティブモデルを肥大化させない
sale.orderに10個も20個もフィールドを追加するのは避けるべきです。一群の項目がひとつの業務実体（例：プロジェクト、契約、認証）を表すなら、新しいカスタムモデルを作りMany2oneでつなぐ方が設計的に優れます。
まずはステージング環境で検証する
本番データベースに直接追加する前に、複製したステージングでテストしてください。型のミスやモデルの誤指定は手動での修復が必要になることがあるため、事前確認が重要です。
カスタムフィールドのドキュメント化を怠らない
追加したフィールドのモデル、技術名、目的、依頼者を記録しておきましょう。導入が進むとフィールドは増え、使われているかどうかがわからなくなります。整理・削除判断には記録が必須です。
計算ロジックは適切なツールで実装する
あるフィールドの値が他フィールドから導出されるなら、ユーザーに手入力させるのではなく計算フィールドで自動化しましょう。整合性が保たれ、入力ミスが減ります。計算フィールドはOdooのPythonフィールド機能としてしっかりサポートされています。
よくある落とし穴
経験のあるチームでもカスタムフィールド関連でよくある問題に遭遇します。代表的なものを挙げます。
Many2oneを作ってOne2manyを忘れる
一番多いミスです。モデルAにモデルBへのMany2oneを追加したとき、逆方向のOne2manyを作らないと、ユーザーはモデルB側から関連レコードを一覧できません。両側セットで作るのが鉄則です。
データを持つフィールドを削除してしまう
フィールドを削除するとその列と中のデータは完全に消えます（元に戻せません）。今後使う可能性があるなら削除ではなく非表示化やアーカイブを検討してください。
本番で直接フィールドを作るリスク
ライブ環境で直接変更を行うと、ビュー設定の誤りでユーザーがエラーを受けるなどの影響が出ます。小さな変更でもまずはテスト環境で動作確認を行ってから本番反映しましょう。
標準フィールドとの命名衝突
同じモデルに既にある名前を使おうとするとOdooは拒否しますが、将来インストールするモジュールと衝突するケースは起き得ます。会社独自のプレフィックス（例：x_acme_）を付けて衝突リスクを下げるのが定石です。
UXを考えずにビューへ大量追加すること
表示できるからといって全てのフィールドをデフォルトで見せるべきではありません。フォームが煩雑になると入力効率が落ちます。文脈に応じてタブに分ける、条件付き表示にするなど工夫しましょう。
Studioフィールドとコードフィールドを無計画に混在させる
Studioとコードの併用は便利ですが、方針が無いと似た用途のフィールドが重複したり名前が衝突したりします。プロジェクト開始時にノーコードで済ませる範囲とコードで管理する範囲を明確に決めておくことが重要です。
まとめ
カスタムフィールドはOdooを業務に合わせる最も手軽で効果的な方法の一つです。ソースを書き換える必要がなく、プラットフォームに自然に溶け込み、ユーザーが必要な情報を直截に入力できるようにします。
重要なのは作る前の設計です。適切な型を選び、命名規則を守り、リレーションの取り扱いに配慮し、追加したら記録を残す。良いフィールド設計は保守性を高め、ビジネスの変化にも柔軟に対応できます。
Odoo Studioで手早く追加する場合でも、Pythonモジュールで堅牢に管理する場合でも、基本原則は共通です：データに合ったフィールドを選び、モデルを汚さず、必ずテストを行うこと。
Dasoloでは、企業の実際の業務に合わせたOdooの導入・カスタマイズ・最適化を支援しています。少数のカスタム項目追加からフルスクラッチのモジュール開発まで、ニーズに応じた支援が可能です。
Odooの設計や運用でお困りなら、お気軽に相談ください。現在の設定を確認して、最も整った移行・改善プランを提案します。