顧客の倉庫図面から、搬送ロボットの台数を提案する

この記事の図の多くと依頼文は、英語で記録したものです。

誰が、何をしたいか

トートを運ぶ搬送ロボット（AMR）を販売・導入する会社の提案担当者には、毎週のように同じ依頼が来ます。顧客が倉庫のPDF図面と「ピーク時に1時間110件」という数字を送ってきて、何台必要か、なぜその台数かを知りたがっています。

答えるために必要なものは三つです。図面と一致する建物のモデル、ロボット2台・3台・4台でのピーク時の試算、そして返送する資料一式（経路と充電器を描いた図面、比較表、その元になるファイル）です。担当者は、モデル化と試算を自分のAIに任せ、根拠は自分の目で確かめたいと考えています。

手元にあったもの

• 顧客の図面：CV-U4-GA-101 Rev C。1階の全体配置図で、A3・1:250、寸法はミリメートル。60 × 40 mの建物に、3つのピッキングゾーンに分かれた12列の棚、各ゾーンの端の受け渡し台（P&D）、3つの搬入口の近くに梱包台4台、パレットラック4列、事務所、「AMR充電場所の候補」と書かれた区画があります。（PDF）
• 顧客の要望：ピーク時に1時間110件、1件につきトート1つ。ゾーンA・B・Cの注文の割合は45・35・20%。梱包係4人で1件およそ100秒。ロボットが減るなら梱包台をピッキングゾーンの近くへ移してもよい、という申し出つき。
• 自社ロボットの仕様書：トート1つを運ぶ。配置検討用の平均速度は毎秒1.0 m、トートの受け取り・受け渡しは各12秒、経路計算では半径0.5 mの円として扱う。ピーク時は作業1時間あたり6分の充電が必要。（要望と仕様書）

エージェントに渡した図面。顧客・倉庫・ロボットはすべて架空です。

図面は受け取ったものではなく、作ったものです。 エージェントの誤差を測るには、本当の配置が必要です。そこで先に、Laydyneのツールを直接呼び出して倉庫を作りました。これが正解モデルです（answer-key.laydyne.json）。それを2Dの図面にし、Laydyneの表題欄を顧客の表題欄に置き換え、寸法をミリメートルにしてPDFに印刷しました。エージェントが作業したフォルダには、そのPDFとPNG、要望のファイルしかありません。モデルを作る間、エージェントがそのフォルダの外を読んでいないことを、シェルコマンドとセッション記録のスクリプトをすべて調べて確かめました。

流れ

1. 担当者が図面・要望・仕様書を1つのフォルダに置く。
2. エージェントがPDFを床の下に敷き、縮尺を合わせて読み取る。
3. 倉庫を作り、図面と照合する。
4. トートの搬送と充電を記述し、Laydyneがピークを試算する。
5. Laydyneがロボット2台・3台・4台を比べ、次に顧客の配置変更を比べる。
6. エージェントが提案資料一式を作る。

各ステップの道具と成果物は flow.json にあります。

手順ごとに

エージェントはCodex（CLI 0.160.1）、担当者の既定のモデルgpt-6.1-sol、推論はmedium。Laydyne StudioにMCPで接続しました。ステップごとに新しいセッションで始めています。作ったものはStudioのタブとフォルダに残るので、依頼文には次にしたいことだけを書きます。以下は送ったとおりの依頼文です。

1. 図面から建物を作る

I'm a proposal engineer at Brindlefield Automation; we sell and install tote-carrying AMRs. A customer, Corrin & Vale Homewares, has sent the layout of their warehouse: CV-U4-GA-101_RevC.pdf in this folder (the PNG of the same sheet is attached). Their brief and our robot's datasheet are in brief.md.

First I need an accurate model of the building in Laydyne. Start a new project (create_space with fresh: true), lay the drawing under the floor with set_underlay, set the scale from the 60 000 dimension and check it against the 40 000 one, and read the drawing with trace_underlay. Then build what matters for the robots' routes: the outer walls with the columns, the doors and dock doors, the office, the shelving rows R01–R12, the pallet racking PR1–PR4, the three P&D stands, the four packing benches, the dock levellers, and the zones on the drawing (pick zones, packing, outbound staging, reserve storage, the possible charging area), with the drawing's labels, each part with source "drawing". Check the model against the drawing with measure_underlay_fit and fix what is off, run check_space, and show me the 2D plan and a 3D view. Save the project in the browser (save_local_project). Tell me what you could not read from the drawing.

4分46秒、ツール呼び出し26回でした。エージェントはPDFを4つに分けてLaydyneへ送り、ページはStudioのタブで描かれました。60 000の寸法線で縮尺を合わせると、40 000の寸法線は40.014 mと読めました。そのうえで trace_underlay が返した候補から72個の部品を作り、すべてに「図面から読んだ」と出典を付けました。

• 図面とのずれ：measure_underlay_fit で、モデルの辺と図面の線の距離は中央値1.4 mm、95%点49.6 mm。
• 検査：重なり、ふさがれた扉、床からはみ出した部品はなし。半径0.5 mのロボットで、3つの受け渡し台と4台の梱包台すべてに到達できる。
• 読めなかったもの：壁と柱の高さ、扉の高さ、作業台の高さ、搬入口のピット、事務所内の名前のない什器が何か。どれも未確認として記録しました。

編集が1回失敗しています。図面から読んだ扉3つが外壁の外面を数ミリ越えていたため、Laydyneが編集を受け付けませんでした。エージェントは寸法を詰めて送り直しました。

エージェント自身の確認。顧客の図面（薄く表示した下絵）の上にモデルを描いたもの。

作り直した倉庫を、エージェントが3Dで描いたもの。

2. トートの搬送と充電

The warehouse model is open in Laydyne (built from the customer's drawing in this folder). Now set up the robot tote transport described in brief.md, for the customer's peak. Read get_process_catalog first.

Add chargers for the robots in the customer's possible charging area (one per robot, up to 4) if that works for the routes. Finished totes appear on the three P&D stands at the brief's rates; the nearest free robot takes each tote to a free packing bench and puts it on the bench; a packer then packs it. Use our datasheet for the robot. Represent charging as well as Laydyne allows, and tell me exactly how you did it and what it leaves out.

Run it for the peak with 3 robots (at least 20 runs, with a warm-up), and tell me the throughput, how long totes wait on the P&D stands for a robot, the robot utilisation, the distance each robot drives and the packer utilisation. Look at a moment of the run in a 2D picture to check that the robots go where they should.

15分3秒、ツール呼び出し131回でした。エージェントは顧客が示した区画に充電器を3台（と予備1台）置き、それぞれ前に1.5 mの空きを取りました。作業は次のように記述しています。

• トートは受け渡し台にランダム（ポアソン）に現れ、1時間あたり49.5・38.5・22個。
• 空いている最寄りのロボットが台へ行き、トートを受け取る（12秒）。
• 空いた梱包台が出るまで、その場で待つ。 梱包台に置けるトートは1つで、ロボットが向かい始めてから梱包係が梱包を終えるまで予約される。
• 梱包台にトートを置くと（12秒）ロボットは空く。梱包は平均100秒（2つの三角分布の混合）。
• 充電：当時のLaydyneには電池のモデルがなかったので、エージェントは1時間に3回、20分ずつずらした6分間の「充電の仕事」を加えました。そのたびに空いている最寄りのロボットが充電器へ向かいます。エージェントは、これで時間と移動は表せるが、電池の残量は表さず、各ロボットが均等に充電される保証もない、と説明しました。

1回3時間（うち30分はウォームアップ）を、同じ乱数で20回計算しました。3台では追いつきませんでした。 梱包できたトートは1時間あたり94.2個で、110に届きません。トートが回収されるまでの待ちは平均15.3分、ロボットは99.9%の時間ふさがっていました。

エージェントはそこで止まらず、頼まれていないのに顧客の申し出（梱包台をピッキングゾーンの南隣へ移す）も試しました。1時間あたり109.0個、待ち2.3分、稼働86.0%。そのあと元の配置に戻しています。

131回のうち大半は、依頼文の「the distance each robot drives（各ロボットの走行距離）」のためのものです。当時のLaydyneは全回の平均としてはロボット全体の走行距離しか返さず、1台ずつの距離は1回目の記録経路にしかありませんでした。そこでエージェントは20個の乱数を1回ずつ計算し直し（配置ごとに20回、計40回）、各ロボットの経路を読みました。その後、Laydyneは各ロボットを全回で返し、電池のモデルも持つようになったので、この依頼文と次の依頼文をもう一度送りました（「結果」の「手順2と3のやり直し」）。

3. 2台・3台・4台

The tote transport scenario from before is saved in the Laydyne project. Now I need the fleet size. On the current layout, compare 2, 3 and 4 robots under the same arrivals, seeds and number of runs (sweep_process_parameters is fine for this). Then save the current layout with the fleet size you would recommend as option A with save_process_option.

Tell me, with the numbers and their 95 % intervals: throughput against the 110 orders per hour, tote waits on the P&D stands, robot utilisation and distance, and which differences between the fleet sizes are beyond the noise. Which fleet size would you put in the proposal for this layout, and why?

3分1秒、ツール呼び出し17回。sweep_process_parameters の1回で、3つの台数を同じ20個の乱数で計算しました。

台数を増やすたびの差は、どれも誤差を超えていました。それでも4台で110件に届きません。 エージェントは「能力の不足を明記したうえで」4台を提案し、原因も指摘しました。梱包台が98.7%の時間予約されていたことです。このモデルでは、梱包台は受け渡し台からの走行中と梱包の間ずっと予約されます。建物を横切る長い走行のたびに、梱包台と梱包係が空いたまま押さえられます。この配置で上限を決めているのは、ロボットではなく梱包台です。

4. 顧客の示した配置変更

The customer offered one layout change: they could move all four packing benches to the open floor south of the pick zones (between the P&D stands and the office); outbound staging and the docks stay. Try it in Laydyne: move the benches there, keeping clear aisles for the robots and away from the office door, and run check_space. With the same arrivals, seeds and runs, find the smallest fleet that keeps up there, save that as option B with save_process_option, and compare option A (saved before) with B using compare_process_options.

Tell me which differences are beyond the noise, what the move gains and what it costs that the simulation does not count (for example, packed parcels now further from the docks). Then give me your recommendation: fleet size and layout.

1分58秒、ツール呼び出し17回。エージェントは梱包台を受け渡し台の約4 m南に、5 m間隔、事務所の間仕切りから3.8 mの位置へ一列に移し、配置を検査しました。そこで1〜4台を計算し、追いつく最小の台数は3台でした。これを案Bとして保存し、案A（4台、梱包台は今の位置）と同じ20個の乱数で比べました。

\*1時間に3回の充電の仕事を含みます。到着は1時間あたり注文110件と充電3回。

どの差も誤差を超えています。梱包台をピッキングゾーンの近くへ移すと、受け渡し台Aでトートがロボットを待つ時間は、元の配置の4台で平均10.8分だったのが、3台で2.3分になりました。 エージェントは、移設のコストのうち試算に入っていないものも挙げました。梱包済みの荷物が搬入口から遠くなること（運ぶ手間かコンベヤが要る）、梱包台への電源とネットワークの移設、移設中の停止、事務所の扉の近くで人が働くことです。推奨は案B・3台で、購入前に梱包後の荷物の運び方を現地で確かめること、としました。

2回の台数比較（各20回、同じ乱数）から。梱包台を南へ移すと3台で追いつき、4台目の効果は誤差の範囲です。

5. 提案資料一式

Now prepare the proposal pack for Corrin & Vale in this folder:

1. Drawings as PDF: the dimensioned plan of the recommended layout with the zones, the chargers and the packing benches (get_view_image, delivery sheet as PDF; join the pieces and check the SHA-256), and the robots' routes from the run of the recommended option (get_process_drawing).
2. The fleet comparison as a CSV table: each option and fleet size you ran, with throughput, tote wait on the P&D stands, robot utilisation, distance per robot and packer utilisation, with the 95 % intervals where you have them. Also save the saved comparison of A and B as JSON (get_process_comparison).
3. The whole project as a .laydyne.json file (export_project; check the SHA-256), and save it in the browser again.
4. A short summary.md for the customer's operations director: the recommendation, the evidence, the assumptions taken from their brief and our datasheet, and what this simulation does not cover.

Tell me where each file is.

6分26秒、ツール呼び出し10回とシェルコマンド91回でした。平面図はLaydyneの1回の呼び出しでPDFになりました。経路図はなりませんでした。 get_process_drawing はHTMLかSVGしか返さず、エージェントはPDFを自分で作るのに19回のシェルコマンドを使いました。変換の道具を探し、システムのChromeはサンドボックス内で異常終了し、pip はネットワークがなく、別のフォルダで見つけたPython環境にもライブラリがありませんでした。最後に、マシンに入っていた rsvg-convert を見つけてPDFにしています。この道具がないマシンなら、経路図のPDFはできていませんでした。

そこで get_process_drawing にPDFの形式を加え、同じ開始状態から同じ依頼文で手順5をやり直しました。今度は経路図のPDFがLaydyneの2回の呼び出しで作られ、関係するシェルコマンドは2回でした。それでも所要時間は6分13秒です。エージェントは空いた時間で案Aを計算し直して根拠をそろえ、1.7 MBの案件ファイルを88回のシェルコマンドで少しずつ書き出しました（未解決の課題）。下のファイルは、このやり直しの成果物です。

案Bの3台のロボットの、1回目の計算で記録された経路。get_process_drawing のPDFから。線は記録点を結んだもので、混雑や速度は表しません。

案Bの寸法入りA3図面。梱包台を南へ移し、東の壁際に充電器3台（と予備1台）。

資料一式：平面図と経路図のPDF、台数の比較表、保存したA/B比較、案件ファイル、エージェントが書いた運営責任者向けの要約。

結果

作り直したモデルと正解モデル

手順1のモデルを、写真の事例と同じ採点スクリプトで測りました。作り直したモデルを壁の中心で正解モデルに重ね、同じ種類の部品を近いものから対応させます。エージェントが同じものを別の種類で作ることがあるので、棚とラック、受け渡し台と作業台はそれぞれ同じ種類として数えました。全結果は score-first-run.json と score-rerun.json にあります。

図面からならセンチメートル、写真からはメートル。 同じ採点で、写真から作ったモデルの誤差は中央値1.97 mでした。今回はすべての寸法が図面の縮尺から来ています。残る数センチは描かれた線の太さで、エージェントは壁を線の太さで作り、壁際の柱を壁ごと1つの箱にしていました。

4列のパレットラックのうち3列が、奥行き半分で作られました。 図面では、ラックの中央に線があり、その線の上にラックの名前が書かれています。名前の白い縁取りが片側の塗りに滲み込み、Laydyneの読み取りは各ラックの半分しか返しませんでした。図面との照合もその半分と一致しました。半分の辺も図面の線の上にあるからです。エージェントはPR2とPR3の間のすき間を「狭い通路」として報告していました。読み取りを修正（下記）してやり直すと、エージェントは4列とも1.1 mで作りました。このやり直しでは柱も24本すべて見つけています。一方、事務所の間仕切りを壁として作ったため、間仕切りとしては対応しませんでした。

灰：正解モデル。橙：1回目の作り直し。青の破線：修正後の作り直し。

奥行き半分のラックは、ロボットの試算結果には影響していません。ロボットは予備保管の区画に入らないからです。

トークンと時間

失敗した呼び出しはどれもエージェントの入力の誤りで、Laydyneはそれぞれ対処できる理由を返しました。

• Laydyneが受け付けない工程の指定（待ち時間ではない手順に作業の記録を付けた、ロボットの池に優先度を付けた）
• 充電の仕事の数が違う2つの定義を、同じ仕事量として比べようとした
• 編集の直後に、古い版番号で保存を2回送った
• 3Dでしか使えない描画の指定（状態の文字、ヒートマップ）
• 直前に戻した設計案に含まれていない定義を実行した
• PDFを分けて送るとき、最初の断片に表示の設定を付けて断られ、続く断片もすべて失敗した（修正済み）
• 扉が床の端を1 cm以下はみ出した（どちらへどれだけはみ出たかを返すよう修正済み）

手順2と3のやり直し（変更後）

このユースケースの後、Laydyneは機体の群れの各ロボットを全回で返すようになりました。受けた仕事の数、走行距離、仕事をしていた時間の割合を、それぞれ平均と95%区間で返します。電池のモデルも加えました。走行と時間で電池が減り、空いたときに閾値を下回っていたロボットは最寄りの空いた充電器へ行き（なければ空くのを待ち）、充電器の速さで充電します。手順1のモデルから充電器を除いた状態に戻し、手順2と3の依頼文を変えずに、同じエージェントと設定で送りました。

• 1つの結果から各ロボット。 エージェントは20回分の1つの結果から各ロボットの距離を読みました。2.5時間のピークで4.86 km、4.81 km、4.86 km、仕事をしていた時間は90.7%、90.8%、90.7%です。乱数を1回ずつ計算し直すことはしませんでした。
• ロボットごとの電池。 仕様書から電池を設定しました。充電器の外で1時間12.5%（1回の充電で8時間）、充電器で1時間125%（作業1時間あたり6分）、70%から82.5%まで充電し、開始時は82.5%。3時間の試算の中で充電が起きるようにするための仮定だと明記しています。各ロボットは1回の試算で2回充電し、充電にかかった時間はロボットの時間の8.5%で、仕様書の11分の1（9.1%）に近い値です。ロボット4台・充電器3台では、充電器の待ちが平均36秒ありました。
• 3台では1時間95.4トート（1回ずつでは90.4〜98.0）、トートがロボットを待った時間は平均13.8分、ロボットが仕事をしていた時間は90.7%、充電にさらに8.5%でした。
• 2台・3台・4台（1回の掃引、各20回）：1時間あたり77.0件、95.4件、105.5件（95%区間は76.6〜77.4、94.4〜96.4、103.7〜107.3）、1台あたりの距離は5.83 km、4.84 km、4.03 km。どの差もばらつきを超え、4台でも110件に届かないのは1回目と同じです。

これらは1回目の数値を直したものではありません。今回のエージェントは、梱包台をロボットが受け渡し台を出たときからではなく、梱包台に着いたときから梱包の終わりまで押さえました。押さえる時間が短くなるので処理量は上がります。また1回目は充電の仕事も完了数に数えていました。手順4と5はやり直していないので、上の提案資料は1回目のものです。

Laydyneで直したこと

• 読み取り：名前の縁取りが滲み込んだ部品の塗りを、はみ出しを除いて読み直します。中央に線のあるラックは両半分とも返り、trimmed と注記されます。
• 経路図のPDF：get_process_drawing に format: "pdf" を加えました。縮尺付きの図面に経路、乱数、時間の範囲、ロボットごとの色の凡例を載せます。
• 下絵の分割送信：opacity と visible は、どの断片と一緒に送ってもよくなりました。点や配置の指定を早く送った場合は、その断片を捨てて理由を返し、続く断片が失敗し続けることはなくなりました。
• 床からはみ出した部品：どちらの端をどれだけ越えたかと、扉は openings で壁に付ければ壁の中に収まることを返します。
• 版の記号：表題欄の版の欄が長い記号に合わせて広がります（「Proposal」が「Propos…」と切れていました）。
• 各ロボットを全回で：試算の結果は各ロボットの仕事の数・距離・仕事をしていた時間の割合を平均と95%区間で返します。台数の掃引には1台あたりの距離と最も忙しい・空いているロボットが加わり、比較は両案のロボットを並べて示します。
• 電池：ロボットの池に電池を持たせられます。走行と時間で減り、閾値で充電に行き、充電器を取るか空くのを待ちます。結果には充電にかかった時間の割合、1時間あたりの充電回数、充電器の待ち、最低の電池残量が出ます。

できないこと

• ロボット同士の交通。 Laydyneが計算するのは経路、容量、待ちの列です。通路でロボットがすれ違う、追い越す、ふさぎ合う、人の近くで減速する、といったことは計算しません。半径0.5 mは、ロボットがどこを通れるかを決めるだけです。
• 電池は簡単なモデルです。 1回目の試算では、充電をロボット全体に1時間3回の6分間の仕事として表し、2台・3台・4台で同じにしていました。仕様書と比べると、4台では1台あたりの充電が少なく、2台では多くなります。やり直しでは各ロボットが電池を持ち、残量は距離と時間で減り、充電器で一定の速さで増えます。満充電に近づくと遅くなる充電、充電器への接続の時間、劣化、温度は計算せず、ロボットが仕事の途中で充電に行くこともありません。
• ピッキングと出荷。 トートは要望どおりの頻度で受け渡し台に現れるとし、ピッキングする人は計算していません。梱包後の荷物の動きはモデルの外で、これが梱包台を移すときの主なコストです。
• 梱包台の仮定が答えを決めています。 要望には、梱包台に何個のトートを置けるかが書いてありませんでした。エージェントは1個とし、ロボットが向かい始めてから梱包が終わるまで予約されるとしました。今の配置ではどの台数でも1時間110件に届かなかったのは、このためです。顧客に次に聞くべきは、梱包台のローラー棚に何個置けるかです。
• 図面は実測ではありません。 高さ、搬入口のピット、名前のない什器の用途は図面に描かれておらず、エージェントは未確認と記録しました。図面の表題欄にも、寸法は現地で測っていないと書かれます。
• 実際の倉庫の数字。 ピーク、ゾーンの割合、梱包時間、ロボットの速度は、要望と仕様書の値です。Laydyneはそれを一貫した再現できる結果にしますが、実際の倉庫の予測ではありません。

試してみる

1. 自分のエージェントをMCPでLaydyneにつなぎ（Codex、Claude Codeなど。説明）、Studioを開いておきます。
2. 顧客の図面（寸法が1つ以上あるPDFかPNG）と処理量をフォルダに置きます。この検証を繰り返すなら、図面と要望を使ってください。
3. 上の5つの依頼文を1つずつ送ります。
4. 手順1のモデルを正解モデルと比べます。

node apps/studio/scripts/score-photo-rebuild.mjs docs/articles/amr-proposal/answer-key.laydyne.json your-model.laydyne.json --class shelf=rack --class conveyor=bench --class cabinet=bench

モデル化、図面、経路図、書き出しは無料です。シミュレーションの実行にはProが必要です。