先に要点
- curl は HTTP 専用ツールではない。FTP / FTPS / SFTP / SCP / SMTP / IMAP / LDAP / MQTT など 25 以上のプロトコルを 1 つのバイナリで扱える「多機能ネットワーククライアント」。FTP も SFTP も同じコマンドで操作できる。
- FTPS は「FTP に TLS を被せた」版で、Explicit FTPS(平文 21 番で接続 →
AUTH TLSで暗号化開始)と Implicit FTPS(最初から TLS、990 番)の 2 種類がある。curl は両方とも対応している。 - FTPS を curl で使う最小例は
curl --ftp-ssl -u user:pass ftp://host/path/file.txt -o local.txt。Implicit ならftps://host:990/...のようにスキーマと URL で指定する。 - 新規構築なら FTPS より SFTP(SSH 上のファイル転送)が推奨だが、既存の取引先システムが FTPS しか喋れない場面では curl が静かに役に立つ。証明書検証、パッシブモード、ファイアウォール周りの落とし穴に注意。
「curl って HTTP を叩くツールでしょ?」「FTPS のクライアントって WinSCP か FileZilla しかないと思ってた」「Linux のバッチで FTPS にファイル上げたいけど、何を入れればいい?」 ── 実は curl は FTPS を喋れる多機能クライアントで、Linux なら何も追加せずに即使えるのが大きな利点です。
ざっくり言うと、curl は 「URL を渡せばだいたいのプロトコルでファイルを行き来できる」 万能ツールで、FTPS / FTP / SFTP も同じ流儀で扱えます。GUI クライアントを CI サーバに入れたくない、シェルスクリプトに組み込みたい、というケースで強い武器になります。
この記事では、curl の正体から FTPS の 2 種類(Implicit / Explicit)、curl での実用例、SFTP との使い分け、自動化の落とし穴までを整理します。
curl は HTTP 専用ツールではない
curl は 1996 年に Daniel Stenberg が公開した、多プロトコル対応のファイル転送ツールです。
対応プロトコル
2026 年現在で HTTP / HTTPS / HTTP/2 / HTTP/3 / FTP / FTPS / SFTP / SCP / TFTP / TELNET / LDAP / LDAPS / IMAP / IMAPS / POP3 / POP3S / SMTP / SMTPS / GOPHER / DICT / FILE / RTMP / RTSP / WS / WSS / MQTT の 25 種以上に対応。
なぜ「curl と言えば HTTP」 と思われがちか
実際の使用例の 9 割以上が HTTP / HTTPS だから。「API を叩く」「Web ページを取る」「shell スクリプトから REST を呼ぶ」 用途で広まったため、他のプロトコル対応が知られていない。
どこに入っているか
Linux 主要ディストリで標準搭載(無ければ apt install curl / dnf install curl)。Windows 10 / 11 にも標準搭載(2018 年から C:\Windows\System32\curl.exe)。macOS にも標準搭載。追加インストール無しで FTPS が叩けるのがありがたい。
「curl は HTTP クライアント」 ではなく、「URL を入力に取るネットワークデータ転送ツール」 と捉えると、FTPS や SFTP も自然に守備範囲に入ってきます。
FTPS とは — FTP に TLS を被せたもの
FTPS は FTP + TLS の組み合わせです。FTP は平文プロトコルでパスワードもデータも丸見えという問題があり、それを TLS(SSL の後継)で暗号化したのが FTPS です。
FTPS と SFTP は別物
名前が似ているが全く別のプロトコル。FTPS は FTP + TLS(歴史: FTP を後から暗号化)、SFTP は SSH File Transfer Protocol(SSH の上に乗ったまったく別仕様)。port も違う(FTPS: 21 / 990、SFTP: 22)。
Explicit FTPS(FTPES)
最初は平文の FTP として 21 番で接続し、クライアントが AUTH TLS コマンドを送って途中から TLS にアップグレードする方式。RFC 4217 で標準化。現在の主流。
Implicit FTPS
最初から TLS で接続する方式。専用ポート 990 番を使う。古い実装が多く、新規導入では Explicit が推奨。
「FTPS は古い取引先や金融系・物流系で根強く残っているレガシー寄りプロトコル」 と覚えておくと、出会ったときに納得しやすいです。
curl で FTPS を使う基本
curl で FTPS を叩く基本構文を、ユースケース別に並べます。
ダウンロード(Explicit FTPS)
# 21 番に FTP として接続 → AUTH TLS で暗号化
curl --ftp-ssl -u user:password \
ftp://example.com/path/file.zip -o file.zip
--ftp-ssl は「TLS が使えるなら使う、ダメなら平文に戻す」 オプション。確実に暗号化したい場合は --ssl-reqd(TLS 必須、失敗したら接続しない)を使います。
# TLS 必須にする(本番ではこちらを推奨)
curl --ssl-reqd -u user:password \
ftp://example.com/path/file.zip -o file.zip
ダウンロード(Implicit FTPS)
# ftps:// スキーマ + 990 番
curl -u user:password ftps://example.com:990/path/file.zip -o file.zip
スキーマを ftps:// にすると curl が Implicit FTPS として扱います。
アップロード
# ローカルの local.zip をリモートにアップロード
curl --ssl-reqd -u user:password \
-T local.zip ftp://example.com/upload/
-T(--upload-file)でローカルファイルをアップロード。末尾を / で終わらせると、ローカル側のファイル名がそのまま使われます。
ディレクトリ一覧
# フォルダの内容を一覧表示
curl --ssl-reqd -u user:password \
ftp://example.com/path/
URL の末尾を / にすると、そのディレクトリのリストが返ってきます(LIST コマンド相当)。
コマンド送信(任意の FTP コマンド)
# DELE コマンドで削除、MKD でディレクトリ作成
curl --ssl-reqd -u user:password \
-Q "DELE oldfile.zip" ftp://example.com/path/
curl --ssl-reqd -u user:password \
-Q "MKD newdir" ftp://example.com/path/
-Q で任意の FTP コマンドを送れます。複数指定可、転送前なら通常通り、転送後なら -Q "+CMD" のようにプレフィックスで指定します。
「ダウンロード / アップロード / 一覧 / 削除」 の 4 動作で、運用バッチの大半はカバーできます。
主要オプション一覧
curl で FTPS を使うときに登場するオプションを整理します。
| オプション | 意味 | 典型的な使い所 |
|---|---|---|
--ftp-ssl | TLS が使えれば使う(平文フォールバック可) | 互換性重視の運用 |
--ssl-reqd | TLS 必須(失敗で接続中止) | 本番の安全運用 |
--ftp-ssl-control | 制御チャネルだけ TLS、データチャネルは平文 | 負荷を抑えたい古い装置 |
-k / --insecure | サーバ証明書の検証をスキップ | 自己署名証明書のテスト時のみ |
--cacert <file> | CA 証明書ファイルを指定 | プライベート CA を使う場合 |
--ftp-pasv | パッシブモード(デフォルト) | クライアント側 NAT 越え |
-P - / --ftp-port | アクティブモード | サーバ側ファイアウォール条件次第 |
-u user:pass | 認証情報 | 大半の FTPS で必要 |
-T <file> | アップロード | 送信側 |
-o <file> | ダウンロード保存先 | 受信側 |
-Q <cmd> | FTP 生コマンド送信 | DELE / MKD / RNFR-RNTO など |
-v / --verbose | 通信内容を詳細表示 | トラブル切り分けの第一手 |
--trace-ascii <file> | 送受信を ASCII でログ化 | 本格的な問題調査 |
最低限 --ssl-reqd -u -T -o -Q -v を押さえておけば、業務での FTPS バッチは作れます。
SFTP も curl で叩ける
curl は SFTP / SCP も叩けます(libssh2 / libssh ビルドオプション有効時。Linux 標準パッケージでは大体有効)。
# SFTP でダウンロード
curl -u user:password sftp://example.com/path/file.zip -o file.zip
# SFTP で公開鍵認証
curl --key ~/.ssh/id_ed25519 --pubkey ~/.ssh/id_ed25519.pub \
-u user: sftp://example.com/path/file.zip -o file.zip
ただし本格的に SFTP を使うなら専用の sftp / scp / rsync のほうが UX が良いです。curl の SFTP 対応は「他プロトコルと同じ書き方で叩ける」 ことに意味があり、CI 上で複数プロトコルを統一インタフェースで扱うときに便利、というニッチな価値です。
FTPS / SFTP / HTTP どれを選ぶか
ファイル転送のプロトコル選定の判断軸を整理します。
新規構築なら SFTP
SSH の鍵管理がそのまま使え、ファイアウォール越しのトラブルが少ない。FTP vs SSH の整理でも書いた通り、現代の標準は SFTP。
取引先が FTPS 指定なら FTPS
金融 / 物流 / EDI 系は「FTPS で送ってください」 と指定されることがまだ多い。先方のシステムが SFTP を喋れないなら FTPS に合わせる。curl があれば追加ツール不要。
人手で操作するなら GUI
業務担当者が触るなら WinSCP / FileZilla の GUI が現実的。curl はバッチ・CI 向け。
「FTPS は積極的に新規採用するものではなく、既存システムに合わせて使う」 のが 2026 年現在の位置づけです。
CI / バッチ自動化での実用パターン
curl を業務バッチに組み込むときの定番パターンを整理します。
「rsync / sftp で済むなら使わない、FTPS に縛られるなら curl で堅く組む」 が王道です。
よくあるトラブル
curl + FTPS で踏みやすい罠を 3 つに絞って整理します。
パッシブモードでデータポートが開かない
FTPS はデータチャネル用に動的なポートを使う。クライアントが PASV モードでも、サーバ側のファイアウォールでパッシブポート範囲が許可されていないと接続が固まる。サーバ管理者にパッシブポート範囲を確認するのが先。
証明書チェーンが繋がっていない
サーバの中間証明書が不足していると、curl が SSL certificate problem でエラーを返す。本物の問題を -k で隠さず、openssl s_client -connect host:port -starttls ftp でチェーンを確認し、不足する中間証明書を --cacert で渡す。
古い TLS バージョンの強要
取引先サーバがTLS 1.0 / 1.1 しか喋れないと、新しい curl はデフォルトで拒否する。本来は先方にアップグレードを依頼するのが筋だが、緊急対応で --tlsv1.0 + --ciphers 'DEFAULT:@SECLEVEL=0' のような明示指定で繋ぐこともある。恒久対応は必ず先方の TLS バージョン引き上げ。
日本語ファイル名で文字化け
FTPS は元が古いプロトコルなので、ファイル名の文字コード扱いが曖昧。URL エンコードする(--url-encode 相当の事前処理)か、可能なら取引先と「ASCII ファイル名で運用」 を合意するのが安全。
「FTPS で繋がらない」 の 8 割は パッシブポート / 証明書チェーン / TLS バージョン のどれかです。-v で通信ログを見れば、どこで止まっているか大抵わかります。
AI 時代の curl
最近は Claude Code のような AI コーディング環境が、「とりあえず curl で API を叩いて検証してみて」 という指示に対し、即座に curl -X POST -H 'Content-Type: application/json' ... を生成して実行できるようになりました。
AI が curl コマンドを書く時代
「FTPS に file.zip を上げて」 と頼めば、AI が curl --ssl-reqd -T file.zip ... を提案してくれる。枯れた技術 である curl は AI の得意分野で、人間がオプションを暗記する必要が減った。
それでも理解は必要
AI が出した curl コマンドに -k が紛れ込んでいるとセキュリティリスク。「証明書検証を切る」「平文フォールバックを許す」 ような危険オプションを使っていないか、人間が読める力は残す。
httpie や xh の選択肢
HTTP API 操作だけに絞れば、JSON 整形が綺麗な httpie / xh が読みやすい。ただし FTPS や SFTP まで含めると依然として curl が最強の万能性を持つ。
「枯れたツール + AI の生成支援 + 人間のレビュー」 の組み合わせで、FTPS のような古いプロトコルもストレスなく扱えるようになっています。
curl と FTPS に関するよくある質問
Q. 一言でまとめると、curl で FTPS は何が嬉しいですか?
A. 追加インストール無しで FTPS バッチが組めること。Linux / Windows / macOS どれにも標準搭載されている curl 1 本で、ダウンロード / アップロード / 一覧 / 削除が完結します。CI サーバや業務バッチに GUI クライアントを入れたくない場面で重宝します。
Q. FTPS と SFTP は何が違いますか?
A. FTPS は FTP に TLS を被せたもの、SFTP は SSH 上で動く別仕様のファイル転送プロトコルです。ポート(FTPS: 21 / 990、SFTP: 22)、認証方式、データチャネルの扱いがすべて違います。詳しくは FTP と SSH の違い を参照してください。新規構築なら SFTP が推奨ですが、既存システムが FTPS 限定なら FTPS で繋ぐしかありません。
Q. --ftp-ssl と --ssl-reqd はどちらを使うべきですか?
A. 本番は --ssl-reqd(TLS 必須)。--ftp-ssl は「TLS が使えなければ平文でも転送する」 動きで、気付かないうちにパスワードが平文で流れる事故になります。互換性確認の初回テスト以外で --ftp-ssl 単体は使わないのが安全です。
Q. -k オプションは使ってもいいですか?
A. 本番では絶対に使わないでください。-k(--insecure)はサーバ証明書の検証をスキップするので、中間者攻撃に完全に無防備になります。「証明書エラーが出たから -k で回避」 ではなく、エラーの原因(中間証明書不足 / 期限切れ / ホスト名不一致)を特定して直すのが筋です。自己署名証明書のローカルテストでのみ許容。
Q. パスワードを安全に渡すには?
A. (1) .netrc ファイル(chmod 600 ~/.netrc、machine host login user password pass の形式)に書いて -n で参照、(2) 環境変数に入れて -u "$FTP_USER:$FTP_PASS" で渡す、(3) -K config.txt でオプションファイルから読み込む、のいずれか。ps aux 経由でコマンド行が見える環境では、-u user:pass の直書きはパスワード露出になります。
Q. パッシブモードとアクティブモードの違いは何ですか?
A. FTP / FTPS は制御チャネルとデータチャネルが分かれた変則的なプロトコルで、データチャネルをどちら側から張るかで 2 モードあります。パッシブ(PASV)はクライアント側から接続するモードで、クライアントが NAT の中にいる場合に推奨。アクティブはサーバから接続するモードで、現代ではほぼ使いません。curl のデフォルトはパッシブで、明示するなら --ftp-pasv。アクティブを使うなら -P - です。
Q. CI(GitHub Actions など)で curl + FTPS を使うときの注意は?
A. (1) シークレット管理でユーザ名 / パスワードを環境変数として渡す。(2) --ssl-reqd で TLS 必須にする。(3) --retry 5 --retry-delay 10 でネットワーク瞬断に備える。(4) ジョブログにパスワードが残らないよう、コマンド行に直書きしない。(5) 失敗時は終了コードで通知する(set -e や if [ $? -ne 0 ])。これだけ守れば、定期バッチとして安定運用できます。
Q. curl のドキュメントはどこで読めばいいですか?
A. 公式の https://curl.se/docs/manual.html が一次情報。man ページ(man curl)も同じ内容で詳しい。Daniel Stenberg(作者)が書いた書籍 Everything curl がオンライン無料で読めて、FTPS / SFTP も含む網羅的な解説があります。
参考リンク
- curl 公式: curl.se
- curl manual: curl.se/docs/manual.html
- Everything curl(オンライン書籍): everything.curl.dev
- RFC 4217: Securing FTP with TLS
- 関連記事: FTP と SSH の違いと使い分け / WinSCP と FileZilla の違い / 枯れた技術を選ぶ価値