FTPは「File Transfer Protocol」の略で、ネットワークで接続されたコンピュータ間でファイルを転送するためのプロトコルだ。

　用途は分かりやすい。遠くにあるコンピュータへファイルを送りたい、あるいは、そこに置かれたファイルを受け取りたいときに利用する。FTPサーバとFTPクライアントが共通の手順に従うことで、機種やOSが異なっていてもファイルをやりとりできた。

　身近な用途の一つが、Webサイトの更新だ。作成したHTMLファイルや画像をFTPクライアントでWebサーバへ転送すると、更新内容が公開される。画面の左側に手元のフォルダ、右側にサーバのフォルダを表示し、ファイルを移動した経験のある人もいるだろう。

　企業では、取引先との受発注データの交換、拠点からの集計ファイルの回収、機器が出力したログの転送などにも利用された。人が操作するだけでなく、決められた時刻にプログラムがファイルを送り、別のシステムが受け取るといった自動処理にも組み込みやすかった。

　人によるファイルの受け渡しと、システム間の自動転送。その両方に使える単純で汎用（はんよう）的な仕組みだったことが、FTPが広く普及した理由の一つだ。

なぜ主役から降りたのか

　企業がネットワークを介して扱うデータが増えるにつれ、単にファイルを「送れればよい」では済まなくなった。誰が送り、誰が受け取れるのか。通信の途中で内容を見られないか。問題が起きたときに履歴を追えるか。管理すべき範囲が広がっていったからだ。

　もともとのFTPは、利用者名やパスワード、転送するデータを暗号化しない。そのままインターネット経由で利用すると、認証情報やデータを盗み見られる恐れがある。また、制御用とデータ転送用に別々の接続を使う仕組みは、ファイアウォールやNATを越える際の設定を複雑にすることもあった。

　転送経路を暗号化する方法として、FTPをTLSで保護する「FTPS」がある。SSHの仕組みを利用する「SFTP」も広く使われているが、SFTPは名前こそ似ているものの、FTPとは別のプロトコルだ。どちらも転送経路を保護できる一方、接続設定や認証情報、サーバなどを管理する必要は残る。

　人がファイルを受け渡す場面では、クラウドストレージやファイル共有サービスが広がった。管理された場所にファイルを置き、相手にはファイルそのものではなく共有リンクを渡す。閲覧だけを許可する、公開期限を設定する、社内アカウントで認証する、アクセス履歴を残すといった機能も利用できる。

　さらに、Webアプリ上で複数人が同じ文書を編集する働き方も一般的になった。ファイルを相手のサーバへ「送る」だけでなく、管理された場所に置き、必要な人と「共有する」。日常業務では、認証や権限、履歴、共同作業まで扱えるクラウドサービスが適する場面が増えた。

　一方、システム間でファイルを自動転送する用途では、SFTPやFTPSのほか、監視や再送、証跡管理などを一元化できるMFT（マネージドファイル転送）製品も選択肢になった。ファイル単位の受け渡し自体を見直し、APIやメッセージングを利用する方法もある。

　FTPが主役を降りたのは、ファイルを転送できなくなったからではない。人による共有とシステム間連携のそれぞれで、企業が求める管理や安全性の水準が上がり、用途に応じた別の選択肢が広がったからだ。

主役を降りたFTPが、現在も残る理由

　それでも、FTPは消えていない。長年稼働している業務システムや工場・店舗の機器、閉じたネットワーク内での連携、取引先と合意済みのデータ交換などでは、今も使われている。

　こうした仕組みでは、通信方式だけを切り離して変更できないことが多い。ファイル名や文字コード、保存先、送信時刻、再送方法、受信後の処理まで含めて、一連の業務が設計されているからだ。古いシステムが新たな通信方式に対応できず、置き換えるにはシステム全体の改修が必要になることもある。

　安定して動いている処理を変更すれば、試験や移行、障害対応にも費用がかかる。接続先が社外であれば、自社の判断だけで一方的に停止することもできない。

　FTPには導入当時の合理性があり、現在は移行コストや接続先との関係によって維持されている場合がある。残っているという理由だけで、直ちに廃止すべきとはいえない。

　ただし、「昔から動いている」は、安全性を確認せずに使い続けてよい理由にはならない。通信経路や認証情報、公開範囲、扱うデータ、利用実態が分からないまま放置されたFTPは、情シスが把握すべきリスクだ。

「残っている理由」と「残してよい理由」を分ける

　維持するか刷新するかを判断するには、FTPというプロトコルだけでなく、それが支えている業務の確認が必要だ。

　誰と何のファイルを交換し、止まるとどの業務に影響するのか。人が操作しているのか、システムが自動処理しているのか。接続先や利用者、データの機密性、転送頻度、障害時の再送方法まで洗い出す。

　現在の対策も確認したい。インターネット上で平文のFTPを使っていないか。認証情報の管理主体や更新方法は明確か。不要なアカウントが残っていないか。アクセス元を制限しているか。ログを保存し、異常な接続を検知できるか。サーバやソフトウェアを更新できる状態か。問題があれば、移行を待たずに可能な範囲でリスクを下げる必要がある。

　刷新方法は一つではない。人が社内外と文書を共有するなら、権限や期限を管理できるクラウドストレージが適する場合がある。定型的な企業間転送で、監視や再送、証跡が重要ならMFT製品を検討できる。既存システムが対応できるならSFTPやFTPS、ファイル単位の連携そのものを見直せるならAPIやメッセージングも候補になる。

　一方、用途と利用者が限定され、通信経路を制限・監視でき、影響と対策も把握できているなら、見直し期限と責任者を定めた上で維持する判断もあり得る。比較すべきなのは、リスクや業務上の必要性、代替手段、移行コストだ。

　残っている理由と、残してよい理由は同じではない。「古いから廃止」「動いているから継続」と決めるのではなく、その転送処理に埋め込まれた業務を可視化し、これから誰がどのように管理するかを決め直す。それが、FTPを見直すということだ。

死神管理人：　FTPは古いのだから、見つけたらすぐに全て廃止すればよい、という話ではないんだね。

アンデッド管理人：　そう。平文のFTPを無防備に使うことは避けるべきだけれど、移行するなら、そのFTPが支えている業務や接続先まで確認しなければならない。

死神管理人：　残っている理由と、残してよい理由は分けて考える必要がある、と。

アンデッド管理人：　そういうことだ。FTPは、ファイルを遠くへ運ぶという課題に応えた。その後、企業が求めるものは、安全な共有や追跡、共同作業を含む管理へ広がった。システム間連携でも、より安全で管理しやすい選択肢が増えている。

死神管理人：　情シスが判断する対象は、プロトコルだけではなく、その向こうにある業務ということだな。

アンデッド管理人：　FTPは単なる昔の技術ではない。今の業務と管理の形を映し出す、古いけれど無視できない存在なんだ。