はじめに
Odooでフォーム保存時に入力欄が赤くなったことがあるなら、それが「必須フィールド」の働きです。データの欠損を防ぐ最も基本的な仕組みの一つで、業務プロセス全体のデータ品質を底上げします。
営業チームの設定、独自モデルの追加、あるいは開発案件のどの段階でも、required相当の扱い方を知っておくと仕組みが安定します。
この記事では、Odooの仕組み上での振る舞いや、Odoo Studio・Python両面での設定方法、適用すべき場面、注意点までを一通り解説します。
Odooでの「必須フィールド」とは何か
Odooにおける「必須」はフィールド単位の制約で、値がなければレコードを保存できません。文字列や数値、選択、Many2one、日付など、ほぼすべてのフィールド種別に適用できます。
コアのデータモデルに組み込まれる一般的な属性で、カスタマイズ時に真っ先に使われることが多いです。必須にすることでデータの欠落や矛盾を未然に防げます。
画面上での見え方
画面では任意フィールドと差別化され、編集モードで視覚的な目印が表示されます。入力せずに保存しようとすると欄が赤くなり、エラーメッセージで教えてくれます。
この即時フィードバックによりユーザーはその場で問題を認識し、未完成のまま提出してしまうリスクが大きく下がります。
固定必須と条件付き必須の違い
必須にする方法は大きく二つあります。常に必須にする「固定必須」と、他の項目の値に応じて必須になる「条件付き必須」です。
どちらを使うかは業務ロジック次第で、状況に応じて使い分けるのが一般的です。
必須フィールドの仕組み
技術的な振る舞いを理解しておくと、設定ミスの発見や問題解決が速くなります。
アプリケーション層での検証
多くの利用者が見落とす点ですが、Odooの必須チェックは「アプリケーション層」で行われます。つまり、OdooのORMがレコード作成・更新時にPython側で検証を行い、その時点でブロックされます。
標準ではPostgreSQLの列に自動でNOT NULL制約が付与されるわけではありません。検証はORM内部のPythonロジックで実行されます。
そのため、直接データベースに値を書き込むと必須制約をすり抜ける可能性があります。ORMやAPI経由でデータ操作を行う運用を徹底してください。
制約違反が起きたときの挙動
フォームを保存しようとして必須項目が空の場合、UIと処理の両面で動作が起きます。
- 画面上で該当フィールドが赤くなり、バリデーションメッセージが表示される
- 保存処理はフィールドが埋まるまで停止される
APIやサーバー側で処理した場合は、どのフィールドが足りないかを示すValidationErrorが発生します。
ビュー側での条件付き必須設定
条件付きで必須にする場合、ビュー側の式で制御できます。従来のバージョンではビューXMLのattrsで表現していました。
例えば、配送タイプが配送のときだけ配達日を必須にするような条件が典型例です。
新しいバージョン以降ではビュー定義がより読みやすくなり、直接的な式で指定できるようになりました。
そのための書き方はバージョン依存ですが、基本はビュー層で条件を評価する点が共通しています。
重要なのは、こうした条件付き必須はビュー層に紐づく制約だということです。モデル定義のrequired=Trueは常に強制されますが、ビュー側の条件はそのビューを経由したときだけ有効です。
ORMやAPIとの相互関係
ORMでcreate()やwrite()を呼ぶとき、モデルに定義されたrequired=Trueのチェックが入ります。値が無い、またはFalseならValidationErrorが発生し、DB操作は実行されません。
XML-RPCなどAPI経由でレコードを作る場合も同様です。モデル定義で必須としたフィールドはデータ辞書に含める必要があります。含めないとエラーになります。
業務での具体的な活用例
実務で役立つ必須フィールドの例
1. CRM：リードに顧客セグメントを必須化
営業がリード登録時にセグメント指定を後回しにしがちだと、後でセグメント別の分析が不完全になります。
リードフォームのカスタム選択フィールドを必須にすることで、登録時点でセグメント情報を確実に取得できます。
2. 営業：受注に配達先住所を必須化
物品を出荷する企業では配達先住所が欠くことのできない情報です。標準設定で必須になっていない場合、受注確定前に住所がないケースが発生します。
受注フォームで配達先を必須にすれば、ロジスティクスに必要な情報が揃わないまま処理が進む事態を防げます。
3. 在庫：入荷時にロット／シリアル番号を必須化
医薬品や食品、精密機器などトレーサビリティが求められる業種では、入庫時にロット番号を確実に取得する必要があります。Odooのトラッキング機能でこれを担保できます。
入荷フォームのカスタム項目を必須にすることで、倉庫担当が受領時に確実に記録するよう促せます。
4. 会計：仕入請求書でコストセンターを必須化
費用を予算管理上のコストセンターに紐付けたい場合、必須化しないと空白が増え、会計報告に穴が空きます。
請求書フォームにMany2oneでコストセンターを必須にしておけば、仕訳や集計の精度が高まります。
5. 人事：入社前に雇用契約タイプを必須化
入社手続きの忙しい時期に契約種別が抜け落ちると、後工程での手戻りが増えます。社員フォームで契約種別を必須にすることで、記録の抜けを防げます。
必須フィールドの作成・カスタマイズ方法
必須にする方法は大きく二つ：ノーコードのOdoo Studioと、自由度の高いPython定義です。状況に応じて選びます。
Odoo Studioを使う場合
Odoo Studioはコード不要でフォームを編集できるツールです。フォーム上のフィールドを選ぶと、プロパティに「必須（Required）」トグルが表示されます。
このトグルをONにするとビュー側で必須が設定され、手早く導入できます。標準フィールドでもカスタムフィールドでも簡単に扱えます。
ただしStudioは基本的にビュー側の固定設定を作るだけなので、条件付き必須のような複雑な制御はビューXMLやコードで対応する必要があります。
開発者向け：Pythonで定義する方法
カスタムモジュールでフィールドを定義する際は、フィールド定義にrequired=Trueを付けるだけでモデルレベルの必須になります。これはOdoo開発では一般的なパターンです。
（例示的なフィールド定義を示す）
モデルレベルで必須にすると、どのビューやAPIから作られたレコードでも強制されます。ビューを迂回して決してバイパスできない点が利点です。
ビューXMLで動的に必須化する方法
特定条件でのみ必須にしたい場合はビュー側で指定します。古いバージョンと新しいバージョンで書き方に差はありますが、要旨は同じです。
たとえば、請求の種類が特定値のときだけコストセンターを必須にする、といったケースが該当します。
バージョン差異のある記法に注意しつつ、ビューに条件式を書き込むことで動的な必須化を実現できます。
最新のビュー定義ではより直感的な式が使えるようになっています。
しかしこれはビュー限定の制約であり、API経由や別のビュー経由では適用されないことに注意してください。
API経由で必須フィールドを作成する場合
ir.model.fieldsをAPIで生成する際にrequiredを設定できます。自動化されたデプロイやスクリプトでフィールドを作る場合に有効です。
（API呼び出し例を示す）
この方法だとフィールド作成と必須設定を一度に実行でき、運用上の自動展開に便利です。
運用上のベストプラクティス
必須フィールドは単純に見えて運用面での配慮が必要です。ここでは実務で役立つポイントを挙げます。
1. 本当に必須かどうか慎重に判断する
過剰に必須を付けると、ユーザーは入力できない場面でダミー値を入れるなどの回避策を取りがちで、データの質を落とします。
入力時点で常に値が確実に揃うかを検討し、難しい場合は作成時ではなく確定時に必須にする、あるいは条件付きにすることを検討しましょう。
2. ステージベースのバリデーションを活用する
CRMや製造といった複数工程のワークフローでは、すべてを最初から必須にするより、特定のステージに到達したときにチェックする方が現実的です。Pythonの制約や自動アクションで実装するのが一般的です。
このやり方はユーザーフレンドリーで運用負荷を下げます。
3. 妥当なデフォルトと組み合わせる
大半のケースで妥当な初期値があるなら、フィールドにdefaultを設定しておくとユーザーの手間が減りつつ必須を確保できます。
4. 重要データはモデルレベルで強制する
会計情報や法律上必須の識別子などは、ビューだけでなくモデル定義で必須にするべきです。ビューだけだとAPIや別ビューで簡単に回避されます。
5. 利用者への周知を忘れない
既存フォームに必須項目を追加すると、途中の作業が止まる可能性があります。変更は事前にチームへ通知し、影響を受ける既存レコードについては案内を行いましょう。
6. 空や不完全なデータで必ずテストする
導入前には空欄や部分的なデータでの保存・API・連携処理のテストを行ってください。これが安心して展開するための基本です。
よくある落とし穴と対処法
経験者でも必須フィールドで悩むことはあります。代表的な注意点を事前に把握しておくとトラブルシュートが速くなります。
落とし穴1：既存レコードが多数あるモデルで後から必須にする場合
既存レコードに値が入っていないフィールドを後付けで必須にすると、次回更新時に保存できなくなり大混乱になります。
導入前に既存データの有無を確認し、必要ならデータ移行で値を埋めてから制約を適用してください。
落とし穴2：ビューとモデルの必須を混同すること
ビューで必須にしてもモデルレベルの制約にはなりません。API経由や別ビューからは回避されるので、厳格に守る必要がある項目は必ずモデル定義で必須化しましょう。
多くの現場で誤解されがちなポイントで、放置するとデータ品質の問題につながります。
落とし穴3：自動化処理が必須項目に対応していない
バッチや自動アクションがレコードを生成する場合、必須フィールドに値を渡すようコードを更新しないと処理が失敗します。
既存の自動処理は、必須を追加した後に必ず見直してください。
落とし穴4：インポート時に必須項目が抜けている
CSVなどでインポートする場合、必須フィールドが欠けているとインポートは失敗します。これは仕様どおりですがユーザーが驚きやすい点です。
インポートテンプレートに必須項目を明記し、ドキュメント化しておくことを推奨します。
落とし穴5：複雑な検証を必須だけで代替しようとする
必須は空でないかのチェックにしか使えません。将来日付であることや複数フィールドの整合性など、複雑な検証は@api.constrains等のPython制約で実装すべきです。
必須だけで業務ロジックを無理に表現すると、保守性の低い設計になります。
まとめ
まとめると、必須フィールドはOdooの基本ツールでありながら、データ品質に大きな影響を与えます。適切に使えば重要情報を確実に取得できますが、乱用すればユーザーの回避策や運用上の障害を招きます。
ポイントは、モデルレベルとビュー層の違いを理解し、本当に必要な項目だけを厳格化し、自動処理やAPI連携での挙動まで見越して設計することです。
Odooの開発ガイドやカスタマイズ作業、あるいはStudioでの設定いずれでも、必須属性をきちんと理解しておくことが長期的な安定運用につながります。
Odoo導入のサポートが必要ですか？
私たちDasoloは、Odooの設計、カスタマイズ、最適化を支援しています。データモデル設計やバリデーション設計、カスタムモジュール作成など、技術と業務両面の知見でプロジェクトをサポートします。
必須項目についてのご相談や、Odoo全般に関する疑問があればお気軽にご相談ください。 お問い合わせはこちら ぜひお話を聞かせてください。