HTTP 418 I'm a Teapot（私はティーポットです）

TL;DR — 418 I'm a teapot は、ウェブで最も愛されているジョークのステータスコードです。RFC 2324のコーヒーポットに関するエイプリルフールRFCに由来し、通常のHTTPアプリケーションの意味論を持つことはありません――しかし、RFC 9110とIANAのレジストリによれば正式に 予約済み であり、未割り当てではありません。Googleの2023年時点のガイダンスでは、ほかの429以外の4xxと同様に扱われるため、URLはインデックス登録されません。このサイトで試してみてください。/coffee は本物の418を返します――Networkタブを確認しましょう。

418の由来

1998年4月1日、IETFは RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) を公開しました。これは、ウェブ経由でコーヒーポットを制御するための、完全に仕様化された風刺的なプロトコルです。その成果には、BREW メソッド、Accept-Additions ヘッダー（milk、syrup、whisky）、そして不朽のステータスコードが含まれます。

418 I’m a teapot — 「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』になるべきである。結果のエンティティボディは短くてずんぐりしたものでもよい。」

ジョークのすべてはそこにあります。ティーポット に コーヒー を頼んだのです。ティーポットにはできません。ティーポットだからです。

その16年後、RFC 7168 はお茶を淹れる家電向けにこの発想を再訪しました。これも情報提供型のエイプリルフールRFCで、一時的にコーヒーが切れている 家電と、永久にティーポットである家電を区別するものでした。どちらのRFCも418に通常のHTTPアプリケーションの意味論を与えていません。いずれも、コアHTTPではなく風刺的なプロトコルであるHTCPCPを説明するものです。

なぜ本物のHTTPにならなかったのか

418に通常のHTTPの意味論が割り当てられることはありませんでした――しかし「未割り当て」でもありません。現在のHTTP Semantics仕様である RFC 9110 は、ジョークとして展開されることが多かった点を理由に、このコードを正式に 予約 しています。また、IANA HTTP Status Code Registry はRFC 9110を参照しながら、418を (Unused) と記載しており、通常の再利用はできません。 Evidence for this claim RFC 9110 reserves status code 418, citing how often it has been deployed as a joke, and leaves open the possibility of assigning it a different meaning in the future if circumstances require it. Scope: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Confidence: high · Verified: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) 2017年、IETFのHTTPワーキンググループは、このコードを有用な用途に再割り当てできるよう整理することを提案しました。インターネットは 「Save 418」キャンペーン で応じ、予約は維持されました――RFC 9110も、将来必要になれば再割り当てできる余地を残しています。 Evidence for this claim The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Scope: IANA's current registry entry for status code 418. Confidence: high · Verified: 2026-07-16 IANA: HTTP Status Code Registry — 418

その予約が実装者を止めることはありませんでした。Goの net/http とPythonの http モジュールは、どちらも名前付きの418定数（StatusTeapot、HTTPStatus.IM_A_TEAPOT）を公開しています。ほかのフレームワークやプラットフォームも、Google独自の google.com/teapot を含め、イースターエッグとして追随しました。 Evidence for this claim Go's net/http and Python's http module both expose a named 418 status constant, showing implementation recognition without requiring servers to emit 418. Scope: Named constants in two mainstream standard libraries; not evidence of a default response. Confidence: high · Verified: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT 名前付き定数があるからといって、フレームワークがデフォルトで418を返すわけではありません。意味するのは、そのコードが認識されるということであり、割り当てられたHTTPの意味を持つということではありません。

SEOにおける418の意味

特別なことは何もありません――そして、知っておくべきポイントはそこです。Googleはジョークを解釈しません。2023年2月の名称付きSearch Central記事 では、429を除くすべての4xxレスポンスはSearchで同じように扱われると説明されています。つまり、以前にインデックス登録されていたURLは時間の経過とともに削除され、ページのコンテンツは利用されません。 Evidence for this claim Google's Search Central blog states that all 4xx responses except 429 receive the same treatment for Search: content isn't used and previously indexed URLs are removed over time. Scope: Google Search's dated, named statement on 4xx handling (not 418-specific). Confidence: high · Verified: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting これは一般的な4xxに関する説明であり、ティーポット専用のルールではありません――Googleの現在の一般的なクローラー・ステータスページも、418のような特殊なステータスは表の対象外であると明記しています。 Evidence for this claim Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Scope: Scope note limiting Google's generic HTTP-status guidance to common codes. Confidence: high · Verified: 2026-07-16 Google: How HTTP status codes affect Google's crawlers 実際には、インデックス登録に関して418は別の429以外の4xxと同じように動作します。ティーポット専用のランキングルール、インデックス削除までの期間、または一般的な説明を超えた復旧保証はありません。

ここで面白さが止まります。WAFやボット対策の設定の中には、418を「ブロックしたリクエスト」のレスポンスとして使うものがあります。 ログで目立ちやすく、見つけやすいという考え方です。そのルールがGooglebotに誤って適用されると、実際のページが418を返し始めます――そして、存在しないページとまったく同じように扱われます。

重要なURLについて、サーバーログやクロールレポートに418が現れたとしても、ステータスコードだけではどのレイヤーが生成したのか分かりません。アプリケーションコード、フレームワークのデフォルト、WAFやボット対策ルール、CDN、オリジンサーバーのいずれも生成でき、レスポンスがクライアントに届くまでに複数のレイヤーを通過することもあります。各レイヤーで設定、レスポンスヘッダー、リクエストパスのログを確認して実際の発生元を特定し、インデックス登録可能なURLに対するほかの望ましくない4xxと同じように修正してください。

次の最小診断手順を使ってください。

1. 対象URLの生のステータスとレスポンスヘッダーを取得します。
2. 同じリクエストパスと時刻について、アプリケーション、WAF、CDN、オリジンの各ログを比較します。
3. 418 を返しているレイヤーを修正し、その後、生のリクエストとクローラーテストを繰り返します。

このサイトにある418

RFCに敬意を表して、このサイトの /coffee はエッジから 実際の418 を、短くずんぐりした形で返します。このページは、そのイースターエッグに正式な説明を与えるため、そしてhttp-status-codesクラスターが人々を実際に笑顔にするステータスコードを扱えるようにするために存在します。

予期しない418を見つけるツール

• Bulk HTTP Status Code Checker: URLの集合をスキャンして418レスポンスを探し、意図したイースターエッグと、WAFやボット対策ルールによってブロックされた実ページを区別します。
• HTTP Header Checker: CDNとセキュリティのヘッダーを調べ、どのレイヤーがレスポンスを生成したかの手がかりを探します。
• ブラウザーのDevTools Networkパネル: 表示されるエラーページのテキストに頼らず、リクエストの生のステータスを確認します。
• curl: curl -i https://example.com/path を実行して、ログイン済みのブラウザーセッションなしでステータス、ヘッダー、レスポンスボディを取得します。
• CDN/WAFのセキュリティイベント: インデックス登録されるべきページに418が現れたら、変更する前にリクエスト時刻とURLを、発火したルールと照合します。

• 418 I'm a teapot は RFC 2324 (HTCPCP) に由来する1998年のエイプリルフールRFCで、ティーポットにコーヒーを淹れるよう求めたことを示します。RFC 7168は2014年に、お茶を淹れる家電向けにこのコードを再訪しました。
• 「未割り当て」ではありません。 RFC 9110 は418を正式に 予約 しており、IANAのレジストリでは (Unused) と記載されています――誰も申請しなかったステータスではなく、インターネットが残すために争ったステータスです。2017年にこのコードを取り戻そうとした試みは、「Save 418」キャンペーンの後に放棄されました。
• GoとPythonはどちらも名前付きの418定数を公開しています。ほかのフレームワークやプラットフォームも、Googleの google.com/teapot を含め、イースターエッグとして実装しています――ただし、定数があるからといってフレームワークがデフォルトで418を返すわけではありません。
• SEOへの影響: 2023年2月の名称付きGoogle Search Central記事は、429以外のすべての4xxをSearchで同じように扱っています。418を返すURLは、404と同じくインデックス登録されません。Googleの現在の一般的なクローラー・ステータスページでは、418のような特殊なコードは対象外です。
• 実務上のリスク: 予期しない418は、アプリ、フレームワークのデフォルト、WAFやボット対策ルール、CDN、オリジンのいずれからも発生し得ます。修正する前に各レイヤーのヘッダーとログを確認し、発生元を特定してください。
• このサイトは /coffee で本物の418を返します。

変更履歴