return ErrMissingRequiredRP AtLeastOneRP p.RPs = append(p.RPs[:i], p.RPs[i:]...)...)
 timing, err := TimingRepository.Get(ctx) append([]RP{rp}, 医療システムにおける Observability向上のための OpenTelemetry活用 h1 { 

自己紹介 株式会社ispec 取締役CTO 山田 佑亮 経歴 好きな技術 慶應義塾大学政策・メディア研究科卒業。 在学中からスタートアップやメガベンチャー複数社にて インターンを経験。その後、株式会社タイミーの立ち上げ期にてバックエンド 開発をリードしたのち、株式会社ispecにCTOとしてジョイン。 BtoB SaaSや電子カルテのPdM/TLを歴任した後、現在はCloudSailの事業責 任者を務める。令和6年度デジタル庁標準型電子カルテ開発のPWGメンバー。 Neovim、Go、OpenTelemetry 趣味 サッカー、フットサル 

[PATIENT] [STRUCTURE] [MODULE] ispecについて ispec.inc/about 

医療DXを加速させる土台を作る 医療業界のシステムは長い間進化せず、取り残されています。 
 その背景には歴史の中で積み上げられた業界構造であったり、 データを慎重にとり扱う必要があることに加えて、システムの停 止が人の健康や生命に関わるがゆえの難しさ等があります。 病院の7割は赤字であり医療費は国の財政を圧迫しています。 その中で高いレベルの医療を提供し続けるためには、 医療DXによる効率化やデータ活用が必須です。 ispecはこの医療DXを加速させるための土台を作るために 医療機関様やベンダー様にサービスを提供します。 

ITインフラと組織を梃子に医療DXを加速させる Loomo AI インシデントレポートを 起点に業務の暗黙知を 形式知へ 病院組織の属人性をなくし AI・システムにタスクシフト 組織の課題 ネットワークの課題 全ての病院が最新技術に アクセス可能な状態へ CloudSail 閉域とクラウドを安全に繋げる
 プラットフォーム ispecは、医療DXが遅れた原因を「閉域中心のITインフラ」と「組織業務の硬直化」の二つにあると考え、 両者を解くためのプロダクトを同時に開発し提供することを目指しています。 

今日の発表の要諦 オンプレとクラウドのハイブリッド環境でのオブザーバビリティ・エンジニアリングについて OTel Collectorの柔軟性、ベンダー非依存の特徴がどうハイブリッド環境とマッチするのか Observabilityのアーキテクチャをプロダクトの成長に合わせてどのように進化させるか さまざまなデプロイモデルをどのように組み合わせて要件を実現していくか 

[PATIENT] [STRUCTURE] [MODULE] CloudSailについて ispec.inc/cloud-sail 

セキュアなITインフラで クラウド化への航海をはじめよう CloudSailは、病院システムのクラウド化を推進する PaaS(Platform as a Service)です。 現在、多くの医療機関が閉域網を中心としたネットワーク環境が主 流となっており、クラウドサービスの導入が困難な状態です。 CloudSailは、院内に専用の小型サーバー(Sail Cube)を設置するだ けで閉域網中心の医療機関様でも簡単にクラウドサービスを導入で きるプラットフォームを提供します。これまでのネットワーク環境 を大きく変更せずに最新技術を活用することができるようになりま す。 

クラウド化の課題に合わせたソリューションの提供 クラウド電子カルテの導入状況など、医療機関さまごとによってどこまでクラウド化が進んでいるかは異なります。 Sail Cubeと呼ばれる小型のサーバーの上でさまざまなアプリを動かすことで、状況に合わせた最適なソリューションを提供します。 Sail Engine オンプレシステムとクラウドシステムを連携させるアプリケーションを動かす ソリューション。連携アプリの可用性を担保し、院内業務の継続性を担保。 Sail Bridge 閉域のPCからでもクラウドサービスにアクセスできるソリューション。 PCで一つでクラウドシステムとオンプレシステムの両方へのアクセスを実現。 Sail Radar 院内のオンプレシステムの稼働状況をモニタリングするソリューション。 オンプレシステムとクラウドシステムの連携に関わる障害の復旧速度を向上。 

CloudSail導入前のシステム構成と課題 クラウドの電子カルテと院内システムを連携させるアプリの可用性の低さ 院内システムの死活状況がわからず、連携障害時の調査工数が増大 閉域のPCからクラウドサービスにアクセスができず業務が非効率 

CloudSail導入後のシステム構成 Sail Engine: Sail Cube上で連携アプリを動かせるPaaSを提供し、このSail Cubeを Sail Bridge: リバースプロキシーを提供することで Sail Radar: 院内システムを監視し、その結果を表示するダッシュボードを提 供することで 冗長化することで可用性を担保 閉域PCからでもクラウド サービスにアクセス 連携障害時の障害復旧速度を向上 

No content

CloudSailのプロダクトロードマップ 2025年09月 2025年12月 2026年03月 2026年06月 Sail Bridgeトライアル開始 Sail Engineトライアル開始 Sail Engine 本格提供開始 Sail Bridge Sail Engine ispecがCubeのヘルスチェックステータスを閲覧できる 医療機関がSail Bridge経由でクラウドサービスを使える ベンダーがCube上でコンテナアプリを動かせる ベンダーがCube上にコンテナアプリをデプロイできる ベンダーがCube上のコンテナのテレメトリーを閲覧できる プロダクトのフェーズやソリューションに合わせてObservabilityの戦略を考える必要性がある 

[PATIENT] [STRUCTURE] [MODULE] CloudSailのObservability ispec.inc/cloud-sail/observability 

CloudSailは小型サーバーを各医療機関様に提供するビジネス 事業のスケーラビリティ = Sail Cubeの管理・運用をいかに楽にできるか ex. Cube側は病院毎にデリバリーする想定だが、クラウド側はマルチテナント 小型サーバーの中で起きた障害に対してリアクティブにならないことが重要 → フェーズに合わせたObservabilityへの投資が事業のスケーラビリティに直結 CloudSailにおけるObservabilityの重要性 

CloudSailのプロダクトロードマップ 2025年09月 2025年12月 2026年03月 2026年06月 Sail Bridgeトライアル開始 Sail Engineトライアル開始 Sail Engine 本格提供開始 Sail Engine ベンダーがCube上でコンテナアプリを動かせる ベンダーがCube上にコンテナアプリをデプロイできる ベンダーがCube上のコンテナのテレメトリーを閲覧できる プロダクトのフェーズやソリューションに合わせてObservabilityの戦略を考える必要性がある Sail Bridge ispecがCubeのヘルスチェックステータスを閲覧できる 医療機関がSail Bridge経由でクラウドサービスを使える 

Sail Cubeとクラウドの通信の状態を把握できること ここの通信が途絶える = 医療機関様がクラウドサービスにアクセス不可 Cube ↔️ クラウドの双方向でヘルスチェックを飛ばしてメトリクスへ リバースプロキシーに追加のリソース割り当ての判断ができること 医療機関様がクラウドサービスを利用するとリバプロへの負荷が増加 早めに検知してリソース調整およびCube本体のスペック向上の提案へ Sail Bridge提供時に求められるObservabilityの要件 

ローカルコレクター + ゲートウェイモデル 

ローカルコレクター + ゲートウェイモデル Cube側はローカルコレクターでコンテナとホストの両方を収集 ヘルスチェック系およびリバプロにはサイドカーを置かない 

ローカルコレクター + ゲートウェイモデル クラウド側はゲートウェイのCollectorを用意 各医療機関に設置されたCubeのCollectorからの通信をまとめて受 け取り、オブザーバビリティ・プラットフォームに送る オブザーバビリティ・プラットフォームの移行に強い設計 

CloudSailのプロダクトロードマップ 2025年09月 2025年12月 2026年03月 2026年06月 Sail Bridgeトライアル開始 Sail Engineトライアル開始 Sail Engine 本格提供開始 Sail Bridge ispecがCubeのヘルスチェックステータスを閲覧できる 医療機関がSail Bridge経由でクラウドサービスを使える Sail Engine ベンダーがCube上でコンテナアプリを動かせる ベンダーがCube上にコンテナアプリをデプロイできる ベンダーがCube上のコンテナのテレメトリーを閲覧できる 

ベンダーが動かすコンテナアプリのテレメトリーをベンダーが見れること ベンダーがコンテナアプリの動作に責任をもつため、ログやメトリクスをベン ダーが見れる必要がある 複数ベンダーのテレメトリーが混ざるリスクが少ないこと 一つのSail Cube上で複数ベンダーのコンテナを動かす可能性がある ベンダー側のコンテナ側の設定ミスによって、ベンダー同士のテレメトリーが混 ざってはいけない オブザーバビリティ・プラットフォームに入るテレメトリーのサンプリングやフィル ターをベンダー側が制御できること オブザーバビリティ・プラットフォームの課金体系はしシグナルの量なので契約 している主体がサンプリングやフィルターをいじれる必要がある Sail Engine提供時に求められるObservabilityの要件 

Sail Engine提供時のアーキテクチャ 

OTel Collectorのデプロイ戦略 (ベンダーコンテナのサイドカー) OTel Collectorをベンダーコンテナのサイドカーとしてデプロイ k8sのDeploymentでまとめてデプロイ コンテナアプリから他のOTel Collectorへのアクセスを制御 

OTel Collectorのデプロイ戦略 (ローカルコレクター) ローカルコレクターがゲートウェイ的に振る舞う ベンダーコンテナのサイドカーからテレメトリーを収集 クラウドへの接続点をローカルコレクターのみに絞る NW接続時のバッファリング、永続化の設定やクラウドへのアクセ ス部分を一元管理できる 

OTel Collectorのデプロイ戦略 (ベンダー毎のCollector) ベンダー毎のサブネット上にベンダー用のOTel Collectorを設置 ベンダー側にOTel Collectorの定義を書いてもらい、CloudSailが デプロイおよび運用 ベンダーがプラットフォームに入るテレメトリーの量を制御 

今後の課題 ゲートウェイコレクターの冗長化 Cubeが増えればゲートウェイコレクターの負荷が上がる コレクタープールとして管理していく必要性 リアクティブにならないためのcubeのアラート設計 今後の運用で実際に起きたシステムの障害とテレメトリー を紐づけていくことで適切なアラートを設計 障害が発生する予兆を事前に察知して先回りした対応を実 現する(ex. ハードウェア交換、コンテナリソース調整) 

[PATIENT] [STRUCTURE] [MODULE] まとめ ispec.inc/summary 

OTel Collectorのオープンさ、柔軟さはオンプレとクラウドのハイブリッド環境でより強みが出る サイドカー、ローカルコレクター、ゲートウェイ等々のデプロイモデルを適材適所で活用し、プロ ダクトのフェーズに合わせてObservability基盤も成長 オープンで柔軟なOTel Collectorの圧倒的な強み 

We are Hiring!! 世の中には様々な課題で溢れています。 その中でも医療の課題はとても複雑な構造的課題であり、 この課題と向き合うのは社会的に意義のあるものです。 私たちのエンジニアリングの力を医療の課題に用い、 少しでも明るい未来を作る仲間を募集しております。 Entrance Book