MENU
プログラムとツールの使い方を、実務目線で分かりやすく整理
  1. ホーム
  2. プログラム
  3. FTPとSFTPの違いを実務で整理。安全なファイル転送の選び方と使い分け

FTPとSFTPの違いを実務で整理。安全なファイル転送の選び方と使い分け

プログラム

FTPとSFTPの違いは何か。安全なファイル転送の選び方と実務での使い分け

サーバーへファイルを上げる作業で、普段はSFTPを選ぶのが基本です。理由は単純で、SFTPはSSH上で動き、認証情報や転送内容を暗号化できるからです。

一方のFTPは古くからある標準プロトコルですが、標準FTPはユーザー名やパスワード、転送データを平文で流します。外部ネットワークや共用環境でそのまま使うのは避けるべきです。

最初に要点だけ押さえると、判断は次の通りです。

  • 公開サーバーや社外ネットワーク越しならSFTPを使う
  • FTPしか受け付けない古い機器や閉域の既存環境だけFTPを検討する
  • FTPを使う必要があるなら、可能ならFTPSも比較対象に入れる
  • 自動化や定期転送でも、認証情報を安全に扱いやすいのはSFTP

ここがポイント: 「FTPとSFTPは似た名前の別物」です。SFTPはFTPをSSHで包んだものではなく、SSHベースの別系統のファイル転送方式として考えたほうが実務で混乱しません。

目次

まず違いを一気に整理

どちらも「サーバー上のファイルを一覧表示し、アップロードし、ダウンロードする」ために使えます。違いは、その通信をどう守るか、運用がどれだけ楽かにあります。

項目 FTP SFTP
通信の保護 標準では暗号化なし SSH上で暗号化される
認証情報 標準では平文送信 パスワード認証や公開鍵認証を使える
よく使うポート 制御接続は21番、データ接続は別で扱う 通常はSSHの22番
接続の扱い 制御接続とデータ接続が分かれる SSH接続の上でまとめて扱いやすい
ファイアウォールとの相性 受動/能動モードの調整が必要になりやすい 比較的シンプル
実務での基本方針 レガシー環境向け 通常はこちらを優先

なぜFTPは扱いが難しいのか

RFC 959で定義されたFTPは、制御用とデータ用の接続を分けて扱います。これ自体は歴史のある設計ですが、いまの運用ではファイアウォールやNAT越しの設定で面倒になりやすい点です。

さらにRFC 2577では、標準FTPではパスワードやデータが暗号化されずに流れることが明記されています。つまり、便利さより先に安全性の制約を理解する必要があります。

SFTPが実務で選ばれやすい理由

SFTPはSSH上で動くため、接続時点で暗号化とサーバー認証の仕組みを使えます。OpenSSHのsftpでも、公開鍵認証やバッチ処理をそのまま利用できます。

この差は大きいです。単に「転送できる」だけでなく、次の作業まで見据えるとSFTPのほうが扱いやすくなります。

  • 本番サーバーへのアップロード
  • バックアップファイルの回収
  • バッチ処理での定期転送
  • CI/CDや運用スクリプトからの自動配置

どんな場面で使い分けるか

結論を実務ベースで分けると、判断基準はかなり明確です。

SFTPを選ぶ場面

  • VPSやクラウドサーバーへ接続するとき
  • 社外ネットワークをまたぐとき
  • 顧客データやバックアップを扱うとき
  • 鍵認証で自動化したいとき
  • 接続先がLinuxサーバーで、すでにSSH運用しているとき

FTPを検討する場面

  • 古いNASや業務機器がFTPしか対応していないとき
  • 閉域網の内部だけで使う既存システムを短期的に維持するとき
  • ベンダー都合でFTPサーバーが前提になっているとき

ただし、この場合でも確認すべき点があります。

  • FTPSへ切り替えられないか
  • 送るファイルに機密情報が含まれないか
  • アカウントを共用していないか
  • 接続元IP制限や監査ログを取れるか

前提環境と今回の例

この記事のコマンド例は、2026年4月25日時点で確認した公式情報をもとに、次の環境を前提にしています。

  • SFTPクライアント: OpenSSHのsftp
  • FTPクライアント例: Windows標準のftpコマンド
  • サーバー側: SSH接続を受け付ける一般的なLinuxサーバー、またはFTPサーバー

GUIで扱うならWinSCPやFileZillaでも考え方は同じです。重要なのは、接続方式の選択を最初に間違えないことです。

基本の書き方

ここでは、最小構成で接続してファイルをやり取りする例を見ます。

SFTPの基本

OpenSSHのsftpは、SSH接続の延長として使えます。

sftp user@example.com

ポート番号を変えているなら、たとえば次のようにします。

sftp -P 2222 user@example.com

接続後によく使う操作は次の通りです。

pwd
lpwd
ls
cd /var/www/html
put index.html
get error.log
mkdir backup
bye
  • pwd: リモート側の現在位置を確認
  • lpwd: ローカル側の現在位置を確認
  • put: ローカルからサーバーへ送る
  • get: サーバーからローカルへ取る

FTPの基本

Windowsのftpコマンドは、対話形式で使えます。

ftp ftp.example.com

接続後の基本操作は次のようになります。

user your_user
binary
cd /public_html
put report.zip
get access.log
bye

ここで初心者がつまずきやすいのが転送モードです。Microsoft Learnでも、テキストはascii、実行ファイルや画像などはbinaryを使う考え方が整理されています。実務では、HTMLやCSV以外も混ざりやすいため、迷ったらまずbinaryを確認するほうが事故を減らせます。

サンプル: 同じ作業をFTPとSFTPで比べる

「ローカルのrelease.zipをサーバーの/uploadsへ送る」作業を比べます。

SFTPで送る例

sftp deploy@example.com

接続後:

cd /uploads
put release.zip
ls
bye

想定される流れ:

  • SSHで接続
  • 認証後に暗号化された状態で転送
  • 送信後にlsで配置確認

FTPで送る例

ftp ftp.example.com

接続後:

user deploy_user
binary
cd /uploads
put release.zip
dir
bye

想定される流れ:

  • FTPサーバーへ接続
  • ユーザー名とパスワードを送信
  • binaryに切り替えて転送
  • dirで配置確認

同じアップロードでも、違いは見た目以上に大きいです。SFTPは認証と転送の保護を前提にしやすく、FTPは追加の安全策を考えないとそのまま使えません。

自動化するならどちらが向くか

定期転送やスクリプト実行では、SFTPのほうが管理しやすい場面が多いです。

OpenSSHのsftpにはバッチモードがあり、コマンドをファイルにまとめて実行できます。

SFTPのバッチ例

upload.txt

cd /uploads
put release.zip
bye

実行例:

sftp -b upload.txt deploy@example.com

この方法が実務で便利なのは次の点です。

  • 公開鍵認証と組み合わせやすい
  • パスワードの手入力を減らせる
  • ログや再実行の制御を組み込みやすい

認証情報の扱いで気を付けること

  • 秘密鍵は平文で共有しない
  • リポジトリへ鍵や接続先一覧をそのまま入れない
  • 自動化用アカウントは権限を絞る
  • 本番と検証で鍵や保存先を分ける

よくある失敗

比較記事として読むなら、ここがいちばん実務に効きます。

1. 「SFTPはFTPの安全版」とだけ覚える

半分は合っていますが、運用では雑すぎます。FTPとSFTPは別の接続方式です。サーバー側がFTPだけを有効にしているなら、SFTPクライアントではつながりません。

接続設定を見るときは、少なくとも次を確認してください。

  • プロトコル名: FTP か SFTP か
  • ホスト名
  • ポート番号
  • 認証方法: パスワードか公開鍵か

2. FTPでascii/binaryを意識しない

画像、ZIP、PDF、実行ファイルをASCIIモードで送ると壊れることがあります。文字列しか見ていないと見落としやすい部分です。

3. FTPの接続モードで詰まる

FTPはデータ接続の扱いが別なので、受動モードと能動モード、ファイアウォール、NATの相性で転送だけ失敗することがあります。

次の症状が出たら、単純な認証ミスではなく接続方式を疑ったほうが早いです。

  • ログインはできるのに一覧取得で止まる
  • 小さいファイルは送れるが大きいファイルで失敗する
  • GUIクライアントだけつながってCLIは失敗する

4. 鍵認証なのにホスト鍵確認を雑に通す

SFTPは暗号化されていても、最初の接続でホスト鍵確認を無視すると別のリスクが出ます。自動化時も、接続先の真正性を確認したうえで運用する必要があります。

FTPしか使えないときの現実的な対処

「今すぐ全部SFTPへ移せない」ケースは珍しくありません。その場合は、FTPを正当化するより、被害を小さくする設計に寄せるほうが現実的です。

最低限やっておきたいこと

  • 可能ならFTPS対応の有無を確認する
  • 専用アカウントを作り、書き込み先を限定する
  • 接続元IPを制限する
  • 機密データをFTPで流さない
  • 置きっぱなしにせず、アップロード後の保存期間を短くする
  • ベンダーや運用担当にSFTP移行の可否を確認する

関連ツールと代替手段

FTPとSFTPだけで考えず、要件に応じて別手段も見たほうが早いことがあります。

GUIで扱いたいとき

  • WinSCP: WindowsでSFTP/FTP/FTPSを切り替えやすい
  • FileZilla: GUIで接続設定を管理しやすい

単発コピー中心のとき

  • scp: 単純なファイルコピーなら手早い

Webサーバー配備まで含めるとき

  • Gitベースのデプロイ
  • CI/CDからの自動配置
  • オブジェクトストレージ経由の配信

「毎回手作業で転送する」こと自体がボトルネックなら、プロトコル比較だけでなく運用全体を見直したほうが効果は大きくなります。

迷ったときの判断基準

最後に、実務で迷いにくい基準だけ残します。

  • 新規で設定するならSFTPを第一候補にする
  • FTPの指定が来たら、まずFTPSやSFTPに変えられないか確認する
  • 認証情報をスクリプトへ埋め込む前に、鍵認証や権限制御を見直す
  • FTPでしか動かない仕組みは、更新時に置き換え候補として管理する

ファイル転送は地味ですが、事故が起きると復旧に時間がかかります。接続できるかどうかより、安全に続けられるかを基準に選ぶと、後から困りにくくなります。

参照リンク

プログラム
CLI FTP OpenSSH sftp SSH WinSCP サーバー運用 ファイル転送 初心者向け
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
目次