こんにちは、Project Manager の久住（ニックネーム: jin） です。
SORACOM Discovery 2026で展示したプロトタイピング作品を紹介します。
ソラカメが在庫棚を撮り、生成 AI が残量を読み、AI エージェントが理由つきで発注する——「カメラが見て → AI が考えて → AI が買う」を人手ゼロでつなぐ、ソラカメ × SORACOM Flux × 生成 AI エージェントの在庫管理デモを作りました。
⚠️ 本記事の「自動発注／人手ゼロ／実発注」は、すべてデモ用 EC サイト（モックデータ）で行われたものです。実在の EC サイトでの購入・決済ではありません。
まず、できたものをご覧ください
在庫が減ると、AI エージェントが Slack に「何を・いくつ・なぜ選んだか」を日本語で添えて発注を報告します。実際の Slack では、在庫レポート（親メッセージ）→ エージェントの判断（スレッド返信）という形で残ります。
在庫レポートに対し、エージェントがスレッドで「発注内容・選定理由・今回見送った品目」を返信します。
単なる自動化ではなく、判断の理由まで説明するのがこのデモの肝です。面白いのは、同じ商品でも状況次第で逆の判断をするところ。2 つの発注メッセージをテキストで並べて見てください。
ケース A：残り 2 本・余裕あり → 「賢く安く」
🥤 ボトルが残り2本になってたので、先に補充しておきました！天然水 500ml×24（¥1,440）を1件オーダー 🛒（注文番号 order_xxxxxx）→ 1本あたり¥60で在庫の中だと一番おトク。★4.3 で2日後に届くのもちょうど良い塩梅でした。緑茶24本（¥1,680／1本¥70）もレビューは高かったんですが、今回は普段使いなので単価重視で見送り。
ケース B：残り 1 本・切迫 → 「速さ優先」
🥤 ボトル残り1本！さすがに心もとないので最速で手配しました ⚡緑茶 500ml×24（¥1,680）を1件オーダー 🛒（注文番号 order_xxxxxx）→ 翌日着で在庫の中で一番速いのが決め手。切迫してるときは速さ優先です。天然水24本（¥1,440）が¥240安いんですが、到着が2日後なので今回は速さを取りました 🙏
同じボトルでも、余裕があれば単価重視、切迫すれば速さ重視と選び方が変わります。そしてこの発注は、デモ EC の管理画面へリアルタイムに反映されます。
何をどうつないだか
処理の流れはシンプルな一本道です。
エージェントとデモ EC サイトは別々にデプロイされており、実行時に MCP でのみつながります。
オフィスの備品棚（トイレットペーパー・飲料ボトル・スナック）を題材に、この 1 サイクルが人手を介さず回ります。掃除で在庫を一時的にどけただけのケースは「発注不要」と見送るなど、誤発注の抑制も入れています。
実際の展示の様子がこちらです。
在庫の実物（トイレットペーパー・飲料ボトル・スナック）とソラカメ、モニタにデモ EC の注文管理画面と Slack、ラップトップにデモ EC のストアフロントが表示されています
どう作ったか（見る・考える・動く）
見る — ソラカメ + Flux + 生成 AI で「画像から個数を数える」
在庫把握は Flux 完結型です。画像取得 → AI アクションで残量推定 → Slack 通知、までをすべて Flux のアクションチェーンで組み、画像解析用の自前コードや学習データは持ちません。
なお当初は重量センサーを用いる方法も検討しましたが、多様な商品を検知できる柔軟性と設置の容易さからソラカメを用いることにしました。。
AI アクションには、後段のエージェントが確実にパースできるよう決め打ちフォーマットで出力させています。判別できないときは全項目を -1・信頼度「低」と返させ、0（在庫切れ）と -1（そもそも判別不能）を区別できるようにしました。判別不能なら発注しない、という安全側の判断にしています。
📦 在庫レポート
ボトル: <整数> / トイレットペーパー: <整数> / スナック: <整数>
信頼度: <高 | 中 | 低> / 撮影時刻: <日時 or unknown> / 備考: <特記 or なし>考える — 自己ホスト AI エージェントの判断ルール
Slack のレポートを読み、発注要否と品目・数量を決めるのがエージェントです。本体は Claude Agent SDK の query() ループで、推論は Amazon Bedrock 上の Claude モデルを使いました。Slack Events API を受ける軽量な Ingress Lambda が署名検証だけして即応答し、実処理を行う Worker Lambda を非同期起動する構成です。
なおこの経路も、当初は Claude.ai の Custom Connector 接続を検討していましたが、制御と再現性を優先して自己ホストの AI エージェント経路に確定しました。捨てた選択肢も含めて、動かしながら決めています。
判断ルールをシステムプロンプトとして定義しました。
- 切迫度で選定基準を変える: 残り 1 個など切迫 → 発送日数を最優先（多少高くても速さ）。残り 2〜3 個で余裕あり → 単価と評価のバランス（賢く安く）
- 誤検知の抑制: 直前まで十分あった品目が急に 0 になったら、欠品ではなく掃除・棚整理での一時退避を疑い、発注を見送る
- 先回り発注: 大量消費イベントが控えていると分かる場合は、在庫の谷を作らないよう先回りで発注する
- 沈黙させない: 処理した投稿には必ずスレッド返信し、発注時も見送り時も「何を・いくつ・いくらで・なぜ選んだか／なぜ見送ったか」を返す。これで「動かなかった（異常）」と「意図的に見送った（正常）」を運用者が区別できる
冒頭の「賢く安く」と「速さ優先」が同じボトルで逆の判断になったのは、この 1 つ目のルールが効いているからです。そもそもカタログを単一指標では選べない構造にしてあるので、状況で選び方を変えざるをえないようにしました。
どれが最適かが一目でわからないようにしました
動く — UCP を MCP でラップし、EC を「AI が操作できる」API に
デモ ECサイトは、人間向け Web 画面と並んで AI エージェント向けのインターフェースを持たせました。Google が提唱するコマース標準 UCP（Universal Commerce Protocol）の考え方に沿ったカタログ/チェックアウトを、AI とツールをつなぐ MCP（Model Context Protocol）でラップしました。MCPサーバーに対応しているエージェントであれば検索と決済を可能にしました。
▼ 補足: MCP / UCP / ACP / AP2 —— 自律購買のプロトコル
AI が EC を操作して買う「エージェンティックコマース」に向け、役割の異なるプロトコルが立ち上がっています。MCP は AI と外部ツール/データをつなぐ汎用の通信路、UCP は発見〜チェックアウト〜購入後まで購買ジャーニー全体をカバーする新興のコマース標準、ACP / AP2 はそれぞれ取引・支払い承認に特化。競合というより補完関係で語られます。本デモは「UCP を MCP でラップしてエージェントに渡す」部分を、IoT センシング起点で動かして確かめたものです。
作るのも動かすのも、AI のループで（Loop Engineering）
このプロトタイプは、実装も運用も AI エージェントがループを回して進めました。「AI に一発で命じる」のではなく、完了まで反復させるループそのものを設計する、最近こうしたやり方は「Loop Engineering」とも呼ばれます。
補足: 「Loop Engineering」は 2026 年に広まった言い回しで、確立した定義があるわけではありません。根っこの「行動 → 検証 → 反復」は以前からある考え方で、Anthropic も長時間駆動エージェントの基本として「Contextを集める → 行動する → 検証する → 繰り返す」を推奨しています。
- 開発ループ: AI コーディングエージェントが、実装のたびに「起動 → MCP に直結してツール実行 → 副作用とログを確認 → テスト → passなら次へ・failなら原因特定して戻る」を人手を介さず回しました。成功条件を「テストが通る」という検証可能な形に落とすのがキモです。
- 運用ループ: 発注エージェントが定期実行で在庫レポートを拾い、判断 → 発注 → 返信 → 状態記録 → 次サイクル予約を繰り返します。記録した状態（発注済み・処理済み）は次サイクルの判断にフィードバックされ、同じ枯渇への二重発注を防ぎます。
- 改善ループ: 運用ループの挙動（誤検知・判断の質・ガードレールの効き・コスト）を点検し、運用ループにはルール／プロンプトの改善として、開発ループには仕様・実装の修正として戻しました。
ループを回すと、不具合も早く見つかります。
Ingress Lambda が Slack へ即 200 を返しつつ裏で Worker Lambda を非同期起動する構成にしていたところ、Worker が一度も起動しない事象が発生しました。非同期ハンドラの返り値 Promise が解決した瞬間に実行環境が凍結され、await していない裏の invoke が取りこぼされていたのが原因です。invoke を await して enqueue を確定させてから応答するよう修正し（InvocationType: Event は enqueue 確認で即返ります）、重い import を module ロード時（cold start INIT）に先読みした結果、実測で cold 約 2,492ms → warm 82〜140ms まで改善しました。これもAIが検証して自律的に解消しました。
まとめ
- ソラカメ + Flux + 生成 AI（Flux は SORACOM Agent で構築）で在庫を画像から把握。自己ホスト AI エージェントが UCP を MCP でラップしたデモ EC へ、判断から発注までを人手ゼロで通せることを確認しました。
- 肝は、単なる自動化ではなく状況に応じた判断（同じ商品で逆の選択）とその説明、そして誤発注の抑制まで含めて「AI が状況を読んで動く」体験を作れたこと。
- AI に IoT を作らせ、その IoT が AI に発注させるという入れ子のループを検証できました。
AIの登場によって普段開発しない人でもIoT開発に参加することが可能になりました。アイディアをお持ちの方はぜひチャレンジしていただきたいです。
― ソラコム久住（jin）