ノーコードで自動化 — Odoo の自動化ルール
「商談が進んだら次の作業を知らせる」「期日を過ぎた請求書を拾う」。Odoo Community に標準で入っている自動化ルールとサーバーアクションを、見本のデータで実際に作って動かし、増えた件数で確かめます。
目次
目次
このページには目次がありません
商談が次の段階に進んだのに、見積を出すのを忘れていた。期日を過ぎた請求書に、誰も気づいていなかった。こうした「決まった時に、決まった作業を起こす」仕事は、人が覚えておくより、システムに任せた方が確実です。
Odoo Community には、そのための 自動化ルール（base_automation）が標準で入っています。画面で項目を足す道具（Studio）は Enterprise 側ですが、自動化ルールは Community で使えます。この記事では、見本のデータの入った Odoo 19 Community に 5 つのルールを作り、動いたことを件数で確かめました。
自動化ルールは「いつ」と「何をする」の組
自動化ルールは、2 つの部品でできています。
- トリガー：いつ動くか。作成時・更新時・段階が変わった時・日付の欄を基準に何日後、などから選びます（18 種類）
- サーバーアクション：何をするか。項目の更新・活動の作成・メールの送信・コードの実行などから選びます（13 種類）
| よく使うトリガー | よく使うアクション |
|---|---|
| 作成時／作成および編集時 | レコードを更新 |
| ステージは以下に設定 | 活動を作成 |
| 日付フィールドに基づく（期日の何日後など） | メールを送信 |
| 削除時・アーカイブ時 | コードを実行 |
ルールの一覧は、開発者モード（URL の末尾に ?debug=1）で 管理設定 → 技術設定 → 自動化 → 自動化ルール にあります。下が、この記事で作った 5 つのルールです。
作ったルールの一覧（画面は見本のデータです）
例1：商談が「案件」になったら、見積の活動を作る
コードは書きません。トリガーで「ステージは以下に設定」と段階「案件」を選び、アクションで「活動を作成」を選ぶだけです。
段階をきっかけにするルール（画面は見本のデータです）
活動の中身は、種類・題・期限・担当を決めます。担当は「ダイナミックユーザ」にして、商談の 販売担当者 に割り当てました。人が変わってもルールを直さずに済みます。
活動を作るアクション（画面は見本のデータです）
商談を「見込あり」から「案件」へ進めると、右側に活動が出ました。商談の活動は 0 件 → 1 件、期限は 2 日後です。別の商談を「見込あり」に進めたときは増えませんでした。
段階を進めたら、活動が自動でできた（画面は見本のデータです）
例2：30 万円以上の見積に、確認のタグを付ける
大口の見積を上長に見てもらう、といった運用の入口です。トリガーは「作成および編集時」、適用対象に「合計が 300000 以上」という条件を置き、アクションは「レコードを更新」でタグを足します。
条件つきのルール（画面は見本のデータです）
タグを足すアクション（画面は見本のデータです）
369,600 円の見積を作ると、タグが付きました。19,800 円の見積には付きません。その小さい見積の数量を増やして 396,000 円にすると、その時点で付きました。タグ付きの見積は 0 件 → 1 件 → 2 件です。
タグが付いたのは、いちばん上の2件の見積です。この一覧ではタグの列を出していません（画面は見本のデータです）
一覧の下の方にある 462,000 円の受注は、ルールを作る前の物で、タグは付きませんでした。ルールは、作った後の作成・変更にだけ効き、それより前のデータには遡りません。既存のデータにも当てたいときは、一覧から選んで手で流すか、別の作業として行います。
例3：期日を過ぎた未入金の請求書を拾う
時間をきっかけにするルールです。トリガーは「日付フィールドに基づく」で支払期日を選び、遅延を「1 日 変更後」にしました。適用対象は「顧客請求書・記帳済・未払か一部支払済」です。
期日を基準にするルール（画面は見本のデータです）
見本の請求書のうち、期日を過ぎて未入金の 2 件 にだけ「入金の確認」の活動ができました。期日前の 1 件と、入金済みの 2 件には作られていません。見回りをもう一度動かしても、同じ請求書に二重には作られませんでした。
期日を過ぎた請求書にだけ活動ができた（画面は見本のデータです）
時間のルールは、保存のたびではなく 定期処理が見回ったとき に動きます。見回りの間隔は既定で 4 時間 ごとで、ルールの遅延が短いほど詰まります（1 日後のルールを置いたら 144 分 ごとになりました）。期日ちょうどに動くわけではない、と考えておきます。
コードが要るとき：「コードを実行」
画面の選択肢で足りないときは、アクションのタイプを 「コードを実行」にして Python を書きます。ルールが無い状態で社内の利用者を作ってみると、従業員の記録は増えませんでした。そこで「社内の利用者を作ったら、従業員も作る」ルールを書きました。
利用者から従業員を作るコード（画面は見本のデータです）
for user in records:
if user.share or user.employee_ids: # 取引先向けの利用者・作成済みは飛ばす
continue
env['hr.employee'].create({
'name': user.name,
'user_id': user.id,
'work_email': user.login,
'company_id': user.company_id.id,
})
log('従業員を作りました：%s' % user.name)
社内の利用者を作ると、従業員は 3 人 → 4 人 になり、ログも 0 件 → 1 件 増えました。取引先向けの利用者を作ったときは増えていません。
利用者を作ったら、従業員ができた（画面は見本のデータです）
コードの中で使えるもの
コードは制限つきの環境で動きます。試して分かったことをまとめます。
| 使える | 使えない（保存の時点で断られる） |
|---|---|
env（モデルを呼ぶ）、records／record（対象の記録）、log（ログを残す）、UserError（止める）、datetime・Command など | import 文、__class__ のような __ で始まる名前 |
保存の時点で断られるのは、この2種と、文の書き方の誤り（括弧の閉じ忘れなど）です。使えない名前や項目名の書き違いは、動かしたときに初めて分かるので、保存したら一度動かして確かめます。
保存を止める
UserError を投げると、その保存は取り消されます。「会社の取引先には電話番号を必須にする」ルールを作り、電話番号なしで保存すると、次のように止まりました。取引先の件数は増えていません。
条件に合わない保存を止める（画面は見本のデータです）
使い始める前に決めておくこと
- ルールはデータベースの中にあります。検証の環境で作ったルールは、本番には自動では移りません。長く使うルールは、アドオンのデータファイルに書いて版を管理します（アドオンの基本）
- 重い処理を入れない。作成・更新のルールは保存の途中で動くので、外部へのつなぎや大量の更新は、保存を遅くします
- ルール同士の連鎖を絵にしておく。あるルールの更新が、別のルールのきっかけになります。Odoo は同じルールを同じ記録に二度は流しませんが、どの順で何が起きるかは数が増えるほど追いにくくなります
- 作れる人を決める。自動化ルールは管理設定の権限を持つ人が作ります。誰が・何のために作ったかを、ルールの「ノート」に残します
自動化ルールで足りない画面や帳票は、アドオンで足します。置き場の決め方は「アップデートしても壊れない — Odoo の拡張の作り方」で紹介しています。