IETFとは？RFCができるまでの標準化プロセスと組織・参加方法【2026年9月時点】

IETF（Internet Engineering Task Force）は、TCP/IP、HTTP、TLS、DNSといったインターネットの通信プロトコルを標準化し、その仕様をRFCとして無償で公開している団体です。会員制度はなく、個人の立場で誰でも議論に加われます。この記事では、IETFの組織と標準化の流れ、RFCのステータスの読み方を2026年9月時点の一次情報で整理し、実務で困りやすい「参照しているRFCがすでに廃止されていないか」の確かめ方まで扱います。

まとめ：IETFとRFCの要点

• IETFはインターネットのプロトコルを標準化する団体で、成果物はRFCとして公開されます。会員制ではなく、個人として参加します。
• 2026年9月時点で、作業は7つのエリアと134のワーキンググループ（WG）に分かれています。
• 標準化の代表的な経路は、Internet-Draft（I-D）の提出、WGでの合意、IESGの承認を経てRFCとして発行される流れです。WGを経ずに進む経路もあります。I-Dは作業中の文書で、確定したIETF標準としては扱えません。参照する場合は作業中の草案であることと版番号を明示します。
• 標準化過程のRFCはProposed StandardとInternet Standardの2段階です（RFC 6410）。Proposed Standardでも広く実装されている正式な仕様です。
• 仕様変更は別のRFCによる更新（Updates）や廃止（Obsoletes）で示されます。ただし、RFC 9920は意味内容を可能な限り保った再発行を認めています。TLS 1.3のRFC 8446も2026年7月にRFC 9846で置き換えられました。

以下で、組織・プロセス・RFCの読み方・参加方法の順に説明します。

IETFの正式名称と標準化の守備範囲

IETFはInternet Engineering Task Forceの頭字語です。JPNICは「インターネット技術の標準化を推進する任意団体」と説明しています。法人格を持つ会員組織ではなく、メーリングリストと会議に集まる参加者の集合体です。IETFの記録では、第1回の会合は1986年1月16〜17日に米国サンディエゴで開かれ、参加者は21人でした。

主な守備範囲はIP層とその上位の通信プロトコル、運用・セキュリティで、IPを各種リンク層で動作させるための仕様も扱います。IP、TCP、UDP、QUIC、HTTP、TLS、DNS、BGP、メール（SMTP）などが該当します。物理層や無線LAN、HTMLの仕様はIETFの担当ではありません。

W3C・WHATWG・ITU-T・IEEEとの分担

「どの団体の仕様を見ればよいか」は技術ごとに決まっています。同じWebの技術でも、HTTPはIETF、HTMLはWHATWGと担当が分かれます。

Webアプリの開発では、通信の約束事はRFC、画面側はWHATWGとW3Cを見る、と覚えておくと迷いません。W3Cのアクセシビリティ部門についてはWAIの解説で扱っています。

IETFの組織構造：7エリアとIESG・IAB・IETF LLC

実際の標準化作業はWGで進みます。WGは技術分野ごとのエリアに属し、エリアごとに置かれるエリアディレクター（AD）がWGの設立や文書の承認に責任を持ちます。

7つのエリアと担当するプロトコル

datatrackerのAPIで2026年9月15日に取得した現行エリアは次の7つで、活動中のWGは134です。WITは旧Transport Area（TSV）と、ARTエリアのWeb関連の一部を統合したエリアで、2024年3月のIETF 119から活動しています。QUIC・TCP・HTTPなどはWITの担当です。

WG名は略称で管理され、たとえばBlueskyのAT ProtocolもIETFでWGとして議論されています（AT Protocolの解説を参照）。

IESG・IAB・IRTF・IETF LLCの役割分担

• IESG（Internet Engineering Steering Group）：ADで構成され、RFCとして発行する標準化文書を最終承認します。
• IAB（Internet Architecture Board）：インターネット全体の設計方針を監督し、IESGの判断への異議申し立てを審査します。RFC 2026では「標準化の手続きが守られたか」についてIABの判断が最終で、手続きそのものが不十分だという訴えだけはISOC理事会に持ち込めます。
• IRTF（Internet Research Task Force）：標準化の前段にある長期的な研究を扱い、成果はIRTFストリームのRFCになります。
• IETF LLC（IETF Administration LLC）：会議運営、財務、契約などの事務を担う法人です。ISOC（Internet Society）の傘下で2018年8月27日に設立されました（RFC 8712）。

RFC 8712は「インターネット標準の開発と品質に責任を負うのはIETF」と明記しています。技術の中身を決めるのはWGとIESGで、IETF LLCやISOCは標準の内容を決めません。

Internet-DraftからRFC発行までの標準化プロセス

標準化の手続きはBCP 9（RFC 2026を中心とする文書群）に定められています。以下はWGを経由する代表的な流れです。

1. 提案者がInternet-Draft（I-D）を提出します。I-Dは原則として掲載から185日で失効するため、議論が続く間は版を更新します。ただし、IESGによる発行審査中など、失効しない状態もあります。
2. WGがI-Dを採択し、議論を重ねてWG Last Call（WG内の最終確認）に進めます。
3. 担当ADのレビューの後、IETF全体に意見を求めるIETF Last Callが行われます。
4. IESGが審査し、承認されるとRFC Editorで編集されます。プロトコル番号などの割り当てが要る場合はIANAと調整します。
5. RFC番号が付いて公開されます。

I-Dの冒頭には「最長6か月有効な草案で、work in progress以外の形で参照資料として引用するのは不適切」という趣旨の定型文が入っています。ベンダーが「draft準拠」とうたう機能は、RFC化の過程で互換性のない変更が入ることがあります。

ラフコンセンサスとハミングの判断基準

IETFは多数決で決めません。合意の考え方はRFC 7282「On Consensus and Humming in the IETF」（2014年6月）にまとめられており、同RFCは「We reject: kings, presidents and voting. We believe in: rough consensus and running code.」という言葉を、Dave Clarkによる1992年7月の第24回IETFでの講演に由来すると紹介しています。

RFC 7282の定義では、ラフコンセンサスは「すべての論点がaddressed（検討された）状態で、必ずしもaccommodated（要求どおり受け入れられた）必要はない」ものです。賛成の人数ではなく、反対意見が技術的に検討されたかで判断します。少数でも検討されていない技術的反論が残っていれば、合意は成立していません。

賛否を声の大きさで示すハミングは、投票ではなく議論の方向を探る手段でした。ただしIETFのWG向けガイドは、リモート参加者に不利なため現在はほぼ行われなくなったと説明しています。

RFCの種類とステータス：Proposed StandardとInternet Standard

RFCはRequest for Commentsの略で、1969年のRFC 1から続く通し番号の文書シリーズです。2026年9月15日時点のrfc-index.xmlでは、最大番号はRFC 10042（2026年8月発行）でした。RFCにはすべて標準が書かれているわけではなく、ステータスで性格が分かれます。

ステータス別の件数と意味

件数はrfc-index.xmlのcurrent-statusを数えた値です。2011年10月のRFC 6410で標準化過程は3段階から2段階に減り、Draft Standardは新規に使われなくなりました。表の138件は、それ以前に付いたステータスが残っているものです。

読み方で注意したいのは、Internet Standardが132件しかない点です。TLS 1.3（RFC 9846）もProposed Standardのままで、実務ではProposed Standardが事実上の標準として扱われています。「まだ提案段階だから採用を待つ」という判断は誤りです。

RFCのストリームとRFC Editor Model

RFCはIETFだけが出すものではありません。RFC Editorによると、発行元の流れ（ストリーム）はIETF、IRTF、IAB、Independent Submissions、Editorialの5つです。インターネット標準を出せるのはIETFストリームだけです。

RFCシリーズ全体の運営体制はRFC Editor Model（Version 3）で定められ、2026年2月にRFC 9920が発行されて、2022年のRFC 9280を置き換えました。

参照しているRFCが現行かを確かめる手順

RFCの再発行は意味内容を可能な限り保つ範囲に限られます（RFC 9920）。仕様の更新や置き換えでは別のRFCが発行され、古いRFCには「Obsoleted by」（廃止）や「Updated by」（一部更新）が記録されます。社内の設計書や古い技術記事に書かれたRFC番号は、そのまま信じると廃止済みの仕様を参照していることがあります。

obsoleted_byをたどるPythonスクリプト

RFC Editorは各RFCのメタデータをhttps://www.rfc-editor.org/rfc/rfcNNNN.jsonで公開しています。次のスクリプトは標準ライブラリだけで、obsoleted_byが空になるまで廃止関係をたどります。一部更新や正誤表は自動判定しないため、到達したRFCのUpdated byとerrataも別途確認してください。

import json
import sys
import urllib.request

def meta(rfc):
    url = f"https://www.rfc-editor.org/rfc/{rfc.lower()}.json"
    with urllib.request.urlopen(url, timeout=20) as r:
        return json.load(r)

def follow(rfc, depth=0):
    d = meta(rfc)
    print("  " * depth + f"{d['doc_id']} {d['status']} ({d['pub_date']}) {d['title']}")
    for newer in d["obsoleted_by"]:
        follow(newer, depth + 1)

follow(sys.argv[1] if len(sys.argv) > 1 else "RFC2616")

2026年9月15日にpython3 rfc_current.py RFC5246を実行した出力です。

RFC5246 PROPOSED STANDARD (August 2008) The Transport Layer Security (TLS) Protocol Version 1.2
  RFC8446 PROPOSED STANDARD (August 2018) The Transport Layer Security (TLS) Protocol Version 1.3
    RFC9846 PROPOSED STANDARD (July 2026) The Transport Layer Security (TLS) Protocol Version 1.3
  RFC9846 PROPOSED STANDARD (July 2026) The Transport Layer Security (TLS) Protocol Version 1.3

TLS 1.2のRFC 5246はRFC 8446とRFC 9846の両方から廃止されており、TLS 1.3の現行仕様はRFC 8446ではなくRFC 9846です。HTTP/1.1も同じ構造で、RFC 2616を指定するとRFC 7230〜7235を経てRFC 9110・9111・9112（2022年6月）に行き着きます。TLS 1.3の仕組みはTLS 1.3の解説記事で扱っています。

RFC番号を仕様の根拠にしてはいけない場面

• Obsoleted byが付いたRFC：調達仕様書や社内規程に「RFC 2616準拠」と書くと、2014年以降の修正が反映されません。現行番号に置き換えます。
• Internet-Draft：draft-ietf-で始まる文書は失効や非互換変更があり得ます。採用する場合はdraftの版番号まで固定して記録します。
• InformationalやExperimentalのRFC：RFCという名前でも標準ではありません。標準化過程かどうかをstatusで確認します。
• 4月1日発行のRFC：鳥でIPデータグラムを運ぶRFC 1149（1990年4月1日）のように、ジョークとして書かれた文書があります。

本文の誤りはRFC Editorの正誤表（errata）に登録されます。実装で解釈に迷ったら、JSONのerrata_urlが示すページも確認します。

IETFへの参加方法：メーリングリスト・ミーティング・参加費

最も手軽な参加方法は、関心のあるWGのメーリングリストに登録して議論を読むことです。登録は無料で、投稿も会議参加も必須ではありません。I-Dの状態やWGの議事録はdatatracker（datatracker.ietf.org）で公開されています。

投稿や発言の前に読んでおくべきなのがNote Wellです。「IETFに参加することで、IETFのプロセスとポリシーに従うことに同意する」と明記されており、著作権の扱いはBCP 78（RFC 5378）、特許の開示義務はBCP 79（RFC 8179）に従います。企業の技術者が自社の特許に関わる提案をする場合は、発言前に社内の知財部門と開示の要否を確認します。

年3回のIETFミーティングと開催予定

対面とオンラインを併用したミーティングが年3回、1週間の日程で開かれます。datatrackerに登録されている直近の日程は次のとおりです。

各回の直前の週末にはHackathonが開かれ、I-Dの実装を持ち寄って相互接続を試します。初回は2015年3月、IETF 92（ダラス）の直前でした。

参加費とリモート参加の選び方

ミーティングは有料です。IETF 127の早期料金（Super Early、登録締切は2026年9月28日23:59 UTC）は次のとおりで、登録時期が遅くなるほど上がります。

リモート参加費を負担できない人には、人数上限のない参加費免除（fee waiver）があります。自己申告に基づく制度で、資格の証明は求められません。特定のWGの議論を追うだけならメーリングリストで足り、発表や議長との調整が要る段階になってから会議に登録する順番で十分です。料金は回ごとに改定されるため、登録前にietf.orgの各回ページで確認してください。

よくある質問

IETFの日本語名はありますか？

公式の日本語名はありません。Internet Engineering Task Forceを直訳して「インターネット技術タスクフォース」と書かれることがありますが、IETF自身が定めた訳語ではないため、文書では英語名かIETFの略称を使うのが確実です。

IETFとRFCの関係は何ですか？

IETFは標準を議論して決める団体で、RFCはその結果を公開する文書シリーズです。ただしRFCの発行元はIETFだけではなく、IRTFやIAB、個人投稿（Independent）のRFCもあります。標準化過程（Proposed StandardやInternet Standard）のRFCを出せるのはIETFストリームだけです。

RFCとは何の略ですか？

Request for Commentsの略です。1969年に最初のRFC 1が出されて以来の通し番号で、2026年8月にはRFC 10042まで発行されています。名前は「意見募集」ですが、Proposed Standardなどのステータスを持つRFCは正式な仕様として扱われます。

IETFとW3Cの違いは何ですか？

IETFはHTTPやTLSなどの通信プロトコルを、W3CはCSS、アクセシビリティのWCAG、WebAuthnなどWebの上位技術を標準化します。HTMLとDOMは、2019年のW3CとWHATWGの覚書により主にWHATWGのLiving Standardとして開発されています。IETFの成果物がRFCなのに対し、W3Cの成果物はW3C勧告です。

IETFの会議には誰でも参加できますか？

参加登録をすれば誰でも参加できます。所属や資格の審査はなく、企業の代表ではなく個人として扱われます。ミーティングは有料で、IETF 127の早期料金は対面のWeek Passが950米ドル、リモートが270米ドルです。リモート参加費を負担できない人には資格証明の要らない参加費免除があり、メーリングリストでの議論は無料で誰でも加われます。

関連記事

• プロトコルとは？通信規約の3要素とRFCの読み方を実装目線で解説
• TLS 1.3とは？RFC 8446の仕組みと0-RTTの採否を実装者向けに解説
• QUIC（通信プロトコル）とは？HTTP/3を支える仕組みとTCPとの違いを実装視点で解説
• TCP/IPとは？4階層モデルとOSI参照モデルの違いを実装目線で解説
• RFC 9457とは？Problem Details（application/problem+json）でHTTP APIエラー応答を標準化【RFC 7807と