北米の医療テック企業Leagueは、健康保険の運営者や医療提供者向けに、給付の案内やケアプログラム、会員向けアプリを提供しています。保護対象の医療情報を扱う領域で、およそ12年にわたり事業を続けてきた企業です。Anthropicが公開した導入事例では、同社がClaude Codeを社内基盤に組み込み、開発の進め方そのものを組み替えたことと、その結果として公表された数値が記載されています。慎重さが要求される業種でAIをどう本番に載せたのかという点で、参考になる事例です。
何をしたか：Swarmという社内の司令塔
Leagueは、Claudeのプラットフォーム上に構築した社内のオーケストレーション基盤「Swarm」を通じてClaude Codeを使っています。仕組みはこうです。まず主導役のエージェントが作業を分解し、担当のエージェント群を生成する。それらが夜間に並列で作業を進め、翌朝にエンジニアが完成した成果物をレビューする。人が一件ずつ指示を出して待つ形ではなく、分解と並列実行を基盤側に任せ、人はレビューに回るという配置です。
導入の速さも公表されています。Claude Enterpriseの契約を金曜に結び、月曜には全社で使える状態になりました。医療情報を扱う企業として必要なセキュリティの土台は、四半期を待たずに整えられています。AI変革担当AVPのSigny Rolandさんは「12年近く続いてきた会社が、AIネイティブになるために必要なセキュリティ面をすべて立ち上げるのに、四半期もかからなかった」と述べています。
意思決定の考え方も語られています。データ・AIエンジニアリング担当SVPのJordan Christensenさんは「変化の速さを考えると、比較検討は終わった時点でもう古くなっている」と述べました。時間をかけて候補を比べるより、動かしながら判断するという姿勢です。2026年3月には、48時間で本番に出すことを目的とした社内イベント「Accelatron」も実施されています。
この判断が置かれている文脈も押さえておく価値があります。公式サイトによれば、Leagueが対象にしているのは保険者、医療提供者、コンシューマー向け健康事業の3領域です。音声とデジタルの双方をまたいだ働きかけ、ケアの抜け漏れの発見と解消、妊娠期の健康支援といった個別プログラムなどを提供しています。いずれも会員の健康情報を扱う業務であり、扱いを誤れば事業そのものが止まる領域です。慎重にならざるを得ない事業でありながら、比較検討に時間をかけない判断を選んだ点が、この事例の特徴になっています。安全性の担保を「導入を遅らせること」ではなく「土台を先に作ること」で解こうとした、と読み替えることもできます。
公表されている結果
事例ページに記載された数値を整理します。アイデアからプルリクエストまでの開発サイクルは半分になりました。従来2週間だったスプリントは、3時間で終わる小さな単位に置き換わっています。エンジニア一人あたりの週間マージ数は、展開前と比べて2〜3倍になりました。
利用の定着も数値で示されています。Claudeの利用率は98パーセントで、2026年3月に展開を始めた時点のおよそ80パーセントから上がりました。AIが書いたコードの比率は、4カ月でおよそ70パーセントから98パーセントへ変化しています。
このうち注目したいのは、スプリントの単位が変わったことです。2週間を3時間に置き換えるという変化は、単に速くなったという話ではありません。2週間の単位では、着手前に要件を固め、期間の終わりに成果を確認します。3時間の単位では、作って確認して直す往復が1日に何度も回ります。見積もりの精度を上げる努力より、間違いに早く気づく設計のほうが効く状態へ移った、という変化として読めます。
開発以外の業務にも広がっています。取引先のセキュリティリスク評価は、数週間かかっていたものが15分に短縮されました。直近53件のうち49件はClaudeが安全と判定し、そのうえで人が署名する流れになっています。セキュリティ部門の応答時間は3週間超から数時間へ、経理では60を超える業務が自動化されました。顧客向けの導入案件が2カ月前倒しで提供された例も挙げられています。
CTO兼共同創業者のDan Galperinさんは、この変化を「全員がプロダクト開発者になりつつある」と表現しています。経理やセキュリティといった部門まで対象が広がっていることを踏まえると、これは比喩ではなく、実際に職種の境界が動いているという意味に近いと読めます。なお、Leagueの売上、従業員数、Swarmの技術的な内部構造については、今回参照した一次情報に記載がありません。公式サイトでは、同社が保険者・医療提供者・コンシューマー向け健康事業の3領域を対象としていることが確認できます。
日本の実務者が参考にできる点
この事例でもっとも移植しやすいのは、レビューを人に残した設計です。セキュリティ評価で「Claudeが判定し、人が署名する」形をとっているように、判断の最終責任は人が持ったままにしています。53件中49件という数字は、裏を返せば残りは人の判断で処理されたということです。全部を任せるのでも、全部を自分でやるのでもない中間の設計が、規制の厳しい領域でAIを動かす条件になっています。
もうひとつは、待ち時間の使い方です。夜間に並列で走らせ、朝にレビューするという配置は、人とAIの稼働時間が重ならないことを前提にしています。人が指示して待つ形だと、AIの速度は人の待機時間に制約されます。作業を分解して投げ、まとめて受け取る形に変えるだけで、同じモデルでも実際の処理量は変わります。この発想は開発に限りません。記事の下書き、データの集計、問い合わせの分類など、まとめて投げてまとめて確認できる作業であれば、同じ形に置き換えられます。
三つめは、レビューの負荷を設計に織り込むことです。並列で作業を進めれば、当然ながらレビュー待ちの成果物も並列で増えます。Leagueの事例で「翌朝にレビューする」という時間の区切りが明示されているのは、確認の作業が滞留しないための工夫だと読めます。生成の速度だけを上げると、確認する人のところに負荷が集中し、そこが新しい詰まりになります。どれだけ作れるかと同じだけ、どれだけ確認できるかを見積もっておく必要があります。
なお、Christensenさんの「比較検討は終わった時点で古い」という発言は、検証をしなくてよいという意味ではありません。Leagueはセキュリティの土台を先に整えたうえで全社展開に進んでいます。順序として、比較に時間をかけるより土台を作って動かす方を選んだ、という話です。この前提を外して速さだけを真似ると、扱う情報の性質によっては危険な判断になります。
最後に、公表値の読み方です。ここに挙げた短縮幅や比率は、Leagueの事業内容と既存の開発体制を前提に測られた値であり、同じ施策が同じ効果をもたらすことを示すものではありません。とくに「開発サイクルが半分」という数字は、比較の起点になっている従来の進め方に依存します。自社で検討する場合は、まず現状の工程のどこに待ち時間が生まれているかを測るところから始めるのが現実的です。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。