保険金を自動で払うスマートコントラクト｜支払後の訂正・異議申立てと支払期限

ある保険会社が、航空便の遅延に備える保険をスマートコントラクトで自動化しました。オラクル（外部のデータをチェーンに届ける仕組み）から「航空便が3時間遅延した」という報告値が届くと、保険金が支払われる仕組みです。

報告値を受け取ったその場で、送金まで済ませたとします。そのあとで、データの提供者が公式の値を訂正するかもしれません。契約者が「別の便に振り替えられた」と主張するかもしれません。けれども、すでに送ったお金は、もう戻せません。

自動の判定が正しく動いていても、こうした問題は起こります。入力データの訂正、契約の解釈が要る事故、重複した請求、支払先の誤り、オラクルの障害などです。そのとき、誰がどう判定を覆し、それをどう記録するのか。

答えの骨組みは次のとおりです。

• 請求の判定・確定・支払・異議申立てを、別々の段階として管理する
• 人が訂正するときは元の判断を消さず、新しい記録を足す
• 誰が承認し、差額をどう払う・返すかを先に決めておく

もう一つ、見落とされがちなのが支払期限です。日本の保険法は保険金の支払期限を定めていて、紛争で審査している間も、その期限は止まるとは限りません。以下では、この保険会社が異議申立てから審査、訂正、追加の支払・返還までの運用を作る流れで見ていきます。状態、権限、監査ログ、期限管理の順に、ブロックチェーンに記録する範囲も整理します。

ここで扱うのは、判断の結果を安全に実行する技術設計です。支払ってよいかという法的な判断や、個別の紛争の判断は扱いません。指標の設計、オラクルの独立性、支払準備金など、自動支払そのものの設計はパラメトリック保険のスマートコントラクト設計で扱っています。こちらはその後ろの工程、「自動判定に異議が出たとき、誰がどう覆し、どう記録するか」の話です。

この記事でわかること

• 払った後の訂正を、元の判断を残したまま記録する方法
• 紛争中も進む支払期限を、どう管理するか
• 人による訂正と緊急停止の権限の分け方、PoCで試す失敗

なぜ判定・確定・支払を別の段階にするのか

冒頭の保険会社の例で考えます。オラクルから「3時間遅延」の報告値を受け取り、同じトランザクションの中ですぐ送金したとします。データの提供者が公式値を訂正しても、契約者が別便への振替を主張しても、もう戻せません。だから紛争を扱うには、判定、確定、支払が別々の段階になっている必要があります。

参考になるのが、UMA Optimistic Oracleというオラクルの考え方です。公式の説明によると、提案されたデータは異議申立て期間内に異議がなければ、正しいものとして確定します。異議が出た場合だけ、Data Verification Mechanism（紛争時にデータを検証する仕組み）へ送られます。

保険に活かしたいのは、この仕組みそのものより、考え方のほうです。通常の請求と紛争になった請求とで、確定までの道筋を別にします。

保険会社の側では、請求ごとに一意な番号を付け、次のものを記録します。

• 入力された報告値のハッシュ、契約・約款の版、判定規則の版
• 金額、受取先

自動判定がするのは、支払候補を作るところまでです。異議申立ての期限が過ぎるか、必要な審査が終わってから確定させます。

すぐ払えることが商品の価値になる、少額で客観的な請求なら、異議申立て期間は短くできます。一方、主観的な損害の査定や高額の支払に、同じ短い期間を使う理由はありません。だから期間の長さは、請求の種類で変えます。状態の管理と冪等キー（同じ要求を何度送っても1回分しか処理されないようにする識別子）の一般的な作り方は、パラメトリック保険の記事に任せます。ここでは紛争に必要な部分だけを見ます。

払った後の訂正は、どう記録するか

外部の決済で送ったお金は、チェーン上の状態を巻き戻しても戻りません。だから、払った請求を前の段階へ戻すのではなく、訂正は新しい記録として足します。

そのため、請求の今の値だけでなく、どの判断からどの判断へ移ったかを保存します。紛争を扱うには、少なくとも次の8つの状態を用途に合わせて用意します。

支払済みの請求を、判定案の段階へ直接戻す作りは避けます。訂正するときは訂正の記録を新しく作り、元の決定を参照させます。追加の支払、返還の請求、将来の保険料との相殺などは、業務の判断を経て、別のお金の処理として追います。各状態で残す証跡と、記録の項目名は後半の「実装する人向けの詳細」にまとめています。

紛争中の支払期限は、どう扱うか

紛争になると「審査が終わるまで待つ」運用になりがちです。けれども日本の保険法は、保険給付の履行期（支払の期限）を定めています。損害保険・生命保険・傷害疾病定額保険のそれぞれについてです（保険法第21条・第52条・第81条）。主な点は次の3つです。

• 約款で支払期限を決めていても、それが確認に必要な相当の期間を過ぎる日なら、その期間を過ぎる日が期限になる。
• 期限を決めていない場合も、請求後、確認に必要な期間を過ぎれば、保険者は遅滞の責任を負い得る。
• 契約者側が正当な理由なく調査を妨げたり応じなかったりした期間は、遅滞の責任を負わないとされている。

つまり、紛争で審査している間も、支払期限は止まるとは限りません。だから紛争の状態管理には、審査の期限だけでなく支払期限も組み込みます。保険会社の側でそろえるのは、次の5つです。

• 期限の記録：請求を受け付けたときに、約款上の支払期限と、それを延ばす事由（追加調査など）があるかを記録する。延長の事由と、契約者へ知らせた日も残す。
• 期限の警告：紛争中になってからの日数ではなく、支払期限までの残り日数で警告する。期限が近い事案は、審査の優先順位を上げる。
• 争いのない部分の先行支払：金額の一部だけが争点なら、争いのない部分を確定として切り出す。残りだけを紛争中に残せる作りにする。
• 調査への協力状況：追加資料を頼んだ日、回答の日、答えのない期間を記録する。遅れの原因がどちらにあるかを、あとで説明できるようにする。
• 遅れたときの扱い：期限を過ぎたときの遅延損害金の計算や、通知が要るかは法務と決める。決まった計算式と承認の手順を、支払処理に組み込む。

どの事由で期限が延びるか、個別の事案でいつが期限かは、約款と法令の解釈を含みます。技術側が担うのは、その判断の結果を期限と理由コードとして記録し、画面と監視で見えるようにすることです。

異議は、どんな種類に分けて審査するか

実務で出る異議は、「オラクルの値が正しいか」だけではありません。少なくとも次の4種類があり、それぞれ別の審査の流れに振り分けます。

• データの紛争：観測値、時刻、対象地点、単位、データ源、公式な訂正の違い。
• 規則の当てはめの紛争：契約の版、免責、上限、丸め、境界値の当てはめの誤り。
• 事実認定の紛争：写真、診断、事故原因など、1つの数値では確定できない事実。
• 決済の紛争：判定は正しいが、受取先、重複した送金、銀行・チェーン側の確定状態に問題がある。

オラクルの仕組みの中には、誰が異議を出せるか、どこで審査するかを決められるものもあります。たとえばUMAのEscalation Managerです。誰が主張（assertion）や異議を出せるか、紛争をどの仲裁の流れで扱うか、オラクルの解決結果を採用するか。これらを方針として別々に決められます。

保険でも同じように、請求の種類ごとに次のことを決めます。異議を出せる人、期限、必要な保証金、濫用の防ぎ方、審査する人です。

ただし、契約者の正当な苦情を、保証金だけで締め出してよいとは限りません。顧客向けの手続は、商品・法域・契約に合わせて作ります。技術的なスパム対策とは別に考えます。

日本の保険会社なら、監督指針にも目を通しておきます。金融庁「保険会社向けの総合的な監督指針」（II-4-3-2-2）は、保険金等の不払いに関する苦情に触れています。不払いを決めた支払担当部門だけで対処せず、最終的にはコンプライアンス担当部門などの他部門が、適切に対処されたかを確かめる態勢です。スマートコントラクトの多数決だけで、この態勢の代わりになるわけではありません。むしろ、審査する人の独立性を、役割と承認の手順に反映する必要があります。

人が訂正するときに守る5つのルール

「手動の上書き（manual override）」という名前で、何でもできる関数を1つ作ったとします。すると緊急対応の名目で、請求金額、受取先、オラクル、契約規則を一度に変えられてしまいます。

訂正は用途ごとの関数に分け、どれも次の5つを守るようにします。

1. 対象を絞る：請求の番号と、変えてよい項目を指定する。全請求を一括で変えない。
2. 根拠を残す：事案の番号、理由コード、証拠一式のハッシュ、元の決定への参照を必須にする。
3. 役割を分ける：提案、審査、実行を別の役割にする。同じ鍵だけで完結させない。
4. 時間で守る：通常の訂正はタイムロックをかける。緊急停止はすぐ実行し、再開とお金の移動は別の承認にする。
5. 足すだけにする：履歴は消さない。新しい決定の版と、差額の処理だけを加える。

担当ごとに、できることとできないことを次のように決めます。どの担当も、1人で判定から送金までを完結できないようにします。

それぞれの担当が操作するときの条件は、後半にまとめています。こうした役割ごとの制御は、既存の部品でも作れます。OpenZeppelin Contracts 5.xのAccessManagerがその例です。コントラクトと関数ごとの役割、実行までの待ち時間、予約された操作をガーディアン（取消しの権限を持つ役割）が取り消す仕組みを備えています。ただし、この仕組みを使っても、保護の指定を付け忘れた関数は守られません。関数ごとのテストが必要です。

緊急停止と訂正の権限を、なぜ別にするのか

オラクルの鍵の侵害、二重支払、判定規則の不具合に気づいたら、被害を広げないための一時停止は素早く行うべきです。ただ、停止の鍵が漏れたときに、攻撃者が請求の承認やお金の移動までできては困ります。だから停止の担当者には、過去の請求を承認・否認する権限を持たせません。

止める範囲にも注意が要ります。全部を一度に止めると、顧客が証拠を出せなくなります。それは、復旧後の受付期限や支払期限にも響きます。だから止める対象は、次の4つに分けます。

• 新しい請求の受付
• 判定の確定
• 支払の実行
• 管理設定の変更

停止したら、インシデントの番号、止めた機能、開始時刻、期限を記録します。再開の前には、次のものを突き合わせる必要があります。そのため、期限が来ても自動では再開させません。

• 影響を受けた請求の範囲
• 最後に正常だったブロック（チェーン上の記録のまとまり）かイベント
• 外部の決済の実績

停止中に手作業で支払った請求にも注意が要ります。再開して自動の待ち行列へ戻す前に、同じ請求の番号で消し込み、二重に実行されるのを防ぎます。停止機能そのものの作り方はスマートコントラクトの緊急停止設計で詳しく扱っています。

ブロックチェーンには何を記録し、何を外に保管するか

請求の本文、診断書、事故の写真、顧客とのやり取りには、個人情報や機微な証拠が含まれます。これらは、そのまま公開チェーンに載せず、アクセスを制限したチェーンの外に保管します。チェーンに記録するのは、改ざんされにくく、複数の組織で突き合わせたい番号・ハッシュ・状態の移り変わりです。

1つの保険会社がすべての入力・審査・支払を管理していて、外部と一緒に確かめる必要がないとします。その場合は、通常の事案管理システム、改ざんに気づけるログ、役割の分離の方が簡潔です。ブロックチェーンは、人による訂正を要らなくする技術ではありません。複数の組織が、訂正の履歴を同じ順序で確かめる必要があるときの選択肢です。

受け入れ試験では、どんな失敗を試すか

正常な自動支払だけを試しても、紛争の作りは確かめられません。PoC（本番前の小さな試験運用）では、次の場面を試します。確かめるのは、状態・イベント・資金の残高・通知のすべてです。

• 異議申立て期限の1秒前と1秒後に異議を出し、期限の扱いが契約の説明と一致する。
• 同じ請求をAPI、担当者、再送の処理から重複して出しても、判定と支払が1件にまとまる。
• 紛争中は争点の部分を払えず、審査した本人が訂正を実行できない。
• 金額の一部だけが争点の請求で、争いのない部分だけを先に確定・支払できる。
• 支払期限が近づいたときと過ぎたときに警告が出る。延長の事由が記録されていない事案は、期限どおりに扱われる。
• オラクルの公式な訂正が届いても、元の報告値と元の決定が残り、差分だけが新しい版になる。
• 支払のトランザクションがタイムアウトした後、外部の決済を照会しないまま再送はできない。
• 停止用の鍵が漏れても、攻撃者は請求の承認、受取先の変更、お金の移動、再開を実行できない。
• 審査の証拠を見る権限が失効した後は、オンチェーンのハッシュから内容を復元できない。

本番では、異議の発生率に加えて、次のものも追います。

• 状態ごとの滞留時間、支払期限までの残り日数、期限を過ぎた件数
• 訂正の理由コード別の件数、同じ担当者による提案と承認の重なり、停止の範囲
• 訂正後の差額の未処理、オンチェーンの確定と外部決済の食い違い

人による訂正が増えたら、担当者の処理能力だけを見ないでください。入力データ、商品の判定規則、画面の説明のどこに、繰り返し起きる欠陥があるかを調べます。

採用してよいのは、どんなときか

スマートコントラクトを使っても、事故の事実、契約の解釈、顧客の本人性、外部の決済まで自動で真実になるわけではありません。設計レビューの合格条件は、通常時と紛争時について、次のことを1枚の権限表と状態の移り変わりで説明できることです。誰の入力を、誰が、どの期限で、どの証拠にもとづいて覆せるか。

向いているのは、請求の履歴を複数の組織で一緒に確かめ、組織をまたぐ訂正の順序をそろえる必要がある場合です。関係するのは、保険会社、データ提供者、再保険者、販売者、決済事業者などです。

一方、次のような場合は、通常のDBを中心にし、必要なハッシュだけを外部に固定する構成も比べます。

• 1つの組織の中の業務の流れを良くしたいだけ
• 主観的な審査が請求の大半を占める
• 個人情報を広く共有できない

実装する人向けの詳細

ここからは、保険会社で請求の状態管理と権限を実際に組む担当者の話です。

状態ごとに必ず残す証跡

次の段階へ進むときは、状態ごとに次の証跡がそろっていることを条件にします。

請求と訂正の記録項目

• 請求ごとに一意なclaim_idを発行し、入力報告値のハッシュ、契約・約款の版、判定規則の版、金額、受取先を記録する。
• PAIDを直接PROPOSEDへ戻さない。訂正時はcorrection_idを新しく作り、supersedes_claim_idで元の決定を参照させる。
• 争いのない部分はFINALIZEDとして分け、残りだけをDISPUTEDに残す。期限の警告はDISPUTEDの滞留日数ではなく、支払期限までの残り日数で出す。
• 停止のトランザクションにはincident_id、対象機能、開始時刻、期限を記録する。停止中に手作業で支払った請求は、同じclaim_idで消し込む。

役割ごとの実行条件

前半の役割表に、操作するときの条件を加えたものです。

AccessManagerを使うときの注意

OpenZeppelinのAccessManagerで守られるのは、restricted修飾子を付けた関数だけです。restrictedを付け忘れた関数は保護されません。権限の定義だけでなく、各入口の関数にテストを書きます。

関連記事

• パラメトリック保険のスマートコントラクト設計｜指標・支払・例外
• DeFi保険とヘッジの設計｜損失原因ごとのリスク移転と限界
• スマートコントラクトのアップグレード設計｜方式・権限・待機時間

XTELAができること

私たちは、請求業務の責任境界を整理し、紛争と訂正を扱う状態機械、支払期限の管理、オラクルと証拠の管理、権限分離を設計・開発します。重複提出や鍵漏えいを再現する障害注入を含めたPoCと、スマートコントラクトの監査も行います。支払期限や約款の解釈など法的な判断が必要な点は弁護士と連携して進めます。貴社の請求・紛争の流れを実装へ落とす段階で、お問い合わせからご相談ください。

主要参考資料

• UMA Documentation: How does UMA's Oracle work?
• UMA Documentation: Escalation Managers
• OpenZeppelin Contracts 5.x: Access Control
• 金融庁: 保険会社向けの総合的な監督指針 II-4 業務の適切性
• e-Gov法令検索: 保険法（平成20年法律第56号）

資料の確認日と注意

一次情報は2026年9月24日に最終確認しました。記載はその時点の公開情報にもとづく一般的な技術設計の解説で、個別商品の支払可否や約款・法令の解釈についての助言ではありません。