# codex 敵対的検証 結果 1回目（何台入れたら店は変わる） - 日時: 2026-10-24 18:50（JST） - 依頼文: codex_敵対的検証依頼_何台入れたら店は変わる.md（md5 2e9afb7a8b0d4f49a7afe221c04e9ca4・25,339 バイト） - 題（依頼文の1行目）: # 敵対的検証依頼：YouTube台本「配膳ロボット、何台入れたら店は変わる？ ― ファミレスの混む2時間を、0台から6台まで試算した」 - codex: codex-cli 0.163.0-alpha.11 - モデル: gpt-6.1-sol - 考える深さ: high - ウェブ検索: あり（検索した回数 8） - かかった時間: 15分15秒 - 使ったトークン: 181,214 - 指摘の数: 27（うち出典のリンクが付いたもの 1） - 出典の URL: 1件（別々・文の中に張られた回数 1） --- 判定は **「直してから」** です。主な問題は数字の転記よりも、**独自の判定基準を通ったことを「人を減らして店が回る」と表現している点**と、**仮の運用ルールの結果を実機の限界に結びつけている点**です。 確認範囲を明記します。 - 公開中の試算ページ・シリーズページ・LOG351／359／367は、ウェブから取得できませんでした。**公開画面で条件を選んだ照合は未確認**です。 - 関連フォルダの [v2.7試算ページのローカル版]()、[v2.7コード]()、保存結果、記事原稿を読みました。以下の「試算ページ」「コード」は、このローカル資料を指します。公開版との同一性は未確認です。 - 主要な数値はローカル資料と一致しました。S064には後述する表示上の丸めの差があります。SimPyが実行環境にないため、**今回の再計算と統計的なばらつきの確認は未実施**です。 - すかいらーくの導入実績は公式サイトでも確認できました。 --- **[❌ NG] S018・S062・S064・S066〜S067・S079** 問題：「1人少なくても回る」は、サービス水準を保って人を減らせたように聞こえます。実際には、独自の入店待ち基準を通っただけで、料理の待ち時間などは悪化しています。 根拠：試算ページで、人数を減らす前後を比較すると次のとおりです。 | 条件変更 | 入店待ち | 料理が届くまで | |---|---:|---:| | 混雑ファミレス：4人・0台→3人・1台 | 11.4→17.4分 | 45秒→2分17秒 | | 食べ放題：3人・0台→2人・1台 | 9.2→9.8分 | 1分17秒→3分26秒 | | 洗い場が遠い店：3人・0台→2人・1台 | 2.9→6.0分 | 1分06秒→2分22秒 | | 大型店：6人・0台→5人・2台 | 9.7→7.4分 | 57秒→2分25秒 | さらに食べ放題の2人・1台では、完成から到着まで3分を超える料理が約55%あります。「回る」の判定は、これらを条件にしていません。 修正案：「店によっては、1人少なくしても、今回の入店待ちの基準は通りました。ただし、料理が遅くなる条件もあります。同じサービスを保って人を減らせた、という意味ではありません。」 --- **[❌ NG] S051** 問題：本人の感想として引用していても、「いまの配膳ロボットの限界点」が今回の結果で分かった、という受け取りになります。今回確認したのは、仮のロボットと運用ルールを組み合わせたモデルの挙動です。 根拠：料理を2分待たせるルール、秒速0.5m、作業時間などを設定した結果であり、現行製品の性能限界を測定していません。本人の感想の真偽ではなく、引用の置き方の問題です。 修正案：「エイイチは、『いまの配膳ロボットの限界点も、よくわかった』と感じたそうです。ただ、今回確かめたのは、この試算の条件での限界です。実機全体の限界が分かったわけではありません。」 --- **[❌ NG] S032** 問題：「ぶれの範囲と見ています」に続く「変わらない、と見てください」は、根拠を示さず増加を打ち消しています。40回平均という情報だけでは、ぶれかどうかも、実用上同等かどうかも判断できません。 根拠：3台2.906分に対し4台3.897分で、差は約1分、約34%です。確認した保存結果は平均値で、反復ごとの分散や差の信頼区間は確認できませんでした。同じコード・同じ乱数で再現しても、この統計的な問題は解消しません。 修正案：「4台では3.9分と、3台より延びています。偶然のばらつきかどうかは、この平均値だけでは判断できません。ここでは、2台目までのような大きな短縮は見られなかった、と読んでください。」 --- **[❌ NG] S013・S027〜S029・S073〜S074** 問題：省略している前提のうち、人員の結論に直接効くものが説明されていません。特に、料理をロボットに積み込み、行き先を設定するためのスタッフの時間が計上されていません。 根拠：コードの `deliver()` から `_robot_run()` では、スタッフを確保せず、待っている料理をまとめて出発させています。`load_s` は下げ膳への積み込みで使われ、上げ膳には使われません。したがって、ロボットを導入すると運搬の仕事は減りますが、その準備に必要な人の仕事が追加されないモデルです。 修正案：「もう一つ、料理をロボットに載せて、行き先を設定する人の時間は、今回の計算に入れていません。人を減らせるかを見るには、ここも実際の店に合わせて確かめる必要があります。」 --- **[❌ NG] S036〜S037・S049** 問題：「動いていた割合」「出ずっぱり」は、計算している指標と違います。「残りは受け渡し口の前」「6台が並ぶ」も、位置を計算していない試算からは確認できません。 根拠：`robot_util` は、全処理が終わるまでの時間に対する、1台平均の仕事でふさがっていた時間です。走行のほか、客の取り出し待ち25秒、一時停止、救出待ちなどを含みます。6台平均22.5%から、6台が同時に並んで待つ様子は分かりません。 修正案：「6台では、1台あたり、仕事でふさがっていた時間は平均で約23%。走る時間だけでなく、お客さんが料理を取るのを待つ時間なども含みます。台数に対して、出番は少なくなりました。」 S049は「1台では、この割合が約75%でした」に変更。 --- **[⚠️ 要注意] S012** 問題：「席は空いているのに」と「満席」の区分は、実際の着席状況をそのまま再現したものではありません。この区分が、人員の合否を決める中心指標になっています。 根拠：コードでは、客が案内される前に卓を確保します。その卓は、案内待ちの間も使用中として扱われます。後続客の待ちが「満席」側に入る場合があり、物理的に客が座っているかとは一致しません。判定への影響量は未確認です。 修正案：「このモデルで、片付け待ちと、案内する人の手が空くまでの待ちを足して、平均10分以上なら『店が回らない』と呼びます。実際の店の営業可否を決める基準ではありません。」 --- **[⚠️ 要注意] S015・S025・S039・S077** 問題：「2台目まで」という境目が、35卓という店の大きさから決まるように聞こえます。また、席待ちの改善が小さいことから、導入すべき台数までは決まりません。 根拠：対象は35組/時、スタッフ3人、料理を運ぶだけ、ロボット優先2分という条件です。料理の到着は2台約62秒から3台約39秒へ短縮しており、何を改善したいかで台数の評価が変わります。 修正案：「今回の35卓・35組毎時・スタッフ3人で、料理を運ぶだけの条件では、席待ちの大きな改善は2台目まででした。料理を早く届けたい場合は、3台目にも効果が出ています。」 --- **[⚠️ 要注意] S016・S054・S078** 問題：「何台入れても」は、試した範囲を超えています。「このファミレスの普通の日には、ありませんでした」は、後で紹介する巡回回収とも衝突します。 根拠：確認したのは0〜6台です。また、同じ店・同じ来客ペースでも、巡回回収なら2人・3台で判定を通っています。 修正案：「このファミレスで、普通の混み具合、料理を運ぶだけなら、試した0台から6台の範囲では、2人で基準を通る条件はありませんでした。」 --- **[⚠️ 要注意] S063〜S066** 問題：「普通の混み具合で比べます」では、来客数などをそろえた業態比較に聞こえます。実際には、業態以外の条件もまとめて変えています。 根拠：ファミレス35組/時、食べ放題20組/時、洗い場が遠い店22組/時、大型店60組/時。食事時間や追加注文数も異なります。食べ放題は来客を発生させる時間も150分で、ほかの120分と違います。 修正案：「ここからは、それぞれの店に別々に置いた『普通』の条件です。来客数も、食事の長さも違います。食べ放題だけは、混む時間を2時間半にしています。店の種類だけを変えた比較ではありません。」 --- **[⚠️ 要注意] S064** 問題：「9.8分で、ぎりぎり」は、入店待ち9.8分を10分の判定線と比べたように聞こえます。判定に使う数字は別です。 根拠：入店待ちは9.803分ですが、判定対象の「席はあるのに」は9.191分です。また、40回平均が線を下回っても、各回で安定して通るかは未確認です。 修正案：「1台では、入店待ちが9.8分に。判定に使う片付け・案内の待ちは9.2分で、今回の10分の線を下回りました。ただし、毎回安定して通るかまでは、この平均だけでは分かりません。」 --- **[⚠️ 要注意] S061** 問題：客が皿を載せることが、結果を左右する前提なのに省略されています。ロボットの使い方を変えるだけで、自動的に2人で回るように聞こえます。 根拠：コードでは回収が完了するたびに、最後の下げ膳の往復を1回減らします。客が載せない、十分な量が集まらない、といった場合は表現していません。 修正案：「この使い方では、ロボットが回収に来るたび、お客さんが一定量の皿を載せてくれる前提です。その条件なら、2人と3台で、今回の基準を通りました。」 --- **[⚠️ 要注意] S033〜S035・S057** 問題：残った待ちの原因を、片付けと案内だけに絞りすぎています。「人の手の速さで決まります」も、作業時間、優先順位、来客の集中などを一括してしまっています。 根拠：コードではスタッフが案内・配膳・会計・呼び出し・片付けを共通で担当し、片付けの優先順位は案内・配膳・会計より低く設定されています。作業別に条件を変えた検証は今回確認できていません。 修正案：「料理の運搬を任せても、片付けや案内、会計などは人に残ります。今回の作業時間と仕事の優先順位では、人の仕事を待つ時間が残りました。」 --- **[⚠️ 要注意] S011・S016・S054・S073** 問題：「ホールのスタッフを減らせるか」という問いに対し、実際の勤務体制を決める仕事がモデルの外にあります。 根拠：スタッフは全員が同じ能力で各仕事を引き受ける共通資源です。担当分け、厨房との兼務、休憩、ピーク前後の準備、清掃などは表現していません。調理にも人数や設備の取り合いがなく、設定した時間で料理ができます。 修正案：「ここで比べるのは、モデルに入れたホールの仕事を、何人で処理できたかです。厨房との兼務や準備、休憩まで含めた、その店の必要人数ではありません。」 --- **[⚠️ 要注意] S046〜S050・S052** 問題：「現場なら空いている人が運べばよい」という反論に、説明はありますが検証結果はありません。「ロボットの出番が減る」は、その運用が悪い理由にはなりません。 根拠：ロボットの稼働割合は、待ち時間や人の負担とは別の指標です。同じv2.7のほかの条件を固定して、優先待ち0秒・30秒・120秒などを比較した結果は未確認です。 修正案：「現場なら、空いた人が先に運ぶ運用も考えられます。今回は、ロボットを優先して使う決まりを試した結果です。2分待つのがよいか、すぐ人も運ぶ方がよいかは、別に比べる必要があります。」 --- **[⚠️ 要注意] S071** 問題：「誰が先に運ぶかで、答えが変わりました」は、この回で運用ルールをそろえて比較した結果まで示したように聞こえます。 根拠：この回の数値比較はv2.7内の台数・人数・使い方が中心です。前の版の説明はありますが、同条件でルールだけを変えた定量比較は提示していません。 修正案：「今日の比較では、台数と任せる仕事で答えが変わりました。そして、誰が先に運ぶかという決まりも、結果に関わっています。」 --- **[⚠️ 要注意] S011・S042〜S045** 問題：「料理が席に届くまで」の終点が、視聴者の想像とずれる可能性があります。 根拠：コードは卓への到着時点で料理の待ち時間を記録し、その後にロボット25秒、人10秒の受け渡し時間を置きます。客が取り終わるまでの時間ではありません。 修正案：「料理の時間は、できあがってから、人かロボットが卓に着くまでです。そこから料理を取り出す時間は含めていません。」 --- **[⚠️ 要注意] S026・S081** 問題：台本の数字を再現するための条件が一つ抜けています。また、「最大3卓」は、コードのまとめ運びの単位を正確には説明していません。 根拠：該当行は `fragile_by="any"`、つまりデザート・ドリンクもロボットが運ぶ設定です。まとめ運びは最大3件の料理で、異なる3卓であることを保証していません。 修正案：「ロボットは料理を運ぶだけ。デザートやドリンクも任せ、待っている料理を一度に最大3件まとめて運ぶ設定です。」 --- **[⚠️ 要注意] S005・S028・S038** 問題：「ファミレスの混む2時間を再現」は、ピーク開始時点ですでに客がいる店を想像させます。今回の計算は空の店から始まります。 根拠：コードは初期客なしで開始し、120分で新規来客を止め、処理が終わるまで回します。歩く距離は客の退店後の片付けまで含むため、「送り出すまで」より範囲が広いです。 修正案：「空の店に2時間だけお客さんが来て、最後の片付けまで計算しています。すでに混んでいる店の2時間を切り取ったものではありません。」 S038は「そのお客さんが帰ったあとの片付けまでに」に変更。 --- **[⚠️ 要注意] S074** 問題：一時停止を仮に入れている説明だけでは、台数を増やしたときの混雑を扱っているようにも聞こえます。 根拠：コードの停止確率は各往復で固定です。ロボットが増えたことで互いを妨げる仕組みはありません。試算ページ自体にも、ロボット同士の通路待ちを入れていない旨の注意があります。 修正案：「停止は、台数に関係なく、往復ごとに同じ確率で入れています。台数を増やしたせいでロボット同士が邪魔になることは、まだ計算していません。」 --- **[⚠️ 要注意] S075** 問題：「3Dで走らせて確かめる」だけでは、現実の妥当性まで確かめられるように聞こえます。 根拠：3D上の動きも、人やロボットの動作ルールに依存します。SimPyとUnityの一致は、現場で同じことが起こる証明にはなりません。 修正案：「そのあと、図面から3Dの店を建てて、通路や動きの影響を調べます。実際の店にどこまで合うかは、現場の観察や実測とも照らしていきます。」 --- **[⚠️ 要注意] S070〜S072・S083** 問題：最も強い反論は、「仮の運用で問題を作って、その結果から専門家の必要性を説いていないか」です。相談窓口への誘導が続くため、宣伝として読まれる余地があります。 根拠：今回の試算には、専門家が関与した場合としなかった場合の比較がありません。「仕事の流れを調べる必要がある」から「専門家が必須」までは導けません。必要な知見を持つ人が、店長や現場スタッフである可能性もあります。 修正案：本人の見立ては残し、S072を変更。 「ハコブくんなりに言うと、まず、店の仕事を知る人と一緒に、運び方を確かめることです。その人は、店長やスタッフかもしれないし、メーカーや導入支援の人かもしれません。」 --- **[⚠️ 要注意] S065〜S066** 問題：「1台の効き目がいちばん大きい」は、何を比べた順位なのか不明です。また、洗い場が遠い店で効いたことから、洗い場の遠さが原因だとは言えません。 根拠：通常表示の人数で入店待ちの短縮量を見ると、大型店は約8.7分、食べ放題は約5.5分です。一方、S064のスタッフ2人での比較なら食べ放題は約17.6分短縮します。「洗い場が遠い店」には追加注文など別の違いもあり、ここでロボットに任せているのは上げ膳です。 修正案：「この食べ放題の設定では、スタッフ2人のまま1台足すと、入店待ちが約18分短くなりました。洗い場が遠い設定の店でも、料理の運搬を任せることで、今回の基準を通りました。」 --- **[⚠️ 要注意] S018** 問題：「人を減らさずに足せば、待ち時間ははっきり縮みます」は、「待ち時間」全体への断定です。直後の料理の悪化と矛盾して聞こえます。 根拠：この条件で1台導入すると、入店待ちは短縮しますが料理の到着は遅くなります。台数を追加するたびに改善する結果でもありません。 修正案：「今日の条件では、人を減らさずに1台、2台と足すと、席に着くまでの時間は短くなりました。一方、料理の待ちは、1台では延びています。」 --- **[⚠️ 要注意] S064** 問題：公開ページと同じ表示値を確かめるという点では、27.5分に小さな不一致があります。 根拠：保存結果は27.4502分なので、直接小数1桁に丸めれば27.5分です。しかしローカルHTMLには27.450として収録され、ページのJavaScriptの `toFixed(1)` では27.4分になります。転記ミスというより、表示までの丸めの問題です。公開画面は未確認です。 修正案：「ロボットなしでは、約27分半。」 または、ページ側の表示精度と台本を統一。 --- **[⚠️ 要注意] S002** 問題：1.4台という計算は成立しますが、導入店舗平均であり、典型的な店舗の台数や適正台数を示す数字ではありません。 根拠：公式の沿革に、2022年12月、約2,100店へ3,000台の導入完了とあります。3,000÷2,100≒1.43です。店舗別の分布は示されていません。提示された2022年2月の開示資料は計画なので、実績の出典は公式沿革に替える方が明確です。[すかいらーく公式「歴史・沿革」](https://corp.skylark.co.jp/about/history/) 修正案：「導入した約2,100店で単純に割ると、1店平均で約1.4台です。店ごとの台数や、ちょうどよい台数が分かる数字ではありません。」 --- **[⚠️ 要注意] S029** 問題：「急がないのも、配膳ロボットの仕事のうち」は、仮に置いた速度を、実機の安全性や設計意図で裏付けたように聞かせます。 根拠：この試算では速度を固定しており、安全性や混雑に応じた速度調整を評価していません。店や会社を笑う表現ではありませんが、前提の説明としては曖昧になります。 修正案：「ロボットは仮に秒速0.5メートル、人は秒速1メートルとしました。この速さも、実際の店で測った値ではありません。」 --- **[⚠️ 要注意] S019〜S025・S040〜S043・S053〜S054** 問題：結論の先出し、目次、節タイトル、「一言で言うと」が重なっています。特に料理が遅くなる話は、答えを何度か明かしたあとにクイズを置いています。 根拠：S006・S021・S023・S040・S041のあとでS043の問いかけが来るため、意外性を作る構成として機能しにくくなっています。必要な但し書きを増やすなら、ここが削減候補です。 修正案：S019〜S023を次の一文に置換。 「まず、スタッフ3人のまま台数を増やした結果から見ます。」 S040〜S043は次に圧縮。 「ところが、料理の待ちは別でした。ロボットなしの58秒が、1台では2分12秒に延びたんです。」 --- 最後の判定です。 1. **このまま公開してよいか：直してから。** 構成全体を作り直す必要はありません。ただし、「回る」「限界」「ぶれ」「動いていた割合」の意味は修正が必要です。 2. **公開前に必ず直すべき文番号：** **S012〜S013、S015〜S016、S018、S032、S036〜S037、S049、S051、S054、S061〜S064、S066〜S067、S070〜S075、S077〜S079。** とくに、人員削減の文には「今回の入店待ち基準を通った」という限定と、料理の待ちが悪化する事実を戻してください。 3. **台本の結論そのもの：条件つきで成立。** 「このモデルでは、席待ちと歩行距離の大きな改善が2台目まで」「台数・仕事・運用ルールで結果が変わる」は支持されます。一方、**実店舗の必要人数、現行ロボットの性能限界、専門家の必須性までは、この試算からは成立しません。** また、「3台目以降は同等」とする統計的な裏付けと、公開中の試算画面との一致は未確認です。