sgcWebSockets vs Indy — 2026 年にどちらを選ぶか

· レビュー

2 つのライブラリ、2 つの異なる仕事

ほぼすべての Delphi 開発者は、どこかで Indy を使ったことがあります。IDE に標準同梱され、1990 年代後半から存在し、Delphi のネットワーキングコードの 1 世代は TIdHTTP、TIdTCPClient、TIdSMTP 等の上に構築されています。sgcWebSockets はずっと新しい商用ライブラリで、Indy が最初に設計されて以降に登場したプロトコル — WebSocket、HTTP/2、HTTP/3 / QUIC、MQTT 5、AMQP 1.0、SSE、WAMP、WebRTC、MCP — に加え、数多くの REST API 統合に焦点を当てています。

Embarcadero フォーラムや Stack Overflow で最もよくある質問は、「Indy が無料なのに、なぜ sgcWebSockets にお金を払うのか？」のバリエーションです。短い答えは、両者は異なる問題を解決しており、多くの実プロジェクトでは両方を使うことになる、というものです。この記事では、どちらが（あるいはどの組み合わせが）アプリケーションに合うかを判断できるよう、2026 年時点での実践的な違いを解説します。

それぞれのライブラリが実際に行うこと

Indy は、HTTP/1.1、FTP、SMTP、POP3、IMAP、NNTP、DNS、IRC、Telnet、Whois、加えて TCP サーバーフレームワークといった古典的なインターネットプロトコルの長いリストを備えた、汎用 TCP/UDP ツールキットです。設計はスレッド／接続およびブロッキング I/O です。標準の Indy にはネイティブな WebSocket クライアントもサーバーもありません — 自前で追加する必要があり、複数のコミュニティプロジェクトがまさにそれをまちまちの結果で実装しています。

sgcWebSockets は、最新のクライアント／サーバーシナリオに焦点を絞ったプロトコル豊富なライブラリです。コアの TsgcWebSocketClient / TsgcWebSocketHTTPServer ペアを中心に、HTTP/2、QUIC ベースの HTTP/3、MQTT、AMQP、STOMP、SSE、WAMP、P2P/WebRTC、IoT（CoAP、AWS IoT、Azure IoT）、エンド・ツー・エンド暗号化、30 以上の API ラッパー（OpenAI、Anthropic、Google、AWS、Azure、Binance、Coinbase、Kraken、Telegram、WhatsApp など）のアドオンを備えます。

見落とされがちな重要事項: sgcWebSockets は内部で Indy をトランスポートバックエンドの 1 つとして使用しています。いくつかのコンポーネントの TCP/TLS 配管は、内部では Indy の TIdTCPClient / TIdHTTPServer です。したがって、sgcWebSockets をインストールしても Indy が置き換わるわけではなく、その上に構築されます。Indy が最適でないシナリオ向けに、代替トランスポート（Synapse スタイル、ICS、SChannel）も提供されます。

機能ごとの比較

機能Indy（標準）sgcWebSockets
HTTP/1.1 クライアントあり（TIdHTTP）あり（TsgcHTTPComponentClient、Indy または ICS バックエンドが利用可能）
HTTP/1.1 サーバーあり（TIdHTTPServer）あり（TsgcWebSocketHTTPServer、同一ポートで HTTP と WS を処理）
WebSocket クライアント／サーバーネイティブサポートなしRFC 6455 完全対応、permessage-deflate、サブプロトコル、Autobahn テスト済み
HTTP/2（h2 + h2c）なしあり、独自 HPACK + フレーム層
HTTP/3 / QUICなしあり（msquic ベース）
MQTT 3.1.1 および 5.0なしあり、クライアントとブローカー
AMQP 1.0 / 0.9.1なしあり
STOMP、SSE、WAMPなしあり
WebRTC / P2P / STUN / TURNなしあり
CoAP および IoT クラウド（AWS、Azure）なしあり
OpenAI、Anthropic、Gemini、MCPなしあり、専用コンポーネント
FTP / SMTP / POP3 / IMAPありなし（用途には Indy を使用）
無料／商用無料、MIT 系商用、Free 版を含む複数エディション
Delphi バージョンD7 以降（フォークによる）D7 から D13 まで
活発な保守コミュニティ（GitHub の IndyProject）ベンダー、月次リリース

Indy がいまだに有利な場面

プロジェクトが古典的なインターネットクライアント — HTTP でファイルをダウンロードする、フォームを POST する、SMTP メールを送信する、IMAP でメールを取得する、古い FTP サーバーと通信する — である場合、標準の Indy が正しい答えです。無料で、IDE に同梱され、API が馴染み深く、他に何も必要ありません。Indy がネイティブで提供するプロトコル（NNTP、IRC、Telnet、Whois）の趣味的な TCP サーバーも同様です。これらの用途では、有料ライブラリを追加するのは過剰です。

すでに Indy 型を使用しているコードと相互運用しなければならない場合 — 例えば TIdSSLIOHandlerSocketOpenSSL や TIdHTTPServerCommandHandler を期待するコンポーネント — も Indy の出番です。

sgcWebSockets が適切な場面

モダンな Web スタックが関わるものは、sgcWebSockets を使うと大幅に容易になります。具体的には:

パフォーマンスとスケーリング

Indy のスレッド／接続モデルは単純で正しいですが、コンテキストスイッチがボトルネックになる前の典型的な Windows サーバーでの実用スループットは、数千の同時接続程度に抑えられます。sgcWebSockets は互換性のために同じ Indy バックエンドを提供しつつ、Windows では IOCP ベースのサーバートランスポートも備えており、プロセスごとに数万の同時 WebSocket 接続でベンチマークされています。純粋な HTTP スループットでは差は小さくなりますが、長寿命接続（WebSocket、MQTT、SSE）ではアーキテクチャの差が効いてきます。

アイドル接続あたりのメモリフットプリントも、ソケットごとに専用 OS スレッドが不要な IOCP トランスポートではより低くなります。Linux では、sgcWebSockets が同梱する Indy フォーク経由の epoll ベースサーバーで同様の状況です。

保守とリリース頻度

Indy は IndyProject の GitHub リポジトリで少数のボランティアによって保守されています。リリースは遅いですが、コードベースは安定しています。重要な修正（TLS 互換性、最新の OpenSSL バインディング）は取り込まれますが、必ずしも迅速ではありません。

sgcWebSockets は eSeGeCe による商用製品で、月次リリース、公開された履歴ファイル、ベンダー直接のサポートがあります。新しい Delphi バージョンは通常初日からサポートされ — Delphi 13 は最初のベータからサポート —、新しいプロトコル改訂（MQTT 5.0.1、HTTP/3 最終版、MCP 仕様更新）は数年ではなく数日で出荷されます。

ライセンスと価格

Indy は無料で、Delphi に同梱されています。sgcWebSockets は商用ですが、非商用利用向けの Free Edition と、プロトコルカバレッジが段階的に広がる有償エディション（Standard、Professional、Enterprise、All-Access）があります。ほとんどの商用プロジェクトは、デプロイ済み顧客が 1 社あれば単一開発者の Professional ライセンスを正当化できます。

シンプルな判断ルール

2026 年の実用的な目安:

まとめ

Indy はどこにも行きません — どの Delphi ツールボックスにもある信頼のハンマーです。しかし、2026 年のインターネットを定義するプロトコル（WebSocket、HTTP/2/3、MQTT、WebRTC、AI API）は Indy が設計された当時にはまったく存在しませんでした。sgcWebSockets はそのギャップを、有用な箇所では Indy の上に構築し、必要な箇所では置き換える、焦点を絞り、活発に保守され、商用サポートされたライブラリで埋めます。モダンなバックエンドを対象とする新規プロジェクトでは、もはや 「Indy か sgcWebSockets か？」 ではなく — 「両者をどう組み合わせるか？」 が問いとなります。