HULFT Square（iPaaS）と従来HULFT（HULFT10）の使い分け

「HULFT Square と HULFT10、どちらを選ぶべきか」という問いは、実は製品の新旧比較ではありません。基盤の面倒を提供側に預けてデータ連携そのものに集中したいのか、それともOSやミドルウェア、配信定義まで自分たちの手で細かく制御し、既存資産や特殊要件を守り抜きたいのか——運用の主語をどちらに置くかの選択です。本稿では、フルマネージドSaaSのHULFT Square（iPaaS）と、インストール型で自社運用する従来HULFT（HULFT10）を、運用負荷・制御性・接続要件の3軸で整理し、AWS上での構成差や両者の相互接続まで、現場目線で使い分けを描きます。

01問いは「新旧」ではなく「誰が運用するか」

HULFT Square と HULFT10 を並べると、つい「SaaSのほうが新しくて良さそう」という短絡に流れがちです。しかし両者は置き換えの関係ではなく、担う役割が違います。HULFT Square はデータ連携の基盤運用そのものを提供側に預けるフルマネージドSaaS、HULFT10 はOS上に導入して自社の手で運用するインストール型です。したがって最初に決めるべきは「どちらが高機能か」ではなく、「基盤運用を手放して連携ロジックに集中したいのか、それとも細部まで自分たちで制御し続けたいのか」という運用の立ち位置です。この軸が定まらないまま機能比較表を眺めても、結論は出ません。

02HULFT Square — 運用を預けるiPaaS

HULFT Square は、日本発のiPaaS（クラウド型データ連携プラットフォーム）で、フルマネージドのSaaSとして提供されます。中核となるのは3つの機能です。ひとつめは HULFT Integrate。GUIでノーコードにデータ連携やETL処理を組み立てられ、変換やルーティングを画面上で設計できます。ふたつめは HULFT Transfer。外部に立っている従来型のHULFTとファイル転送で連携でき、既存のHULFT資産と橋渡しができます。みっつめは APIマネジメントで、連携をAPIとして公開・管理できます。コンプライアンス面ではGDPRやSOC2などに対応しています。導入・アップデート・パッチ・可用性の維持といった基盤運用をユーザーが抱えずに済むため、「連携そのもの」に人的リソースを寄せられるのが最大の価値です。

03従来HULFT（HULFT10）— 自社で握る制御性

従来HULFT（HULFT10）は、2024年12月にリリースされた、HULFT8以来2度目のメジャーバージョンアップです。最大の特徴はマルチプラットフォーム性で、メインフレーム（zOS）、ミッドレンジ（IBMi）、UNIX（AIX）、Linux、Windows を横断してファイル連携を張れます。新機能としてはZstandard圧縮、FIPS 140-2認証の暗号モジュール、PCI DSS v4への対応、そしてコンテナ対応が加わりました。サポートは「レベル」単位のポリシーで、原則として標準サポート5年に加えメンテナンスサポート2年・リミテッドサポート3年という考え方です（旧HULFT8はレベルによらず固定の期限で、通常技術サポートは2030年6月30日まで、延長技術サポート（有償）は2035年6月30日まで）。細かなOS版数やサポート期限の詳細は、必ず公式の動作環境・サポート情報を参照してください。既存の配信定義やジョブ資産を活かし、OS権限やネットワーク経路まで自分たちで作り込めるのが従来型の強みです。

04使い分けの3軸 — 運用負荷・制御性・接続要件

判断は、次の3軸に落とし込むと迷いにくくなります。第一に運用負荷。基盤の面倒を手放したいなら Square、運用体制を持ち自社標準で回したいなら HULFT10。第二に制御性・カスタマイズ。標準化された連携で足りるなら Square、配信定義・外部連携・OS権限まで細部を作り込む必要があるなら HULFT10。第三に接続・既存資産・特殊要件。メインフレームを含む多様なプラットフォームや、既存のHULFT配信資産、規制対応・暗号要件が絡むなら従来型が担い、逆に新規のデータ連携やAPI連携を素早く立ち上げたいなら Square が効きます。下図はこの3軸を一覧にしたものです。

05二者択一ではない — HULFT Transfer で相互接続

実務で重要なのは、両者が排他ではないという点です。HULFT Square の HULFT Transfer 機能は、外部に立っている従来型のHULFTとファイル転送で相互接続できます。つまり「クラウド側の新しい連携は Square で軽く回し、既存のオンプレミス／サーバ導入型の配信は HULFT10 が担い、両者を HULFT Transfer で橋渡しする」というハイブリッド併存が成り立ちます。全面刷新を一気に迫るのではなく、動いている配信を止めずに、価値の高いところから段階的にSaaS化していける——この移行のしなやかさが、HULFTファミリーで揃える利点です。

06AWSで従来HULFTを動かす場合の構成差

従来HULFT（HULFT10）をAWSで動かす選択肢は複数あり、ここでストレージ設計を混同しないことが肝心です。スタンドアロン（非コンテナ）のHULFTをEC2で動かす場合、集配信ファイルの格納先は通常インスタンスのローカルディスク、すなわちAmazon EBS（ブロックストレージ）です。EBSの代わりにEFSをそのまま集配信ターゲットにはできません。EFSを使うにはHULFTの「ネットワークファイル対応」機能が前提で、NFS上のバイト範囲ロックによる排他制御やNFSクライアント属性キャッシュの無効化といった条件があり、単一ファイルへの複数プロセス・複数インスタンスからの同時アクセスは避ける必要があります。一方、EFSが「標準構成」として登場するのはコンテナ版のHULFT10 for Container Services（Amazon ECS上で動作、AWS Marketplaceでのサブスクライブが必要）です。EC2起動タイプでは複数コンテナ間の共有ファイル格納先としてEFSを用い、監査ログはS3へ、そしてFargate起動タイプ（バージョン10.1.0で対応、CloudFormationで配備）ではサーバレスでストレージはS3となります。周辺サービスは、管理情報・履歴をAurora MySQL、オンプレミス接続をNLB、外部／内部トラフィックをALB、鍵管理をSecrets Manager、証明書をACM、監視をCloudWatchが担い、オンプレミスとはVPNまたはDirect Connectで結びます。Square を選べば、こうした基盤の作り込みと運用そのものを持たずに済みます。

07落とし穴は検証で先に踏み抜く

私たちは、コストや設計の落とし穴をPoC・検証段階で先に踏み抜き、本番では未然に防ぐことを徹底しています。たとえば、あるコンテナ化の検証では、Fargate起動タイプはEFSではなくS3が前提だと早い段階で確認できたため、本番の永続化設計とファイルの受け渡し方式を先に見直しました。EC2起動タイプの想定でEFS前提のまま進めていたら、後戻りは避けられませんでした。スタンドアロンのHULFTをEC2に載せる案件でも、EFSを安易に集配信先に選ばず、「ネットワークファイル対応」機能やNFSの排他・属性キャッシュ条件を検証で先に押さえてから構成を確定しています。SaaSであるHULFT Squareを絡める場合は、SaaSからオンプレミスへの到達経路・接続条件（ネットワーク要件やファイアウォールの許可方針など）を検証で先に確認し、契約・サービス仕様上の前提とあわせて設計に織り込みます。既存のHULFT資産についても、そのままSquareへ持ち込めるわけではないため、移行対象と再作成が必要な範囲を検証段階で切り分けます。こうして先に潰しているからこそ、EMWは重大障害0を継続できています。

08まとめ — 使い分けの結論

結論はシンプルです。基盤運用を手放して連携ロジックに集中したく、対象が新規のデータ連携やAPI連携中心なら HULFT Square。細かい制御やカスタマイズ、メインフレームを含む多様なプラットフォーム、既存のHULFT配信資産、規制・暗号といった特殊要件を抱えるなら従来HULFT（HULFT10）。そして現実には、多くの現場で「新しい連携は Square、既存の配信は HULFT10、両者を HULFT Transfer でつなぐ」という併存が最も無理のない解になります。どちらか一方に決め切る前に、運用主体・制御要件・接続要件の3軸を書き出し、迷う部分は小さな検証で先に確かめる——この手順が、後戻りの少ない選択につながります。製品仕様やサポート・動作環境の細部は、必ず公式情報で最新の値を確認してください。