T最新テックトレンド

事例研究と深掘り: LangGraph/MCPを活用した遠隔医療サポートエージェントの革新

AI Engineer
0:00--:--

現代医療において、患者ケアの向上と効率化は喫緊の課題です。特に、在宅医療や慢性疾患管理の分野では、患者との継続的なコミュニケーションと個別化されたサポートが不可欠となっています。しかし、これまでの手作業による対応では、スケーラビリティや柔軟性に限界がありました。

そんな中、AIエージェント技術の進化は、この課題に対する強力な解決策として注目されています。今回ご紹介するのは、私たちStrideがAila Science社（以下、Aila）と共同で開発した、LangGraphとMCP（Microservice Communication Protocol）を基盤とする革新的な遠隔医療サポートエージェント「Ava」の事例です。このプロジェクトは、AIエージェントがいかにして医療コミュニケーションの質と効率を劇的に向上させ、ビジネスに多大な影響を与えるかを示す、実践的なケーススタディとなるでしょう。

なぜ今、AIエージェントが医療を変えるのか？ - 背景と課題

Ailaは、早期妊娠喪失（流産）の治療を支援する女性の健康機関です。この治療では、患者は病院やクリニックで薬を受け取り、自宅で自己投与を行います。この期間は患者と家族にとって精神的に非常に負担が大きく、同時に投薬スケジュールや体調管理に関する正確な情報が必要とされます。

Ailaの既存システムはテキストメッセージベースであり、患者の質問に答えたり、治療の進捗を確認したりする役割を担っていました。しかし、その運用には以下のような深刻な課題がありました。

  1. オペレーターの負担とスケーラビリティの限界:

    • 患者からのメッセージに対し、人間のオペレーターが手動でコンソール上のボタンをクリックし、テキストメッセージを送信していました。
    • 患者が「薬を午後3時に服用しました」と報告したり、「出血があり、大丈夫か」と尋ねたり、治療に関する多様な質問をしてくるたびに、オペレーターはワークフロー上の適切なボタンを選択する必要がありました。
    • この手作業は非常に時間がかかり、多くの患者に対応するためには莫大な数のオペレーターが必要となり、人的リソースの拡張が困難でした。

  2. 新規治療プロトコルへの対応の難しさ:

    • 既存のシステムは特定の治療プロトコルに特化して構築されており、新しい治療法をサポートするためには、大幅なソフトウェアの再構築が必要でした。
    • Ailaは、流産治療以外にも化学療法など、患者が投薬スケジュールを忘れがちな状況でのサポートに関心を持っていましたが、そのたびにコードを書くのは非現実的でした。

  3. 医療承認済み言語の厳守:

    • 提供される情報は医療アドバイスであるため、厳密に医療承認済みの言語を使用する必要がありました。人間が自由にテキストを入力するのではなく、定型化された応答を選ぶ必要があり、これが柔軟性を損なっていました。

これらの課題を解決し、より多くの患者に高品質なサポートを提供するために、AilaはLLM（大規模言語モデル）を核とした新しいエージェントワークフローの構築を決断しました。目指したのは、システムをより柔軟に、より高機能に、そして最終的には「よりクールに」することでした。

AIエージェント「Ava」の誕生 - システム概要と革新的なアーキテクチャ

私たちは、従来のソフトウェアでは達成できなかった柔軟性とスケーラビリティを実現するため、AIエージェント「Ava」を開発しました。Avaは、LLMが対話の流れを制御する「エージェントワークフロー」の中核を担い、人間オペレーターの役割を「ボタン押し」から「監督」へと進化させました。

主要コンポーネントとエージェントの役割

Avaシステムは主に以下の2つのエージェントと人間による監督で構成されています。

  1. Virtual Operations Associate (VA):

    • 患者との会話の「心臓部」となるエージェントです。
    • 患者からのテキストメッセージを受信すると、会話の現在の状態を評価し、次にどのような返信（テキストメッセージ）、質問、またはアクションを行うべきかを決定します。
    • 具体的には、患者の投薬時間、薬の種類、現在のタイムゾーン、治療のフェーズなど、多岐にわたる患者の状態をシステム内で維持・管理します。
    • 決定された応答やアクションは、提案として次のEvaluator Agentに渡されます。

  2. Evaluator Agent (LLM as a Judge):

    • VAエージェントが生成した提案を評価する役割を担います。
    • これは「LLM as a judge」と呼ばれるプロセスで、VAが生成した応答が適切であるか、複雑な状況であるかなどを判断します。
    • LLMは自身の決定がどれほど「正しい」と考えているかを評価しますが、これに加え、更新されたアンカー、複数のメッセージ送信、患者データの変更（タイムゾーンの変更など）といった「複雑性」の条件も考慮します。
    • これらの評価基準に基づき、自信度スコアを生成し、特定の閾値を下回る場合は人間のレビューを推奨します。

  3. Human-in-the-Loop:

    • AIエージェントが自律的に対応できない複雑な状況や、自信度スコアが低い場合に、人間オペレーターが介入します。
    • オペレーターは、AIエージェントの生成した応答やその根拠（Rationale）を確認し、必要に応じて修正や指示を自然言語で与えることができます。
    • これにより、人間は単調なボタン押し作業から解放され、より高度な判断や監督に集中できるようになります。このモデルにより、人間のオペレーターはエージェントの「上司」としての役割を果たすことになります。

コア技術スタック

Avaの基盤を支える技術スタックは以下の通りです。

  • LLMフレームワーク: LangChainとLangGraph

    • 私たちはLangChainとLangGraphを主に採用しました。その最大の理由は「説明のしやすさ」にあります。複雑なエージェントのワークフローをクライアントに視覚的に、かつ直感的に説明できる点が非常に優れていました。
    • LangGraphのグラフ構造により、処理の流れ、ループ、人間が介入するポイントなどを明確に示せるため、非技術者とのコミュニケーションが円滑に進みました。
    • 他のフレームワーク（Autogen, CrewAIなど）も検討しましたが、説明性と、LangChainエコシステム（LangSmithによる可観測性）が提供するサポート体制を重視しました。

  • LLM: Claude (Sonnet 4)

    • 主なLLMとしてAnthropicのClaudeを利用していますが、基盤となるコードはGeminiやOpenAIのモデルでも動作するようモデル非依存で設計されています。
    • Claudeは、その透明性と推論能力、そして柔軟なホスティングオプションが選択の決め手となりました。特に、Claudeの大きなコンテキストウィンドウは、RAGなしで多数のドキュメントを読み込ませる戦略を可能にしました。

  • 補助システム:

    • フロントエンドとバックエンド: Node.js (バックエンド), React (ダッシュボード), MongoDB (データベース)。
    • SMSゲートウェイ: Twilio。
    • インフラスト: AWS（複数のリージョン展開に対応するため）。
    • 評価システム: PromptFu（LLM as a judge）。

BlueprintとKnowledge Base: コードから独立した治療設計図

Avaシステムの最も革新的な側面の一つは、治療プロトコルと知識ベースが「コードから独立している」点です。

  • Blueprint（治療設計図）:

    • 各治療プロトコルはGoogleドキュメントとして管理され、Markdown形式でエクスポートされます。これには、患者に伝えるべき医療承認済み言語、特定の状況での対応、質問のフローなどが詳細に記述されています。
    • 例えば、「薬を服用したか」「いつ服用したか」といった問いかけのメッセージ文言や、そのメッセージを送る「理由」が明記されています。この「理由」をLLMに提供することで、より適切な意思決定を促します。
    • このアプローチにより、医師の助手など、非技術的なクライアント側の担当者が直接ブルーPをメンテナンスできるようになり、コードを変更することなく新しい治療プロトコルを迅速に追加・更新できます。

  • Knowledge Base（トリアージ）:

    • ブルーPでカバーされていない質問（例えば、「お腹が痛い」といった症状に関する問い）に対応するための知識ベースも用意されています。
    • 私たちはRAG（Retrieval Augmented Generation）システムを採用せず、代わりに自己参照型のドキュメント構造を選択しました。これは、特定の治療フェーズに関する情報は特定のファイルを参照し、汎用的なQ&AはCSV形式のリストを参照するといった方式です。
    • RAGを採用しなかった主な理由は、医療分野において部分的な情報（スニペット）だけをLLMに与えることの信頼性の懸念と、LLMが治療全体の「形状」を理解する必要があるという考えからです。Claudeの大きなコンテキストウィンドウにより、ドキュメント全体をLLMに読み込ませることが可能でした。

Avaはいかに患者と対話するか - 詳細なワークフローと状態管理

Avaは、患者とのテキストメッセージでの対話を、状況に応じて柔軟に進めていきます。その裏側には、高度なワークフローと緻密な状態管理の仕組みが隠されています。

対話の開始から完了まで

患者との対話は、QRコードのスキャンや特定のイベントをきっかけに開始されます。

  1. 対話のキックオフ:

    • 患者が薬のパッケージのQRコードをスキャンし、電話番号を入力すると、Avaから最初のメッセージが送信されます。
    • 患者は自由形式のテキストで応答します。「はい」だけでも様々な言い方があるため、LLMがその意図を正確に解釈します。
    • Avaは、なぜその応答を選んだのかという「Rationale（根拠）」と、その応答に対する「Confidence（自信度）」を提示します。通常、ストレートなやり取りでは自信度は100%に近く、自動的に処理が進みます。

  2. タイムゾーンの特定と適応:

    • 遠隔医療の重要な要素の一つは、患者の正確なローカルタイムゾーンを知ることです。これは、投薬スケジュールやリマインダーを適切に設定するために不可欠です。
    • Avaは、患者からの「今何時ですか？」という問いに答える形でタイムゾーン情報を収集し、UTCからのオフセットを計算して患者のデータとして保存します。
    • 患者が移動してタイムゾーンが変わった場合でも、Avaは柔軟に対応し、システム内のタイムゾーン情報を更新します。

  3. 治療ステップの進行と「アンカー」の設定:

    • 患者が治療を開始する準備ができたと回答すると、Avaは治療プロトコルに基づいた次のステップ（例：投薬スケジュールの画像と具体的な日時）をMMS（マルチメディアメッセージングサービス）で送信します。
    • 患者が薬を服用したことを確認すると、Avaはシステム内に「アンカー」を設定します。アンカーは、治療の特定のイベント（例：ステップ1の投薬完了）がいつ発生したかを記録する重要な状態情報です。
    • これにより、患者が過去の服用状況を報告した場合でも、Avaは治療の進行状況を正確に把握し、適切な次のステップに進むことができます。以前のシステムでは、患者が投薬を飛ばしたり、予定と異なるタイミングで服用したりした場合、人間が手動で全てを更新する必要がありましたが、Avaはこれを自動化します。

  4. リマインダーと患者の離脱/復帰への対応:

    • Avaは、患者がメッセージに返信しなかった場合に備えて、投薬リマインダーなどの自動メッセージをスケジュールします。
    • 患者が数日間メッセージを送ってこなくても、Avaは最後に把握している状態から会話を再開できます。これは、患者に過度な負担をかけず、かつ治療から完全に離脱させないための工夫です。

状態管理の仕組み

Avaのエージェントワークフローにおける状態管理は、LangGraphのstateオブジェクトを中心に構築されています。

  • JSON Blobによる状態のシリアライズ:

    • 患者からメッセージが送られるたびに、会話の全状態（メッセージ履歴、アンカー、治療フェーズ、患者データなど）がJSON blobとしてLangGraphのstateオブジェクトにロードされます。
    • LLM自体は、このstateオブジェクトに直接アクセスするわけではありません。初期プロンプトでシリアライズされた状態がLLMに渡され、LLMはその情報をコンテキストとして利用します。
    • LLMは、後述するツール呼び出しを通じてこの状態を更新し、最終的にLLMが応答を生成すると、更新された状態が再びJSON blobとしてシリアライズされ、外部システム（Node.js/MongoDBのバックエンド）に保存されます。
    • この「会話のたびに状態をロードし、更新し、保存する」というアプローチは、LLMが過去の情報を過度に保持して混乱するのを防ぐとともに、ブルーPなどの外部情報が変更された場合でも柔軟に対応できる利点があります。

  • LLMとツールの連携による状態更新:

    • LLMは、会話中にlist_messages、set_anchor、update_patient_dataといった特定のツールを呼び出すことで、状態をリアルタイムに操作します。これらのツールはPythonコードとして実装されており、LangGraphのグラフ内で定義されています。
    • ツールの呼び出しにより、患者のタイムゾーンが更新されたり、新しいアンカーが設定されたり、次に送信すべきメッセージがスケジュールされたりします。
    • 会話履歴は、LLMに渡す際には最新の20〜25メッセージなど、必要に応じて圧縮されます。これにより、コンテキストウィンドウの制限を回避し、トークンコストを管理します。

「人間の介入」の仕組み

エージェントが全てを完璧にこなせるわけではありません。Avaでは、人間が適切に介入できる仕組みが導入されています。

  • 自信度スコアリングと複雑性に基づく介入閾値:

    • Evaluator Agentは、VAが生成した応答に対する自信度スコアを算出します。このスコアは、LLM自身が応答の「正しさ」を評価する要素と、特定の「複雑性」条件による減点要素を組み合わせたものです。
    • 例えば、「複数のメッセージを送信する」「患者データを更新する（タイムゾーンや名前の変更など）」「予定外の時期にリマインダーを送信する」といった状況は「複雑」と見なされ、自信度スコアから減点されます。
    • 自信度スコアが設定された閾値（例：75%）を下回った場合、その対話は人間オペレーターによるレビューが必要とフラグ付けされます。

  • 人間オペレーターによるフィードバックとエージェントの応答修正:

    • レビューが必要な対話は、オペレーションダッシュボードに「要対応」として表示されます。
    • 人間オペレーターは、VAが提案したメッセージと、そのRationale（根拠）を確認できます。
    • もし修正が必要な場合、オペレーターは自然言語でフィードバックを与えます。「患者の名前をメッセージに入れてください」といった具体的な指示を出すことで、LLMはそれを解釈し、メッセージを修正します。
    • このアプローチは、オペレーターが特定のUIツールを操作するのではなく、LLMと対話する感覚で修正できるため、システム全体の柔軟性を高めます。
    • フィードバックが与えられると、LangGraphの実行スレッドは再開され、LLMはフィードバックを基にメッセージを再生成します。この再生成されたメッセージは再度オペレーターによって承認されるか、自動的に送信されます。

  • Retry Logic:

    • LLMがツール呼び出しで間違ったJSON形式を生成したり、応答が不完全で会話が途切れたりする「マルフ形成」エラーが発生する場合があります。
    • 私たちは、これらのエラーを検出し、LLMに「ツール呼び出しを間違えました。もう一度やり直してください」といった具体的なメッセージを返すリトライロジックを実装しています。
    • この際、誤ったツール呼び出しの記憶がLLMを混乱させないよう、その時点のLLMの記憶をリセットし、改めて状態を読み込ませて再試行させます。これにより、エージェントは自力でエラーから回復し、対話を継続できます。

品質と信頼性の追求 - 評価システムと課題への挑戦

医療分野でのAIエージェントの導入には、その品質と信頼性を継続的に保証することが不可欠です。私たちは、厳密な評価システムと、実際の運用で直面する課題への挑戦を通じて、Avaの信頼性を高めてきました。

LLM as a Judge (PromptFu)

Avaの評価システムは、従来のテスト手法と最新のLLMベースの評価を組み合わせたハイブリッドアプローチを採用しています。

  • カスタム評価ハーネス:

    • 私たちは、LangSmithから定義済みのデータセットを抽出し、PromptFuを介して「LLM as a judge」形式で評価するカスタムハーネスを構築しました。
    • このハーネスはPythonアプリケーションとBashスクリプトで構成されており、LangGraphインスタンス（ローカルまたはクラウド）に対してテストを実行します。
    • 特に「時間」に関する操作（タイムゾーンの計算、スケジュール設定など）は、評価において困難な課題でした。3週間前の評価データと現在の実行結果では時間が異なるため、評価時にタイムスタンプを前処理するなどの工夫を施しました。

  • LLMルーブリックによる評価基準:

    • PromptFuでは、YAML形式で「LLMルーブリック」を定義し、評価基準をLLMに指示します。これにより、生成された応答が「ほぼ同じか」「軽微な不一致があるか」「完全に壊れているか」などを判断させます。
    • ルーブリックでは、「アンカーの文言のわずかな違いは気にしない」「タイムゾーンの細かい計算の差は許容する」といった具体的な指示をLLMに与え、過度に厳密な評価にならないように調整します。
    • この評価システムは、システムの現在の状態を、ハッピーパスのシナリオだけでなく、エッジケースに対しても継続的にテストするために利用されています。

エラーと改善のサイクル

Avaの品質向上は、継続的なエラーの特定と改善のサイクルによって推進されています。

  • 人間による「レッドチーミング」:

    • 初期段階では、最も経験豊富な医師の助手やオペレーションアソシエイトが「トリッキーな患者」を演じ、システムを騙そうと試みる「レッドチーミング」を実施しました。これにより、初期のプロンプトやガイドラインの弱点を特定しました。
    • その後、オペレーションチーム全体に拡大し、患者から実際に寄せられた複雑なケースを再現してテストを行いました。

  • フィードバックのプロンプトとガイドラインへの反映:

    • エージェントの不適切な挙動が発見された場合、その対話のログ（LangSmithに保存されている）を分析し、何が問題だったかを特定します。
    • 改善は主に、プロンプト（特に「ガイドライン」ドキュメント）とブルーPの更新によって行われます。例えば、特定の状況での指示を追加したり、誤解を招く表現を修正したりします。
    • 現時点では、患者との対話履歴を直接モデルのファインチューニングには利用していません。これは、モデルのリリースサイクルが早く、ファインチューニングのコストとメリットのバランスが取れないこと、そしてプライバシー上の懸念があるためです。私たちは、モデルがよりスマートで安価になるにつれて、全体を切り替える方が効率的であると考えています。

  • 安全性とプライバシー（HIPAA準拠）:

    • 医療データを扱うシステムであるため、HIPAAなどのプライバシー規制への準拠は最優先事項です。
    • システム全体はAWSのVPC（Virtual Private Cloud）内に隔離されており、外部からのLLMへの直接アクセスは不可能です。
    • LLMに渡される患者データは匿名化され、電話番号などの個人識別情報は含まれません。LLMは、意思決定に必要な最小限の情報（患者の識別名と治療状況）のみを受け取ります。
    • 患者からの感情的なメッセージに対しては、承認済みの知識ベースに基づいて対応を試みますが、感情的な混乱が深まったり、システムの対応範囲外と判断されたりした場合は、人間のオペレーターにエスカレートするか、「911に電話してください」といった緊急指示を出すように設計されています。

人間エラーとの比較

興味深いことに、人間オペレーターもまた間違いを犯します。過去のデータ分析から、人間がボタンを押し間違えたり、状況判断を誤ったりするケースがあることが分かっています。この事実は、LLMが完璧でなくとも、人間が監督することで、全体としてのエラー率を抑制し、むしろより一貫した、スケーラブルなケアを提供できる可能性を示唆しています。AIの導入は、人間がより高度な監督業務に集中できるため、リソースのより良い活用にもつながります。

ビジネスへの影響と未来の展望

AvaのようなAIエージェントの導入は、Ailaのビジネスに多大な影響をもたらしました。

ビジネスインパクト

  1. キャパシティの劇的な向上:

    • AIエージェントの導入により、Ailaは約10倍もの患者をサポートできるようになる見込みです。これは、オペレーターチームを大幅に増員することなく達成されるため、人件費の削減と効率化に直結します。
    • LLMがほとんどの対話を自動処理することで、人間オペレーターはより複雑なケースや、AIでは対応しきれない感情的な問題に集中できるようになります。

  2. コード変更なしでの新規治療の追加:

    • 最も重要な成果の一つは、コードを一行も書かずに新しい治療プロトコルを追加できるようになったことです。
    • 例えば、私たちは「Ozempic（オゼンピック）」の投薬管理プロトコルを、わずか数回のLLMとの対話とGoogle DocsベースのブルーPの定義だけで作成しました。Avaは、既存の汎用的なガイドラインと新しいブルーPを読み込むだけで、Ozempicの患者に対応できるようになりました。
    • これにより、Ailaは新しい治療領域への迅速な展開が可能となり、ビジネスの成長を加速させることができます。

  3. オペレーションコスト削減と効率化:

    • 単一のテキストメッセージ応答生成にかかるトークンコストは、平均で15～20セント程度と決して安価ではありません。しかし、人間のオペレーターを雇用し、訓練し、維持するコストと比較すれば、AIエージェントははるかに効率的です。
    • 特に、24時間365日の対応や多言語対応を考慮した場合、AIエージェントの費用対効果は絶大です。

将来の課題と展望

Avaの開発はまだ初期段階にありますが、その将来性は非常に大きいと考えています。

  • コスト最適化とキャッシュ戦略:

    • 現在のトークンコストは、キャッシングの積極的な利用によって管理されていますが、さらなる最適化の余地があります。Claudeの新しい「アワーキャッシュ」機能など、セッションを跨いだキャッシュ戦略を検討し、コストをさらに削減する可能性があります。
    • また、プロンプトの長さや、LLMの「おしゃべり」な特性を抑制することで、トークン消費量を減らすことも可能です。

  • 評価システムのさらなる洗練:

    • 現在のLLM as a judgeシステムは機能していますが、自信度スコアリングと複雑性評価の間の conflation（混同）など、改善の余地があることを認識しています。
    • より洗練された評価基準や、特定のエラーパターンを自動的に検出するAIモデルを導入することで、システムの堅牢性をさらに高めることができます。

  • エージェントの自律性と人間監督のバランス:

    • どこまでエージェントに自律性を与え、どこから人間が監督すべきかというバランスは、今後も継続的に調整していく必要があります。
    • 複雑な状況では人間が介入することが不可欠ですが、AIエージェントは人間の判断を補完し、その専門知識をより有効に活用できる環境を提供します。

  • 医療分野におけるAIエージェントのさらなる可能性:

    • 今回のテレメディシンサポートエージェントの成功は、AIエージェントが医療分野の様々な側面で革新をもたらす可能性を示唆しています。
    • 投薬リマインダー、症状の初期トリアージ、慢性疾患管理、患者教育など、多様なユースケースでAIエージェントの活用が期待されます。

結論

Ailaのテレメディシンサポートエージェント「Ava」の事例は、AIエージェント技術が単なるコード生成やデータ分析に留まらず、人間の専門知識と協調しながら、実世界の複雑な課題を解決できることを明確に示しています。LangGraphのようなフレームワークは、このような複雑なワークフローを構築し、説明可能にするための強力なツールとなります。

もちろん、この道のりには技術的な挑戦や倫理的な考慮が伴います。特に医療分野では、安全性、プライバシー、そして信頼性が何よりも重要です。しかし、適切な設計、継続的な評価、そして人間がループに入る仕組みを導入することで、AIエージェントは患者ケアを根本的に変革し、医療従事者の負担を軽減し、最終的にはより多くの人々により良い医療サービスを提供できるでしょう。

私たちは、この事例が、AIエージェントの可能性を探求する開発者やビジネスリーダーにとって、具体的な洞察とインスピレーションを提供することを願っています。人間の知見とAIの能力が協調する未来は、すでに始まっているのです。

← 一覧に戻る