【チームによるAI駆動開発の勘所：第5回】サービスをまたぐ整合性 - 「どちらも使えない」が正解のとき

複数のシステムやサービスにまたがる整合性をどう保つか。この問いに対して、多くの現場では「外部SaaSを使っているから、Saga（補償トランザクション）で行こう」と短絡している。記事の主張は、その判断順序が間違っているということだ。技術的事実（DBが分かれている、外部SaaSがいる）から入るのではなく、業務要件から問う順序でなければ誤る。同じケースを2つの順序で辿ると、別の答えに到達することがある。外部の決済SaaSと自社の売上計上が必ず同期していなければならない業務では、Sagaの宿命である「中間状態が外から見える」という特性そのものが業務要件に違反する。つまり「Sagaも基盤も使えない」という答えが出る。その場合、対処は「もっと便利なツールを探す」ではなく、「そもそも整合性境界の引き方を再検討する」という設計レベルの立ち戻りになる。

ここでAIの側面から見えるのは、AIが落とすタイプの異常系だ。AIは「正常系の一本道」は素早く書くが、失敗時の補償処理で特徴的なミスをする。冪等性を理解していない、中間状態を表現できない、他サービスのDBを直接読み書きしてしまう。こうした誤りは実はプログラマにもよくある。違うのは、AIはプロンプトで細かく指示すればするほど、指示に書かれていない異常系が増えるという点だ。ここが分散トランザクション基盤の本当の価値だ。例外が「決まった3つの分岐に閉じる」なら、プロンプトは短くてすむ。型に収まらない異常系は、そもそも設計に吸収させるという判断をしておく。

中小企業にとっては、複数システム連携で整合性が崩れるのはツール選択の問題ではなく、業務フロー設計の問題だという認識が重要だ。外部SaaSを使うなら、その制約（API仕様、応答遅延、失敗時の挙動）を最初から踏まえた上で、業務フロー自体を再設計する。「この基盤なら全部守られている」という思い込みで、フロー設計を投げ出さないこと。