判断の7割が人に載る業界で、DXCがAIに任せた4つの層

AIをどこまで任せるかを決めるとき、現場の議論はたいてい「精度は足りるか」から始まります。米DXC Technologyが公表した事例は、そこではなくあとから説明できるかを先に置いていました。同社は世界の保険会社の基幹システムを動かしている会社で、AnthropicのClaudeを自社の統合プラットフォームAssureの全層に入れたことを公表しています。

読みどころは、成果の数字よりも順序です。DXCはモデルを選ぶ前に条件を並べています。すべての行動を追跡できること、試験導入ではなく本番であること、中核業務であること、判断の単位で効果を測れること、価値が出るまでが速いこと。この5つを満たせるかどうかで評価した、と書かれています。

この記事では、Anthropicが公開した導入事例と、DXC公式サイトにあるAssureの説明の2件だけを材料にします。書かれていない項目は埋めません。数字は原文の表記のまま扱い、通貨や単位の換算はしません。確認日は2026年9月3日です。

どんな会社の、どこにAIを入れたのか

DXC Technologyは、保険業界の基幹システムを提供している会社です。導入事例によれば、保険会社・ブローカー・第三者管理業者を含む1,100社が同社のプラットフォーム上で契約を動かしています。その規模は原文の表記で「billions of policies」、扱う年間保険料は「between five and seven trillion dollars」と書かれています。桁の大きい数字なので、換算はせず原文のまま示します。

Assureは、その一群をまとめる統合プラットフォームです。DXC自身の説明では、AWS上で動くクラウド環境で、ホスティング、運用の可視化、コンプライアンス、保護、システム連携までを含みます。公式サイトには、AWS上に原文の表記で28M+の契約があること、運用コストを最大40%削減できること、30件を超える顧客の移行実績があることが挙げられています。同社は自社を、保険業界向けの中核技術の提供者として世界で1位だと記載しています。

AIを入れた対象は、この基幹側です。新しく作った実験用のアプリではなく、請求書類の読み取りから規制対応の記録までを担っている土台のほうに置いたということになります。DXCは約1年かけて、Claude Platform上でAssureを作ってきたと書かれています。

判断の7割が人に載っている、という前提

なぜ基幹側なのか。導入事例は、保険という事業が2つの判断で成り立っていると説明します。引き受けるかどうかと価格を決める引受、そして何をいつ支払うかを決める請求です。DXCのBill Pieroni氏（Global AI, Strategy & Growth Executive）は、この2つが業界の生む価値のすべてを動かす判断だと述べています。

そのうえで同氏は、こうした判断の70%が、構造化された規則ではなく人の判断に載っていると見積もっています。しかも量が多い。平均的な保険会社では、1時間に満たない時間で数百万件の判断が行われる、という表現が使われています。

その判断は書類の上で動きます。申込みも請求も、メール、ファックス、紙、電話で届き、手入力かOCRが必要になります。業界が抱えるデータは原文の表記で「four exabytes」あり、そのうち使える状態にあるのは15%未満だとPieroni氏は見ています。Claudeを入れる前は、書類を読み解く作業が請求業務の専門家の時間の40〜50%を占めていた、と書かれています。

滞留はそのままコストになります。事例には、解決までの時間が請求の重さを左右する要因の一つであり、時間がかかるほど費用が増えるという説明が置かれています。加えて、顧客が保険会社を離れる理由は2つしかなく、1つは請求の対応を誤られたこと、もう1つは1年で10%を超える値上げだ、とも整理されています。損害保険の会社が長期的には1%の利幅で動いていることを踏まえると、どちらも吸収できない、という論の運びです。

Assureの4層すべてにAIを置く

Assureは4つの層でできています。1つめは書類インテリジェンスです。書類が届くと、Claudeがその種類を1秒未満で分類します。保険契約、当事者、金額、日付といった要素を抜き出し、人の作業が必要な箇所を立てます。引受側でも同じ層が申込内容を読み、リスクを構造化して、例外にあたるものを引受担当へ渡します。

2つめはワークフローの調整で、判断を扱うべき担当者へ回します。3つめはSmart Appsです。事故が起きたときの第一報や、支払いに備えて金額を積む準備金の設定のように、1つの仕事に特化したエージェントを置きます。小さく始めて効果を確かめ、そこから広げられる形にするためだ、と書かれています。

4つめがコンプライアンスです。200を超える国と地域にまたがる業界を前提に置かれた層で、Pieroni氏の言葉では「誰が決めたか、何を根拠にしたか、いつか、人かエージェントか」がすべて記録されます。エージェントは決められた権限の範囲で動き、金銭・法務・重大な影響を伴う判断は人が確認の関門を持ちます。規制当局が任意の判断を最初から最後まで再構成できること、それがこの層の要件です。

読む量でモデルの階層を変える

実装として参考になるのが、モデルの使い分けです。事例には、すべての判断に同じモデルが要るわけではない、と書かれています。単純なトリアージは軽いティアのモデルで動かし、数百ページに及ぶ請求ファイルはフロンティアモデルへ回します。

これは費用の話としても読めますが、それだけではありません。1件の重さを先に見積もり、それに合った処理へ振り分けるという設計は、どのモデルを使うかという問いを「1つ選ぶ」から「振り分けの基準を決める」へ移します。DXCが選定の段階で数百ページの請求ファイルを試し、他のモデルでは文脈を保てなかったと述べているのも、この重い側の要件から来ています。

Assureは、DXC自身がどう説明しているか

ここまでの記述は、Anthropic側が公開した資料によるものです。売り手の側から見た説明でもあるので、DXC自身がAssureをどう位置づけているかも確認しておきます。

公式サイトのAssureのページでは、保険会社のデジタル移行を支える環境として説明されています。並んでいるのは、AWS上で動くクラウド基盤、既存資産をつなぐEnterprise Link、移行を速めるAssure Acceleratorsといった構成要素です。AIと自動化のサービスも、レガシーと新しい仕組みの双方を支えるものとして挙げられています。

つまり、導入事例で語られているのは新しい製品ではなく、すでに動いている基盤の中身が変わったという話です。AssureはAPI経由で既存の製品群とつながっているため、顧客側は個別の作り込みなしに接続できる、と導入事例には書かれています。

公表されている結果

公表されている変化のうち、いちばん分かりやすいのは滞留の解消です。請求書類の滞留は数日から数分になり、書類の分類は1秒未満です。規制の新しい規則を組み込む作業も、業界では12〜18か月かかっていたところが数日になったと書かれています。Claudeが複雑な法令を秒から分の単位で読み込むためです。

具体的な例として挙げられているのが、労災の計算です。対象は負傷前の平均週給で、これは回復中の労働者が毎週受け取る額を決める数字です。原文には、平均して52週分の総収入をもとに算出されるとあります。Pieroni氏はこれを「請求の全体が乗っている数字」と表現し、規制が厳しく、外せば取り返しがつかない領域だと述べています。プロジェクトが数か月遅れることが珍しくない、とも書かれています。

DXCはここに、規制、法令、文書化された規則、自社システムのアルゴリズム、自社の計算機を与えました。動くSmart Appは8時間で立ち上がり、初回で80%が正しかったとされています。残りの20%は請求の専門家が確認し、その確認がそのまま次の判定の材料になりました。人の判断を要する割合は、すでに70%から20%へ下がったと書かれています。

使っている人の規模も出ています。保険事業の14,000人のうち数千人がこれらの機能を使っており、現場の開発担当はClaude Codeで作っている、という記載です。

何が確認されていて、何が見通しなのか

ここで分けておきたいのは、公表された事実と、当事者の見通しです。上に挙げた数字はいずれも事例に記載されたものですが、そのあとに続く自律化の話はPieroni氏個人の目標として書かれています。同氏は、いま保険業界で誰も触れずに決まっている判断は約1%だとしたうえで、これを50%にしたいと述べています。規制そのものが規則の変更に合わせて更新される「living code」になる、という展望も同じ性質の話です。

目標は成果ではありません。当サイトでは、公表された結果と、これからやりたいことを同じ行に並べません。読者が判断に使えるのは前者だけです。

日本の実務者が読み替えられる点

業種が違っても持ち帰れるものが3つあります。いずれも効果を約束するものではなく、設計の材料です。

1つめは、モデルを選ぶ前に条件を書き出すことです。DXCは、追跡できること、本番であること、中核業務であること、判断の単位で測れること、速いことを先に置きました。選定の基準を先に文章にしておくと、評価が「賢いかどうか」の印象論から離れます。何を試すかではなく、何を満たしたら採用するかが先に決まるためです。

2つめは、記録を後付けにしないことです。誰が・何を根拠に・いつ・人かエージェントかを、動かし始めた時点から残す設計になっています。マーケティングの現場でも、生成物の出どころや承認者を残していなければ、あとから問われたときに再現できません。記録の設計は、動き出したあとでは足しにくい部分です。

3つめは、任せる範囲を割合で管理することです。この事例で示されているのは「全部任せた」ではなく、初回で80%、残りは人、そして人の確認が次の材料になる、という形でした。割合が動いていく前提で設計されているところが要点です。

読み替えられない部分もあります。保険の規制も、労災の給付の計算方法も、国によって違います。52週という前提や、判断の70%が人に載っているという見積もりは、同社の顧客基盤を前提にした話です。同じ数字を日本の業務へそのまま持ち込むことはできません。規制の強い領域でAIをどう使ったかという点では、当サイトの契約レビューを扱った事例もあわせて読めます。海外のAI活用事例は海外AI活用事例にまとめています。

公表されていないこと

確認できなかった項目を残します。導入にかかった費用、使っているモデルの内訳、軽いティアとフロンティアの振り分けをどの基準値で行っているか、Smart Appが何種類あるかは、どちらの一次情報にも書かれていません。数千人という利用者数も幅のある表現のままで、内訳の記載はありません。

初回で80%という値についても、どの範囲を分母にした正答率なのかは記載がありません。同じ条件で再現できる形では公表されていない、と理解しておくのが正確です。滞留が数日から数分になったという記述も、対象の業務範囲までは示されていません。

出典と注記

この記事は、Anthropicが公開したDXCの導入事例と、DXC公式サイトのAssureの説明の2件を出典としています。件数・人数・割合は原文の表記のまま記載し、通貨や単位の換算はしていません。引用した発言はいずれも事例に記載されているもので、当サイトが取材したものではありません。確認日は2026年9月3日です。