導入
CharフィールドはOdooのデータモデルで最も基本的なフィールドの一つです。顧客名、商品コード、受注のメモなど、日常的に目にする短い文字列の多くはこのフィールドによって保持されています。
このフィールドの性質を理解することは、Odoo Studioでフォームを調整する業務担当者、カスタムモジュールを書く開発者、顧客のシステム設計を支援するコンサルタントのいずれにとっても重要です。使いどころや制約を知らないと後で手戻りが発生します。
一見すると単純ですが、実務では知っておくべきプロパティや振る舞いが複数あります。本稿ではフィールドに格納される内容、UI上での表示のされ方、作成方法、カスタマイズの手順、そして実際の業務での適用例までを一通り解説します。
OdooのCharフィールドとは何か
OdooのORMでは、Charフィールドは短いテキスト（1行）を想定して設計されています。データベース側ではサイズ指定の有無に応じてPostgreSQLのVARCHARやTEXTに対応します。
ユーザー視点では、フォーム上は単一行のテキスト入力、一覧表示では普通のテキスト列として表示されます。名前、コード、識別子、参照番号といった“一行で済む”データを保存するのに最適です。
モデル定義における記述例のイメージ（Pythonで定義する場合）を以下に示します。
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
customer_po_reference = fields.Char(
string='Customer PO Reference',
size=64,
index=True,
)stringは画面上で表示されるラベルを決めます。sizeは任意で最大文字数を制限します。indexを有効にすると検索を速くするためのデータベースインデックスが作成されます。
In Odoo Studio, this same field is called a Text field (single line). When created through Studio, it gets an x_studio_ prefix automatically. When created via code or the XML-RPC API, you choose the technical name yourself.
Charフィールドの仕組み
フィールドを定義すると、モジュールのインストールやアップグレード時にフレームワークが自動でデータベース列を作成します。手動でSQLマイグレーションを書く必要は基本的にありません。
サイズ指定がないCharはデータベース上ではTEXTとして保存され、サイズ指定がある場合はVARCHAR(n)になります。PostgreSQLは両者を効率的に扱うため、主な違いは性能よりも長さ制約の有無です。
主要なフィールド属性
Charフィールドで知っておくべき代表的なプロパティをまとめます。
- size: 最大文字数。未指定ならデータベースレベルでの長さ制約はありません。
- translate: Trueにすると言語ごとに値を翻訳可能にします。多言語環境で有用です。
- required: インターフェース上およびモデルレベルで必須にします。
- default: レコード作成時の自動的な初期値を設定します。
- index: そのフィールドに対する検索やフィルタを速くするデータベースインデックスを作成します。
- compute: Pythonの計算メソッドと紐づけて動的に値を生成するために使います。
- store:
computeと組み合わせたときに計算結果をデータベースに保存するかを制御します。 - copy: レコード複製時に値を引き継ぐかを決めます。デフォルトは
Trueです。
ビュー上での見え方
In form views, a Char field renders as a standard <input type="text"> element. In list views, it displays as plain text. In search views, it supports filters using contains, equals, and starts-with operators out of the box.
表示にウィジェットを組み合わせることもできます。例えばemailウィジェットを使えばクリック可能なメールリンクになり、urlウィジェットで新しいタブで開くリンクにできます。
Odoo ORMとのやり取り
開発者から見ると、Charフィールドの読み書きは他のフィールドと同じ扱いです。レコードオブジェクト上の属性にアクセスするとフレームワーク側でサニタイズや定義に基づくバリデーションを行います。複雑な変換が不要なため、日常的な開発で扱いやすいフィールドです。
業務での活用シーン
CharフィールドはOdooのほぼ全パーツで見かけます。以下に業務で頻出する5つの具体例を挙げます。
CRM: 顧客管理の参照コード
企業内で顧客に独自コードを付与している場合、res.partnerにCharフィールドを追加すると顧客一覧検索や受注・請求書への参照表示が容易になります。類似名の取引先が複数あるときに役立ちます。
販売: 顧客発行の注文番号
顧客から届く発注書に記載されたPO番号は請求書や納品書にも表示される必要があります。sale.orderの既存フィールドclient_order_refはCharで定義されており、請求書へ自動で引き継がれるようになっています。これにより参照番号のやり取りが減ります。
在庫: 商品の内部参照コード
product.templateのdefault_codeは内部参照を保持するためのCharフィールドです。倉庫管理、バーコード、発注などで一貫して使われる重要な属性で、データ品質の維持が在庫運用の鍵になります。
会計: 税番号や登記番号
VATや税ID、法人番号などは取引先レコード上のCharフィールドに保存され、適切に設定しておけば請求書や仕入伝票に自動表示されます。複数国を扱う場合、この情報を正確に管理することが手作業削減につながります。
人事: 社員IDやバッジコード
社員の識別番号や出退勤システムのバッジコードなど、外部システムと紐付けるための短い文字列は従業員モデル上のCharフィールドで扱うのが実務的です。初期は単純な参照で十分なことが多いです。
Charフィールドの作成とカスタマイズ方法
Charフィールドの追加方法は主に3つあります。技術体制や運用ポリシーに応じて選んでください。
Odoo Studioを使う（ノーコード）
Odooに内蔵された低コードツールであるStudioを使えば、コードを書かずに簡単にフィールドを追加できます。手順の概要は次の通りです。
- メインメニューからOdoo Studioを起動します。
- フィールドを追加したいフォームを開きます。
- サイドバーから「Text（単一行）」フィールドをドラッグしてフォームに配置します。
- プロパティでラベル、必須設定、必要ならサイズ制限を設定します。
- 保存してStudioを閉じます。
Studio automatically creates the field with an x_studio_ prefix and adds it to the form view. No database migration is needed on your side.
カスタムモジュールのPythonで定義する
複数環境へ配布するカスタマイズやバージョン管理が必要な場合はPythonでフィールドを定義するのが推奨です。モジュールとして実装すれば確実に展開できます。
from odoo import fields, models
class ResPartner(models.Model):
_inherit = 'res.partner'
x_erp_customer_id = fields.Char(
string='ERP Customer ID',
size=32,
index=True,
copy=False,
)モデルにフィールドを追加したら、表示させたいビューのXMLにも項目を追加します。モジュールのインストール時にOdooが自動的にデータベース列を作成します。
XML-RPC APIを使う方法
デプロイパイプラインやリモート自動化の一環としてプログラム的にフィールドを作成する場合はXML-RPC経由でフィールドを生成できます。
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_custom_reference',
'field_description': 'Custom Reference',
'model_id': model_id,
'ttype': 'char',
'size': 64,
'state': 'manual',
}]
)ここでのstate: 'manual'は、StudioやAPIで手動作成されたフィールドであることを示す適切な設定です。外部ツールによる自動設定シナリオでも同様のフローを取れます。
運用のベストプラクティス
1. 最大長が分かるならsizeを設定する
If the field stores ISO country codes, phone numbers, or fixed-length identifiers, define a size. This communicates intent to anyone reading the model and prevents accidental data entry errors. A field meant to store a two-letter country code should not silently accept a 500-character string.
2. よく検索するフィールドにはインデックスを付ける
顧客コードや受注参照のように頻繁に検索されるフィールドはindex=Trueにしておくと、大量データ時に検索レスポンスが格段に改善します。
3. 多言語で表示が必要ならtranslateを使う
製品名や役職名のように言語ごとに異なる表示が求められる場合は翻訳フラグを立てておきましょう。ドキュメント出力時の言語切替で差が出ます。
4. 技術名は分かりやすく一貫性を持たせる
カスタムモジュールではx_customer_erp_idのように意味が分かる名前を付けてください。Studioで作ったら本番導入前にプロパティから名前を見直すことを推奨します。技術名は一度データが入ると変更が難しいです。
5. 派生値はcomputeで生成する
年と連番を組み合わせた参照番号など、他フィールドから導出できる値はcomputedフィールドにして中央でロジックを管理します。store=Trueにすれば検索やレポートで効率的に使えます。
よくある陥りやすい点
無制限にすると無秩序なデータが入るリスク
サイズ制限がないと利用者が長文を貼り付けてしまい、帳票出力や外部連携先で文字数制限に引っかかることがあります。長さが重要なフィールドには適切なサイズを設けましょう。
検索頻度の高いフィールドにインデックスがない
インデックス未設定だと大きなテーブルでフィルタが全件スキャンになり、パフォーマンス問題が後から発覚します。リストビューや検索バーで頻用するフィールドは初めからインデックスを検討してください。
CharとTextの混同
Charは短い単一行向け、Textは複数行の長文向けです。住所や説明文をCharで扱うと改行が使えないなどUXが悪化します。文章が数文に及ぶ可能性がある場合はTextを選びましょう。
多言語フィールドでtranslateを忘れる
国際展開をする会社では翻訳可能にしておかないと、すべての言語ユーザーに同一の値が表示されて混乱を招きます。顧客向け表示項目は意識して設定してください。
選択肢やリレーションであるべきデータをCharにする
状態やカテゴリ、国のように限定された値しか取りえない場合はSelectionやMany2oneにすべきです。Charだと入力の揺らぎ（typoや表記差）が生じて集計やグルーピングが壊れやすくなります。
よくある質問（FAQ）
CharフィールドとTextフィールドの違いは何ですか？
Charは短い単一行のテキストを格納し、フォーム上はテキスト入力として表示されます。Textは長文向けでリサイズ可能なテキストエリアになります。名前やコードはChar、説明や備考はTextが基本です。
Charフィールドの文字数を制限できますか？
はい。Pythonで定義する際にfields.Char(size=64)のように指定できます。Studioでもプロパティで設定可能です。未指定だとデータベース上での長さ制約はありません。
Charフィールドを検索バーに表示するにはどうすればよいですか？
そのモデルの検索ビューにフィールドを追加してください。Studioではフィールドプロパティで検索可能にするオプションを有効にします。コードではXMLの<search>内に<field name="your_char_field"/>を追加します。追加後は検索バーで直接フィルタできます。
数値をCharフィールドに保存できますか？
技術的には可能ですが、計算や数値比較が必要な値はIntegerやFloatにすべきです。郵便番号や電話番号、シリアルなど数字を含むが文字列として扱うべき値はCharで問題ありません。
計算結果を保持するcomputedなCharフィールドはどう作るのですか？
フィールド定義でcompute='_compute_my_field'とstore=Trueを指定し、@api.depends()で再計算トリガーとなるフィールドを宣言したメソッドを書きます。store=Trueにすると計算結果がDBに保存され、検索やエクスポートで再計算を待たずに使えます。
まとめ
Charフィールドは見た目より奥が深い存在です。多くのユーザーが日常的に触れていますが、システム構築時にその特性や使い分けを理解しておくことでデータ品質や運用効率が大きく変わります。
Odoo Studioで簡単に追加する場合も、カスタムモジュールで厳密に定義する場合も、本稿で示したパターンを知っておくと初回で適切に設計できます。
適切なフィールド設計は堅牢なデータモデルの基盤です。Charフィールドは小さな要素ですが、全体の信頼性を左右する重要なピースです。
当社Dasoloでは、企業のOdoo導入・カスタマイズ・最適化を部門横断で支援しています。データモデル設計やカスタムフィールド追加、フルモジュール開発など、必要に応じてお手伝いします。 お問い合わせはこちら まずはご相談ください。あなたのOdooプロジェクトについてお話ししましょう。