HULFTとは？ファイル転送の仕組みと暗号化・ジョブ連携の設計とiPaaS移行の判断基準を解説

HULFT（ハルフト）は、システムとシステムの間でファイルを確実に届けるための国産のミドルウェアです。開発元のセゾンテクノロジーは自社の製品ラインアップで「企業やシステム間でのファイル連携を実現する国内シェアNo.1のミドルウェア」と位置づけています。ただ、実装者が設計時に迷うのは製品の来歴ではありません。どの方式で転送するか、暗号化と経路をどう組むか、転送のあとにどの処理をつなぐかを先に決めないと、動くには動くのに障害のたびに人が張り付く連携ができあがります。本記事はその順番で設計を追いました。iPaaSという製品分類そのものの整理は別記事に譲り、ここではファイル転送レイヤの判断に絞ります。

本文の版番号と日付は、2026年8月31日にセゾンテクノロジーの公式サイト・製品マニュアル・公式FAQで確認した値です。同日時点の系列はHULFT10系で、Ver.10.0.0は2024年12月10日にリリースされています。

まとめ｜HULFTの採否は転送要件と運用体制と移行の期日で決まる

先に結論を置きます。採否は機能一覧では決まりません。判断を分けるのは、ファイル単位の確実な到達が要件の中心にあるか、異常時に人が動く運用体制を持てるか、いつまでに新しいリビジョンへ上げ続けられるかの三点です。

転送要件が第一の分岐になります。届ける対象が業務ファイルそのもので、届いたか届かなかったかを一件ずつ追跡したいなら、HULFTの設計思想は要件と噛み合います。逆に、レコード単位で他システムのAPIへ書き込みたい要件なら、転送製品では層が合いません。

運用体制が第二の分岐です。HULFTは転送の成否でジョブを分岐させる仕組みを備えており、異常時ジョブに何を書くかで運用品質が決まります。ここを設計せずに導入すると、転送は成功しているのに後続処理が止まっている状態を誰も検知できなくなります。

期日が第三の分岐です。公式FAQでは2026年8月31日時点で、HULFT8の通常サポート終了が2030年6月末・延長サポート終了が2035年6月末、HULFT10.2の通常サポート終了が2029年12月末・延長サポート終了が2034年12月末と案内されています。新しい系列のほうが期限が近いという逆転が起きるのは、期限がリビジョンの販売終了を起点に決まるためです。以下、この三点を設計の順に分解します。

HULFTとは配信と集信の対で動くファイル転送ミドルウェアである

HULFTは、送信側と受信側の両方に導入して初めて機能する製品です。ファイルを送ることを配信、受け取ることを集信と呼び、この二つが対になって一回の転送が成立します。両端に同じ製品を置いて管理情報を突き合わせる構成だと理解すると、設計の勘所がつかみやすくなります。

配信と集信という二つの役割とプッシュ型プル型の使い分けを押さえる

転送の起点は二通りあります。配信側が主導してファイルを押し出すプッシュ型と、集信側が要求を出して取りに行くプル型です。既定はプッシュ型で、業務処理の終わりに配信を起動する形が基本形になります。

プル型を選ぶ場面は限られます。集信側の都合で受け取るタイミングを制御したい場合や、配信側が常時稼働していない場合が代表例でしょう。ただしプル型は要求を受け付けるプロセスを配信側で待機させる構成になるため、通信の向きとファイアウォールの設定が変わります。

対応プラットフォームの広さも設計に効きます。公式の製品ページではWindows・Linux・AIX・IBM i・メインフレーム系のOSが対象と示されており、古い基幹環境を含む構成でも同じ製品で両端を揃えられる点が特徴です。HULFTが選ばれ続けている理由は、機能の豊富さよりこの範囲の広さにあると考えてください。

配信管理情報と集信管理情報を中心に管理情報の構成を先に押さえる

HULFTの設定は、いくつかの管理情報に分かれて格納されます。実装で触るのは主に次の五つです。

この構成で最初につまずくのはファイルIDです。配信側の配信管理情報と集信側の集信管理情報を、同じファイルIDで結び付けるのがHULFTの基本形になります。命名を場当たりで進めると、システムが増えたときに一覧から目的の定義を探せなくなります。業務区分・送信元・データ種別を含む規則を、最初の一本を作る前に決めてください。

ファイル転送の方式と暗号化は通信経路の性質から逆算して決めていく

転送方式の設計は、経路がどこを通るかで決まります。社内ネットワークで閉じるのか、拠点間の専用線を通るのか、インターネットを経由するのか。この違いが暗号化の要否と製品構成を変えます。

HULFT標準の暗号化と暗号オプションの線引きを要件から確認する

暗号化には二つの層があります。ひとつはHULFT標準暗号化方式で、これは同社独自の手法による暗号化です。マニュアルにはSSLやHTTP-Sは使用していないと明記されており、一般的なTLSによる経路暗号化とは別物だと理解しておく必要があります。

もうひとつがHULFT暗号オプションで、こちらはAESまたはC4Sタイプの暗号化方式を選べます。監査や取引先の基準でアルゴリズム名を求められる場面では、標準暗号化ではなくオプション側を前提に見積もることになります。

設定面の注意は暗号キーの運用です。配信管理情報と集信管理情報に同一の暗号キーを8から20バイトの英数字で指定する仕様のため、キーは相手先ごとに管理台帳を持つ前提になります。キーの受け渡し手段と更新手順を決めずに本番へ入ると、更新のたびに両端で作業を合わせる調整が発生します。

なお、HULFT10ではFIPS 140-2認証の暗号ライブラリの採用とPCI DSS v4.0への準拠対応が強化点として示されています。クレジットカード関連のデータを扱う連携で基準への適合を問われるなら、この点が版を上げる直接の理由になります。

圧縮方式とコード変換の設定が転送の所要時間と文字化けを左右する

転送時間の設計では圧縮の設定が効きます。HULFT10では新しい圧縮方式としてZstandardが採用され、ファイル転送速度の向上とCPU使用率の削減が強化点に挙げられました。圧縮率の高い方式ほどCPUを使うため、転送する時間帯とサーバの余力を見て設定してください。

文字コードの扱いはさらに事故が起きやすい箇所です。HULFTは転送時にコードセットの変換を行えますが、変換規則から外れた文字は意図しない形に置き換わります。設計段階で決めるのは、変換元と変換先のコードセット、変換不可文字の扱い、改行コードの扱い、そして固定長データの桁揃えの四つです。

インターネット経由の転送は中継サービスとの併用で切り分けていく

取引先とファイルをやり取りする構成では、両端にHULFTを置けるとは限りません。相手先が導入していない場合や、インターネット経由での接続が前提になる場合には、同社のSaaS型中継サービスであるHULFT WebConnectが受け皿として用意されています。

切り分けの考え方は単純です。自社が管理する拠点の間は製品同士の直接転送、管理の及ばない相手先との間は中継サービス、と層を分けてください。境界を曖昧にしたまま社外との接続を直接転送で押し通すと、相手先ごとに個別のネットワーク設定が積み上がります。取引先とのデータ交換が中心なら、EDI導入の進め方を工程順に整理した記事で扱う枠組みから入るほうが筋の良い設計になるでしょう。

ジョブ連携とスケジューリングは異常終了時の設計から組み立てていく

HULFTの実力が出るのは、転送そのものより転送の前後です。配信処理または集信処理が終了した時点でジョブを起動でき、正常終了と異常終了で別のジョブを割り当てられます。この分岐をどう使うかが、運用に載る連携かどうかを分けます。

集信後ジョブは正常終了時と異常終了時の分岐を最初に決めておく

集信後ジョブには、正常終了時に起動される正常時ジョブと、異常終了時に起動される異常時ジョブがあります。正常時ジョブに後続の取り込み処理を書くところまでは誰でも設計しますが、抜けやすいのは異常時ジョブのほうです。

異常時ジョブに書くべき内容は三つに整理できます。第一に、どの転送がいつ失敗したかを運用担当へ届ける通知。第二に、途中まで書き込まれたファイルを後続処理が拾わないようにする退避。第三に、再送の可否を判断するための情報を残すログ出力です。この三つが無い状態で異常時ジョブを空にしておくと、失敗が静かに通り過ぎます。

正常時ジョブ側にも落とし穴があります。集信が正常に終わったことと、業務データとして正しいことは別の話です。件数チェックやヘッダの整合確認を正常時ジョブの先頭に置き、そこで弾いた場合の扱いを異常系と同じ経路に流す設計にしておくと、後工程での手戻りが減ります。

既存のジョブ管理ツールとの役割分担を決めて二重管理を避けていく

スケジューリングで悩むのは、HULFT側で時刻起動を組むか、既存のジョブ管理ツールから配信コマンドを叩くかという分岐です。判断の基準は、その連携が単独で完結するか他ジョブと順序関係を持つかにあります。

単独で完結する転送、たとえば日次で一本のファイルを送るだけの処理なら、HULFT側で完結させて構いません。一方、基幹の夜間バッチの中に転送が挟まる構成では、順序と依存関係をジョブ管理ツール側に一元化し、HULFTは呼ばれて動く部品に徹するほうが破綻しません。両方でスケジュールを持つと、片方だけ変更されたときに二重起動や取りこぼしが起きます。

データの変換処理を挟む場合は、さらに層が増えます。転送はHULFT、変換と業務システムへの投入は別の製品、という分担が定石です。同社の製品ではDataSpiderのアダプタ構成とスクリプト設計を実装目線でまとめた記事で扱う領域がそこにあたります。どちらでも実現できる処理を両方に書くと、障害時にどちらを見ればよいか分からなくなるため、工程単位で持ち場を切ってください。

再送とリカバリの手順は運用担当が迷わない粒度まで落としておく

転送は失敗します。ネットワークの瞬断、相手先サーバの停止、ディスク容量の不足。どれも起こる前提で手順を用意しておきます。

手順書に落とすのは、失敗の種類ごとの初動です。通信エラーなら再送してよいのか、途中まで書かれたファイルを消してから再送するのか、二度取り込んだときに業務データが壊れるのか。この判断を障害の夜に考えさせないでください。二重取り込みの可否は後続処理が冪等かどうかで答えが変わるため、設計時に業務側と合意しておきます。

HULFT10で変わった前提を版番号と時点つきで押さえておく

ここからは版の話です。2026年8月31日時点で提供されている系列はHULFT10系で、メジャーバージョンのVer.10.0.0が2024年12月10日にリリースされました。新機能・非互換説明書は第7版（2026年5月1日発行）が公開されています。

圧縮方式と暗号ライブラリの更新は転送性能と監査対応に効いてくる

HULFT10の強化点として公表されているのは、新圧縮方式による転送速度の向上とCPU使用率の削減、FIPS 140-2認証の暗号化モジュールによるデータ暗号化、PCI DSS v4.0への準拠対応、インターネットを含む混合ネットワーク環境への対応、そして統合管理ミドルウェアによる管理と運用の負荷軽減です。

この並びは、版を上げる理由の優先順位をそのまま示しています。性能で困っていないなら急ぐ理由にはなりませんが、監査で暗号モジュールの認証を問われる、カード関連データを扱う、拠点がインターネット経由の構成に移った、といった条件のいずれかに当たるなら、版を上げること自体が要件への回答になります。

コンテナ版とAPI Gatewayが配置の選択肢をどう広げたか

HULFT10では、従来のサーバ導入以外の配置が増えました。コンテナ版のHULFT10 for Container ServicesはAmazon ECS対応として2024年2月9日に先行提供が始まり、Red Hat OpenShift対応の版も加わっています。リリース情報ではVer.10.5.0が2025年10月3日、Ver.10.6.0が2026年5月8日と公表されました。課金は利用時間に応じた従量制です。

もうひとつがHULFT10 API Gatewayで、オンプレミスとクラウドに分散した複数のHULFTを、REST APIとウェブ画面から統合的に管理するミドルウェアです。リリース情報ではVer.10.3.0が2025年11月6日と示されています。台数が増えて各サーバへ個別にログインして設定する運用が限界に来ている組織では、ここが版を上げる実務的な動機になります。

HULFT8からの移行はサポート期限より販売終了の期日で動く

移行判断で誤解が生まれやすいのが期限の読み方です。公式FAQに掲載されている期限は、2026年8月31日時点でHULFT8が通常サポート2030年6月末・延長サポート2035年6月末、HULFT10.2が通常サポート2029年12月末・延長サポート2034年12月末となっています。数字だけ見ると、新しいHULFT10.2のほうが先に終わることになります。

この逆転は、期限が世代ではなくリビジョンの販売終了を起点に決まる仕組みから生じます。原則として販売終了後の5年が通常サポート、さらに5年が延長サポートという構造のため、リビジョンが更新されるたびに前のリビジョンの時計が動き出します。HULFT10系を選ぶということは、リビジョンを上げ続ける運用を引き受けるということだと捉えてください。塩漬けで10年動かす前提の案件ほど、この構造が後で効いてきます。

その上で、HULFT8を使い続ける判断は現実的な選択肢として残ります。販売とサポートの終了日が示された以上、新規のライセンス調達は10系が前提になりますが、既存環境の移行時期は業務システムの更改サイクルに合わせて構いません。移行そのものを単独の案件にするより、基幹システムの更改や拠点統合と束ねるほうが、検証コストを一度で回収できます。

新規にHULFTを採用する条件と見送る場面を条件付きで言い切る

ここからは判断です。API連携やiPaaSが選択肢に入った現在、ファイル転送製品を新規に入れる場面は確実に狭まりました。それでも残る条件と、避けたほうがよい条件を分けて示します。

採用するのはファイル単位での確実な到達が要件の中心にある案件

採用してよいのは次の条件に当たる案件です。第一に、届ける単位がファイルそのもので、一件ごとに到達を確認して記録に残す必要がある場合。第二に、接続先にIBM iやメインフレームなど、APIの口を持たない環境が含まれる場合。第三に、取引先や拠点との間で転送本数が増え続け、本数に比例した課金を避けたい場合です。

三つ目は費用構造の話です。買い切りのライセンスを軸とする製品は、連携本数が増えても費用が読めます。接続数や実行回数で課金するSaaS型との分岐点はここにあり、連携が増える見込みの高い組織ほど後から効いてきます。

見送りたいのは接続先がSaaS中心で転送の単位が小さくなる案件

見送るべき条件も明確です。接続先がSaaSばかりで、やり取りしたい単位がファイルではなくレコードやイベントである場合、ファイル転送製品を挟むと余計な層が増えます。ファイルに書き出してから送り、受け側で読み直してAPIへ投入する構成は、途中の一時ファイルという壊れやすい部品を運用に加えるだけです。

もうひとつ、両端に製品を導入できない相手との連携も見送りの対象です。中継サービスで解けるなら別ですが、相手先の数が多く導入の合意形成が難しいなら、そもそも別の方式で組むほうが早く終わります。方式の選び分けそのものに迷うなら、iPaaSとETLの違いを連携方式5種の判定表で切り分けた記事で自社の要件がどこに落ちるかを先に確かめてください。

DataSpiderやHULFT Squareとの役割分担を工程で切る

同社の製品ラインアップは層で分かれています。オンプレミスのファイル転送がHULFT10、オンプレミスのデータ変換と連携がDataSpider Servista、クラウドサービス間の連携を担うiPaaSがHULFT Square、インターネット経由の中継がHULFT WebConnectという構成です。

実装で崩れやすいのは、HULFTとDataSpiderの境目です。どちらもファイルを扱えるため、変換処理をどちらに書くかで判断が割れます。原則は、転送はHULFT、データの解釈と業務システムへの入力はDataSpiderという工程での切り分けです。同じ処理を両方に持たせると、障害の切り分けに二倍の時間がかかります。

既存のEDIをどう扱うかも同じ構図で整理できます。レガシーEDIから寄せる場合の役割分担はiPaaSでEDI連携を組む場合の移行設計をまとめた記事で判定軸を示しました。転送そのものは既存の仕組みに残し、変換と業務連携だけを新しい層へ移すという段階的な進め方が、実務では通しやすくなります。

自社の要件がどの層に落ちるかを整理した上で、実装と運用まで含めて相談したい場合は、一創のiPaaS導入支援で連携方式の選定から設計・構築まで対応しています。転送製品を残すか寄せるかの判断を含めて、現行構成の棚卸しから伴走します。

よくある質問

HULFTの読み方と開発元はどこですか？

読み方は「ハルフト」です。開発と販売を手がけているのは株式会社セゾンテクノロジー（旧セゾン情報システムズ）で、同社は自社の製品ラインアップでHULFT10を国内シェアNo.1のファイル連携ミドルウェアと位置づけています。販社経由での導入例が多い製品のため、仕様やサポート期限の確認は開発元のサイトで行うのが確実です。

HULFTとFTPは何が違うのですか？

違いは到達の保証と運用機能にあります。FTPはファイルを転送するプロトコルで、転送後の処理起動、正常終了と異常終了の分岐、暗号キーによる相手認証、転送履歴の記録は自前で作ることになるでしょう。HULFTはこれらを製品として持ち、両端に導入して管理情報を突き合わせる形で運用します。単発のファイル移動ならFTP、毎日動かす業務ならHULFT側の設計思想が噛み合う形です。

HULFTの暗号化はSSLやTLSと同じものですか？

同じではありません。マニュアルではHULFT標準暗号化方式について、独自の手法による暗号化でSSLやHTTP-Sは使用していないと明記されています。AESなどアルゴリズム名を指定した暗号化が必要な場合はHULFT暗号オプションを利用します。監査要件でアルゴリズムの明示を求められるなら、オプションの導入を前提に見積もってください。

HULFT8からHULFT10へ移行する必要はありますか？

期限だけを理由に急ぐ必要はありません。公式FAQでは2026年8月31日時点でHULFT8の通常サポート終了が2030年6月末と案内されています。移行の実質的な動機になるのは、FIPS 140-2認証の暗号ライブラリやPCI DSS v4.0への対応、コンテナ環境への配置、API Gatewayによる統合管理といった機能面です。該当する要件が無いなら、基幹システムの更改時期に合わせて計画するのが妥当でしょう。

クラウド移行後もHULFTを使い続けられますか？

使えます。クラウド上の仮想サーバへ導入する構成に加え、Amazon ECSやRed Hat OpenShiftに対応したコンテナ版が提供されており、リリース情報ではVer.10.6.0が2026年5月8日と公表されました。接続先がSaaS中心へ移り、やり取りの単位がファイルからAPI呼び出しへ変わっていくなら、iPaaS側へ寄せる判断も並行して検討してください。

関連記事

• iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説：製品分類としての全体像を押さえられます。
• DataSpiderとは？アダプタ構成とスクリプト設計・オンプレ基幹連携の配置を実装目線で解説：同じ開発元の変換レイヤの設計を確認できます。
• iPaaSとETLの違いを実装視点で判定｜連携方式5種の選定表と分岐条件：連携方式の選び分けを判定表で確認できます。
• iPaaSでEDI連携は可能か｜レガシーEDIから寄せる移行設計と役割分担の判断：取引先とのデータ交換を移す場合の境界を確認できます。
• EDI導入の進め方｜六工程の手順と基幹システム連携・電子契約の使い分け：社外とのデータ交換を工程順に設計できます。