HTTPメソッドの使い分け — GET・POST・PUT・DELETEで何が変わるか
バイブコーディング入門 — 第7回
前回までのおさらいと、今回のテーマ
前回（第6回）では、DevTools（開発者ツール）のNetworkタブを使って、ブラウザとサーバーの間で行われている通信を自分の目で確認する方法を学んだ。ステータスコード（200は成功、404は見つからない、500はサーバーエラー）を見れば通信の結果が分かるという話だった。
Networkタブを見ていると、各通信の「Method」という列に GET や POST という文字が表示されていることに気づいた方もいるかもしれない。これがHTTPメソッドだ。
第5回でCRUD（作成・読み取り・更新・削除）を紹介したとき、「GET は読み取り、POST は作成」と軽く触れた。今回はこのHTTPメソッドをもう少し深掘りする。
HTTPメソッドは、サーバーに送る手紙に書く「用件」のようなものだ。同じ宛先（URL）に手紙を送るとしても、「見せてください」と書くのか「新しく作ってください」と書くのかで、サーバーの対応はまったく変わる。この「用件の書き方」がHTTPメソッドだ。
バイブコーディングで「商品一覧を表示する機能」と「商品を登録する機能」をAIに作ってもらうとき、裏側では異なるHTTPメソッドが使われている。この仕組みを知っておくと、AIに「GETで取得しているはずなのにデータが来ません」「POSTで送信すると500エラーが出ます」と的確に伝えられるようになる。
4つのHTTPメソッドと「手紙の用件」
Webの世界で使われるHTTPメソッドは実はもっとたくさんあるが、日常的に使うのは4つだ。GET、POST、PUT、DELETEの4つを覚えておけば、ほとんどの場面に対応できる。
第5回で紹介したCRUD（Create、Read、Update、Delete）と1対1で対応している。
- GET → Read（読み取り）: データを見せてもらう
- POST → Create（作成）: 新しいデータを作ってもらう
- PUT → Update（更新）: 既存のデータを書き換えてもらう
- DELETE → Delete（削除）: データを消してもらう
もう1つ、PATCH（パッチ）というメソッドもよく使われる。PUTが「データを丸ごと書き換える」のに対して、PATCHは「一部だけ書き換える」という意味だ。たとえば、ユーザー情報のうち名前だけを変えたいならPATCH、名前も住所もメールも全部まとめて送り直すならPUTを使う。ただし、実際のアプリではPUTとPATCHを厳密に区別しないことも多い。
ここからは、4つのメソッドそれぞれを具体的な場面で見ていこう。
GET — 「見せてください」
GETは最もよく使うメソッドだ。ブラウザでWebサイトを開くたびに、裏側ではGETリクエストが飛んでいる。
どんなときに使われるか
- ページを表示するとき
- 商品一覧を読み込むとき
- ユーザーのプロフィールを表示するとき
- 検索結果を取得するとき
要するに「何かを見る」操作はすべてGETだ。
具体例: タスク管理アプリ
バイブコーディングでタスク管理アプリを作ったとする。画面を開くと、タスクの一覧が表示される。このとき裏側では次のような通信が行われている。
リクエスト: GET /api/tasks
レスポンス: [ { "id": 1, "title": "企画書を提出する", "done": false }, { "id": 2, "title": "会議室を予約する", "done": true }, { "id": 3, "title": "見積書を作成する", "done": false } ]
ブラウザが「/api/tasks のデータを見せてください」という手紙（GETリクエスト）をサーバーに送り、サーバーがタスクの一覧をJSON（ジェイソン）形式で返している。JSONとは、データを受け渡しするときに使う書き方のルールだ。
特定のタスク1つだけを見たいときは、URLにIDを含める。
リクエスト: GET /api/tasks/1
レスポンス: { "id": 1, "title": "企画書を提出する", "done": false, "due_date": "2026-04-20" }
GETの特徴: 「見るだけ」で安全
GETには大事な特徴が1つある。「サーバー側のデータを変えない」ということだ。GETは見るだけ。何回GETしても、データは変わらない。
だから、ブラウザの「戻る」ボタンを押してページを再表示しても問題が起きない。GETリクエストがもう一度送られるだけで、データが二重に作られたり消えたりすることはない。
もう1つ、GETの情報はすべてURLに含まれる。第4回で学んだクエリパラメータがその手段だ。
/api/tasks?status=done&sort=date
このURLの中に「完了済みのタスク」「日付順」という情報が入っている。URLを見れば、何を要求しているかが分かる。
DevToolsでの見え方
前回学んだDevToolsのNetworkタブを開いて、任意のWebサイトにアクセスすると、Method列に「GET」と表示されている行がたくさん見つかるはずだ。ページを表示するだけで、HTMLファイル、CSSファイル、画像ファイル、APIのデータ — すべてGETで取得されている。
POST — 「新しく作ってください」
POSTは、サーバーに新しいデータを送って作成してもらうメソッドだ。
どんなときに使われるか
- 新しいアカウントを登録するとき
- 新しいタスクを追加するとき
- お問い合わせフォームを送信するとき
- ファイルをアップロードするとき
「何かを新しく作る」操作はPOSTだ。
具体例: タスクを追加する
タスク管理アプリで「新しいタスクを追加」ボタンを押して「報告書を印刷する」と入力して保存する。このとき裏側では次のような通信が行われている。
リクエスト: POST /api/tasks 送信データ: { "title": "報告書を印刷する" }
レスポンス: { "id": 4, "title": "報告書を印刷する", "done": false }
ブラウザが「/api/tasks に新しいデータを作ってください」という手紙（POSTリクエスト）を、作りたいデータの中身と一緒にサーバーに送っている。サーバーは新しいタスク（ID: 4）を作成して、「作りました」という返事と一緒に作成されたデータを返している。
GETとPOSTの決定的な違い
GETは「見るだけ」だったが、POSTは「サーバー側のデータを変える」。新しいデータが作られる。だから、POSTは何回も送ると、そのたびに新しいデータが作られてしまう。
ネットショッピングで「注文する」ボタンを連打すると、同じ商品が何個も注文されてしまう — これはPOSTリクエストが何回も送られるからだ。多くのショッピングサイトでは、ボタンを押した直後にボタンを無効にして二重注文を防いでいる。
POSTはリクエストに「荷物」を持っている
GETは「見せてください」と書いた手紙だけを送る。手ぶらで訪問するようなものだ。
POSTは「作ってください」という手紙と一緒に、作りたいデータ（荷物）も送る。この荷物のことをリクエストボディ（request body、リクエストの本文）と呼ぶ。
DevToolsのNetworkタブでPOSTリクエストをクリックすると、「Payload」（ペイロード）または「Request Body」というタブに、送信したデータの中身が表示される。エラーが起きたとき「何を送ったか」を確認するのに使える。
また、POSTの情報はURLには含まれない。GETは情報がURLに入るので、ブラウザの履歴やサーバーのログに残る。パスワードのような機密情報はGETではなくPOSTで送る理由がここにある。
PUT — 「書き換えてください」
PUTは、既存のデータを更新するメソッドだ。
どんなときに使われるか
- タスクの内容を編集するとき
- ユーザーのプロフィールを更新するとき
- 設定画面で変更を保存するとき
「すでにあるものを変える」操作はPUTだ。
具体例: タスクを完了にする
タスク管理アプリで「企画書を提出する」のチェックボックスをクリックして、完了状態にする。このとき裏側では次のような通信が行われている。
リクエスト: PUT /api/tasks/1 送信データ: { "title": "企画書を提出する", "done": true }
レスポンス: { "id": 1, "title": "企画書を提出する", "done": true }
「/api/tasks/1（IDが1のタスク）を書き換えてください」という手紙と、書き換え後のデータをサーバーに送っている。URLにIDが含まれているのがポイントだ。「どのデータを」「どう変えるか」の両方を伝えている。
POSTとPUTの見分け方
POSTが「新しく作る」のに対して、PUTは「既にあるものを上書きする」。URLを見れば区別がつく。
- POST /api/tasks → IDなし。「新しいタスクを1つ作って」
- PUT /api/tasks/1 → IDあり。「ID 1のタスクを書き換えて」
まだ存在しないものを作るPOSTにはIDがなく、既に存在するものを指定して変えるPUTにはIDがある。
PUTのもう1つの特徴は、「同じリクエストを何回送っても結果が同じ」ことだ。「タイトルを『企画書を提出する』、完了をtrue にする」というPUTリクエストを5回送っても、データは同じ状態になるだけだ。5つのタスクが作られることはない。
DELETE — 「消してください」
DELETEは、その名の通りデータを削除するメソッドだ。
どんなときに使われるか
- タスクを削除するとき
- アカウントを退会するとき
- アップロードしたファイルを消すとき
具体例: タスクを削除する
タスク管理アプリで「会議室を予約する」タスクのゴミ箱アイコンをクリックする。
リクエスト: DELETE /api/tasks/2
レスポンス: （ステータスコード 204: 成功したが返すデータなし）
「/api/tasks/2（IDが2のタスク）を消してください」という手紙を送っている。DELETEは「消す」だけなので、送るデータ（荷物）は基本的にない。URLでどれを消すかを指定するだけだ。
レスポンスのステータスコード 204 は「成功したが、返すデータはない」という意味だ。消したのだから、返すものがないのは当然だ。200（成功）が返ることもある。
4つのメソッドを並べて比較する
ここまでの内容を整理する。
GETは「見せてください」。データを取得する。URLだけを送る。サーバー側のデータは変わらない。
POSTは「新しく作ってください」。データを新規作成する。URLとデータ（リクエストボディ）を送る。サーバー側に新しいデータが増える。
PUTは「書き換えてください」。既存データを更新する。URLとデータを送る。サーバー側のデータが変わる。
DELETEは「消してください」。データを削除する。URLだけを送る。サーバー側のデータが減る。
普段の仕事で使う書類棚に置き換えてみるとよい。
- GET: 棚から書類を取り出して読む（書類は棚に残る）
- POST: 新しい書類を作って棚に入れる
- PUT: 棚にある書類を取り出して、内容を書き直して戻す
- DELETE: 棚から書類を取り出してシュレッダーにかける
DevToolsで確認してみよう
前回学んだDevToolsを使って、実際にHTTPメソッドが使い分けられている様子を確認してみよう。
ステップ1: 準備
バイブコーディングで作ったアプリ（タスク管理アプリなど）を開く。まだアプリがない方は、普段使っているWebサービス（Trello、Notion、Googleカレンダーなど）でも確認できる。
ステップ2: DevToolsを開いてフィルターをかける
F12キーでDevToolsを開き、Networkタブを選ぶ。上部のフィルターから「Fetch/XHR」を選んでおく。これでAPIとの通信だけに絞り込める。
ステップ3: 操作してメソッドを確認する
アプリで次の操作を順番にやってみる。それぞれの操作の後に、Networkタブに表示されたMethod列を確認する。
- ページを開く（または再読み込み）→ GETが表示される
- 新しいデータを追加する → POSTが表示される
- 既存のデータを編集する → PUTまたはPATCHが表示される
- データを削除する → DELETEが表示される
Method列が表示されていない場合は、列のヘッダー部分を右クリックして「Method」にチェックを入れると表示される。
実際に手を動かしてみると「あ、本当にメソッドが使い分けられているんだ」と実感できるはずだ。
AIにエラーを伝えるときの使い方
HTTPメソッドを知っていると、エラーをAIに伝えるときの精度が上がる。
よくないエラー報告
「タスクが追加できません」
これだけだと、AIはどこから調べればいいか分からない。画面の問題か、通信の問題か、サーバーの問題か、データベースの問題か。選択肢が多すぎる。
よいエラー報告
「新しいタスクを追加しようとすると、POST /api/tasks が500エラーを返します。DevToolsのResponseタブに 'column title cannot be null' と表示されています」
これなら、AIは即座に「POSTで送っているデータにtitleフィールドが含まれていない」か「フロントエンドからサーバーへのデータの受け渡しに問題がある」と判断できる。
HTTPメソッドを含めてエラーを報告するだけで、原因特定までの時間が大幅に短くなる。前回紹介したエラー報告テンプレートと組み合わせると、次のようになる。
（症状）新しいタスクを追加しようとすると、保存されない。 （DevToolsの情報）POST /api/tasks が500エラーを返している。 （レスポンスの内容）'column title cannot be null' というメッセージ。
よくある不安と答え
メソッドを間違えたらデータが壊れるか
バイブコーディングでは、AIがHTTPメソッドを適切に選んでコードを書いてくれるので、あなたが直接メソッドを指定する場面はほとんどない。この記事の知識は「AIが書いたコードが正しく動いているかをDevToolsで確認する」ためのものだ。もしDevToolsで、追加なのにGETが使われていたり、表示なのにDELETEが使われていたりしたら、AIに指摘できる。
GETとPOST以外は覚えなくていいか
実際のところ、GETとPOSTだけでアプリを作ることも技術的には可能だ。ただ、PUTとDELETEを正しく使い分けたほうが、コードの意味が読み取りやすくなる。AIが書いたコードでも4つのメソッドが使い分けられているのが普通なので、4つとも知っておくほうがDevToolsでの確認がスムーズだ。
PUTとPATCHの違いは気にしなくていいか
実務上はあまり気にしなくて大丈夫だ。どちらも「既存データを更新する」という意味で、動作も似ている。AIが書いたコードでPUTとPATCHのどちらが使われていても、「更新しているんだな」と理解できれば十分だ。
まとめ
HTTPメソッドは、サーバーに送る手紙の「用件」だ。GET（見せてください）、POST（新しく作ってください）、PUT（書き換えてください）、DELETE（消してください）の4つを覚えておけば、Webアプリの通信の大部分が理解できる。DevToolsのNetworkタブでMethod列を見れば、どの操作がどのメソッドで行われているかを確認できる。エラーをAIに伝えるとき、メソッド名を含めるだけで原因特定が格段に速くなる。
次回は「ステータスコードを深掘りする — 404、500、401、403で何が起きているか」。第6回で触れたステータスコードを、もう少し詳しく見ていく。
参考リファレンス
- MDN Web Docs「HTTPリクエストメソッド」— Mozilla が提供するHTTPメソッドの技術リファレンス
- 前回: 第6回「HTTPリクエストとレスポンスを覗く — DevToolsで通信の中身を見る」（/articles/vc-006）
- 次回: 第8回「ステータスコードを深掘りする — 404、500、401、403で何が起きているか」（/articles/vc-008）
- バイブコーディング入門 カリキュラム（/vibe-coding）
