導入
Odooでの「テキスト」フィールドはとても汎用性が高く、メモ欄、商品説明、社内コメントなど、行数の多い自由記述を保存する場面で頻繁に使われます。短いラベルでは収まらない自由文を扱うときはまずこれを検討するのが一般的です。
見た目は単純なtextareaですが、データモデルやORM上での扱い方を理解すると、フォーム設計やカスタムモジュール開発、Studioでのフィールド追加時に無駄な設計ミスを防げます。
本稿では、Textフィールドが何を保存しどのように振る舞うかを説明し、実務例、技術的な追加方法、運用上の注意点やありがちなミスまで網羅的に解説します。
Odooにおけるテキスト（Text）フィールドとは何か
OdooのORMでは、fields.Textが複数行のプレーンテキストを格納するための型に相当します。PostgreSQL側ではTEXT型のカラムにマッピングされ、文字数制限は設けられません。短文から長文までそのまま保存できます。
In forms, it renders as a resizable <textarea> element. In list views, it appears as truncated plain text. In search views, it supports text-based filtering just like the Char field.
Pythonモジュールでの基本的な定義は、一行でフィールドを宣言するだけで済み、バックエンドが必要なDB変更を自動的に行います。
例：モジュール内でモデルを拡張してinternal_notes = fields.Text(string='Internal Notes', translate=False)のように定義します。
Odoo Studio上では“Multi-Line Text”として提供され、Studioで作成すると技術名に自動でx_studio_プレフィックスが付与されます。コードやAPIで作る場合は、自分で技術名を決めます。
CharやHtmlとの違い
同じ“文字列”を扱うフィールドでも用途に応じて3種類があり、使い分けが設計上のポイントです。
- Char（単一行）: 氏名やコード、参照など短い単一行向け。入力幅や最大長を想定できる値に適します。
- Text（複数行）: メモや説明文など複数行の自由記述向け。プレーンテキストを制限なく保存します。
- Html（リッチテキスト）: 太字や箇条書き、リンクなどのフォーマットを保持したい場合に使います。HTMLマークアップを保存します。
TextはCharとHtmlの“中間”に位置します。Charより入力スペースが広く、Htmlほどフォーマットの複雑さは不要な場面に最適です。多くの社内メモや簡潔な説明にはTextが最も自然です。
フィールドの動作仕組み
モデルにTextフィールドを追加すると、モジュールのインストールやアップグレード時に自動的にPostgreSQLのTEXTカラムが生成されます。手動でSQLを触る必要はありません。
CharのようなsizeパラメータはTextには存在せず、DB側に文字数制限はありません。これは、あらかじめ長さを限定する意味がない自由文向けの設計です。
主要なフィールド属性
実務で重要になるTextフィールドの代表的な属性は次の通りです。
- translate: Trueにすると言語ごとの翻訳が可能になり、多言語運用する場合、顧客向けの説明文などに有効です。
- required: 空欄を許さない必須項目にできます。UIとORM両方で検証されます。
- default: 新規作成時の初期値を静的文字列やコール可能で設定できます。
- compute: Pythonメソッドで動的に値を生成する際に使います。自動要約や派生テキストに便利です。
- store: computeと併用してTrueにすると計算結果をDBに保存し、検索やレポートで利用可能になります。
- copy: レコード複製時に値を引き継ぐかを制御します。デフォルトはTrue。複製に残したくないメモはFalseにします。
- index: Textには通常B-treeインデックスは適しません。フルテキスト検索やOdooのフィルタ機能で対応するのが一般的です。
ビューでの見え方
In form views, the Text field renders as a <textarea> that users can resize vertically. In list views, content is truncated to fit the column width. In search views, it supports text-based search filters out of the box once you add it to the search view definition.
HtmlフィールドのようなWYSIWYGは表示されないため、ユーザーが入力した通りのプレーンテキストが保存され、改行もそのまま保持されます。
ORMとのやり取り
開発者視点では読み書きが簡単で、レコードオブジェクトの属性に直接アクセスすればORMが永続化を扱います。Textは自動的なサニタイズを行わない点でHtmlと異なり、その点を理解して使う必要があります。
ビジネスでの利用シーン
現場でよく見かける具体例
営業：社内注文メモ
受注レコードのnote系フィールドはTextが一般的です。配送指示や梱包注意、顧客の好みなど構造化しにくい情報を記録し、顧客向け書類には出力しない運用が多いです。
在庫：商品の社内メモ
商品フォームのNotesタブにあるTextフィールドは倉庫向けの取り扱い注意や納入元固有の情報を書き留めるのに使われます。外部公開しない運用ならプレーンテキストで十分です。
購買：仕入先の条件や納入指示
発注書に添える仕入先メモとして、電話やメールで合意した特記事項を残しておくと、受入時の齟齬を減らせます。会話の内容を発注レコードに紐づけておくことが有効です。
CRM：案件の要約や面談メモ
営業案件に自由記述のTextフィールドを設けて、面談の要点や顧客の反論、検討状況などを整理しておくと、次に引き継ぐ担当者が状況を素早く把握できます。
人事：応募者や従業員のコメント
面接メモやオンボーディング時の観察、評価に関する所見などを従業員レコードに残す用途に向きます。モデルを増やさずに簡潔に記録できるのが利点です。
テキストフィールドの作成とカスタマイズ方法
Textフィールドを追加する方法は主に3つあり、環境や運用方針で選びます。
Odoo Studioを使う（ノーコード）
コードを書きたくない現場担当者やコンサル向けに最も手軽な方法です。手順は直感的で短時間に完了します。
- Studioアプリを開き、
- 対象のフォーム画面へ移動し、
- サイドバーからMulti-Line Textをドラッグして配置、
- ラベルや必須設定、初期値をプロパティで設定、
- 保存してStudioを閉じる、という流れです。
Studioはビュー更新とフィールド作成を自動で行い、x_studio_で始まる技術名を付与して即時利用可能にします。DBマイグレーションやサーバ再起動は不要です。
カスタムモジュールにPythonで定義する方法
複数環境で管理・配布する変更や長期保守が必要な場合は、コードベースで定義するのが標準的かつ推奨される方法です。
例：res.partnerを拡張してx_client_notes = fields.Text(string='Client Notes', translate=False, copy=False)のようにモデルに追加します。
定義後は該当ビューのXMLにフィールドを追加し、モジュールをインストール/アップグレードすればDBカラムが自動的に作成されます。本番運用するカスタマイズはこの方法で管理するべきです。
XML-RPC APIを使う方法
デプロイスクリプトやリモートからの設定自動化が必要な場合は、API経由でフィールドを作成できます。
例：ir.model.fieldsに対してttype='text'でcreate呼び出しを行えばTextフィールドを作成できます。
ttypeにtextを渡すとText型が作られ、state='manual'はモジュール外（StudioやAPIで作成した）フィールドであることを示します。遠隔設定を一括展開する際に有効な手法です。
実務で押さえるべきベストプラクティス
ベストプラクティス（要点まとめ）
1) 複数行が本当に必要な場合にのみTextを使う：名前やコードなど一行で足りる値はCharにし、誤用でUIが冗長にならないようにすること。
2) フォーマットが必要ならHtmlを選ぶ：箇条書きや太字などの見た目が重要な出力先があるならTextではなくHtmlを使うべきです。
（補足）プレーンテキストで書式を期待させるとユーザーの混乱を招きます。
3) 多言語表示が必要ならtranslateを有効化：顧客向け説明やサイト公開する文言はtranslate=Trueにして言語別の文面を管理しましょう。
（補足）社内運用専用のメモは通常翻訳は不要です。
4) 複製時に引き継ぎたくないメモはcopy=Falseに：特定レコード固有の履歴は複製先に残さないように設定すると誤解を防げます。
5) 自動生成要約はcompute＋store=True：複数フィールドを結合したサマリをcomputeで作り、store=Trueにすれば検索やレポートで使えます。
実務的には、計算済みTextをDBに保存しておくと一覧やフィルタで活用しやすくなります。
設計ミスの典型と対応
よくある落とし穴と回避法
TextをHtmlが必要な場面で使ってしまうケース
出力先に装飾や段落構成が必要なのにTextを選ぶと、貼り付けた太字や箇条書きが消えて平坦な本文になります。表示先の要件を確認してから型を決めましょう。
TextをCharで十分な場面で使ってしまうケース
トラッキング番号など短文だけを入れる箇所にTextを使うとフォームが間延びします。入力欄の見た目や操作性を重視してCharに振り分けてください。
多言語環境でtranslateを忘れるケース
顧客向けや国際環境でユーザーが言語ごとに別文面を期待する場合、translate=Falseのままだと全員同じ文面が表示されます。後から有効化する際は既存データのマイグレーションに注意が必要です。
構造化データをTextに詰め込むケース
JSONや区切り文字で意味付けしたデータを自由文に入れると、検索・集計・連携で破綻します。データにルールがあるならSelectionやMany2one、関連モデルで正しく定義してください。
検索ビューに追加し忘れるケース
重要情報をTextに保存しても検索ビューに登録していないと、一覧の検索バーから絞り込めません。ユーザーがキーワードで探せるようにsearch viewへの追加を忘れないでください。
まとめ
結び：設計次第で威力を発揮する地味な部品
Char、Text、Htmlのどれを選ぶかはOdooカスタマイズの初期段階で頻繁に直面する判断で、正しく選ぶことで後の手戻りを大きく減らせます。
Studioで素早く追加するのも、Pythonで管理するのも、APIで一括展開するのも、それぞれ適した場面があります。本稿で示したパターンを参考に正しい選択と設定を行ってください。
堅牢で使いやすいデータモデルは小さな判断の積み重ねで成り立ちます。用途に応じたフィールド選定はその中でも重要な一手で、Textは適材適所で使えば柔軟で扱いやすいツールになります。
Dasoloでは、企業のOdoo導入・カスタマイズ・運用最適化を支援しています。データモデル設計や専用フィールドの構築、フルスクラッチの導入支援など幅広く対応可能です。 お問い合わせ 貴社のOdooプロジェクトについてぜひお話を聞かせてください。