イントロダクション
Odooで最も単純かつ頻繁に使われるフィールドの一つがブール型（Boolean）です。見た目は単純なチェックボックスでも、受注の承認や取引先の有効/無効、商品のお気に入り登録といった日常の操作のほとんどがこのフィールドを介して行われています。
単純だからこそ挙動を正しく理解しておかないと、意図しない動作や運用面の混乱を招きます。どの場面でブールを選び、いつ別の型を使うべきか、設定のポイントは何かを押さえておけば、より堅牢で扱いやすいOdoo環境が作れます。
本記事はブール型フィールドをあらゆる角度から扱います。データベースに何を保存するのか、UI上でどう見えるか、StudioやPythonでの作り方、現場での具体的な適用例、そして実務で役立つ設定や注意点までカバーします。
Odooにおけるブール型フィールドとは何か
OdooのORMではブール型は真偽のいずれか一方を保持します。PostgreSQL上ではBOOLEAN列に対応し、値は基本的にTrueかFalseのどちらかになります。中間的な値や曖昧さは存在しません。
ユーザーインターフェース上ではフォームにチェックボックスとして表示されるのが標準です。一覧ではTrueならチェックやアイコンが表示され、Falseなら何も表示されないため、スキャン性の高いリスト表示ができます。ウィジェット次第でトグルスイッチやスターアイコンのような見せ方にも切り替えられます。
開発者向けには、Pythonモジュール内でブールフィールドを定義してモデルに追加します。
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
needs_manual_review = fields.Boolean(
string='Needs Manual Review',
default=False,
)The string parameter sets the label shown in the interface. The default parameter controls the initial value when new records are created. Without a default, Odoo treats the field as False automatically, but it is considered good practice to declare it explicitly.
In Odoo Studio, this same field type is simply called a Checkbox. Fields created through Studio receive an x_studio_ prefix automatically. When created through Python or the XML-RPC API, you define the technical name yourself.
ブール型フィールドの動作仕組み
モデルにブールフィールドを追加すると、モジュールのインストールやアップグレード時に対応するDB列が自動で作成されます。手動でSQLを触る必要は基本的にありません。
重要な点として、OdooのブールフィールドはNULLを返しません。ORMは読み取り時に常にTrueかFalseを返すため、Noneチェックに悩まされることはありません。他のMany2oneやCharのような型とはこの点で挙動が異なります。
主要なフィールド属性
ここではブール型で設定可能な代表的属性を紹介します。
- default：新規作成時の既定値。多くはFalseですが、オプトアウトのような場面ではTrueにすることもあります。
- compute：他のフィールドの状態から値を算出するメソッドを紐づけるために使います。派生的なフラグに有効です。
- store：computeと組み合わせる場合にDBに保存するかを決めます。store=Trueにすると検索やレポートで利用可能になります。
- readonly：画面上でユーザーが手動変更できないようにする設定です。システム側でのみ制御したいフラグに使います。
- copy：レコード複製時に値を引き継ぐかを制御します。デフォルトはTrueですが、承認済みなど複製後はクリアすべきフラグにはcopy=Falseを指定します。
- groups：表示・編集を特定ユーザーグループに制限するために使います。
ビューでの見え方
フォームではHTMLのチェックボックス、一覧ではTrueにチェックアイコンを表示して視認性を高めます。ユーザーが一覧を流し読みするときに便利な表現です。
ウィジェットで見た目を変えられます。toggleウィジェットなら設定や好みなどに使いやすいスイッチ表示に、boolean_favoriteであれば商品や連絡先のお気に入りを星アイコンで表現できます。
ドメイン（フィルタ）での使い方
ブールは検索ドメインで扱いやすく、検索ビューや自動化アクション、アクセスルールの条件式で頻繁に使われます。たとえば未チェックのレコードを抽出する場合は次のようになります。
[('needs_manual_review', '=', True)]True/Falseしかないため、演算子なしでもシンプルに書ける場面が多いです。
[('needs_manual_review', '=', False)]この単純さが自動化やスケジューラ、サーバーアクションと相性が良く、複雑な条件を組まずに処理判定ができる利点につながります。
ORMとのやり取り
開発者はレコードオブジェクト上の属性をそのまま読み書きします。True/Falseで比較・代入するだけで、ORM側が必要な変換やAPI連携をきれいに処理してくれます。XML-RPC経由でもブールは素直に渡せます。
業務での利用ケース
代表的な業務での活用例
CRM：リードの育成可否の管理
営業ではシニアが有望なリードかを判定する場面が多くあります。リードにis_qualifiedといったブールを置くことで、優先すべき案件を即座に抽出でき、段階ごとのステージを無理に増やさずにシンプルに運用できます。
販売：手動チェックが必要な注文のフラグ付け
高額注文や新規顧客などで承認フローが必要な場合、needs_manual_reviewのようなチェックを自動で立てることで財務やオペレーション側の作業キューが明確になります。注文一覧をこのフラグで絞り込めば処理が速くなります。
在庫：カタログ外商品を示す
販売終了だが履歴として残す商品はis_discontinuedのようなフラグを付けると、購買や営業が誤って見積や発注に含めないようにできます。価格リストや購買ルール、ウェブショップの表示制御にも利用できます。
会計：注意が必要な請求書の識別
請求に異議や差額がある場合、chatterの自由記述ではなくunder_disputeのようなブールで管理するとフィルタやレポートが容易になります。フラグ付けした請求には自動リマインダーを止める、といった運用にも向きます。
人事：資格・研修の完了管理
必須研修や保有資格の管理には、社員レコードにsafety_training_completedのようなブールを持たせると簡単に抽出・監査ができます。複雑なモジュールを作らずにコンプライアンスレポートへも繋げられます。
ブール型フィールドの作成・カスタマイズ方法
ブールフィールドを追加する方法は主に3つあり、技術レベルや運用方針で使い分けます。
Odoo Studioを使う（ノーコード）
Studioはコードを書かずに画面やフィールドを追加できるローコードツールです。ブールを追加する手順は簡単です。
- Studioアプリを起動します（Studioアプリのインストールが必要）。
- フィールドを追加したいフォームを開きます。
- サイドバーからCheckbox（チェックボックス）をドラッグしてフォームに配置します。
- プロパティでラベルや初期値、必須や読み取り専用設定を行います。
- 保存してStudioを閉じます。
Studio handles everything automatically: the field is created in the database with an x_studio_ prefix and added to the view. No restart or upgrade is required.
カスタムモジュールでPythonを使う方法
バージョン管理やテスト、複数環境への展開が必要な場合はPythonでフィールドを定義するのが推奨です。
from odoo import fields, models
class ResPartner(models.Model):
_inherit = 'res.partner'
x_is_key_account = fields.Boolean(
string='Key Account',
default=False,
copy=False,
)定義後は該当ビューのXMLにフィールドを追加して画面に表示します。モジュールのインストールやアップグレード時にDB列が生成されます。
計算フィールドとして定義するパターンもあります。
from odoo import api, fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
is_high_value = fields.Boolean(
string='High Value Order',
compute='_compute_is_high_value',
store=True,
)
@api.depends('amount_total')
def _compute_is_high_value(self):
for order in self:
order.is_high_value = order.amount_total >= 10000store=Trueにすると計算結果がDBに保存され、検索やグルーピングで再計算なしに利用できます。
XML-RPC APIを使う方法
デプロイパイプラインやリモート設定スクリプトで自動的にフィールドを作成する場合、XML-RPC経由でir.model.fieldsにレコードを追加できます。
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_needs_manual_review',
'field_description': 'Needs Manual Review',
'model_id': model_id,
'ttype': 'boolean',
'state': 'manual',
}]
)state: 'manual' はStudioやAPI外で作成されたフィールドであることを示します。自動設定フローでリモート作成する運用にもこの形が適します。
ベストプラクティス
1. 常にdefaultを明示する
ORMは未設定をFalseとして返しますが、モデル定義でdefault=Falseを明記しておくことが推奨です。設計意図が明確になり、他の開発者や自動化ルールの読み取りが楽になります。
2. 質問文として自然に読める名前にする
フィールド名はyes/noで答えられる問いの形が望ましいです。is_verified、needs_approval、has_warranty、is_key_accountのように意味が即座に伝わる名前を付け、不明瞭なflagやstatusといった命名は避けましょう。
3. 承認やステータス系にはcopy=Falseを設定する
複製時に承認済みフラグが引き継がれると業務上の混乱を招きます。複製後はフラグをクリアすべきものにはcopy=Falseを付ける習慣をつけましょう。
4. 派生的な状態は計算フィールドにする
他項目の変化に応じてブールを更新する場合、個別のサーバーアクションで都度書き換えるよりもcomputeと@api.dependsで一元管理すると保守性が高まります。
5. フィルタで使うなら検索ビューに追加する
If users regularly need to filter records based on a Boolean field, add it explicitly to the search view. In Studio, enable the search option in the field properties panel. In code, add it to the <search> view XML. This gives users a clean filter button in the search bar rather than forcing them to use advanced filters every time.
よくある落とし穴
状態が三者以上あるのにブールを使う
もっとも多い誤りは、三状態以上をブールで表現しようとすることです。「保留」「承認」「却下」など複数状態がある場合、ブールを重ねると管理が破綻します。そうした場合はSelection型やワークフローで表現すべきです。
承認フラグにcopy=Falseを付け忘れる
レコードを複製したときに承認済みやレビュー済みのフラグがそのままコピーされると、承認プロセスをすり抜けた状態が生じます。複製後に初期化すべきフラグには必ずcopy=Falseを設定してください。
検索ビューにフィールドを追加しないままにする
ユーザーがそのフィールドで絞り込みたいのに検索ビューに無いと、高頻度で詳細フィルタを開く手間が発生します。フィールドを追加する際は同時に検索ビューへの配置も検討しましょう。
可視性用途に独自ブールを使ってしまう
レコードの表示/非表示に関しては多くのモデルに既存のactiveフィールドがあります。アーカイブや表示非表示をしたい場合は標準のactiveを使うことでUIの既存機能と整合性が取れます。
store=Trueにしない計算ブールをフィルタに使う
計算フィールドでstore=Falseのまま検索やグルーピングに使おうとするとエラーになったり無視されたりします。フィルタやレポートで使う計算ブールは必ずstore=TrueにしてDBに保存してください。
まとめ
ブール型は目立たない存在であるほど優秀です。activeフラグからis_publishedまで、あらゆる場面で自然に動作していることで日常業務が滑らかになります。
その挙動を正しく理解し、適切なデフォルトや属性を設定し、Selectionなど他の型との使い分けをすることで、保守性の高いOdoo設計ができます。
適切に使われたブールはエンドユーザーにとって“何も考えずに使える”存在になります。誤った使い方をすると混乱や例外処理、手作業が増える原因になります。ルールを知り、運用に落とし込むことが重要です。
Dasoloでは、各部門にまたがるOdooの導入・カスタマイズ・最適化を支援しています。クリーンなデータモデル設計やカスタムフィールドの追加、フルモジュールの開発など、お客様の要件に応じたサポートが可能です。 お問い合わせはこちら あなたのOdooプロジェクトについてぜひお話を伺わせてください。