---
title: "承認の強制はどう機能するか"
description: "承認の関門がどこにあるか、承認者の権限がどう認可されるか、担当者が自分の見積を承認できないようにする方法、そして管理者の取り消しの記録を扱います。"
url: "https://www.quotway.com/ja/docs/approvals/how-approval-enforcement-works"
type: "documentation"
category: "approvals"
updated: "2026-10-14"
locale: "ja"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# 承認の強制はどう機能するか

**読了時間：** 5 分。
**最終更新：** 2026年10月14日
**対象：** 承認を慣習ではなく統制として機能させる必要のある方。そしてQuotWayの承認が法令順守やガバナンスの要件を満たすかを検討している方。

[承認ワークフロー](./approval-workflows.md)はポリシーの組み立て方を扱います。この記事は、それを実際に支えているものを扱います。

## 関門は送信の動作の内側にある

ポリシーが提案に合致するとき、承認は営業担当者に表示される注意書きではありません。送信そのものに対する条件であり、サーバー側で評価されます。

1. 担当者が**提案を送信**を選びます。
2. 提案の版が作成され、記録されます。
3. 見積が**マーチャントの承認待ち**で止まります。
4. **バイヤーにメールは送られません。** 見積がその状態にある間、通知が処理の列に入ることは一度もありません。
5. 承認の連なりが承認で終わったときにのみ、提案がバイヤーへ届きます。

送信の動作に例外はありません。急いでいる担当者のための「それでも送信」はありません。この確認は画面ではなく送信の経路の中でサーバー側で実行されるため、送信がどう始まったかにかかわらず適用されます。自動化ルールによる送信も含みます。自動化された提案も、手動の提案とまったく同じポリシーを通ります。

## 誰が段階を決裁できるか

連なりの各段階は、承認者を次のいずれかとして指定します。

- **特定のスタッフ** - 「この段階はDanaが承認する」、または
- **役割** - 「この段階は任意のマネージャーが承認する」。

決裁はサーバー側でその一覧に対して認可されます。指名された承認者でもなく、承認する役割にも属さないスタッフは拒否されます。ボタンが隠されるのではなく、要求の時点で拒否されます。

## 担当者が自分の見積を承認できないようにする

これは役割の設定から導かれるものなので、意図をもって決める価値があります。

**営業担当者**の役割には承認の権限がまったくありません。営業担当者は提案を作り、再見積を出し、バイヤーに連絡し、承認された見積を変換できますが、どの見積についても承認の段階を決裁できません。自分が書いたものについてもです。**マネージャー**と**管理者**は決裁でき、それも自分が承認者として挙げられている段階に限られます。

ですから、職務の分離をもたらす構成はこうなります。

| 誰が | 役割 |
| --- | --- |
| 見積を書く人 | **営業担当者** |
| 決裁する人 | **マネージャー**または**管理者** |

このように設定すれば、見積を書いた本人は構造的にそれを承認できません。一人が執筆と承認の両方を行う必要がある場合、たとえば経営者がすべてを行う小さなチームでも、それは機能します。ただ、分離ではなく利便性を選んだことは把握しておいてください。

各役割ができることは[スタッフと役割](../staff/staff-and-roles.md)をご覧ください。

## 条件付きの段階：値引きの深さで引き上げる

段階は条件を持てるため、連なりは必要なときにだけ作動します。「担当者は10%まで値引きしてよく、それより深いものはマネージャーへ引き上げる」は、条件付きの段階を一つ持つ一つのポリシーです。マネージャーの段階は値引きが10%を超えたときにのみ作動し、そうでなければ飛ばされるため、通常の見積はそのまま送られます。

条件は、見積の金額、全体の値引き率、**単一の明細での最も深い値引き**、手付金の割合、商品またはコレクション、顧客タグ、会社の拠点、通貨を基準にできます。最も深い明細の条件がここで効きます。見積全体でならした値引き率では、一つの深い明細が定価の明細の陰に隠れてしまうからです。

> ⚠️ 承認ポリシーには **Professional** プランが必要です。**条件付きの段階**、並列の段階、期限切れのエスカレーション、代理承認には **Enterprise** が必要です。金額だけによる振り分け、たとえば「$50,000を超えるものはすべて管理者が必要」は、条件付きの段階ではなくポリシーの*適用範囲*であり、Professionalで機能します。

## 管理者による取り消しと、それが記録するもの

管理者は進行中の承認の連なりを取り消せます。承認者が止まっている場合、商談が変わった場合、あるいは合致すべきでなかったポリシーの場合です。これは意図的に制約されています。

- **管理者のみ。** マネージャーと営業担当者は行えません。
- **書面での理由が必須です。** 黙って取り消すことはできません。
- **開いているすべての段階に決裁が記録されます。** 作動中、待機中、代理中の各段階に、理由、実行者、そのIPアドレスとユーザーエージェントを伴う「飛ばした」という決裁が書き込まれます。
- **提案は送信されません。** 取り消すと見積は**確認中**に戻ります。送るには改めて送信します。そのときポリシーが再評価され、新しい連なりが作られます。

最後の点の要点は、この取り消しが*止まった連なり*からの脱出路であって、関門を迂回する経路ではないということです。提案がバイヤーに届く唯一の道は、承認された連なりです。

## 監査証跡

すべての決裁はそれぞれ独立した記録として保存され、アプリがそれを編集することはありません。誰が、どの段階を、いつ決裁したか、結果、そして理由です。取り消しによる「飛ばした」という決裁も、省かれるのではなく承認と並んで現れ、条件によって省略された段階は省略として表示されるため、履歴は実際に起きたとおりに読めます。その記録こそが、承認を意図ではなく証拠にするものです。ある値引きがどう認可されたのかを尋ねられたときに示すものになります。このような記録の設計については、[価格承認の監査ログ設計](/blog/pricing-approval-audit-log)をご覧ください。

段階ごとの決裁は、それが属する承認の連なりとともに見積に表示されます。見積のイベントログに記録されるのは承認の依頼と連なりの結果であり、段階ごとの決裁ではありません。

履歴を消すポリシーの編集が二つあります。ポリシーを削除すると、そのもとで記録された完了済みの連なりと決裁が削除され、ポリシーから段階を取り除くと、その段階に記録された過去の決裁が削除されます。記録を残したままポリシーを使わなくするには、削除せずにオフにしてください。[承認ワークフロー](./approval-workflows.md#ポリシーを編集する)をご覧ください。

## 関連記事

- [承認ワークフロー](./approval-workflows.md) - ポリシー、段階、承認者を組み立てます。
- [スタッフと役割](../staff/staff-and-roles.md) - どの役割が何を決裁できるかです。
- [自動化ルール](../automation/automation-rules.md) - 自動化された送信も同じポリシーに従います。