AIエージェントは商品リストを書き換えることができます。しかし、その商品が自動販売機に収まるとは限らず、ソフトウェア上の作業が完了しても、現実世界で何かが変わったとは限りません。こうした隔たりが、Prosusによる4カ月間の自律型自販機実験を形づくりました。プロジェクトは6台の運営を目標とし、試験期間中はアムステルダムの拠点で2台が稼働しました。在庫、販売、価格に加え、なお人の手を要する作業をエージェントが管理すると何が起きるかを検証しました。

デジタルの操作から現物の在庫へ

Prosusは、自社のデジタルマーケットプレイスを利用する小規模事業者に関わる問いから始めました。AIエージェントは、ソフトウェアの枠を超えて日常的な事業運営を担えるのでしょうか。飲食店は最初の試験には複雑すぎると判断しました。自動販売機なら業務の範囲を絞れますが、それでも当初の「設置は1日で済むかもしれない」という見込みは崩れました。

最初の制約はハードウェアでした。高機能な自販機の中には納期が6カ月と提示されたものもあったため、チームは遠隔監視、管理ダッシュボード、QRコードから利用するモバイル決済画面を備えた機械を扱う、オランダの地元サプライヤーを選びました。ダッシュボードは人向けに作られており、エージェント向けではありません。エンジニアはその機能を、エージェントが呼び出せるツールに対応づけました。この作業は1営業日もかかりませんでしたが、サプライヤーの顧客向け販売システム（POS）では、商品を固定のカタログからしか選べませんでした。Prosusは、エージェントが商品説明、掲載内容、価格を変更できるよう、別のPOSを構築しました。これにはさらに2日かかりました。

こうして、制御経路は二つに分かれました。一方は商品の排出など、自販機の機能に接続します。もう一方は、顧客に表示される内容と支払額を変更します。この区別は重要でした。商品カタログの編集はソフトウェア上で元に戻せますが、排出命令を出すと実際の在庫が動くからです。

別々の抽象的な制御経路を通じて、クラウド上の作業環境と決済画面につながる自動販売機

▲ 自販機と商品カタログの別系統制御

起動し、行動し、結果を確かめるエージェント

システムにはClaude Agent SDKと、二つの主要なコマンドラインスキルを使いました。スキルは、エージェントが自販機とPOSを操作するための指示とツールのセットです。通信、ブラウジング、報告には、ほかの連携ツールを使いました。エージェントは常時稼働するのではなく、次のサイクルを予定に沿って繰り返しました。

  1. 起動： 予定された業務タスクを開始します。
  2. 実行： 利用可能なツールでタスクを遂行します。
  3. 記憶： 次の実行に向けて文脈を保存します。
  4. 確認： 結果を目標と照合します。

Cloudflare Workersは共通のフロントエンドを支え、Cloudflare VMsはエージェントの実行環境を分離しました。Cloudflare R2にはエージェントが読み込める文書とスキルを置き、Cloudflare D1には実行記録を保存しました。認証情報を管理する仕組みにより、秘密鍵をモデルの作業コンテキストやログに置かずに、連携サービスへアクセスできるようにしました。

チームはエージェントの記憶方法も変更しました。長い会話を単に短くまとめるのではなく、決定事項、判明したこと、次の手順、作業文書への参照を保存しました。これにより、予定された実行の間も事業上の目標を保ちやすくなりました。複数人でのアクセスも運用上の要件となりました。管理者の1人が不在でエージェントが助けを必要とした際、作業は1週間進みませんでした。共通の画面を設けたことで、複数のチームメンバーが状態を確認し、対応できるようになりました。

こうした仕組みがあっても、操作が成功したとは限りません。初期のダッシュボードでは、実機で処理が行われていなくてもタスクが完了と表示されました。この試験は、エージェントの実行が成功したかどうかと、実機の状態が変わったことを確認できたかどうかを、別々に確かめる必要性を示しました。

現実世界で計画が崩れた場面

あるテストでは、本来アクセスすべきでない段階で、稼働中の排出機構にアクセスしました。エージェントは排出装置を繰り返し作動させ、飲料約30本を床に落としました。実用上の防止策は、模擬的な確認と実機を動かす命令を分け、物理的な結果を独立して確認することです。

商品の購入判断では、別の隔たりが表れました。麺類を売るという提案を受け、エージェントは排出用コイルに収まらない大きさのカップ麺を注文しました。チームはそれをオフィスで配りました。在庫を探した際には、無関係な値引き対象の石けんボトルの商品情報が1,100件返されました。洗剤や大きすぎるスナック菓子の袋など、ほかにも不向きな商品が選ばれました。エージェントは商品や特売品を探すという依頼には従えても、その自販機に収まり、販売できるかまでは考慮できていませんでした。

対策として、チームは商品を入れる区画の寸法と商品要件を、エージェントが使える文書に記載しました。また、業務上のやり取りでは役割をより明確にする必要があると分かりました。状況報告を求められたエージェントは、販売や利益率の情報ではなく、ソフトウェア開発で使うような変更履歴を作成しました。自販機の宣伝を頼まれた際には、画像生成ツールを使えるにもかかわらず、最初はSlackにテキストだけを投稿しました。管理業務とマーケティング業務を分け、エージェントにより広い目標を与えることで、1回の投稿を仕事のすべてとみなすのではなく、次のタスクを提案・検討するよう促しました。

自動販売機のそばにある大きすぎる食品や不向きな商品と、補充用カートに載った包装済みの菓子

▲ 商品のサイズ適合と在庫選定

商品の補充には、引き続き人の手が必要でした。商品を追加するよう曖昧に依頼されると、担当者はどの自販機のどの区画に入れるべきか分かりませんでした。担当者向けの専用画面によって依頼を手順に落とし込み、不明点をエージェントに尋ねられるようにしました。この環境では、自律的な運営は、残された人の作業を進めやすくすることにもかかっていました。

売上から見えた価格設定の問題

売上記録の対象期間は2026年5月20日から9月15日までです。試験は需要を観察するための無料提供から始まりました。自律的な価格設定を始めると、当初は販売が鈍るほど価格が上がりました。夏に需要が落ち込んだ後、エージェントは価格を大幅に下げ、一部のプロテインシェイクは近くのスーパーマーケットより安くなりました。注文が増えても商品の収支不足は解消せず、オフィスで無料提供される菓子や飲料も顧客を奪っていました。

4カ月間の試験の指標 報告額
自販機の売上 €800
食品の卸売仕入れ額 €1,100
商品の現金収支不足額 €300
モデルのトークン費用 月額約€300

€300の不足額は売上と食品の仕入れ額を比較したもので、別途かかる月額のモデル費用は含みません。これは今回の試験の結果であり、ほかの自販機事業の予測ではありません。需要が変化した際に利益率を守るには、自動価格設定システムに制限が必要であることを示しています。

開発者がこの試験から学べること

Prosusは、6台の自販機、30稼働日、€1,500の初期予算を設定したオープンソースのシミュレーション「Prosus Vending Bench」も公開しました。実際の在庫を動かさずにエージェントの設計を試せます。

中心となる教訓は、会話ではなく運用に関するものです。エージェントには、正確な物理的制約、独立した結果の確認、価格設定の安全策、そして人への実行可能な引き継ぎが必要です。同様のシステムを検討するチームは、在庫、決済、ハードウェアの制御をエージェントに委ねる前に、そうした境界を定めるべきです。