まず、コンピュータの 話では ない ところから。

ねじを 思いうかべて ください。

お店で 買った ねじが、 べつの 会社の 作った あなに ぴったり 入る。

あたりまえに 見えますが、 よく 考えると ふしぎです。

作った 人は、あなたの もって いる ものを 見た ことも ないのに。

どうして 合うのでしょう。

みんなで「この 太さに しよう」と きめて あるからです。

コンセントも 同じです。 かたちを きめて あるから、 どの きかいでも さしこめます。

この「みんなで きめた こと」を きかくと いいます。

コンピュータの 世界にも、 おなじ ものが たくさん あるのです。

コンピュータの話をする前に、身近な例から始めます。

ねじが合う理由

お店で買ってきたねじが、別の会社が作った穴にぴったり入ります。

当たり前に見えますが、変な話です。 ねじを作った人は、あなたが持っている穴を見たことがありません。

合うのは、あらかじめ寸法を決めてあるからです。 太さ、ねじ山の角度、山と山の間隔。全部そろえてあります。

この「みんなで決めたこと」を 規格、あるいは 標準 といいます。

決めごとがないと、どうなるか

想像してみてください。会社ごとにねじの太さがバラバラだったら。

• 修理のたびに、その会社のねじを取り寄せる
• 会社がつぶれたら、二度と直せない
• ねじ屋さんは、何十種類も在庫を持つ

誰も得をしません。 だから決めごとを作る。単純ですが、これが標準の本質です。

コンピュータでも同じ

コンピュータの世界にも、同じものが山ほどあります。

ケーブルの形、電気の流し方、データの並べ方、文字の表し方、 通信の手順。どれも決めてあります。

そして面白いのは、その決め方が分野によって違うことです。 次の章から、3つ見ていきます。

標準（standard）とは、複数の作り手が独立に作ったものを、 事後に組み合わせられるようにするための共通の取り決めです。

なぜ必要になるのか

ねじを例に考えると、構造がはっきりします。

注目すべきは最後の行です。 標準は、新しい作り手が入ってこられるようにする装置でもあります。

標準は「制約」であり「自由」でもある

標準に従うと、設計の自由は減ります。好きな寸法にはできません。

しかし同時に、相手を気にせず作れるようになります。 標準を満たしていれば、まだ存在しない製品とも組み合わさる。

釣り道具の記事で、 小寺彦兵衛が技法を同業者に公開したことが産地を生んだ話を書きました。 共有できる形にしたことが、結果として全体を大きくするという点で、 標準も同じ構造を持っています。

では、その標準は誰がどうやって決めているのか。 決め方は一つではありません。次の3章で、性格の違う3つを見ます。

インターネットの きまりは、 RFCと いう 文しょに 書いて あります。

この 名前が おもしろいのです。

RFC は、外国の ことばで 「ごいけんを ください」と いう いみです。

「これが きまりだ、したがえ」では ありません。

「こう しようと 思うけど、どう？」 と 聞く 形なのです。

さいしょの RFC は、 1969年 4月7日に 出されました［1］。

書いたのは、 スティーブ・クロッカーと いう 人です［1］。

じつは この 人、 そのとき まだ 大学院生でした。

えらい 人が きめたのでは なく、 学生が「こう しませんか」と 出した。

その やり方が、いまも つづいて います。

インターネットの決めごとは、RFC という文書に書いてあります。

この名前が、いきなり面白い。

最初のRFCは1969年

RFC 1 のタイトルは「Host Software」。 1969年4月7日、スティーブ・クロッカーが書きました［1］。

インターネットの記事で、 最初の通信が「LO」で止まった話を書きました。あれが1969年10月です。 RFC はそれより半年前から始まっていたことになります。

そしてクロッカーは、当時まだ大学院生でした。 偉い人が決めたのではなく、学生が「こうしませんか」と書いた文書から始まっている。

いまも番号が続いている

RFC には1番から順に番号がついていて、 いまも増え続けています。番号は取り消されません。

古くなった決めごとは、新しいRFCが「これに置きかえる」と宣言します。 古い文書は消さずに残す。 だから、なぜそう決まったのかを後から追えます。

誰でも書ける

RFC は、誰でも草案を出せます。 会社の代表でなくても、有名でなくてもかまいません。

出された案は、みんなに読まれ、議論され、 「まあこれでいいだろう」となったら公開されます。

この「まあこれでいい」という決め方に、じつは名前がついています。 次の章で出てきます。

インターネットの技術仕様は RFC（Request for Comments）という 文書群として公開されています。

名前が方針を表している

Request for Comments を直訳すれば「意見を求む」です。 規則の宣告ではなく、提案と応答の形式を名前に持っています。

RFC 1 は「Host Software」、著者は Steve Crocker、 公開は 1969年4月7日 です［1］。 ARPANET の最初のホスト間通信（1969年10月29日）よりも前です。

言葉の強さを定義した文書

標準文書には、独特の難しさがあります。 「〜すること」がどれくらい強い要求なのかが曖昧になるという問題です。

これに取り組んだのが RFC 2119（S. Bradner、1997年3月、BCP 14）です［2］。

「言葉の意味を決めるための文書」を、番号付きの標準として発行した。 これは重要な発明です。

仕様書を読む人が世界中にいて、母語もばらばらである以上、 解釈の幅そのものを潰しておかないと、実装がずれます。 いまも多くのRFCが、冒頭で「本文書のキーワードはBCP 14に従う」と宣言します。

なお、この定義はその後も手が入っています。 RFC 8174（B. Leiba、2017年5月）は RFC 2119 を更新し、 これらのキーワードは大文字で書かれたときにだけ特別な意味を持ち、 小文字なら通常の英語として読むことを明確化しました［3］。

「言葉の意味を決めた文書」に、さらに補足が必要になった。 曖昧さを潰す作業には、きりがないということでもあります。

番号を消さないという設計

RFC は発行後に書きかえられません。 内容が古くなった場合は、新しいRFCが旧文書を obsolete（廃止）すると宣言する形をとります。

この方式には利点があります。

• ある時点で何が標準だったかを、後から正確に再現できる
• なぜその決定に至ったかの経緯が残る
• 古い実装が何に従っていたかを特定できる

ブラックホールの記事で 論文のDOIを示したのと同じで、 あとから同じ文書にたどりつけることが、 技術の議論では決定的に重要になります。

きまりを つくる とき、 ふつうは どう すると 思いますか。

とうひょうを して、 多い ほうに きめる。

そう 思いますよね。

でも、インターネットの きまりを つくる 人たちは、 それを しません。

1992年、ある 先生が こんな ことばを 言いました［4］。

どういう いみでしょう。

「えらい 人が 言ったから」では きめない。

「多くの 人が そう 言ったから」でも きめない。

きめるのは、 じっさいに 作って みて、動いたか どうか。

口で 言いあうより、 動く ものを 見せた ほうが 早い、と いう ことですね。

決めごとを作るとき、ふつうは多数決を思いうかべます。 代表者が集まって、投票して、多いほうに決める。

インターネットの決めごとを作る人たちは、そうしません。

1992年の言葉

1992年7月、IETF という会合で、 デビッド・クラークがこう述べました［4］。

何を言っているのか

3つとも否定されています。

• 王＝ 権威で決めない。「偉い人が言ったから」は理由にならない
• 大統領＝ 選ばれた代表が決めるのでもない
• 投票＝ 多数決でも決めない

では何で決めるのか。

• おおまかな合意……全員一致でなくてよい。強い反対が残っていなければ進む
• 動くコード……実際に作って、動かして、示す

なぜ多数決を避けるのか

多数決には弱点があります。

誰に投票権があるのかを、先に決めなければならないのです。

会社ごとに1票？ 人数ぶん？ 国ごと？ そこを決めた時点で、大きな会社や大きな国が有利になります。

それを避けるために、票の代わりに動くものを持ってこいとしました。 動くかどうかは、誰が言おうと同じだからです。

肩書きも、会社の大きさも関係ない。 この考え方が、インターネットの決めごとを支えています。

標準化の意思決定において、IETF は投票による多数決を採りません。 その方針を端的に示すのが、次の言葉です。

この一文は、標準化の方法論として次の3つを否定しています。

投票の何が問題なのか

多数決には、見落とされがちな前提があります。 投票する資格の範囲を、あらかじめ確定しておく必要があるという点です。

• 1企業1票にすれば、小さな企業を分社した側が有利になる
• 参加人数ぶん与えれば、人を多く送れる組織が有利になる
• 国単位にすれば、技術と無関係な力学が入る

どう設計しても、資源を持つ側が有利になります。

代わりに置いたもの

そこで置き換えたのが、次の2つです。

• rough consensus（おおまかな合意）：全会一致は求めない。 残った反対が technical な根拠を欠くなら前へ進む
• running code（動くコード）：主張は実装で示す。 相互接続の実験で動けば、それが最も強い論拠になる

この方式のねらいは、判定基準を発言者から切り離すことにあります。 動くかどうかは、原理的には誰が確かめても同じ結果になります。

ただし、標語がそのまま手続きではない

ここは正確に押さえておく必要があります。

この言葉は 1992年のスライドに書かれた一文であって［4］、 現在の標準化手続きそのものを説明したものではありません。

実際のIETFには、ワーキンググループでの合意確認、 広く意見を募る段階、承認の段階、異議申立ての仕組みといった、 明文化された手順があります。

標語はその手順が何を目指しているかを示すもので、 手順の代わりになるものではない、と読むのが正確です。

弱点もある

• 「おおまかな合意」に達したかどうかの判断には、裁量が入る
• 実装できる資源を持つ側が、やはり有利になりうる
• 合意に至らない論点は、決まらないまま残る

権威と多数決を避けた代わりに、別の難しさを引き受けている。 完全な方式ではなく、どの困難を選ぶかという選択だと理解するのが正確です。

Wi-Fi の せつめいに、 こんな 数字を 見た ことは ありませんか。

802.11

へんな 数字ですね。 でも、ちゃんと いみが あります。

802 は、 「コンピュータを つなぐ きまり」を あつかう グループの 番号です。

そして、その あとの 数字で しゅるいを 分けて います。

• 802.3……ケーブルで つなぐ ほう
• 802.11……電波でんぱで つなぐ ほう（Wi-Fi）［5］

ここで、まちがえやすい ことが あります。

「802.11」と「Wi-Fi」は、じつは べつの ものです。

• 802.11……きまりそのもの
• Wi-Fi……その きまりを ちゃんと まもって いるか しらべて、みとめて あげる しるし［6］

Wi-Fi Alliance と いう だんたいが、 きかいを しらべて、 「これは 大じょうぶ」と みとめて います［6］。

つまり、 きまりを 作る ところと、 まもって いるか しらべる ところが べつべつに ある、と いう ことです。

きかいの はこに どちらも 書いて あるので、 こんど さがして みて ください。

Wi-Fi の説明書に、こんな数字が並んでいるのを見たことがありませんか。

IEEE 802.11ax とか、802.11be とか。

呪文みたいですが、ちゃんと意味があります。

番号の読み方

「Wi-Fi」は規格の名前ではない

ここは間違えやすいところです。 IEEE 802.11 と Wi-Fi は、別のものです。

Wi-Fi Alliance は Wi-Fi CERTIFIED という認証をしていて、 2023年時点で8万を超える製品が認証を受けています［6］。

役割が分かれていることの意味

決める人と、守れているか確かめる人が別なのです。

これは大事な工夫です。規格を読んだだけでは、 その製品がちゃんと従っているかは分かりません。 誰かが実際に試して確かめる必要がある。

決めるだけでは足りず、確かめる仕組みまでいる。 規格が本当に役に立つには、そこまで必要だということです。

分けて決める、という工夫

なぜ番号で分けるのでしょう。

全部をひとつの規格にすると、どこかを直すたびに全体を見直すことになります。 有線の話をしたいだけなのに、無線の担当者も付き合わされる。

そこで、扱う分野ごとにグループを分けました。 有線は有線、無線は無線で、それぞれが自分のペースで進められます。

大きな問題を、小さく切り分けて、別々に進める。 これは規格に限らず、ものごとを前に進めるときの基本です。

RFCとの違い

RFC と IEEE では、決め方がずいぶん違います。

802.11 のワーキンググループでは、 定期的な会合と投票の手続きが行われています［5］。 日程も決まっていて、手順に沿って進みます。

決め方は一つではないということです。 電波の規格のように、国の法律や他の機器への影響が関わるものは、 手続きをはっきりさせたほうが都合がよい面もあります。

IEEE 802 は、LAN／MAN（構内・都市規模のネットワーク）を扱う 標準化委員会です。番号の階層が、そのまま分野の区分になっています。

802.11 のワーキンググループは 「The Working Group for WLAN Standards」を名乗り、 課題ごとに タスクグループ を置いて並行して作業します［5］。 規格名の末尾につく `ax`、`be` といった英字は、このタスクグループの識別子に由来します。

分割することの意味

番号による分割は、単なる整理ではありません。 作業を独立させ、並行して進められるようにするための構造です。

• 有線の改訂が、無線の議論を待たなくて済む
• 関心のある人だけが、その議論に参加すればよい
• ある系列が停滞しても、他の系列は進む

インターネットの記事で見た 「全体を管理する主体を置かない」設計と、発想が通じています。 依存を減らせば、部分ごとに動ける。

RFC との比較

同じ「標準を作る」でも、RFC と IEEE では方式が異なります。

どちらが優れているという話ではありません。 対象の性質が違えば、適した決め方も変わります。

無線の規格は、電波という共有資源を扱います。 干渉すれば他人に迷惑がかかり、各国の法規制とも関わる。 手続きの明確さが求められる領域だと言えます。

さいごに、うまく いかなかった 話を します。

コンピュータは、文字を 数字で おぼえて います。

「あ」は この 番号、 「い」は この 番号、と きめて あるのです。

むかしは、この 番号の きめ方が 国に よって ちがいました。

日本には 日本の きめ方、 中国には 中国の きめ方。

すると、どう なると 思いますか。

日本で 書いた ものを べつの きめ方で 読むと、 へんな 記ごうの ならびに なって しまいます。

これを もじばけと いいます。

そこで、 「世界じゅうの 文字を、 ぜんぶ ひとつの 表に 入れよう」 と いう 話に なりました。

ところが、ここで こまった ことが 起きます。

その 表を、 べつべつの ところが 2つ 作って しまったのです［7］。

最後に、うまくいかなかった例を見ます。

文字は数字で覚えている

コンピュータは文字を数字として扱います。 「あ」は何番、「い」は何番、と決めておくわけです。 この対応表を 文字コード といいます。

問題は、この表が国ごとにバラバラだったことです。 日本には日本の表、中国には中国の表がありました。

別の表で読むと、文字が化けます。文字化けです。 規格が合っていないと、こうなるという分かりやすい例です。

統一しようとしたら、2つできた

インターネットが広がり、 ソフトウェアを大きく変えずに世界中で使いたいという要求が出てきました［7］。 そこで「世界の文字を全部ひとつの表に入れよう」という話になります。

ところが、ここで困ったことが起きました。

ISO（国際標準化機構）が作ろうとした表と、 Unicode という別の枠組みが、同時に進んでいたのです［7］。

統一するための規格が、2つできてしまった。 これでは意味がありません。

どうやって解決したか

結末は、ある意味で拍子抜けするものでした。

ISO の案には、各国から一本化を求める声が上がりました。 そして Unicode と同じ文字集合、同じ番号にそろえることになり、 いまは両者が連携しながら拡張を続けています［7］。

どちらかが勝ったのではなく、そろえたのです。 いまも2つの名前は残っていますが、中身は同じものを指しています。

規格の世界では、ときどきこういうことが起こります。 2つあること自体が困りごとなので、寄せるしかないのです。

そして、2つに割れているあいだの時間は、 誰にとっても損でした。標準の目的は、そもそも合わせることだからです。

標準化がうまくいかない場合もあります。 その典型が、標準が複数できてしまう状況です。

前提 ── 文字は符号で表す

文字は、コンピュータ内部では数値（符号）として扱われます。 どの文字にどの符号を割り当てるかを定めたものが文字コードです。

かつては各国が独自の文字コードを持っており、 異なる文字コードで解釈すると文字化けが生じました。 標準が一致しないことの帰結が、そのまま画面に出るという、 分かりやすい例です。

統一の動機

統一が求められた背景には、 インターネットの普及と、 ソフトウェアを大きな変更なく全世界で使えるようにしたいという要求がありました［7］。

分裂と収束

ところが、統一のための規格が2系統で進みました。

ISO は、世界中の文字を統合せずそのままの形で32ビットに収める ISO 10646 を策定しましたが、 Unicode との一本化を求める各国から賛同が得られず、 結果として Unicode と同じ文字集合・符号位置とすることになりました。 現在は両者が連携を取りながら拡張されています［7］。

ここから読み取れること

この経緯には、標準というものの性質がよく表れています。

• 標準の価値は、内容より「揃っていること」に強く依存する。 2つある標準は、1つの劣った標準より役に立たないことがある
• 技術的な優劣だけでは決着しない。 採用の広がりが、事実上の決定要因になる
• 収束には、どちらかが譲る必要がある。 折り合う対象は、たいてい「使われている側」になる

インターネットの記事で、 1983年にネットワーク全体が一斉に TCP/IP へ移行した話を書きました。 移行できたのは、つながっている台数が少ないうちだったからです。

文字コードも同じで、 普及したあとで統一しようとすると、はるかに高くつきます。 規格を決めるタイミングそのものが、技術的な問題になるということです。

きかくは、身の まわりに たくさん あります。 さがして みましょう。

• きかいの はこや うらを 見る。 「802.11」と 書いて ありませんか。
• 電池を 見る。 大きさが きまって いますね。 これも きかくです。どの 会社のでも 入ります。
• もじばけを 見て みる。 おとなの 人に 聞くと、 むかし よく 見た 話を してくれるかも しれません。
• ねじを くらべる。 ちがう ものから 取った ねじが、 入れかえられるか ためして みましょう。

規格は身のまわりだらけです。探すゲームだと思うと面白くなります。

• 機器の裏や箱を見る。「IEEE 802.11」と書いてあります。 末尾の英字（ax、be など）が世代です。
• RFC を実際に読んでみる。誰でも無料で読めます。 RFC 1 は短いので、最初の1本として向いています。
• 身近な規格を数える。単3電池、USB、紙のA4サイズ、 線路の幅、信号の色。全部決めごとです。
• 文字化けを再現する。テキストファイルを別の文字コードで開くと起きます。 5章の話が目で見えます。

関連する記事

• インターネットはなぜ世界中とつながるのか（決めごとの中身のほう）

この分野の利点は、一次資料がすべて公開されていることです。 伝聞ではなく、原典を直接読めます。

やってみる

1. RFC 1 を読む：rfc-editor.org で読める。 1969年の文書が、いまも同じ場所にある
2. RFC 2119 を読む：MUST と SHOULD の定義を原文で確認する。 日常語との違いが分かる
3. 手元の機器の規格番号を調べる：802.11 の後ろの英字から、 どのタスクグループの成果かをたどる
4. 文字化けを起こす：同じファイルを異なる文字コードで開き、 何が起きるかを観察する

調べる入口

• RFC Editor（すべてのRFCが番号順に読める）
• IEEE 802.11 Working Group
• IETF（議論の記録も公開されている）

考えてみると面白いこと

• 権威でも多数決でもない決め方は、どんな場面なら成り立つのか
• 標準が2つできたとき、どちらに収束するかは何で決まるのか
• 「いつ決めるか」は、なぜ技術的な問題になるのか