イントロダクション
Odooでは「モデル」がデータベース内のデータ構造を規定します。取引先、商品、注文、あるいはサイト設定のように、業務で扱う情報はすべてモデルに保存されます。
モデルを理解することは開発者だけでなく、機能担当者にとっても不可欠です。モデルがフィールド定義や関連（リレーション）、業務ルールの土台となり、Odoo全体のデータ設計を支えます。
本稿はウェブサイトモデルに焦点を当てます。サイトの設定や見た目を管理する中核であり、マルチサイト運用、ブランディング、外部連携など、サイトに関わるあらゆる作業で関わるモデルです。
ウェブサイトモデルとは何か
ウェブサイトモデルは、サイトの振る舞いや見た目を定義する設定情報を保持します。ドメイン、対応言語、ブランドロゴ、SNSリンク、メニュー構造など、サイトを成り立たせる要素がここに格納されます。
このモデルはWebsiteアプリの一部で、複数サイトを運用する場合はサイトごとにレコードを持ちます。各サイトは個別のドメインや会社、言語、テーマを指定できます。
多くの他のモデルはwebsite_idフィールドでこのウェブサイトモデルを参照します。ページ、ブログ、製品などにサイト固有の情報を紐づけることで、データを正しいサイト領域にスコープできます。
モデルで重要なフィールド一覧
ここからはウェブサイトモデルで頻繁に使う主要フィールドを紹介します。どのフィールドが何を制御するかを把握すれば、設定やカスタマイズがスムーズになります。
1. name（サイト名）
型: Char（必須）。ウェブサイトの表示名です。バックエンドのサイト切替や設定画面に表示され、サイトの識別子として使われます。
2. sequence（表示順）
型: Integer。デフォルトは10。複数サイトがある際の並び順を制御します。値が小さいほど先に表示されます。
3. domain（ドメイン）
型: Char。サイトのドメイン（例: https://www.example.com）。Odooはhttpsを補完します。ユニーク制約があり、ルーティングやSEOに利用されます。
4. company_id（会社）
型: Many2one (res.company)。必須。サイトを特定の会社に紐づけます。マルチカンパニー環境では、その会社に関連するデータのみを表示します。
5. language_ids（対応言語）
型: Many2many (res.lang)。そのサイトで利用可能な言語一覧。訪問者は言語を切り替えられます。通常はインストール済みの言語がデフォルトで入ります。
6. language_count（言語数）
型: Integer。計算フィールド。利用可能な言語数を保持し、表示やフィルタに便利です。
7. default_lang_id（デフォルト言語）
型: Many2one (res.lang)。必須。訪問者が初めて来たときに表示されるデフォルト言語です。language_idsに含まれている必要があります。
8. auto_redirect_lang（自動リダイレクト）
型: Boolean。デフォルトTrue。有効にすると訪問者のブラウザ言語に基づき自動的に適切な言語ページへリダイレクトします。
9. cookies_bar（クッキーバー表示）
型: Boolean。Trueにするとクッキー同意バナーを表示します。GDPR対応などで有用で、Odooはクッキーポリシーページを自動作成できます。
10. logo（サイトロゴ）
型: Binary。サイトのロゴ画像。ヘッダー等に表示され、未設定時はOdoo標準のロゴが使われます。
11. favicon（ファビコン）
型: Binary。タブに表示されるファビコン。Odooは256x256にリサイズします。
12. social_twitter（Twitter/X）
型: Char。Twitter/XのアカウントURL。会社データからデフォルトを引けます。フッターや共有時に使われます。
13. social_facebook（Facebook）
型: Char。FacebookのアカウントURL。他のSNSフィールドと同様の使い方です。
14. social_linkedin（LinkedIn）
型: Char。LinkedInのアカウントURL。
15. social_instagram（Instagram）
型: Char。InstagramのアカウントURL。
16. social_youtube（YouTube）
型: Char。YouTubeのチャンネルURL。
17. social_github（GitHub）
型: Char。GitHubアカウントURL。
18. social_tiktok（TikTok）
型: Char。TikTokのアカウントURL。
19. social_default_image（共有用デフォルト画像）
型: Binary。SNS共有時に使うデフォルト画像。設定するとロゴより優先され、Open GraphやTwitterカードで利用されます。
20. google_analytics_key（GAキー）
型: Char。Google AnalyticsのトラッキングID。設定するとOdooがトラッキング用スクリプトを挿入します。
21. google_maps_api_key（Maps APIキー）
型: Char。地図表示やロケーション機能で使うGoogle MapsのAPIキー。
22. user_id（公開ユーザー）
型: Many2one (res.users)。必須。このサイトでの公開（匿名）ユーザー。ポータルや匿名アクセスで使われ、会社設定からデフォルトを採ります。
23. cdn_activated（CDN有効化）
型: Boolean。Trueにすると静的アセットをCDN経由で配信し、パフォーマンスを向上させます。
24. cdn_url（CDNベースURL）
型: Char。CDNが有効な場合に使うベースURL。
25. cdn_filters（CDN置換フィルタ）
型: Text。書き換えるURLの正規表現パターン。デフォルトで静的パスが入ります。
26. menu_id（メインメニュー）
型: Many2one (website.menu)。計算フィールド。そのサイトのルートメニューアイテムを指します。
27. homepage_url（ホームパス）
型: Char。ホームページのパス（例: /contactus や /shop）。先頭はスラッシュが必須です。
28. custom_code_head（ヘッドに挿入するカスタムコード）
型: Html。head内に注入するカスタムHTML/スクリプト。解析ツールやメタタグの設定に使います。
29. custom_code_footer（フッターに挿入するカスタムコード）
型: Html。フッターに挿入するコード。チャットウィジェットや追加トラッキングに便利です。
30. robots_txt（robots.txtの内容）
型: Html。カスタムrobots.txtの内容を保持し、クローラ制御やSEOに利用できます。
31. theme_id（テーマ）
型: Many2one (ir.module.module)。インストールされたテーマモジュールを参照します。
32. auth_signup_uninvited（サインアップ方式）
型: Selection。b2b（招待制）か b2c（自由登録）の選択。招待なしでアカウントを作れるかを制御します。
33. create_date（作成日時）
型: Datetime。レコードが作成された日時。Odooが自動管理します。
34. write_date（更新日時）
型: Datetime。レコードが最後に更新された日時。こちらも自動管理されます。
業務フローでの活用例
1. マルチサイト運用とローカライゼーション
複数ブランドや地域を持つ企業はサイトごとにレコードを作ります。各サイトは独自のドメインや言語、コンテンツを持ち、ページや商品はwebsite_idで正しいサイトに紐づけられます。
2. ブランディングとアイデンティティ管理
ロゴやファビコン、SNSリンクはサイト単位で設定します。リブランディングやキャンペーン時にはマーケティングチームがこれらを更新します。共有時の見え方を整えるためにsocial_default_imageを活用すると効果的です。
3. 言語対応とSEO対策
language_idsやdefault_lang_idで対応言語を制御します。auto_redirect_langを有効にすると多言語ユーザーのUXが向上し、hreflangやSEO面でも適切に振る舞わせることができます。
4. パフォーマンス対策とCDN活用
トラフィック増加時はcdn_activatedとcdn_urlで静的ファイルをCDNへ移行して負荷軽減します。cdn_filtersでどのパスを置換するかを細かく制御できます。
5. コンプライアンスと解析ツール
cookies_barで同意バナーを出し、google_analytics_keyやcustom_code_headで解析ツールを挿入します。robots_txtでクローラの挙動を制御するのも重要です。
開発者がモデルを拡張する方法
開発者はOdooの継承パターンを使ってウェブサイトモデルを拡張します。標準の仕組みを壊さずに機能追加やカスタムロジックを実装するのが基本です。
モデル継承の考え方
モデルを拡張する際は _inherit = 'website' を使います。新しいフィールドを追加したり、メソッドをオーバーライドしたり、独自の制約を定義できます。拡張はモジュールとして切り出すことで将来のアップグレードを容易にします。
フィールド追加のポイント
拡張モデルに新しいフィールドを定義する際は適切な型（Char, Many2one, Boolean, Integer, Text, Selection）を選びます。マルチサイト対応が必要ならウェブサイト依存の設計を検討してください。
Python側の拡張
create、write、unlinkなどのメソッドをオーバーライドして業務ロジックを差し込めます。既存処理を残すためにsuper()で親処理を呼び出すことを忘れないでください。API経由でサイトを作る場合は user_id や company_id の取り扱いに注意が必要です。
Odoo Studioの活用
Odoo Studioを使えばコードを書かずにフィールド追加ができます。素早い試作には便利ですが、複雑なロジックやAPI連携がある場合はモジュールとして実装した方が保守性が高くなります。
実務でのベストプラクティス
- 本番では各サイトに正しいドメインを設定してください。ルーティングとSEOに直結します。
- default_lang_idは必ずlanguage_idsの中に含めること。Odooはこの整合性を検証します。
- 外部スクリプトはcustom_code_headやcustom_code_footerに入れるのが安全です。コアテンプレートを直接編集するのは避けましょう。
- API連携を作る場合はXML-RPCやJSON-RPCを利用します。websiteモデルはAPIで操作可能なので、コンテンツ同期時には website_id を正しくマッピングしてください。
- カスタムフィールドの命名は x_ プレフィックスやモジュール固有プレフィックスを付けて、将来のOdooバージョンとの名前衝突を避けましょう。
よくあるミスと落とし穴
- ドメインを重複して作成すること。domainフィールドにはユニーク制約があるため、重複はエラーになります。
- APIでサイトを作る際に user_id を設定し忘れること。公開ユーザーは必須項目です。
- homepage_url を先頭スラッシュなしで設定すること。Odooはバリデーションでエラーを出します。
- cdn_activated を有効にしたのに有効な cdn_url を設定していないこと。アセットが読み込めなくなる可能性があります。
- 親処理を呼ばずにコアメソッドをオーバーライドすること。super()を呼ばないと他モジュールや将来のアップデートで問題が発生します。
まとめ
ウェブサイトモデルはOdooにおけるサイト設定の要です。ドメイン、言語、ブランディング、挙動に関する情報を保持し、他モデルからの参照を通じてサイト単位のデータ分離を実現します。これを理解すれば設定・カスタマイズ・連携が効率的になります。
機能担当者がマルチサイト要件を整理するにせよ、開発者がカスタムモジュールを作るにせよ、ウェブサイトモデルを正しく理解していることが工数削減とトラブル回避につながります。
Odoo導入でお困りですか？
Dasoloは企業のOdoo導入、カスタマイズ、最適化を支援します。API連携や開発を得意とし、データ設計やモデル周りの豊富な経験を持つチームが対応します。
Odooの導入やマルチサイト設定、各種連携でお困りなら、お気軽にご相談ください。 デモを予約する プロジェクトについてご相談しましょう。