1. はじめに
こんにちは！HULFT Squareとオンプレ環境のネットワーク連携を紐解くシリーズの第2回です。
前回（第1回）は、各通信プロトコルとネットワーク経路の全体像をまとめた一覧をご紹介しました。
第2回となる今回は、データの即時性を求められるリアルタイム連携向きの「REST API連携」について深掘りします。
HULFT SquareにおけるREST API連携は、「オンプレ環境からHULFT Squareへ入れる（Inbound）」のか、「HULFT Squareからオンプレ環境へ送る（Outbound）」のかによって、ネットワーク経路が異なります。構成図を基に要所を解説します。
2. Inbound（オンプレ環境 ➔ HULFT Square）のネットワーク構成
オンプレ環境のシステムから、HULFT Squareが公開しているAPI（REST APIジョブ）を呼び出す際の構成図がこちらです。
※本図は、2026年5月末時点の仕様に基づき、全体の通信フローを簡潔に表現した構成図です。
💡 設計の見極め：Inboundはインターネット経由
第1回の一覧にも記載した通り、HULFT Squareの仕様として、外部からAPIを呼び出してもらう「REST APIジョブ」は、AWS PrivateLinkやVPN経由での接続に対応していません。
そのため、オンプレ環境から通信を開始するインバウンド通信においては、上図の通りインターネット（公衆回線）を経由した接続となります。
🔒 インターネット経由でも安全な理由
「インターネット経由」の接続ですが、HULFT Squareの機能により、セキュリティは以下のように担保されています。
- プログラムからの呼び出しを想定：外部システムから安全にジョブを実行するための専用エンドポイントを提供。
- Bearer認証（トークン認証）：有効なトークンを持つ正当なリクエストしか受け付けないため、公衆回線であっても不正アクセスやジョブの不正実行を防止。
社内のセキュリティ要件で「どうしてもインターネットへ通信を出せない」という場合は、後述するOutbound（HULFT Square側から通信を開始する形式）への設計変更、または別プロトコル（HULFT連携など）への切り替えを早い段階で検討する必要があります。
3. Outbound（HULFT Square ➔ オンプレ環境）のネットワーク構成
HULFT Square側でトリガー（スケジュールやファイル検知など）が発生し、オンプレ環境にある社内システムのWEB APIを呼び出す際の構成がこちらです。
※本図は、2026年5月末時点の仕様に基づき、全体の通信フローを簡潔に表現した構成図です。
💡 設計の見極め：Outboundは「閉域構成」の構築が可能（推奨）
インターネット経由の一択だったInboundとは異なり、OutboundにおいてはAWS PrivateLinkを活用した「閉域構成」が可能です。これがHULFT SquareにおけるREST API連携の構成となります。
具体的には、以下のネットワーク経路を辿ります。
- HULFT Square側のVPCエンドポイントを経由し、お客様VPC環境のVPCエンドポイントサービスに向けて通信を確立。
- AWS VPCからオンプレ環境へは、専用線（AWS Direct Connect）またはVPNを経由。
この構成をとることで、HULFT Squareからオンプレ環境のシステムを呼び出す通信はすべて閉域環境内で完結します。社内のセキュリティポリシーが厳しく、「社内APIをインターネットに公開したくない」というケースでも、この構成であればクリアできることでしょう。
4. REST API連携の設計で押さえておきたいポイント
第2回の締めくくりとして、REST API連携を採用する際に押さえておくべき「通信の向きによる特性の違い」について整理します。
① 通信の「向き」によるネットワーク経路の違いと、構成流用時の注意点
実際のプロジェクトにおいて、「インバウンド」か「アウトバウンド」かという通信の向き自体は、システムの要件（どちらが処理のトリガーになるか）によって初期段階で明確に決まるため、ここで迷うことはあまりないのではないかと思います。
ただし注意が必要なのは、「すでに片方の向きで実績があるから、もう片方の向きを追加するときも同じネットワーク構成をそのまま流用できる」と考えてしまうケースです。
同じREST API連携であっても、通信の向きが変われば、以下のように利用できる経路やセキュリティの考慮点が異なります。
-
Outboundの実績をInboundに流用しようとする場合
「先にHULFT Squareから社内APIを呼び出す（Outbound）仕組みを、PrivateLink（閉域網）を使って構築した。その後、オンプレ環境からHULFT SquareのAPIを呼び出す（Inbound）処理を追加することになったが、既存のPrivateLinkはそのまま流用できない（インバウンドは仕様上インターネット経由＋Bearer認証となる）」というケースです。この場合、インバウンド用のセキュリティ設計を別途行う必要があります。 -
Inboundの実績をOutboundに流用しようとする場合
「先にオンプレ環境からHULFT Squareを呼び出す（Inbound）処理を、インターネット経由＋Bearer認証でシンプルに構築した。その後、逆向き（Outbound）の処理を追加する際、同じようにインターネット経由で社内システムにアクセスさせようとすると、社内のセキュリティポリシー（社内APIのインターネット公開制限）に抵触する」というケースです。この場合は、Outbound用にPrivateLinkの検討が必要になります。
このように、同じAPI連携であっても「向き」が変わればネットワークの特性が異なるため、それぞれ個別に最適な経路を評価・設計することが大切です。
② 他の連携方式も含めた「最適な選択」は最後に比較する予定です
今回はREST API連携にスポットを当ててその特性を解説しましたが、HULFT Squareには他にも多くの連携手段（HULFT連携、SFTPやFTP連携など）が用意されています。
「自社の要件において、本当にREST API連携がベストなのか？」「他の方法を選んだ方がネットワーク設計がシンプルになるのではないか？」という疑問に対する答えとして、本連載の最後に、通信パターンのメリット・デメリットを網羅した比較一覧を公開する予定です。
まずは「API連携には向きによる特性の違いがある」という点を頭の片隅に置きつつ、全体の設計を進めていくのがおすすめです。
▼ 次回の記事はこちら
今回はREST API連携におけるインバウンド・アウトバウンドのネットワーク挙動と、設計時の考慮事項について解説しました。
次回（第3回）は、HULFT Squareのもう一つの柱である「HULFTアプリケーション（ファイル転送）連携」について深掘りします。REST APIとは異なるネットワーク要件や、PrivateLinkの活用方法を解説しますので、あわせてご覧ください！
※本記事は、対応する通信プロトコルやネットワーク経路、必要な追加機能の依存関係を2026年5月末時点の情報で簡易的に整理したものです。実際の提案・設計・構築にあたっては必ずHULFT Squareのマニュアルをご確認ください。