HULFT対応OS早見表：メインフレームからLinux/Windows・コンテナまで

「うちのHULFT、AWSに載せられますか」という問い合わせの多くは、実は「対応OSと実行環境の全体像」を一枚で見たいという要望です。HULFT10はメインフレームからLinux/Windows、さらにコンテナまでを一つの製品系列でカバーします。本記事では、個別のOSバージョンを断定せず、プラットフォーム区分という粒度で対応範囲を早見できるよう整理し、AWSへ載せるときの勘所まで踏み込みます。

HULFTの強みは、長年にわたる「マルチプラットフォーム対応」にあります。基幹の集配信をメインフレームで回しつつ、業務系はUNIXやWindows、新規はLinux、という混成環境をそのまま束ねられるのがHULFTを選ぶ理由でした。2024年12月にリリースされたHULFT10は、2014年のHULFT8以来2度目のメジャーバージョンアップで、この従来資産を維持したままコンテナ実行環境という新しい選択肢を加えています。本記事は、その対応範囲を「早見表」としてプラットフォーム区分の粒度で見渡し、AWSに載せるときに現場で迷いやすい点を先回りして押さえるためのものです。

01「マルチプラットフォーム対応」が意味すること

HULFT10が対応するプラットフォームは、大きく5系統に整理できます。メインフレーム（z/OS）、ミッドレンジ（IBM i）、UNIX（AIX）、Linux、Windowsです。ポイントは、これらが別製品ではなく同じHULFT10という製品系列で提供され、系統をまたいだファイル連携が同じ設計思想（集信・配信、転送前後ジョブ、配信確認）で組める点にあります。オンプレミスの基幹から、AWS上のEC2で動くLinux/Windowsまで、一貫したファイル連携を張れることが、移行や共存の設計を大きく楽にします。

02早見の粒度は「プラットフォーム区分」まで

下図に、HULFT10の対応範囲を一枚でまとめました。左が従来からのマルチプラットフォーム5系統、右がHULFT10で加わったコンテナ実行環境です。ここで意図的に「z/OS」「AIX」といった系統名までにとどめ、個別のOSバージョン番号は載せていません。動作環境の版数は改訂されますし、系統内でもサポート対象の版が細かく分かれるため、番号の早見は誤りのもとになるからです。正確な版数は、必ず公式の「動作環境」ページで最新を確認してください。

03第6の選択肢 ― コンテナという実行環境

HULFT10で新設されたコンテナ対応は、大きく2つに分かれます。ひとつはHULFT10 for Container Platformで、Kubernetes上で動作し、Red Hat OpenShiftにも対応（Red Hat Operator認定）します。もうひとつがHULFT10 for Container Servicesで、こちらはAmazon ECS上で動作し、AWS Marketplaceでのサブスクライブが必要です。いずれも構成の考え方は共通で、管理を担う「管理コンテナ」と、実際のファイル転送を担う「転送コンテナ」に役割を分ける設計になっています。従来のスタンドアロン（非コンテナ）版とは、運用モデルもストレージの考え方も別物だと捉えるのが出発点です。

AWS上でコンテナ版を採る場合、Container ServicesにはさらにEC2起動タイプとFargate起動タイプの2つがあります。Fargate起動タイプはバージョン10.1.0で対応し、CloudFormationテンプレートで配備できるサーバレス構成です。「どの実行環境を選ぶか」は、既存資産の版数だけでなく、運用体制（Kubernetesを自前で運用できるか、サーバレスに寄せたいか）で決めることになります。

04AWSに載せるときの落とし穴 ― ストレージを混同しない

対応OSの早見表と並んで、AWS移行で最も事故りやすいのがストレージの設計です。ここは3つのケースを明確に切り分ける必要があります。まず、スタンドアロン（非コンテナ）のHULFTをEC2で動かす場合、集配信ファイルの格納先は通常インスタンスのローカルディスク、すなわちAmazon EBS（ブロックストレージ）です。Amazon EFSをそのまま集配信のターゲットにはできません。使うにはHULFTの「ネットワークファイル対応」機能が前提となり、NFS（EFSはNFS）上のバイト範囲ロックによる排他制御や、NFSクライアントの属性キャッシュ無効化といった条件があり、単一ファイルへ複数プロセス／インスタンスから同時アクセスする使い方は避ける必要があります。EFSはEBSの単純な置き換えではない、というのが要点です。

EFSが「標準構成」に登場するのは、コンテナ版のContainer Services（EC2起動タイプ）で、複数コンテナ間の共有ファイル格納先としてEFSを用い、監査ログはS3に置くケースです。一方、Fargate起動タイプはストレージがS3（EFSではない）になります。つまり「スタンドアロンEC2＝EBSが基本／コンテナEC2起動タイプ＝EFS共有／Fargate起動タイプ＝S3」という3層を混同しないことが、設計の生命線です。

05オンプレミス〜AWSをまたぐ接続とマネージドサービス

対応OSが分かっても、実際の連携はネットワークをまたいで成立します。オンプレミスの基幹（メインフレームやAIX）とAWS上のHULFTをつなぐ場合、経路はVPNまたはDirect Connectで確保し、外部からの接続点にはNLBを置くのが定石です。Container Servicesの標準的な構成では、外部／内部トラフィックにALB、オンプレミス接続用にNLB、管理情報・転送履歴の保持にAurora MySQLといったマネージドサービスを組み合わせます。加えて、Secrets Manager、ACM、CloudWatch、Route 53、NAT Gateway、Auto Scaling Group、IAMが役割ごとに絡みます。

コンテナ版ならではの利点として、転送負荷に応じた転送コンテナの自動起動や、障害時の再起動、さらに転送の前後でWeb APIを呼び出す連携が可能です。これにより、従来はジョブスケジューラで組んでいた前後処理を、よりクラウドネイティブな形に寄せられます。どのマネージドサービスに何を担わせるかは、対応OSの選定と同じ重みで最初に設計しておくべきポイントです。

06版数とサポート ― 早見表に載せてはいけない情報

繰り返しになりますが、個別のOSバージョン番号は本記事の早見表に載せていません。これは意図的な設計です。動作環境は改訂され、系統内でも対象版が分かれるため、番号を固定で覚えるのは危険だからです。正確な版数は公式の「動作環境」ページを一次情報として参照してください。

サポートの考え方も、HULFT8とHULFT10で異なります。HULFT8（2014年リリース）は、レベルによらず期限が固定されており、製品販売終了が2025年6月30日、通常（標準）サポート終了が2030年6月30日、延長サポート終了が2035年6月30日です（延長サポートは、通常サポート終了後にさらに5年間が設定されているものです）。対してHULFT10のサポートポリシーは「レベル」単位で、原則として標準サポート5年＋メンテナンスサポート2年＋リミテッドサポート3年という構成になっています。移行計画を立てるときは、対応OSの可否と同時に、この「どのレベルがいつまで支えられるか」を突き合わせておくと、更新の谷を作らずに済みます。

07クラウド型という別解 ― HULFT Squareの位置づけ

「対応OSを気にせずデータ連携したい」というニーズには、もう一つの解があります。日本発のiPaaSであるHULFT Squareです。これはフルマネージドのSaaSで、GUIノーコードでデータ連携／ETLを組むHULFT Integrate、外部のHULFTとファイル転送するHULFT Transfer、そしてAPIマネジメントを備えます。GDPRやSOC2などにも対応しています。自社でOSやコンテナ基盤を持たずにデータ連携を始めたい、あるいは対外接続だけを素早く立ち上げたい、という場面では有力な選択肢になります。

まとめると、HULFT10は「従来のマルチプラットフォーム5系統＋コンテナ2種」という広い対応範囲を持ち、AWSに載せる際はストレージ（EBS／EFS／S3）とネットワーク（VPN／Direct Connect／NLB）の設計が要になります。EMWは、この早見表を出発点に、既存資産の版数確認からAWS上の実行環境選定、永続化設計までを一気通貫で支援しています。対応OSの可否で迷ったら、まずプラットフォーム区分の全体像から一緒に描いていきましょう。