イントロダクション
もしあなたがOdooで商品写真をアップロードしたり、会社ロゴを設定したり、社員の顔写真を登録したことがあれば――それはすでにImageフィールドを操作した経験があります。見た目に関わる代表的なフィールドであり、思っている以上に多くの画面や処理で使われています。
エンドユーザーにとっては単純な操作に見えますが、コンサルタントや開発者の視点では内部でいくつか重要な処理が行われています。Imageフィールドは保存方法、サイズ調整の挙動、アクセス制御などを内包しているため、カスタムモデルへ追加する前に仕組みを理解しておくと後で役立ちます。
このガイドでは、Imageフィールドが何を保存するのか、Odooフレームワーク内でどのように振る舞うのか、Odoo StudioやPythonでの追加方法、そして実務での利用例をわかりやすく説明します。
OdooにおけるImageフィールドとは何か
ImageフィールドはOdooのORMで専用の型として用意されており、Odoo 13以降は fields.Image がその役割を担います。それ以前は fields.Binary に画像ウィジェットを組み合わせて実装するのが一般的でした。現在の型は画像のライフサイクル（保存時のリサイズなど）を自動的に処理します。
内部的には、画像データはbase64でエンコードされたバイナリとして扱われます。保存先はデータベースのbyteaカラムではなく、現行構成では多くの場合ir.attachmentによる添付ファイルとして管理されます。添付ファイル化することで主テーブルの肥大化を防ぎ、専用のURL経由で効率的に配信できます。
画面上の見え方のポイント
フォーム画面では、Imageフィールドはクリック可能なプレースホルダとして表示されます。ローカルファイルのアップロードや一部ケースでURL貼り付けが可能で、フォーム上でサムネイルが確認できるため視覚的に識別しやすくなります。
一覧画面ではサムネイル表示は必要最低限に留めるのが一般的です。リストで多くの画像を読み込むと表示が遅くなるためですが、カード型レイアウト（カンバン）では小さな写真が視認性を高めるため有効に使われます。
フィールド型の違い：ImageとBinary
Binary型は任意のファイル（PDFやZIPなど）を扱う汎用フィールドです。一方でImage型は画像専用で、保存時の自動リサイズや画像固有のバリデーション、デフォルトでの適切なレンダリングを持ちます。写真やロゴはImage、その他ファイルはBinaryが適切です。
フィールドの内部動作の概要
ユーザーがImageフィールドに画像をアップロードすると、ただそのまま保存されるわけではなく、Odoo側で前処理が行われます。
自動的なリサイズについて
fields.Image は max_width と max_height を受け付けます。アップロードされた画像がこれらを超える場合、縦横比を維持して自動でリサイズされます。保存時に透過的に実行されるため、ユーザー側で操作を意識する必要はありません。
標準的なImageフィールドは、長辺を1920ピクセルに制限するのがデフォルトです。これが理由で、標準モデル（例：product.templateやres.partner）では image_1920 という名称のフィールドがよく使われます。
複数サイズの運用パターン
組み込みモデルでは、メインの画像に対して image_1920、image_1024、image_512、image_256、image_128 のような関連フィールドが並んでいることが多いです。これらは主画像に紐づく related フィールドで、表示用途ごとにサイズ上限が異なります。
この設計により、表示コンテキストに応じて最適なサイズを配信できます。一覧ページやカード表示には小さいサムネイル（例：128px）を、商品詳細や大きなプレビューにはフルサイズ（1920px）を使う――という使い分けです。カスタムモデルでも同様の方針が必要かどうかは、表示先と頻度を見て決めましょう。
添付ファイルとしての保存形態
Imageフィールドは通常、ir.attachmentとしてデータを保持します。つまりバイナリ本体はレコードの直接カラムではなく添付モデル側に保存され、レコードはその参照を持ちます。
この仕組みはテーブルサイズを抑え、画像へは予測可能なURL（例：/web/image/product.template/42/image_1920）でアクセスできるという利点があります。ウェブサイトやメールテンプレート、APIレスポンスでもこの形式が使われます。
アクセス制御の取り扱い
画像の取得はレコードの読み取り権限に従います。ユーザーに対象レコードの参照権限がなければ画像も取得できません。ポータルや公開ページで画像を扱う際は、このセキュリティ挙動を考慮する必要があります。
業務での具体的な活用例
Imageフィールドが使われる代表的なモジュールと用途
1. 商品カタログ（販売・在庫）
商品の画像はOdooで最も目立つ用途のひとつです。各商品テンプレートに image_1920 があり、ウェブショップ、受注書PDF、POS画面、モバイルでのピッキング画面など多くの場所で使われます。
大規模カタログを扱う企業は、UIから一つずつ追加するよりAPI経由で一括登録することが多いです。Imageフィールドはbase64での受け渡しに対応しているため、XML-RPCやJSON-RPCを使った自動化が容易です。
2. 取引先・仕入先のロゴ（CRM・購買）
res.partner には連絡先写真や会社ロゴ用のImageフィールドがあります。フォームやチャッター、CRMのカンバンで表示され、営業チームが顧客一覧を視覚的に把握するのに役立ちます。
3. 社員写真（人事）
hr.employee は社員の顔写真を保持します。社内ディレクトリや場合によっては給与明細、またOdoo内のメッセージ横に表示されるなど、オンボーディング時に大量インポートされることがよくあります。
4. 設備や資産の写真（保守）
保守モジュールでは設備レコードに写真を添付できます。現場技術者がメンテナンス前に対象機器を写真で確認できれば、誤修理の防止や効率化につながります。
5. 検査・品質フォームへの実装
品質チェックや現地検査、配達確認といったカスタムモデルにImageフィールドを追加すれば、現場担当者が証拠写真を記録できます。Odoo StudioやPythonコードのどちらでも追加可能で、実務上よく使われるパターンです。
フィールドの作成とカスタマイズ方法
Imageフィールドの追加方法は大きく分けて2つあります：コードを書かないOdoo Studioと、より柔軟なPython開発です。
Odoo Studioでの追加手順
Odoo Studioはノーコードでカスタマイズできるツールです。追加したいアプリを開き、画面上部からStudioを有効化して、フィールドを置きたいフォームへ移動します。
左側のフィールドパネルからImageフィールドをドラッグしてフォームへ配置すると、ラベル名を求められ、モデル上に自動でフィールドが作成されます。開発者を介さずにフィールドを追加したい業務担当者や機能コンサルタントには最適な方法です。
Studioで作られたフィールドは慣例的に x_studio_ プレフィックスが付きます（例：x_studio_site_photo）。実運用上はネイティブのImageフィールドと同等に振る舞います。
Pythonでの実装（開発者向け）
コードで制御したい場合は、Pythonのモデル定義ファイルに直接Imageフィールドを定義します。柔軟な設定や関連フィールドの作成が可能です。
例としてカスタムモデルにImageフィールドとサムネイルを追加する典型的なコード例は次のようになります：
from odoo import models, fields
class SiteInspection(models.Model):
_name = 'site.inspection'
_description = 'Site Inspection'
name = fields.Char(string='Reference', required=True)
photo = fields.Image(
string='Site Photo',
max_width=1920,
max_height=1920,
)
photo_128 = fields.Image(
related='photo',
max_width=128,
max_height=128,
store=True,
string='Thumbnail',
)
この例は、フルサイズの保存と同時に小さなサムネイルを関連フィールドで保持する標準的なパターンを示しています。
上記の max_width / max_height 指定により、保存時に1920ピクセルを上限にリサイズされます。関連フィールドの photo_128 はカンバンや一覧表示向けの小さい画像を保持するために使います。
ビューへの追加方法
モデルにフィールドを追加したら、表示させるためにビューへ組み込む必要があります。フォームのXMLでは widget="image" を使ってImageフィールドを描画します。
例：
<field name="photo" widget="image" class="oe_avatar"/>
oe_avatar クラスを付けるとフォーム左上に丸いアバター位置で表示され、Odoo標準の見た目になります。クラスを外せばフォーム中に通常のブロック要素として埋め込むこともできます。
導入時のベストプラクティス
クライアントに勧める運用上の注意点
現実的なサイズ上限を設定する
デフォルトの1920pxは多くの用途で妥当です。印刷用など特別なケース以外はこれを安易に上げないほうが良いです。大きな画像は添付サイズを増やし、データベースやページ表示速度に影響します。
一覧やカンバン用にサムネイルを用意する
一覧やカンバンで画像を使うなら、128pxまたは256px程度の小さいrelatedフィールドを用意しましょう。各行で1920pxを読み込むのは遅く、ページ体験が悪化します。
大量アップロードはAPIで自動化する
何百〜何千件の画像を投入する必要がある場合、UIから手作業で行うのは避けてください。XML-RPCやJSON-RPCでbase64エンコードした画像を一括投入するスクリプトを使うと効率的です。
アップロード前に画像を圧縮する
Odooはリサイズを行いますが、高圧縮までは常に実施しません。例えば5MBのJPEGを1920pxに縮小しても数百KB残ることがあります。事前に圧縮しておけば添付ファイルの総容量を抑えられます。
頻繁に検索されるリストビューにはImageを置かない
一覧表示のカラムにImageを直接入れると、その行のバイナリ取得が増えてリストが重くなります。本当に必要なら小さなサムネイルに限定し、フルサイズはフォームで管理するのが賢明です。
よくある落とし穴と回避策
導入時に多く見られるミス
BinaryとImageを混同する
Binary型を単に追加すると、ビュー上ではダウンロードボタンとして表示されるだけで画像プレビューにはなりません。画像表示を期待するなら fields.Image を使うか、Binaryに widget="image" を明示的に指定する必要があります。特に古いバージョンでの混乱が目立ちます。
画像サイズの戦略を後回しにする
最初に大きなImageフィールドだけを作るのは簡単ですが、後から一覧用の小さい画像が必要になった場合、カスタムモジュールだとデータベース移行が必要になることがあります。導入時に表示用途を洗い出しておくと後の手間を減らせます。
添付ではなく本体に直接保存してしまう
古い設定や不適切な構成でバイナリがレコードカラムに直接入ると、メインテーブルが肥大化してクエリ性能が劣化します。添付ファイルやS3互換ストレージを使う設定を確認してください。
画像フィールドをドキュメント保管に使ってしまう
スキャンした書類や複数ページの文書をImageフィールドに入れるのは適切ではありません。ドキュメント管理には Odoo Documents モジュールやBinary型（ダウンロード用途）を使いましょう。Imageは写真・ロゴ用途に最適化されています。
公開ページでアクセスルールを忘れる
公開サイトやポータルで画像URLを表示するとき、元のレコードが公開アクセスできないと404になります。ウェブ公開・ポータル向けの設計時は画像の公開可否を必ず確認してください。
まとめ
Imageフィールドは表面的には扱いやすい反面、設計を誤ると運用で困る点が出てきます。リサイズの仕組み、添付ファイルとしての保存、複数サイズを用意するパターンを理解しておけば、カスタムモデルや標準モデルの設定で余計な手戻りを避けられます。
業務担当者は画像がレコードに安全に保存され、予測可能なURLで利用できることを知っておくとウェブ公開やポータル構築がスムーズになります。開発者は fields.Image と関連サムネイルの組み合わせを標準パターンとして早めに習熟すると効率的です。
商品写真の登録、現地検査での証跡添付、顧客ポータルでのロゴ表示など、ImageフィールドはOdoo内で視覚情報を一貫して扱うためのシンプルで統合的な手段を提供します。
Odoo導入のサポートが必要ですか？
私たちDasoloは、Odooの各モジュール・各バージョンについて実装・カスタマイズ・最適化の支援を行っています。標準モデルのフィールド調整、スクラッチでのモジュール開発、または既存システムからのデータ移行など、業務に即した形でOdooを稼働させるために伴走します。
もしOdooの構成について疑問がある、あるいはプラットフォームで何が可能かを相談したい場合は、 ぜひお問い合わせください。喜んでサポートいたします。