なぜHULFT？ S3 Replicationや直接書き込みじゃダメなのか — ファイル連携の整合性を裏側から解説

「社内システム同士の連携なら、送信側がS3にPUTして、あとはS3 Replicationで別リージョンや別アカウントに複製すれば済むのでは？」——AWS移行の設計レビューで、ほぼ毎回出てくる問いです。結論から言えば、要件が緩ければそれで十分なこともあります。ただしHULFT（ハルフト）が標準で担ってきた「完全に届いてから処理する」という送達保証は、S3のレプリケーションや直接PUTには載っていません。この記事ではHULFT転送の裏側を開けて、S3との本質的な差を、ポジショントークにせず率直に整理します。

01なぜ「S3にPUTすれば終わり」と思ってしまうのか

クラウドネイティブに慣れるほど、ファイル連携は「置く側がS3にPUTし、受ける側がイベントで拾う」だけの単純な話に見えてきます。実際、新規に作るパイプラインならそれで正しいことも多いです。ところが基幹系から出てくる連携は、単なるコピーではありません。「配信の記録が残る」「届かなければ再送する」「相手が取り込み終わるまで完了扱いにしない」といった業務の作法が転送の内側に埋め込まれています。この作法がHULFTでは標準機能で、S3では自前実装になる——ここが問いの正体です。まずHULFTが裏側で何をしているのかを開けてみます。

02HULFTの中身：配信・集信と3つのシステム

HULFTでは送信を「配信」、受信を「集信」と呼びます。プロダクト内部は大きく配信システム・集信システム・要求受付システムの3つで構成されます。転送の起こし方は2通りで、配信側から送り出すプッシュ型は「配信要求」、集信側から相手に取りに行くプル型は「送信要求」です。受け取り側の集信処理は、ネットワークからデータを受信し、コード変換や圧縮の解凍を行い、最後に集信ファイルへ書き込む、という順で流れます。つまり「受信＝ファイルが書けた」ではなく、変換まで含めて業務が使える状態にして初めて書き込みが完了します。

03HULFTの「届いた」はハッシュ検証まで含む

HULFTは転送データからハッシュ値を作成してデータ検証を行い、配信側のデータと受信側のデータが一致していることを確かめます。「バイト数が合っていそう」ではなく、内容の同一性まで担保する設計です。さらに転送が回線瞬断などで中断した場合は、チェックポイント再送により中断箇所（チェックポイント）から再送を行い、すでに送り終えた分は再送しません。自動で再配信して正常終了まで持っていくため、運用側が手で送り直す必要がありません。転送の結果は完了コードで表され、0が正常、0以外が異常として扱われ、後続の分岐に使えます。

04集信後ジョブ連携：「後続が終わるまで完了にしない」

HULFTは集信完了後に後続ジョブ（取り込みバッチなど）を起動できます。ここが地味に重要で、集信完了通知を「正常時ジョブ完了」に設定すると、後続の正常時ジョブが終了するまで転送を完了扱いにしません。言い換えると、HULFTにおける「届いた」は、ファイルが完全に届き、ハッシュ検証が通り、さらに受信側の取り込み処理まで終わって初めて成立します。送り手から見て「相手が使える状態になった」ことまでが送達の定義に含まれる、ということです。この一気通貫の完了定義は、対外連携や締め処理のように「途中で止まっていることが最悪」の業務で効いてきます。

05S3 Replicationの実像：自動・非同期・結果整合性

ではS3 Replicationは何を保証するのか。これは指定したバケット間でオブジェクトを自動・非同期・結果整合性で複製する仕組みです。運用の手間なく複製が作られる点は強力ですが、順序保証・送達確認・再送・突合・後続処理との連動は、いずれも機能として持っていません。オプションのS3 Replication Time Control（RTC）を使うと「新規オブジェクトの99.9%を15分以内にレプリケートする」というSLAが付きます（99.99%は設計目標値で、SLAの保証水準は99.9%。これを下回るとサービスクレジットの対象になります）が、これには除外条件があり、そもそも複製速度の保証であって業務の作法ではありません。「15分以内に届く（ことが多い）」と「届いたと確認して次へ進む」は別物です。ここを同一視すると、締め処理の設計を踏み外します。

06S3直接PUTの実像：アトミックだが「まとまり」は守らない

もう一方の直接PUTはどうか。S3では単一オブジェクトのPUTはアトミックです。中途半端に半分だけ書かれたオブジェクトが見える、ということは起きません。ここは信頼してよい。問題はその外側です。複数ファイルで1つの業務的まとまり（ヘッダ＋明細、当日分の一式など）を成す場合の到達順序、失敗したときの再送、そして「全部そろってから一度だけ後続を起動する」冪等な制御は、すべて自前実装になります。「オブジェクトが置かれた」ことと「業務データが正しく届いた」ことの間には、この距離があります。両者の違いを1枚に整理すると次のようになります。

07だからHULFTを選ぶ——社内連携でも、AWS上でも

ここまでを踏まえると、HULFTを使う理由は「対外だから」だけではありません。送達保証・整合性検証・チェックポイント再送・後続ジョブ連動・世代管理・対外（取引先）互換を標準機能で持ち、「完全に届いてから処理する」を宣言的に組める——これが本質価値です。しかもAWS移行後もこの作法は捨てなくて済みます。既存の集配信定義をEC2でそのまま続投する道もあれば、コンテナ化して運用を寄せる選択肢として、Amazon ECS上で動くHULFT10 for Container Services（AWS Marketplaceでのサブスクライブが必要）もあります。この構成では管理情報・履歴をAurora MySQLに、オンプレミス接続をNLBで受け、経路はVPNやDirect Connectで結ぶ、といった形でAWSサービスと自然にかみ合います。「HULFTを残す＝クラウドに乗れない」ではない、という点は設計判断で押さえておきたいところです。

08正直に：S3で十分なケースと、検証で先に潰す落とし穴

ポジショントークにしないために正直に書きます。新規・社内・小規模で、送達確認が緩くてよく、後続処理が冪等——この条件がそろうなら、S3 + EventBridge + 冪等な取り込み処理で十分です。むしろその方が軽く、費用も運用も有利です。HULFTの価値が明確に出るのは、ミッションクリティカルな送達保証が要る、取引先との対外互換が要る、監査で「確かに届いた記録」が要る、という領域です。そして設計上の落とし穴は、本番ではなく必ずPoC・検証段階で先に踏み抜いておきます。たとえば当社の検証では、HULFT10 for Container ServicesのFargate起動タイプが永続化ストレージにS3を前提とする（EC2起動タイプの共有EFSやスタンドアロンEC2のEBSとは前提が異なる）ことを先に確認し、本番の永続化・共有設計を早い段階で見直しました。ストレージの前提を「EBS／EFS／S3どれでも同じ」と横並びに書いてしまうのが典型的な事故のもとで、ここを検証で潰しておくことが、本番での重大障害ゼロを支えています。