Odoo 19 では、テキスト生成を超える AI レイヤーが導入されました。ユーザーが情報を見つける、レコードを解釈する、ビューを開く、ドキュメントを分類する、ヘルプデスク業務を支援する、Webサイト訪問者に回答する、制御されたアクションを選択する、といった作業を支援できます。Odoo 19.4 では、モデルの自動選択、音声対話、保存された会話、より豊富なライブチャットのレコードカード、MCP 接続により、この方向性がさらに拡張されています。

重要なのは、Odoo に AI があるかどうかではありません。特定の状況で、どのエージェントにどの情報とツールの使用を許可するかです。Odoo はそれを、エージェント、スキル、ソース、サーバーアクションで分離しています。

標準の Ask AI アシスタントから始める

標準の Ask AI アシスタントは、コマンドパレットと Odoo インターフェース全体の AI ボタンから利用できます。公式の Odoo AI documentation によると、自然言語の質問への回答、ビューの表示、コンテンツの改善、chatter の要約、文脈に基づく次の手順の提案ができます。

標準の Ask AI エージェントはデータベースレコードを変更できません。情報の理解や移動を支援することはできますが、Odoo はその支援と書き込みを実行するツールを意図的に分離しています。流暢な回答が、気づかないうちに会計、営業、運用上の取引に変わってしまうべきではないため、この既定は重要です。

カスタムエージェントは特定の役割を定義する

カスタムの Odoo AI エージェントには、システムプロンプト、応答スタイル、1 つ以上のスキル、任意のソースがあります。公式の AI agents documentation では、エージェントは目的が定義された自然言語アシスタントであり、Odoo ツールへのアクセスを持つものとして説明されています。

以前の Odoo 19 のドキュメントでは、指示とツールの集合は topics と呼ばれていました。Odoo 19.4 ではそれが skills に改称されています。目的は同じで、各スキルがタスクの文脈、ルール、ワークフローを説明し、実際に呼び出される関数がツールです。

この構造により、広範で曖昧な権限を持つ 1 つのアシスタントではなく、状況ごとに設計されたエージェントを実現できます。例としては、次のようなものがあります。

  • 機会を見つけ、パイプラインデータを説明し、フォローアップメッセージを下書きする営業アシスタント。
  • 承認済みの Knowledge 記事から回答し、判断が難しいケースをエスカレーションするサポートエージェント。
  • アップロードを分類し、承認済みのフォルダやタグを選ぶドキュメントエージェント。
  • タスク履歴を要約し、顧客向け更新内容を準備するフィールドサービスアシスタント。
  • よくある質問に回答し、必要な詳細を収集した後に CRM リードを作成するライブチャットエージェント。

ソースは、エージェントが参照できる情報を決める

Odoo のエージェントは、PDF、Web リンク、Documents のファイル、Knowledge 記事を索引化されたソースとして利用できます。Restrict to Sources オプションは、アクティブにアップロードされたソースのみにエージェントを制限します。これにより、組織がエージェントに使わせるべき資料を定義できるため、顧客向けの回答で特に有用です。広範で根拠のない回答を許す必要がありません。

ソース制限は制御性を高めますが、ソースの品質も依然として重要です。ドキュメントには所有者、レビュー日、古い価格、ポリシー、手順を削除するためのプロセスが必要です。すべての文書が形式上は承認済みであっても、相反するソースがあると回答が一貫しなくなる可能性があります。

Odoo AI Live Chat の仕組み

Odoo では、AI エージェントを Live Chat チャンネルのルールに割り当てられます。公式の AI Live Chat documentation によると、エージェントは一般的な質問に回答し、追加情報を求め、会話を見極め、必要に応じて人間の担当者へエスカレーションできます。

提供されているライブチャットのパターンは、最初のメッセージの後に単純にリードを作成するわけではありません。指示には、いつエスカレーションするか、不足している連絡先情報を収集する方法、既知の詳細を確認する方法、そしてリード作成ツールを 1 回だけ呼び出す条件が定義されています。これが示しているのは、ワークフローの指示が言語モデルと同じくらい重要だということです。

Odoo 19.4 では、エージェントがサポート対象の Odoo レコードに言及すると、ライブチャット内でリッチでクリック可能なカードを表示できます。これにより、商品、予定、その他の対応レコードを訪問者が理解し、開きやすくなります。

会社別チャットボットは 1 つのチェックボックスではなく、設計パターンです

マルチカンパニー組織では、各会社の Web サイトに、その会社についてだけ回答するチャットボットを置きたい場合があります。Odoo にはこの設計のための要素がありますが、境界は明示的に設定する必要があります。

実用的なパターンは次のとおりです。

  • 会社向けの体験ごとに、別々の Web サイトと Live Chat チャンネル、またはチャンネルルールを使う。
  • 会社を推測しようとする 1 つのエージェントではなく、会社ごとに別の AI エージェントを作成する。
  • 各エージェントには、その会社の承認済み Knowledge 記事、ドキュメント、ポリシー、Web リンクだけを与える。
  • Restrict to Sources を有効にして、回答を会社固有のソースセット内に保つ。
  • 情報検索や制御されたリード作成など、そのチャネルに必要なスキルとツールだけを割り当てる。
  • 作成されたリード、チケット、予定が、意図した会社コンテキストと担当チームを受け取るようにする。
  • 会社をまたぐ質問、曖昧なブランド名、別会社の情報を取得しようとする試みをテストする。

Odoo のマルチカンパニーレコードは、共有も会社別も可能です。公式の multi-company documentation では、会社に紐づく見積書、請求書、仕入先請求書は関連する会社コンテキストに制限される一方、連絡先や製品など一部のレコードは既定で共有される場合があると説明されています。

そのレコードモデルは、すべての AI ソースが自動的に分離されることを意味しません。システムプロンプトの「Company A だけを話題にする」といった文言を、機密性の制御として扱わないでください。より強い境界を作るのは、ソースコレクションの分離、チャンネル割り当て、アクセス権、ツール側のチェックです。厳格な法的分離が必要な場合は、共有のマルチカンパニー構成よりも、別データベースのほうが適していることがあります。

エージェントがタスクを実行できるのは、割り当てられたツール経由のみです

エージェントにスキルがなければ、Odoo は情報提供はできるが、タスクの完了やデータベースの変更はできないと説明しています。ツールはエージェントを会話の外へ拡張します。あらかじめ用意された例には、ビューを開くことやリードを作成することがあり、インストール済みアプリによって他のツールも利用可能になります。

自動化されたレコードワークフローでは、Odoo は AI server actions を使用します。公式の AI server actions documentation では、AI マネージャーと実行用ツールが分離されています。AI はレコードとプロンプトを読み、ツールを選択し、宣言された引数を渡します。標準の server action が、実際のビジネスロジックを実行します。

これにより、AI は状況に応じた判断を行い、決定的なコードがルールを強制できます。たとえば、AI は仕入先ドキュメントを分類できますが、選択されたツールは、書き込む前に保存先、会社、許可されたレコード状態、必須フィールドを検証する必要があります。

有用なタスク自動化パターン

  • 受信したドキュメントを分類し、承認済みのタグまたはフォルダを適用する。
  • ヘルプデスクのチケットを要約し、構造化されたトリアージ項目を入力する。
  • レコードに基づいてフォローアップの経路を選び、送信や承認はユーザーに任せる。
  • 必須の連絡先情報が確認された後、ライブチャットからCRMリードを作成します。
  • 現在のレコードの文脈から、レビュー用のメール下書きを作成します。
  • 文書から構造化された詳細を抽出し、管理されたワークフローに取り込みます。

最も弱いパターンは、1つの広範なエージェントに強力な書き込みツールをまとめて持たせることです。範囲の狭いエージェントのほうが、テストしやすく、説明しやすく、監査しやすくなります。

Odoo 19.4で追加されたもの

公式のOdoo 19.4 リリースノートでは、このエージェントモデルに関していくつかの機能が追加されています:

  • タスクに最も適切な設定済みAIモデルを自動選択します。
  • エージェントへの依頼を音声で指示できる音声対話。
  • エージェント会話を最後のメッセージから最大30日間保存します。
  • 対応する外部ツール向けのMCP接続。
  • ライブチャットで言及された対応レコードのリッチプレビューカード。
  • トピック名をスキルへ変更。

MCPは連携の可能性を広げますが、セキュリティレビューの範囲も広げます。外部のAIクライアントを接続する前に、認証情報、公開されるツール、ユーザー権限、ログ、データ境界を文書化しておく必要があります。

プロバイダーと価格に関する考慮事項

OdooはOpenAIとGoogle Geminiのプロバイダーをサポートしています。Odoo Onlineユーザーは標準サービスのために独自のAPIキーを追加する必要はありませんが、より細かな制御のために追加することもできます。Odoo.shとオンプレミスのデータベースでは、AI機能にプロバイダーキーが必要です。Odoo AI APIキーのドキュメントには、顧客所有のキーを使用する場合、プロバイダーの料金が発生する可能性があると記載されています。

安全な導入チェックリスト

  • 測定可能な手作業プロセスがある、範囲の狭いユースケースを1つ選びます。
  • 承認済みの情報源、禁止トピック、人によるエスカレーション経路を定義します。
  • 必要最小限のツールを割り当て、各ツール内でルールを適用します。
  • 管理者だけでなく、通常のアカウントでも会社、ユーザー、レコードへのアクセスをテストします。
  • 誤り、不完全、敵対的、他社にまたがる質問をテストします。
  • 財務、契約、破壊的、または外部送信されるアクションにはレビューを必須にします。
  • 公開後は、回答、ツール呼び出し、プロバイダー利用、ソースの鮮度を監視します。

実践的な結論

Odoo AIは、既存の業務ワークフロー内にある、焦点を絞ったアシスタントの集合として使うのが最も有効です。ライブチャット、会社固有のナレッジ、リード作成、文書分類、レコードベースの自動化は、Odooが自然言語の判断を構造化レコードと管理されたツールに組み合わせられるため、実現可能なユースケースです。

設計は、信頼感やプロンプトだけに依存してはいけません。目的ごとにエージェントを分け、情報源を制限し、ツールを最小限に抑え、業務ルールは決定的なOdooアクションに保持します。それが、チャットボットのデモを支援可能な業務機能に変える方法です。