Concurrence が Unity Gateway を使用して、1兆トークン規模の臨床AIをどのように管理するか

医療AIには、エラーの余地がほとんどありません。患者ケアの調整を支援するAIエージェントは、信頼性の高い患者コンテキスト、データとモデルアクセスに対する明確な制御、すべてのインタラクションの可視性に依存しており、そのすべてが厳格なコンプライアンス要件を維持しながら行われます。 

Concurrenceは、これらのヘルスケアエージェントシステムを大規模に運用しています。同社は、AI臨床医、看護師、ケアコーディネーターから、アンビエントドキュメンテーション、ケアプランの要約、知識検索に至るまで、患者およびプロバイダー向けのワークフロー全体で臨床AIエージェントを構築しています。

Concurrenceは、本番AI環境全体で、現在30日ごとに約1,008億の入力トークンと1,120万のLLM呼び出しを処理しており、これは年間約1.2兆の入力トークンに相当します。月間トークン量は、2025年後半のベースラインから2026年7月までに約5倍に増加しました。

リスクの高い臨床ワークフローでは、信頼性の高いAIエージェントは、信頼できる適切に管理されたデータから始まります。大規模な信頼性をサポートするには、強力なコンプライアンス、厳格なエージェントテスト、および管理されたAIアクセスが必要です。Concurrenceは、これらの機能をDatabricksに統合しており、運用エージェントと会話状態には Lakebaseを、データとAIアセットの管理には Unity Catalogを、そして急速に成長する開発者AIワークロード全体での集中型AIアクセスとセキュリティには Unity Gatewayを使用しています。

信頼できるデータに基づいて信頼性の高い臨床AIを構築する

医療データは、システム間で競合することがよくあります。患者が既存の記録と異なる情報を提供する可能性があり、最新の値が常に最も信頼できるとは限りません。

Concurrenceは、既存の記録を上書きするのではなく、新しい情報を不変のイベントとして記録することでこれに対処しています。その履歴から、Concurrenceは各情報のソースと出所を保持しながら、現在の患者の状態を計算します。これを「ワールドモデル」と呼んでいます。これにより、エージェントは患者について知られていることの一貫したビューと履歴を得ることができ、患者や臨床医から学んだことを将来のワークフローのために状態にフィードバックすることができます。

Databricksは、このアーキテクチャの共有データ基盤を提供します。イベントは Zerobus Ingestを介して管理されたDeltaテーブルにストリーミングされ、これには月間270万件のワールドモデルイベントとピーク時には1日あたり9万件が含まれます。 Apache Spark™ Declarative PipelinesはConcurrenceのワールドモデルと臨床データを導出し、Unity Catalogは各顧客環境を管理し、Lakebaseは運用アプリケーションに必要な患者の状態、エージェントと会話の状態、およびナレッジベースデータを提供します。

ケアギャップと服薬遵守の働きかけはその一例です。Concurrenceのエージェントは、フォローアップケアが遅れている患者や服薬を中断している患者に電話またはテキストメッセージを送信し、既存の患者コンテキストを使用して会話を誘導し、学んだことを将来のワークフローのために患者の状態に記録することができます。Concurrenceはまた、ケアパケットガイド、看護師ケアプランの要約、臨床コンテンツレビューサーフェスなど、Databricks Apps上で本番アプリケーションを実行しています。それぞれが同じ管理された患者コンテキストとインフラストラクチャに基づいています。このアーキテクチャへの移行により、Concurrenceは自社開発のプロンプトログストアとリバースETLジョブを廃止し、管理されたDeltaテーブルとLakebase Synced Tablesに移行することができました。

本番環境投入前の臨床AIエージェントのテスト

Concurrenceの新しいプラットフォーム上のすべてのエージェントは、実際の患者に到達する前にシミュレートされた患者に対してテストされます。現在、新しいプラットフォームでのシミュレーションおよび評価トラフィックは、本番トラフィックの約7倍です。

Concurrenceのデータアーキテクチャにより、このテストが可能になります。患者の状態は不変のイベント履歴から計算されるため、チームはその状態をリプレイし、実際の患者記録を変更することなくさまざまなパスをテストできます。これにより、Concurrenceはエージェントを患者に展開する前に、さまざまなシナリオにどのように応答するかを評価できます。

エージェントのトレースはZerobus Ingestを介してストリーミングされ、それらを生成した臨床データとともにDeltaテーブルに格納されます。DatabricksでホストされているClaudeを使用するスケジュールされた ai_queryジョブは、会話の品質と安全性についてこれらのインタラクションをスコアリングし、メモリを抽出し、結果をDeltaに書き戻します。患者データ、トレース、結果、評価が同じ管理された基盤上にあるため、チームはパフォーマンスの変化がモデル、データ、またはワークフローのいずれに起因するのかを調査できます。

医療におけるAIガバナンスとコンプライアンスの強化

Concurrenceにとって、HIPAA要件は最初からアーキテクチャを形成しています。Concurrenceは現在、HIPAA、GDPR、SOC 2に準拠しており、HITRUSTおよびISO 27001/42001は進行中です。各医療機関は独自のスキーマとサービスプリンシパルを取得し、アクセス制御、リネージ、監査証跡はUnity Catalogを通じて管理されます。

バッチAIワークロードの場合、ConcurrenceはBAAの下でDatabricksホスト型Claude上でai_queryジョブを実行します。そのエンドポイントリゾルバーは、BAAでカバーされる名前空間内のモデルのみを許可し、PHIがカバーされていないモデルにルーティングされるのを防ぎます。同じカバーされたパスは、Concurrenceの自傷行為、自殺念慮、および医療緊急事態に対する安全性分類を実行します。したがって、その最もリスクの高いAIワークロードの一部は、同じアーキテクチャ上の制約によって保護されています。これはまた、Concurrenceのモデルルーティングへのアプローチを形成します。ルーティングはコストゲートされる前にコンプライアンスゲートされます。Concurrenceが品質、パフォーマンス、またはコストを考慮する前に、モデルはまずワークロードのコンプライアンス要件を満たす必要があります。

リアルタイムの患者および臨床医の推論は、現在もConcurrenceの既存のプロバイダーインフラストラクチャ上に残っています。Concurrenceは、リアルタイム推論のためのUnity Gateway統合をすでに構築し、機能フラグを設定しており、合成カナリアが継続的にエンドツーエンドでテストしています。必要なコンプライアンスカバレッジが利用可能になり次第、本番トラフィックはUnity Gatewayに移行できます。

Unity Gatewayによるコーディングエージェントの管理

Concurrenceは、開発者AIにも同じアプローチを適用しています。コーディングエージェントは、機密性の高い医療データを扱う顧客環境で作業する先行配備エンジニアを含め、エンジニアリング、運用、研究全体で使用されています。

Concurrenceは、すべてのコーディングエージェントのモデルおよびツールトラフィックを Unity GatewayのコーディングCLI、ugを介してルーティングします。開発者は承認されたモデルとMCPツールへの単一の管理されたパスを取得し、各リクエストはそれを作成した個人のIDに関連付けられたままになります。MCPアクセスは同じ環境を通じて一元的に管理され、エンジニアグループによって権限が割り当てられ、エージェントがDatabricks、Datadog、Linearなどのツールにアクセスする際に各ユーザーが個別に認証します。

その規模はすでに相当なものです。7月には、14人の個人ユーザーがUnity Gatewayを通じて358.5億の入力トークンを生成し、そのうち95.37%がキャッシュ読み取りでした。7月10日にugが展開されて以来、Concurrenceのコーディングエージェントは、約36万件のリクエストと累積610億の入力トークンを生成しています。

コーディングエージェントのトラフィックを一元化することで、Concurrenceは開発者AIがどのように使用され、どれくらいのコストがかかるかを可視化できます。すべてのリクエストはそれを作成したエンジニアに帰属され、個人は ug usageを通じて自身の使用状況を監視できます。組織レベルでは、Concurrenceは system.ai_gateway.usageからのDatabricks使用データを使用して、使用中のモデル、トークン消費量、キャッシュ率、および個人とチームごとの支出を追跡します。

Unity GatewayによるAIアクセスの集中化

Concurrenceの目標は、Unity Gatewayを使用して、本番、バッチ、および開発者AIを共通の推論制御ポイントの下に置くことです。開発者AIはすでにUnity Gatewayを介して実行されており、バッチ推論はBAAでカバーされるパスを介してDatabricksホスト型モデル上で実行されます。現在、Claude Opus 4.8とGPT-5.6 Solがコーディングエージェントモデルの使用の大部分を占めており、Opus 5の使用が増加しています。リアルタイムの患者および臨床医の推論は、必要なコンプライアンスカバレッジが利用可能になるまで、Concurrenceの既存のプロバイダーインフラストラクチャ上に残ります。

そのマルチモデルアプローチは、Concurrenceの臨床ワークロードにとって特に重要です。同社は現在、本番推論を提供する14のモデルと、統制された46のモデルのカタログを保有しています。ほとんどの本番稼働は、より小さく高速なモデルで実行され、フロンティアモデルはより複雑な推論のために予約されています。Concurrenceは、さまざまなヘルスケアタスクにおいてどのモデルが最も優れたパフォーマンスを発揮するかを判断するために、臨床推論ベンチマークを開発しています。

Concurrenceは、Unity Gatewayによるイノベーションのペースにも期待を寄せています。最近では、自社で開発しているヘルスケア特有のルーティングアプローチに対して、Unity Gateway Smart Routingのテストを開始し、その結果を公開しています。ヘルスケアにおけるモデルの適格性はコンプライアンスから始まるため、これらの評価では、インテリジェントルーティングが各ワークロードに設定された境界内でモデルの選択をどのように最適化できるかを評価します。開発者側では、Concurrenceはまた、コーディングエージェント環境全体でメタハーネスとしてOmnigentを検討しています。

ヘルスケアAIのための統合基盤

Concurrenceがより多くのワークフローをDatabricksに移行するにつれて、エージェントとのインタラクションごとに基盤の価値が高まります。各エージェントの作業は、次のエージェントが開始する患者の状態を豊かにし、新しいワークフローが既存のコンテキストを再構築するのではなく再利用できるようにすることで、新しいAIワークフローを追加する際の増分コストと労力を削減します。

年間約1.2兆の生産入力トークンというペースで、この複合的な基盤は重要です。患者のコンテキスト、運用状態、トレース、評価、ガバナンス、AIアクセスをDatabricks上で統合することで、Concurrenceはヘルスケアが要求する信頼性と制御を維持しながら、重要な臨床AIを大規模に展開できます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事