「ファイルを取ってくるだけ」で終わるはずだったスクリプトを、夜遅くまで何度もデバッグしてきました。十回のうち九回は、犯人が cURL 自体ではなく、自分が指示したとおりには動くけれど自分が望んだようには動いていない、というところにありました。言い換えると、curl -O が動くことと、curl -O が本番環境で安定して動くことは、まったく別の話です。
このギャップを埋めるために書いたのがこの記事です。cURL は macOS、ほとんどの Linux ディストリビューション、そして Windows 10 以降に標準で入っているので、今この瞬間あなたの環境にもすでに入っている可能性が高いです。ただ、リダイレクトが静かに失敗したり、理由のわからない 403 に出くわしたり、「ファイルを1つ落とす」から「ターミナルを落とさずに 500 ファイル落とす」へ話が大きくなると、引っかかるポイントが本当にたくさんあります。ここでは、重要なフラグ、実際の使い方、よくあるエラー、そして cURL ではもう無理な状況とそのとき何に乗り換えるべきかまで、順を追って説明します。
cURL とは何か、なぜ気にする必要があるのか
cURL は URL を使ってサーバーとデータをやり取りするための、無料のオープンソースなコマンドラインツールです。HTTP、HTTPS、FTP、SFTP を含むとても多くのプロトコルに対応していて、bash スクリプトから Dockerfile、CI パイプラインまで、あちこちで見かけるのもそのためです。内部的には、ターミナルで打つ curl コマンドが libcurl を使っています。libcurl は多くのアプリケーションや言語バインディングに組み込まれている C 製の転送ライブラリです。PHP の cURL 拡張はその一例で、Python でよく使われる Requests は別の HTTP クライアントであり、libcurl ベースではありません。
執筆時点での最新安定版は curl 8.21.0 で、2026年6月にリリースされました。ただし OS に同梱されているバージョンがそのまま同じビルドとは限りません。ディストリビューション付属の curl は上流より数か月、ときにはそれ以上遅れていることがよくあるので、--parallel のようなフラグが実際に使えるかどうかは、まず curl --version で確認しておくのが安全です。
なぜ cURL でファイルを落とすのか：主な使いどころ
「ブラウザで普通にダウンロードすればいいのに、わざわざコマンドラインツールを使う必要ある？」という質問をよく受けます。正直に答えると、「自動化が必要になった瞬間にブラウザは限界が来る」です。
| ユースケース | cURL が強い理由 |
|---|---|
| CI/CD パイプラインでバイナリを取得する | スクリプト化しやすく、GUI が要らない |
| API レスポンスやデータ出力を取得する | カスタムヘッダー、認証、出力のパイプ処理に対応 |
| SSH 経由で大容量ファイルのダウンロードを再開する | 再開機能を標準で搭載（-C -） |
| 定期ダウンロードの自動化（cron ジョブ） | 軽量でシェルスクリプトとの相性が良い |
| 認証が必要な場所からファイルを取得する | 柔軟な認証フラグ（Basic、トークン、Cookie、.netrc） |
ブラウザのダウンロードは、その都度おこなう手作業です。cURL は同じ作業を、スケジュール実行でき、パイプラインに組み込め、失敗したらリトライでき、100台のサーバーでも同じように回せる形に変えてくれます。そこが本当の魅力です。派手ではありませんが、再現性が高いのです。
ファイルのダウンロードに欠かせない cURL のフラグ
私がやる作業の9割は、結局のところ似たような10個前後のフラグに落ち着きます。ここでは、何をするオプションなのかがひと目でわかるよう、用途別に整理したチートシートを紹介します。
出力と保存まわりのフラグ
-O（--remote-name）は URL の末尾の名前をそのままファイル名にして保存します。手軽ですが、同じ名前があると気づかないうちに上書きしてしまうことがあります。-o <filename>（--output）は保存するファイル名を自分で指定できます。例：curl -o report.pdf https://example.com/downloads/file.pdf-J（--remote-header-name）は URL ではなく、サーバーのContent-Dispositionヘッダーに書かれたファイル名を使います。API からのダウンロードに便利ですが、サーバーが返してきたファイル名を信用しすぎるのは禁物です。curl のセキュリティガイドでも勧められているとおり、ホームディレクトリより専用フォルダに保存するほうが安全です。curl のセキュリティガイド
どんなダウンロードでもよく使う挙動まわりのフラグ
-L（--location）は HTTP リダイレクトを追いかけます。これがないと 3xx レスポンスが、本物のファイルではなく小さな HTML のリダイレクトページとして保存されてしまいます。私が見てきた「ダウンロードできない」原因のうち、いちばん多いミスです。-C -（--continue-at -）は中断したダウンロードを続きから受け取ります。-s/-Sは静かに実行しつつエラーだけを表示します。プログレスバーでログが汚れるのを避けたいスクリプトに向いています。--limit-rate 1Mは転送速度を制限します。共有回線を使っているときや、帯域を使い切りたくないときに便利です。--connect-timeout 10と--max-time 300は、接続が固まってスクリプト全体が永遠に止まるのを防いでくれます。--retry 3と--retry-delay 5は一時的な失敗を自動でリトライします。curl の man page によれば、--retry-all-errorsは「本当に同じリクエストを繰り返しても安全だ」と言えるときにだけ併用するのが良いとされています。
進捗表示とデバッグ用のフラグ
-#は既定の統計テーブルの代わりに、シンプルなプログレスバーを表示します。-vは詳細出力を有効にし、リクエスト／レスポンスのヘッダーまですべて見せてくれます。挙動がおかしいとき、真っ先に使うオプションです。-I（--head）はレスポンスヘッダーだけを取得します。大きなダウンロードを始める前の下調べに向いています。-wは転送後にカスタム出力を表示できます。たとえばcurl -o /dev/null -s -w "%{http_code}\n" <url>のように書いて、ステータスコードだけを確認できます。
始める前に
- 難易度： 初級〜中級（バッチ処理と認証のパートは少し上級です）
- 所要時間： 基本コマンドを一通り試すのに約15〜20分
- 必要なもの： ターミナル（macOS の Terminal、Linux のシェル、または Windows の PowerShell/WSL）、curl が入っている環境（
curl --versionで確認）、テスト用の URL（ここでは安定していて自由にアクセスできる GitHub の公開リリースアセットを例に使います）
cURL でファイルをダウンロードする方法：ステップごとの解説
ステップ1：ファイルを1つダウンロードする
いちばん基本の形は、curl -O <url> で元の名前のまま保存する方法と、curl -o myfile.zip <url> で名前を変えて保存する方法です。
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
私はもう例外なく、いつも -L を付けています。リダイレクトのせいで「落とせたと思ったら 400 バイトの HTML ファイルだった」という失敗を、あまりに何度も経験してきたからです。成功するとターミナルに進捗表示が出て、最後にカレントディレクトリへファイルが保存されます。
コマンドが成功していれば進捗が 100% になり、curl-8.21.0.tar.gz がカレントフォルダにできます。使う前に、まず存在するかどうかを確認しましょう。
ls -lh curl-8.21.0.tar.gz
ステップ2：ダウンロードしながらファイル名を変える
URL の末尾に何が付いていようと関係なく、ローカルでは好きな名前で保存したい場合は -o を使います。
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
ここでの -S は、ほかの場所で -s を使っていてもエラーだけは表示し直してくれます。-L -o <name> -S の組み合わせは、単一ファイルを落とすときに私がほぼ定番として使っている形です。
ステップ3：中断したダウンロードを再開する
大きなファイルを受け取っている途中で切れてしまったら（電波が悪い、VPN が切れた、など）、最初からやり直す必要はありません。次のように実行すれば大丈夫です。
curl -C - -LO https://example.com/large-file.iso
ただしこの機能は、サーバーが byte range リクエストに対応している場合にだけ使えます。Accept-Ranges: bytes は対応している可能性が高いというサインではありますが、これが見えないからといって非対応だと断定はできません。いちばん確実なのは、実際の range リクエストに対するサーバーの応答を見ることです。再開できるサーバーはたいてい 206 Partial Content と正しい Content-Range を返します。再開コマンドを実行したあとは -v または -D - で状態を確認しましょう。サーバーが range を無視したり offset を拒否したりする場合は、途中のファイルを安全だと思い込まず、明示的に最初から取り直してください。
ステップ4：プログレスバーを出す、または静かに実行する
対話的なターミナルできれいに見せたいときは curl -# -LO <url> を使います。スクリプトや cron のようにノイズは不要でエラーだけ見たい場合は curl -sS -LO <url> を使いましょう。私は手動デバッグでない限り、ほぼいつも静かな方を選びます。
ステップ5：ダウンロード速度を制限する
会社の共有回線を使っているときや、ビデオ会議中に帯域を根こそぎ持っていきたくないときは、次のように制限できます。
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
単位は K、M、G で、それぞれキロバイト、メガバイト、ギガバイト毎秒を意味します。
ステップ6：レスポンスヘッダーをファイルと一緒に保存する
サーバーが実際に何を返してきたのか、たとえば content type やキャッシュヘッダーなどを確認したいときがあります。ターミナルを散らかさずに済ませるには、こうします。
curl -L -D headers.txt -o file.zip https://example.com/file.zip
こうするとレスポンスヘッダーは headers.txt に、実ファイルは file.zip に保存されます。content-type の不一致を確認したり、CDN が本当に期待どおりキャッシュしているかを点検したりするのに便利です。
コツとよくある落とし穴
- コツ：
-Lは最初から既定のように付けておきましょう。付けて困ることはほぼなく、付けなかったせいで何時間も溶かすことのほうがずっと多いです。 - コツ： スクリプトではダウンロードコマンドに
--failも添えましょう。そうすれば 2xx 以外のレスポンスをエラーページとして静かに保存せず、きちんと失敗として扱ってくれます。 - 落とし穴：
-C -と--remove-on-errorは併用しないでください。curl のドキュメントでも互いに互換性がないと明記されています。再開するには途中のファイルが残っている必要があるからです。 - 落とし穴：
-Oは警告なしにファイルを上書きすることがあります。共有ディレクトリへ一括ダウンロードするときは、--output-dirで保存先を囲っておくのが安全です。
cURL で複数ファイルをダウンロードする、バッチ処理する
ファイルを1つ受け取る例は簡単です。本当に必要なのは、夜間のデータエクスポートを回収したり、ビルドサーバー間でバイナリを同期したりといった、同時実行の混ざった実運用のワークフローです。多くのチュートリアルはここで終わってしまいますが、押さえておく価値のある方法が3つあります。順に少しずつ難度が上がります。
方法1：1つの cURL コマンドに複数の URL を並べる
いちばん簡単なのは URL をいくつも書くことです。
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
これでも動きますが、順番に処理されます。つまり1つ終わってから次へ進みます。ファイルが3つなら問題ありませんが、300個だとつらくなります。
方法2：--parallel で並列ダウンロードする（curl 7.66 以上）
curl 7.66 以降は --parallel（または -Z）を付けて複数の URL を同時に取得できます。
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
知っておくとよいのは、並列数の既定値が実は 50 だという点です。これは多くのサーバーや自分のネットワーク環境にとって優しい値ではなく、むしろ多すぎることがほとんどです。私は既定値を信用せず、--parallel-max は明示的に、たいてい4〜8くらいまで下げておきます。
方法3：URL リストに xargs や Bash ループを使う
テキストファイルに URL がたくさん入っているなら、私はたいてい xargs を使います。
cat urls.txt | xargs -n1 -P 8 curl -O -L
あるいは各ジョブをもっと細かく扱いたいときは、バックグラウンドの Bash ループで回します。
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
最後の wait は重要です。これがないと、バックグラウンドのダウンロードが終わる前にスクリプトが終了してしまうことがあります。
wget や aria2 を使うべきとき
はっきり言っておくと、cURL がいつでも最善とは限りません。サイト全体のディレクトリ構造を再帰的にミラーリングしたいなら、wget -r のほうがその用途向けに作られています。1つの巨大なファイルをできるだけ速く受け取りたいなら、マルチソースの分割ダウンロードに対応した aria2c のほうがずっと速いことがあります。
| ツール | いちばん向いている用途 |
|---|---|
| cURL | 精密な制御、スクリプト化、単一ファイルや少量バッチのダウンロード、API 連携 |
| wget | 再帰的なサイト収集、ミラーリング、静的ファイルの大量取得 |
| aria2 | マルチソース／分割ダウンロード、大容量ファイルのスループット最大化 |
cURL の強みは、力任せのクローリングではなく正確さと組み合わせやすさです。パイプ、スクリプト化、プロトコルの柔軟性が肝になります。
cURL で保護されたファイルをダウンロードする：認証パターン
多くの cURL チュートリアルは -u user:pass で終わってしまいますが、それは昔のインターネットの名残です。2026年のいま、私が実際に受け取るファイルは REST API、セッションベースのダッシュボード、CI システムから来ることが多く、それぞれ違う認証方式を求めてきます。
Basic 認証
curl -u username:password -O https://legacy-server.example.com/file.zip
古い FTP サーバーやシンプルな HTTP エンドポイントなら、これで十分です。ただしパスワードがシェルの履歴やプロセス一覧に露出しうるので注意が必要です。機微な情報にはあまりおすすめしません。
Bearer / OAuth トークン認証
多くのガイドでは意外と扱いが小さいのですが、いまいちばんよく使う方式です。
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
これは非公開の GitHub リリースアセットを取得する実用的なパターンです。トークンとアセット ID だけ差し替えれば使えます。REST API や OAuth2 で保護されたリソースは、いまやほとんどこの方式に集約されています。
Cookie ベースのセッション認証
ログインするとセッションができるタイプの Web アプリでは、ログイン時に Cookie を保存し、ダウンロード時にもう一度取り出して使います。
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
スクリプト／CI 環境向けの .netrc ファイル
私は無人実行にはこの方式をいちばんよく使います。~/.netrc ファイル（Windows なら _netrc）を作ります。
machine example.com
login myusername
password mypassword
chmod 600 ~/.netrc で権限を絞ったうえで、こう書きます。
curl --netrc -LO https://example.com/protected-file.zip
この方法の良いところは、認証情報がシェルの履歴にもスクリプトのソースにも残らない点です。CI/CD ではスクリプト全体がログに残ることも多いので、これが本当に効いてきます。
| 認証方式 | フラグ／オプション | いちばん向いている用途 |
|---|---|---|
| Basic 認証 | -u user:pass | レガシーな FTP、シンプルな HTTP |
| Bearer トークン | -H "Authorization: Bearer <token>" | REST API、OAuth2 |
| Cookie 認証 | -b cookies.txt（保存には -c） | セッション型の Web アプリ |
.netrc ファイル | --netrc または --netrc-file | CI/CD、スクリプト環境 |
よくある cURL ダウンロード失敗のトラブルシューティング
ここは私が初心者だったころ、いちばん読みたかった章です。というのも、こういうことをきちんと説明してくれる記事があまりないからです。「なぜ curl のダウンロードがうまくいかないのか」は、実際とてもよくある、そしてストレスの大きい検索ワードです。そして原因さえわかれば、解決策はたいてい一行で済みます。
| 症状 | よくある原因 | 解決方法 |
|---|---|---|
curl: (60) SSL certificate problem | 自己署名証明書または期限切れの証明書 | --cacert <file> または -k（開発用のみ） |
403 Forbidden / 空のファイル | サーバーが既定の curl User-Agent をブロックしている | -A "Mozilla/5.0..." または -H "User-Agent: ..." |
-C - なのに 0 バイトから再開される | サーバーが Range に対応していない | curl -I <url> で Accept-Ranges: bytes を確認 |
| 0 バイトのファイルが保存される | リダイレクトを追いかけていない | -L を追加 |
curl: (28) Operation timed out | サーバーが遅い、またはネットワークが不安定 | --connect-timeout 10 --max-time 300 + --retry 3 |
| 実ファイルの代わりに HTML ページが保存される | JavaScript レンダリングが必要なページ | curl は JS を実行できません。次の章を参照 |
SSL 証明書エラー：意味と対処
エラー 60 は、curl がサーバーの SSL 証明書を検証できなかったという意味です。原因は自己署名、期限切れ、または curl が信頼していない CA から発行されているケースが多いです。サーバーを自分で管理しているなら、正しい CA バンドルを --cacert /path/to/ca.pem で指定しましょう。-k（--insecure）は検証を飛ばしますが、ローカル開発ならまだしも、本番環境や実ユーザーのデータに触れる場所では避けるべきです。
403 Forbidden と空のダウンロード
意外とよくあるのが、curl/8.21.0（curl の既定 User-Agent 文字列）を見てブロックしてくるサーバーです。ボットやスクレイパーだと判断しているわけですね。解決はたいてい、ブラウザらしく見せるだけで済みます。
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
本格的に受け取る前に何が返ってくるか見たいときは、私はたいていこうします。curl -o /dev/null -s -w "%{http_code}\n" <url>
タイムアウト、リトライ、不安定な接続
タトゥーを入れるなら腕に彫りたいくらい、よく使うコマンドがあります。
本番のスクリプトで実際に使っている、信頼性重視の基本ダウンロードコマンドは、こうしたフラグを全部載せた形です。
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
リダイレクト追跡、再開、5回のリトライと3秒待機、10秒の接続タイムアウト、10分の全体制限、そして不正な HTTP ステータスなら即座に失敗。私が失敗しながら学んだことを、全部詰め込んだ構成です。
実務での cURL：CI/CD パイプライン、パイプ処理、スクリプトの安全性
cURL の出力を別のツールへそのまま渡す
cURL は必ずしもディスクへ保存する必要はありません。別のコマンドへ直接パイプするのは、もっと評価されていい機能です。
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
ダウンロードして展開する、あるいはダウンロードしてパースする。一行で終わります。私は使い捨てのデータ収集にこの方式をよく使います。
GitHub Actions や CI/CD で cURL を使う
リトライ付きでバイナリをダウンロードし、問題があればきちんと失敗させる、最小構成の GitHub Actions はこんな形です。
- name: バイナリをダウンロード
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
トークンは CI の secret として保存し、環境変数から参照してください。スクリプトに直接書いてはいけません。そして --fail（またはエラー本文をデバッグに使いたいなら --fail-with-body）を使って、壊れたダウンロードが静かに成功扱いされないようにしましょう。
curl | sh のセキュリティ問題
これは私が見てきた開発者フォーラムで、ほぼ毎回話題に上がる件です。理由は単純で、curl をそのまま sh に渡すというのは、まだ読んでもいないリモートのコードをそのまま実行するということだからです。信頼の前提は、そのサーバーが侵害されておらず、通信が改ざんされていないことです。これは脅すための話ではなく、サプライチェーンの観点で現実的なリスクです。
より安全な流れは、まずダウンロードし、スクリプトを読み、可能ならチェックサムや GPG 署名を確認してから実行することです。
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # 実際に読む
sha256sum install.sh # 公開されたチェックサムがあれば照合する
bash install.sh
rustup や Homebrew のような有名なインストーラーも curl | sh パターンを使っています。提供元と配布経路の信頼性が十分に検証されているため、特定の状況では広く受け入れられています。それでも私は、10秒だけ余計に使ってスクリプトを確認するほうが安心です。あとから「信じるべきではなかった」と気づくよりずっとましですから。
cURL だけでは足りない場合：JS レンダリング、ボット対策サイト、構造化データ
ここで多くの人がつまずきます。そして、その大半は本人のせいではありません。見た目は普通のページに curl -O を使ったのに、期待した中身の代わりに空っぽの HTML の殻、Cloudflare のチャレンジページ、あるいは正体不明のゴミだけが返ってくることがあります。cURL は設計どおり、生の HTTP レスポンスを取ってきただけです。しかし JavaScript の実行、CAPTCHA の突破、アンチボットのフィンガープリント回避はできません。それは cURL のバグではなく、そもそも担当領域の外なのです。
最近の Web ページで cURL が失敗する理由
現代のシングルページアプリは HTML の骨組みだけを返し、実際の中身はページが開かれたあとに JavaScript がクライアント側で描画します。cURL はそれを実行しません。さらに Cloudflare や Akamai のようなシステムは、本物のブラウザに見えないアクセスにチャレンジページを返します。同じ IP から cURL のリクエストが続けば、あっという間にレート制限を受けたり、ボットトラフィックとして分類されたりします。
次の一手：開発者向けの AI スクレイピング API
私は、cURL がファイルやデータ取得の作業の約8割には本当に良いツールだと思っています。静的アセット、API レスポンス、単純な HTTP リソースとして提供されるものは cURL で十分です。問題は残りの2割です。JavaScript の多いページやボット対策の強いページでは、多くの開発者がヘッダーや User-Agent を何時間もいじった末に、結局は別のレイヤーを探すことになります。
まさにその隙間を埋めるために、私たちのチームは Thunderbit を作りました。おなじみの Chrome 拡張機能 もありますし、開発者向けには Thunderbit Open API があって、POST /distill はページのレンダリングをサービス側で処理したうえで、URL から LLM 向けのきれいな Markdown を返します。POST /extract は、読みやすいテキストではなく実際の構造化データが必要なときに、スキーマに沿った JSON を返します。また Claude や Cursor のエージェントが作業中に thunderbit_distill や thunderbit_extract を呼べる MCP サーバーもあり、CLI（npx @thunderbit/thunderbit-cli distill <url>）はターミナルで cURL のように扱えます。たとえば JSON 出力を jq に渡すなら thunderbit distill <url> --format json | jq -r '.data.markdown' のように書けますし、--format markdown の出力はテキストツールやファイルへそのまま流せます。
並べてみると違いは明らかです。JavaScript レンダリングが必要な商品ページへの cURL リクエストは、ほぼ空の <div id="root"></div> しか返さないことがあります。一方 thunderbit distill は、レンダリング後のページ内容をきれいな Markdown で返します。Distill は URL あたり1クレジット、Extract は URL あたり20クレジットです。現在の上限はエンドポイントごとに異なり、Batch Distill はジョブあたり最大100 URL、Batch Extract は共通スキーマ1つで最大50 URL を受け付けます。本番のキューを設計する前に、必ず最新の API ドキュメントを確認してください。
概念がまだなじまないなら、私たち自身のWebスクレイピングとは何かの解説が良い出発点になりますし、ノーコードのスクレイピングガイドは、ターミナルをあまり使わないチームメンバーにこの問題を別の角度から説明してくれます。関連ツールを広く比較したいなら、おすすめの AI Web Scraper もまとめてあります。
クイックリファレンス：cURL ダウンロードのチートシート
| やりたいこと | コマンド |
|---|---|
| 基本のダウンロード | curl -LO <url> |
| ファイル名を指定する | curl -L -o myfile.zip <url> |
| ダウンロードを再開する | curl -C - -LO <url> |
| エラーは見せつつ静かに実行する | curl -sSL -O <url> |
| 並列ダウンロード | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Bearer トークン認証 | curl -H "Authorization: Bearer <token>" -LO <url> |
| スクリプト用の基本ダウンロード | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| 展開ツールへパイプする | curl -sL <url> | tar xz |
まとめと要点
cURL でファイルをダウンロードする作業は、最初はとても単純です。curl -O だけでたいていは片付きますから。でも本当に大事なのはその下の層です。いつ -L を付けるべきか、いつ最初から取り直さずに続きから受け取るべきか、どの認証方式が自分のワークフローに合うのか、そして期待したファイルの代わりに 403 や空の HTML が返ってきたときにどう動くのか。私はこれらのほとんどを、「なぜこれが大事なのか」を身をもって学んだ直後に書き留めてきました。
cURL はいまでも、単純なファイル取得とスクリプト化された HTTP 処理の第一候補です。速く、どこにでもあり、シェルのパイプラインとも相性が良い。ただし JavaScript レンダリングのページやアンチボットの壁にぶつかったなら、それはフラグを足せば解決する cURL の問題というより、別のレイヤーが必要だというサインです。そういう場面でこそ、Thunderbit のような API がターミナルを離れずに次の作業を引き受けてくれます。
チートシートはブックマークしておいて、次に不安定なダウンロードに出くわしたら、リトライと再開のコマンドを一度試してみてください。そして cURL がゴミしか返さない壁にぶつかったときには、次の一手がもうわかっているはずです。Thunderbit の価格ページには現在のクレジットの内訳が載っているので、実際にどれくらいコストがかかるか確かめたいならそこで見られます。文章より動画が好みなら、YouTube チャンネルにも案内動画があります。
cURL ファイルダウンロードの FAQ
cURL でファイルを特定の名前で保存するにはどうすればいいですか？
-o のあとに好きなファイル名を付ければ大丈夫です。例：curl -L -o yourname.ext <url>。リダイレクトによる失敗を防ぐため、-L も一緒に付けましょう。
失敗した cURL のダウンロードを続きから受け取るには？
curl -C - -LO <url> を実行すれば大丈夫です。これはサーバーが range request に対応している場合にだけ動きます。まず curl -I <url> で確認し、レスポンスに Accept-Ranges: bytes があるか見てください。
ログインが必要なファイルも cURL で受け取れますか？
はい。主な方法は4つです。Basic 認証（-u user:pass）、Bearer トークン（-H "Authorization: Bearer <token>"）、Cookie ベースのセッション（-b cookies.txt）、そしてスクリプト環境向けの .netrc ファイルです。詳しくは上の認証セクションを参照してください。
ファイルのダウンロードという観点で、cURL と wget の違いは何ですか？
cURL は対応プロトコルが多く、スクリプト化やパイプ処理、単一ファイルや少量バッチの精密な取得に向いています。wget は再帰的なクローリングとサイト全体のミラーリング向けに作られているので、静的サイトの大量取得により適しています。
なぜ cURL が実ファイルではなく HTML ページを受け取ってしまうのですか？
よくある原因は2つです。-L を付け忘れて別の場所へリダイレクトされたか、ページの中身が JavaScript でレンダリングされるタイプで curl がそれを実行できないかです。後者なら、cURL のフラグを増やすのではなく、レンダリングできるツールが必要です。
