ステータスコード405 Method Not Allowedとは？「間違ったツール」エラー

壁に絵を掛けようとしています。ドライバーは持っているものの、本当に必要なのはハンマーです。どんなに頑張っても、そのドライバーでは釘を壁に打ち込むことはできません。使用しているツールが、達成しようとしているタスクに合っていないのです。

これは、HTTPの最も具体的で役立つエラーコードの1つである405 Method Not Allowedが示す状況そのものです。

より一般的な404 Not Found（「お探しのものが見つかりません」）や400 Bad Request（「おっしゃっていることが理解できません」）とは異なり、405エラーは信じられないほど正確です。これは、「お探しのリソースは見つかりましたが、それとやり取りするために間違ったHTTPメソッドを使用しています。」と伝えています。

これは、サーバーが「/api/usersが何であるかは知っていますが、それをDELETEすることはできません。代わりにGETを使ってみてください。」とあなたに伝える方法です。

RESTful APIを扱う開発者であれば、405ステータスコードを理解することは、APIを正しく構築し、利用するために不可欠です。

この詳細なブログ記事では、405 Method Not Allowedステータスについて知っておくべきことすべて、つまりその意味、発生理由、一般的なシナリオ、修正方法、そして適切に処理するためのベストプラクティスについて探求します。

💡

このエラーを効率的にテストおよびデバッグしたい場合は、Apidogを無料でダウンロードしてください。Apidogは、APIとのやり取り、405のようなエラーの発見と修正、開発ワークフローの合理化を容易にするオールインワンのAPIテストおよびドキュメントツールです。

button

それでは、HTTP 405 Method Not Allowedステータスコードの目的、仕組み、および実用的な意味について見ていきましょう。

問題：HTTPメソッドとRESTfulデザイン

405を理解するためには、RESTful APIがどのように機能するかを簡単に再確認する必要があります。RESTfulデザインでは、同じURLでも使用するHTTPメソッド（動詞）によって動作が異なります。

GET /api/users - ユーザーのリストを取得する
POST /api/users - 新しいユーザーを作成する
PUT /api/users/123 - ユーザー123を更新する（完全な置換）
PATCH /api/users/123 - ユーザー123を部分的に更新する
DELETE /api/users/123 - ユーザー123を削除する

405エラーは、サーバーがその特定のエンドポイントに実装していないメソッドを使用しようとしたときに発生します。たとえば、/api/users/123（通常はGET、PUT、PATCH、DELETEのみをサポート）に対してPOSTしようとすると、405が返される可能性が高いです。

HTTP 405 Method Not Allowedは実際に何を意味するのか？

405 Method Not Allowedステータスコードは、サーバーがターゲットリソース（リクエストしたURL）の存在を認識しているものの、リクエストで使用されたHTTPメソッドをサポートしていないことを示します。

適切な405応答には、1つの重要な要件があります。それは、リクエストされたリソースでサポートされているHTTPメソッドをリストするAllowヘッダーを含める必要があることです。

適切な405応答は次のようになります。

HTTP/1.1 405 Method Not AllowedAllow: GET, HEAD, OPTIONSContent-Type: application/json
{
  "error": "Method Not Allowed",
  "message": "POST method is not supported for this endpoint."
}

重要な要素を分解してみましょう。

Allow: GET, HEAD, OPTIONS: これが最も重要な部分です。このヘッダーは、クライアントに許可されているメソッドを正確に伝えます。サーバーが「ここではハンマーは使えませんが、代わりにこれら3つのツールは使えます。」と言っているようなものです。

簡単に言えば、クライアントはGET、POST、PUT、DELETEなどの有効なHTTPメソッドを送信しましたが、サーバーはリクエストされたURLまたはエンドポイントでその特定のメソッドを許可していません。

405エラーはなぜ発生するのか？

405は、HTTPリクエストで使用されたメソッドがリソースに対して許可されていない場合に発生します。一般的な原因は次のとおりです。

POSTのみをサポートするエンドポイントでGETを呼び出す。
DELETEのみがサポートされている場所でPUTを使用する。
OPTIONSリクエストを許可しないリソースに送信する。
サーバーのルーティングまたはHTTPメソッドハンドラーの設定ミス。
REST APIの誤った使用または古いドキュメント。

根本原因を理解することで、問題を効率的に解決できます。

サーバーが404ではなく405を返す理由

なぜ404 Not Foundを返さないのか、疑問に思うかもしれません。

404はリソースがまったく見つからないことを意味しますが、405はリソースは存在するものの、そのメソッドでは利用できないことを意味します。

この違いは開発者にとって重要です。なぜなら、これは次のことを伝えているからです。

あなたは正しい場所にいます。
あなたは間違ったツールを使っているだけです。

仕組み：具体的な例

製品情報を提供する読み取り専用のAPIエンドポイントを想像してみましょう。

有効なリクエスト：

GET /api/products/123 HTTP/1.1Host: api.example.com

サーバー応答： 製品データとともに200 OK。

無効なリクエスト：

クライアントが誤ってPUTを使用して製品を更新しようとします。

PUT /api/products/123 HTTP/1.1Host: api.example.comContent-Type: application/json
{"name": "New Product Name"}

サーバーの405応答：

HTTP/1.1 405 Method Not AllowedAllow: GET, HEADContent-Type: application/json
{
  "error": "Method Not Allowed",
  "message": "The PUT method is not supported for this resource."
}

Allow: GET, HEADヘッダーは、これが読み取り専用のエンドポイントであることをクライアントに明確に伝えます。クライアントは、何が間違っていたのか、そしてどのように修正すればよいのかを正確に理解できます。

Allowヘッダーが非常に重要な理由

Allowヘッダーは、405をイライラするエラーから役立つ会話に変えます。これがないと、クライアントは推測するしかありません。

Allowヘッダーがある場合： 「ここではPUTできないが、GETまたはHEADはできる。」
Allowヘッダーがない場合： 「ここではPUTできない。¯\_(ツ)_/¯ 何ができるか見つけ出すのは頑張って！」

これが、HTTP仕様がサーバーに405応答にAllowヘッダーを含めることを義務付けている理由です。これにより、このコードは単にイライラさせるだけでなく、真に役立つものになります。

405応答はどのようなものか？

サーバーは、許可されているHTTPメソッドを示すAllowヘッダーとともに405ステータスで応答します。RFC 7231 (HTTP/1.1仕様) は、405ステータスコードが送信される場合、サーバーはリソースに対して許可されているHTTPメソッドをリストするAllowヘッダーを含めなければならないと指示しています。

応答例：

textHTTP/1.1 405 Method Not Allowed Allow: GET, HEAD, OPTIONS Content-Type: text/html
<html> <body> <h1>405 Method Not Allowed</h1> <p>The requested method POST is not supported for this resource.</p> </body> </html>

Allowヘッダーは、クライアントにどのメソッドが受け入れられるかを通知し、修正を可能にするため、非常に重要です。

このようにして、クライアントはどのメソッドがサポートされているかを知り、それに応じてリクエストを調整できます。

405エラーを引き起こす一般的なシナリオ

1. 読み取り専用エンドポイント

上記の例のように、一部のリソースは意図的に読み取り専用です。GETで取得することはできますが、PUT、PATCH、またはDELETEで変更することはできません。

2. アクションに対するメソッドの誤り

これはおそらく最も一般的な原因です。開発者がどのアクションにどのメソッドを使用すべきかを混同しています。

リソースを作成するためにGETを使用する（POSTであるべき）
リソースを更新するためにPOSTを使用する（PUTまたはPATCHであるべき）
/api/usersのようなコレクションURLでDELETEを使用する（/api/users/123のような特定のリソースであるべき）

3. メソッドの実装不足

API設計者が、エンドポイントに対して特定のメソッドを単に実装していない場合があります。たとえば、あるエンドポイントがGETとPOSTはサポートするが、PUTやDELETEはサポートしない場合があります。

4. Webアプリケーションファイアウォール（WAF）とセキュリティルール

場合によっては、セキュリティ設定が意図的に特定のメソッドをブロックすることがあります。たとえば、WAFがセキュリティ上の理由から特定のパスでPUT、PATCH、DELETEメソッドをブロックし、405を返すことがあります。

405とその他の4xxエラー：違いを知る

405を他のクライアントエラーコードと区別することが重要です。

405 Method Not Allowed vs. 404 Not Found:

405は「このURLは存在するが、そのメソッドでは利用できない。」を意味します。

404は「このURLはどのメソッドでも存在しない。」を意味します。

405 Method Not Allowed vs. 501 Not Implemented:

405は「あなたが何をしたいかは知っているが、この特定のリソースに対しては許可しない。」（クライアントエラー）

501は「このHTTPメソッドを、どのリソースに対してもどのように処理すればよいかまったく知らない。」（サーバーエラー）

405 Method Not Allowed vs. 403 Forbidden:

405は「この操作は誰にも利用できない。」（メソッドの制限）

403は「この操作は利用できるが、現在の権限を持つあなたには利用できない。」（認証の制限）

405が表示される一般的なシナリオ

RESTful API: GETまたはPOSTのみをサポートするエンドポイントにPUTしようとする。
Webフォーム: POSTを期待するエンドポイントにGETメソッドでフォームを送信する。
誤って設定されたルート: 特定のメソッドを適切に処理しないサーバールート。
ミドルウェアの問題: 特定のメソッドをブロックまたはフィルタリングするセキュリティソフトウェア。
静的リソース: 静的画像またはファイルURLでPOSTをリクエストする。

クライアントは405 Method Not Allowedをどのように処理すべきか

クライアントが405応答を受け取った場合、次のことを行う必要があります。

サポートされているHTTPメソッドを特定するためにAllowヘッダーを確認する。
許可されたメソッドを使用するようにリクエストを変更する。
それに応じてリクエストを再試行する。
ユーザーインターフェースまたはワークフローでエラーを適切に処理する。
サポートされていないアクションについてユーザーに明確に通知する。

開発者が405エラーを修正する方法

サーバーのルーティングと設定を確認する: すべての予期されるHTTPメソッドをルートが処理していることを確認する。
APIドキュメントを確認する: 正しいHTTPメソッドの使用法を確認する。
メソッドハンドラーを実装する: 許可されているすべてのメソッドに対してハンドラーを明示的に定義する。
適切なAllowヘッダーで応答する: クライアントの使いやすさを向上させる。
クライアントリクエストを検証する: クライアントアプリで誤ったメソッドの使用を早期に検出する。
405エラーをログに記録する: 繰り返しの問題を監視し、修正するため。

HTTPメソッドと許可された使用法の例

HTTPメソッド	典型的な使用例
GET	リソースまたはデータを取得する
POST	リソースを作成するか、アクションを実行する
PUT	リソースを更新または置換する
DELETE	リソースを削除する
PATCH	リソースを部分的に更新する
OPTIONS	サポートされているメソッドを問い合わせる

メソッドとリソースの機能の不一致が405を引き起こします。

Apidogで405応答をテストする

サポートされていないメソッドに対してAPIが正しく405を返すことをテストすることは、堅牢なAPI開発の証です。Apidogは、このプロセスを信じられないほど簡単にします。

Apidogを使用すると、次のことができます。

すべてのメソッドを簡単にテスト: 任意のエンドポイントURLを取得し、ワンクリックでGET、POST、PUT、PATCH、DELETEメソッドを簡単に切り替えて、どのメソッドがサポートされているかを確認できます。
Allowヘッダーを検証: 405応答を受け取ると、Apidogは応答の詳細にAllowヘッダーを明確に表示します。正しいメソッドのリストが含まれていることを確認できます。
メソッドテストを自動化: サポートされていないメソッドが適切なAllowヘッダーとともに405を返し、サポートされているメソッドが予期される2xxステータスを返すことを自動的に検証するテストスイートを作成します。
クライアント側コードをデバッグ: 405を受け取るクライアントアプリケーションを構築している場合、Apidogを使用して正確なリクエストと応答を再現し、クライアントコードの問題を理解して修正するのに役立ちます。
APIの動作をドキュメント化: Apidogを使用して、各エンドポイントでどのメソッドがサポートされているかをドキュメント化し、APIを利用する他の開発者にこの情報を明確に伝えます。

button

推測する代わりに、数秒で明確になります。Apidogを無料でダウンロードして、HTTPエラーのトラブルシューティングを簡単にしましょう。

405を処理するためのベストプラクティス

API開発者向け（サーバー側）：

405応答には常にAllowヘッダーを含めること。これは、準拠したHTTPサーバーにとって必須です。
API全体でメソッドの使用法を一貫させること。ほとんどのコレクションエンドポイントがGETとPOSTをサポートしている場合、正当な理由なしにGETのみをサポートするエンドポイントを持たないようにしましょう。
特に他の開発者が利用するAPIの場合、応答本文に役立つエラーメッセージを提供すること。
OPTIONSの使用を検討する: エンドポイントにOPTIONSメソッドを実装し、同じAllowヘッダーを返すようにします。これにより、クライアントはエラーをトリガーすることなく、サポートされているメソッドを発見できます。

APIコンシューマー向け（クライアント側）：

405を受け取ったら、Allowヘッダーを確認すること。何ができるかを正確に教えてくれます。
他の操作を試す前に、OPTIONSメソッドを使用してサポートされているメソッドを発見すること。
コード内で405エラーを適切に処理すること。致命的なエラーとしてではなく、リクエストを修正する方法のガイダンスとして扱います。

OPTIONSメソッドの役割

OPTIONSメソッドは、405応答の積極的な従兄弟です。操作を試して拒否される代わりに、クライアントはまずサーバーにどのメソッドがサポートされているかを尋ねることができます。

リクエスト：

OPTIONS /api/products/123 HTTP/1.1Host: api.example.com

応答：

HTTP/1.1 200 OKAllow: GET, HEAD, OPTIONS

これは、エラーをトリガーすることなくAPIの機能を検出する、はるかに洗練された方法です。

一般的な405問題のトラブルシューティング

ルート定義とHTTP動詞ハンドラーを再確認する。
特定のメソッドをブロックする可能性のあるプロキシまたはファイアウォールの設定を確認する。
クライアントリクエストのスペルミスや不一致を探す。
Apidogのようなデバッグツールを使用して、完全なリクエスト/応答サイクルをキャプチャする。
環境間でテストして、本番環境固有の問題を発見する。

405のセキュリティ上の影響

405にはセキュリティ上の影響もあります。

安全でないメソッド（TRACEなど）を無効にすることは、攻撃を防ぐのに役立ちます。
Allowヘッダーで多くの情報を開示しすぎると、攻撃者にヒントを与える可能性があります。
一貫した405処理は、サーバーの詳細の漏洩を防ぎます。

結論：フラストレーションから明確さへ

405 Method Not Allowedステータスコードは、単なるランダムな障害ではありません。それは、リソースは存在するが、使用したメソッドを受け入れないという貴重なシグナルです。HTTP 405 Method Not Allowedステータスコードは、優れたAPI設計が明確で実用的なフィードバックをどのように提供するかの完璧な例です。それは、混乱を招く行き止まりになりかねないものを、「この道は行けませんが、ここが開いている道です」と示す役立つ道しるべに変えます。

API開発者にとって、正確なAllowヘッダーを含む適切な405応答を実装することは、プロフェッショナリズムと細部への配慮の証です。APIコンシューマーにとって、405エラーの読み方と対応方法を理解することは、堅牢で自己修正可能なアプリケーションを構築するための鍵となります。

したがって、次に405エラーに遭遇しても、イライラしないでください。Allowヘッダーを読んでください。それはサーバーがあなたの成功を助けようとしているのです。そして、自分でAPIを構築またはテストしている場合、Apidogのようなツールは、メソッドの使用が正しく、エラー処理が適切に役立つことを保証する力をもたらします。

button