【初心者向け】curl で API を完全攻略！POST/PUT/DELETEと認証の基礎から実践まで

「Webサイトのデータ取得は curl でできるようになったけど、APIを叩いてデータを登録したり、更新したりするにはどうすればいいんだろう？」

APIのドキュメントに載っている curl コマンドをコピペしてみるものの、400 Bad Request や 401 Unauthorized といったエラーに遭遇し、「何が間違っているんだろう…？」と頭を抱えてしまう。これは、多くの開発者が一度は通る道です。

ご安心ください。この記事を読み終える頃には、あなたは curl を使ってサーバーと自由に対話し、データを自在に操るための基本的な武器を手に入れています。GETリクエストの先にある、より動的なWebの世界へ、一緒に踏み出しましょう。

この記事であなたが得られること

• curl を使ってデータを新規作成（POST）、更新（PUT）、削除（DELETE）する方法
• APIのテストや操作に不可欠なJSONデータの送信テクニック
• 認証が必要なAPIを突破するための「Bearerトークン」の扱い方

[NOTE]
curlコマンドのより詳細な情報や最新の仕様については、curlの公式ドキュメントをご参照ください。

対象となる読者

• curl でGETリクエストは使ったことがあるが、他のメソッドは未経験の方
• APIのドキュメントを読んで、curl でのテスト方法を理解したい方
• PostmanなどのGUIツールを立ち上げる前に、コマンドラインで素早くAPIを試したい開発者
• シェルスクリプトでの定型作業の自動化に興味があるインフラエンジニア

動作検証環境

この記事で紹介するcurlコマンドの動作は、以下の環境で検証しています。

• OS: Ubuntu 24.04.3 LTS
• ハードウェア: VAIO VJP131

目次

• APIと対話するHTTPメソッドの基本：GETだけじゃない！
• データ作成の要！curlでPOSTリクエストを送信する
  • JSONデータをリクエストボディに含める方法
  • サーバーに「JSONです」と伝えるContent-Typeヘッダー
• APIの門番を突破！Bearerトークンによる認証
  • Authorizationヘッダーで認証情報を渡す
  • 【セキュリティ対策】トークンを安全に扱うベストプラクティス
• データの更新と削除：PUTとDELETEリクエスト
• API操作でよく遭遇するエラーと対処法
• curlのその他の便利オプション
• よくある質問 (FAQ)
• まとめ：API操作の扉を開いたあなたへ、次のステップは？

APIと対話するHTTPメソッドの基本：GETだけじゃない！

Webアプリケーションの裏側では、さまざまな目的でHTTPメソッドが使い分けられています。

Webアプリケーションでは、単に情報を「見る」だけでなく、新しい情報を「登録」したり、既存の情報を「更新」したり、「削除」したりする操作が頻繁に行われます。
例えば、ECサイトで商品をカートに入れたり、SNSで新しい投稿をしたり、プロフィール情報を変更したり、不要なアカウントを削除したりするような場面です。

これらの操作を実現するために、HTTPメソッドが使い分けられています。特にAPI操作においては、以下の4つのメソッドが基本となります。これは、データのライフサイクルを管理する「CRUD」という考え方に対応しています。

[!NOTE]
HTTPメソッドのより詳細な定義については、RFC 9110 (HTTP Semantics) を参照してください。

• Create (作成) → POST
• Read (読み取り) → GET
• Update (更新) → PUT
• Delete (削除) → DELETE

この関係性を理解することが、APIと自在に対話するための第一歩です。

[!NOTE]
厳密には、PUT はリソース全体の置換、部分的な更新には PATCH を使うなど、メソッドにはより詳細な意味合いがあります。今の時点では、まずはこの4つの基本をマスターすることに集中しましょう。

データ作成の要！curlでPOSTリクエストを送信する

それでは、実際に curl を使ってデータを作成してみましょう。ここでは、ダミーのAPIを提供してくれる JSONPlaceholder というサービスを利用します。

新しいブログ記事を投稿する、というシナリオで考えてみましょう。

JSONデータをリクエストボディに含める方法

curl でPOSTリクエストのボディ（本体）にデータを含めるには、-d (または --data) オプションを使います。

# 新しい投稿を作成する
$ curl -d '{"title": "新しい投稿", "body": "これはcurlからのテストです。", "userId": 1}' https://jsonplaceholder.typicode.com/posts

# レスポンスデータ
{  
  "{\"title\": \"新しい投稿\", \"body\": \"これはcurlからのテストです。\", \"userId\": 1}": "",  
  "id": 101  
}

# 新しい投稿を作成する
$ curl -d '{"title": "新しい投稿", "body": "これはcurlからのテストです。", "userId": 1}' https://jsonplaceholder.typicode.com/posts

# レスポンスデータ
{  
  "{\"title\": \"新しい投稿\", \"body\": \"これはcurlからのテストです。\", \"userId\": 1}": "",  
  "id": 101  
}

成功です！サーバーは私たちが送ったデータを受け取り、新しいID 101 を採番して応答してくれました。

[著者の経験談]
curlコマンドを使い始めた頃、-d オプションのデータ全体をシングルクォート(')で囲むのを忘れ、JSONのダブルクォート(")がシェルに解釈されてしまい、" の部分でコマンドが途切れてエラーになるというミスをよく繰り返しました。特に、複雑なJSONを扱う際には、このミスに気づくまでに時間がかかり、何度も試行した記憶があります。データは一つの文字列として渡す、とテンプレート化するのがコツです。

サーバーに「JSONです」と伝えるContent-Typeヘッダー

先ほどのコマンドは上手く動きましたが、実は少し不完全です。正しくは「JSON形式のデータを送っている」ということを、サーバーに明示的に伝えるべきです。

その役割を果たすのが、HTTPヘッダーです。-H (または --header) オプションを使って、Content-Type というヘッダーに application/json を指定します。

また、-d を使うと curl はデフォルトでPOSTメソッドを選択しますが、-X POST と明示的に指定することで、より可読性の高いコマンドになります。

# Content-Typeヘッダーと-X POSTを明記した、より丁寧なPOSTリクエスト
$ curl -X POST -H "Content-Type: application/json" -d '{"title": "丁寧な投稿", "body": "ヘッダーをちゃんと指定しました。", "userId": 1}' https://jsonplaceholder.typicode.com/posts

# レスポンスデータ
{
  "title": "丁寧な投稿",
  "body": "ヘッダーをちゃんと指定しました。",
  "userId": 1,
  "id": 101
}

# Content-Typeヘッダーと-X POSTを明記した、より丁寧なPOSTリクエスト
$ curl -X POST -H "Content-Type: application/json" -d '{"title": "丁寧な投稿", "body": "ヘッダーをちゃんと指定しました。", "userId": 1}' https://jsonplaceholder.typicode.com/posts

# レスポンスデータ
{
  "title": "丁寧な投稿",
  "body": "ヘッダーをちゃんと指定しました。",
  "userId": 1,
  "id": 101
}

[TIP]
ほとんどのモダンなAPIは Content-Type ヘッダーを必須としています。APIを叩く際は、-H "Content-Type: application/json" 等のように、APIの仕様に合わせた適切なヘッダーをつけるようにしましょう。

APIの門番を突破！Bearerトークンによる認証

多くのAPIは、誰でも自由にデータを操作できないように、認証を要求します。その最も一般的な方法の一つが「Bearerトークン」です。

これは、APIへのアクセスを許可されたユーザーであることを証明するための「デジタルな身分証明書」のようなものです。このトークンを提示することで、APIはあなたが正当なリクエスト元であると認識し、安全にデータへのアクセスを許可します。

Authorizationヘッダーで認証情報を渡す

Bearerトークンは、Authorization ヘッダーを使ってサーバーに送ります。形式は Bearer <あなたのトークン> です。

# ダミーのトークンを使って認証が必要なAPIにリクエストを送る例
$ curl -X GET -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." https://api.example.com/v1/me

# ダミーのトークンを使って認証が必要なAPIにリクエストを送る例
$ curl -X GET -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." https://api.example.com/v1/me

[NOTE]
上記のコマンドは、Authorization ヘッダーの指定方法を理解するための例です。api.example.com という架空のエンドポイントを叩いているため、実際には動きません。

[著者の経験談]
Authorization: Bearer <トークン> の Bearer とトークンの間にスペースが1つ必要なことに気づかず、401 Unauthorized エラーで小1時間溶かしたことがあります。この微妙なスペースの有無が原因で認証が通らないという状況でした。些細なことかもしれませんが、API連携の現場では本当によくある話で、このようなミスを起こさないように、なるべくテンプレート化したいものです。

【セキュリティ対策】トークンを安全に扱うベストプラクティス

アクセストークンのような機密情報は、コマンドに直接書き込むのではなく、環境変数に入れておくと安全です。
export MY_API_TOKEN="eyJhbGci..." のように設定しておき、curl -H "Authorization: Bearer $MY_API_TOKEN" ... のように使うのがベストプラクティスです。

データの更新と削除：PUTとDELETEリクエスト

POSTと認証の方法をマスターすれば、データの更新（PUT）と削除（DELETE）はもう怖くありません。-X オプションでメソッドを指定し、操作対象のリソースIDをURLに含めるだけです。

PUTリクエスト (更新)

IDが 1 の投稿を更新してみましょう。

# ID:1 の投稿を更新する
$curl -X PUT -H "Content-Type: application/json" -d '{"id": 1, "title": "更新されたタイトル", "body": "内容は完全に上書きされました。", "userId": 1}' https://jsonplaceholder.typicode.com/posts/1

# レスポンスデータ
{  "id": 1,  
  "title": "更新されたタイトル",  
  "body": "内容は完全に上書きされました。",  
  "userId": 1}

# ID:1 の投稿を更新する
$curl -X PUT -H "Content-Type: application/json" -d '{"id": 1, "title": "更新されたタイトル", "body": "内容は完全に上書きされました。", "userId": 1}' https://jsonplaceholder.typicode.com/posts/1

# レスポンスデータ
{  "id": 1,  
  "title": "更新されたタイトル",  
  "body": "内容は完全に上書きされました。",  
  "userId": 1}

PUT はリソース全体を置き換える、という点に注意してください。一部だけを送ると、送らなかった項目は消えてしまうことがあります。

DELETEリクエスト (削除)

最後に、IDが 1 の投稿を削除します。DELETEリクエストにはボディは不要です。

# ID:1 の投稿を削除する
$ curl -X DELETE https://jsonplaceholder.typicode.com/posts/1

# レスポンスデータ
{}

# ID:1 の投稿を削除する
$ curl -X DELETE https://jsonplaceholder.typicode.com/posts/1

# レスポンスデータ
{}

空のオブジェクト {} が返ってくれば、削除成功の合図です。（APIの仕様によって応答は異なります）

API操作でよく遭遇するエラーと対処法

APIを操作していると、様々なエラーに遭遇します。特に初心者がよく目にするHTTPステータスコードとその対処法を理解しておきましょう。

• 400 Bad Request: リクエストの形式が不正です。JSONの構文エラー、必須パラメータの不足、不正な値などが原因です。-v オプションで詳細なリクエスト内容を確認し、APIドキュメントと照らし合わせましょう。
• 401 Unauthorized: 認証情報が不足しているか、無効です。Bearerトークンが正しいか、有効期限が切れていないか、Authorization ヘッダーの形式が正しいか（Bearer の後のスペースなど）を確認しましょう。
• 403 Forbidden: 認証は成功したが、そのユーザーにリソースへのアクセス権限がありません。APIキーやトークンに付与されている権限を確認しましょう。
• 404 Not Found: 指定したリソースが見つかりません。URLが正しいか、リソースIDが存在するかを確認しましょう。
• 500 Internal Server Error: サーバー側で何らかのエラーが発生しています。クライアント側でできることは少ないですが、リクエスト内容に問題がないか再確認し、API提供者に問い合わせる必要があるかもしれません。

curlのその他の便利オプション

APIデバッグや自動化に役立つ curl のオプションは他にもたくさんあります。

• -i, --include: レスポンスヘッダーも表示します。APIからの詳細な応答を確認する際に便利です。
• -s, --silent: プログレスメーターやエラーメッセージなど、curlの進行状況表示を抑制します。シェルスクリプトで結果だけを扱いたい場合に役立ちます。
• -o, --output <file>: レスポンスボディを指定したファイルに保存します。大きなレスポンスを扱う際に便利です。
• -L, --location: リダイレクト（HTTPステータスコード3xx）を自動的に追跡します。APIがリダイレクトを返す場合に、最終的なリソースを取得できます。
• -k, --insecure: SSL証明書の検証を無効にします。開発環境や自己署名証明書を使用している場合に一時的に利用できますが、本番環境での使用は避けましょう。

よくある質問 (FAQ)

Q1: -d と --data の違いは何ですか？
A1: 違いはありません。--data が正式名称で、-d はその短縮形（エイリアス）です。どちらを使っても機能は同じですが、シェルスクリプトなどでは可読性のために --data が好まれることもあります。

Q2: POST と PUT の使い分けがよくわかりません。
A2: POST は「新しいリソースを作成する」ために使います。リクエストを送るたびに新しいリソースが作られる可能性があります。一方、PUT は「指定したリソースを更新（置換）する」ために使います。同じリクエストを何度送っても、結果は同じ（冪等性を持つ）であるべきとされています。

Q3: 長いJSONデータをコマンドラインで扱うのが大変です。何か良い方法はありますか？
A3: JSONデータをファイルに保存し、@ を使ってそのファイルを読み込ませることができます。例えば、data.json というファイルに {"title": "..."} を保存した場合、curl -d @data.json ... のようにコマンドをスッキリさせることができます。

まとめ：API操作の扉を開いたあなたへ、次のステップは？

今回は、curl を使ってAPIと対話するための基本的なメソッド POST, PUT, DELETE を学びました。

• HTTPメソッドの使い分け: POST (作成), PUT (更新), DELETE (削除)
• データ送信: -d でリクエストボディを、-H で Content-Type などのヘッダーを指定する。
• API認証: Authorization: Bearer <トークン> ヘッダーで認証情報を渡す。

これらの知識は、APIテスト、簡単なタスクの自動化、そしてバックエンド開発者との円滑なコミュニケーションの礎となります。

さあ、今日からあなたもAPIマスターへの第一歩を踏み出しましょう！まずはこの記事で紹介した JSONPlaceholder のコマンドを、あなたのターミナルで一つずつ実行し、APIと対話する「手応え」をぜひ感じてみてください。

この記事が役に立ったら
ぜひチームに共有したり、X（旧Twitter）で感想をポストしていただけると、執筆の励みになります！あなたの小さなアクションが、日本の開発文化をより良くする大きな一歩になるかもしれません。

本記事をご利用いただくにあたって

この記事は、公開時点（2025年9月）の情報に基づき、正確な情報を提供するよう努めています。
しかし、本記事で解説するソフトウェアやサービスの仕様は日々更新されるため、記事内で紹介している画面や手順が、ご覧いただいている時点では変更されている可能性があります。
もし内容に相違がある場合は、各サービスの最新の公式ドキュメントも併せてご参照ください。本記事の情報を利用される際は、ご自身の判断と責任においてお願いいたします。