- 公開日
入札を行うAIエージェントには、一回の入札額だけでなく、同時に成立し得る入札の総額と追随回数にも上限を置きます。上限は実行直前にシステム側で検査し、異常値や状態不明があれば新しい入札を止めます。停止した後も、既に受け付けられた入札が撤回されたかは別に確かめる必要があります。
以下は市場に接続しない架空の教材用設計です。金額や時間は説明用の仮定値で、入札戦術、投資判断、実サービスの利用許可を示すものではありません。模擬試験も実施しておらず、示すのは期待される動作と確認方法です。
自動入札と上限の自動変更を分ける
オークション側が、利用者の指定した最高額まで代理で入札する仕組みと、Agentがその最高額を引き上げる処理は分けて管理します。eBay.comのAutomatic biddingは、設定した最高額までの自動入札と、送料を考慮する必要を説明しています。この説明を、すべてのオークションの仕様として扱うことはできません。
相手に追い越されたという情報だけで、新しい予算を承認済みにはできません。「落札するまで続ける」を目標にするときも、最高額を超えたら落札を諦める条件を残します。提案を作るモデルと、送信を許可する実行器を分け、モデルに上限の変更権限を持たせない構成を考えます。
OWASPのExcessive Agencyは、過剰な機能・権限・自律性を区別し、必要な権限への限定と下流での認可、人による高影響操作の確認を勧めています。以下の金額予約や停止手順は、その考え方を入札へ適用した設計案です。特定サービスの標準機能や法的義務を意味しません。反復やツール呼び出しの費用を環境側で止める仕組み全般は、Agentの反復とツール呼び出しに費用上限を設ける方法で扱っています。
一件の最高額と総額を同時に守る
入札ごとに、対象ID、通貨、数量、単価か総額か、手数料・税・送料、実行主体、許可期限を固定します。表示価格と、成立した場合に負担する最大額も分けます。代理入札の表示額が低くても、その裏で設定した最高額までは負担が増える可能性があるためです。
総額の計算には、成立済みの負担、受付済みで未決着の入札、送信中で結果が分からない入札、新しい提案を含めます。一方、同じ品物への最高額変更を新旧二件として数えるかは、サービスの置換規則によります。旧入札が残る可能性を確認できない間は、勝手に差額だけへ減らしません。
複数のAgentが共通予算を使う場合、全員が同じ残額を見て同時に通過することも考慮します。実行器が予算枠を一括管理し、判定と枠の確保を他の要求に割り込まれない処理にする設計が必要です。モデルへの「予算を守る」という指示や、超過後の通知だけでは、この競合を制御できません。
異常値は金額上限だけで判定しません。桁の増加、通貨の変更、増分単位との不一致、数量の変化、情報の古さ、同じ更新の重複受信を確認します。基準価格からの急な変化を検知した場合も、悪意や故障と断定せず、対象と原データを照会します。上限内の値でも、別通貨や古い情報に基づく提案なら送信を保留します。
市場に接続しない条件を固定する
模擬環境には送信用の本番資格情報を置かず、外部の入札先へ接続しない構成を前提とします。教材の対象Aと、別対象B・Cを使い、同時に落札する可能性を認めます。次の条件は比較中に変えません。
| 項目 | 架空の条件 |
|---|---|
| 通貨・数量 | JPY、各対象一個。換算は行わない |
| Aの一回の最高入札額 | 20,000円以下。付帯費用は別枠で2,000円固定 |
| 全対象の総額上限 | 付帯費用込み45,000円以下 |
| B・Cの確保済み枠 | 合計28,000円。取消や失効を確認するまで維持 |
| Aの初回提案 | 最高額15,000円。画面の現在価格は12,000円 |
| 追随 | 初回を除いて二回まで。更新は1,000円刻み、最低30秒間隔 |
| 情報の有効性 | 対象IDが一致し、模擬時計で取得から五秒以内 |
| 模擬期間 | 開始から600秒で終了。取消受付は480秒未満に限定 |
同じ対象の最高額更新は、模擬サービス内で旧値を新値へ一括置換し、有効な入札を一件だけ保持する設定です。取消は、模擬サービスが対象の未決着を確認し、撤回済み状態を保存した場合に成立するものとします。これは実在サイトの取消規約ではありません。各時点の判断は模擬サービス側の時計を基準にし、Agentの送信時刻だけで期限内と決めません。
Aの初回に必要な枠は15,000＋2,000＝17,000円です。28,000＋17,000＝45,000円なので、他の条件も合えば初回は許可候補になります。現在価格12,000円を使って残額を多く見積もることはしません。付帯費用が固定できなくなれば計算の前提が崩れるため、金額を推測して通過させず人の確認へ戻します。
実サービスでは規約、対象の条件、本人の権限と具体的な承認、適用される制度を別途確認します。
条件を変えて停止と引き継ぎを確かめる
次の行は独立したケースです。入札の各行では同じ初回提案を基準に金額や情報を変え、取消の各行ではAが15,000円で受付済み・未決着の状態から時点や応答の有無を変えます。連続した試験結果ではなく、実行器の判定と模擬サービスの状態を照合する計画です。
| 変える入力・状態 | 期待する判定と次の対応 |
|---|---|
| 初回15,000円、必要条件がすべて一致 | 枠を確保し、模擬受付IDで対象・金額・受付状態を照合する |
| 相手の更新に追随して16,000円を提案 | 総額が28,000＋18,000＝46,000円となるため拒否。上限を自動で増やさない |
| Aへ150,000円を提案 | 一回上限と総額上限の不適合を記録し、新規送信を阻止。桁や原入力を人が確認する |
| 金額は同じだが通貨がUSD、または情報が六秒前 | 換算や補完を行わず保留。正しい通貨と新しい原データを取得できるか確認する |
| 470秒で取消を要求し、撤回済み応答と状態を確認 | 新規追随を止め、Aの枠を解放できるか確定状態から判定する |
| 490秒で取消を要求 | 期限外として保留・引き継ぎ。追随停止と、Aの入札が残ることを別々に報告する |
| 470秒の取消に応答が返らない | 撤回済みと扱わず枠を維持。受付ID・対象IDで照会し、結果不明を人へ伝える |
追随回数にも、金額とは独立した確認が必要です。B・Cの枠がない別の比較では、Aの最高額15,000円から16,000円、17,000円への二回の更新は、金額条件だけなら範囲内です。三回目の18,000円は、一回・総額上限内でも回数条件で拒否します。待機間隔を満たさない要求も送信しません。この比較ではB・Cの枠をゼロにし、更新の間隔と情報の有効性は満たすものとします。総額超過と回数超過を別々に確かめるための条件です。
回数は応答が成功した時だけ数える設計にしません。送信後に結果が不明になった更新も、実行され得る一回として保持します。同じ価格通知の重複を新しい追随機会として扱わないこと、停止後に待機中の提案が送信されないことも、模擬サービス側の受信記録で確かめます。
止めたことと撤回できたことを区別する
停止はこれからの行動を制御する措置です。既に成立した入札や支払義務を消せるとは限りません。eBay.comのRetracting a bidでも、撤回には理由・時間・カテゴリーによる制限があります。実サービスへ移す際は対象の現行条件を確認し、期限だけで取消可能と判断しないことが必要です。
タイムアウトも失敗の証拠ではありません。AWSの冪等API設計が説明するように、応答を受け取れなくても副作用が生じている可能性があります。冪等性とは同じ意図の要求を繰り返しても重複適用しない性質ですが、その成立にはサービス側の仕組みと契約が必要です。受付IDがあるだけで再送が安全になるわけではありません。
取消結果が不明なら、入札と取消要求を別々の状態として保存します。「追随停止済み、Aの撤回は未確認、17,000円の枠は保持中」と返せば、担当者は残っている負担を判断できます。先の要求が遅れて実行される可能性を解消できず、重複適用防止の条件も確認できないときは、入札も取消も機械的に繰り返しません。
再開を判断する人と記録を決める
業務責任者は対象・予算・承認期限を決め、開発担当者は実行前の検査と停止経路を実装します。運用担当者は異常時に新規送信を止め、入札先の状態を照会します。再開の承認者は、残っている入札、枠の計算、取消可否、異常原因を確認してから判断します。緊急停止に、入札を提案したモデルの同意を必要としない構成にします。
残す記録は、対象ID、提案額と通貨、適用した上限版、枠の増減、追随回数、入力の取得時刻、送信・受付・照会・撤回の状態、停止理由、担当者です。資格情報や不要な相手方情報は記録しません。再開時には古い提案をそのまま流さず、現在の条件で再評価します。
上限を厳しくすると機会を逃す場合があり、結果不明の枠を保持すれば利用可能額も減ります。その負担を見込んだうえで、異常時に人が確認できる時間と権限を用意します。模擬環境で確認すべきなのは、異常を表示できることに加え、送信が止まること、既存入札の状態を追えること、条件を満たした処理だけを再開できることです。
AIに購入や決済を代行させるときの金額上限と取消は「AIの購入・決済代行を設計する：金額上限と支払権限、取消の扱い」、価格設定Agentのアルゴリズム共謀リスクの評価と抑制策は「価格設定AgentのAlgorithmic Collusionリスクを評価し、抑制策を検討する」で解説しています。
