ワークフロー・オーケストレーションの設計：冪等性と補償トランザクション

自動化ワークフローの品質は、すべてが順調に進むときではなく、途中で失敗したときにどう振る舞うかで決まる。複数のステップを連鎖させる処理では、あるステップが失敗したとき、それまでに実行した処理をどう扱うかという問いが避けられない。本稿では、冪等性の確保と補償トランザクション（Saga パターン）という二つの設計概念が、なぜ後付けでは困難なのかを技術的に説明する。

冪等性：同じ処理を二度実行しても安全か

分散した処理では、あるステップが成功したかどうかが不確実になる瞬間がある。ネットワークの切断や応答の遅延により、処理は完了したのに完了通知が届かない、という状況が起こりうる。このとき、システムは再実行すべきか判断できない。安全に再実行するための性質が冪等性である。同じ操作を何度実行しても結果が変わらないなら、通知が届かなくても再送すればよい。

冪等性は、後から付け加えるのが難しい性質である。冪等性という概念自体は、HTTP のメソッド定義（RFC 9110 として標準化された仕様）でも、同じ要求を複数回送っても副作用が一度分にとどまる性質として明示されている。たとえば「残高に千円を加算する」という操作は、そのままでは冪等でない。二度実行すれば二千円加算されてしまう。これを冪等にするには、操作に一意な識別子を持たせ、同じ識別子の操作を二度処理しないよう記録する仕組みが要る。この仕組みは、処理を設計する最初の段階で組み込まなければ、後から全体に導入するのは大掛かりな改修になる。もっとも、すべての操作を冪等にする必要はなく、再実行の可能性がある境界を見極めて集中的に設計するのが現実的である。

部分的な失敗という難問

単一のデータベース内であれば、トランザクションによって「全部成功するか、全部なかったことにするか」を保証できる。ところが、複数のサービスや外部システムにまたがる処理では、この保証が働かない。三つのステップのうち二つが成功し、三つ目で失敗したとき、成功した二つをどう扱うかという問題が残る。何もしなければ、システムは中途半端な状態で放置される。

この部分的失敗の問題は、自動化ワークフローが単純なスクリプトから本格的な業務処理へ育つ過程で、必ず直面する壁である。RPA からエージェントへの移行で例外処理の重心が移動するのと同様、複数システムにまたがる処理では、失敗の扱いが設計の中心的な関心事になる。表面的には正常に動いているように見えても、部分的失敗への備えがなければ、いずれ整合性の崩れが顕在化する。

補償トランザクション（Saga）という考え方

分散した処理で全体の整合性を保つ有力な手法が、補償トランザクション、いわゆる Saga パターンである。この概念は、長時間トランザクションを扱う研究（Garcia-Molina と Salem による1987年の研究として知られる）に起源を持ち、各ステップに対して、それを打ち消す「補償処理」をあらかじめ用意しておく。処理が途中で失敗したら、それまでに成功したステップの補償処理を逆順に実行し、全体を矛盾のない状態へ戻す。データベースのロールバックを、複数システムにまたがって手続き的に再現する発想である。

ただし、補償処理は元の処理を単純に逆にすればよいものではない。「メールを送る」という処理の補償は「送ったメールを取り消す」ことができないように、現実には打ち消せない操作が存在する。こうした操作は、そもそも失敗の可能性が低い段階まで遅らせるか、取り消し不能であることを前提に設計する必要がある。とはいえ、補償処理をすべての操作に用意する労力は小さくなく、どこまで厳密に整合性を保つかは業務上の要求とのバランスで決まる。

可観測性なしには回らない

冪等性と補償トランザクションを設計しても、それらが正しく機能しているかを観測できなければ運用は成り立たない。どのステップがどの順で実行され、どこで失敗し、どの補償が走ったか——この履歴が追跡できて初めて、複雑なワークフローの障害に対処できる。可観測性は、冪等性や補償処理と並ぶ、後付けの難しい設計要素である。

特にエージェントを組み込んだワークフローでは、判断の履歴も含めて記録する必要がある。エージェントの信頼性を支えるのも、結局はこの可観測性である。処理が確率的になるほど、何が起きたかを事後に再構成できることの価値は高まる。

結論：失敗への備えは最初に埋め込む

ワークフロー・オーケストレーションの設計思想は、失敗を例外ではなく前提として扱う点に集約される。冪等性・補償トランザクション・可観測性は、いずれも処理が順調なときには目立たないが、失敗したときに全体の整合性を守る土台になる。そしてこれらはいずれも、後から付け加えるのが困難な性質である。自動化を単純なスクリプトから業務処理へ育てるなら、失敗への備えを最初の設計に埋め込むこと——それが、後々の大規模な作り直しを避ける唯一の道になる。