出荷指示のあと、商品を取る作業もシステムが行う
たとえば、物流の基幹システムです。注文を受け、在庫を確認し、出荷指示を出すところまでを、ITが担当していました。棚から商品を取り、箱に入れる判断は、現場の人の仕事です。商品の形も、置かれた向きも、毎回少し違います。
この分担が、倉庫では変わり始めています。2025年6月、Amazonは100万台目のロボットを、日本のフルフィルメントセンターへ納入したと発表しました。拠点は世界で300か所を超えます。この100万台は、棚や荷物を運ぶ移動ロボットの数です。同時に、複数のロボットの移動を調整する生成AIの基盤モデル DeepFleet も発表されました。移動時間を10%短くする、とAmazonは説明しています。発表は Amazon launches a new AI foundation model to power its robotic fleet and deploys its 1 millionth robot です。納入が2025年6月であることは、英国版の解説 に書かれています。
移動時間が短くなるのは、棚を人のところへ運ぶ作業です。商品を見て、つかむ位置を決め、アームを動かし、結果を見て次の動作を変えるのは、別のロボットの仕事です。どちらの場合も、人がその場で判断していた作業を、AIを含むシステムが実行し始めています。これまで注文データや在庫データを処理していたシステムが、商品そのものを動かすようになります。
現実の物を認識して動かすAIを、フィジカルAIと呼ぶことがあります。認識からモーターまでの分担と、動いた結果が次の判断の入力になる仕組みは、「ロボットのAIなんて昔からあったよね？」——それでもフィジカルAIが新しいと呼ばれる理由 に書きました。この記事で書くのは、失敗したときに何をするかを、導入前に決めておくことです。
振込のような条件分岐では、商品の把持は書けない
従来の業務システムなら、この失敗時の動作も条件分岐で書けます。銀行の振込が、その典型です。依頼を受け、残高を確認し、限度額以内なら実行する。残高が足りなければエラーにする。例外も、業務ルールとして先に列挙できれば、プログラムにできます。実際の業務システムには、事前に書き切れない例外もあります。従来の開発では、ルールを明確にして実装することが中心でした。
倉庫で商品をつかむ作業は、その列挙が難しいです。形、重さ、材質、包装、置き方、隣の商品。同じ商品でも、角度が違えば結果が変わります。そこで、過去の把持から成功率を推定するモデルを使います。モデルが候補に点数を付け、システムはその点数で、どの商品から取るかを決めます。
推定は外れることがあります。どの判断を自動で実行し、どの状態で止めるかを、モデルのプログラムとは別に設計します。その設計の前に、公開されている成功率が、どの作業の数字なのかを確認します。
93.73%は、Robinの試験の1行である
把持の93.73%は、100万台の発表とは別の資料にあります。Demonstrating Large-Scale Package Manipulation via Learned Metrics of Pick Success（Li et al.）です。Amazon Roboticsの Robin というアームが、山積みの荷物を1つずつ分ける作業を扱っています。学習で「成功しやすさ」を推定し、どの荷物から取るかを並べ替える方式を、本番のロボットで比べています。
6つの並べ替えを同時に比べたA/B試験では、学習の推定で順位を付けた LPR-Center が、1,160,005回のうち失敗72,789回、成功率93.73%でした。荷物の高さなどを使う規則の TopoZ-Center は、1,158,353回のうち失敗89,378回、成功率92.28%です。
同じ論文には、別の成功率もあります。本番で使った Experiment という順位付けでは、評価期間の仕分けが2億回を超え、成功率は98%でした。約18万回の別の比較では、従来の順位付けが95.02%、学習を使った方式が96.20%です。差は1.18ポイントで、失敗の割合は約23.7%下がっています。98%、96.20%、93.73%は、対象の回数も方式も違うので、倉庫全体の失敗率にするときは、同じ試験の中の数字だけで計算します。
A/Bの93.73%と92.28%を、10万回あたりの失敗回数に換算すると、LPR-Centerは約6,275回、TopoZ-Centerは約7,716回です。10万回あたり約1,440回の差です。
図は、論文 Table III の失敗回数を、方式ごとの試行回数で割り、10万回あたりに換算したものです。無作為に取る TopoZ-Random は、約9,426回まで増えます。差が出るのは、どの荷物から取るかの規則です。論文では、高い荷物を優先すると、倒れやすい荷物を先に取ってしまうことがある、と説明しています。学習を使う方式は、位置、面の向き、隣の荷物との関係も見て、そうした荷物を後に回せます。使っているモデルは、5つのCatBoostの平均です。木の深さは6、学習率は0.05、と論文にあります。DeepFleetのような大規模な基盤モデルとは別の、小さいモデルです。
約1,440回減っても、失敗が少ない方式で10万回あたり約6,275回は失敗します。1日の把持が10万回なら、この成功率では約6,275回です。論文の数字を1日の回数に換算した値であり、ある日の倉庫の実測値ではありません。商品の種類と、何を失敗と数えるかで、実数は変わります。この回数を業務で扱うには、失敗したあとの手順が要ります。
失敗したあとの再試行、停止、引き継ぎを先に決める
約6,275回の失敗では、もう1回同じ位置へ行けば成功することもあります。その失敗で、商品が倒れたり、別の商品と重なったり、吸盤が別の荷物に触れたりすることもあります。状態が変わったのに同じ動作を繰り返すと、商品が壊れたり、複数個を一度に取ったりします。論文も失敗を3種類に分けています。取る位置を決められない場合、つかんだあと落とす場合、複数個を同時に取る場合です。
そこで、導入前に次の項目を決めます。
| 設計 | 決めておくこと |
|---|---|
| 成功の確認 | 取れたこと、取った個数が1つかを、別のセンサーで確認する |
| 再試行 | 何回までか。繰り返す前に、画像や力のセンサーを取り直すか |
| 停止 | 姿勢、力、対象以外への接触の、どの条件で止めるか |
| 引き継ぎ | 何回失敗したら、誰に、どの画像と理由を渡すか |
| 記録 | 推定、実行、結果を、同じIDで残すか |
| 改善 | その記録を、次のモデル比較に使える形にするか |
従来の業務システムでも、例外と再試行は設計してきました。モデルによる推定では、同じ入力でも同じ結果になるとは限りません。周囲の状態が少し変わるだけで、出力がずれます。業務として続けられるかは、失敗したあとの手順も含めて決まります。商品、人、設備が安全で、作業が長時間止まらないことが条件です。
次のコードは、表のうち再試行と引き継ぎだけを書いた例です。Python 3.10以降、標準ライブラリのみで動きます。ロボットにもネットワークにも接続しません。「場面が変わったか」の判定は、現場のセンサーの定義に置き換えてください。
# 把持1回の結果から、次の処理を決める例。
# 本番の制御プログラムではない。
def next_step(grasped: bool, scene_changed: bool, attempt: int, max_retry: int = 2) -> str:
if grasped:
return "次の商品へ進む"
if scene_changed or attempt >= max_retry:
return "人へ引き継ぐ"
return "画像を取り直してから再試行する"
cases = [
(True, False, 1),
(False, False, 1),
(False, True, 1),
(False, False, 2),
]
for grasped, changed, attempt in cases:
print(attempt, grasped, changed, "->", next_step(grasped, changed, attempt))
1回目の失敗で、商品の配置が変わっていなければ、画像を取り直して再試行します。配置が変わったときと、再試行の上限に達したときは、人へ渡します。上限の2回は例です。壊れやすい商品なら、再試行を0回にしてもよいです。実行すると、この4通りの結果が出力されます。
人の承認は、影響の大きさで分ける
ロボットでは、何度か失敗したら人へ渡す、と書きました。生成AIやAIエージェントが返金やマスタ更新を実行するときも、同じ選択があります。問い合わせを読み、顧客情報を確認し、返金や契約変更を実行する。判断を誤ると、台帳の値が変わります。フィジカルAIでは、商品を落としたり、設備に接触したりします。どちらも、AIの判断が、業務データの値や現場の物の状態を変えます。
人を判断の途中に入れる方法（Human-in-the-Loop）も有効です。ただし、1日に数万件の処理や、ロボットの把持のように回数が多い処理を、全部人が承認すると、自動化で減らした作業時間が元に戻ります。処理が複雑になると、内容を確認しないまま承認してしまうこともあります。
そのため、承認の有無は、影響の大きさと、あとから取り消せるかで分けます。
影響が小さく、取り消せる処理は自動で実行する
在庫の照会や、下書きの作成は、この区分に入れやすいです。誤っても、次の処理の前に破棄できます。
金額や権限の上限を超えたら、承認を求める
返金の上限、配送日の変更、外部への送信は、承認が必要になりやすい処理です。上限は、モデルが出す自信の点数では決めません。誤ったときに発生する損失の大きさで決めます。
影響が大きい処理は、AIは案の提示までにする
契約の解除や、本番データの一括更新では、AIが案を出し、実行は人が決めます。
安全に関わる停止は、AIの出力とは別の仕組みで行う
ロボットが人や設備に近づいたときの停止は、把持モデルが「成功しそう」と推定したかとは別に動く仕組みにします。エージェントでは、本番の認証情報や、取り消せない送金を、そのジョブの権限に含めません。
モデルのプログラムの外で、権限と手順を制限する考え方は、ハーネスエンジニアリングとは？——AIエージェントを「手綱」で導く設計思想 にあります。ここまで書いたのは、その制限を、影響の大きさと、取り消せるかで分ける方法です。
1つの作業が速くなっても、別の負担が増えることがある
承認の範囲を分けても、速くなった作業の前後まで良くなるとは限りません。ロボットを導入すれば倉庫全体が安全になる、とも限りません。Burtch、Greenwood、Ravindran の Lucy and the Chocolate Factory: Warehouse Robotics and Worker Safety（ILR Review）は、Amazonのフルフィルメントセンターについて、ロボットがある拠点とない拠点を比べています。公開されている要旨では、ロボットの導入は、重度の負傷が40%少ないこと、重度でない負傷が77%多いことと関連する、と報告されています。重度とは、仕事を休む必要がある負傷です。重度でない負傷とは、配置転換や作業制限が必要になる負傷です。用語の説明は George Mason University の紹介 が読みやすいです。
論文が示しているのは、ロボット導入との関連です。調査期間、倉庫の規模、人に残った作業、仕事の速さが同時に変わっています。論文は、重度でない負傷が増えた理由の一部を、作業ペースが上がったことと関連付けています。紹介記事では、重い荷物の運搬や長い歩行をロボットが行い、人は同じ場所で同じ動作を繰り返す時間が増える、と説明されています。歩く負担は減り、同じ動作を繰り返す負担が増える、という変化です。
問い合わせの分類でも、速くなった作業のあとに負担が移ります。AIが振り分けを速くすると、回答担当者に短時間で多くの問い合わせが届くことがあります。AIが分類できない難しい問い合わせだけが人に集中し、その人の負荷が上がることもあります。分類の精度と処理時間を測るだけでは、この負荷の移動は分かりません。
負荷の移動を見つけるには、AIの機能以外の指標も見ます。
| 対象 | 指標の例 |
|---|---|
| AIの処理 | 分類精度、処理時間、失敗率 |
| 業務の流れ | 解決までの時間、待ち行列の長さ |
| 顧客 | 解決率、再問い合わせ |
| 従業員 | 繰り返し作業、例外が特定の人に集中していないか |
| 経営 | 費用、品質、止めずに続けられるか |
処理時間は短くなっても、解決率が下がることがあります。人件費は減っても、例外対応と品質確認の費用が増えることがあります。導入の評価では、自動化した割合だけでなく、業務全体で何が変わったかを確認します。この確認には、現場で何が起きたかの記録が要ります。
学習に使う記録は、動作と成功・失敗の組である
現場の記録は、カメラ画像だけでは足りないことがあります。画像から位置は推定できても、どの力でつかむかは分かりにくいです。包装が柔らかい、表面が滑る、中の重さが片側に偏っている、といった違いがあるためです。
画像に加えて、力のセンサーを使う
2025年5月、Amazonは力を検知するロボット Vulcan を発表しました。アームの先端のセンサーが、6方向の力と回転力を測ります。接触が強すぎる前に、力を弱めます。保管している商品の種類の約75%を、しまう作業と取り出す作業の対象にできる、とAmazonは書いています。動かせないと判断した商品は、人に渡します。Vulcanは、移動ロボット100万台とは別のアームです。発表は Introducing Vulcan、センサーと制御の説明は Amazon Science の解説 にあります。
ここで分けるのは、モデルの性能の問題と、判断に必要なデータが取れているかの問題です。業務システムでも同じです。マニュアルと過去の障害記録を渡しても、監視のグラフに異常が出る前の「最近、少し使いにくくなった」という利用者の声は、記録がなければ入力になりません。その声を集めれば、分析の入力にできます。
成功したか失敗したかを、同じIDで残す
データが取れても、学習に使えるとは限りません。100万台を運用すると、さまざまな失敗を現場で観測できます。Amazon Science は、DeepFleet の学習に、ロボットが走行した数十億時間分のデータがある、と書いています。記事は Amazon builds first foundation model for multirobot coordination です。台数が多いことと、そのデータでモデルを改善できることは別です。把持なら、画像、つかむ位置、アームの動き、接触、成功か失敗かを、同じ操作IDで記録します。この対応が記録されていれば、次のモデル比較に使えます。
顧客への回答も同じ対応が要ります。文章が自然であることと、顧客の問題が解決したことは別です。障害対応の手順提案がもっともらしいことと、障害が解消したことも別です。AIが出力した内容に加えて、その後に業務で何が起きたかを記録します。
設計時に確認する項目は、次のとおりです。判断と実行結果を同じIDで記録する。失敗を種類別に分ける。モデルを更新する前後で、同じ指標を比べる。改善によって別の失敗が増えていないかを確認する。問題があれば、前のモデルに戻せるようにする。集めたデータは、品質、個人情報、アクセス権限、誤って付いた成功・失敗のラベルを確認してから学習に使います。
データの収集から監査までの準備は、フィジカルAI時代に、IT技術者は何を準備すべきか に整理してあります。この記事で確認するのは、動作と、成功か失敗かが、同じ操作として記録されているかです。
複数のシステムをまたぐときは、順序と取り消しを先に決める
記録があっても、AIエージェントが複数の業務システムを操作するときは、別の設計が要ります。在庫を確認し、注文を変更し、配送を指示する、という一連の処理です。順序を誤ったとき、途中で失敗した処理をどこまで取り消すか。複数の処理が同じデータを同時に更新したとき、どう整合を取るか。許可されていない操作を、どう止めるか。分散システム、トランザクション、アクセス制御の課題は、モデルが自然な文章を書けるようになっても残ります。実行できる操作が増えるほど、これらの条件を先に決めます。
判断そのものにも、優先順位の文書が要ります。配送コスト、納期、環境負荷のどれを優先するかは、企業の方針です。方針が複数あって対立していると、モデルはそのうちの1つを、それらしい理由で選びます。選ばせる前に、どの条件ならその判断を業務の決定として採用するかを書いておきます。ここまでの内容は、設計レビューでは次の5つの問いに分けられます。
設計レビューでは、5つの問いに分けて確認する
何を改善したいのか
処理時間、自動化した割合、費用は、途中で見る指標です。顧客に渡す結果、従業員の作業、企業が維持したい品質の、どれを優先するかで、自動化してよい範囲が変わります。目的が人件費の削減なら、自動化した割合が重要になります。目的が問題解決の質なら、難しい問い合わせを早く人へ渡す設計の方が合うことがあります。
判断を誤って実行したとき、損失と復旧はどうか
商品の推薦を誤ることと、送金を誤ることは、同じ精度でも影響が違います。確認するのは、精度の点数、実行したあとの損失、取り消せるか、の3つです。
失敗したとき、システムは何をするか
前の節で書いた再試行と引き継ぎを、自分の業務に置き換えます。失敗を検知できるか。安全に停止できるか。処理を取り消せるか。必要なときに人へ引き継げるか。信頼性は、成功したときの性能と、失敗したときの手順の両方で決まります。
ある作業を速くした結果、別の作業の負担が増えていないか
負傷の研究と、問い合わせ分類で見た負荷の移動を、ここで確認します。別の担当者へ作業が集中していないか。難しい仕事だけが特定の人に残っていないか。顧客が確認する項目が増えていないか。評価は、AIの機能以外の指標でも行います。
稼働のあと、何を比べて改善するのか
商品も、企業の方針も変わります。導入した時点の精度は、運用開始時の数字です。判断、実行、その後の業務結果を記録し、更新の前後を比べ、前の方式に戻せるようにします。
次に書くのは、失敗したあとの4行です
100万台は、AIが画面上の情報処理だけでなく、倉庫の商品を動かす仕事を始めたことを示す数字です。人が定義した手順を正確に実行するシステムに加えて、推定が外れても業務を安全に続けられる条件を書く作業が増えます。
分析も改善案も、AIが下書きできる範囲は広がっています。その範囲は、モデルが新しくなると変わります。会社として決めるのは、人員をどうするか、どの失敗まで受け入れるかです。現場の制約と合わせて決め、その材料にモデルの出力を使います。
これまで多かった作業と、これから増える作業を並べると、次のようになります。
| これまで多かった作業 | これから増える作業 |
|---|---|
| 業務要件を機能に変換する | その業務が今も必要かを見直す |
| 処理手順を書く | 判断してよい範囲と、超えたら止める条件を書く |
| 正常な処理を実装する | 不確実な結果と、失敗後の手順を実装する |
| システムの速度を上げる | 人と顧客を含む業務全体の結果を確認する |
| システムを監視する | AIの判断と、その後の業務結果を照合する |
| 障害を修正する | 比較でき、元に戻せ、改善を続けられる運用にする |
右側の作業も、いずれAIが下書きを作ります。確認するのは、その下書きを現場の結果と照合して修正できるかです。
次に行うのは、小さい業務を1つ選び、失敗したあとの節で挙げた再試行、停止、引き継ぎ、記録を4行に書くことです。問い合わせの分類でも、バッチの再実行でも構いません。成功率の目標と並べて書きます。この4行があると、レビューで成功率と失敗時の手順を両方確認できます。
Robinの試験は、成功率を1.45ポイント上げても、10万回あたり約6,275回は失敗することを示しています。4行が空欄のままだと、その回数の扱いが現場任せになります。
作成日: 2026-10-21