HULFTバージョン別ガイド：HULFT8 / HULFT10 / HULFT Square で何ができて何ができないか

HULFTは長く日本の基幹系ファイル連携を支えてきましたが、いまや「HULFT8・HULFT10・HULFT Square」という世代も形態も異なる三択があり、どれも“HULFT”と呼ばれます。販売終了済みの現役資産、2024年末に出た最新版、そしてクラウド型のiPaaS——それぞれ得意・不得意が違います。本稿ではAWS移行を見据えて、三者の「できること・できないこと」と選び方を、現場の設計判断として整理します。

01同じ“HULFT”に三択がある — まず全体像

「HULFTを使い続けたい」という相談でも、実体は三つに分かれます。2014年リリースで販売終了済みのHULFT8、2024年12月に登場した最新のHULFT10、そしてクラウド型のiPaaSであるHULFT Squareです。世代（バージョン）だけでなく、オンプレミス／EC2で動かすスタンドアロン、コンテナ、フルマネージドSaaSという形態の違いも重なるため、「できること・できないこと」は三者三様になります。まずは一枚の比較マップで俯瞰し、そのうえで各世代を掘り下げます。

図：同じ“HULFT”でも、HULFT8（販売終了・延命）、HULFT10（最新・コンテナ対応）、HULFT Square（iPaaS/SaaS）は形態も得意分野も異なる。世代と形態をセットで選ぶ。

02HULFT8：2014年の資産、いまは“延命と移行計画”のフェーズ

HULFT8は2014年リリース、すでに販売終了済みですが、いまも多くの基幹系で現役です。サポートの考え方はHULFT10と大きく異なり、レベル（バージョンの細かな刻み）によらず固定で、通常サポート（Standard Support）は2030年6月30日まで、延長サポート（Limited Support）は2035年6月30日までと公式に案内されています（延長サポートは通常サポートに対して料金が1.5倍。期間は通常・延長ともおおむね各5年）。できることは、長年育てた集配信定義をそのまま動かし続けること。オンプレミスのサーバをEC2へ載せ替えて“続投”させる移行も現実的です。一方でZstandard圧縮やコンテナ対応といったHULFT10の新機能は載らないため、新規案件でHULFT8をあえて選ぶ理由は乏しく、位置づけは「延命しつつ、期限を起点に移行計画を立てる」フェーズにあります。

03HULFT10：2024年12月の新基準

HULFT10は、HULFT8（2014年）以来2度目のメジャーバージョンアップとして2024年12月にリリースされました。メインフレーム（z/OS）、ミッドレンジ（IBM i）、UNIX（AIX）、Linux、Windowsを横断するマルチプラットフォーム対応はそのままに、Zstandard圧縮、FIPS 140-2認証の暗号モジュール、PCI DSS v4対応、そしてコンテナ対応が新たに加わりました。サポートは「レベル」単位で、原則として標準サポート5年＋メンテナンスサポート2年＋リミテッドサポート3年という考え方です。対応OSの個別バージョンは更新されていくため、本稿では列挙せず、必ず公式の動作環境ページで最新を確認してください。新規構築や大規模更改では、まずHULFT10を基準に据えるのが妥当です。

現場のコツ：FIPS 140-2やPCI DSS v4といった要件は、後から足すと構成全体の作り直しになりがちです。カード情報や個人情報を扱う連携なら、世代選定の段階でHULFT10を前提に置き、暗号モジュールや監査ログの要件を設計初期から統制側と握っておくと手戻りが減ります。

04コンテナという新しい形態：Platform と Services を混同しない

HULFT10のコンテナ対応には二つの製品があり、混同しないことが重要です。HULFT10 for Container PlatformはKubernetes上で動作し、Red Hat OpenShift（Red Hat Operator認定）に対応、管理コンテナと転送コンテナで構成します。HULFT10 for Container ServicesはAWS向けで、AWS Marketplaceでのサブスクライブが必要、Amazon ECS上で動きます。起動タイプは二つあり、EC2起動タイプはストレージにAmazon EFSとS3を用い（EC2起動時にEFSをマウント）、Fargate起動タイプはバージョン10.1.0（2024年6月）で対応、サーバレスでストレージはS3、CloudFormationテンプレートで配備します。いずれも管理コンテナ（hulft-control-container）と転送コンテナ（hulft-transfer-container）の構成で、Aurora MySQL（管理情報・履歴）、ALB（外部／内部トラフィック）、NLB（オンプレミス接続）、Secrets Manager、ACM、CloudWatchなどのAWSサービスと組み合わせます。転送負荷に応じた転送コンテナの自動起動・障害時再起動や、転送前後のWeb API呼び出しといった、スタンドアロン版にはない運用の自動化が持ち味です。

05HULFT Square：ノーコードのiPaaS/SaaSという第3の道

HULFT Squareは日本発のiPaaS（クラウド型データ連携プラットフォーム）で、フルマネージドのSaaSとして提供されます。主要機能は、GUIでノーコードにデータ連携・ETLを組むHULFT Integrate、外部のHULFTとファイル転送するHULFT Transfer、そしてAPIマネジメントです。GDPRやSOC2などにも対応しています。できることは、自前で基盤を構築・運用せずに連携を素早く立ち上げること、そして既存の（オンプレミスやEC2上の）HULFTとも転送でつながること。逆に、基盤を細かく作り込みたいケースや、完全オフライン・特殊なOS要件が絡むケースでは、スタンドアロンのHULFT10やコンテナ版のほうが適することがあります。「基盤を持つか、持たないか」が、HULFT SquareとHULFT10を分ける最初の問いです。

06ストレージ設計の落とし穴は検証で先に踏む（EBS/EFS/S3を同列にしない）

三者・三形態を扱ううえで最も事故りやすいのがストレージ設計で、ここは形態ごとに明確に分かれます。スタンドアロン（非コンテナ）のHULFTをEC2で動かす場合、集配信ファイルの格納先は通常インスタンスのローカルディスク＝Amazon EBS（ブロックストレージ）です。EFSをそのまま集配信のターゲットにはできません——使うにはHULFTの「ネットワークファイル対応」機能が前提で、NFS（EFSはNFS）上のバイト範囲ロックによる排他制御やNFSクライアント属性キャッシュの無効化といった条件があり、単一ファイルへの複数プロセス／インスタンスからの同時アクセスは避ける必要があります。EFSが“標準構成”として登場するのは、コンテナ版のHULFT10 for Container Services（EC2起動タイプ）が複数コンテナ間の共有ファイル置き場としてEFSを使う場合で、監査ログはS3です。Fargate起動タイプはストレージがS3であり、EFSではありません。EBS・EFS・S3を安易に同列の「集配信先」として並べないことが肝心です。

現場のコツ：ある案件のPoCで、Fargate起動タイプはEFSではなくS3前提であることを検証段階で先に踏み抜き、本番の永続化設計（共有が要る処理はEC2起動タイプ＋EFS、サーバレスで割り切る部分はS3）を作り込む前に見直しました。EBS前提の設計をそのままコンテナに持ち込むと、本番で「ファイルの置き場所が想定と違う」という手戻りになります。EMWでは、この種のストレージ前提を検証で先に確定させることで、本番の重大障害を未然に防いでいます。

07どれを選ぶか：判断の軸とマイグレーション

最後に、判断の軸を整理します。①既存のHULFT8資産を活かすなら、まず通常サポート終了の2030年6月30日（延長サポート／最終サポート終了は2035年6月30日）を起点に、延命と移行のスケジュールを引くのが出発点です。②オンプレミス〜AWSで作り込みたい新規・更改なら、HULFT10を基準に、単純な集配信はスタンドアロンをEC2（ストレージはEBS）で、スケールや運用自動化が要るならコンテナ版（ECSのEC2／Fargate）を選びます。③基盤を持たず素早く連携を立ち上げたい、SaaSで割り切れるならHULFT Squareが有力です。いずれの場合も、対外接続の回線（VPN／Direct Connect）、オンプレミス接続用のNLB、管理情報を預けるAurora、鍵を預けるSecrets Managerといった周辺の設計が実装品質を左右します。世代・形態・ストレージ・回線をセットで決めることが、HULFT×AWSを安定稼働させる近道です。