# 砂時計モデル ## 定義 砂時計モデル(hourglass model)とは、インターネットのプロトコルスタックを、IPという極めて狭いくびれと、その上下に広がる多様なアプリケーション(裾野上部)・リンク技術(裾野下部)として描く設計モデルである。くびれは「あらゆる通信チャネルを利用可能にするグローバルなアドレッシングとルーティングの方式を規定する」という最小限の合意事項だけに絞り込まれており、信頼性のある配送・セキュリティ・モビリティ・QoSといった他の要件はすべて上位層またはリンク層固有の技術に先送りされる。この構図の起源は1994年に米国学術研究会議が発行した報告書 *Realizing the Information Future*(RTIF)にあり、David ClarkはBruce Davieへの取材で「(それ以前から考え方自体はあったとしても)初出はおそらく1994年のRTIFだろう」と述べている。1990年代後半、Steve Deeringの講演 "Watching the Waist of the Protocol Hourglass" によって図として広く知られるようになった(図2.1)。Larry Peterson・Bruce Davieが1995年に上梓した教科書 *Computer Networks: A Systems Approach* もこのモデルをインターネットアーキテクチャの重要な側面として取り上げていたが、RTIF・Deeringの講演ほど整然とした図示はしていなかったとされる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]] §2.2) 砂時計モデルで本質的に重要なのは、くびれの狭さそのものではなく、上部と下部の裾野の広さである。この広さこそが、インターネットのアーキテクチャにおける柔軟性の余地を表現している。競合するモデルと比較すると特徴が際立つ。ATM(非同期転送モード)はSONETなど特定のリンク技術を前提とし、スタック下部の選択肢が固定された「漏斗」型であり、ケーブルTVネットワークはスタック上部のアプリケーションがほぼ映像配信に限定された、砂時計とは逆の狭まり方をしていた。RTIFはこの3者(インターネット・ATM・ケーブルTV)を比較し、上部または下部のどちらかを少数の選択肢に狭めることの弊害を明確に指摘した。IPがリンク層のあらゆる技術革新(Ethernet、Wi-Fi、各世代の移動体通信網)を受け入れ続けられたのは、砂時計の下部を狭めなかったためであり、逆にATMは「既存ネットワークを活用する」明確なデプロイメントの道筋を欠いていた。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]] §2.2) 砂時計モデルはそれ自体が「アーキテクチャ」ではなく、より一般的に適用できる「アーキテクチャ上の原則」として位置づけられる点に注意が必要である。ルネ・マグリットの絵画「これはパイプではない」になぞらえて説明されるとおり、モデル(表現)と実装(実体)は区別されるべきものであり、砂時計モデルはインターネットに限らず、広く普及することを想定したあらゆるシステムに適用しうる設計原則だとされる。この原則の核にあるのが**遅延バインディング(late binding)**の考え方であり、複雑な意思決定や機能の実装を設計プロセスの後半まで意図的に遅らせることで、最小かつ論争の少ない合意事項からくびれを構成し、他者による革新の余地を残す。TCPは、この砂時計のくびれには含めずにリファレンス実装の一部として組み込まれた典型例であり、その後セキュリティ(TLS)・モビリティ(DHCP、HTTPリダイレクト)・オブジェクト識別子(URI)などが上位のプラットフォームとして時間をかけて積み上がった。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]] §2.3) ## 横断的知見 - **第8章は、砂時計のくびれにセキュリティ機能を含めなかった決定を「見落とし」ではなく「遅延バインディング」の一例として積極的に再評価し、第2章が示した遅延バインディングの一般原則(複雑な意思決定を設計プロセスの後半へ意図的に遅らせること)にセキュリティという具体的な適用事例を与える**: 第2章は遅延バインディングを砂時計モデルの核にある考え方として定義したが、その適用例としてはTCP・TLS・DHCP・URIといった機能一般を挙げるにとどまっていた。第8章§8.4はこの一般原則を名指しで引用し、「セキュリティ機能をいっさい備えていないネットワークアーキテクチャを構築するという当時の決定は遅延バインディングの一例である」というLarry Petersonの指摘をBruce Davieが紹介する形で、セキュリティという具体的かつ議論の的になりやすい機能に原則を当てはめている。ただし同時に、Vint CerfとDavid D. Clarkの証言(セキュリティは「見逃されていた」のではなく「信頼できない人々を排除できると想定していた」)を引き、遅延バインディングという設計上の美徳と、当初の前提(少数の信頼し合う研究者間の接続)が崩れたことによる後付けの正当化との線引きが実際には曖昧であることも示している。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]] §2.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 8 セキュリティ：負の目標]] §8.4) - **第8章は「くびれの外に先送りされた機能がその後どう発展したか」の系譜を示すことで、第2章の未解決の問いに部分的な答えを与える**: 第2章はTCP・TLS・DHCP・HTTPリダイレクト・URIをくびれの外で積み上がった機能の例として列挙するのみだったが、第8章§8.4はセキュリティに焦点を絞り、モリスワームによってエンドシステムのセキュリティだけに依存することの限界が露呈し、その後ファイアウォールという「点」の対策、さらにSDN・ネットワーク仮想化によるマイクロセグメンテーション・ゼロトラストへと発展していった経緯を描く。すなわち、くびれの外に置かれた要件は「そのまま放置される」のではなく、「エンドシステムでの局所対応 → 境界での点対応 → 分散アーキテクチャでの統合対応」という段階を経て徐々に洗練されていくパターンを持つことが、セキュリティという一事例を通じて示される。この段階的発展のパターンが他の先送りされた機能(モビリティ・QoSなど)にも一般化できるかは未検証。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 8 セキュリティ：負の目標]] §8.3, §8.4) - **第6版第1章 §1.3.5 は、砂時計モデルの起源(RTIFの報告書・Deeringの講演)を論じるLambdaNote版第2章とは異なり、「なぜIPが狭いくびれになったのか」という設計判断の中身そのものを、教科書自身の一次資料として与える**: LambdaNote版第2章は歴史的経緯(誰がいつこのモデルを提唱・図示したか)に力点を置くのに対し、当の教科書 *Computer Networks: A Systems Approach* 自体が持つ設計原理としての説明は第1章§1.3.5に置かれている。ここでIPが「アーキテクチャの焦点」とされる理由は、IPの上に任意の数のトランスポートプロトコルが、IPの下に任意の数のネットワーク技術が存在でき、「ホスト間のメッセージ配送という課題」と「プロセス間通信サービスの提供という課題」が完全に分離される、という構造上の分離にある。この分離こそが、狭いくびれが「最小限かつ論争の少ない合意事項」で足りる理由を与える——配送(IP)とサービス(TCP/UDPより上)という異なる関心事を1つのプロトコルに背負わせなければ、くびれに含める機能を最小化できるからである。LambdaNote版第2章はこの「なぜ最小化できたのか」という設計判断の内的論理には立ち入らず、RTIF・Deeringという外的な歴史の系譜を語るにとどまる。両者を合わせると、砂時計モデルには「誰がいつ提唱し可視化したか」という歴史的経緯と、「なぜIPをくびれに選ぶことが機能したか」という設計原理という、2つの異なる説明のレイヤーがあることが分かる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 1 Foundation]] §1.3.5, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]] §2.2) - **第5章のPerspective節「HTTP is the New Narrow Waist」は、第2章§2.3が示した『遅延バインディングの結果、くびれの外側にTCP・TLS・DHCP・URIが積み上がった』という一般論の先に何が起きるかを示す——積み上がった機能群が並存し続けるのではなく、それ自体が新しいくびれへ再収束する**: 第2章はTCP・TLS・DHCP・HTTPリダイレクト・URIをくびれの外で積み上がった機能の例として列挙するにとどめていた(既存の横断的知見)。これに対し本書第6版第5章のPerspective節は、これらの機能のうちHTTP・TLS・TCP・IPの4層が「チーム」として一体化し、IPに代わってHTTPが「あらゆる合意が収束する不動点」の役割を引き継ぎつつあると論じる。HTTPはグローバルなオブジェクト識別子(URI)とGET/PUTインターフェースを、TLSはエンドツーエンドセキュリティを、TCPは接続管理と輻輳制御を、IPはグローバルアドレッシングを、それぞれ分担する。すなわち、くびれの外に先送りされた機能は無限に多様化していくのではなく、ある時点で新たな共通基盤へ結晶化しうるという、砂時計モデルの動的な性質(くびれ自体が移動しうること)を第5章は具体例で示す。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] Perspective, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]] §2.3) - **第5章の問題設定(Problem: Getting Processes to Communicate)は、第1章§1.3.5がIPを狭いくびれに選べた理由として挙げる『ホスト間配送とプロセス間通信サービスの分離』を、まさにその「プロセス間通信サービス」側で具体的に実装する章である**: 第1章§1.3.5は、IPの上に任意のトランスポートプロトコルが載り、IPの下に任意のネットワーク技術が載るという構造上の分離ゆえにIPのくびれを最小化できたと説明していた(既存の横断的知見)。第5章は「ホスト間のパケット配送サービスをプロセス間の通信サービスへ変換する」ことをそのまま章の問題設定に据え、UDP・TCP・RPC・RTPという4つの異なる答えを提示する。すなわち第5章は、第1章が語ったIPくびれの設計原理のうち「配送より上のプロセス間通信サービスをどう提供するか」という側だけを、丸ごと1章かけて具体化した部分である。両者を合わせると、砂時計モデルの狭いくびれ(IP)を最小に保てた理由は、その直上の層(トランスポート)が多様な答えを許容できる設計になっていたことと表裏一体であることが分かる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] Problem, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 1 Foundation]] §1.3.5) - **第9章はアプリケーション層の内部から見て、HTTPがくびれの外側に積み上がった多様なアプリケーションプロトコルの共通基盤へとどう収束していったかを具体的に跡づけ、第5章が示した『HTTPが新しいくびれになりつつある』という主張を、gRPCという直近の事例で裏付ける**: 第5章のPerspective節は、TCP・TLS・IP・HTTPの4層が一体化し、HTTPがIPに代わる新しい合意の収束点になりつつあると論じたが、そこで扱われるのはトランスポート層寄りの議論(HTTP/2・HTTP/3・QUIC)にとどまっていた(既存の横断的知見)。第9章§9.1は、この収束がアプリケーション層側でどう進んだかを示す。まず、SMTP・HTTPのような伝統的アプリケーションプロトコルは、RPCトランスポートの上に構築されるのではなく、TCPの上に「簡易なRPC類似の機構」を個別に再発明する形で実装されてきた。次に、Web Servicesの2つの流儀——WSDL/SOAP(プロトコルごとにカスタムのトランスポートを設計する)とREST(HTTPそのものをアプリケーションプロトコルとして再利用する)——のうち、著者らはRESTの側が「安定性と実証済みのスケーラビリティ」という利点を持つとし、実際Amazonの開発者の大半がSOAP APIではなくREST APIを選んだという実例を挙げる。最後に、マイクロサービス時代のREST+JSON対gRPC+Protobufsという係争においてすら、「両者ともHTTPの上で動く」ことが明記される。すなわち第9章は、くびれの外側で個別に発明されていたアプリケーションプロトコルの系譜(SMTP・HTTP・SOAP・REST・gRPC)が、時代を追うごとにHTTPという単一の共通基盤へ収束していく過程そのものを描いており、第5章の「HTTPが新しいくびれになりつつある」という主張を、トランスポート層の外側であるアプリケーション層からも裏付ける。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.1.1, §9.1.2, §9.1.3, [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] Perspective) ## 未解決の問い - 第1章§1.3.5が示す「配送とサービスの分離」という設計原理は、なぜこの分離点が具体的にIPという1プロトコルに宿ったのか(TCP/UDPのような上位プロトコルではなくIPが選ばれた理由)までは説明しない。この設計判断の経緯は、RTIF報告書やDeeringの講演といった歴史的資料に別途あたる必要がある。 - 砂時計のくびれ(IPの最小限機能)に何を含め何を含めないかの判断基準は、本章では「最小かつ論争が最も少ない事柄から始める」という定性的な指針しか示されていない。→ 第8章はセキュリティに関して「遅延バインディングとして事後的に正当化できる」という視点を示したが、これは事前の判断基準ではなく事後の解釈であり、次にくびれへの再統合を迫られる機能が生じた際にどう判断すべきかの一般的な基準はなお示されていない。 - くびれの外で段階的に発展した機能(エンドシステム対応 → 点対応 → 分散アーキテクチャ対応)というパターンがセキュリティ以外(モビリティ・QoS・信頼性)にも当てはまるかは、第8章単体では検証できない。他章(特に9章5G、11章ネットワーク管理)の ingest で確認する必要がある。 - 砂時計モデルは「ある時点でのインターネットの姿を切り取ったスナップショットにすぎない」という批判が本章内で紹介されている(§2.1)。モデルが進化を経ても有効であり続けるための条件、あるいはモデル自体が更新を要するタイミングをどう判定するかは、本章では明示的に答えられていない。 - ATM・ケーブルTVという2つの「敗れたモデル」との比較は本章で詳細に論じられるが、砂時計型ではない設計が特定の文脈(例えばモバイルネットワークの世代交代でアーキテクチャと技術が結合してしまう問題、9章で扱われる5G)でなお採用され続ける理由は何か。 - 第9章の ingest により、gRPCがHTTPを代替するのではなくHTTPの上に積み上がることは確認できた(横断的知見を参照)。しかし、くびれが再びHTTPから別の層へ移動するとすれば、それはどのような条件で起きるかという問い自体は依然として未解決である——第9章はHTTPへの収束を描くのみで、収束の先にさらなる移動が起きる可能性(あるいは起きない理由)には触れていない。 ## 関連 - ソース: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]](§2.2, §2.3) / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 8 セキュリティ：負の目標]](§8.3, §8.4) / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 1 Foundation]](§1.3.5、原著教科書における砂時計モデルの設計原理としての説明) / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]](Perspective、HTTPが新しいくびれになりつつあるという本書で最も重要な現代的主張) / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]](§9.1、アプリケーション層側からHTTPへの収束を跡づける) - 概念: [[ネットワークアーキテクチャ]](砂時計モデルはその具体例・原則の一つ) / [[ネットワークセキュリティアーキテクチャ]](くびれの外に置かれたセキュリティが辿った発展) / [[トランスポートプロトコル設計]](くびれの直上でUDP・TCP・RPC・RTPが多様な答えを提供する層) - 実体: [[Steve Deering]](講演で図を広めた人物) / [[David D. Clark]](RTIFの起源を証言。第8章では初期インターネットのセキュリティ前提についても証言) / [[Vint Cerf]] / [[Bruce Davie]] / [[Larry Peterson]] ## 出典 - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第2章 §2.2, §2.3, 第8章 §8.3, §8.4. - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 1: Foundation, §1.3.5. https://book.systemsapproach.org/foundation.html - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 5: End-to-End Protocols, Perspective: HTTP is the New Narrow Waist. https://book.systemsapproach.org/e2e.html - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.1 Traditional Applications. https://book.systemsapproach.org/applications.html