配置をLaydyneに探させる：以前の3つの提案を解き直す

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

2026-10-07。AIエージェント（Codex）が、利用者自身のAIと同じようにMCPでLaydyneを操作しました。数値はすべて実行から取ったもので、出典つきの一覧はfacts.jsonにあります。以下の「最良」は、いつも「探した候補の中で一番よい」という意味で、最適の証明ではありません。

だれが、何をしたかったか

3人とも、すでにLaydyneで案を手で比べていました。

• ロボットのインテグレーターの提案担当（AMR導入提案）。顧客はピーク時に1時間110件の注文を求めています。顧客の今の配置でロボット4台（案A）と、梱包台4台をピッキング区画の南へ移してロボット3台（案B）を比べ、案Bを提案しました。
• 展示会の主催者（60 × 100 mの展示ホール）。ステージの位置を奥・中央・入口側の3通りで、来場者の歩行と待ち、観客と配信カメラからの見通しを比べました。
• 小さな診療所と仕事をする設計者（診療所の提案）。受付と会計を同じカウンターで行う案A と、会計の窓口を分ける案Bを、医師が見積もった忙しい午前で比べました。

どれも、だれかが思いついた2〜3案から選んでいます。今回の問いは、変えてよい所・判断の指標・守ることを伝えれば、Laydyneが候補を作り、同じ条件ですべて計算して順位を付けられるか。そして、その順位は人の選んだ案と合うか、です。

Laydyneが今できること

search_layouts は3つを受け取ります。

• 変えてよい所：部品の塊を線上・範囲内・ずらし量で動かす、回す、列の間隔を変える、並んだ台のうちいくつ残すか、台数や人数などのシナリオのパラメータ、配置一式の選択肢。
• 判断の指標：シミュレーションがすでに出している指標（待ち時間・処理量・歩行距離・稼働率・見通しの割合）を1つ、最小化か最大化。同点を分ける2つ目の指標も指定できます。
• 守ること：配置の検査の新しい指摘がない（重なり・狭い通路・扉の前・床の外）、空けておく範囲、動かさない部品、計算結果の閾値。

Laydyneは候補を一つずつ作り、規則に反する候補を計算の前に除き、残りを今の配置と同じ乱数・同じ回数でブラウザのタブの中で計算します。よい順に、95%区間と、今の配置・最良案との対ごとの差を付けて返します。候補が予算より多いときは標本を取り、最良の周りを細かく探します。上位はいくつか固定の配置案として保存され、ふだんの比較とその報告にそのまま使えます。今の配置は変わりません。

Studioには、エージェントが動かしている探索がそのまま出ます。進み具合と中止、終わると順位、保存された案を比較で開くボタンです。

Studioの実行パネルの探索カードの上部（1章の倉庫の探索をMCPで送ったもの）。探索を始めるのはエージェントで、人はここで読んで確かめます。

流れと、使う道具・出てくるものはflow.jsonにあります。

1. 倉庫：ロボットは何台で、梱包台はどこに置くか

提案担当がエージェントに送った依頼（抜粋。全文、英語）：

What may change: the number of robots (2, 3, 4 or 5); the four packing benches pack-1 to pack-4 as one block, with its centre anywhere on the aisle line z = 27.5 m from x = 5 to x = 53 m in 2 m steps; and the spacing of the benches (4, 5.5 or 7 m centre to centre). Keep clear: the office and the outbound staging lane. No new layout-check problems. The peak must still reach 110 orders an hour. Goal: the fewest robots; among those, the lowest average wait. The same 20 runs and seed as the proposal, so the numbers line up with Option B.

Laydyneが探したもの。 台数4通り × 位置25通り × 間隔3通り = 300候補。60は計算の前に除きました（52は梱包台が床の外に出る、8は壁かラックと重なる）。残りの240をそれぞれ20回（今の配置を除いて4,800回のピーク）、ブラウザのタブで19秒で計算しました。そのうち138は処理量の閾値に届きませんでした。

見つかったもの。 ロボット3台、梱包台の列の中心は x = 17 m、台の間隔4 m。中心 x = 15 m が2位で、1位とはばらつきの範囲内でした。人が選んだ案Bは、3台で、x = 17.5 m あたりに7 m間隔。探索は台数と場所で案Bと一致し、列を詰めました。

顧客の配置との差分を get_view_image で描いたもの。エージェントは描くために候補を一度当て、そのあと顧客の配置に戻しました。

同じ乱数で対にした、探索の最良と案Bの差：待ち −22.4秒（−31.0〜−13.8）、ロボットの走行 −708 m（−764〜−653）、顧客の注文 +0.34件/時（0.11〜0.57）。3つともばらつきを超えていますが、処理量の差は意味のある大きさではありません。

確かめられなかったこと。 依頼の閾値はシミュレーションの処理量にかけていましたが、これは完了したすべての仕事を数え、このシナリオは充電を1時間に約3件の仕事として表しています（AMRの記事の脚注のとおり）。エージェントはこれに気づき、20個の乱数を1つずつ仕事ごとの記録つきで実行し、観測窓の中で完了した顧客の注文だけを数え直しました（全仕事の合計は探索の値と小数まで一致）。案Bも探索の最良も、顧客の注文の平均は1時間110件に届きません（どちらも区間は110を含みます）。同じ300候補を処理量最大で探し直した1位（5台）も109.5件でした。探索が言えるのは、梱包台をどこに置くべきか、台数は制約ではないことまでで、このモデルで1時間110件に届くとは言えません。前の記事の梱包台の仮定（ロボットが向かい始めてから梱包が終わるまで台を確保する）を、まず顧客に確かめる必要があります。

2. 展示ホール：ステージをどこに置き、通路をどれだけ広くするか

主催者の依頼（抜粋。全文、英語）：

Where the stage goes: in any of the three zones (the far end, the centre, near the entrance, as in the saved arrangements, with the booths in the other two zones), and shifted sideways by −8, −4, 0, 4 or 8 m. How wide the cross aisles between the booths are: try 0.9, 1.2, 1.5 and 1.8 m. Sight lines must hold: everyone in the audience zone sees the whole stage front, and our streaming camera sees at least 99 % of it. No new layout-check problems. Goal: the least walking in total; among equals, the lowest average wait. The same 3 runs and seed 7 as before.

Laydyneが探したもの。 エージェントは、3つの配置 × 4つの通路幅を12通りの配置一式として書き（人の案を保存済みの設計案から読み、幅ごとにブースの位置を計算）、横のずれをずらし量にしました。60候補です。配置の規則に反する候補はなく、40は見通しが足りず計算の前に除かれました（中央と入口側のすべて）。奥の20候補をそれぞれ3回、19秒で計算しました。

見つかったもの。 ステージは奥で、西へ4 mずらし、通路は0.9 mのまま。上位5つはすべて奥・通路0.9 mでずれ方だけが違い、互いにばらつきの範囲内でした。通路を広げた候補はどれもそれより下の順位です。

奥の配置で、ステージ一式を西へ4 m、通路0.9 m。エージェントが保存したプロジェクトから、あとで私たちが描いた3D（エージェントは2D平面図で示しました）。

人の奥の案との対ごとの差：歩行 −0.22 km（−0.83〜+0.38）、待ち +0.10秒（−1.16〜+1.36）、どちらもばらつきの範囲内です。中央・入口側と比べると総歩行は27 km少なく、ばらつきを超えています。入口側と比べると待ちは3.9秒長く（1.1〜6.6）、これも超えています。探索は人の選択を裏付け、探した範囲にこれらの指標でよりよい案はありませんでした。3回では区間が広くなります。数値をそろえるため、前回の比較の回数のままにしました。

3. 診療所：人員の分け方と会計の窓口

設計者の依頼（抜粋。全文、英語）：

The doctor asks: without hiring anyone (2 receptionists and 2 nurses today; the 2 doctors stay), what is the best way to cut the time from arriving to leaving? Let Laydyne search it instead of us guessing: how the four front-desk and nursing staff are split (each at least 1, together at most 4), and whether payment shares the counter (layout A) or has its own window (layout B). Goal: the shortest average time from arriving to leaving. The same 20 mornings and seed. And how many waiting chairs the best needs, against the 20 chairs we have.

Laydyneが探したもの。 保存した午前のシナリオは人数が固定だったので、エージェントはまずそれをパラメータにしました（配置Aは受付と看護師、配置Bは受付・会計・看護師）。ほかは変えていません。1回の探索ではシナリオを切り替えられないため、受付の配置ごとに1回ずつ探し、人数の合計を計算前の規則にしました。Aは9通りのうち3つが合計を超え、6つを計算。Bは8通りのうち4つが超え、4つを計算。各候補を20回の午前で計算し、2回の探索は0.4秒と0.3秒でした。

見つかったもの。 どちらの配置でも、最良の分け方は今と同じ受付2人・看護師2人でした。Aでの最良は人の案Aそのもの、Bでの最良は案Bです。来院から帰るまでの時間は同点で（BとAの差 +0.27秒、−11.8〜+12.3、ばらつきの範囲内）、前回の比較のとおり、案Bは待ちを受付から医師の前へ移すだけで、来院時間は短くなりません。

Aのほかの分け方と今の分け方の差（同じ午前で対に）：受付3人・看護師1人は来院時間が21秒長く（4〜37秒）、2人・1人は29秒長く（13〜45秒）、受付1人では5.6分長くなります（3.9〜7.4）。受付の待ちが6.9分増え、医師の前の列が6.3分短くなるためです。どれもばらつきを超えていて、どれも悪くなります。制約は医師のままです。48.8分のうち29.5分が医師の待ちで、ほかの4人の分け方ではこれは変わりません。

椅子。 エージェントは、待合の同時最多人数を午前ごとに1回の呼び出しで取りました（今回足した perRun）。10、22、18、12、32、6、19、22、8、21、10、19、14、13、10、13、15、15、14、9。平均は15人ですが、20回のうち4回は20脚を超え、1回は32人でした。設計者は、椅子を増やすか、9時の集中をならす予約にするかを、この数字で医師と話せます。

かかったもの

1回目のあと、ユーザーの指示でモデルを変えました。3列はモデルや課題の同条件の比較ではありません。 倉庫の回の時間と呼び出しの大半は、顧客の注文を数え直すエージェント自身の確認に使われました（シナリオの書き込み80回と、乱数1つずつの実行80回）。観測窓の中の、1つの工程の完了数を数える指標がないためです。探索そのものは数秒でした。

失敗した呼び出しの多くは、エージェントが探索の入力の形を探ったものです。Codexはツールの入力を型の宣言としてモデルに見せますが、変えてよい所のリスト（6種類からの選択）と、サーバーがフィールド間で共有している部分を unknown と表示していました。倉庫の回では {type, key, ids, line} と3回推測し、エラーから正しい名前を読みました。その後、種類のない指定には全種類とその項目・例を返すようにし、道具の説明に依頼の例を1つ入れました。ホールと診療所の回では、最初のエラーから正しい種類に進みました。残りの失敗は、同じく unknown と表示されたほかの項目（カメラの向け先、観客の範囲、ずらし量はリストではなくオブジェクトで渡すこと）、6件以上の結果の要求、診療所での、1回の探索の中で2つのシナリオから選ぼうとしたもの（探索はこれができません）です。

目安として、ブラウザのタブでの探索は遅い部分ではありません。倉庫の300候補 × 20回の格子は、同じ依頼を直接送ると16.3秒（エージェントの回の中では19秒）、Nodeでは23.2秒でした。

計算しないもの

• 探索は、指定した候補だけを見ます。範囲・刻み・乱数・回数の外は試していません。標本を取る探索はすべてを試しません。
• ロボット：衝突回避、交差する交通、混雑による減速、加速、電池の物理は計算しません。充電は予定された確保です。ピッキングと出荷の積み込みはモデルの外です。
• ホール：混雑や密度による減速、人が視線をさえぎることは計算しません。見通しは図面上の遮る物だけです。
• 診療所：到着とサービスの時間は医師の概算で、実測ではありません。
• 区間は、試した乱数の中でのばらつきです。同じ乱数で多くの候補から一番よいものを選ぶと、運のよかった候補が少し有利になります。小さな差に頼る前に、選んだ案を別の乱数で計算し直してください。

ファイル

• 実行後のプロジェクト（Laydyneのプロジェクト JSON。保存した案と比較つき）：倉庫、ホール、診療所。
• エージェントが受け取った探索の結果：倉庫、ホール、診療所。倉庫の顧客注文の数え直し：amr-order-audit.json。
• 依頼文：倉庫、ホール、診療所。この記事の数値と出典の一覧：facts.json。