# AI による書き込みに Odoo の ACL は必要だが十分ではない理由

Published: 2026-08-18
Last updated: 2026-08-27
Canonical: https://erpipe.com/ja/guides/human-approval-odoo-ai-writes
MCP endpoint: https://mcp.erpipe.com/mcp

## まず結論から

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

これは [https://erpipe.com/](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 として記録され、再投稿の理由として扱われません。

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

| ステップ | 起きること | 起きないこと |
| --- | --- | --- |
| Preview | ペイロードとターゲット ID が表示される | Odoo は変更されない |
| Validate | フィールドポリシーと許可リストが実行される | タイムアウトが盲目的に再試行されない |
| Approve | オーナーの 1 回の決定 | チームメイトがより広いグラントを継承しない |
| Execute | 承認された書き込みが 1 回実行される | 曖昧な結果が自動で再生されない |

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 に残して置いてください。ポーリングツールはホステッド専用で、[カタログ](/tools) に名前が記載されています。

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

## 限界

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

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

## ソースと関連エビデンス

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

## FAQ

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