CurativeがClaudeのエージェントで医療提供者契約を週2,000件超に

米国の医療保険会社Curativeは、Claude上に作ったエージェントの階層で、医療提供者との契約を週に2,000〜2,400件のペースで結んでいます。2025年は1年間で約2,100件でした。契約交渉を受け持つエージェント「Gwen」を、料金を審査する役、送信前の文面をチェックする役が囲む構成で、契約の締結は同社の2025年の人手のおよそ50倍の速さになったと紹介されています。

2026年11月10日に公開された事例記事の内容を、エージェント設計の観点から読み解きます。

要点

数字

Curativeの数字

• Gwen経由の契約

  23,000件

  累計

• 週あたりの新規契約

  2,000〜2,400件

  2025年は通年で2,100件

• 1契約のトークン

  約2,000万

  当初のコストの約10分の1

• クレーム異議への回答

  90日 → 30分未満

  メールまたはFAX

• Gwenは1回の実行で1つの医療提供者だけを担当する。主にClaude Opusで動き、他の案件の情報は混ざらない
• 料金の妥当性はSonnetの審査役が判断し、約3分の2を通す。残りの非標準案件は人間(CEO)が承認する
• 送信前の文面はHaikuの送信前チェック役がすべて読む。Gwenが社内メモを提供者に同報した事故がきっかけで追加された
• ツールを細かく用意せず、Pythonを実行する1つのツールでdocxの修正履歴を統合する方式が最も安定した
• 契約チームは45人から約55人に増え、1人あたりの生産性は約2.5倍。人は関心を示した見込み客への電話に移った

全体として、エージェントに大きな権限を渡すより、別のエージェントに見張らせる構成が選ばれた事例です。

Curativeの事例で参考になる点

業務を自動化したい事業会社にとって

契約や調達のような、相手との往復が長い業務の自動化事例です。人を増やすだけでは届かない規模の目標に対し、エージェントを「1案件に1つ」付ける発想が取られています。1契約のコストが当初の約10分の1になったことで、大手のネットワークに見落とされがちだった小規模な提供者を取りにいく戦略が成り立っています。エージェントは大病院にも個人診療所にも同じ注意を払います。

Curativeは契約チームの報酬にもGwen経由の案件を含めています。人とエージェントが同じ目標を追う形にして、役割の奪い合いを避ける仕組みです。

エージェントを設計する開発者にとって

設計の判断材料は、後述の6原則のうち、ツール・実行の分離・実行の外側からの改善の3点です。権限の渡し方は、後述の「権限・失敗・監査の3つの問い」(事例記事末尾の問答)にまとまっています。

サブエージェントを畳むかどうかの判断基準はClaudeのサブエージェントをメインループに畳む判断で扱っています。

医療・規制業種にとって

事例記事はPHI(HIPAAが保護する健康情報)の扱いにも触れています。Gwenは長い間PHIに触れない領域だけで動かされ、のちにPHIのある領域へ移されました。現在はバックエンドの制御で会話に入る情報を絞り、エージェントの動作をログに残して監査に備えています。

事例記事は、BAA(HIPAAで事業委託先がPHIを扱う前に交わす契約)の締結も楽になったと書いています。CTOのIsaac Turner氏は、規制下でも新しいサービスを早く導入できたと話しています。Anthropicが公開しているBAAの案内ページには、BAAの対象がファーストパーティAPIやEnterpriseプランなど、承諾した組織1つに限られ、Claude Consoleやクラウド上のCoworkなどは対象外と書かれています。自社の構成がどこまで対象かは、導入前に確かめる必要があります。詳しくはClaude EnterpriseのBAA締結の前提条件とClaudeの医療活用ガイドを参照してください。

背景・文脈

検査会社から保険会社へ

Curativeは2020年創業で、2022年に医療保険事業を始めました。最初は検査の会社で、同社の内部推計では米国のCOVID-19検査の10%を処理しました。その過程でほぼすべての保険会社と取引することになったといいます。

英国出身の創業者たちは、患者が医療費を払わない仕組みに慣れていました。そこで予防に軸足を置く保険会社を作ろうと考えます。ところが全国規模の提供者ネットワークを作る難しさを、大きく見誤っていました。

CEOのFred Turner氏は、2025年に2,100件(その前年の2倍)の契約を結んだものの、このペースでは全国網の構築に30年かかると話しています。全国規模のネットワークを持つ保険会社が数社しかなく、それらが約30年前に作られたことも理由に挙げています。

会員は165,000人超、契約企業は1,200社超です(2025年12月)。商品は、Baseline Visitを終えるとネットワーク内の医療が自己負担・免責ともに0ドルになる設計で、Claude Platform、Claude Code、独自の請求システムを使っています。

エージェントの役割分担

Gwenの周りには、役割の違うエージェントが並びます。

役割分担

Gwenを囲むエージェント

• Gwen(主にOpus)

  問い合わせフォームから来た提供者を調べ、市場の料金データを示して料金案を返す。インバウンドもアウトバウンドも担当する。

• 料金の審査役(Sonnet)

  Gwenが標準テンプレートを超える料金を求めるときに、理由を読んで可否を決める。

• 送信前チェック役(Haiku)

  すべての連絡文を送信前に読む。止めた場合は理由を添えて戻し、Gwenが書き直す。

• 資格確認と登録

  署名後に別のエージェントが提供者のライセンスを確認し、請求の計算に使うデータと契約をシステムに読み込む。

Gwenが示す料金は、購入した請求データと、保険会社に公開が義務づけられた価格の透明性ファイルが根拠です。市場の相場を見せながら交渉する形になります。

営業側にはBradという別のエージェントもいます。こちらもOpus系で、ブローカー経由の見積もりへの追跡や、保険引き受け担当が手作業で整えていた従業員データの抽出を受け持ちます。

契約が結ばれるまで

アウトバウンドの案件は粘り強さが要ります。診療所は忙しく、返信が14通目のメールや9通目のFAXで届く例があるといいます。

交渉が始まると、Gwenは相手の修正案をCurativeの方針文書と突き合わせます。そのうえでPythonを書き、双方の変更を統合した最終版を作ります。フォームから署名まで、早ければ1時間です。

署名後の資格確認と、請求システムへの登録もエージェントが行います。

人の役割は電話に寄った

契約チームは45人から約55人に増えました。一人ひとりの生産性は約2.5倍になりました。面識のない提供者への最初の連絡と書類作業はGwenに任せ、人は関心を示した見込み客への電話を引き取ります。

Turner氏は、新しく診療所を開いた医師が提携と資格確認(クレデンシャリング)に3か月かかると、その間は収入がないと指摘します。契約が速くなれば、小規模な診療所が独立を保ちやすくなるという見方です。

請求・事前承認・財務の基盤はClaude Codeで作り直した

エージェントが動く土台である請求、事前承認、財務のシステムは、13人のエンジニアが今年Claude Codeで作り直しました。請求システムだけで100人年と見積もったこともありました。

システムはAWS上のPythonで、MCPとAPIを備えています。Claudeが書いたものなので、Claudeがその構造を理解しているというのがTurner氏の説明です。

請求の異議への回答は、以前は約90日かかっていました。現在はメールやFAXの異議に30分未満で、その請求に固有の内容を説明する手紙を返せます。多くの保険会社はテンプレートを差し込んだ定型文で返すため、提供者に不満が残りやすい、という対比が語られています。

運用で見えた設計上の教訓

事例記事は「人と交渉するエージェント」を作るうえでの知見を6つにまとめています。

設計原則

Curativeの設計原則

• 汎用のツールを1つから始める

  用途別のツールはうまくいかず、Pythonの実行を1つ持たせてdocxライブラリで修正履歴を統合する方式が最も安定した。

• 相手の使うチャネルに合わせる

  FAXツールを足したところ、Gwenの成約率が2倍以上になった。印刷したFAXに手書きして返す提供者も多い。

• 実行を分離する

  Gwenは案件ごとに記憶を持たない。記憶を持つBradでは、誤ったメモが残って消せなくなる悪循環が起こることがある。

• 実行の外側から改善する

  数日おきに、直近1万件の実行を抽出して異常を洗い出し、修正のPRを出すようClaude Codeに頼む。

• PHIの外で先に試す

  PHIに触れない環境で失敗を重ねてから、PHIのある領域へ移した。

• エージェントが自発的に始めた行動を見る

  提供者が社内共有用のチラシを求めると、Gwenは指示がないままPythonでチラシを作った。受付に断られた会員の件では、診療所に職員教育を求め、会員が受診できたかまで確認した。

実装の細部で気づくのは、記憶の扱いです。Gwenには持たせず、Bradには持たせています。同じ会社の同じ基盤でも、案件が独立している交渉役と、顧客との関係が続く営業役とで、方針が分かれています。

権限・失敗・監査の3つの問い

記事末尾の問答は、導入を検討する側の疑問に近い内容です。

• 最初に与える権限は、扱えると思う範囲より狭くする。Gwenは料金の上乗せ幅に人間の承認キューを置いて始め、段階的に緩めた。決定が定型化できる部分から緩め、そのうえで審査役を足した
• 誤りへの構え方は、完璧さではなく比較で決める。CTOのIsaac Turner氏の基準は、千人が契約を結んだ場合に後悔するミスが何件出るか、というものだった
• 数十万通のメッセージの監査は、すべて記録し、送信ごとに送信前チェック役を置き、Claude Codeで実行を抽出して見る

次はケアナビゲーション、提供者側のエージェントも視野に

事例記事の最後で、Curativeは次の展開を示しています。次はケアナビゲーションにエージェントを入れ、会員を案内し指導する130人のチームの手を広げる計画です。

Fred Turner氏は、提供者側にもエージェントが入ると見ています。請求の異議の多くは、すでにエージェントが書いたものらしいと話し、契約交渉でも提供者がエージェントを使うことを望んでいます。「適正価格が早く見つかれば、皆が医療の提供に戻れる」という趣旨の発言です。

Gwenを強くするより、審査役とチェック役で囲む構成が選ばれた

この事例で注目したいのは、エージェントの性能を上げる話より、エージェントを囲む構造の話が中心になっている点です。

Gwenに料金の裁量を広げず、Sonnetの審査役を挟んだことで、人間の承認は例外的な案件に絞られました。

もう1つは、送信前チェック役がHaikuで動いている点です。事例記事はHaikuを選んだ理由を書いていませんが、すべての送信文に走る確認役なので、単価の低いモデルを当てたと考えるのが自然です。モデルを役割で振り分ける設計は、Claude Codeのサブエージェントのモデル指定と配分でも同じ型を扱っています。

FAXを足した話も、モデルの賢さの話ではありません。相手が使う手段に合わせる判断が、成果を左右しています。FAX業務自体はClaudeをFAX業務で使う方法で別の角度から扱っています。

交渉の両側がエージェントになれば、Gwenの料金案も、相手側のエージェントを前提に組み直すことになります。事例記事に相手側の設計は載っていないため、どう変わるかは今後の報告待ちです。

留意点もあります。数値はいずれもCurative自身の説明で、記事には誤りの発生率や送信前チェック役が止めた件数は載っていません。「50倍」は2025年のチームとの比較で、他社の水準との比較ではありません。同様のデータが並ぶほかの導入事例はClaude導入事例まとめにあります。

まとめ

この事例で持ち帰れるのは、権限の広げ方です。Curativeは人の承認キューから始め、権限を緩める段階でGwenの裁量を広げる代わりに審査役を足しました。送信前チェック役も、内部メモが提供者に届いた失敗を受けて加えたものです。自社に当てはめるなら、取引先が実際に使う連絡手段と、BAAの対象になる利用面の確認が先になります。