Claude for Excelで保険の準備金を検証する — Cowork連携で異常を洗い出す手順

Coworkが準備金ワークブックと前期の提出資料を読み込んで数式の異常を洗い出し、Claude for Excelで修正、Claude for Wordで提出書類の説明文を仕上げる。この3段構成が、保険の準備金検証でClaudeを使うときの基本形です。データ取得はCowork、数式の修正はClaude for Excel、文書化はClaude for Wordと、アプリごとに役割が分かれます。

保険の準備金検証にClaudeを使うとは

評価基準日は先週の金曜。5タブに分かれた損害進展トライアングル(development triangle)を含む準備金ワークブック、別ウィンドウで開いた前期の提出書類、IBNR(既発生未報告)の動きを尋ねてくる選任アクチュアリー、そして2週間後に迫った州への提出期限。こういう状況から作業が始まります。

Coworkに評価用フォルダを渡すと、ワークブックを読んで数式を検証し、自社が運用するNAIC(米国の保険監督機関)コネクタ経由で前期の提出書類と最新の通達を取得します。そのうえで、損害進展係数(development factor、LDF)のどこがおかしいか、どのセルが誤った列を参照しているかを指摘します。指摘を受けてClaude for Excelでワークブックを直し、Claude for Wordで提出書類のメモを開く。ExcelからWordへの引き継ぎで会話の文脈が保たれるため、どの準備金区分がどう動いたかをWord側で説明し直す必要がありません。

数式の検証と異常の指摘はClaudeが担い、準備金の水準そのものを承認するのは人間です。この線引きは最後まで変わりません。

前提条件 — 接続とアドインの準備

• 評価用フォルダをCoworkにアタッチする。今期の準備金ワークブック(トライアングル・前期の提出メモを含む)を1つのフォルダにまとめておきます
• NAICを自社のリモートMCPサーバーとして接続しておく。この手順は、自社がNAICのデータソースを独自のリモートMCPサーバーとして運用している前提です。組織のOwnerが「Organization settings > Connectors」で「Add > Custom > Web」からサーバーURLを登録し、メンバーは「Customize > Connectors」で接続してCoworkのタスク内の「+」メニューから有効化します
• Claude for ExcelとClaude for Wordのアドインをインストールしておく。両方ともPro・Max・Team・Enterpriseの有料プランでGA(一般提供)のOffice add-inです

ステップ1: Coworkでワークブックを検証し異常を洗い出す

まずCoworkのチャットで状況を伝え、ワークブックに触る前に検証を依頼します。

Q1の準備金レビュー(Personal Auto BI)。選任アクチュアリーのレビューが来週、
提出期限は2週間後。数字を確定する前にワークブックを一通り見てください。
 
・評価用フォルダのワークブックを読み、数式を検証する
・NAICからFY24の提出書類と新しい通達を取得する
・前期と比べて損害進展係数とテール前提でおかしい箇所にフラグを立てる
・Excelに持ち込めるブリーフをください — セル参照、壊れている箇所、
  単なる数値の動きで説明が要るだけの箇所を分けて

同種の実行例では、前期(Q4)比の準備金の動きがこう返ってきました。

同時に、数式そのものが壊れている箇所を3件、数値は正しいが説明が必要な動きを1件に切り分けて返してきます。

数式の異常は次の3件でした。

• Triangles!K47 — 24〜36か月の進展係数が0.987でハードコードされている。同じ列の他のセルはすべてMethodology!B14の損害進展係数(LDF)テーブルから値を引いており、この1セルだけ一時的な上書きが戻し忘れられていた可能性がある。ドライバーから算出される値は1.024で、0.987のままだとその事故年のIBNRを約210万ドル過小に見せている
• Roll-forward!E22 — 2023年事故年のQ1既払金累計が、2022年事故年の列を参照している。89万ドルのズレ。行の他のセルのパターンは正しく、このセルだけがずれていた
• BF Method!D38 — 入力タブの120か月テール係数は1.015に更新済みだが、BF法の計算はまだ前回の1.012を使っている。前四半期にテールタブを再構築した際、3つの参照が繋ぎ変わっていなかった

説明が必要な動きは1件で、こちらは数式の誤りではありません。IBNRが960万ドル(+12%)増加した理由は、Personal Auto BIでAY2024(2024年事故年)の請求件数の発現がQ1に想定より8%多かったことと、LDFの見直しで12〜24か月のリンク比率が約50bp上乗せされたことの2つです。実際に起きた動きなので、提出書類側で説明する対象になります。

Coworkとの会話をそのままExcelに持ち込むより、「セル参照つきの1段落ブリーフをください」と最後に頼むほうが、次のステップに進みやすくなります。

ステップ2: Claude for Excelのサイドバーで数式を修正する

ワークブックを開いたまま、受け取ったブリーフをClaude for Excelのサイドバーに貼り付けます。

Q1の準備金レビュー — IBNRが960万ドル増、Ultimateが640万ドル増。
数式の修正が3件: Triangles!K47(ハードコードされたLDF)、
Roll-forward!E22(参照列の誤り)、BF Method!D38(テールが未反映)。
1つずつ説明したうえで正しい数値を示し、最後に準備金の動きを
再計算してクリーンなUltimateを見せてください。

回答にはセル参照へのリンクが付き、クリックすると該当セルへ直接ジャンプします。Triangles!K47の数式を確認せずに変更を承認しないことが、この作業を安全に保つ最低条件です。

修正が終わったら、同じサイドバーでテール前提の感応度も確認できます。

新しいタブにテールの感応度表を作ってください。テール係数を1.010・1.015・
1.020・1.025の4通りに振って、他の前提を固定したままUltimateがどう
動くかを見せてください。

Claude for Excelはピボットテーブルの編集や条件付き書式、データ入力規則(ドロップダウン)の作成といったExcelのネイティブ操作にも対応しているため、感応度表の体裁を整える作業も同じサイドバーで完結します。

ステップ3: Claude for Wordへ引き継いで提出書類の説明文を作る

数式を直し終えたら、案件フォルダの提出メモをClaude for Wordで開きます。Excel側の会話がそのまま引き継がれるため、どの準備金区分が動いてなぜ動いたかをClaudeはすでに把握しています。

準備金の妥当性セクションと、方法論変更の開示部分を書いてください。
テール係数を更新し、LDFの選定期間に事故年を1つ追加しました。
ASOP 36の記載要件を意識した書き方にしてください。

トラックチェンジで編集履歴が残るため、下書きの段階から人が手を入れた跡が追える点は、規制当局への提出書類として扱いやすい部分です。ただし、ASOP(アクチュアリー実務基準)への適合そのものを判定するのはClaudeではなく、選任アクチュアリーの責任であることは変わりません。

業界水準との突き合わせも一続きの会話でできる

提出書類を仕上げる前に、算出したLDFが業界水準から外れていないかをCoworkで確認しておくと、選任アクチュアリーへの説明が的確になります。

Personal Auto BIの12-24か月と24-36か月のリンク比率は、NAICが前四半期に
公開した業界ベンチマークと比べてどうですか。

Coworkは同じNAICコネクタから業界データを引き当て、自社の係数との差を返します。ワークブックの数式が正しくても、前提そのものが業界水準から外れていれば別の論点になるため、この確認は数式検証とは別に必要です。

Cowork・Claude for Excel・Claude for Wordの役割分担

同じ「準備金レビュー」でも、段階によって向くアプリが変わります。

保険の準備金検証で確認しておきたい制約

規制対象データを扱う業務だからこそ、便利さの裏にある制約を先に押さえておく必要があります。

• 監査ログ・コンプライアンスAPIの対象外: Claude for Excel上のやり取りは、組織が独自に設定したデータ保持期間を引き継がず、Enterpriseの監査ログやコンプライアンスAPIの対象にもなりません。準備金の意思決定プロセス自体を証跡として残す必要がある場合は、Excel上のやり取りとは別に、判断根拠をメモや議事録として残す運用を組み合わせます
• 入出力データは30日以内に削除される: 入力・出力データはバックエンド側で受信または生成から30日以内に削除されます。会話履歴自体はブラウザーのIndexedDBにローカル保存され、Anthropicのサーバーには同期されません
• 監査対象の数値をそのまま確定に使わない: Claude for Excelは、最終的な顧客提出物や監査対象になりうる計算を検証なしで使うことを推奨されていません。委員会・当局への提出前に、動かした数値は必ず人が再計算します
• データテーブル・マクロを含むブックは対象外: データテーブルやVBAマクロを含むワークブックには対応していません。準備金ワークブックは感応度分析のデータテーブルやマクロを抱えていることが多いため、検証にかける前に対象範囲を切り分けます
• 対応版に限りがある: Excel on the web、Windows(ビルド16.0.13127.20296以降)、Mac(バージョン16.46以降)が対象です。Excel 2016/2019の永続ライセンス版、iPad版、Android版では動きません

準備金検証でよくあるつまずき

• 前期提出書類をそのまま信用する: 外部から届いたワークブックやテンプレートには、隠れた指示が埋め込まれている場合があります。Claude for Excelがリスクのある操作を提案してきた際は、内容を確認してから承認します
• NAICコネクタの契約範囲を勘違いする: NAICのデータソースを自社でホストするカスタムコネクタとして接続している場合、接続できる範囲や更新頻度は自社側のMCPサーバー実装に依存します。プリビルドのS&P Global・LSEG・Daloopaコネクタと同列に扱うと、データの鮮度で足をすくわれます
• 数式修正と前提の妥当性を混同する: Triangles!K47のような数式の誤りは機械的に直せますが、成長率やテール前提が業界水準から外れていないかどうかは別の論点です。数式が合っていても前提が甘ければ、準備金の水準自体が誤ります

保険以外の業種でも、「外部データの取得(Cowork)→数値の修正(Claude for Excel)→文書化(Claude for Word)」という3段階の構造は応用が利きます。同じ発想の実務例はClaude for Excelでクレジットメモを作成する方法、金融業界でのClaude活用の全体像は金融業界のClaude活用ガイドで扱っています。保険業界での他社の導入事例はClaude保険・リスク管理導入事例にまとめてあります。

まとめ

保険の準備金検証は、前期資料の取得と数式検証(Cowork)、セル単位の修正と感応度分析(Claude for Excel)、提出書類の説明文の下書き(Claude for Word)という3段階に分かれ、会話の文脈がアプリをまたいで引き継がれます。監査ログの対象外であることと、監査対象の数値は必ず人が再計算することの2点を押さえたうえで、四半期ごとに繰り返す作業はプロジェクトやSkillとして保存しておくと、次回以降の立ち上がりが速くなります。