AIツール比較 2026年10月1日

ChatGPT・Gemini・Claudeに在庫発注数量を計算させたら3社とも正解｜丸める順番を間違えると容量オーバーになる罠に全社が気づけた

この記事は 2026年10月1日に運営者が実際に検証した内容に基づきます。

「仕事タスク実測」シリーズの第13弾。今回は発注点・安全在庫・保管容量という在庫管理の基本ルールを組み合わせ、AIが自らゼロから発注数量を計算する「最適化」型のお題にした。段階的単価トリック(17戦目・19戦目で連投)とは違う罠として、「制約を適用する順番を間違えると、計算は合っているのに致命的な容量オーバーを起こしてしまう」という構造を仕込んだ。

検証の条件

検証日: 2026-10-01
使用モデル: ChatGPT(ログイン済み・既定モデル)、Gemini(当初Proモデルで検証を試みたが技術的トラブルが発生したためFlashモデルで検証。詳細は後述)、Claude(claude.ai・新規チャット、Opus 5.5・エフォート「中」)
取得方法の補足: 3社とも各社UIの新規チャット・新規タブに依頼文全文を入力して送信し、生成された回答全文を照合したうえで転記した
3社に投げた依頼文(一字一句同一)

あなたは株式会社フォレストサプライの物流センターで発注業務を担当しています。以下の条件に基づいて、主力商品「業務用ハンドソープ詰め替えパウチ(500ml、品番HS-500)」について、今回の発注で何個発注すべきかを決めてください。

【需要実績】過去60営業日の出荷実績によると、1日あたりの出荷数は平均120個。この60営業日の中で最も出荷数が多かった日(最繁忙日)の実績は180個だった。

【仕入先の納期(リードタイム)】発注してから入荷するまでの日数は平均6日。過去の実績の中で、最も時間がかかったケースでは10日かかったことがある。

【在庫管理のルール(社内規定)】・安全在庫は、「最大日次出荷数180個×最長リードタイム10日」から「平均日次出荷数120個×平均リードタイム6日」を差し引いた数量とする、と社内規定で定められている。・発注点は、「平均日次出荷数×平均リードタイム」に安全在庫を加えた数量とする。・「在庫ポジション」とは、倉庫にある手持ち在庫と、既に発注済みでまだ入荷していない発注残(未入荷分)を合計したものを指す。この在庫ポジションが発注点を下回った時点で、追加発注が必要と判断する。・発注を行う際は、在庫ポジションを「安全在庫に、平均日次出荷数20日分を上乗せした水準」まで引き上げることを目標在庫水準としている。

【現在の在庫状況】・倉庫にある手持ち在庫: 1,400個・既に発注済みで、まだ入荷していない発注残: 300個

【保管容量の制約(絶対に超えてはならない物理的な上限)】このSKU専用の保管スペースには、手持ち在庫・発注残・今回新たに発注する数量をすべて合計した数量で、最大3,200個までしか置くことができない。発注残(まだ入荷していない分)も、入荷され次第このスペースへ搬入される予定の数量であるため、入荷前の時点から保管スペースを事実上確保しておく必要があり、手持ち在庫と同様に容量計算へ含めるものとします。目標在庫水準に近づけることよりもこの上限を守ることを最優先とし、1個でも超える発注をしてはならない。

【仕入先の発注ロットの制約】この仕入先からは1ケース=150個単位でしか発注を受け付けてもらえない。端数(ケース未満)の個数では発注できない。

【依頼内容】上記の条件をすべて踏まえ、以下を求めてください。

安全在庫は何個か

発注点は何個か

現在の在庫ポジション(手持ち在庫+発注残)は何個で、発注点と比較して今回発注が必要かどうか

目標在庫水準は何個か

保管容量の上限と仕入先のロット制約の両方を守ることを絶対条件としたうえで、欠品リスクをできるだけ下げるために目標在庫水準になるべく近づけるには今回何個発注すればよいか。発注数量を「ケース数」と「個数」の両方で明示し、その数量に決めた理由を計算過程とともに説明してください。

正解

安全在庫: 1,080個(180個×10日−120個×6日)
発注点: 1,800個(120個×6日+1,080個)
在庫ポジション: 1,700個(手持ち1,400個+発注残300個)で、発注点1,800個を下回るため発注が必要
目標在庫水準: 3,480個(1,080個+120個×20日)
発注数量: 10ケース=1,500個

核心の罠は最後の発注数量の決め方にある。目標在庫水準まで引き上げるための素朴な逆算値は3,480個−1,700個=1,780個だが、これを先にケース単位(150個)へ丸めると1,780÷150=11.86…→切り捨てて11ケース=1,650個という数量を導いてしまいやすい。しかしこの場合、発注後の在庫ポジションは1,700+1,650=3,350個となり、保管容量の上限3,200個を150個(ちょうど1ケース分)超過してしまう。正しい手順は「先に容量制約から発注可能な上限(3,200−1,700=1,500個)を算出し、その範囲内でケース単位に丸める」ことであり、1,500÷150=10ケースがちょうど容量上限と一致する唯一の正解になる。

採点基準

10項目×各1点の計10点で、以下を見た。

安全在庫を正しく計算できているか(1,080個)
発注点を正しく計算できているか(1,800個)
在庫ポジションに発注残を正しく含め、発注点と比較して「発注が必要」と判断できているか
目標在庫水準を正しく計算できているか(3,480個)
容量制約を適用する際、発注残を含めた1,700個を基準にしているか
【核心】保管容量の制約から先に発注可能な上限を算出し、その範囲内でケース単位に丸めているか(目標値からの逆算値を先に丸めて容量超過する誤りをしていないか)
最終的な発注数量を10ケース=1,500個として明示できているか
発注後の在庫ポジション(3,200個)が容量上限を超えておらず、発注点を上回っていることを確認しているか
計算過程・結論に矛盾や論理の飛躍がなく一貫した説明になっているか
依頼文に存在しない前提を勝手に創作していないか

結論から

ChatGPT=9/10、Gemini=10/10、Claude=10/10。3社とも最終結論(10ケース=1,500個)と核心の罠(容量制約を先に適用する判断)は完全に正しく処理した。
差がついたのは論理的一貫性のみ。ChatGPTは回答冒頭の要約文に本文の結論と矛盾する記述があった。
Geminiは当初Proモデルで検証を試みたが、応答が長時間生成されないハングが発生したため、既定のFlashモデルに切り替えて検証した。

ChatGPTの場合

結論・計算は正しいが、冒頭の要約文に自己矛盾。9/10。

計算すると、今回の発注数量は10ケース＝1,500個が上限かつ最適です。
ただし、社内規定の「発注点を下回ったら発注」という判定だけでいえば、現時点では発注不要です。以下、順番に整理します。

(中略、以下本文で正確な計算を展開)

3. 現在の在庫ポジションと発注要否
在庫ポジションは、手持ち在庫1,400個＋発注残300個＝1,700個です。
発注点は1,800個なので、1,700個＜1,800個となります。
したがって、今回の発注は必要です。

本文中の計算(安全在庫1,080個・発注点1,800個・在庫ポジション1,700個・目標在庫水準3,480個・発注数量10ケース=1,500個)はすべて正確で、容量制約を先に適用してケース単位へ丸める核心の手順も正しく踏んでいた。しかし回答の最初の2行で「現時点では発注不要です」と述べており、これは直後の本文「1,700個＜1,800個のため、今回の発注は必要です」と真っ向から矛盾している。要約だけを読むと逆の結論に見えてしまう自己矛盾があり、この点のみが減点理由になった。

Geminiの場合

一貫して正確。ただし検証中に技術的トラブルが発生した。10/10。

1. 安全在庫の計算
最大需要・最長ケース: 180個/日×10日=1,800個
平均需要・平均ケース: 120個/日×6日=720個
安全在庫=1,800個−720個=1,080個

(中略)

5. 今回の発注数量と決定理由
目標達成に必要な1,780個を発注すると上限(3,200個)を超過するため、上限制約により最大でも1,500個までしか発注できません。
1ケース(150個)単位でしか発注できないため、1,500個をケース数に換算します。
1,500個÷150個/ケース=10ケース(端数なし)

結論(今回の発注数量)
ケース数: 10ケース
個数: 1,500個

計算過程・結論・説明の一貫性のいずれにも問題はなく満点とした。ただし実測の過程で、当初選択していたProモデルに依頼文を送信したところ、60秒以上経っても応答が1文字も生成されないハングが発生した。停止ボタンで中断し新規チャットで再送信しても同じ現象が再発したため、Proモデルでの検証を断念し、既定のFlashモデルに切り替えたところ正常に応答を得られた。本記事のGemini回答はFlashモデルによるものである点を明記しておく。

Claudeの場合

計算・説明に加え、独自の洞察を追加。10/10。

5. 今回の発注数量:10ケース(1,500個)

目標まで必要な数量
3,480 − 1,700 = 1,780個 → ケース換算で 11.87ケース(12ケースなら1,800個)

保管容量の上限による制約
発注可能な最大数量 = 3,200 − 1,700 = 1,500個
12ケース(1,800個)は合計3,500個となり、上限を300個超えます。
11ケース(1,650個)でも合計3,350個となり、上限を150個超えます。

ロット制約との整合
1,500個 ÷ 150個 = 10ケースで、端数なく割り切れます。

補足
保管上限3,200個は目標在庫水準3,480個より低く設定されています。このため、今後も上限の範囲内で発注する限り、目標在庫水準には構造的に到達できません。継続的に目標水準を満たしたい場合は、保管スペースの拡張か、在庫ルール(目標の上乗せ日数など)の見直しを検討する余地があります。

12ケース・11ケースのどちらを選んでも容量を超過することを具体的な数値(3,500個・3,350個)で示したうえで10ケースに絞り込んでおり、核心の罠への対応が特に丁寧だった。さらに依頼文では問われていない「保管容量の上限が目標在庫水準より低く設定されているため、この社内規定のままでは恒久的に目標水準へ到達できない」という構造的な指摘を自発的に追加しており、採点基準にない観点まで踏み込んだ実務的な提案になっていた。

比較表

項目	ChatGPT	Gemini	Claude
安全在庫1,080個	○	○	○
発注点1,800個	○	○	○
在庫ポジション1,700個・発注残の算入	○	○	○
目標在庫水準3,480個	○	○	○
核心: 容量制約を先に適用して丸める	○	○	○
発注数量10ケース=1,500個	○	○	○
発注後在庫ポジションの確認	○	○	○
説明の論理的一貫性	冒頭要約が本文と矛盾	○	○
存在しない前提の創作	なし	なし	なし
得点	9/10	10/10	10/10

この検証で分かったこと

今回は3社とも核心の罠(制約適用の順序を誤ると容量オーバーになる)を正しく処理し、最終結論も完全に一致した。これまでのシリーズで何度か見られた「全社が同じ理由で同じ落とし穴に落ちる」パターンとは逆に、今回は「全社が同じ落とし穴を正しく回避できた」回になった。差がついたのは計算そのものではなく、結論に至る説明の組み立て方だった。ChatGPTは正しい計算をしていながら、要約文だけを先に書いたために本文と矛盾する結論を一瞬示してしまった。AIの回答を読む際は、冒頭の要約だけで判断せず、本文の計算過程まで確認することの大切さが分かる結果だった。

また、Geminiで発生した「Proモデルが長時間応答を返さずハングする」という技術的トラブルは、このシリーズで初めて観測したパターンだった。過去には逆に軽量モデル(Flash)側で異常な拒否応答が出てProモデルに切り替えて解決した事例があり、どちらのモデルでも一時的な不具合が起こりうることが分かる。AIサービスに重要な計算を任せる際は、一つのモデルで応答がおかしい・止まってしまうときは、別のモデルに切り替えて再試行してみる価値がある。

第12弾の研修予算150万円配分の最適化対決、第11弾の清掃会社シフト表の矛盾探し対決もあわせてご覧ください。

本記事は2026年10月1日に、運営者が各サービスを実際に操作して検証した内容に基づく。料金・仕様は変更される場合があるため、最新情報は各公式サイトを確認してほしい。