🚀 最近よく見る curl コマンドを、現場目線でちゃんと理解する

API を触る機会が増えたことで、技術ドキュメントやチャットツールのサンプルに curl コマンド が頻繁に登場するようになりました。読み方はカールと読みます。「とりあえずコピペで動かしているけど、実はよく分かっていない」という声もよく聞きます。

この記事では、curl の基本から、企業ネットワークでよく発生する SSL エラー、そして Git Bash と Windows curl の“中身の違い”まで、現場で本当に役立つポイントに絞って解説します。

🔧 curl の基本とよく使うオプション

curl は「URL を扱うためのコマンドラインツール」で、API の疎通確認やデバッグで欠かせません。

基本構文はシンプルです。

curl [オプション] URL

よく使うオプションを目的別に整理するとこうなります。

curl -v https://api.example.com/users

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Yoshinori Kajimoto"}'

curl を使っていると、企業ネットワーク特有の SSL エラーに遭遇することがあります。特に最近よく見るのがこの 2 つです。しかもGitBashであれば、うまく通ります。

Git Bash では通るのに、PowerShell や CMD の curl だけが失敗する── この現象には明確な理由があります。

同じ curl に見えて、実は SSL の仕組みがまったく違います。

環境	内部の SSL ライブラリ	特徴
Git Bash の curl	OpenSSL（＋Git 同梱の CA バンドル）	独自 CA を使用／失効チェックが緩い
Windows curl	Schannel（Windows 証明書ストア）	失効チェックが厳しい／企業ネットワークの影響を受けやすい

Git for Windows は独自の CA バンドルを持っています。

C:\Program Files\Git\mingw64\ssl\certs\ca-bundle.crt

そのため Git Bash の curl は、

結果として、企業ネットワークの SSL インスペクション環境でも動きやすいです。

Windows curl は Schannel を使います。 Schannel は次のような厳格なチェックを行います。

そのため、企業ネットワークでは次のようなエラーが頻発します。

curl: (35) schannel: next InitializeSecurityContext failed:
CRYPT_E_NO_REVOCATION_CHECK (0x80092012)
失効の関数は証明書の失効を確認できませんでした。

これは Schannel が証明書の失効確認（CRL/OCSP）に失敗したことを意味します。

企業ネットワークでは、

といった理由で、失効確認が通らずエラーになります。

Git Bash の curl は OpenSSL 系で失効チェックが緩いため、同じ環境でも問題が表面化しません。

IT 部門が配布している社内ルート証明書を 信頼されたルート証明機関 に登録します。

Windows curl に OpenSSL の CA を使わせる方法。

curl --cacert "C:\Program Files\Git\mingw64\ssl\certs\ca-bundle.crt" https://example.com

curl -k https://example.com

疎通確認や証跡取得のための一時利用なら現場ではよく使われます。

curl の基本と SSL の仕組みを押さえておくと、 API のデバッグや証跡取得が格段にスムーズになります。