はじめに
Odooでは、データの構造と保存方法を“モデル”で定義します。受注や請求書、取引先など、業務で扱うほぼすべてのデータはモデルとしてデータベースに保管されます。
モデルの仕組みを理解することは、開発者だけでなく業務コンサルタントにとっても不可欠です。モデルがフィールドや関連、業務ロジックの基盤となり、システム全体の振る舞いを決めます。
では、システム内のすべてのモデル情報はどこに格納されているのでしょうか。答えは ir.model です。これは各モデルのメタデータを管理するレジストリであり、カスタムモジュール作成やAPI探索、トラブルシューティングの際に必ず触れる中心的な存在です。
ir.model とは何か
ir.model は Odoo のモデル定義を記録するメタデータテーブルで、システム内の各モデルごとに1レコードを持ちます。Pythonで新しいモデルを定義したり、Odoo Studioでモデルを作ると、自動的に対応する ir.model レコードが作成／更新されます。
このモデルは base モジュールの一部で、Odooコアの中核を成しています。通常モデル、抽象モデル、トランジェントモデルいずれであっても、それぞれに対応する ir.model のエントリが存在します（注：抽象モデルはデータベーステーブルを持たないため例外あり）。
ir.model は ir.model.fields と密接に関連しています。後者は各フィールドのメタ情報を持つため、両者を合わせて参照することで Odoo のリフレクション（自己点検）機能が成り立ちます。
開発者は利用可能なモデル一覧を取得したり、継承関係を確認したり、任意のモデルに汎用的に対応するツールを作る際に ir.model を参照します。外部からは XML-RPC や JSON-RPC 経由で情報を引き出せます。
モデルに含まれる主要なフィールド
ここからは、ir.model に含まれる主要フィールドをご紹介します。これらを押さえておくとレジストリ操作がスムーズになります。
1. name
タイプ: Char。モデルの人が読むための名称です。多言語化され、管理画面や開発者向けツールでラベルとして表示されます。
2. model
タイプ: Char。開発で使う技術名（例: res.partner や sale.order）。必須かつインデックス付きで、高速検索に適しています。
3. info
タイプ: Text。モデルに関する追記やメモを保存するフィールドです。ドキュメント用途で使われ、空欄のことも多いです。
4. state
タイプ: Selection。モデルの出所を示します（base = モジュール由来、manual = Studioや手動作成）。base は保護され、manual は編集の自由度が高い、といった区別になります。
5. transient
タイプ: Boolean。True の場合はトランジェント（一時）モデルを示します。ウィザードや一時データに使われ、定期的にクリーンアップされます。
6. field_id
タイプ: One2many (ir.model.fields)。そのモデル上に定義されたすべてのフィールドを一覧化した関係です。各レコードはフィールド名や型、属性を説明します。
7. access_ids
タイプ: One2many (ir.model.access)。モデルに対するアクセス権一覧です。どのグループが作成・閲覧・更新・削除できるかが定義されます。
8. rule_ids
タイプ: One2many (ir.rule)。レコード単位のフィルターとなるルール群です。ユーザーが参照できる行を制限するために使われます。
9. inherited_model_ids
タイプ: Many2many (ir.model)。モデル継承の親モデルを示す関係です。継承を使うとここに親モデルがリンクされます。
10. modules
タイプ: Char。そのモデルが定義されているモジュール名を列挙した計算フィールドです。複数モジュールで拡張される場合は全モジュールを表示し、依存関係の把握に役立ちます。
11. sort
タイプ: Integer。テクニカル設定メニューなどでの表示順を決める値です。小さいほど先に表示されます。
12. constrains
タイプ: Text。@api.constrains デコレータで定義された Python レベルの制約コードを格納します。モデル固有のバリデーションがある場合に利用されます。
13. post_constrains
タイプ: Text。バリデーション後の追加チェック用コードを記録します。高度な検証ロジックで使われます。
14. sql_constraints
タイプ: Text。一意制約など、データベース側で保証する SQL 制約を定義します。データ整合性を強制するための重要な項目です。
15. view_ids
タイプ: One2many (ir.ui.view)。そのモデルに関連するビュー一覧を計算して返すフィールドで、ビュー管理や調査に便利です。
16. record_count
タイプ: Integer。当該モデルに格納されているレコード数を示す計算フィールド。データ量の目安やレポートに使えます。
17. display_name
タイプ: Char。画面表示用に整形された名称です。通常は name と model の組み合わせなどで生成され、リレーション表示に用いられます。
18. create_date
タイプ: Datetime。レコード作成日時。Odoo が自動で管理します。
19. create_uid
タイプ: Many2one (res.users)。レコードを作成したユーザー。監査・履歴確認に役立ちます。
20. write_date
タイプ: Datetime。最終更新日時。こちらも自動管理されます。
21. write_uid
タイプ: Many2one (res.users)。最終更新を行ったユーザー。変更履歴確認に必要です。
22. active
タイプ: Boolean。ソフトデリート用フラグ。False にするとアーカイブされ、非推奨モデルの管理に使われます。
23. id
タイプ: Integer。データベース上のユニークIDで、APIなどでモデルを参照するときに使います。
24. restrict_functionality
タイプ: Boolean。一部エディションで機能制限がかかるモデルを示します。Enterprise と Community の差分管理に関係します。
25. is_mail_thread
タイプ: Boolean。そのモデルが chatter（メッセージ機能）を持つかどうかを示します。フォロワーやメッセージ履歴が必要なモデルに True になります。
26. is_mail_activity
タイプ: Boolean。そのモデルがアクティビティ（次のアクション）機能をサポートするかを示します。営業リードやタスク管理などで使われます。
業務フローでの利用例
1. テクニカル設定と構成管理
管理者はテクニカル設定メニューからモデルを閲覧します。ir.model のレコードが一覧表示を構成し、モデル名や説明、フィールド数などが確認できます。
2. アクセス権管理
セキュリティ設定では、管理者がグループごとの権限を割り当てます。ir.model の access_ids が、作成・閲覧・更新・削除の許可を決めます。
3. Odoo Studio によるカスタマイズ
Odoo Studio でカスタムモデルを作ると、state が manual の ir.model レコードが作成され、field_id にカスタムフィールドが紐づきます。コードを書かずにモデルを追加できます。
4. API と統合でのモデル発見
外部システムは XML-RPC や JSON-RPC を通じて ir.model を照会し、利用可能なモデルやその構造を自動検出できます。統合ツールはこれを使って柔軟に連携を組みます。
5. モジュール開発とデバッグ
開発者はモジュール作成時に ir.model を参照して継承関係（inherited_model_ids）やフィールド一覧（field_id）を確認します。デバッグや依存関係解決で重宝する情報源です。
開発者による拡張方法
通常、開発者が ir.model 自体を直接拡張することは稀です。新しいモデルを定義すればレジストリは自動更新されるため、通常は ir.model を操作する必要はありません。
モデルの継承
Python側で _inherit = 'res.partner' のように継承を宣言すると、Odoo は res.partner の ir.model レコードや継承チェーンを更新します。これにより親子関係がレジストリへ反映され、継承の管理が可能になります。
フィールドの追加
モデルに新しいフィールドを追加すると、対応する ir.model.fields レコードが作成され、model_id で ir.model に紐づきます。ir.model 本体そのものは通常変更されません。
Pythonでの拡張
ir.model のメソッドを上書きするのは一般的ではありません。コアの一部として振る舞うため、カスタマイズが必要な場合は ir.model が示すモデル側を拡張するのが正しいアプローチです。
Odoo Studio の挙動
Studio を使うと、コードを書かずに ir.model と ir.model.fields が生成されます。transient フラグにより一時モデルと通常モデルを区別できます。抽象モデル（データベーステーブルを持たない設計）は ir.model レコードを作らない点に注意してください。
ベストプラクティス
- 統合を作る際は、モデル名をハードコーディングせず ir.model を参照して利用可能なモデルを列挙するのが安全です。変更に強い実装になります。
- 特定モデルを探す際は model フィールドで検索しましょう。インデックスが張られているため高速です。
- カスタムモジュールを作る前に inherited_model_ids を確認し、継承チェーンを把握してから拡張することを推奨します。
- 外部から ir.model を読む場合は Odoo の公開API（XML-RPC/JSON-RPC）を使って取得してください。Studio のようなツールを作るのでなければ直接編集は避けましょう。
- フィールド単位の調査が必要なときは ir.model.fields を参照します。field_id 関係でそのモデル上のすべてのフィールド情報を取得できます。
よくある誤り
- ir.model レコードを直接書き換えるのは危険です。レジストリは Odoo 本体が管理しており、手動変更はシステム障害やアップグレード時の上書きにつながる可能性があります。
- ir.model を Python のモデルクラスと混同しないでください。ir.model はデータベース上のメタデータレコードであり、Python クラスは実際のビジネスロジックを持つ実体です。役割は関連しますが別物です。
- 全てのクラスに ir.model レコードがあると誤解しないでください。抽象モデルはテーブルを持たず、ir.model エントリを生成しないことがあります。
- トランジェントモデルが永続データに向かない点を忘れないでください。transient フラグが付いているとデータは定期的に削除されます。長期保存には向きません。
- ir.model を無差別にクエリしないでください。標準インスタンスには数百のモデルが存在するため、モデル名やドメインで絞り込んで検索することが重要です。
まとめ
まとめると、ir.model は Odoo の全モデルを記録するレジストリで、各モデルのメタデータを保持します。ir.model と ir.model.fields の関係を理解すると、Odoo のデータ構造を効率的に把握できます。
テクニカル設定を扱うコンサルタントから API 統合を作る開発者まで、ir.model を正しく理解しておくと作業工数を減らし、ミスを防げます。
Odoo導入のサポートが必要ですか？
Dasolo は企業の Odoo 導入・カスタマイズ・最適化を支援します。API 統合やカスタム開発を得意とし、ir.model を含む Odoo のデータ設計に関する豊富な経験を持っています。
Odoo の導入やカスタムモジュール、外部連携でお困りなら、お手伝いします。 デモを予約する プロジェクトについてご相談ください。