HTTPステータスコード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エラーは、サーバーがその特定のエンドポイントに対して実装していないメソッドを使用しようとしたときに発生します。例えば、通常GET、PUT、PATCH、DELETEのみをサポートする/api/users/123に対して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 対 404 Not Found:

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

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

405 Method Not Allowed 対 501 Not Implemented:

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

501は「このHTTPメソッドを、いかなるリソースに対しても全く処理する方法を知らない。」（サーバーエラー）を意味します。

405 Method Not Allowed 対 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