本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
Historical Math & Network Flow:M/M/1 & TCP BBR 高槻・淀川水運と情報工学 執筆:加藤 明生(ネットワークスペシャリスト / 登録情報処理安全確保支援士)

淀川三十石船と高槻藩の宿場物流を「待ち行列理論(M/M/1)」と 現代のインターネット輻輳制御(TCP BBR)で読み解く歴史数理紀行

1. 基本と全体像

この記事の要点と4つの章のご案内

概要と背景:淀川の舟運とインターネットの「渋滞しない流し方」に関するイメージ写真
概要と背景:淀川の舟運とインターネットの「渋滞しない流し方」
具体的な対策・手順:会社の業務や窓口の「行列・渋滞」をなくす3つの知恵に関するイメージ写真
具体的な対策・手順:会社の業務や窓口の「行列・渋滞」をなくす3つの知恵
淀川三十石船と高槻藩の宿場物流を「待ち行列理論(M/M/1)」と 現代のインターネット輻輳制御(TCP BBR)で読み解く歴史数理紀行 の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 概要と背景:淀川の舟運とインターネットの「渋滞しない流し方」 【身近なたとえ話:高速道路のサービスエリアに全員が入ると大渋滞するけれど、走りながら給油できれば止まらない】
2. 現場での進め方と対策 具体的な対策・手順:会社の業務や窓口の「行列・渋滞」をなくす3つの知恵 江戸時代、京都(伏見)と大坂(天満橋・八軒家浜)を結ぶ最大の物流ルートは、高槻市の南端をゆったりと流れる「淀川(よどがわ)」の舟運でした。もし28人の乗客を乗せた大型の「三十石船」が、お腹が空くたびに途中の船着場へ接岸して全員が降りて食事をしていたら、船着場に船の順番待ち(行列)ができてしまい、大坂に着くまでに何時間も余計にかかってしまいます。そこで高槻(柱本・唐崎・三島江)や対岸の枚方周辺で生まれたのが、航行中の三十石船に小舟をピタッと横付けし、船を止めないまま温かい汁物や餅を渡す「くらわんか舟」でした。これは現代のインターネットにおいて、ルーターの待ち行列(バッファ)でパケットを止めずに一定の速度で流し続ける最新アルゴリズム(TCP BBR)と驚くほど同じ発想なのです。
3. 関連する制度とルール 実務確認 場面別の実務確認ポイント 高槻藩(永井家3万6千石)にとって、淀川に面した唐崎浜や三島江浜は、城下町や北摂の山間部で作られた米・酒・寒天を大坂・江戸へと送り出す極めて重要な「水運ゲートウェイ(河港)」でした。
4. 詳しい技術仕様としくみ 江戸時代に高槻の南を流れる淀川を行き交った「三十石船(さんじっこくぶね)」と「くらわんか舟」とは何ですか? 1961年にジョン・リトルが証明した「L = λ W」という美しい公式は、江戸時代の船着場から現代のスーパーのレジ、病院の待合室、クラウドサーバーの通信制御まで、あらゆる行列に100%当てはまります。
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
この記事のポイント 歴史物流×待ち行列理論×インターネット工学
  • 01 江戸時代の淀川は「大容量バックボーン回線」だった:陸路(西国街道)の飛脚が低遅延の制御パケットなら、1隻に米30石・乗客28人を乗せる「淀川三十石船」は大容量データ通信そのものでした。
  • 02 利用率80%を超えると行列は爆発する(M/M/1の法則):船着場もお店のレジも通信ルーターも、稼働率(ρ)が80〜90%を超えると待ち時間が急激に跳ね上がるため、「2割の余白」が最速を生みます。
  • 03 高槻名物「くらわんか舟」は現代のゼロ停止通信(TCP BBR):親船を港に停めず、航行中に小舟を横付けして食事を届けた知恵は、バッファ渋滞を作らず等間隔でパケットを流す最新通信技術と同じ構造です。

1. 概要と背景:淀川の舟運とインターネットの「渋滞しない流し方」

Yodo River Logistics & Queueing Theory

【身近なたとえ話:高速道路のサービスエリアに全員が入ると大渋滞するけれど、走りながら給油できれば止まらない】

江戸時代、京都(伏見)と大坂(天満橋・八軒家浜)を結ぶ最大の物流ルートは、高槻市の南端をゆったりと流れる「淀川(よどがわ)」の舟運でした。もし28人の乗客を乗せた大型の「三十石船」が、お腹が空くたびに途中の船着場へ接岸して全員が降りて食事をしていたら、船着場に船の順番待ち(行列)ができてしまい、大坂に着くまでに何時間も余計にかかってしまいます。そこで高槻(柱本・唐崎・三島江)や対岸の枚方周辺で生まれたのが、航行中の三十石船に小舟をピタッと横付けし、船を止めないまま温かい汁物や餅を渡す「くらわんか舟」でした。これは現代のインターネットにおいて、ルーターの待ち行列(バッファ)でパケットを止めずに一定の速度で流し続ける最新アルゴリズム(TCP BBR)と驚くほど同じ発想なのです。

ポイント 01 / 高槻藩と「唐崎浜・三島江浜」

年貢米や寒天を積み出した北摂の物流ハブ

高槻藩(永井家3万6千石)にとって、淀川に面した唐崎浜や三島江浜は、城下町や北摂の山間部で作られた米・酒・寒天を大坂・江戸へと送り出す極めて重要な「水運ゲートウェイ(河港)」でした。

ポイント 02 / 待ち行列理論「リトルの法則」

平均待ち人数 L = 到着率 λ × 滞在時間 W

1961年にジョン・リトルが証明した「L = λ W」という美しい公式は、江戸時代の船着場から現代のスーパーのレジ、病院の待合室、クラウドサーバーの通信制御まで、あらゆる行列に100%当てはまります。

ポイント 03 / 利用率80%の壁(非線形カーブ)

稼働率90%になると待ち時間は「9倍」に跳ね上がる

窓口の混み具合(利用率 ρ)が50%のとき待ち時間は処理時間の1倍ですが、利用率80%で4倍、利用率90%で9倍、利用率95%で19倍へと急増します。「余白を残すこと」が渋滞を防ぐ唯一の数学的解です。

01 淀川水運と高槻河港の「ハイブリッド通信網」 陸路:西国街道・芥川宿(継飛脚 = 低遅延制御パケット) 小さな書状(数キロ)を最速でリレー中継する高速コントロール回線 水路:淀川三十石船・高槻唐崎浜(= 大容量高帯域ストリーム) ・下り(伏見→高槻→大坂):水流に乗って約半日(高スループット) ・上り(大坂→高槻→伏見):岸から綱で引く「曳舟」で約1日(非対称帯域) ・くらわんか舟:本船を港に停めずに並走して補給(Zero-Stop Pacing) 現代のインターネットとの共通点: 下り回線(ダウンロード)が速く上り回線に力が要る非対称通信そのもの! 02 待ち行列理論(M/M/1):利用率80%の壁 窓口・回線の利用率 ρ (0% → 50% → 80% → 95%) 待ち 時間 利用率 80% の分岐点 快適ゾーン(ρ ≤ 75%) 余白があるため行列がすぐ消える 式:待ち時間 W_q = ρ / (μ(1 - ρ)) → ρが1に近づくと無限大へ発散

01. 江戸時代の淀川は「下りは高速、上りは綱引き」の非対称ブロードバンドだった

京都・伏見から高槻の南を通り、大坂・天満橋の八軒家浜までの約40キロメートルを結んだ「淀川三十石船」は、興味深い物理的特徴を持っていました。京都から大坂へ向かう「下り船」は、川の流れに乗って所要時間わずか約6時間(夜船なら一晩)で快走できたのに対し、大坂から京都へ川を遡る「上り船」は、川岸の堤防を歩く「綱曳き人足(つなひきにんそく)」たちが何人もで長い綱を引っ張って歩くため、約12時間(丸1日)を要しました。

情報ネットワーク工学の目で見ると、これは現代の家庭向けインターネット回線やモバイル通信において「下り(ダウンロード)の帯域幅は太くて速いけれど、上り(アップロード)には大きなエネルギーと時間がかかる非対称リンク(Asymmetric Link)」とまったく同じ構造です。そのため、高槻の唐崎浜や三島江浜などの船着場では、上り船と下り船、そして綱を引く人足たちが絡み合って渋滞(デッドロック)を起こさないよう、巧妙な進路分けとペーシング(間隔制御)が行われていました。

02. なぜ「詰め込みすぎないこと(TCP BBR)」が一番速く届くのか?

かつての古いインターネット通信(従来のTCP輻輳制御)は、「途中のルーターの待合室(バッファ)が満杯になってパケットが溢れるまで、とにかく全力でデータを詰め込む」という走り方をしていました。しかし待合室を100%満杯にしてしまうと、後から来た緊急のパケットが長い行列の後ろに並ばされ、画面の反応がひどく遅くなってしまいます(これをバッファブロート=待合室の膨張問題と呼びます)。

これに対して現代の最新通信アルゴリズム「TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)」は、まさに淀川の「くらわんか舟」のように、「一番狭い水路の幅(ボトルネック帯域)を測り、船着場に行列を作らないギリギリの等間隔ペースで船を送り出す」という制御を行います。その結果、待合室の行列はほぼゼロになり、最小の待ち時間で最大の荷物を運べるようになったのです。

2. 具体的な対策・手順:会社の業務や窓口の「行列・渋滞」をなくす3つの知恵

Queueing Optimization in Business

現場で陥りやすい落とし穴と回避策

待ち行列理論(M/M/1・M/M/c)を使うと、日々のオフィス業務やクリニック・店舗の受付が驚くほどスムーズになります。

現場の課題 現場で陥りやすい落とし穴(NG例) 待ち行列理論に基づく改善策(推奨策)
社員のスケジュール管理 「稼働率100%が効率的だ」と考え、社員の1日の予定を隙間なく会議と定型作業で埋め尽くしてしまう。 稼働率 ρ が80%を超えると突発対応の待ち時間が4倍以上に跳ね上がるため、定型業務をAIで自動化し、常に25%の「余白時間」を確保する。
受付窓口の並び方 3つの窓口それぞれに別々の列を作らせ、たまたま時間のかかる手続きの後ろに並んだ人がずっと待たされる。 銀行や空港のように「列は1本にまとめ、空いた窓口から順番に案内する(フォーク並び:M/M/cモデル)」だけで平均待ち時間が大幅に短縮される。
決裁・承認のボトルネック 数百円の備品購入から重要な契約まで、すべて同じ1人の責任者のハンコ待ち行列(単一サーバー)に並ばせる。 くらわんか舟のように「定型・少額の案件はルールに基づいてノンストップで通過」させ、本当に重要な判断だけに人の時間を集中させる。

仕事の渋滞をなくす「淀川水運×待ち行列 3項目チェックリスト」

達成状況:0 / 3 項目

あなたの職場やご自身の働き方に「渋滞を防ぐ仕組み」が入っているかチェックしてみましょう。

まずは「月末にまとめてやっている作業を、日々の自動処理に変えられないか」という視点から点検してみてください。

理解を深める確認クイズと関連コラム・豆知識

【確認クイズ】待ち行列理論(M/M/1モデル)において、窓口やサーバーの利用率(混み具合 ρ)が「50%」から「90%」に増えたとき、順番を待つ平均時間は何倍になるでしょうか?

選択肢 A:混み具合が約1.8倍になったので、待ち時間も約1.8倍になる クリックして判定 →

直感的には約2倍くらいに思えますが、実は到着のばらつきが重なって解消できなくなるため、比例以上の急激な増加が起きます。選択肢Bを開いてみてください!

選択肢 B:なんと「9倍」に跳ね上がる(ρ / (1 - ρ) の法則) クリックして判定 →

大正解です! 平均待ち時間は ρ / (1 - ρ) に比例するため、利用率50%(0.5 / 0.5 = 1)に対して、利用率90%では(0.9 / 0.1 = 9)となり、待ち時間が一気に9倍に膨れ上がります。だからこそ「心に2割の余白を持つこと」が数学的にも極めて合理的なのです。

選択肢 C:待ち時間はまったく変わらない クリックして判定 →

空き時間が10%しかなくなると、少しの遅れが次の人へと連鎖して大渋滞になります。正解は選択肢Bの「9倍」です!

関連コラム・豆知識:Why Bowl Tally Worked Like Token Bucket

「くらわんか舟のお椀の枚数勘定と、小銭を海に落とさない決済の工夫」
揺れる淀川の船の上で、くらわんか舟の商人たちはどうやって素早くお会計をしていたのでしょうか。実は、食べた後に重ねた「お椀の数と種類」だけで一瞬で金額を計算する『ストリーム集計』を行っていました。船がすれ違うわずかな時間(短い通信ウィンドウ)の中で、商品の受け渡しと決済を完了させるための見事な現場オペレーションだったのです。

高槻の歴史工学シリーズ&業務の渋滞をなくすAI自動化相談

安満遺跡・西国街道の歴史工学記事や、社内の待ち時間をゼロにする業務改善支援もぜひご覧ください。

実務確認 場面別の実務確認ポイント

歴史好き・高槻・北摂の市民の方へ

十返舎一九の『東海道中膝栗毛』や歌川広重の浮世絵にも描かれた高槻・枚方周辺の淀川舟運の賑わいを、現代の科学の視点から楽しく味わえます。

経営者・物流・店舗マネージャーの方へ

倉庫や窓口、社内の業務フローで「なぜ予定を100%埋めるとかえって納期遅れが起きるのか」を、リトルの法則(L = λ W)を使って具体的に解説します。

ネットワーク・バックエンド技術者の方へ

ErlangのM/M/1・M/M/c待ち行列モデル、Bufferbloat問題、および帯域遅延積(BDP)に基づくTCP BBRペーシング制御器のRust 2024実装を収録しています。

技術仕様・実装解説(ERLANG M/M/C QUEUEING THEORY & TCP BBR PACING) 第3章: 技術仕様・実装解説(ネットワーク工学・数理モデルの詳しい解説)
設計背景・判断基準リファレンス

リトルの法則(L = λ W)、淀川河港・関所モデルの Erlang M/M/c 待ち行列解析、および帯域遅延積(BDP)に基づく TCP BBR ペーシング制御器

本モノグラフでは、近世淀川水運における河港荷役・関所通過プロセスと現代のインターネット輻輳制御(Congestion Control)の同型性を確率過程論により定式化する。(1) ポアソン到着率 λ・指数サービス率 μ における生滅過程(Birth-Death Process)の定常分布とリトルの定理 L = λ W、(2) 複数船着場(c 窓口)を持つ M/M/c モデルの Erlang C 式、および (3) Kleinrock の最適動作点(Bandwidth-Delay Product: BDP = B_tlBw × RT_prop)を維持してキュー遅延を最小化する TCP BBR ペーシングコントローラを Rust 2024 で実装する。

Stochastic Model
Kendall M/M/1 & M/M/c Markov Chain
Conservation Law
Little's Theorem L = λ W
Congestion Control
IETF TCP BBRv2 / BBRv3 Operating Point
In-Flight Target
cwnd = γ_cwnd · B_tlBw · RT_prop
1. 設計仕様・数理モデル(Formal Architecture, Markovian Queueing & Kleinrock's BDP Operating Point)

01. M/M/1 生滅過程の定常状態確率と Pollaczek-Khinchine / Little の法則: 高槻・唐崎浜のような河港またはネットワークルーターの出力ポートへ、単位時間あたり平均 λ 隻(パケット/秒)のポアソン過程で到着し、単一サーバーが平均サービス率 μ(ρ = λ / μ < 1)の指数分布で処理する M/M/1 系を考える。系内状態数 n の定常確率は P_n = (1 - ρ)ρ^n となり、系内平均滞留数 L、待ち行列長 L_q、および平均待ち時間 W_q は次式で与えられる。

L = ∑_n=0^∞ n(1-ρ)ρ^n = (ρ)/(1 - ρ), L_q = (ρ^2)/(1 - ρ), W_q = (L_q)/(λ) = (ρ)/(μ(1 - ρ))

ここで (∂ W_q)/(∂ ρ) = (1)/(μ(1-ρ)^2) であるから、利用率 ρ → 1 の極限で遅延感度 (1-ρ)^-2 は二次関数的に発散する。これが Loss-Based TCP(CUBIC / Reno)においてルーターバッファを満杯にするまでウィンドウを拡大させた際に発生する Bufferbloat(数秒単位のキューイング遅延)の数理的本態である。

02. TCP BBR と Kleinrock の最適動作点(Bandwidth-Delay Product): 水路(通信経路)のボトルネック帯域を B_tlBw、無負荷時の往復伝搬遅延を RT_prop とすると、パイプラインをちょうど100%満たし、かつ船着場(ルーターキュー)に1隻の待ち行列も作らない最適飛翔データ量(In-Flight Data)は帯域遅延積 BDP = B_tlBw × RT_prop で与えられる。TCP BBR は過去の時間窓における最大送達速度 B_tlBw と最小往復遅延 RT_prop を独立に推定し、パケット送出間隔 Δ t_pace を次式で直接ペーシング制御する。

BDP = B_tlBw · RT_prop, Δ t_pace = (PacketSize) / (γ_pace · B_tlBw)
2. パラメータ・構成仕様(Historical Yodo River Water Transport vs. Modern TCP/IP Control Matrix)
System Dimension Edo Yodo River Logistics Queueing / TCP Equivalent Mathematical Invariant
High-Throughput Frame 三十石船 (4.5 Metric Tons / 28 Pax) Jumbo Frame / Bulk Data Stream High Payload-to-Header Efficiency
In-Flight Edge Cache くらわんか舟 (In-Transit Provisioning) Zero-Queue Pacing / Edge CDN Eliminates Dock Queueing Delay W_q → 0
Asymmetric Link Capacity Downstream (6h) vs Upstream Tow (12h) Asymmetric Downlink / Uplink BDP ACK Clocking & Rate Pacing Required
Port Utilization Cap 唐崎浜・三島江浜 Multi-Berth Dock Erlang M/M/c Load Balancer Keep ρ = λ / (cμ) ≤ 0.75
3. 実装コード・設定仕様(Executable Specification Code (crates/ok-net-pacing/src/bbr_mm1_controller.rs)) Rust 2024(M/M/1 Queueing Analyzer & TCP BBR Pacing Controller)
#![forbid(unsafe_code)]

/// Steady-state metrics for an M/M/1 queueing system under Little's Law (L = lambda * W).
#[derive(Debug, Clone, Copy, PartialEq)]
pub struct Mm1Metrics {
    pub utilization_rho: f64,
    pub mean_queue_length_lq: f64,
    pub mean_wait_time_wq_sec: f64,
    pub mean_system_time_w_sec: f64,
}

/// Computes exact steady-state M/M/1 metrics given arrival rate lambda and service rate mu.
/// Returns None if the system is unstable (lambda >= mu).
pub fn analyze_mm1_queue(arrival_rate_lambda: f64, service_rate_mu: f64) -> Option<Mm1Metrics> {
    if arrival_rate_lambda < 0.0 || service_rate_mu <= 0.0 || arrival_rate_lambda >= service_rate_mu {
        return None;
    }
    let rho = arrival_rate_lambda / service_rate_mu;
    let lq = (rho * rho) / (1.0 - rho);
    let wq = rho / (service_rate_mu * (1.0 - rho));
    let w = 1.0 / (service_rate_mu - arrival_rate_lambda);

    Some(Mm1Metrics {
        utilization_rho: rho,
        mean_queue_length_lq: lq,
        mean_wait_time_wq_sec: wq,
        mean_system_time_w_sec: w,
    })
}

/// BBR-inspired Bandwidth-Delay Product (BDP) pacing state machine.
#[derive(Debug, Clone, Copy)]
pub struct BbrPacingController {
    pub max_bw_bytes_per_sec: f64,
    pub min_rtt_sec: f64,
    pub pacing_gain: f64,
    pub cwnd_gain: f64,
}

#[derive(Debug, Clone, Copy)]
pub struct PacingSchedule {
    pub target_inflight_bdp_bytes: usize,
    pub target_cwnd_bytes: usize,
    pub inter_packet_interval_nanos: u64,
}

impl BbrPacingController {
    /// Updates bottleneck bandwidth and minimum RTT estimates from a delivery sample.
    #[inline]
    pub fn update_telemetry(&mut self, delivered_bytes: usize, interval_sec: f64, rtt_sec: f64) {
        if interval_sec > 1e-6 {
            let sample_bw = (delivered_bytes as f64) / interval_sec;
            if sample_bw > self.max_bw_bytes_per_sec {
                self.max_bw_bytes_per_sec = sample_bw;
            }
        }
        if rtt_sec > 1e-6 && (self.min_rtt_sec <= 0.0 || rtt_sec < self.min_rtt_sec) {
            self.min_rtt_sec = rtt_sec;
        }
    }

    /// Computes Kleinrock's optimal BDP congestion window and inter-packet pacing interval.
    pub fn compute_pacing_schedule(&self, mss_bytes: usize) -> PacingSchedule {
        let bdp = self.max_bw_bytes_per_sec * self.min_rtt_sec;
        let cwnd = (bdp * self.cwnd_gain).ceil() as usize;
        let effective_rate = (self.max_bw_bytes_per_sec * self.pacing_gain).max(1.0);
        let interval_sec = (mss_bytes as f64) / effective_rate;
        let nanos = (interval_sec * 1e9).round() as u64;

        PacingSchedule {
            target_inflight_bdp_bytes: bdp.ceil() as usize,
            target_cwnd_bytes: cwnd.max(4 * mss_bytes),
            inter_packet_interval_nanos: nanos.max(100),
        }
    }
}
Network & Operations Research Note: 当社のサーバー基盤および業務自動化設計は、すべて待ち行列理論と非ブロッキングI/Oに基づき、渋滞と待ち時間を極小化するよう設計されています。
システム設計・業務改善のお問い合わせ
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます