陳腐化した承認：申請時は正しくても、数時間の承認待ちの後に押された押印は有効か

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。

この記事で扱うのは、既存の AI エージェント導入において最も見落とされやすい重大なセキュリティホールです。「エージェントがコマンド承認を申請してから、担当者が不在・会議から戻って「Allow（許可）」を押すまでの数時間の時間差（Time-of-Check to Time-of-Use, TOCTOU）」に潜むデータ乖離リスクです。

事故の現場：既存エージェント製品に潜む「盲目的な再開」の罠

水曜日の午前 10:00、カスタマーサポートの AI エージェントが、顧客クレームの対応中に Slack チャンネルまたは開発者 CLI へツール実行の承認通知を起票しました。「注文 #8821 に対する 68,000 円の返金処理を申請します。承認しますか？ [Allow / Deny]」。

この午前 10:00 時点でのエージェントの判断根拠は完全に正確でした。CRM 上の記録では返金は未実施であり、顧客のクレーム内容も正当で、社内返金ポリシーに合致していました。

しかし、実際の企業現場において、上長や担当者が 24 時間常に画面に張り付いていることはあり得ません。

• サポート部門の責任者は、その直後から 2 時間に及ぶ役員報告会議に出席していました；
• 承認待ちで放置されていたこの 2 時間の間に、顧客が直接店舗窓口に来店し、店舗スタッフが POS レジにて現金で返金手続きを完了させた；
• あるいは午前 11:00、別の運用担当者がトラブル対応の一環として、該当の注文を手動で対応完了（ステータス変更）として処理した。

正午 12:00、会議を終えて自席に戻った責任者は、Slack に 2 時間前から残っていた通知「エージェントが 68,000 円の返金を申請」を目にします。案件の経緯を思い出し、内容に問題はないと判断して [Allow] をクリックしました。

市場に流通する多くの既存エージェント製品において、まさにこの瞬間に重大インシデントが発生します。 多くのエージェント基盤は、人間による「Allow」のクリックを、単に停止していたワーカープロセスを再開させるためのフラグ（Unpause）としてしか扱いません。ボタンが押された瞬間、エージェントは 2 時間前に生成された古い API ペイロードをそのまま盲目的に外部決済ゲートウェイへ送信します。その結果、店舗ですでに現金返金済みの注文に対して、さらに 68,000 円が二重返金されて直接的な金銭損失を招きます。

この障害は、AI のプロンプトインジェクションやハルシネーションによるものではありません。責任者のビジネス判断も 2 時間前の情報としては妥当であり、エージェントも指定されたツールの範囲内で動いていました。単に**「承認の申請」と「人間の承認」の間に必然的に発生する時間差があり、既存システムが 2 時間前の古いスナップショットを盲信してしまった**のです。

決済 API 自体の保護で防げること、防げないこと

上の事故には決まった反論があります。「決済ゲートウェイには冪等キーと返金上限があるのだから、二重返金にはならない」。正しく、しかし足りません。ゲートウェイが防げるのはゲートウェイ自身に見える二つのことで、事故の原因は見えない三つ目にあります。

ゲートウェイが知っているのは「このカード決済にはまだ 68,000 円の返金余地がある」ことだけで、顧客が 10:40 に店舗で現金を受け取ったことは知りません。三つ目の層は、稟議書を持つ側が書き込みの前に CRM と注文記録へ戻って確かめるしかありません。GembaOS は三層すべてを行います。相手が冪等キーを認識するなら相手のキーを使い（キーは GembaOS が稟議 ID と作業票 ID から生成します）、認識しないなら GembaOS 自身が一度だけ送ることを保証します。上限は書き込み前に相手から返金可能額を読んで比べ、相手自身も上限を強制する場合は記録にそう書きます。承認時の前提は書き込み前に項目ごとに読み直して突合します。

「人間の承認済み」は「盲目的な実行許可」ではない

多くのエージェント製品やワークフロー基盤は、「Slack やチケット上で Allow が押された」ことを、そのまま「直ちに API を叩いて書き込んでよい」と同義と捉えています。この二つを混同することが、重大な本番障害を引き起こす原因です。

承認が保証するのは、「その時点のビジネス判断として適切である」という点までです。「今、この実データに対して、1 回だけ安全に書き込んでよい」という実行時の保証は、堅牢なガバナンス実行基盤が担う必要があります。

GembaOS が承認タイムラグの窓をどう狭めるか

GembaOS のアーキテクチャは、**「人間の判断には必然的に非同期な遅延（数分、数時間、あるいは翌朝まで）が伴う」**という現実を起点に設計されています。そのため、GembaOS は承認ボタンを古いデータの無条件な実行トリガーとはみなしません。

[エージェントがツール呼び出しを起票] 
       │ （基幹データのバージョンと前提アサーションを添付）
       ▼
┌──────────────┐      ┌──────────────────────────┐
│  AI が事実を  │ ───> │ 人間の非同期判断（会議・離席）│
│   整理固定   │      │                          │
└──────────────┘      └──────────────────────────┘
                                   │
                              [責任者が承認]
                                   │
                                   ▼
                      ┌──────────────────────────┐
                      │  AI モデルは実行経路から  │
                      │       完全に離脱         │
                      └──────────────────────────┘
                                   │
                                   ▼
                      ┌──────────────────────────┐
                      │ GembaOS ガバナンスカーネル│
                      │ 1. 基幹 DB の現物を再読み込み│
                      │ 2. 前提アサーションの差分検証│
                      │ 3. 許可証の有効期限（TTL）検証│
                      │ 4. 対象レコードの排他ロック   │
                      │ 5. カーネルが一意な冪等キー注入│
                      └──────────────────────────┘
                                   │
                         [現物データと前提が一致]
                                   ▼
                      ┌──────────────────────────┐
                      │  外部 API へ安全に書き込み│
                      └──────────────────────────┘

相手の接続先が与える保護の分だけ、GembaOS が引き受けるもの

接続された書き込み操作は、接続先の契約に二つのことを宣言します。リトライが安全か（冪等、キーによる冪等、再試行不可）、そして相手が古い読み取りに基づく書き込みを拒否できるか（バージョン、条件付き書き込み、何もない）。GembaOS は宣言に応じて振る舞いを選び、どれを選んだかをその実行の記録に書きます。

三行目が企業の大半です。GembaOS に同梱の接続設定 12 件のうち 9 件は「何もない」と宣言しています。接続先の仕組みがそうだからです。支払ファイルには冪等キーという概念自体がなく、同じファイルを二度置けば二度支払われるので「再試行不可」と宣言され、タイムアウト後に GembaOS がもう一度置くことはありません。

保証されること、そして閉じずに狭めているところ

何の保護もない接続先に対しても、次の三つは成り立ちます。

• 一度だけ送る。 許可証は一度しか消費されず、実行は「予約 → 実行 → 消費」の順に進みます。再試行不可と宣言された操作はタイムアウト後に再送されず、その実行は「未確認」として不足台帳に載り、その業務の責任者が確かめます。
• 前提が変わっていれば書かない。 書き込み前に GembaOS 自身がレコードを読み直し、承認者が押印時に見た内容と項目ごとに比べます。違えば許可証を失効させ、稟議書を差し戻します。
• GembaOS 経由の書き込み同士はぶつからない。 同じレコードへの二つの承認済み操作は、一方がリースを持つ間もう一方が待ちます。許可証の期限までリースを得られなければ差し戻されます。

閉じずに狭めているのは一か所だけです。GembaOS の外にいる書き手——店舗のレジ係、ERP の画面でレコードを手で直す同僚——が、「読み直し」から「書き込み」までの数十ミリ秒に割り込む場合です。GembaOS はこの窓が閉じているとは言わず、記録します。実行ごとの ExecutionChecked 事象に、どの保護で書き込みを支えたか（相手のバージョン、相手の条件照合、GembaOS 自身のリース）、窓が何ミリ秒だったか、書き込み後の読み戻しが何を示したかが書かれます。読み戻しが一致しない、あるいは読めない場合は黙って通らず、「未確認」の記録として人が見るものになります。

承認者が決裁時に目にするもの

この防御機構は、裏方の見えないブラックボックスではなく、承認者の画面上に明示されます。

稟議画面には、タイムラグ対策のパラメータが明確に表示されます。

• 有効期限：この決裁が有効である時間枠（例：30分間）；
• 実行回数：多重決済を防ぐための厳格な「1回のみ」の制限；
• 実行直前の照合項目：API 呼び出し直前に、現物データベースと突き合わせる必須フィールド一覧。

まとめ

承認までの待機時間は、単なるユーザー体験（UX）の問題ではなく、企業の資産安全に関わるシステム整合性の根本問題です。

人間が判断に関わる限り、時間の経過は避けられません。その経過時間の間に、レコードは書き換わり、同僚は並行して作業し、上限値は変動し、通信はリトライを発生させます。

「Slack で Allow が押されたからそのまま再開する」という既存の素朴なアプローチでは、これらのリスクを何ひとつ防げません。GembaOS の答えは明確です。人間の承認を「その特定時点におけるビジネス判断の是認」として位置づけ、ガバナンスカーネルが書き込み直前の最後の 1 ミリ秒で「その前提が現在の現実世界でも依然として成立しているか」を厳格に再照合し、確かめられなかったところには人のための記録を残すことです。