通信の形式いろいろ

Web サービスを作っていると HTTP ばかり使うので、 通信 = HTTP だと思いがちです。

しかし実務では、こういう場面に出会います。

「取引先とのデータ連携は SOAP です」
「バッチの結果は SFTP でファイルを置いてください」
「通知は SMTP で送っています」
「デバイスとの通信は MQTT です」
「銀行との連携は全銀フォーマットの固定長ファイルです」

知らないと、何を調べればいいかも分かりません。 この章は、その地図です。すべてを覚える必要はなく、 「そういうものがある」と知っていることが目的です。

1970-80年代  回線が細く高価 → 少ないデータ量で確実に届けることが最優先
             （メール・FTP・EDI）

1990年代     Web の登場 → 誰でも読める、テキストベースの単純な形式
             （HTTP・HTML）

2000年代     企業システムの連携 → 厳密な型定義と、複雑な業務要件
             （SOAP・WS-*）

2010年代     モバイルと大量アクセス → 軽量・高速・非同期
             （REST/JSON・WebSocket・gRPC・MQTT）

2020年代     マイクロサービスと大規模化 → 効率・型安全・双方向
             （gRPC・GraphQL・HTTP/3）

Web で使うもの

WebSocket と SSE の使い分け

チャット、共同編集、ゲーム   → WebSocket（双方向）
通知、進捗表示、株価の配信   → SSE（サーバーから送るだけ）

SSE は HTTP のままなので、既存のインフラ（CDN・LB・認証）がそのまま使えます。 双方向が要らないなら、こちらのほうが楽です。

□ ロードバランサやプロキシがタイムアウトで切ることがある
□ 切れた時の再接続を、自分で実装する必要がある
□ サーバーの接続数が上限になる（プロセスとメモリのファイルディスクリプタ）
□ スケールアウトすると、どのサーバーに繋がっているか管理が要る

API の作り方（HTTP の上の流儀）

SOAP — なぜ生まれ、なぜ減ったか

□ 型が厳密に定義されていること（間違ったデータを送れない）
□ トランザクション・セキュリティ・信頼性の仕様が標準化されていること
□ 言語やベンダーに依存しないこと

□ XML が冗長で、パースも重い（モバイルには厳しい）
□ 仕様が巨大で、実装ごとの解釈の違いに悩まされた
□ Web の世界では、もっと単純な REST + JSON で十分だった

<!-- SOAP のリクエストの雰囲気（実際はもっと長い） -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetBalance xmlns="http://example.com/bank">
      <AccountId>12345</AccountId>
    </GetBalance>
  </soap:Body>
</soap:Envelope>

□ WSDL（定義ファイル）が渡されたら、そこからクライアントを生成する
□ 手で XML を組み立てない
□ 文字コードと日時形式の指定に特に注意する（文字コードと改行コード）

この構造は、実は gRPC と同じ発想です（定義ファイルからコード生成）。 違いは、XML かバイナリか、という点にあります。

メッセージング

□ ヘッダが極小（最小2バイト）
□ 接続が切れた時の遺言メッセージ（Last Will）を設定できる
□ QoS のレベルを選べる（届かなくてよい / 最低1回 / ちょうど1回）

メール

「メールを送る」は、実務でも頻繁に実装します。

□ 自前で SMTP サーバーを立てない（到達率が絶望的に低い）
□ 送信サービス（SendGrid / SES / Postmark など）を使う
□ SPF / DKIM / DMARC を設定する ← これが無いと迷惑メール扱いされる
□ バウンス（宛先不明）を処理する
□ 配信停止の導線を必ず入れる（エンジニアと法律の特定電子メール法）

□ 送信に成功した ≠ 相手に届いた
□ 届いた ≠ 迷惑メールフォルダに入っていない
□ 迷惑メール判定は、送信元の評判で決まる

ファイル転送

古いと思われがちですが、企業間連携では今も主流です。

□ 平文の FTP は、認証情報がネットワーク上を流れる → 使わない
□ 鍵認証を使う（パスワードよりも）
□ 転送完了の判定に注意（書き込み途中のファイルを読まないよう、
  一時名で置いてからリネームする）

1. こちらが夜間バッチで CSV を SFTP に置く
2. 相手が朝のバッチで取りに来る

□ 書き込み途中のファイルを相手が読んでしまう
   → 一時ファイル名で書き、完了後にリネームする（リネームは原子的）
□ 前日のファイルが残っていて、二重に処理される
□ 文字コードと改行コードの不一致（文字コードと改行コード）
□ 相手が取りに来たかどうかが分からない

インフラ・運用で出会うもの

レガシー連携（日本の実務で出会うもの）

教科書には載りませんが、実際には非常に多い領域です。

□ 桁数が1バイトでもずれると、以降が全部ずれる
□ 半角カナ・Shift_JIS が現役（文字コードと改行コード）
□ 日付が「YYMMDD」で、世紀の判定ルールが独自
□ 数値が右詰めゼロ埋め、負数の表現が独特
□ 仕様書が PDF で、質問すると数日かかる

□ 相手のシステムは変えられない（相手にとっては巨大な資産）
□ 何十年も安定して動いてきた実績がある
□ 変更には、業界全体の調整が必要なことがある

選び方

□ ブラウザから呼ぶ                    → HTTP（REST / GraphQL）
□ サービス間で高速・型安全に          → gRPC（スキーマと RPC）
□ 画面ごとに必要な項目が違う          → GraphQL
□ サーバーから push したい            → SSE（一方向）/ WebSocket（双方向）
□ 非同期に流したい                    → メッセージング（非同期処理とメッセージング・RabbitMQ と Kafka）
□ 大量のファイル / 定時のやり取り     → SFTP + バッチ（バッチとジョブ）
□ IoT デバイス                        → MQTT
□ 相手が指定してくる                  → **相手に合わせる**（選択の余地は無い）

最後が実務では最も多いことも覚えておいてください。

どの形式でも共通して確認すること

新しい連携を実装する時、必ず確認するリストです。

□ 文字コードと改行コード（文字コードと改行コード）
□ 日時の形式とタイムゾーン（見つけにくいバグ）
□ 数値の形式（桁数、小数、負数、通貨単位）
□ 認証方式（証明書 / 鍵 / ID・パスワード / IP 制限）
□ タイムアウトとリトライの規定（性能と負荷対策）
□ **再送された場合の扱い**（冪等性。非同期処理とメッセージング・間違えられない処理を作る）
□ エラー時の連絡方法と、相手の窓口
□ テスト環境の有無

この8項目は、どのプロトコルでも聞くべきことです。 そして、仕様書に書かれていないことが必ずあります。先に聞いてください。

まとめ

• 通信 = HTTP ではない。プロトコルはその時代の制約から生まれる
• Web では HTTP / WebSocket / SSE。双方向が要らないなら SSE のほうが楽
• API の流儀は REST / GraphQL / gRPC / SOAP。 SOAP は「厳密さ」の要求から生まれ、今も金融・行政で現役
• メッセージングは AMQP / MQTT / Kafka。MQTT は IoT の制約から生まれた
• メールは SMTP / IMAP。自前で立てず、SPF/DKIM/DMARC を設定する。 「届いたか分からない」前提で設計する
• ファイル転送は SFTP。書き込み途中を読まれない工夫が必須
• レガシー連携（固定長・EDI）は今も多い。腐敗防止層で内部と分離する
• 実務では相手が形式を指定してくることが最も多い
• どの形式でも、文字コード・日時・数値・認証・タイムアウト・冪等性を必ず確認する

公式ドキュメント・参考資料

仕様の最終的な正本は RFC です。読みにくいですが、 「この挙動は仕様上どうなっているのか」を確定させたい時は、ここに戻ります。

次の章では、これらが実際に流れる Web と HTTP を詳しく見ます。