AIに基幹を任せる — preview→confirm→履歴→revert で作る安全なエージェント連携

全操作がWebAPIだから、AIは受注から出荷まで実行できる。暴走させないための"試す・承認・記録・戻す"の設計。

PREMISE基幹が「全部API」であることの意味

通販基幹エンジンでは、受注登録・在庫引当・販促適用・出荷確定といった業務操作が、すべて単一ゲートウェイのWebAPIとして開かれている。人がGUIで押すボタンの裏側と、外部システムが叩くエンドポイントは同じ入口を通る。この均質さが、AIエージェント連携の前提になる。

操作がAPIで揃っていれば、それぞれをLLMの関数呼び出し(function calling)やMCPツールとして薄く包める。ラッパは薄くてよい。認証やバリデーションは基幹側に既にあるので、ツール定義は「名前・説明・引数」を宣言するだけで済む。結果として、AIエージェントは受注を自分で登録し、在庫を引き当て、販促を適用し、確定まで一連の業務を"自律的に"実行できるようになる。

SAFETY暴走させないための4段構え

AIに実行権を渡すなら、失敗を前提にした安全弁が要る。ここでは4段の設計を組み合わせる。

• preview(下書き評価):AIの提案を未来日の下書きとして評価し、本番データに影響を与えずに効果を確認する。「この販促を入れると受注がどう変わるか」を実行前に見える化する。
• confirm(承認):人、あるいは事前ルールが承認して初めて確定に進む。AIの出力は"提案"であって"決定"ではない、という境界を明示する。
• 履歴(追跡):全操作が項目単位で記録され、どのエージェントがいつ何を変えたかを後から追える。監査と原因究明の土台になる。
• revert(復元):時刻バージョニングと冪等性により、いつでも安全に過去の状態へ戻せる。誤りが確定してしまっても、被害を巻き戻せる。

GUARDAIを信じすぎない — 冪等キーと基幹バリデーション

エージェントの出力は非決定的で、時に雑になる。同じ指示を二度実行したり、整合しない値を渡したりする。そこで各API呼び出しには冪等キーを持たせ、同一キーの再実行は結果を重複させない。加えて、値の検証はプロンプト側ではなく基幹側で行う。AIがどれだけ丁寧でも、最後の砦は業務ロジックに置く。

この二重の守りにより、二重受注や不正データは入口で弾かれる。「AIを賢くして防ぐ」のではなく「AIが間違っても壊れない」構造にするのが要点だ。

USECASEユースケース — 自然言語から自動受注まで

典型は自然言語の運用指示だ。「来週の在庫過多の商品に販促を組んで」に対し、AIは既存の設定を読み、衝突しない整合的な設定案を組む。それをpreviewで検証し、担当者が承認して反映する。人はゼロから作らず、AIの下書きを吟味する側に回る。

もう一つは自動受注だ。音声・チャット・メール・EDIといった多様な入口をAIが解釈し、受注APIへ橋渡しする。入口の形式に依存せず、後段は同じAPIと同じ安全ループを通る。

{
  "name": "create_order",
  "description": "受注を登録する。previewモードでは本番に確定せず効果のみ返す。",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_ref": { "type": "string", "description": "顧客参照キー" },
      "lines": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "sku": { "type": "string" },
            "qty": { "type": "integer", "minimum": 1 }
          }
        }
      },
      "idempotency_key": { "type": "string" },   // 二重実行を弾く冪等キー
      "mode": { "type": "string", "enum": ["preview", "confirm"] }
    },
    "required": ["customer_ref", "lines", "idempotency_key", "mode"]
  }
}

TRADEOFF払うべきコストと限界

この設計は万能ではない。previewは追加の計算と評価環境を要し、承認フローは運用者の手を挟むぶん即時性を犠牲にする。全自動の速さと、人が挟まる安全性は基本的にトレードオフだ。どこまで自動承認ルールに委ね、どこから人を要求するかの線引きが、運用設計の勘所になる。

さらに、プロンプトインジェクション対策・権限設計・監査ログの保全は、この4段とは別に必須で用意しなければならない。ツールにどの操作を露出するか、エージェントごとに権限をどう絞るかは、実行権を渡す前に決めておく。安全ループは"間違いを戻せる"仕組みであって、"悪意ある入力を防ぐ"仕組みではない。