承認フローを検収するとき、差し戻し・代理承認・取消も確かめる

承認フローの開発を検収するときは、申請して承認できることだけで合格にしません。申請中の内容変更、差し戻し、不在時の代理承認、取消、途中での権限変更、同じ申請への同時操作を試し、操作前の状態から期待した状態へ移るか、許されない操作なら元の状態を保つかを確かめます。

合否を分けるのは、「ボタンが押せたか」ではなく、「誰が、どの状態の申請に、どの条件で操作し、最後に何が一つだけ確定したか」です。発注時にこの組み合わせを受入条件として渡せば、納品時の認識差を減らせます。ただし、変更後に最初から承認し直すのか、どこまで戻すのかは業務ごとの決定が必要です。

承認フロー開発の検収は、画面ではなく状態遷移で決める

「申請中」「差し戻し」「承認済み」「取消済み」といった状態名だけでは、検収条件として足りません。同じ「承認」操作でも、申請者本人が行う、代理人が行う、権限を失った人が古い画面から行う、と条件が変われば、許可するか拒否するかも変わるためです。

OWASPの取引承認に関する公式ガイダンスは、複数段階の処理を所定の順序で進め、手順の飛ばしや順序変更を許さないよう、アプリケーションが状態遷移を制御する必要があるとしています（Transaction Authorization Cheat Sheet、2026年9月21日確認）。また、業務ロジック層では一般的な権限の有無だけでなく、その利用者が、その対象に、その時点の状態で操作できるかを確認する必要があると説明しています（Business Logic Security Cheat Sheet、2026年9月21日確認）。

したがって、発注者が用意する検収資料は画面一覧だけでなく、操作前状態、実行者、条件、操作、期待する状態、拒否時の状態を並べた表にします。要件を整理する段階では、システム要件定義の確認項目も併せて、業務上の決定と実装対象を分けておくと確認しやすくなります。

例外経路を含む状態遷移受入表

以下は、小規模な受託開発で発注者と開発者が検収条件を詰めるための運用上の提案です。業種を問わず必須となる網羅的な仕様ではありません。「または」とした箇所は実装側へ選択を任せず、自社が採用する一方へ書き換えます。期待する遷移と拒否時の状態を確定させて、見積依頼時の前提または納品時の判定表にしてください。

表を埋めると、「差し戻し後は誰が直すのか」「代理人が承認できる対象は何か」「承認済みを取り消せるのか」のような未決事項が現れます。各行には採用する条件を一つに絞り、対象外なら削除せず「対象外」と残します。発注者が決めずに開発側の解釈へ預けると、実装後に仕様変更なのか不具合なのかを判定しにくくなるためです。

申請内容を変えたら、変更前の承認を流用しない

金額や申請先など承認対象の内容を変更できる設計なら、変更前に得た承認をどう扱うかを先に決めます。運用上の提案としては、既存承認をそのまま残さず、すべて再承認するか、影響する段階まで戻す条件を明記します。

OWASPは、承認対象の取引データが変更された場合に、入力済みの承認データやチャレンジを無効にする、または承認プロセスをリセットする方法を、改ざん防止策の例として示しています（Transaction Authorization Cheat Sheet、2026年9月21日確認）。これは特定の方式をすべてのシステムに必須とする記述ではありません。発注者は、何を変えたらどの承認が無効になるかを、自社の判断として受入表へ書き込みます。

検収では、変更が許される場合と許されない場合を分けます。許される場合は、内容の更新だけでなく、古い承認が無効になり、決めた段階へ戻るところまで確認します。許されない場合は、変更操作が拒否され、申請内容と承認状態の両方が元のままであることを確認します。「編集ボタンが非表示」という画面上の確認だけで終えず、対象への操作そのものが成立しないことを受入条件にします。

代理承認と権限変更は、実行時点で確かめる

不在対応を「代理承認あり」とだけ指定しても、検収できません。代理できる対象、代理権限が有効な条件、代理操作後の状態、誰が実行したと記録するかを決めます。代理人が自分の申請も承認できるのかなど、対象との関係で拒否すべき条件も受入表へ追加します。自分自身の申請を承認できないことはOWASPが挙げる文脈依存の認可の一例であり、全業務に共通する網羅要件ではありません。採用するかは発注者の業務ルールによります。

権限確認は、画面を開いた時点だけでは不十分です。OWASPの認可ガイダンスは、権限をリクエストごとに正しく検証し、対象オブジェクトまたは機能へのアクセスを制御する必要があるとしています（Authorization Cheat Sheet、2026年9月21日確認）。

そこで、承認画面を開いたあとに承認権限を外し、そのまま古い画面から実行する検収を入れます。期待結果は、実行時点の権限と対象状態で拒否され、申請が進まないことです。代理承認、取消、差し戻しについても、画面を開いたあとに権限または申請状態を変え、古い表示のまま操作して確かめます。

同時操作では、勝ったボタンではなく最終状態を見る

同じ申請に対して、同時承認、承認と取消、承認と差し戻しを競合させます。運用上の提案として、どちらを優先するか、先に成立した操作だけを有効にするかを合意し、最終的に許された一つの状態だけが成立することを検収条件にします。

OWASPは、競合し得る二つのリクエストを実際に競合させ、最終状態の整合性を検証することを推奨しています。重要操作の記録については、認証済み利用者、対象、操作、結果、事後確認に足るリクエスト文脈と業務文脈を挙げています（Business Logic Security Cheat Sheet、2026年9月21日確認）。

さらに、取引の実行直前に適切な承認済みかを確かめる最終制御を実行処理へ結び付け、承認確認の飛ばしや、確認時と実行時の差を防ぐことも推奨されています（Transaction Authorization Cheat Sheet、2026年9月21日確認）。そのため検収では、各操作への画面応答だけでなく、確定した状態と、実行者・対象・操作・結果を後から追跡できることまで確認します。

見積依頼・納品・追加範囲を同じ表で判定する

見積依頼時には、受入表の各行を「今回実装する」「今回対象外」「業務判断待ち」に分けます。「業務判断待ち」は契約前に解消し、実装する行には操作前状態を作るための準備方法も確認します。画面数だけでは見えにくい例外経路を先に示せるため、開発側は必要な状態と権限制御を前提に見積もれます。見積項目の揃え方は、システム開発の見積もりを確認するポイントも参照できます。

納品時には、合意した各行について、操作前状態を作り、指定した実行者で操作し、期待する遷移または拒否を確認します。結果欄には合否だけでなく、確認した申請、操作した役割、操作前後の状態を残します。拒否ケースでは、エラーが表示されることだけでなく、内容と状態が変わっていないことも判定対象にします。競合ケースでは、片方の画面表示だけでなく、最終状態と追跡記録を確認します。

契約後に「承認済みからも取消したい」「代理権限の対象を条件で切り替えたい」と要望が出たら、受入表に同じ組み合わせがあるかを照合します。なければ直ちに不具合と決めず、追加範囲として状態、実行者、条件、期待結果を追記し、変更対象を合意します。反対に、表にある許可遷移が進まない、または拒否すべき遷移が成立するなら、合意済みの検収条件との差として扱えます。

検収後に残すのは、正常系が通ったという記録だけではありません。合意した六つの経路ごとに、採用した条件、期待結果、実際の結果を対応させます。表にある許可操作が成立しない、拒否操作で状態が変わる、一つであるべき最終状態が競合するなら、合意済み条件との差です。表にない状態・実行者・条件の組み合わせなら追加要望として切り出せるため、修正依頼の根拠と追加見積もりの前提を同じ資料に残せます。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る