AI による Odoo 書き込みに ACL だけでは不十分な理由

Published: 2026-08-18

MCP endpoint: https://mcp.erpipe.com/mcp

まず結論から

Odoo の ACL は、接続ユーザーが書き込みできるかどうかに答えます。しかし、AI エージェントがこの変更を今、このレコードに対して、このペイロードで行うべきかどうかには答えません。ERPipe は書き込みをデフォルトでオフに保ち、プレビュー、フィールドポリシー、バリデーション、そして 1 回限り消費される人間の決定を Odoo の手前に重ねられます。Odoo 自身のアクセスチェックも引き続き実行されます。

これは https://erpipe.com/ のホステッド製品に関する説明であり、MCP URL の変更ではありません。クライアントは依然として https://mcp.erpipe.com/mcp を呼び出します。

環境と方法

このフィールドノートは、ERPipe のホステッド書き込み経路を、プレビュー、バリデーション、承認、実行、監査、曖昧な結果のチェックとして実装・テストしたものに基づいています。Odoo 接続は引き続き実在の Odoo ユーザーを使用し、ゲートウェイは承認を使ってグループ、ACL、レコードルール、フィールドアクセスを迂回しません。

方法は意図的に狭く設計しました。書き込みを無効にした状態から始め、正確なモデル、レコード ID、フィールド、値を準備し、ポリシーチェックを実行し、1 つの人間の決定を要求し、1 回だけ実行し、その後記録された結果を検査します。これはベンチマークではなく、すべての Odoo ビジネスワークフローが自動化に対して安全だという証拠でもありません。

なぜ人がループに残るのか

エージェントは、正しい請求書日付と、破滅的な取引先変更を、同じ自信でドラフトできます。人間による承認は目に見えるロックです。オーナーはモデル、メソッド、ID、ペイロードを見てから、1 回承認するか拒否します。グラントが密かに拡大することはありません。

Chatter ノートと許可リストされたメソッドには別のゲートを使えるため、コメントが在庫移動のように扱われることはありません。

財務を模した経路

• エージェントは、Odoo ユーザーがすでに閲覧できる期限超過の account.move 行を検索します。
• PDF を開き、発注オーダーと比較します。
• フォローアップ日付への書き込みをプレビューします。
• オーナーがダッシュボード、メールの Approve/Reject、または Telegram からその書き込みを 1 回承認します。
• 監査にはマスキングされた運用詳細が保存されます。請求書は Odoo に残ります。

これがループです。「Connect をクリックした後、モデルが何でも好き勝手に投稿する」のではありません。

結果

有用な境界は、2 つの独立した決定です。Odoo は このユーザーがその操作を実行できるか？ に答えます。ゲートウェイは このクライアントと提案されたペイロードを、今、試行させてもよいか？ に答えます。人間の承認は 2 つ目の決定を狭めることはできますが、1 つ目を広げることはできません。

これらの決定を分離しておいたことで、失効と失敗対応が明確になりました。Odoo のグループを変更せずに接続を一時停止できます。拒否されたペイロードは拒否されたままです。不確実な結果は unknown として記録され、再投稿の理由として扱われません。

オーナーが実際に目にするもの

Odoo 呼び出しの結果が不明確な場合、ERPipe はそれを unknown とマークします。ゲートウェイのタイムアウトを理由に 2 重に投稿するよりも安全です。

例: フォローアップ日付の変更

1. 接続の書き込みはまだオフです。エージェントは検索と読み取りのみ可能です。
2. 書き込みを有効化し、create/write/unlink に対してオーナー承認を維持します。
3. エージェントが preview を呼び出し、次に validate を呼び出し、待機します。
4. メールで Approve をタップするか、/app/approvals を開きます。
5. 書き込みは同じ Odoo ユーザーとして実行されます。レコードルールは引き続き適用されます。

拒否すれば、何も投稿されません。接続を一時停止すれば、後続のツール呼び出しには黙示的な成功ではなく一時停止エラーが返ります。

失敗モード

• 広い権限の Odoo サービスユーザーは、その後のポリシーミスすべての代償を大きくします。まず最小権限を使ってください。
• 「はい」というチャットメッセージは、1 つのプレビュー済みペイロードに紐付いたオーナーの決定ではありません。
• フィールドポリシーのない承認は、人間に不必要に広いミューテーションを突き付けることがあります。
• ミューテーション後のタイムアウトは、コミット済みの書き込みを隠すことがあります。盲目的な再試行はビジネスアクションを複製しかねません。
• 永続的な承認トークンは、静かに別のクレデンシャルになります。決定は有界で 1 回限り消費されるべきです。

「モデルがチャットで尋ねてきた」場合との違い

ChatGPT 内のチャット確認はオーナーの受信箱ではありません。チャットにアクセスできる誰もが「はい」と打てます。ERPipe の承認は、特定のプレビュー済みペイロードに対するワークスペースオーナーの決定です。モデルが自信ありげに聞こえたからといって、グラントが拡大することはありません。

ホステッドのオリジナル事実（2026-08-18）: execute_approved_write が HITL_APPROVAL_REQUIRED を返すとき、それは 短い待ち であり、失敗でも会話を終える理由でもありません。同じ承認オブジェクトを保持し、オーナーに Approve を伝え、5–10 秒待ってから get_write_approval_status をポーリングします（または同じ承認で実行を再試行します）。約 30–45 秒後も保留のままなら、Approvals に残して置いてください。ポーリングツールはホステッド専用で、カタログ に名前が記載されています。

曖昧な Odoo の結果は unknown とマークされます。タイムアウトが起きたからといって、ゲートウェイが投稿を盲目的に再試行することはありません。

限界

人間による承認は 1 つのクラスのリスクを減らしますが、提案された会計、在庫、顧客アクションが正しいことの証明にはなりません。オーナーには依然として、適切な Odoo ユーザー、バックアップ、ビジネス管理、ワークフロー固有のレビューが必要です。高頻度または時間的制約の強いプロセスでは、行ごとの承認とは別の管理手段が必要な場合があります。

このノートは、ERPipe の現在のホステッド挙動をカバーするものであり、すべての MCP サーバーをカバーするものではありません。別のゲートウェイで書き込みを有効化する前に、実装を検査し、失効、拒否、unknown の結果をテストしてください。

ソースと関連エビデンス

• Odoo のアクセス権、レコードルール、フィールドアクセス、セキュリティの落とし穴: https://www.odoo.com/documentation/19.0/developer/reference/backend/security.html
• ERPipe のセキュリティ境界
• ホステッドツールカタログ
• Odoo MCP アーキテクチャのフィールドノート
• Odoo AI エージェント vs 外部ゲートウェイ

FAQ

• 承認は必須ですか？ create、write、unlink に対しては要求させられます。オーナー承認を有効のままにするのが、本番での保守的な設定です。
• 承認は Odoo の ACL を迂回しますか？ いいえ。拒否された Odoo ユーザーは、その行を書き込めません。ERPipe は裏口ではなく、2 つ目のゲートを追加します。
• 結果が不確実な場合は？ 操作は unknown とマークされ、自動的には再試行されません。タイムアウトが投稿を複製することはありません。
• チームメイトは承認できますか？ いいえ。現在の承認アクションはワークスペースオーナーに限定され、チームメイトは承認権限を継承しません。
• Webhook は自動承認しますか？ いいえ。署名済みイベントは pull/ack キューに入ります。クライアントが一覧化して acknowledge するまで、何も実行されません。
• 書き込みを再度オフにするには？ 接続で書き込みを無効化するか、接続を一時停止してください。既存のトークンが新しい書き込み経路を作り出すことはありません。