技術構成(設計段階) / セキュリティ要点(現状)

HospitaLinkの技術構成・セキュリティを、1枚で説明する資料

本ページはFTPで見せる補助資料想定で、運用前提を前提に「現時点の実装状況」「開発工程」「本番接続前に確認すべき点」を分離して記載します。

重要: ここでの内容は公開用プロポーザルの一部として使う前提です。セキュリティは実環境の構成差分(本番DB、監査基盤、ネットワーク境界)により変わります。
提案・見積工程

開発工程と成果物

HospitaLinkは、いきなり実装するのではなく、要件定義からテスト・運用設計までを小さく区切って進めます。商談時は、どこまでを今回の範囲に含めるかをこの工程で確認します。

01 要件定義

対象施設、既存SaaS、Slack運用、承認者、価格/返信/清掃の判断ポイントを整理します。

成果物: 要件一覧 / 対象外範囲 / 優先度
02 業務設計

現場の流れ、通知先、承認ルート、例外時の人間判断、SOP化する作業を定義します。

成果物: 業務フロー / 承認フロー / SOP案
03 基本設計

全体構成、データの流れ、Slack/Sheets/API/管理画面の役割、権限とログ方針を決めます。

成果物: システム構成図 / データ設計方針
04 詳細設計

Webhook項目、テーブル、YAML変数、通知テンプレ、エラー時の挙動を実装単位に落とします。

成果物: API/DB/通知仕様 / テスト観点
05 実装

Webhook受信、判定ロジック、承認キュー、Slack通知、簡易管理画面を段階的に作ります。

成果物: 動作する検証版 / 設定ファイル
06 単体テスト

価格異常、重要メッセージ、署名検証、設定読込、保存処理などを機能ごとに確認します。

成果物: テスト結果 / 修正ログ
07 結合・受入テスト

Slack通知、承認操作、Sheets/DB保存、外部SaaS停止時の代替手順を一連で確認します。

成果物: 受入チェックリスト / リリース判定
08 運用設計・改善

運用担当、監視項目、月次レビュー、改善ToDo、障害時の連絡手順を決めて回します。

成果物: 運用SOP / 月次改善レポート
初期診断で出すもの要件整理、現状フロー、リスク一覧、見積レンジ、優先順位。
構築案件で出すもの基本設計、詳細設計、検証版、単体テスト結果、受入チェックリスト、運用SOP。
実装済み

技術スタック(現状)

  • 言語・実行基盤Python 3 + FastAPI(`uvicorn`起動)
  • API層Webhook受信(予約・メッセージ・価格イベント想定)と承認判定エンドポイント
  • データ保存SQLite(例: `data/hospitalink.sqlite`)
  • 外部連携需要・価格・予約データ / Slack / Sheets / AirHost / OTA周辺を変数化
  • 設定Tenant設定(地域別)をYAMLで分離
  • 監査承認キュー・閾値超過時の停止制御のルール
運用前提

実行フロー(簡易)

イベント受信 → 入力検証 → 判定ルール適用 → 承認キューへ寄せる/保留
→ Slack通知(要約)→ 人的承認 → 手動/半自動実行(将来拡張)

価格変更やゲスト返信は、未接続時は「下書きまたは確認待ち」を基本にし、完全自動実行を抑止する設計です。

検証中

データ設計の基本原則

  • 最小保持必要な情報のみを保存し、個人情報は可能な限り除外
  • 用途分離地域ルール・閾値・通知ルールを設定値として分離
  • 監査可能性承認者・時刻・判定結果の追跡が取りやすい構造
  • 失敗耐性外部連携が遅延しても判断経路が途切れない構成

全体アーキテクチャ

営業資料では「何でもつなげる」ではなく、入力・制御・通知・記録・改善の5層で説明すると安全です。

役割設計上の注意
入力層OTA、AirHost、自社フォーム、手動CSV、Google Sheetsからイベントを受ける。予約ID、氏名、連絡先などは必要最小限にし、Slackには要約だけ出す。
制御層価格上限、返金、重要メッセージ、清掃遅延、宿泊税、帳票などを判定。金額・外部送信・個人情報に関わるものは承認キューへ。
通知層Slackチャンネル、担当者、管理者、清掃担当へ通知を分岐。通知過多にならないよう、重要度・期限・担当を明記する。
記録層承認履歴、対応状況、改善ログ、CRM同意、帳票出力履歴を保存。保存期間、削除、閲覧権限を案件ごとに決める。
改善層週次レポート、レビュー改善、直予約施策、地域変数更新へつなげる。売上だけでなく、対応漏れ・返信時間・レビュー変化も見る。

セキュリティ要点(実装・要確認)

実装/有効

認証・受信

Webhook署名検証(本番接続時)を想定し、ローカルでは検証を緩めて検証可能性を保つ。 これは現状READMEに明記されている運用条件。

要確認

通信・機密情報

APIキー・Webhook secretは環境変数管理。送受信はHTTPS前提とし、ログ・画面・添付物にキーを出さない。

未実装/要確認

境界防御・監査

本番のWAF、レート制御、攻撃監視、改ざん検知、監査台帳の恒久運用は要設計。 これは別途運用基盤連携が必要。

観点 現状想定 推奨する運用
個人情報保護(氏名・連絡先・予約ID等) 要設計 収集を最小化、公開チャネルでの露出回避 表示/保存制御、マスキング、保存期間ポリシーを明文化
誤実行防止価格反映・返信送信 設計済み前提 重要操作は承認キュー化 閾値超過時は自動停止、承認者必須、監査ログ
外部依存SaaS連携 要確認 需要・価格・予約データ連携は契約条件とAPI条件に依存 用途境界と再表示許諾を文書化、利用制限反映
データ保護保管・バックアップ・削除 要確認 実運用差分の設計必要 運用環境別に暗号化有無、アクセス権、削除手順を定義
設計で分ける

データ分類と保持方針

分類方針
公開してよい情報施設名、部屋タイプ、公開済み料金、公開レビューの要約。LPや営業資料に利用可能。ただし誇大表現は避ける。
社内運用情報清掃担当、承認者、改善ToDo、価格判断メモ。社内/顧客管理画面まで。外部公開資料には出さない。
個人情報宿泊者名、連絡先、予約番号、宿泊者名簿。Slackではマスク。保持期間と削除方法を案件ごとに定義。
機密情報APIキー、Webhook secret、鍵情報、認証URL。環境変数・権限管理。画面、ログ、資料に出さない。
法務/税務確認情報宿泊税、領収証、請求書、国税庁対応、契約条件。専門確認候補。断定せず、確認ステータスを管理。
テスト観点

単体テスト・受入テストで見ること

正常系

予約通知、清掃通知、価格アラート、CRM登録、帳票作成が想定どおりに流れる。

停止系

返金、鍵、クレーム、価格上限、配信停止、個人情報を含む場合に自動処理を止める。

異常系

未入力、重複、API遅延、Slack失敗、CSV文字化け、権限不足時に手動復旧できる。

監査

誰が承認・却下・保留したか、後から説明できるログが残る。

SP表示

営業資料、診断、管理画面のプレビューがスマホ幅で縦崩れしない。

運用

初期SOPを見れば、現場担当が日次確認と週次改善を回せる。

結論

「技術構成は軽量で整理しやすい形に寄せており、セキュリティは『未接続時は確認必須の制御』を中心に現実的な導線が取りやすい状態」です。
本番公開前は、「API鍵管理」「通信境界」「ログ監査」「SaaS規約の一次確認」を追加し、ページの要点を更新してください。

Next Step

商談後は、この順番で具体化します。

無料相談で終わらせず、診断から要件定義、見積、構築、月次伴走へ進めます。

01導入診断

予約、清掃、価格、CRM、帳票の詰まりを棚卸し。

02要件定義

対象範囲、承認者、除外範囲、テスト観点を決める。

03見積

Core、宿泊事業側、CRM/グロース追加を分けて提示。

04構築

Slack OS、承認キュー、監査ログ、通知ルールを実装。

05月次伴走

レビュー、価格、CRM、直予約の改善を週次/月次で回す。

導入診断フォームへ 料金表を見る 要件定義を見る