承認ワークフロー

実務では

承認ワークフローはワークフローソフトウェアよりはるか以前から存在する。購買申請、変更諮問委員会、与信委員会、治験のサインオフは、いずれも同じパターンを体現している。本物の承認ワークフローと、それらしく見えるだけの通知とを分ける性質が三つある。第一に、リクエストが保留中の間、変更は実際にブロックされなければならない。メールが未読のまま放置されている間に変更が進んでしまうのではいけない。第二に、判断は共有メールボックスではなく、判断したその時点で権限を持っていた個人に帰属できなければならない。第三に、ルーティングは名前ではなく組織に対して解決されなければならない。特定の人に結び付けたチェーンは、次の組織変更で静かに壊れ、すでに退職した人へ回されてしまうからだ。どれ一つ満たさないプロセスは、遅延付きの通知にすぎない。

ObjectStack における承認は独立したシステムではなく、フローの中の永続的なノードである。実行が承認ノードに到達するとリクエストを作成して一時停止し、判断が記録されると approve または reject の出力エッジに沿って再開する。承認者はユーザー、ロール、チーム、または申請者の上長階層として宣言され、リクエスト時点の実際のアイデンティティに対して解決される。役職は、その時点でそれを担っている人に展開される。各ステップは自身の振る舞いを設定するため、あるノードは「最初の応答で決定」、次のノードは「全員一致」とすることができる。lockRecord はレコードを固定し、誰もレビュアーを飛び越えて編集できないようにする。maxRevisions は差し戻しループに上限を設け、リクエストが「修正してください」の周りを永遠に回り続けないようにする。onEmptyApprovers は承認者の候補が誰にも解決されなかった場合の扱いを決め、デフォルトではレコードを黙って通過させるのではなく管理者による救済に回す。判断は実行が進む前に監査台帳へ書き込まれるため、判断が記録されないまま承認を通り過ぎる経路は存在しない。承認ノードが扱うのは、値引き、返金、購買といったビジネス上の判断である。AI がアプリそのものに加える変更は、別の経路で人のもとに届く。オープンソースの ObjectStack では、コーディングエージェントの変更は誰かがレビューする git diff 上のメタデータであり、ObjectOS Cloud では、すでにレコードを持つ稼働中のアプリへの AI Builder の変更は、人が公開するための下書きとして保存される。これこそが、エージェントが書いたソフトウェアを、後から発見するものではなく、人が署名できるものにしている。

どの承認エンジンにも問う価値があるのは、その期限がどこにあるのかであり、ここでの正直な答えは範囲が狭い。フロー内の wait ノードにはタイムアウトがまったくない。かつてタイムアウトがあると謳う二つのキーがあったが、ランタイムが守らない約束として残すのではなく、どちらも廃止された。エスカレーションは承認ノードにのみ存在し、グローバルなタイマーサービスではなくノードごとの SLA として働く。timeoutHours を設定すると、スイープ処理が作成からその時間数を過ぎてもまだ保留中のリクエストを見つけ出し、それぞれを生涯で最大一度だけエスカレーションして、設定されたアクション——notify、reassign、auto_approve、auto_reject——を実行する。escalateTo はユーザー、またはその時点の担当者に展開される役職を指定する。エスカレーションの監査行が先に書き込まれるため、クラッシュしたスイープや繰り返されたスイープが二重に発火することはない。設計上の帰結ははっきり言っておく価値がある。あるステップに時間制限が必要なら、SLA 付きの承認としてモデル化するか、フローの外から期限を駆動すること。単なる wait は、辛抱強く、正しく、そして永遠に待ち続ける。