パラメトリック保険をスマートコントラクトで自動化する前に｜指標のずれ・欠測・支払資金

ある損害保険会社が、農家向けに干ばつの保険を考えています。一定の期間に降った雨の量が決めた値を下回ったら、あらかじめ決めた額を払う。損害を査定しないので、支払いを速くできます。こうした保険をパラメトリック保険と呼びます。雨量のほか、風速、地震の震度・マグニチュード、航空便の遅延時間なども指標に使われます。

支払いをスマートコントラクトで自動にすれば、もっと速くなる。企画の段階ではそう見えます。ところが、過去のデータを当ててみると困った例が出てきます。契約地点から離れた観測所では雨が降っているのに、契約者の農地は干ばつだった。この契約者には、保険金が払われません。逆に、損害がないのに支払いの条件を満たしてしまう契約者もいます。

観測所と農地が離れていれば、観測所の雨量は農地の状態を表しきれません。コントラクトは観測所の値を正しく読み、契約どおりに判定しています。つまりこれはコントラクトのバグではなく、指標の選び方から来る誤差です。指標と実際の損害とのずれをベーシスリスク（basis risk）と呼びます。コードが仕様どおりに動いても、商品として正しく払えるとは限らないのです。

ほかにも、止まる場面はいくつもあります。観測データが欠ける。公式の値が後から訂正される。大きな災害で支払いが一度に集中する。契約者が判定に異議を唱える。事業責任者が本番前に決めておくべきなのは、こうした場面での扱いです。以下では、この保険会社が商品を形にしていく順に、商品担当とシステム担当がそろえることを見ていきます。

この記事でわかること

• 指標と実損のずれを、契約前にどう確かめるか
• データの欠け・訂正・二重払い・資金不足に備える支払いの流れ
• 日本の商品審査で見られる点と、ブロックチェーンを使うべきかの見極め方

まず、何を損害の代わりの指標にするかを確かめる

全米保険監督官協会（NAIC）の解説によると、パラメトリック保険の契約で決めるのは3つです。

• イベントの大きさに応じた支払額
• 使う指標（パラメータ）
• 支払条件（トリガー）を満たしたかを確かめる第三者

World Bankの災害リスク資金・保険用語集は、ベーシスリスクをこう定義しています。指標で決まる支払額と、実損を査定する損害填補型の契約なら払われた額との差です。

冒頭の観測所と農地の例が、まさにこの差です。そこで保険会社は最初に、過去の損害データと候補の指標を、同じ時間・同じ地域の区切りにそろえます。そのうえで、次の5つを確かめます。

• 対象の危険：干ばつ、洪水、強風、地震、航空便の遅延など、何による経済損失を補うか。
• 場所：観測点、メッシュ、行政区域、飛行経路のどれを契約地点に結び付けるか。
• 時間：瞬間の最大値、時間平均、連続日数、便の到着実績など、どの観測期間を使うか。
• 支払曲線（payout curve）：閾値を超えたら定額か、段階式か、連続した関数か。上限と免責をどう置くか。
• 誤差：損害があるのに支払いが足りない「負のベーシスリスク」と、損害を超えて払う「正のベーシスリスク」を別々に測る。

損害との関係は、直線的とは限りません。極端な災害のときだけ誤差が大きくなることもあります。こうしたずれは、相関係数だけでは見えません。そのため、次の3つも確かめます。

• 保険期間の外のデータを使った過去検証（バックテスト）
• 地域・季節ごとの誤差
• 閾値の直前・直後での結果の変わり方

World Bankの研究も同じ整理です。指標で説明できない個別の損害の変動がベーシスリスクであり、気象と損害の関係は非線形になりうるとしています。

誰がどのデータに責任を持つかを7つに分ける

支払いが誤ったとき、どこで間違えたかを後から確かめられるようにします。システムは次の7つに分けて考えると、責任の持ち主がはっきりします。

各層で残す記録は、後半の「実装する人向けの詳細」にまとめました。

観測機器が故障していたり、指標が商品に合っていなかったりしたら、どうなるか。元の値そのものが誤っているので、オラクルを分散して多数決しても直りません。つまりオラクルは「正しいデータを出す箱」ではないのです。オラクルの役目は、誰がどの値をいつ署名し、どの集め方で報告値にしたかを、判定コントラクトへ安全に届けることです。

データの出どころは、数より「同時に壊れないか」で選ぶ

Chainlink Data Feedsの公式説明では、集約が何段にも重なっています。複数のデータ提供者が元のデータを集め、独立したノードが値を取得します。複数ノードの結果をチェーンの外で集約し、報告値としてスマートコントラクトへ渡します。

こうすれば、1つのAPIやノードに頼らずに済みます。ただし、同じ上流のデータを使っていれば、共通の障害は残ります。同じ衛星、同じ通信回線、同じ較正モデルでも同じです。

保険に使うオラクルでは、「独立している」ことを次の5点で確かめます。

• データ源の多様さ：地上観測、衛星、レーダー、航空会社の運航実績など、測り方か管理する主体が違う。
• 提供者の多様さ：同じ元データを転載する3社ではなく、障害や改ざんの責任を負う主体が分かれている。
• ノードの多様さ：報告値を作る運営者、クラウド、地域、署名鍵が一か所に集まっていない。
• 時刻の有効性：観測した時刻、公開された時刻、報告値を作った時刻、チェーン上で受け付けた時刻を区別し、古い値は受け付けない。
• 単位と精度：mm/hと累積mm、m/sとkm/h、現地時刻とUTC、小数の桁数を契約の版ごとに固定する。

3つのデータ源が同じ上流を使っていれば、3つのうち2つが一致しても、独立した確認にはなりません。逆に、災害で観測所の一部が止まったときに全員一致を求めると、支払いが最も必要なときに止まります。ですから「3つのうち2つが一致すれば安全」という決め打ちも避けます。

そこで、商品ごとに次のことを決めます。

• 通常時に必要な署名の数
• 災害時の代わりの手段と、データ源どうしのずれをどこまで許すか
• 最終的に確定させるまでの期限

オラクルが止まったときの代わりの手段と遮断の考え方はオラクル障害時のフォールバック設計で扱っています。正しい値の出どころ・新しさ・訂正の伝え方はRWA・金融システムのオラクル設計をご覧ください。

支払うかの判断と送金を分け、止まっても二重に払わない

たとえば、支払条件を確かめた直後に、支払いネットワークが止まったとします。確認から送金までを1つの処理で一気に行う作りだと、処理を最初からやり直すしかありません。やり直すたびに指標を評価し直すので、その間にオラクルの値が遅れて届いたり、訂正値が届いたりすると、結果が変わるおそれがあります。そこで支払いを、次の段階を一つずつ進む流れにします。各段階は記録に残します。

1. 契約が有効：契約の版、対象地点、観測期間、受取人、上限額を固定する。
2. 観測期間の終了：これ以降のデータは、訂正の手続きを除いて使わない。
3. 報告値の確認中：必要な署名数、新しさ、単位、署名、データ源どうしのずれを確かめる。
4. 支払条件の成立／不成立：使った報告値と判定規則の版を結び付けて、判断を保存する。
5. 支払額の確保：準備金から支払額を押さえる。同じ請求番号で二重に実行しない。
6. 支払い済み：決済ネットワークの確定IDと時刻を保存する。
7. 例外：欠測、異常値、データ源の食い違い、資金不足、支払い失敗を、理由付きで別扱いにする。
8. 異議・訂正：異議や公式の訂正を、元の判断への参照付きで処理する。

二重払いを防ぐ要は、支払いの番号の作り方です。同じ契約・同じ観測期間・同じ判定規則からは、番号が1つしか作られないようにします。そうすれば、同じオラクル報告やAPIの要求が10回届いても、支払いは1回だけです。

通信が途中で切れたとき、別の番号で送り直してはいけません。決済の結果を照会し、まだ払われていないと確かめられたときだけ、同じ番号でやり直します。

判断と送金も分けておきます。支払条件が成立したという事実は、支払いネットワークが止まっても消しません。支払額を確保した後の障害は、支払いの順番待ちに回して復旧します。指標を評価し直して、判断を作り直すことはしません。

パラメトリック保険でも、異議は起こります。公式値の訂正、観測地点の結び付け方、支払先の誤りなどです。そのときも「異議・訂正」を元の判断への参照付きで加え、過去の記録は上書きしません。異議の期限、争点ごとの審査の流れ、人による訂正の権限の分け方、紛争中の支払期限の管理はスマートコントラクト保険の請求紛争と人による訂正で詳しく解説しています。

閾値ちょうど・欠測・訂正の扱いを、契約前に決めておく

閾値ちょうどの値や、欠けたデータをどう扱うか。契約で決まっていなければ、実装者がその場で決めることになります。すると、欠けた値を0として扱う、食い違ったデータから都合のよい値を選ぶ、といった処理が入りこむおそれがあります。そこで次の6つの場面は、契約を結ぶ前に扱いを決めておきます。

緊急停止の仕組みは必要です。ただ、1つの管理者鍵で何でも変えられると、その鍵を持つ人が報告値や指標を書き換えられてしまいます。これでは、オラクルを分散した意味が薄れます。

OpenZeppelin ContractsのAccessControlが示す、役割ごとに権限を与えるやり方を使います。報告値の提出、一時停止、再開、判定規則の更新、資金の移動、アップグレード（コントラクトの差し替え）は、それぞれ別の役割にします。

ふだんの規則変更は、タイムロックと複数人の承認を通します。緊急停止はすばやく実行できてよいのですが、支払先や指標は書き換えられない権限に絞ります。停止機能の設計はスマートコントラクトの緊急停止設計も参考になります。

判定規則やオラクルのアドレスを差し替えられる場合は、既存の契約にどの版を当てるかを固定します。新しい規則を過去の契約にさかのぼって当てると、契約時に説明した支払条件が変わってしまうからです。新しい版は、原則として新しい契約に当てます。既存の契約を変えるなら、契約・規制上必要な手続きと記録を伴わせます。変更管理の全体像はスマートコントラクトのアップグレード設計で整理しています。

災害のときに一度に払えるだけの資金を用意する

判定を自動にしても、払うお金がなければ自動では払えません。支払コントラクトの残高を見るだけでは足りず、次のことを含めて資金計画を作ります。

• 同時に払う可能性のある最大額
• 再保険から回収するまでの時間差、決済に使う資産の換金しやすさ、手数料
• 支払先のネットワークが止まる場合

災害のときは、多くの契約が同じ指標で一度に支払条件を満たします。独立した少額の請求の平均からは見積もれません。

資金の持ち方は、次の3つが候補です。

• 全額を前もって分けて確保しておく（ring-fence）
• 保険会社の資金管理口座から、承認済みの上限まで引き出す
• 確定した請求を、ふだんの保険金支払いの仕組みに渡す

すべてをチェーン上のエスクロー（預かり）にすると、支払いの確実さは見せやすくなります。一方で、長期間の資金の拘束、運用資産・通貨の管理、鍵の侵害、資産の凍結、会計・規制上の扱いといった負担が増えます。法定通貨の銀行送金を使うなら、「支払い済み」にするのは送金APIが受け付けた時点ではありません。銀行側の確定結果と突き合わせた時点です。

保険負債、責任準備金、支払余力、再保険、資産の保全を、スマートコントラクトだけで置き換えられるわけではありません。個別の商品の認可・届出、約款、募集、顧客への説明、個人情報、支払原資の扱いは、対象の法域と商品の仕組みによって違います。技術側の役目は、決まった判断を権限・状態・記録に正しく反映することです。

日本では、商品審査とシステム設計を同時に進める

金融庁「保険商品審査事例集」（令和7年5月）には、地震パラメトリック（インデックス）保険の事例が載っています。被保険者の住む地域で一定の震度を超える地震が起きたら、定額を払う保険です。保険金の受取先として、二次元バーコード決済サービスなどを選べるようにしました。

審査では、決済サービスへ送金できなかったときの対応を含め、業務の流れとシステムが整っているかが確認されました。契約時に被保険者の同意を得る必要があることも示されています。

2026年9月24日時点の最新版である同事例集（令和8年1月）には、企業向け地震パラメトリック保険の事例があります。補償金額を決める根拠の「十分なデータ等」に、統計的な手法に加えて工学的な手法も含まれうると確認されました。敷地・構造などの区分ごとに、損害額の分布を推計するやり方です。

同じ事例では、実損てん補性を補う方法も挙げられています。損害申告書の提出を求めること、事後調査権を約款に定めることです。どちらも、日本でパラメトリック商品を検討できることを示しています。ただし、スマートコントラクトを使えば保険規制の要件を自動で満たせる、という意味ではありません。

商品担当と技術担当は、少なくとも次のことを同じ仕様書で管理します。

• 約款の支払条件の文言と、コードの比べ方・単位・時刻・丸めが一致していること。
• 指標、データ提供者、ベーシスリスク、欠測・訂正時の扱いを、契約者が理解できる形で示していること。
• 自動処理の結果に異議を申し立てる窓口と、説明できる判定の記録があること。
• 住所、農地、移動履歴、便の予約などの個人データを、公開チェーンに直接書かないこと。
• 保険会社、少額短期保険業者、販売者、データ提供者、開発・運用者の責任の分け方が、契約と運用で一致していること。
• 損害申告や事後調査を約款に入れる場合、その入力と結果を判定の記録のどこに結び付けるかが決まっていること。

公開チェーンに要るのは、後から改ざんがないことを確かめるための最小限の情報です。個人情報や元の観測値そのものは要りません。たとえば、契約を直接特定できない暗号上の値（コミットメント）、報告値のハッシュ、判定規則の版、判断した時刻です。詳しいデータはアクセスを制限したチェーンの外に保管し、保存期間と削除の手続きを決めておきます。

ブロックチェーンを使うべきかを見極める

ブロックチェーンが役に立つのは、たとえば複数の会社が同じ判断を確かめ合う場面です。一社で商品もデータも支払いも管理するなら、合意を取る相手がいません。その場合は、通常のDBと改ざんを検知できるログで足ります。状況ごとの向き不向きは次のとおりです。

効果は「自動化率」では測りません。次のものが良くなるかで判断します。

• 会社どうしの突き合わせの件数と、判断を確かめる時間
• 紛争のときに記録を復元する時間と、二重払いの率
• 例外の状態から回復するまでの時間

ふつうのシステムで、同じ結果をもっと単純に得られるなら、スマートコントラクトは使わない方が合理的です。

PoCでは、誤払いと不払いを止められるかを試す

本番で問題になるのは、ここまで見てきた欠測・訂正・二重払い・資金不足の場面です。正常に支払えるデモでは、こうした場面を一度も通りません。そこで少なくとも次の9つを試します。

• 指標の過去検証：過去の実損と支払曲線を、地域・季節・災害の規模ごとに比べ、負・正のベーシスリスクを測る。
• 閾値ちょうど：閾値の直前・同じ値・直後と、丸めの前後で、約款どおりの結果になる。
• 欠測・食い違い：データ源の停止、古い値、単位違い、外れ値、署名数の不足を、例外として別扱いにできる。
• 重複：同じ報告値と請求を繰り返しても、判断と支払いが1件だけになる。
• 停止・復旧：判断の前、準備金の確保後、送金の受付後に処理を止めても、再起動後に同じ状態へ戻る。
• 鍵の侵害：オラクルの署名鍵か管理者鍵を失効させ、承認のない規則変更・送金・再開を拒める。
• 資金不足：大きな災害で一度に支払条件を満たしても、判断を失わず、支払いの順番待ちと顧客への通知へ移せる。
• 訂正・紛争：公式値の訂正を、過去の記録を上書きせずに処理し、追加払い・返還・据え置きの承認の流れを再現できる。
• プライバシー：チェーンエクスプローラー、ログ、分析基盤から、契約者や対象地点を特定できない。

合格の条件は、正常時の支払時間だけでは足りません。次のものも含めます。

• ベーシスリスクの許せる範囲と、データの遅れの上限
• 例外になる割合、復旧までの時間、説明に必要な記録
• 同時に払う最大額に対して、資金が足りている割合

PoCで自動送金できても、商品設計、顧客保護、資金の準備、運用の復旧が成り立ったことにはなりません。監査で確かめる観点はDeFiサービスのスマートコントラクト監査事例、気象データ基盤の事業性・品質はWeatherXMの分散気象観測ネットワーク分析も参考になります。

よくある質問

パラメトリック保険とは何ですか？

実際の損害額を査定する代わりに、降雨量や震度など契約で決めた指標が条件を満たしたとき、あらかじめ決めた額を払う保険です。査定を待たないので支払いを速くしやすい一方、指標と実損のずれ（ベーシスリスク）が残ります。

実際の損害と支払額が違ったらどうなりますか？

契約どおりに指標が条件を満たしていれば、実損より多くても少なくても、決めた額が払われるのが基本です。ずれを小さくする要は、観測地点・観測期間・支払曲線の設計と、過去データでの検証です。日本の審査事例では、損害申告書の提出や事後調査権を約款に入れて、実損てん補性を補う取り組みも挙げられています。

スマートコントラクトにすれば支払いは完全に自動になりますか？

判定は自動にできても、データの欠け・訂正、支払原資の不足、送金の失敗、異議の申し立ては残ります。これらを例外として別扱いにし、人が承認して復旧できる流れにしておく必要があります。

実装する人向けの詳細

ここからは、保険会社でこの仕組みを実際に作る開発チームの話です。前半の7つの層と支払いの流れを、記録と状態名の形で書き直します。

7つの層で固定する記録

支払いの状態名

前半の8段階は、状態機械（決まった状態を順に移る仕組み）として永続化します。

1. ACTIVE：契約が有効。
2. OBSERVATION_CLOSED：観測窓が終了。
3. REPORT_PENDING：報告値を検証中。
4. TRIGGERED / NOT_TRIGGERED：支払条件の成立／不成立を、報告値のハッシュと判定規則の版に結んで保存。
5. PAYMENT_RESERVED：準備金から支払額を確保。
6. PAID：決済ネットワークの確定IDと時刻を保存。銀行送金ならAPIの受付時ではなく、銀行側の確定結果を照合した時点。
7. EXCEPTION：理由コード付きで隔離。
8. DISPUTED / CORRECTED：元の決定への参照付きで追加し、過去の記録は上書きしない。

TRIGGEREDになった事実は、支払ネットワークが停止しても消しません。PAYMENT_RESERVED以降の障害は支払の待ち行列で復旧します。

二重払いを防ぐ冪等キー

冪等キーは、同じ要求が何度届いても1回分しか処理しないための識別子です。同じ契約・観測窓・判定規則から一意に作ります。

claim_id = hash(policy_id, observation_window, rule_version)

タイムアウト後に別IDを発行して再送しないでください。決済結果を照会し、未実行と確認できた場合だけ同じIDで再試行します。

関連記事

• スマートコントラクト保険の請求紛争｜人による訂正と監査の設計
• DeFi保険とヘッジの設計｜損失原因ごとのリスク移転と限界
• オラクル障害時のフォールバックとサーキットブレーカー設計

XTELAができること

私たちは、商品担当・データ提供者・支払基盤の責任境界を整理し、オラクルとスマートコントラクトの構成、状態機械、権限、監視を設計・開発します。欠測・訂正・鍵侵害・資金不足を再現する障害注入を含めたPoCと、スマートコントラクトの監査も行います。保険商品の法的な判断が必要な点は弁護士と連携して進めます。貴社のパラメトリック商品を実装へ落とす段階で、お問い合わせからご相談ください。

主要参考資料

• NAIC: Parametric Disaster Insurance
• World Bank: Disaster Risk Financing and Insurance Program glossary
• World Bank Policy Research Working Paper: The Role of Index-Based Insurance
• EU-U.S. Insurance Dialogue Project: Climate Risk and Resilience
• 金融庁: 保険商品審査事例集（令和8年1月）
• 金融庁: 保険商品審査事例集（令和7年5月）
• Chainlink: Data Feeds architecture
• OpenZeppelin Contracts: Access Control

資料の確認日と注意

一次資料は2026年9月24日に確認しました（審査事例集の最新版もこの日に確認）。その時点の公開情報にもとづく、一般的な技術設計の解説です。保険・法務・会計・投資の助言ではありません。制度と必要な手続きは、法域と個別の仕組みによって違います。