目に見えないエラーを検出：ケニアのHIV対策プログラム向けに重複検出エージェントを構築した方法

Elasticsearch 8.11（Serverless）上でElastic Agent Builderを使用し、Claude Sonnet 3.7を推論モデルとしてマルチエージェントシステムを構築しました。すべてを一つの巨大なエージェントが行おうとするのではなく、検出エージェント、リスク評価エージェント、アクション推奨エージェントという3つのエージェントに作業を分割しました。それぞれに狭い範囲、特定の入力、そして定義された出力形式があります。

検出エージェントは患者インデックスに対してES|QLクエリを実行し、3つのレンズを通じて重複を検索します。具体的には、施設間のパターンマッチング（同じ患者が複数の施設に現れる）、人口統計分析（例：名前のバリエーション、一貫性のない性別識別子、部分的なIDマッチ）、時間的異常検知（遠隔地の施設での同日検査）です。これは検索レイヤーで、候補を浮上させますが、判断は下しません。

リスク評価エージェントはこれらの候補に対して、重み付けされたシグナルを用いて0～100のスコアを付けます。

• 複数施設訪問：最大40ポイント
• 人口統計上の不一致：最大30ポイント
• 地理的な不可能性：最大20ポイント
• タイミングの異常：最大10ポイント

ケースはCRITICAL、HIGH、MEDIUM、LOWの4つのティアのいずれかに分類されます。二値分類を用いなかった理由については、後ほど説明します。

アクション推奨エージェントは、スコアをケニアのヘルスケア環境に合わせて調整された具体的な次のステップに変換します。「CRITICAL」ケースの場合は即時のM&E担当者のレビュー、「MEDIUM」の場合は次の施設訪問でのフラグ付け、そして組織的なパターンを示す施設にはスタッフトレーニングの推奨を行います。このエージェントが存在する理由は、リスクスコアだけでは医療従事者には役に立たず、スコアに対して何をすべきかを提示する必要があるからです。

構築の初期段階では、よりシンプルなアプローチを試しました。それは、重複させるか、重複させないかという方法です。実際のデータに触れると、うまく機能しませんでした。

問題は、正当なフォローアップテストが重複のように見えることです。ARTを受けている患者は、数か月ごとに同じ施設に通院することになっています。乳児は繰り返し検査を受ける必要があります。二項分類を使用すると、正当な訪問回数が多すぎる（そして医療従事者はすべてのフラグを無視するようになる）か、誰かが同じ日に2つの異なる施設で少し異なる名前で検査するという微妙なケースを見逃すかのどちらかになります。

段階的なアプローチにより、医療従事者は優先順位をつけることができます。リスクスコアが87の「CRITICAL」ケース（同日検査、異なる施設、性別識別情報の不一致）は、直ちに対応され、スコア22の「LOW」ケース（同じ施設で予想されるフォローアップ間隔）はシステムに提出されます。最終判断を下すM&E担当者は直感ではなく証拠に基づいて行動します。

重みの調整には、実際のデータを用いて何度も試行錯誤を繰り返しました。最適かどうかにはまだ完全には自信が持てませんが、構造自体は適切であり、より多くの現場データを収集するにつれて、重み付けを調整していくことができます。

システム開発において、インデックス設計に他のどの部分よりも多くの時間を費やしましたが、それが最高の投資となりました。

インデックスのマッピングには、インデックス作成時に計算される派生フィールド（cross_facility_flag、total_tests、facility_count（患者ごと））が含まれます。主要な人口統計フィールドにはキーワード（完全一致）とテキスト（分析済み、あいまい検索）の両方のサブフィールドがあるため、検出エージェントは追跡するシグナルに応じて完全一致とあいまい一致を切り替えることができます。サンプルIDには完全一致、患者名にはあいまい一致が使用され、「Wanjiku」と「Wanjiku Mary」は同一人物である可能性があります。

候補の事前絞り込みには、Elasticsearchのアグリゲーション機能を大いに活用しました。このシステムは、ペアワイズ比較を実行する前に、施設、テストタイプ、日付範囲ごとにレコードをバケット化します。これにより、より大規模なデータセットでも検出処理が扱いやすくなります。候補となるレコードを先に絞り込めるのであれば、すべてのレコードを他のすべてのレコードと比較する必要はありません。

ES|QLは今回初めて使用しました。ハッカソン中に学んだのですが、大規模なリアルタイム分析には非常に効果的です。最も効果的だったアーキテクチャーは、パターン検出と集計にES|QLを使用し、アプリケーションロジックの処理にPythonを使用するという組み合わせでした。初心者だったので、この分離のおかげでシステム全体を理解しやすくなりました。

ケニアの59の医療施設から収集した、匿名化された実際の患者記録1,010件を用いてシステムをテストしました。スキャンは10秒以内に完了しました。

重複した患者が131人特定され、その中には同日に複数の施設で検査を受けた5件のケースと、施設全体で意図的に性別識別子が一貫していない患者4人が含まれていました。

驚いたのは、同日に検査を受けた患者に関するケースに関してでした。根気強く手作業で確認すれば、名前の重複はいずれ見つかるでしょう。しかし、地理的に離れた2つの施設で同日に検査を受け、人口統計学的属性もわずかに異なる患者が検査を受けたというパターンは、意識的に探さない限りデータの中に隠れて見えません。M&E担当者によると、これらの事例は、もし見つかったとしても、手作業で明らかになるまでに数週間かかるだろうとのことでした。

初期のプロトタイプでは、リスクスコアと推奨事項が返されました。これをM&E担当者に見せましたが、出力を信用してくれませんでした。

これは技術的な失敗ではありませんでした。スコアは正確でした。しかし、フラグが立てられた患者を診る医療従事者は、なぜそれがフラグが立てられたのかを理解する必要があります。それなしでは行動に移しません。名前の不一致でしょうか？地理的な不可能性でしょうか？タイミングでしょうか？その文脈がなければ、システムはブラックボックスとなり、患者の治療がかかっている臨床現場ではブラックボックスは無視されてしまいます。

具体的な根拠に基づいた説明を生成するアクション推奨エージェントを構築したことで、プロトタイプが実際に使用されるものに変わりました。ナイロビでデモを行ったM&E担当者は、「これがあれば先月は3日も時間を節約できたのに」と言っていました。

この教訓は医療分野に限ったものではありません。AIシステムの推奨事項に人間の介入が必要な場合、その説明自体が推奨事項と同様に製品の一部となります。

各エージェントはElastic Agent Builderで構築され、ドメインの専門知識、推論ステップ、出力形式がカスタム命令により定義されています。その指示の質がどれほど重要かを過小評価していました。

初期バージョンは指示が曖昧だったため、出力結果にばらつきが生じました。検出エージェントは、その理由を説明する場合もあれば、説明しない場合もありました。リスク評価エージェントは時折スコアリング要素を飛ばすことがありました。信頼性の高い、証拠に基づく出力を得るには、必要な証拠フィールドについて具体的に指定し、エージェントが従うべき推論の連鎖を明確にする必要があります。カスタム指示はコードのように扱いましょう。正確に記述し、例外的なケースをテストし、繰り返し改善してください。

これは棚上げされるようなハッカソンのデモではありません。この計画は今後2～3ヶ月かけてナイロビ郡の5つの施設で試験的に実施され、M&E担当者の研修と、実際の運用実績データの収集を行い、リスク評価の精度向上を図る予定です。

その後、ロードマップには生体認証の一致統合とスワヒリ語の音声名ファジーマッチングが含まるようになりました。これは現在のアプローチでは本当にギャップがあります（「Wanjiku」対「Wanjiku」は簡単ですが、「Njeri」対「Njery」は、標準のファジーマッチングではうまく処理できない音声認識が必要）。最終的には、HMISでの患者登録中にシステムをリアルタイムで実行し、重複をシステムに入力される前に捕捉したいと考えています。

長期的には、ケニアの保健情報交換システムに接続し、それを47の全郡に拡大したいと考えています。Elasticsearchの水平スケーリングとモジュール式のエージェント設計により、コアシステムを再構築する必要はなく、拡張機能を追加するだけで済みます。全国規模での予測される影響は、年間19万5000ドルの節約と重複検査の70％削減となります。さらに重要なのは、臨床医が治療方針を決定する際に参照する記録を信頼できるようになるということです。

データ品質が人手による作業を必要とする、目に見えにくい問題となっている分野で作業する場合、Elastic Agent Builderを使用すると、パターン検出のための ES|QL、階層分析のためのマルチエージェントオーケストレーション、ドメイン固有の推論のためのカスタム指示などのツールを使って単にクエリを実行するだけでなく、問題を説明する仕組みを構築できます。予想よりも早く完成しました。

この構築を通して最も満足できた瞬間は、設置そのものではなく、この作業を毎日行っている人がツールが自分の問題を理解したことをわずか 10秒ほどで認識した瞬間でした。