ネットの裏側：Cookie・DNS・動画・文章づくり

ふだん使っているネットには、目に見えない決まりごとがたくさんあります。ここでは、Cookie（クッキー）、DNS、動画の配信、そして文章をつくるしくみの4つを取り上げます。 このサイトの4つの作品は、どれも「教育用の簡略化モデル」です。実際のしくみはもっと複雑で、画面の数値や規則は説明のために決めた仮のものです。

Cookie：ブラウザに預けるメモ

Webサイトは、1回ごとの通信を、基本的には覚えていません。そこで、サイトが「このメモを持っていてね」と頼み、ブラウザがそれを預かって、次に同じサイトへ行くときに見せる、という方法が使われます。このメモが Cookie です。 サーバーが「名前=値」の形で渡し（Set-Cookie）、ブラウザが次から送り返す（Cookie）、というのが基本の流れです。

Cookie は1994年に考案されたとされています。ネットショップの買い物かごを覚えておく問題が、きっかけの一つと説明されています。考えたのはルー・モンテュリたち、とされています。名前は、昔のUnixの「マジッククッキー」という言葉に由来するといわれます。 現在の仕様は RFC 6265（2011年4月）です。その改訂版の案が、IETFで最終段階にありますが、まだ RFC にはなっていません（2026年10月時点の確認）。

Cookie には、送る条件を決める「属性」があります。

• 期限（Expires、Max-Age）：どちらも無ければ、ブラウザを閉じると消える「セッション Cookie」。両方あれば Max-Age が優先されます。
• Domain：省略すると、そのホストにだけ送ります。指定すると、その下のサブドメインにも送ります。
• Path：そのパスと、その下のページにだけ送ります。
• Secure：安全な通信（HTTPS）のときだけ送ります。
• HttpOnly：ページのスクリプトからは見えないようにします（サーバーとのやりとりには付きます）。
• SameSite：別のサイトから来たリクエストに付けるかどうかを決めます。Strict は同じサイトだけ、Lax はそれに加えてリンクを踏んで移動したとき、None は別サイトにも送ります（None には Secure が必要です）。指定が無いときは Lax として扱う、というのが現在の考え方です。

別のサイトが設定する「サードパーティ Cookie」は、広告や埋め込み部品に使われ、サイトをまたいで同じブラウザを見分けることもできます。 扱いはブラウザごとに違い、日付つきで見ると、2020年3月に既定でブロックを始めたもの、2022年6月にサイトごとに別々の保管場所に分け始めたもの、2025年4月に廃止の計画を取りやめると発表したもの、があります。この分野は変化が速いので、最新の状況はそれぞれのブラウザの案内で確かめてください。

DNS：名前から住所へ

「example.com」のような名前から、通信に使う数字の住所（IPアドレス）を調べるしくみが DNS です。基本の仕様は、1987年11月の RFC 1034（と、対になる RFC 1035）で、ポール・モカペトリスが書いたとされています。「電話帳」にたとえられることがよくあります。

名前は木のような構造になっていて、右から左へ詳しくなります。たとえば www.example.com は、いちばん上の「根（ルート）」、その下の「.com」、その下の「example.com」と降りていきます。 手元のリゾルバー（調べてくれる係）は、典型的にはまずルートに聞いて「.com の案内先」をもらい、次にそこへ聞いて「example.com を管理する所」の案内をもらい、最後にそこから答えの住所を受け取ります。 ただし「いつも3回」ではありません。一度調べた案内は覚えておく（キャッシュ）ので、2回目以降はルートまで行かないことが多いのです。

覚えておく長さは、TTL（秒で表す）で決まっています。RFC 1034 は、TTL を「キャッシュが捨てるまで持っていてよい時間」と説明しています。TTL のうちは覚えている答えを返し、切れたらまた聞きに行きます。 レコードにも種類があり、A は名前からIPv4アドレス、CNAME は別名（正式な名前への読み替え）、NS はそのゾーンを管理するネームサーバーを示します。

ルートのネームサーバーの名前（識別名）はAからMの13個で、12の独立した組織が運営しています。ただし、「サーバーが13台」ではありません。同じ識別名のサーバーを世界中に置いていて、2026年10月17日時点で運用中の数は2000を超えます。

このサイトの例には、example.com のような名前と 192.0.2.x のようなアドレスを使っています。これらは文書の例用に、実際には使われないよう取っておかれたものです（RFC 2606、RFC 5737）。

動画：細かく切って、先に読んでおく

インターネットで動画を流すとき、1本の大きなファイルを最初から最後まで送るのではなく、数秒の短い「セグメント」に切り、目次のような「プレイリスト」と一緒に配る方法があります。HLS という方式がその一つで、2009年に導入され、RFC 8216（2017年）に書かれています。ただし RFC 8216 は標準の規格（Standards Track）ではなく、情報として公開された文書（Informational）です。MPEG-DASH という別の方式は、2012年に最初の国際規格が出ました。 プレイリストには画質ちがいの一覧があり、回線の状態に合わせて切り替えられます。RFC 8216 の説明では、セグメントの長さは典型的には10秒です。

プレイヤーは、再生位置より先の分を先に読み込んでためておきます。これが「バッファ」です。バッファが空になると再生が止まります。 回線が、選んだ画質に必要なビットレート（1秒あたりのデータ量）より遅い状態が続くと、バッファは減っていきます。たとえば、回線が3、画質が6なら、1秒の再生に必要な量の半分しか届かず、ためた分から削られます。これは単純な割り算です。 そこで、回線やバッファの量を見て、次のセグメントの画質を選ぶ「適応ビットレート」という工夫が使われます。バッファの量を重く見る方式の研究もあります（2014年の論文）。 このサイトの画面の選び方の規則は、説明のために簡単にした仮のもので、実際のプレイヤーの方式とは違います。

LLM：次の言葉を選ぶ計算

LLM（大規模言語モデル）は、文章を「トークン」という小さな単位に区切り、それまでのトークンから次に来るトークンの確率を出し、その中から1つ選んで足す、という作業を繰り返して文章をつくります。 トークンは、単語より小さい断片を含みます。珍しい言葉を断片の組み合わせで表す方法が、2015年の論文などで研究されました。このサイトでは、自作の小さな規則で区切っています。実際の区切り方とは別物です。

2017年の論文「Attention Is All You Need」は、「注意」というしくみだけでつくる新しい構造（トランスフォーマー）を提案しました。多くの現在の言語モデルが、この構造を土台にしています。

どのトークンを選ぶかには、くじ引きのような要素があります。確率の表から選ぶ際、「温度（temperature）」という数で偏りを調整します。温度を下げると確率の高いものに集中し、上げると平らに近づいて、ふだん選ばれにくいものも出やすくなります。 この計算は、点数（スコア）を温度で割ってから確率に直すものです。たとえば点数が 2.0、1.0、0.1 のとき、温度1なら確率は約 0.66、0.24、0.10、温度2なら約 0.50、0.30、0.19、と平らになります。

大切なのは、モデルは「もっともらしい次の言葉」を選ぶように作られていて、単体では、書いた内容が事実かどうかを確かめる仕組みを持たないことです。そのため、もっともらしく書かれた間違いが出ることがあり、研究では「ハルシネーション」と呼ばれています。 このサイトの例は、自作の小さな確率表で、本物のモデルが何をどのくらい知っているかを表すものではありません。

ちがいを見る

• Cookie：同じ Cookie でも、属性しだいで送られる場面が変わります。
• DNS：2回目が速いのは、キャッシュに覚えているからです。TTL が切れると、また聞きに行きます。
• 動画：止まるのは、回線の速さが画質に追いつかず、バッファが空になったときです。
• LLM：温度を変えると、同じ入力でも出る文が変わります。

4つの作品を順に触ると、どれも「ためる」「覚える」「選ぶ」という考え方でつながっていることに気づくかもしれません。