リトルの法則 計算

「仕掛を3割減らせ」と言われて、リードタイムは何日縮むのか

改善会議で必ず出る指示だ。そして必ず、その場では答えが出ない。おかしな話で、必要な式は L = λ·W の1行しかなく、答えは電卓で出る。それでも議論が止まるのは、計算が難しいからではなく、その1行が「どの系について言っているのか」を誰も決めないまま話しているからだ。

ライン全体の仕掛なのか、機械加工の前後だけなのか、受注を受けてから出荷するまでなのか。系の境界が1本動けば、λ（通過量）も W（滞在時間）もまるごと別の数字になる。「うちのリードタイムは4日だ」「いや2週間だ」と食い違うとき、多くの場合どちらも正しく、ただ数えている箱が違う。

このツールは、その箱を決めたうえで数字を突き合わせるために作った。スループット λ・仕掛在庫 WIP・リードタイム W の3つのうち2つを入れると残り1つが出る。1日200個を流すラインに仕掛が800個あれば、リードタイムは4.0日。ただしこの4日は「加工に4日かかっている」という意味ではない。4日の中身は、どの工程にどれだけ仕掛が置かれているかだけで決まる。まずはそこから見ていく。

なぜ作ったのか — 式1行のツールに、載せる価値があるとしたら

「リトルの法則 計算」で検索して驚いた。日本語圏に、数値を入れて確かめられるブラウザ完結のツールが1つも見つからない。上位に並ぶのは Wikipedia の定義、シンクタンクの解説コラム、ERPベンダー（SAP／Infor／Microsoft）が自社製品の文脈で書いた記事、コンサル企業の理論紹介。どれも式は書いてあるが、自分の現場の数字を入れる場所が無い。

理由は察しがつく。式が1行だからだ。WIP ÷ λ を電卓で叩けば終わる計算に、わざわざツールを作る人はいない。だが実装してみて、1行だからこそ「その先」が丸ごと抜け落ちていることに気づいた。

リトルの法則が言えるのは「仕掛が多いとリードタイムが長い」までだ。肝心の「その仕掛は減らせるのか」には何も答えない。処理のばらつきで自然に溜まった仕掛なら、削ろうとしても工程が手待ちになるだけで戻ってくる。逆にロットをまとめる都合や前倒し着手で意図的に積んだ仕掛なら、運用を変えれば消える。この2つは現場で見ても区別がつかない。

そこで、M/M/1 の待ち行列近似を同じ画面に並べて出すことにした。「ばらつきだけで説明できる滞在時間」を別ルートで計算し、実測と対比させる。部品加工ラインの例では、実測リードタイム4.0日に対して待ち行列近似はわずか0.1日。40倍の差は、ばらつきでは説明できない量の仕掛がそこに置かれていることを意味する。つまり、そこが削れる。一方で個別受注生産の例では実測8.0日に対し近似1.0日と差が縮まり、削りしろの割合が違うことが数字で見える。

削れる仕掛と削れない仕掛の切り分け。これが式1行のツールに載せる価値だと判断した。

リトルの法則 とは — 分布に一切依存しない、面積の話

リトルの法則 とは — 同じ面積を、縦に切るか横に切るか

リトルの法則は待ち行列理論の基本定理で、定常状態にある系について L = λ·W、つまり「系の中にいる平均個数 ＝ 平均到着率 × 平均滞在時間」が成り立つ、というものだ。驚くのはその適用範囲で、到着がどんな分布でも、処理時間がどんな分布でも、処理の順序が先入先出でも後入先出でも成り立つ。

なぜそんなに強いのか。答えは、これが確率の定理というより面積の数え方の定理だからだ。

横軸に時間、縦軸に「そのとき系の中にいる個数」を取ったグラフを描く。1個入るたびに段が1つ上がり、1個出るたびに1つ下がる、階段状のギザギザした線になる。この線の下の面積を考える。

面積を横に薄く切って足すと、「各時刻の系内個数 × 微小時間」の総和になる。観測期間で割れば平均系内個数 L だ。同じ面積を縦に細く切って足すと、今度は「1個1個が系の中に居た時間」の総和になる。観測期間で割ると、（通過した個数 ÷ 期間）×（1個あたりの平均滞在時間）、すなわち λ·W になる。

同じ面積を2通りの向きに数えているだけなので、両者は必ず等しい。だから分布も順序も関係ない。前提はたった2つ、系の境界が決まっていることと、定常状態にあること（長い目で見て入った数と出た数が釣り合っていること）だけだ。冒頭で「系の境界を決めないと議論が噛み合わない」と書いたのは、それが唯一にして絶対の前提だからだ。

身近な例なら高速道路の渋滞区間が分かりやすい。ある5kmの区間に常時1,000台の車が乗っていて、1時間に4,000台がその区間を通過しているなら、1台がその区間を抜けるのにかかる時間は 1000 ÷ 4000 = 0.25時間 = 15分。個々の車が速かろうと遅かろうと、車線変更が多かろうと、区間内の台数と通過台数さえ分かれば通過時間は決まってしまう。

外部参考: リトルの法則（Wikipedia）。生産管理用語としてのリードタイム・仕掛品の定義は JIS Z 8141:2001 生産管理用語 を参照。

リードタイム 仕掛 計算・スループット 求め方 — 3方向の逆算は単位で確認する

式が1本なので、2つ決まれば残り1つは一意に決まる。3方向とも単位が必ず整合するのが確認になる。

W = L / λ    // [個] ÷ [個/日] = [日]      リードタイムを求める
L = λ × W    // [個/日] × [日] = [個]      仕掛在庫を求める
λ = L / W    // [個] ÷ [日] = [個/日]      スループットを求める

単位が合わない組み合わせは入力の取り違えだ。よくあるのは「スループットは1日単位、リードタイムは時間単位」で混ぜてしまうケースで、10倍以上ずれる。時間の単位はスループット・処理能力・リードタイムの3つすべてで揃える必要がある。

工程単位でも成立する — リードタイムの内訳は仕掛の配置そのもの

ここからがリトルの法則の本領だ。系の境界はどこに引いてもいいという性質を、1つの工程に対して使う。

直列につながったラインでは、定常状態なら同じ λ が全工程を通過する。切断工程を1日200個通ったものは、機械加工も200個、検査も200個通る（そうでなければどこかで仕掛が無限に増える）。だから工程 i だけを1つの系と見なしてリトルの法則を当てると、その工程の滞留時間は次で求まる。

W_i = WIP_i / λ            // 工程 i の滞留時間
ΣW_i = ΣWIP_i / λ = W      // 総和は全体のリードタイムに一致する

これは実務的にかなり重い結論だ。リードタイムの内訳は、仕掛の配置そのもので決まる。どの工程が「遅い」かではなく、どの工程の前に仕掛が積まれているかが、そのまま時間の配分になる。作業者が忙しそうに見える工程ではなく、山積みの中間品が置かれている工程が時間を食っている。

同時実行数 スループット 応答時間 — ITでも文字が違うだけの同じ式

同じ式は製造業の外でもそのまま使える。Webシステムの性能設計で出てくる「同時実行数 ＝ スループット × 応答時間」は、L = λ·W の L を同時実行数、λ をリクエスト処理件数、W を応答時間と読み替えただけの、文字通り同一の式だ。スループット50件/秒・応答時間0.4秒なら同時実行数は20件。応用情報技術者試験の性能設計で頻出する計算はここに帰着する。

なお、この式は「λ をどこまで上げられるか」については何も言わない。そこは待ち行列理論の領分で、稼働率を上げるとどうなるかは §4 以降で扱う。

なぜこの数字が実務に効くのか — 待ち時間が大半を占めるという事実

リードタイムを縮めたい、という要求はどの現場にもある。ここでリトルの法則を W = L / λ の形で見ると、意外に窮屈な結論が出てくる。λ は客先要求（＝出さなければならない量）で決まっているので、勝手に下げられない。すると W を縮める直接の手段は、L すなわち仕掛を減らすことしか残らない。

「頑張って早く作る」は各工程の正味加工時間を縮める施策で、待っている時間には効かない。そして待ち時間こそがリードタイムの大半を占める。使用例のケース1では、リードタイム4.0日のうち1.9日（47.5%）が機械加工の前で滞留している。ここに1個置かれた部品は、加工されるまでほぼ2日待つ。加工そのものを2割速くしても全体は数%しか縮まないが、この工程の前の仕掛を半分にすれば1日近く縮む。

稼働率を上げるほどリードタイムが跳ね上がる

もう1つ、現場の直感を真正面から裏切る事実がある。M/M/1 モデルでの滞在時間は 1/(μ(1−ρ)) で、稼働率 ρ が1に近づくと発散する。

• ρ = 85% → 滞在時間は 1/(μ×0.15)
• ρ = 95% → 滞在時間は 1/(μ×0.05)（85%のときの 3.0倍）
• ρ = 98% → 滞在時間は 1/(μ×0.02)（ρ=50%のときの 25倍）

設備を止めずに回すほど効率が良い、という発想は投資回収の観点では正しいが、リードタイムの観点では逆方向に効く。稼働率を95%まで詰めたラインは、設備の軽微な故障や1人の欠勤で簡単に能力不足側へ落ちる。能力に余裕を残すほうがリードタイムは安定する。実務で「稼働率85%前後を目安に」と言われるのは、規格に定められた基準があるからではなく、この非線形が効き始める入口がその辺りだからだ。

仕掛を持ちすぎることの実害

滞留時間が長いこと自体が、金額に見える形で害を出す。滞留中に設計変更が入れば仕掛全部が作り直しになる。長期滞留は錆・変質・打痕といった品質劣化を招く。仕掛はそのまま寝ている運転資金で、800個の仕掛は800個分の材料費と加工費を先払いしている状態にほかならない。そして最も痛いのが、不良の発見が遅れることだ。工程間に2日分の仕掛があれば、上流の異常は2日後にまとめて発覚する。そのとき手戻りするのは1個ではなく、その2日間に流れた全数になる。

この論点は中小企業診断士の運営管理でリードタイム短縮・仕掛削減として頻出し、応用情報技術者の性能設計でも同じ式が形を変えて出る。試験対策としても、実務の説明資料としても、数字で語れるかどうかが分かれ目になる。

こんな場面で使う

改善会議の前の試算。 「仕掛を3割減らす」という目標に対して、リードタイムが何日縮むのかを先に出しておく。目標値が独り歩きする前に、削減率と時間短縮の対応を数字で持っておくと議論が具体になる。

リードタイムが長い原因工程の特定。 工程ごとの仕掛数を入れると、リードタイムのどこが誰に食われているかが構成比で出る。ストップウォッチで作業時間を測る前に、仕掛の置かれ方から当たりをつけられる。

設備投資・要員計画の検討。 「この設備、稼働率をどこまで上げてよいのか」を稼働率−リードタイム曲線で確認する。稼働率90%と96%でリードタイムがどれだけ違うかを見てから、増設するか投入を絞るかを決められる。

Webシステムのキャパシティ見積もり。 想定スループットと目標応答時間から同時実行数を逆算し、スレッドプールやコネクションプールの上限設計に使う。時間単位を秒にすれば、そのまま性能設計の画面になる。

基本の使い方

1. 求める量と時間単位を選ぶ。 リードタイム／仕掛在庫（WIP）／スループットのうち、どれを求めるかを選ぶ。選んだ量の入力欄は消え、残り2つだけを入力する形になる。あわせて時間単位を日・時間・秒から選ぶ。製造ラインの分析なら日か時間、Webシステムの性能設計なら秒を選ぶと、スループットや数量の単位表記もまとめて切り替わる。

2. 残り2つの数値を入れる。 たとえばリードタイムを求めるなら、スループットと仕掛在庫を入力する。リードタイムは2通りの単位で併記され、日を選んだ場合は稼働8時間/日で換算した時間数も表示される（暦日の24時間換算ではない点に注意）。

3. 工程別の内訳を入れる。 工程名・その工程の仕掛数・処理能力を1行ずつ追加すると、工程ごとの滞留時間と構成比、ボトルネック工程、稼働率、待ち行列近似との対比が表示される。工程は最大8行まで。行を全部消しても構わない——その場合は工程別の情報が出ないだけで、基本計算は通常どおり動く。仕掛の削減率を入れれば、削減後のリードタイムと短縮量も試算される。

具体的な使用例 — 8ケースで確かめる

すべて実装済みの計算エンジンに同じ値を入れて出力を確認した数値を載せている。時間単位はケース4を除きすべて「日」。

ケース1: 部品加工ライン（少量多品種）— 実測4.0日 vs 近似0.1日

入力: スループット 200個/日、仕掛在庫 800個、削減率 30%。工程は 切断（WIP120／能力240）・機械加工（WIP380／能力210）・バリ取り（WIP180／能力300）・検査（WIP120／能力260）。

結果: リードタイム 4.0日（＝32.0時間、稼働8時間/日換算）。工程別の滞留は 切断0.6日（15.0%）／機械加工 1.9日（47.5%）／バリ取り0.9日（22.5%）／検査0.6日（15.0%）。ボトルネックは機械加工（210個/日）で稼働率 95.2%【危険】。待ち行列近似の滞在時間は 0.1日、その系内数は 20.0個で、実際のWIP800個は近似の 40.0倍。30%削減すると WIP560個・リードタイム2.8日で、1.2日の短縮。

解釈: このラインの本題は40.0倍という比だ。処理のばらつきだけなら20個で回るはずの系に800個が置かれている。差の780個は変動の結果ではなく、ロットまとめ・前倒し着手・工程間バッファとして意図的に積まれた仕掛と読める。つまりここは運用を変えれば削れる。同時に稼働率95.2%は危険帯で、これ以上投入を増やすとリードタイムが跳ね上がる領域に入っている。

ケース2: 組立ライン（量産）— 同じ4工程でも桁が違う

入力: スループット 1,200個/日、仕掛在庫 1,500個。工程は 部品供給（WIP300／能力1500）・組付（WIP600／能力1300）・ねじ締め（WIP350／能力1400）・検査（WIP250／能力1600）。

結果: リードタイム 1.25日（＝10.0時間）。工程別は 部品供給0.25日（20.0%）／組付0.5日（40.0%）／ねじ締め0.2917日（23.3%）／検査0.2083日（16.7%）。ボトルネックは組付（1,300個/日）、稼働率 92.3%【注意】。待ち行列近似の滞在時間0.01日・系内数12.0個で、実測は近似の125.0倍。30%削減で WIP1,050個・0.875日、0.375日の短縮。

解釈: ケース1と工程数も構造も同じなのに、リードタイムは4.0日から1.25日へ、桁が1つ違う。仕掛の絶対数はむしろ多い（1,500個 > 800個）のに短いのは、λ が6倍あるからだ。仕掛の多さそのものではなく、λ との比がリードタイムを決めるという当たり前の事実が、2ケースを並べると数字で見える。

ケース3: 個別受注生産（受注→出荷）— 近似との差が縮まる系

入力: スループット 8件/日、受注残 64件。工程は 設計（WIP20／能力12）・製作（WIP30／能力9）・検査出荷（WIP14／能力20）。

結果: リードタイム 8.0日（＝64.0時間）。工程別は 設計2.5日（31.3%）／製作3.75日（46.9%）／検査・出荷1.75日（21.9%）。ボトルネックは製作（9件/日）、稼働率 88.9%【注意】。待ち行列近似の滞在時間 1.0日・系内数 8.0個で、実測は近似の 8.0倍。30%削減で 44.8件・5.6日、2.4日の短縮。

解釈: ケース1と対比すると面白い。あちらは40.0倍、こちらは8.0倍。個別受注生産は案件がばらばらに飛び込み、処理時間も1件ごとに違うため、待ち行列モデルが想定する世界に近い。同じ「仕掛が多い」でも、系の性質によって「計画的に積んだ分」の割合はまるで違う。倍率が小さいケースで無理に仕掛を削ると、単に手待ちが増える。

ケース4: Webシステムの性能設計 — 同時実行数を逆算する

入力: 求める量を「仕掛在庫」に、時間単位を「秒」に切り替える。スループット 50件/秒、応答時間 0.4秒。工程は Webサーバ（WIP4／能力120）・アプリサーバ（WIP12／能力65）・DB（WIP4／能力80）。

結果: 同時実行数 20.0件（50 × 0.4）。応答時間0.4秒は 400.0ミリ秒と併記される。内訳は Webサーバ0.08秒（20.0%）／アプリサーバ0.24秒（60.0%）／DB0.08秒（20.0%）。ボトルネックはアプリサーバ（65件/秒）で稼働率 76.9%【良好】。待ち行列近似の滞在時間0.0667秒・系内数3.33件で、実測は近似の6.0倍。

解釈: 単位表記が「件/秒」「件」「ミリ秒」に総入れ替わりするだけで、計算は製造ラインとまったく同じだ。同時実行数20件という結果は、スレッドプールやコネクションプールの上限がこれを下回っていないかの直接のチェックに使える。応答時間の60%がアプリサーバで消費されている点も、チューニングの優先順位をそのまま示している。

ケース5: スループットを逆算する

入力: 求める量を「スループット」に切り替え、仕掛在庫 800個・リードタイム 4日。工程はケース1と同じ。

結果: スループット 200.0個/日。以降の工程別滞留時間・ボトルネック・稼働率・待ち行列近似は、すべてケース1と完全に一致する。

解釈: 実務では λ が分からないケースが意外に多い。日々の完成数がばらつくと平均が掴めないためだ。そういうときは、仕掛の平均数と「投入から完成まで何日かかっているか」という現場の実感値の2つから λ を逆算するほうが早い。3方向の逆算はこの用途のためにある。

ケース6: 能力不足 — 待ち行列近似が算出できなくなる

入力: ケース1の工程構成のまま、スループットを 250個/日 に引き上げる（仕掛在庫は800個）。

結果: リードタイム3.2日。稼働率 119.0%【能力不足】。待ち行列近似の滞在時間は算出不能となり、その旨の注記に切り替わる。

解釈: ボトルネックの機械加工は1日210個しか処理できないのに250個投入している。この状態では仕掛が毎日40個ずつ積み上がり続け、定常状態そのものが存在しない。リトルの法則の前提（入った数と出た数が釣り合う）が崩れているので、表示されるリードタイム3.2日も「今この瞬間の平均」であって、明日には伸びている。ここで必要なのは仕掛削減ではなく、能力増強か投入の抑制だ。

ケース7: 工程別の合計が全体と合わない

入力: スループット 200個/日・仕掛在庫 800個だが、工程別の合計が 700個（切断120／機械加工300／バリ取り180／検査100）。

結果: 差 −100個の注記が出る。滞留時間の構成比は工程別の合計700個を分母にして 17.1% / 42.9% / 25.7% / 14.3%。

解釈: これはエラーにしていない。「工程別に内訳を試算してみる」という使い方を潰さないためだ。ただし実測値を入れているつもりなら、100個はどこかで数え漏れている。よくあるのは、工程間の台車やパレット上の中間品を誰の工程にも計上していないパターンと、そもそも系の境界（受注残を含めるかどうか）が食い違っているパターンで、後者なら §3 の話に戻って境界を引き直す必要がある。

ケース8: 削減しすぎると前提が崩れる

入力: スループット 95個/日・仕掛在庫 20個、削減率30%。工程は 工程A（WIP8／能力100）・工程B（WIP12／能力120）。

結果: 稼働率 95.0%【危険】。待ち行列近似の系内数は 19.0個で、30%削減後のWIPは 14.0個。削減後の仕掛が待ち行列モデルの必要量を下回るため、スループット一定の前提が崩れる旨の注記が出る。

解釈: 仕掛削減の計算は「λ を変えずに L だけ減らせたら」という仮定の上に成り立っている。しかし稼働率95%の系では、ばらつきを吸収するためだけに19個の仕掛が要る。そこを14個まで削るとボトルネックが手待ちになり、落ちるのは λ のほうだ。この場合の正しい手順は、削減率を下げるか、先にボトルネック工程の能力を上げて稼働率を落とすこと。「削れる仕掛」には下限があることを、数字で示せる唯一の場面になっている。

仕組み・アルゴリズム

なぜ M/M/1 近似を選んだのか

滞在時間の推定には4つの選択肢があった。

手法	必要な入力	判断
(a) リトルの法則単体	λ・WIP・W の2つ	λ の上限が分からず、稼働率の議論ができない
(b) M/M/1 待ち行列近似	ボトルネック能力 μ のみ	採用
(c) Kingman 近似（G/G/1）	μ ＋ 変動係数 Ca・Ce	精度は上がるが入力コストが跳ね上がる
(d) 離散事象シミュレーション	工程ごとの分布・搬送・段取り	入力コストが桁違い

(a) だけでは「稼働率を上げるとリードタイムがどうなるか」という §4 の主題に触れられない。(c) の Kingman 近似は到着と処理のばらつき（変動係数 Ca・Ce）を入れれば実ラインにかなり近い値が出るが、変動係数は実測データを集めないと出せない値で、それを要求した瞬間に「手元の数字だけで確かめる」というツールの性格が壊れる。(d) は言うまでもない。

(b) を選んだのは精度が高いからではなく、入力がボトルネックの処理能力1つで済むからだ。そもそもこの近似値は予測値として使うのではなく、「ばらつきだけならこの程度で回るはず」という基準線として実測と対比させるのが目的なので、粗くても構わない。むしろ最も単純なモデルであることが、差の解釈を素直にしている。

計算フロー

入力: λ / WIP / W のうち2つ、工程行 [{name, wip, capacity}]、削減率 r
────────────────────────────────────────────
1. 基本計算（3方向の逆算）
     solveFor="leadTime"   → W   = WIP / λ
     solveFor="wip"        → WIP = λ × W
     solveFor="throughput" → λ   = WIP / W
     ※ 逆算した値にも直接入力と同じ上限ガードをかける
2. 工程別の積み上げ
     W_i  = WIP_i / λ
     構成比 = WIP_i / ΣWIP_i × 100 [%]
     積み上げリードタイム = ΣWIP_i / λ
3. ボトルネック抽出
     μ = min(capacity_i)          ← ラインの律速スループット
4. 稼働率
     ρ = λ / μ × 100 [%]
     isOverloaded = ( λ >= μ × (1 − 1e-9) )
5. M/M/1 近似（isOverloaded が false のときだけ）
     W_q = 1 / (μ − λ) = 1 / (μ(1 − ρ))
     L_q = λ × W_q     = ρ / (1 − ρ)
     比  = WIP / L_q               ← 「計画的に積んだ仕掛」の指標
6. 稼働率−リードタイム曲線
     ρ = 50,60,70,75,80,85,90,92,94,95,96,97,98 [%] の各点で 1/(μ(1−ρ))
     ※ 跳ね上がるのは95%以降なので、高稼働率側を密にサンプリングする
7. WIP削減の試算
     WIP' = WIP × (1 − r/100)
     W'   = WIP' / λ
     短縮  = W − W'

ケース1の数値を最後まで追うと次のようになる。800 ÷ 200 = 4.0日 → 機械加工の滞留 380 ÷ 200 = 1.9日（構成比 380 ÷ 800 = 47.5%）→ ボトルネック min(240, 210, 300, 260) = 210 → 稼働率 200 ÷ 210 = 95.2% → 待ち行列近似 1 ÷ (210 − 200) = 0.1日 → その系内数 200 × 0.1 = 20.0個 → 実測との比 800 ÷ 20 = 40.0倍。

設計判断1: 稼働率100%の判定に許容誤差を入れている

isOverloaded の判定に 1e-9 の相対許容誤差を入れているのは、見た目の慎重さではなく実害の回避だ。

λ を「仕掛 ÷ リードタイム」で逆算する経路では、倍精度の丸め誤差が境界をまたぐ。処理能力110個/日のボトルネックに対し、仕掛121個・リードタイム1.1日を入れると、121 ÷ 1.1 は 110 ではなく 109.99999999999999 になる。素直に λ >= μ で判定すると「まだ能力に余裕がある」と通ってしまい、μ − λ = 1.42e−14 から滞在時間が 70,368,744,177,664日（約70兆日） と表示される。

厄介なのは、この事故が静的解析にもテストベクトルの自動検証にもページ動作確認にも引っかからないことだ。数学的にちょうど能力いっぱいという境界の入力を手で叩いて初めて出る。そこで判定を λ >= μ × (1 − 1e-9) の形で1箇所に集約し、待ち行列の算出可否・警告の出し分け・曲線の描画可否・ステータス判定のすべてをこのフラグ1つから分岐させている。稼働率の4段階判定（95% / 85%の境界）にも同じ理由で許容誤差を入れてある。λ を逆算する経路では 94.99999999999999 という値が普通に出てきて、素の比較では1段下の帯に落ちるためだ。

設計判断2: WIP削減の試算は「λ 一定」であることを、崩れる場所ごと示す

削減後リードタイムの WIP' / λ は、仕掛だけを減らしてスループットは維持できた場合の値だ。この仮定は緩やかな削減では妥当だが、どこかで必ず破綻する。破綻を文章の注意書きで済ませず、判定して警告するようにした。

境界の置き方は明快で、削減後のWIPが待ち行列近似の系内数 L_q = ρ/(1−ρ) を下回ったときとした。L_q は「この稼働率で、ばらつきを吸収するためだけに必要な仕掛」なので、そこを割り込む削減は物理的に無理がある。ケース8がその実例で、稼働率95%の系では L_q が19.0個あるのに、20個を30%削って14.0個にしようとしている。この状態では削減の結果として落ちるのは λ のほうで、リードタイムは計算値ほど短くならない。

ちなみにこの判定は、「削れる仕掛が2倍以上ある」という別の情報表示と同時に出ることがある。矛盾ではなく、削れる余地は大きいが、この削減率は踏み込みすぎという意味だ。両方を読んで初めて「どこまで削ってよいか」が決まるので、あえて排他にしていない。

他ツールとの違い（リトルの法則 計算ツールの立ち位置）

日本語圏の検索結果が理論解説とベンダーの読み物に偏っている話は前半で触れたとおりなので、ここでは繰り返さない。本ツールが式1行の電卓に何を足しているかだけを、5点に絞って書く。

1. 3方向の逆算を1画面で切り替えられる。 リードタイム・仕掛在庫・スループットのどれを求めるかを選ぶと、選んだ量の入力欄が消えて残り2つだけを入れる形になる。W = L/λ と L = λ·W と λ = L/W を頭の中で組み替える必要がない。

2. 工程別に分解して滞留時間の内訳が出る。 工程ごとの仕掛数を入れると W_i = WIP_i/λ が工程数ぶん並び、横積み上げの帯グラフになる。全体のリードタイムが「何日」かではなく「どこで何日食われているか」まで降りる。

3. 稼働率−リードタイム曲線を描く。 稼働率を横軸、待ち行列近似の滞在時間を縦軸に取った折れ線に、いまの稼働率の位置をマーカーで打つ。式を見ても伝わらない「ある点から先で跳ね上がる」感覚が、線の形として一目で分かる。

4. 待ち行列近似との対比で「削れる仕掛」を切り分ける。 これが他に見当たらない部分。実際の仕掛が M/M/1 の推定系内数の何倍あるかを出し、倍率が大きいときは「差分は変動ではなく計画的に積んだ仕掛」と読める旨を注記する。

5. 製造業の日・時間と、ITの秒を同じ画面で扱える。 時間単位を秒に切り替えると、スループットは件/秒、数量は件、併記はミリ秒に総入れ替わりする。同時実行数＝スループット×応答時間 の計算がそのまま同じ画面でできる。

関連ツールとの役割分担も書いておく。タクトタイムと編成効率のツールはライン内で作業をどう配分するかの話で、1個あたりの正味時間を扱う。EOQ・安全在庫のツールはいくつまとめて発注し、どれだけ手元に置くかの話で、在庫の量を決める。本ツールはその中間にあって、時間と在庫を相互に翻訳する位置にいる。仕掛を減らす議論をするときは、まず本ツールで「何個減らすと何日縮むか」を出し、その削減が発注ロットの都合で不可能ならEOQ側、工程間の作業配分の都合ならラインバランシング側に話を渡す、という順番になる。

豆知識（リトルの法則の来歴と、その周辺）

「明らかに正しいが、誰も証明していない」式だった

リトルの法則は1961年に John D. C. Little が証明するまで、待ち行列の研究者が全員なんとなく使っている経験則だった。特殊なモデルごとに成立を確かめた例はあったが、到着や処理の分布に一切依存しない形での一般証明が無かった。だから論文のタイトルは公式の名前ではなく "A Proof for the Queuing Formula: L = λW"、つまり「証明」そのものが主題になっている。今では学部の教科書に1行で載っている関係が、当時は論文1本を要する主張だった、という順番が面白い。

仕掛をゼロにしてもリードタイムはゼロにならない

生産管理の教科書 Factory Physics には「臨界WIP（critical WIP）」という概念がある。仕掛を減らせばリードタイムは縮むが、どこまでも縮むわけではない。仕掛をゼロに近づけていくと、最後は正味加工時間そのもので下げ止まる。逆に言えば、臨界WIPより仕掛が少ない状態はボトルネックが手待ちになっている状態で、そこから先はスループットのほうが落ちる。本ツールが削減シミュレーションに前提崩れの注記を付けているのは、この境界を数字で示すためだ。

参考: Factory Physics - Wikipedia（英語）

1個流しは L を極小化する戦略そのもの

トヨタ生産方式の「1個流し」は、工程間に仕掛を置かず1個ずつ流す。これをリトルの法則の言葉に翻訳すると、λ を変えずに L を極限まで小さくしてリードタイムを縮める戦略になる。ロットでまとめて流すほうが段取り回数は減って効率が良さそうに見えるのに、なぜ1個ずつなのか——その答えが W = L/λ の1行に入っている。改善活動のスローガンが、実は待ち行列理論の定理の言い換えだったという構図。

参考: ジャストインタイム生産システム - Wikipedia

待ち行列理論は工場ではなく電話交換機から生まれた

そもそも待ち行列理論の出発点は生産現場ではない。デンマークの電話会社に勤めていた数学者 A. K. Erlang が1909年に、交換機の回線を何本用意すれば通話が待たされないかを解析したのが最初とされる。呼量の単位「アーラン」も彼の名前だ。工場の仕掛の話と電話網の回線設計が同じ数式で書けるのは、どちらも「入ってきて、待って、出ていく系」だからで、本ツールが製造業とITの両方の単位を持っているのも同じ理由による。

参考: Agner Krarup Erlang - Wikipedia（英語）

Tips（入力する前に決めておくと結果が変わる5つのこと）

• 系の境界を先に紙に書く。 受注から出荷までなのか、加工工程だけなのか、外注に出している期間を含むのか。境界が動けば λ も W も別の数字になる。工場全体で語っているつもりの人と、自分の担当ラインの話をしている人が同じ会議にいると、数字が一生噛み合わない。入力欄に数字を入れる前に、まずここを合わせておく
• 仕掛は「今この瞬間の数」ではなく期間平均で数える。 リトルの法則は定常状態の平均について成り立つ関係なので、月末に在庫を一斉に流し切った翌朝の数字を入れると実態より短いリードタイムが出る。1〜3か月ぶんの棚卸や日次カウントを均した値を使ってほしい
• 工程別の合計と全体の仕掛が合わないときは、まず数え漏れと境界の食い違いを疑う。 本ツールは合計がズレてもエラーにせず差だけを注記する（内訳を試算する使い方を潰さないため）が、実測値を入れているつもりならズレは情報だ。検査待ちの置き場や外注品の在庫が、全体には入っていて工程別からは抜けている、というパターンが多い
• 稼働率は上げすぎない。能力の余裕はリードタイムの保険。 稼働率−リードタイム曲線を描かせてみると、跳ね上がりが始まる位置が思ったより手前にあることが分かる。設備を止めずに回すほど得だという直感が最も裏切られるのがこの帯で、判定が「注意」「危険」に入ったら投入を増やす前に曲線の形を見てほしい
• ITの性能設計では、出てきた同時実行数を実際の上限と突き合わせる。 時間単位を秒にして求めた同時実行数が、アプリケーションサーバのスレッドプール数やコネクションプール数を超えていれば、その時点で待ちが発生している。具体的な数値の読み方は使用例のWebシステムのケースを見てほしい

FAQ（リトルの法則 計算ツール よくある質問）

工程を1つも入れなくても計算できる?

できる。工程の行を全部削除すると、基本計算とWIP削減シミュレーションだけが動く状態になる。この場合は工程別の滞留時間・ボトルネック・稼働率・待ち行列近似・稼働率曲線がまとめて非表示になり、代わりに「工程を追加すると内訳とボトルネックが出る」旨の案内が出る。同時実行数を求めたいだけ、手計算の答え合わせをしたいだけ、という使い方では工程を入れる必要はない。逆に、工程の行はあるが仕掛数か処理能力が1つでも空欄だと、その行を黙って無視せず工程セクション全体を止める。行を勝手に除外するとボトルネックが別の工程にすり替わってしまうためだ。

待ち行列近似の滞在時間が、実際のリードタイムと桁違いに小さいのはなぜ?

M/M/1 が最も単純なモデルだからで、そのズレ自体が読み取るべき情報になっている。M/M/1 は「到着がランダム、処理時間もランダム、窓口1つ」という条件での滞在時間なので、出てくる値は処理と到着のばらつきだけで自然に溜まる分でしかない。実際のリードタイムがそれより大幅に長いなら、差分はばらつきではなく、ロットをまとめて流す・前倒しで着手する・工程間にバッファを置くといった意図して積んだ仕掛だと読める。ばらつきは減らしにくいが、意図して積んだ仕掛は運用を変えれば減らせる。だから近似が当たっているかどうかより、どれだけ離れているかを見てほしい。

稼働率が100%を超えたと出たのに、現場では実際に生産できているのはなぜ?

考えられるのは2つ。1つは入力したボトルネック工程の処理能力が実力とずれている場合で、残業・応援・休日出勤・2直目を含めた実効能力が設備仕様の値より大きいことは普通にある。もう1つは定常状態の仮定から外れている場合で、期首の仕掛を食いつぶしながら流している期間や、受注のピークを一時的に押し込んでいる期間は、短期的には能力を超えた出来高が出る。ただしその状態が続けば仕掛は際限なく積み上がるので、本ツールは滞在時間を算出せず能力不足として扱う。まずは処理能力の入力値を、実績の出来高から逆算した値に置き換えて確かめてほしい。

リードタイムを日で表示したときの時間換算が、24倍になっていないのはなぜ?

稼働8時間/日で換算しているため。製造業でリードタイム「4日」と言うとき、それは暦の4日ではなく稼働日で4日を指すのが普通で、24時間で換算すると2倍以上ずれた数字になる。だから日を選んだときの併記は稼働時間ベースで出し、その前提を結果の補足にも書いている。3交替で24時間連続操業しているラインでは、この換算は実態と合わない。その場合は時間単位のほうを「時間」に切り替えて、スループットも仕掛も処理能力もすべて1時間あたりの値で入力し直すと整合が取れる。

削減率を上げるほどリードタイムが縮むと出るが、どこまで削ってよい?

削減シミュレーションはスループットを一定に保ったまま仕掛だけを減らせた場合の値なので、削りすぎるとこの前提そのものが崩れる。仕掛を減らしすぎるとボトルネックが手待ちになり、スループット側が落ちてリードタイムは計算値ほど短くならない。本ツールは削減後の仕掛が、その稼働率で待ち行列モデルが必要とする系内数を下回った時点で注記を出すようにしてある。逆にその手前であれば、削減の余地はまだ残っていると読める。なお削減率の入力は0でも構わず、その場合はシミュレーション部分が「削減率を入れると試算する」という案内に切り替わる。

入力した仕掛数や工程名は、どこかに送信される?

送信していない。計算はすべてブラウザの中だけで完結していて、スループット・仕掛在庫・リードタイム・工程名・各工程の処理能力といった入力値がサーバへ送られることはなく、保存もしていない。工程名には社内でしか通じない呼び名や、取引先名を含む工程名を入れることもあるはずなので、そのまま入れて問題ない。ページを再読み込みすれば入力内容は初期状態に戻る。結果を残したい場合はコピー機能で結果テキストを取り出して、手元のファイルや資料に貼り付けてほしい。

まとめ：時間と在庫を翻訳する1本の式

L = λ·W は式としては1行だが、系の境界を決め、工程ごとに分解し、稼働率の非線形と突き合わせるところまで行くと、リードタイム改善の議論に必要な材料がひととおり揃う。仕掛を何個減らすと何日縮むのか、その仕掛は削れるものなのか、稼働率をどこまで上げてよいのか——手元の数字を入れて確かめてみてほしい。

工程内の作業配分まで踏み込むならタクトタイム＆ラインバランシング計算、仕掛の元になる発注ロットと在庫水準を設計するならEOQ・安全在庫・発注点 計算が対になる。検査工程の負荷を見直すときは抜取検査 AQL・サンプルサイズ判定、ボトルネック工程のばらつきそのものを評価するなら工程能力指数 計算を使ってほしい。

計算結果が実感と合わない、この条件も扱ってほしい、といった要望があればお問い合わせページから知らせてほしい。実際のラインの事情を聞けるほど、判定の出し方は現場に寄せられる。