冪等性 — 一度の押印が、二回の書き込みにならないために

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。この記事が扱うのは、エージェントが実損を出す経路のうち、いちばん地味なものです。正しいことを、二回やってしまう。

冪等性とは何で、なぜエージェントに必要なのですか

冪等性（べきとうせい）とは、繰り返し実行しても一度だけ実行したときと同じ結果になる性質のことです。エージェントにこれが要るのは、再送が異常ではなく日常だからです。呼び出しがタイムアウトし、クライアントが再送する。流量制限で弾かれ、何かが再試行する。書き込みは出たが応答が返る前にプロセスが再起動する。あいまいなツール結果を受けて、モデルがその手順をもう一度計画する。

どれもエージェントの不正ではありませんし、権限の判定では一つも捕まりません。そのエージェントはその呼び出しをしてよいのです。ただ、二回しているだけです。

冪等キーはどこから作るべきですか

試行からではなく、承認からです。設計上の判断はこれがすべてで、よくある誤りは呼び出しの中で生成することです。UUID やタイムスタンプから作ると、再試行では別の値になり、相手システムは新しい依頼として受け取り、重複が書かれます。キーは両方の試行で同じでなければならず、それはつまり、どちらの試行よりも前から存在していたものから作られなければならない、ということです。

GembaOS は三つ目を採ります。キーは稟議書と作業票から GembaOS 実行基盤側で組み立てられるため、エージェントはそれを選ぶことも変えることもできません。同じ金額でも稟議が別であれば、キーも別になります。

統制された実行は、実際に何を保証していますか

「一度の押印は、多くとも一回の書き込み」という一文の背後には、層の違う三つの仕組みがあります。GembaOS の内側では、ワンタイム許可証が一回限りです。承認された操作を実行すると消費され、同じ許可証による二回目は拒否され、そのことも記録されます。相手システムの内側では、冪等キーによって再送が同じ一件として着地します。どちらも使えないシステムでは、アダプターが自分の書き込みが何に守られているか（版番号、条件付き書き込み、実行中の記録の押さえ）を宣言します。

記録に残る報告行は、その二つを名指しします。どの許可証のもとで書き込まれたか、そして稟議書と作業票から導かれた実行キーは何か。あとからこれを読む監査担当者は、「再送はうまく処理されたはずだ」と信じる必要がありません。安全にした当のキーが、記録の上にあります。

一括処理の場合はどうなりますか

重複がいちばん高くつくのは一括処理です。一部が失敗したあと、人はまず「もう一度流す」を選ぶからです。GembaOS では一つの承認が一覧全体を覆うことはできますが、各行はその承認のもとで、それぞれ独立した作業票として記録に残ります。

三件は成功し、一件は対象システムが「その口座は存在しない」と答えたために失敗し、その行については何も実行していないことが明記されています。件数、行ごとの状態、共有された承認がすべて記録の上にあるため、「結局どの行が実際に行われたのか」という問いに、ログを読まずに答えられます。

まとめ

冪等性は HTTP クライアントの細部ではありません。業務システムに書き込むエージェントにとっては、権限の一部です。人が一度署名した判断は、その間にネットワークが何をしようと、一回の書き込みになるべきだからです。エージェント基盤を見分ける実務的な問いは短くて済みます。冪等キーはどこから来るのか、と聞いてください。答えが「エージェントが生成します」であれば、その基盤はこの問題を解いていません。ずらしただけです。