処理を自動化しても、必ずしも人の介入なしに実行する必要はありません。重要なデータの変更、商取引上の条件の適用、資金の移動、第三者への影響が生じる可能性がある操作は、人の承認を待つべき場合があります。PHP自動化における人的承認フローを設ければ、メッセージや判断が非公式に積み重なり、後から経緯を追えなくなる事態を避けながら、こうした制御を実現できます。
重要なのは「承認」ボタンを追加することではなく、何を提案し、誰が、どの情報に基づいて、どれだけの時間内に判断し、その後何が起きるのかを定義することです。システムは各状態を説明できなければなりません。また、古い承認や重複した承認によって、レビューされたものとは異なる操作が実行されないようにする必要があります。
操作を一時停止するタイミングを決める
事後レビューは、操作の実行後に問題を検出するためのものです。一方、事前承認では、判断が得られるまで実行を停止します。潜在的な影響、操作の取り消しにくさ、不確実性が、自動化に許容される水準を超える場合は、承認を必須にするのが適切です。
各操作について、具体的な問いを使って評価します。復元が難しいデータを変更する可能性はあるか。金銭、権利、アクセス権、顧客との約束に影響するか。自動実行を認める検証可能なルールがあるか。誤りによる損害はどれほどで、対応までにどれだけの時間があるか。定型的で取り消し可能かつ影響範囲が限定された操作は、自動実行して記録を残し、後からレビューできる場合があります。例外的または影響の大きい操作は、実行前の承認を必須にできます。
すべての操作に一律で人的制御を適用するのは避けてください。キューが滞留すると遅延が生じ、承認が機械的に行われるようになります。しきい値と例外を定め、保留件数、待ち時間、却下件数、期限切れ件数を測定して、調整すべきルールを特定します。判断の根拠は、操作が技術的に可能かどうかだけでなく、実際のリスクであるべきです。
提案内容と承認可能な範囲を定義する
レビュー担当者が理解すべきなのは操作の影響であり、PHP内部のオブジェクトを読み解くことではありません。現在値と提案値、理由、データの出所、関連する影響、制約を提示します。判断がルールに依存する場合は、その適用に必要な説明を示します。不要な個人データは非表示にするか、保護してください。
提案コマンドと承認を分離します。提案は操作とそのパラメーターを記述し、承認はその具体的な提案の実行を許可します。包括的な権限を与えたり、承認者がパラメーターを気づかれないまま編集できたりしてはなりません。変更が必要な場合、レビュー担当者は変更を依頼できます。その場合、システムは更新された提案を作成し、適用される承認ルールに従って再審査します。
最小権限を適用し、提案の作成、承認、却下、キャンセルができる人を制限します。また、状態遷移のたびにサーバー上で権限を確認してください。リスクに応じて、提案者が自分の操作を承認できないようにします。この分離は権限ロジックに実装し、インターフェース上でボタンを隠すだけに依存してはなりません。
状態と遷移を明示的にモデル化する
プロセスを状態機械として表現します。初期状態の例として、pending、approved、executing、rejected、changes_requested、expired、cancelled、executedを設定できます。保留中の提案は承認、却下、キャンセル、または期限切れになり得ます。承認済みの提案は、引き続き有効な場合に限って実行に進めます。実行中の提案は、実行済みになるか、効果がなかったと確認された場合に復旧可能な状態へ戻ります。実行済みの提案を再承認することはできません。
現在の状態とともに、判断と状態遷移の変更不能な履歴を保存します。提案ID、遷移前後の状態、実行者、日時、理由、レビュー対象データのバージョンへの参照を記録します。レコードの更新時に履歴を置き換えてはなりません。何が起きたかを監査し、障害を診断するために必要です。
PHPでは、ドメインサービスまたは同等のコンポーネントに状態遷移を集約します。複数のコントローラーが汎用的な更新処理で直接状態を変更する構成は避けてください。必要に応じてトランザクション内で遷移と権限を検証し、現在の状態と矛盾する操作を拒否します。この構成により、競合によるエラーを減らし、インターフェースに依存せずルールをテストしやすくなります。
古い承認と重複実行を防ぐ
提案が保留されている間にデータが変更される可能性があります。実行対象の操作と一致しなくなった条件を承認者が承認してはなりません。提案の作成時に、バージョン、更新日時、または関連フィールドのフィンガープリントを保存します。承認時には、現行の状態と照合してください。
承認時の確認だけでは不十分です。操作を適用する前にデータが変わる可能性があります。実行の直前に、現行のバージョンまたはフィンガープリントを承認済みのものと再度比較します。一致しない場合は処理を停止し、その提案に対する承認を無効にして、更新後のデータに基づく新たな判断を求めます。リスクに応じて差分を提示し、明示的な再確認を求めることはできますが、以前の承認を自動的に再利用してはなりません。
有効期限を設けることで、判断が有効と見なされる期間を制限できます。期限が切れたら提案を期限切れとして記録し、処理を続けるには新たな承認を必須にします。再試行のたびに承認が有効であることを確認してください。期限切れの承認を再開や再実行に再利用してはなりません。
承認は識別可能な提案にひも付け、再利用可能な合図にしてはなりません。複数のワーカーが同じ提案を実行するのを防ぐには、approvedからexecutingへの遷移を原子的に取得またはロックします。提案が引き続き承認済みかつ有効な場合に限り、取得できるワーカーは1つです。このローカルな保護では、冪等性も確認し、一意な操作IDを記録してから処理を続けます。これによりシステム内の重複は防げますが、データベーストランザクションだけでは、外部APIが効果を一度だけ適用することは保証できません。
別のサービスで操作を行う場合、そのサービスが対応していれば、受け付けて冪等に処理する冪等性キーを使用します。相関ID、試行回数、応答を記録してください。応答が失われた場合や結果が不明な場合は、効果をむやみに再実行せず、そのIDでリモートの状態を照会するか、信頼できるデータと結果を照合します。効果が発生したか確認できない場合は、自動再試行を停止し、運用担当者に引き継いでください。リクエスト送信前に障害が発生したと判明している場合は、状態と承認を再確認すれば、再試行できることがあります。
ワーカーの障害によって提案がexecutingのまま残っても、自動的に実行済みにしたり、診断なしに再送したりしてはなりません。復旧プロセスでは、ローカルの記録を使い、必要に応じてリモートサービスにも問い合わせて、効果が発生したかを判断します。発生していないと確認できた場合は、有効期限、データ、承認を再検証した後に限り、提案を実行可能な状態へ戻せます。結果が不明のままなら、提案をブロックした状態に保ち、エスカレーションします。
運用キューと手動の代替手段を設計する
キューでは、保留期間、影響度、担当者、期限で絞り込めるようにし、判断の根拠となるコンテキストも表示します。なぜケースが停止しているのか、待機、変更依頼、キャンセル、エスカレーションのどの対応が適切なのかを説明してください。インターフェースでは判断ボタンを提示するだけでなく、承認後に何が起きるかも明確にします。
通知サービスや操作実行に必要な連携など、依存先に障害が発生した場合の代替手段を定めます。提案を保留のまま維持し、利用可能な運用システム上で、権限を持つ担当者がケースを確認するための管理された手順を用意できます。手動経路でも同じ検証を行い、実行者と理由を記録し、並行実行を防ぎ、連携の復旧後に結果を照合する必要があります。
技術的な障害を暗黙の承認にしてはなりません。ID、権限、必要な情報を検証できない場合、システムは安全側に倒し、処理を一時停止して通知し、エスカレーションする必要があります。誰がプロセスを再開できるのか、その介入をどのように記録するのか、サービス復旧後にどの作業を確認すべきかを定めてください。
フローをテストし、稼働状況を監視する
ドメインルールと一連の処理をテストします。承認、却下、変更依頼、期限切れ、キャンセル、再試行を対象にしてください。権限のない人が状態を変更できないことを確認する権限テストと、同時に行われた2つの判断から二重実行が発生しないことを確認する並行性テストも追加します。
保留中または実行直前にデータが変更されるケース、リモート実行がリクエストを受け付けた後に失敗するケース、効果が発生したにもかかわらず応答が失われるケースも含めます。原子的な取得によって提案を実行するワーカーが1つだけになること、再試行時に期限切れの承認が拒否されること、各手動介入に十分な記録が残ることを確認してください。本番環境では、保留件数と経過時間、期限切れ、実行エラー、照合が必要なケースを監視します。
適切に設計されたフローは、チームの記憶に安全性を委ねることなく、人の監督が制御に役立つ場面でそれを維持します。明示的な状態、分離された権限、有効なレビュー済みデータ、冪等な実行、障害時の明確な手順により、非公式な承認を検証可能なプロセスにできます。
