HTTP 418とは？ティーポットが今も残る理由

APIの実装中にHTTPステータスコードの一覧を眺めていると、400番台の途中で手が止まることがあります。417の次、418の行に I'm a teapot と書いてあるからです。

私はティーポットです、というサーバーからの返事。冗談としか思えない一行ですが、これはWikipediaの落書きではなく、IETFが正式に発行した文書に書かれた定義です。しかも消えるどころか、いまも主要な言語のライブラリに残り続けています。

この記事では、418がどこで生まれ、なぜ消えなかったのかを、RFC本文・IANAのレジストリ・GitHubのissueといった一次情報だけを頼りに整理します。裏の取れない噂話は載せません。読み終える頃には、規格というものが何で決まっているのかについて、少し違う景色が見えるはずです。

この4コマで描いたのは、実際の開発現場でよく起きる順番です。まずステータスコード一覧という実装者しか読まない場所で418に出会い、由来を調べ、最後に消せない理由を知る。技術ドキュメントの中に紛れ込んだ冗談は、笑い話として消費される前に、まず実装上の疑問として現れます。

現場で厄介なのは、ジョーク由来だと分かった後の判断です。自分たちのAPIで使ってよいのか、フレームワークが返してきたら不具合なのか、レビューで指摘すべきなのか。番号の出自を知っただけでは、この問いには答えられません。必要なのは、その番号がいまどの文書で管理されているかという現在地の確認です。

4コマの最後でデプロイ太郎が触れているのは、削除にもコストがかかるという事実です。世界中の実装に組み込まれた識別子を取り除く作業は、追加するより手間がかかります。この非対称性が、418という番号の運命を決めた大きな要素だと私は見ています。

HTTP 418 I’m a teapotとは何を返すステータスコードなのか？

HTTP 418 I’m a teapotは、ティーポットに対してコーヒーの抽出を依頼したときにサーバーが返す、と定義されたステータスコードです。出典はHTTPの本体仕様ではなく、コーヒーポットをネットワーク越しに操作するための架空のプロトコル文書にあります。

その文書がRFC 2324、正式名称は Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) です。発行日は1998年4月1日、区分はInformational、著者はL. Masinter氏。エイプリルフールに合わせて公開された、いわゆるジョークRFCの代表格として知られています。

418の定義そのものは、RFC 2324の2.3.2節にわずか2文で書かれています。原文は次のとおりです。

Any attempt to brew coffee with a teapot should result in
the error code "418 I'm a teapot". The resulting entity body
MAY be short and stout.

ティーポットでコーヒーを淹れようとする試みは、すべて418 I’m a teapotというエラーコードになるべきである、という内容です。返される本文は短くずんぐりしていてもよい、という一文まで添えられています。英語圏の童謡を思わせる言い回しですが、RFC本文にその由来の説明は書かれていません。

16年後、この設定はもう一度更新されます。2014年4月1日に発行されたRFC 7168、The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) です。著者はI. Nazar氏で、こちらもInformationalとして正式に発行されています。同文書の2.3.3節では、お茶を淹れられるポットがコーヒーに対応していない場合、一時的な理由なら503を、恒久的にティーポットであるという意思表示なら418を返してよい、と整理されました。

418と404・503は何がどう違うのか？

418と404・503の最大の違いは、拠り所となる文書の性質です。404と503は現行のHTTP仕様であるRFC 9110で定義された実務用のコードですが、418の定義はジョークプロトコルの側にしかありません。

比較観点	404 Not Found	418 I’m a teapot	503 Service Unavailable
定義している文書	RFC 9110（HTTPの現行仕様）	RFC 2324・RFC 7168（ジョークRFC）	RFC 9110（HTTPの現行仕様）
意味	要求されたリソースが見つからない	ティーポットなのでコーヒーは淹れられない	サーバーが一時的に利用できない
実務での役割	日常的に発生する標準的な応答	イースターエッグや拒否の意思表示として散見される	メンテナンスや過負荷時の応答
IANAレジストリでの記載	正規のコードとして登録	(Unused) として予約	正規のコードとして登録

なぜHTTPステータス418は削除されずに生き残ったのか？

HTTPステータス418が注目を集めた直接のきっかけは、2017年に出された削除提案と、それに反発する形で立ち上がったSave 418と呼ばれる動きです。皮肉なことに、消そうとした行為が418の知名度を一段押し上げました。

時系列で確認します。2017年8月6日、Node.jsのリポジトリに 418 I’m A Teapot という表題のissue（#14644）が起票されました。起票者はmnot氏です。内容は、HTCPCPはHTTPが乱用されている状況を示すための4月1日のジョークであり、皮肉なことに今度はそのHTCPCPの一部が各種HTTPスタックに実装されてしまっている、という問題提起でした。

提案の理由も明快です。現時点で4xxの空き番号には余裕があるものの、将来HTTPの意味論がこの番号を必要とする可能性がある。実装が418を抱え込んでいること自体が、HTTPワーキンググループで418を実用目的に割り当てない根拠として使われてしまっている。だからコア実装からは外し、必要な人は拡張で実装すればよい、という筋立てです。

これに対して立ち上がったのがsave418.comです。運営しているのはShane Brunswick氏で、サイト開設当時の自己紹介によれば、高校2年生に進級する時期の学生でした。同サイトはRFC 2324の418の定義文を掲げたうえで、418はコンピューティングが人間の手で作られてきたことを思い出させる存在であること、長年418を取り込んできたWebサイト側に技術的な影響が出ることを主張しています。IETF、ワーキンググループの議長、Node.jsへの言及もそれぞれ確認できます。

いまのNode.jsとGoに418は残っているのか？

結論として、Node.jsにもGoにも418は残っています。issue自体はクローズされましたが、削除は実行されませんでした。

Node.jsのmainブランチにある lib/_http_server.js のステータスコード表には、417と421に挟まれる形で次の行が現在も存在します。

417: 'Expectation Failed',
418: 'I\'m a Teapot',
421: 'Misdirected Request',

コメントとして参照されているのはRFC 7168の2.3.3節、つまり2014年のお茶版ジョークRFCです。もう一方のGoでは、標準ライブラリ net/http に定数が定義されています。

StatusTeapot = 418 // RFC 9110, 15.5.19 (Unused)

興味深いのは参照先の違いです。Node.jsはジョークRFCを引用したまま、Goは現行仕様であるRFC 9110の予約条項を引用しています。同じ番号を残しながら、根拠だけが時代に合わせて差し替えられている状態です。

418はIANAとRFC 9110で現在どう扱われているのか？

現在の418は、IANAのHTTP Status Code Registryに (Unused) として登録された予約枠です。空き番号ではなく、他の用途に割り当てられない状態で押さえられています。

レジストリを実際に見ると違いが分かります。418の説明欄は (Unused)、参照先は RFC 9110, Section 15.5.19 と記載されています。一方で続く419や420の行は Unassigned、つまり未割り当てのままです。登録済みで使わないと明記された418と、まだ誰にも割り当てられていない419以降は、レジストリ上で別物として扱われているわけです。なお、このレジストリの最終更新日は2025年9月15日と表示されています。

参照先のRFC 9110は、2022年に発行されたHTTPの意味論を定める現行仕様です。その15.5.19節は 418 (Unused) という見出しで、この番号がRFC 2324に由来し、ジョークとして広く実装された結果、他の用途に割り当てられないよう予約されている旨を扱っています。ジョークが、正規仕様の中に注釈付きで居場所を得たかたちです。

MDN Web Docsの日本語版も、この経緯を明記しています。当初はエイプリルフールのジョークとして定義されたが、ジョークとして広く普及したためRFC 9110で正式に予約され、当分の間ジョーク以外の意味を割り当てることはできない、という記述です。さらに同ページには、一部のウェブサイトが自動化されたクエリーなど処理したくないリクエストに対してこのレスポンスを使用している、という一文もあります。

実務のAPIで418を返してもよいのか？

実務で418を返す設計は、可能ではあるものの、公開APIでは避けたほうが無難だと私は考えています。MDNが認めているとおり実際に使っている運用は存在しますが、受け取る側にとって意味が一意に定まらないためです。

アクセスを拒否したいのであれば403、回数制限に引っかかったのであれば429といった具合に、意味が定義済みのコードを使ったほうがクライアント側の実装は素直になります。監視ツールやSDKの多くも、既知のコードを前提に挙動を組み立てています。ここは仕様の是非というより、運用のしやすさの問題です。

逆に、社内ツールや検証用のエンドポイントで、明確に遊びと分かる場所に置く分には害は小さいでしょう。イースターエッグとしての418は、そういう文脈で長く生き延びてきた面があります。判断の分かれ目は、その応答を将来別の誰かが機械的に解釈する可能性があるかどうかです。

418が消えなかった経緯からIT業界の何が読み取れるのか？

418が消えなかった経緯から読み取れるのは、規格が正しさの一点だけで決まるわけではないという現実です。実装された数と、それを剥がすときの手間が、番号の生死を左右しています。

ここから先は事実の整理ではなく、私の解釈です。私はサービスや仕様を見るとき、まずそれが誰のどんな課題を解決したのかを確かめる癖があります。その物差しを418に当てると、答えは少し変わったものになります。418は技術的な課題を何ひとつ解決していません。解決したのは、HTTPが本来の用途を超えて使われつつあるという状況を、笑いの形で伝えるという表現上の課題でした。

技術に良し悪しはなく、使いどころと伝え方で価値が決まる。これは私が繰り返し書いてきた持論ですが、418はその極端な実例だと感じます。機能はゼロなのに、伝え方だけで四半世紀生き延びた。仕様は機能で採用され、習慣で生き残るという言い方をしてもよさそうです。

なぜ削除ではなく予約という着地になったのか？

削除ではなく予約に着地した理由について、あくまで外から公開情報を追っていた私の見立てを書きます。決め手は、削除コストと維持コストの非対称性ではないでしょうか。

ステータスコード表から1行消す作業自体は一瞬です。ところが、その1行に依存しているかもしれない世界中の実装・テスト・ドキュメントを洗い出す作業は一瞬では終わりません。対して、残しておくコストはほぼゼロに近い。この差がある限り、消すという判断は常に不利な側に立たされます。

もう一点、2017年の議論が持った副作用も無視できないと見ています。削除提案が公開の場に出た瞬間、それまで一部の実装者しか意識していなかった418が、多くの開発者にとって守る対象として認識されました。公式発表を鵜呑みにせず時系列から逆算すると、可視化と反発が同時に起きたこの局面で、418は単なる番号から共有された文化財に変わったように見えます。もちろん、これは内部事情を確認したうえでの断定ではありません。

この構造は、IT業界のあちこちで見かけます。誰も積極的に選んだわけではないのに、いつの間にか動かせなくなっているもの。418はその中でも、当事者たちが少し楽しそうに守っている珍しい事例です。

この先を考えると、418の意味はもう一度変わるかもしれません。仕様書を読むのが人間だけでなくAIにも広がった今、由来を知らないまま418を提案してくるコード生成や、逆にジョークだと判断して除外する挙動が出てくる場面は増えていくはずです。過去の文脈を知っている側が判断を誤らずに済む、という構図は当分続くでしょう。あなたのシステムに残っている消せない何かは、418のように誰かが理由を語れる状態になっているでしょうか。

次の一歩としておすすめしたいのは、IANAのHTTP Status Code Registryを一度そのまま眺めてみることです。自分が普段使っている番号のうち、どれが正規で、どれが予約で、どこが空いているのかを知るだけで、API設計時の迷いはかなり減ります。

類似のIT考察

LGTMに猫画像を貼る文化はなぜ生まれた？	開発現場の遊び心が定着し、レビュー文化の一部として共有されるようになった経緯を考察。
hoge・foo・barとは？サンプルコードで使う理由を解説	誰も決めていない仮の名前が、事実上の標準として世界中のサンプルコードに残り続ける理由。
なぜパスワードは半角英数字なのか？残る昭和の理由	過去の制約が撤廃されないまま現在の入力ルールとして生き残っている背景を掘り下げた記事。

この記事と一緒に知っておきたい用語

用語	この記事との関連
HTTP	418が属するステータスコードの仕組みそのものを定めている通信の約束事。
404エラー	418と同じ400番台でありながら、現行仕様で定義された代表的な正規コード。
イースターエッグ	418が実装に残り続けた形態そのもので、遊び心を仕込む開発文化を指す言葉。
IANA	HTTPステータスコードのレジストリを管理し、418を予約扱いで登録している組織。
API	418に出会う場面の多くがAPI開発であり、返すコードの選び方が設計品質を左右する。

【出典】参考URL

https://www.rfc-editor.org/rfc/rfc2324 ：RFC 2324の正式名称・1998年4月1日という発行日・2.3.2節の418の定義原文
https://www.rfc-editor.org/rfc/rfc7168 ：RFC 7168（HTCPCP-TEA）の正式名称・2014年4月1日という発行日・2.3.3節の503と418の使い分け
https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ：418が (Unused) として登録され、419以降が Unassigned である点とレジストリの最終更新日
https://www.rfc-editor.org/rfc/rfc9110 ：現行のHTTP仕様における15.5.19節 418 (Unused) の位置づけ
https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/418 ：RFC 9110で予約された経緯と、自動化されたクエリーへの利用に関する記述
https://github.com/nodejs/node/issues/14644 ：2017年8月6日に起票されたNode.jsへの418削除提案の内容
https://raw.githubusercontent.com/nodejs/node/main/lib/_http_server.js ：現在のNode.jsのステータスコード表に418が残っている事実
https://pkg.go.dev/net/http ：Goの標準ライブラリにおける StatusTeapot = 418 の定義
https://save418.com/ ：Save 418運動のサイトの主張と運営者に関する記載