Webhookを利用する
Webhookとは主に外部のサービスからイベントを受け取りたい場合に利用される仕組みです。
例えば、図3のようにあらかじめ外部サービス側で特定のイベントが生じた場合に、指定のURLにそのイベントを通知してもらうようにします。
最近のクラウドサービスなどでは、このWebhookインターフェースが用意されているものが非常に多くなっています。
例えば、決済サービスでWebhookを利用する場合、支払いがどんな方法で行われたか、いつ完了したかを販売サイト側で管理せずとも、必要な処理が完了した段階でその通知を受けて処理を進められます。
ただし、今回のWebhookの利用は、Webhookリクエストを受け取る側ではなく、Webhookのリクエストを送信する側の立場での話です。Webhookを利用することで、バリューレイヤーで発生した状況やデータの変化を通知でき、図4のような利用が可能となります。
本来、バリューレイヤーにおいて処理の途中経過やデータの部分的な把握は、主要な機能ではありません。バリューレイヤーの主要な責務はビジネスロジックの実行であり、UIの表示制御ではないため、本来は途中経過を厳密に管理する必要はないのです。
しかし、ユーザー体験の向上といった観点からは、進行状況のフィードバックは重要です。そうした状況の通知に利用するのが、Webhookとなるわけです。
Webhookは、前述のREST API連携などと比較して、以下のメリットがあります。
リアルタイムでのシステム連携
バリューレイヤーで「注文処理が完了した」「在庫が変動した」といったイベントを、即座に連携先のシステムに通知できます。ポーリングのように定期的な確認が不要なため、遅延が少なく、常に最新の情報に基づいて連携できます。
実装がシンプル
ビジネスロジックの実装者は、通知先のシステムがそのデータを使って何を行うかを意識する必要がありません。例えば、注文処理を実行する際、在庫数の変化をUI上に反映するか、配送手配が行われたかをフィードバックするかなどを、バリューレイヤーが意識する必要はありません。
これにより、ビジネスロジックは本来の処理に集中でき、コードの複雑化を防ぎます。また、通知処理などの補完的な処理でエラーが発生した場合も、ビジネスロジックの処理フローにまで影響が及ぶ可能性は低くなります。
効率的なリソース利用
従来のAPI連携、特に同期的なAPI呼び出しでは、リクエスト元は処理が完了するまでサーバーからの応答を待つため、リソースを消費する可能性があります。一方、Webhookはイベント発生時のみに通知を送信するため、不要なリクエストを減らし、リソースを効率的に利用できます。
また、サーバーレス（AWS Lambdaなど）のようなイベント駆動型の環境との親和性が高く、必要な時だけ処理を実行できるため、コスト削減につながります。例えば、大量の注文が集中する部分だけWebhookの処理を実行するといった運用も可能です。
スケーラビリティの向上
Webhookを利用する場合、イベントを送信するシステムと、その通知を受け取るシステムを独立して運用できます。ECサイトの注文システムと、在庫管理システム、配送システムを別々のサーバーやサービスとして構築した場合、それぞれの負荷状況に応じて個別にスケールさせることも容易になります。
こうしたメリットの反面、Webhookを利用しにくい点もあります。以下は、Webhookを利用する際のデメリットです。
Webhookをうける側の制御（特にエラー制御）
Webhookのリクエストを送信する側は、受信側がどのようにデータを受け付け、処理を行うかを完全に把握できません。そのため、受信側のシステムでエラーが発生し、データを受け付けなかった場合や、処理に失敗した場合の再送処理などを、受信側の特性に合わせて個別に実装する必要があります。
例えば、受信側のシステムが一時的にダウンしている場合に、いつ、何回リトライするかといったルールを受信側で管理する必要があります。
セキュリティ
Webhookの通信経路は、必ずしも直接的なクライアント／サーバー間の通信とは限りません。悪意のある第三者がWebhookのURLを知り、不正なリクエストを送信するリスクや、通信経路上でデータが傍受されるリスクがあります。そのため、送信元が正当なシステムであることを証明するためのAPIキー、トークン、署名検証などのセキュリティ対策や、HTTPSによる通信の暗号化が不可欠です。
これらのデメリットはWebhookの特性によるものであり、適切な対策を講じることで、安全かつ効率的なシステム連携を実現できます。また、Webhookを利用したシステム構築をより迅速に行いたい場合には、ESB/EAIやデータフローオーケストレーションツールなどの利用も有効な選択肢となります。
ESB/EAIやデータフローオーケストレーションツールを利用する
Webhookのようなイベント通知機能をビジネスロジックの内部に直接組み込みたくない場合もあります。その場合に有効なのが、各種イベントを検知する外部システムを設けて処理を行う方法や、ESB（Enterprise Service Bus：エンタープライズサービスバス）や EAI（Enterprise Application Integration：エンタープライズアプリケーション統合）といった連携基盤、あるいはデータフローオーケストレーションツールを利用するアプローチです。
ESBやEAIは、以前の記事エンタープライズシステムのためのマイクロサービスアーキテクチャの実現で紹介したように、異なるアプリケーションやサービス間を統合し、連携を仲介する役割を担います。
これらのツールは、異なる通信プロトコル（HTTPSOAP、JMSなど）を相互に変換する機能を備えていることが多く、それらの機能を利用することで、多様なシステム間の連携を柔軟に実現できます。
著者がバリューレイヤーを実装する際には、マイクロサービスアーキテクチャを採用しており、その中で組み込み型のEAIフレームワークであるApache Camelを活用することが多くあります。
Apache Camelは、さまざまなプロトコルに対応したコンポーネント（HTTP、メール、ファイル、データベースなど）を提供しています。処理本体で発生する状態変化を検知し、これらのコンポーネントを通じて外部システムと連携する仕組みを容易に構築できます。
組み込み型のフレームワークであるため、マイクロサービスとの親和性が高く、軽量で開発しやすいという利点もあります。
また、開発の初期段階で連携を明示的に設計していなかった場合でも、データフローオーケストレーションツールを用いることで、既存のシステム間の連携を外部から定義し、管理できます。
例えば、Apache NiFiは代表的なデータフローオーケストレーションツールの一つです。
Apache NiFiは、さまざまなシステムのデータ入出力やイベント発生をトリガーとして、定義された処理フローを実行できるツールです。
例えば、Webhookの仕組みを構築する場合、図6のように特定のディレクトリに外部ファイルが生成されたことをトリガーとして、そのファイルの内容を解析し、HTTP リクエストを送信することも可能です。同様に、データベースの特定のテーブルを定期的に監視し、条件に合致するデータを抽出して、別のシステムに連携するといった処理も簡単に実現できます。
データフローオーケストレーションツールは、ESB/EAI と比較して、よりデータの流れの定義と管理に特化している傾向があります。
一方、ESB/EAIは、サービス間の仲介やメッセージング、プロトコル変換など、より広範な連携機能を提供することが多いです。これらをシステムの要件や連携の複雑さに応じて、適切なツールを選択することが重要です。
WebSocketによるセキュリティ制約の迂回
WebSocketはサーバーとクライアント間でのリアルタイム通信を実現する場合などに用いられます。チャットアプリケーションや、株価・金融情報のリアルタイム配信などが代表的な例です。
ただしそれ以外にも、クライアント上にサーバ機能を設け、サーバ上にクライアント機能を作りたい場合にもWebSocketは活用できます。
少し意味がわかりにくいかも知れませんが、IoT機器をWebブラウザから操作・監視するダッシュボードのようなシステムを作るときに、このような構造にする場合があります。
具体的な例を挙げてみましょう。IoT機器に限らず、現在の業務担当者のデスクトップには、さまざまなサービスや情報が集約しているケースがあります。
例えば、外部のクラウドサービスがAPIを提供していない場合、Webブラウザから直接ローカルPC上のリソース（ファイルシステムなど）にアクセスして処理する必要がある場合や、ローカルファイルの一括操作などをWebインターフェースから行いたいケースがあります。一方、それらの操作の履歴管理や共有データの管理は、セキュリティや一貫性の観点からサーバー側で集中管理したいとします。
この場合、図7のような仕組みの中で、利用者のPCをサーバ化するためにWebSocketを使います。
インターネット上のサーバーからローカルPCへ直接接続することは、通常ファイアウォールやNATの制限により困難です。そこで、ローカルPC上のWebブラウザから中央のサーバーに向けて通常のHTTPS接続を確立し、その接続上でWebSocket通信も確立します。ユーザーがWebブラウザ上で操作（ローカルファイルの読み込み、編集、実行の指示など）を行うと、その指示はWebSocket通信を通じてローカルPC上に伝達され、処理を実行します。その結果のうち、管理に必要なデータ（処理ログ、ステータス、操作結果の概要など）をWebSocketを通じてサーバーに返送するわけです。
このように、WebSocketを用いることで、インターネットを介した直接的なローカルPCへのアクセスというセキュリティ上の制約を回避しつつ、Webブラウザをインターフェースとしてローカルリソースを利用した処理と、サーバーによる集中管理を両立できます。
こういったニーズは現在は限定的ですが、将来的には増える可能性があります。AIシステムがエンドユーザーの端末上で動作するケースが増えると、ユーザーはローカル環境でのみ可能な処理と、クラウド側でのみ可能な処理を意識せずに利用したいと考えるようになるでしょう。
WebSocketの技術は、そういった未来のシステムにおいても柔軟な連携を実現する上で重要な役割を果たす可能性があります。このような利用の具体例は、後述する「生成AIを使った連携」においてより詳細に説明します。
Web Workerやiframeを使ったJavaScript APIの提供
これまで紹介したシステム連携の方法は、ネットワークの制約（異なるオリジン間のリソース共有制限であるCORSなど）を含め、利用する開発者がある程度の知識を必要とします。
しかし、クライアントエンジニアがサーバー側のインフラストラクチャやセキュリティポリシーといった制約を意識せずに、純粋にフロントエンドの開発に集中したい場合には、これらの複雑さを抽象化し、使いやすいJavaScript APIとして提供する必要があります。
その際に有効なのが、図8に示すWeb Workerやiframeを用いた連携方法です。
特にiframeを利用する場合、埋め込み元のWebページとは独立したドキュメントコンテキストを持つため、既存のWebシステムのJavaScript変数名やCSSスタイル定義との衝突を避けられます。この特性から、より独立性の高いウィジェット型APIなどを提供するのに適しています。
ただし、Web Workerやiframeを通じてJavaScriptの機能を提供する場合は、セキュリティ面で利用者に不信感を与えないように、APIの提供者側があらかじめ信頼性を確保し、その旨を明確に伝えることが重要です。
これらの仕組みは、クライアント側のJavaScriptから直接的なサーバーへの接続を間接的に行うため、通信経路が表面上は見えにくい印象を与えます。
そのため、ユーザーのローカルリソースにアクセスするAPIや、機密性の高い情報を扱うAPIの場合は、利用者の明示的な許可を得てからAPIが実行されるようにするなど、APIの種類や利用シーンに応じて慎重な設計が求められます。
