# 承認ポリシー

> 承認マトリックスを明示的な条件、責任ある立場、管理されたルートに変えます。

_Updated: 2026-09-12_

承認ポリシーには、作業を続行する前にリクエストがどのチェックと決定を通過する必要があるかが記述されています。

## まずは社内ルールから

意思決定の種類、法的会社、責任ある立場、制限、証拠、および例外処理に名前を付けます。スプレッドシートは議論のソースになる可能性があります。公開されたプロセスは、サポートされているルールを正確に表現する必要があります。

## 購入マトリックスの例

| 金額 | ルート例 |
| --- | --- |
| $10,000 未満 | マネージャー |
| $10,000 から $50,000 | マネージャー → 財務 |
| $50,000 から $250,000 | マネージャー → 財務 → CFO |
| $250,000以上 | マネージャー → 財務 → CFO → CEO |

この表は、組織固有のポリシーを示しています。 Railbase のデフォルト制限を定義したり、すべてのレビュー担当者が最終承認権限を持っていることを暗示したりするものではありません。

## 金額だけでは決まらない

会社、部門、購買カテゴリ、リスク、委任および職務の分離がルートに影響を与える可能性があります。どの条件が必須であり、誰が例外を所有するかを文書化します。

## ドラフトからアクティブな行動へ

[Workflow Studio](/ja/learn/railbase-studio) を使用して、サポートされているプロセスを構成します。信頼できる企業情報源からポジションと参加者を選択し、不足している依存関係を解決して、必要な公開パスに従います。

ドラフトは実行中の作業を黙って変更するものではありません。効果的なプロセスの改訂と各決定に使用されるポリシーを維持します。

## 境界をテストする

各制限の下および上で代表的なリクエストを使用します。文書の欠落、承認者の不在、委任の期限切れ、職務の矛盾、返送された要求などを含めます。割り当てられた役割、許可されたアクション、目に見える結果、および記録された決定を確認します。

[権限と委任](/ja/learn/authority-and-delegation) · [最初のプロセス ガイド](/ja/learn/quickstart)