第6章 Smart Assist通信設計の技術解剖

6.1 実際の通信シーケンス図

Smart Assist PCがAWSクラウドへ未確定画像を送信し、分類結果を取得するまでの通信シーケンスを時系列で示す。

各ステップを以降の節で詳しく解説する。

6.2 DNS解決の流れ

ステップ①②の詳細

Smart Assist PCが最初に行うのは、接続先のFQDNをIPアドレスに変換するDNS問い合わせである。

病院環境での注意点

AWS環境特有の注意

AWSのサービスでは、同じFQDNに対するIPアドレスが動的に変化することがある。そのため、ファイアウォールの許可ルールをIPアドレスではなくFQDNで設定することが推奨される（第7章で詳述）。

6.3 TLSハンドシェイク

TLS証明書（Let's Encrypt ロゴ例）

ステップ③④の詳細

TCP接続が確立された後、TLSハンドシェイクが行われる。

SSLインスペクションの影響

病院のプロキシやファイアウォールがSSLインスペクションを行っている場合、TLSハンドシェイクの動作が変わる。

この場合、Smart Assist PCが受け取る証明書はAWSのものではなく、プロキシが発行した証明書になる。これが証明書エラーの原因となることがある（第10章で詳述）。

6.4 画像データ送信の流れ

ステップ⑤⑥の詳細

TLSハンドシェイク完了後、暗号化された経路上でHTTPSリクエストとして画像データを送信する。

HTTPSリクエスト（イメージ）:

  POST /api/v1/images HTTP/1.1
  Host: smartassist.example.com
  Content-Type: multipart/form-data
  Authorization: Bearer <認証トークン>

  [画像バイナリデータ]
  [検体ID]
  [自動分類結果]
  [タイムスタンプ]

通信の特性

レスポンスの内容

HTTPSレスポンス（イメージ）:

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "accepted",
    "request_id": "abc-123-def"
  }

このレスポンスは「データを受け付けた」という確認であり、分類結果はまだ返ってこない。

6.5 分類結果返却の仕組み

ステップ⑦⑧の詳細

遠隔技師が分類を完了した後、Smart Assist PCがクラウドに問い合わせることで結果を取得する。

HTTPSリクエスト（イメージ）:

  GET /api/v1/results?since=2025-01-15T10:00:00Z HTTP/1.1
  Host: smartassist.example.com
  Authorization: Bearer <認証トークン>

HTTPSレスポンス（イメージ）:

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "results": [
      {
        "request_id": "abc-123-def",
        "specimen_id": "SP-20250115-001",
        "classifications": [
          { "image_id": "img-001", "category": "RBC", "confidence": 0.95 },
          { "image_id": "img-002", "category": "WBC", "confidence": 0.92 }
        ],
        "classified_by": "technician-A",
        "classified_at": "2025-01-15T10:30:00Z"
      }
    ]
  }

ポーリングの仕組み

Smart Assist PCは定期的にクラウドへ結果を問い合わせる。これをポーリング（Polling）と呼ぶ。

6.6 「Outbound Only」とは何を意味するのか

定義

「Outbound Only」とは、すべての通信が院内から外部への方向で開始されることを意味する。

通信方向の分類

レスポンスはInboundではない

ファイアウォールの観点で重要なのは、Outbound通信に対するレスポンスは「Inbound通信」ではないという点である。

Outbound Onlyであることのセキュリティ上の意味

6.7 外部からの直接侵入がない理由

技術的な根拠

Smart Assistの通信設計において、外部（インターネット）から院内ネットワークへの直接侵入がないと言える技術的根拠を整理する。

根拠1: Inboundポートが開いていない

外部から院内への新規接続を許可するファイアウォールルールが存在しないため、外部からの接続は物理的にブロックされる。

根拠2: NATの内側

院内PCはNATの内側に位置しており、外部からプライベートIPアドレスへ直接到達する方法がない。

根拠3: リスニングサービスなし

Smart Assist PCは外部からの接続を待ち受けるサービス（Webサーバ、SSHサーバなど）を稼働させていない。仮にファイアウォールを通過できたとしても、接続を受け入れるプロセスが存在しない。

根拠4: TLSによる通信保護

TLSにより、通信経路上での盗聴・改ざん・なりすましが防止されている。中間者攻撃（MITM）による通信の傍受も困難である。

まとめ：病院IT担当者への説明

6.8 資料の読み方：ネットワーク説明資料（Network Explanatory Materials）

資料の概要

「SmartAssist Network Explanatory Materials」 は、Smart Assistクラウドのシステム構成とネットワーク接続方法を図解した技術資料である。病院IT部門がファイアウォール設定や接続方式を検討する際に使用する。

対応するファイル: UHW-PRJ2024040-L-2025-007a_SmartAssist Network Explanatory Materials

Smart Assistクラウドの構成要素

ネットワーク説明資料には、Smart Assistクラウドを構成するAWSサービスの全体像が示されている。担当者は各サービスの役割を理解しておく必要がある。

セキュリティ・監査サービス

Smart Assistクラウドでは以下のAWSセキュリティサービスが有効化されている。

3つの接続オプション

ネットワーク説明資料では、病院からSmart Assistクラウドへの接続方法として3つのオプションが提示されている。

重要: いずれのオプションでも 静的なインバウンド設定は不要 である。通信方向はすべて病院側からクラウドへのOutboundである。

物理接続の構成

AUTION EYEとPC・LIS間の接続構成も資料に記載されている。

次章では、この通信を実現するためのファイアウォール設計と、病院IT担当者への申請方法を学ぶ。