規格は誰が決めているのか

ここまで、たくさんの略語が出てきました。

HTTP  TCP  DNS  TLS  JSON  UTF-8  ISO 8601  ECMAScript  POSIX  OAuth

素朴な疑問があります。

これ、誰が決めたのか？

Google が作ったブラウザと、Apple が作ったスマホと、 どこの誰が書いたか分からないサーバーが、なぜ同じ手順で会話できるのでしょうか。

答えは、書かれた仕様が公開されていて、全員がそれに従っているからです。 その仕様を 規格（standard） といいます。

この章は、その仕様がどこにあり、どう読み、いつ役に立つかの話です。

なぜ規格を知っていると得なのか

新人のうちは「規格なんて自分には関係ない」と感じます。実際には3つの場面で効いてきます。

1. 仕様の争いを1分で終わらせられる

「この API、日付は yyyy/MM/dd で返すべきでは？」
「いや yyyy-MM-dd でしょう」
   ↓
「日時は RFC 3339 に寄せませんか。2026-08-14T09:30:00+09:00 の形です」

「私はこう思う」の水掛け論が、「既にある選択肢のどれを採るか」に変わります。

ただし、規格を持ち出せば議論が終わるわけではありません。 規格はたいてい幅を持っているので（ISO 8601 には複数の書き方があります）、 「その中のどれを自分たちの API の約束にするか」はチームで決める必要があります。 規格が与えてくれるのは、共通の語彙と、検討済みの選択肢です。

2. 車輪を再発明しなくて済む

□ 国の一覧を自分で作る          → ISO 3166 がある
□ 通貨コードを独自に決める      → ISO 4217 がある
□ 「日本語」の言語コードを決める → ISO 639 がある
□ 独自のパスワード保存方式を作る → 既存の標準アルゴリズムがある

自分で決めた独自コードは、他社とデータ交換する日に必ず破綻します。

3. 「仕様ではどうなっているか」を自分で確認できる

ライブラリの挙動が想定と違う時、 「バグなのか、仕様通りなのか」を判定できるのは規格だけです。

Stack Overflow の回答より、一次情報のほうが速くて確実です。

誰が決めているのか — 標準化団体の地図

規格は1つの組織が全部決めているわけではありません。領域ごとに担当が違います。

通信の手順       → IETF（RFC）
ブラウザの中     → W3C / WHATWG
JavaScript の文法 → Ecma
物や決まりごと    → ISO
電気・信号・数値  → IEEE
文字             → Unicode
暗号             → NIST

RFC — インターネットの仕様書

エンジニアが最も読む機会が多いのが RFC（Request for Comments）です。 IETF が公開していて、全部無料で読めます。

RFC 9110  HTTP Semantics          HTTP そのもの
RFC 9112  HTTP/1.1
RFC 8446  TLS 1.3
RFC 8259  JSON
RFC 6749  OAuth 2.0
RFC 3339  日時の書き方（インターネット向け）
RFC 1035  DNS
RFC 2119  仕様書で使う「MUST」「SHOULD」の意味

名前の由来が示していること

「Request for Comments」——意見募集です。 「これで決まりだ」ではなく「こう考えたけど、どう思う？」として始まった文化がそのまま残っています。

インターネットの仕様が、特定の企業や政府ではなく、公開の議論で決まってきたことの表れです。

読み方の作法

RFC 2616  HTTP/1.1（1999年）      ← 今これを読んではいけない
   ↓ Obsoleted by
RFC 7230-7235（2014年）
   ↓ Obsoleted by
RFC 9110-9112（2022年）           ← 今読むべきはこれ

まだ規格ではないもの

Internet-Draft   議論中の草案。おおむね6ヶ月で失効し、改訂版が別の版として出る

「draft-」で始まる文書を根拠に実装すると、来月には内容が変わっている可能性があります。 参照すること自体は問題ありませんが、その場合は 版番号まで含めて固定し、更新を追いかける必要があります。

安定した標準として依存してはいけない、と覚えてください。

実務で効く ISO 番号

ISO の規格は数万件ありますが、プログラマが繰り返し出会うのは片手で足ります。

-- 悪い例
country VARCHAR(20)   -- '日本' '日本国' 'JAPAN' 'Japan' が混在する
 
-- 良い例
country CHAR(2)       -- ISO 3166-1 alpha-2: 'JP'
currency CHAR(3)      -- ISO 4217: 'JPY'

ISO 8601   幅が広い。20260814T093000+0900 のような区切りなしも許す
RFC 3339   ISO 8601 のうち、機械が扱いやすい部分に絞ったもの

デジュールとデファクト

規格には2種類あります。

デファクトが後から正式な規格になることはよくあります。 Docker はその典型で、広まった後に OCI として仕様が切り出されました。

どこで引くか

実務の落とし穴まとめ

まとめ

• 異なる会社の機械同士が会話できるのは、公開された仕様に全員が従っているから
• 領域ごとに担当が違う。通信は IETF、Web は W3C/WHATWG、JS は Ecma、物と決めごとは ISO
• RFC は無料で読める。 ただし番号は永久なので、Obsoleted by を必ず確認する
• MUST / SHOULD / MAY は定義された用語。「SHOULD だから省く」には理由が要る
• 国・通貨・言語・日時は自分で決めない。ISO のコードを使う
• デファクト標準もある。そして「規格だと思っていたら慣習」も珍しくない
• 迷ったら一次情報。Stack Overflow より速くて確実なことが多い

公式ドキュメント

章末問題

次の章では、ここまでの規格を実際に実装している側—— ブラウザの中で何が起きているのかを見ていきます。