承認ステップはAI自動化における最も重要なガバナンスコントロールの1つです。重要な出力が顧客に届いたり、公開されたり、財務取引をトリガーする前に、人間がレビューすることを保証します。しかし、常に摩擦の問題がありました：承認者はコンソールにログインし、承認キューに移動し、コンテキストをレビューし、承認または拒否をクリックする必要があります。メールで生活している忙しいマネージャーやエグゼクティブにとって、そのコンテキスト切り替えはワークフローキラーです。
私たちはその摩擦を完全に排除するためにメールベースの承認を構築しました。
仕組み
ワークフローがメール配信設定された承認ステップに到達すると、以下のシーケンスが自動的に実行されます：
- ワークフローが一時停止 — 実行エンジンがコンソールベースの承認と同様に、ワークフローを「承認待ち」状態に停止します。
- コンテキストメールの送信 — 指定された承認者に、ワークフローコンテキストの要約を含むメールが送信されます：何がトリガーしたか、前のステップが何を生成したか、決定に応じて次に何が起こるか。
- ワンクリックアクションボタン — メールには目立つ承認と拒否ボタンが含まれます。各ボタンにはユニークな署名付きアクションURLが含まれています。
- 決定の記録 — 承認者がボタンをクリックすると、アクションURLはトークンを検証して決定を記録する軽量APIエンドポイントに解決されます。
- ワークフローの再開 — 実行エンジンは一時停止した正確な場所からワークフローを再開し、承認決定と承認者メタデータが後続ステップで利用可能になります。
承認者の視点からは全体のフローに数秒しかかかりません。メールを開き、コンテキストをレビューし、ボタンをクリック。ログイン不要。
セキュリティ設計
メールベースの承認はコンソールベースの承認と少なくとも同等のセキュリティが必要です。トークンシステムの仕組みは以下の通りです：
HMAC署名トークン — 各アクションURLにはサーバー側シークレットを使用してHMAC-SHA256で署名されたトークンが含まれます。トークンはワークフロー実行ID、承認ステップID、アクション（承認または拒否）、有効期限タイムスタンプをエンコードします。いずれかのフィールドを改ざんすると署名が無効化されます。
設定可能な有効期限 — トークンは設定可能な期間後に期限切れになり、デフォルトは72時間です。期限切れ後にボタンをクリックすると、承認者をコンソールに誘導する明確なエラーメッセージが返されます。これにより、数週間後に古い承認が実行されることを防ぎます。
使い捨て強制 — 各トークンは1回のみ使用できます。最初のクリック後、トークンは消費済みとマークされます。同じボタン（または反対のボタン）の後続クリックは「決定は既に記録されました」メッセージを返します。これによりリプレイ攻撃と二重送信を防ぎます。
軽量検証エンドポイント — アクションURLは専用APIエンドポイントに解決され、HMAC署名を検証し、トークン期限切れをチェックし、使い捨て状態を確認し、決定を記録し、ワークフローを再開します。署名付きトークン自体が認証情報であるため、セッションや認証クッキーは不要です。
ワークフローエディターでのメール承認の設定
ワークフロー作成者は既に知っているApprovalStepEditor UIを使用してメールベースの承認を設定します。唯一の新しいオプションは配信方法セレクターです：
- コンソールのみ（デフォルト）— 承認がコンソール承認キューに表示されます。承認者はログインが必要。
- メール通知 — ワンクリックアクションボタン付きの承認メールが指定承認者に送信されます。承認はフォールバックとしてコンソールキューにも表示されます。
- 両方 — メール通知とコンソールキューエントリ。チームがメール承認を導入する移行期間に有用。
承認者のメールアドレスはRBACユーザープロファイルから自動的に取得されます。指定された承認者ロールが複数ユーザーにマッピングされている場合、各ユーザーがメールを受信し、最初にアクションした人が決定を記録します。
監査証跡とコンプライアンス
すべてのメールベースの承認はコンソールベースの承認と同じ監査記録を生成し、メールチャネル固有の追加メタデータも含みます：
- 承認または拒否のタイムスタンプ
- アクションを実行した承認者メールアドレス
- 実行されたアクション（承認または拒否）
- アクションURLをクリックしたクライアントのIPアドレス
- クライアントのユーザーエージェント
- アクション時点でのトークン有効期限と残り時間
- 承認ステップ時点でのワークフローコンテキストスナップショット
この監査証跡はコンソールベースの承認と同じコンプライアンス要件を満たします。SOC 2、HIPAA、SOXの対象組織にとって、メールベースの承認ログは人間のレビューと認可の同等のエビデンスを提供します。
ユースケース
メールベースの承認は、ログインの摩擦のために承認ステップを避けていたチームのガバナンスを解放します：
コンテンツ公開パイプライン — エディターがAIレシピを使用してブログ記事を作成します。ワークフローが記事を生成し、承認ステップに到達します。マーケティングマネージャーは携帯電話でメールを受信し、要約を読み、会議の合間に承認をタップします。ワークフローは承認済み下書きからソーシャルメディア投稿とニュースレターコンテンツの生成を続行します。
財務取引ワークフロー — アナリストが自動化ワークフローを使用して請求書バッチを準備します。CFOはバッチ合計、明細数、ベンダー内訳の要約付き承認メールを受信します。ワンタップで承認すると、バッチは支払いシステムに移動します。
デプロイゲート — エンジニアが自動デプロイワークフローを通じて設定変更を提出します。DevOpsリーダーはdiffサマリーと環境ターゲット付きの承認メールを受信します。Slackのメール統合または受信トレイから直接承認します。
はじめに
メールベースの承認はすべてのプランで利用可能です。承認ステップのある任意のワークフローを開き、配信方法として「メール通知」を選択し、ワークフローを実行してください。指定された承認者はワークフローが承認ゲートに到達してから数秒以内にメールを受信します。
既に承認ステップを使用しているチームにとって、メール配信の有効化はステップごとのワンクリック設定変更です。ワークフローの再構築は不要です。