openinsurance-wiki

openinsurance-wiki

ある国の保険市場を支える頭脳です。 自立した、オープンソースの、国を問わず利用できるフレームワークです。各国の公開保険文書を、あらゆるAIエージェントが読み取れる、相互につながり、出典が明記された豊富なナレッジベースに変換します。

公開サイト：sluyasu.github.io/OpenInsurance - このリポジトリ内のすべてのページを、インストール不要で閲覧・検索できます。

チャットボットでも、ブラックボックスのRAGでもありません。透明性が高く、再現可能なナレッジグラフです。リポジトリには一連の処理がすべて含まれており、保険会社が公開している普通保険約款のPDFを見つけてダウンロードし、それぞれのPDFの内容を可能な限り忠実に保ったMarkdownページに変換し、出典を記載します。さらに、商品、保険会社、保険種目、規制、概念を相互リンクし、たどれるグラフにまとめます。

私たちの知る限り、これは保険商品を対象とする唯一のオープンソースで、機械可読かつ出典が明記されたデータベースです（最も近いものは商用かつ非公開です）。どの国でも利用できます。分類体系はコードではなくデータであり、国の追加方法は手順書（_meta/BOOTSTRAP-COUNTRY.md）に記載されています。

データセットはベルギー、フランス、ルクセンブルク、スイスの4か国を対象とし、合計で39社の保険会社と1,189の商品ページ（自動車、住宅、健康、賠償責任、旅行、弁護士費用など）を収録しています。各ページには出典文書が記載されています。

国	保険会社	商品ページ	保険種目ページ	状況
ベルギー（be）	24	269	17	参照国：入力済みのすべての保険種目について保険種目ページ、3つの規制ページ、国別用語集を手作業で作成した唯一の完全なレイヤー
フランス（fr）	10	714	24	収録数は最多。市場全体の網羅にはまだほど遠い
ルクセンブルク（lu）	4	194	15	国内の主要な保険会社を取り込み済み
スイス（ch）	1	12	0	最初の垂直スライスにすぎません

この手順はまずベルギーで実証され、その後さらに3回実行されました。これにより、「国を問わず利用できる」という設計上の主張が、テストによって裏付けられました。最新の件数は、インデックスの実行ごとにデータから再構築される、AGENTS.md の生成済み収録状況表をご覧ください。

---

2 分で使えます — API キーは不要です

データセットはビルド済みの状態でリポジトリに含まれています。4 か国の 1,189 件の商品ページ、保険会社のページ、用語集に加え、それらの元となる構造化 JSON も含まれています。必要なのは、最初から再抽出する場合の LLM キーだけで、利用するだけなら必要ありません。

1. 読む。 sluyasu.github.io/OpenInsurance でオンライン閲覧するか、クローンしたリポジトリを Obsidian の保管庫として開くと、[[wikilinks]] がたどれるグラフになります。 （github.com 自体では [[wikilinks]] はリンクとして表示されません。サイトか保管庫を使うのがおすすめです。）

2. エージェントに接続する（MCP）。 MCP サーバーは API キー不要で、読み取り専用です。

git clone https://github.com/sluyasu/OpenInsurance.git
cd OpenInsurance
python3 -m venv .venv && .venv/bin/pip install "mcp[cli]" pyyaml

その後、Claude Code などの MCP クライアントに登録します。

claude mcp add insurance-wiki -- "$(pwd)/.venv/bin/python" "$(pwd)/mcp/insurance_wiki_mcp.py"

（または、PyPI からリリース済みのサーバーを利用できます。INSURANCE_WIKI_REPO にクローン先を指定して uvx openinsurance-wiki-mcp を実行してください。リポジトリ内の上記サーバーは、コミット済みのデータセットに常に対応しています。）

search、get_product、get_coverage（1 つの質問に関連する情報のみを逐語引用付きで取得）、compare_products、find_overlap（2 つの保険契約を組み合わせた際の重複補償の候補を検索）、verify_claim（ファクトチェック用の逐語的な根拠を取得）、get_branch_overview などを利用できます。詳しくは mcp/README.md をご覧ください。

3. 生データを取得する。 data/<cc>/extracted/ には、ソース文書ごとの構造化 JSON が格納されており、schema/ に照らして検証済みです。data/<cc>/index.json はフラットなインデックスです（cc は be、fr、lu、ch のいずれかです）。 AGENTS.md は生成されたマニフェストで、ノートの種類、件数、各ページの path／source_url／freshness が記載されているため、ファイルを読むエージェントは推測せずに移動できます。

---

MCP サーバーを採用する理由（チャットボット、RAG スタック、REST API ではなく）

目標は、あらゆる AI エージェントが、引用可能なドキュメントから保険に関する質問に回答できるようにすることです。この要件から、採用するアーキテクチャが決まります。

MCP を採用する理由。 Model Context Protocol は、AI アシスタントとデータをつなぐ標準的なソケットです。サーバーは1つだけで、Claude、ChatGPT、Cursor、または独自のエージェントは、カスタム統合を作らず、3行の設定で接続できます。このサーバーはキー不要（アカウント、API キー、利用枠は不要）、読み取り専用で、ホスティングも不要です。データセット自体がリポジトリにあるため、データは git clone とともに取得でき、オフラインでも動作します。Wiki を再抽出したときは、git pull で更新できます。

RAG チャットボットを採用しない理由。 チャットボットは単一のインターフェースですが、ナレッジベースは複数の用途（ブローカーの比較ツール、コンプライアンスチェック、市場マッピングエージェントなど）に対応すべきです。RAG では、ブラックボックスの埋め込みインデックスが追加されます。差分を確認したり、PR でレビューしたり、再現したりできず、検索の誤りも見えません。ここでは、レビューとコミットを経たファイルを対象に、決定的なマッチングで検索します。同じクエリには常に同じドキュメントが返され、すべての回答にはソース PDF とページ番号が含まれます。LLM は本来あるべき場所、つまりクライアント側で、正確な抜粋を基に推論します。

REST API を採用しない理由。 API を使うには、年に数回しか変わらないデータセットのために、サーバーの24時間365日の稼働、稼働率の確保、キー管理、バージョン管理、利用者ごとの専用統合が必要になります。MCP なら、ローカルプロセスを動かすだけで、同じプログラムによるアクセスを実現できます。

4つの段階で動作します。

1. ソース（sources/）：各保険会社の公開 PDF の保存場所を記した、コミット済みの YAML です。
2. 固定された抽出結果（data/）：コミット自体に含まれるプロンプトを使って、各 PDF を構造化 JSON と出典付き Markdown に一度だけ変換します。クエリ時に生成されるものはありません。
3. 決定的な MCP サーバー（mcp/）：これらのファイルを対象とする、読み取り専用の10個のツールです。内部に LLM はなく、ネットワークも状態もありません。同じ入力には、常に同じ出力が返ります。
4. 推論を行うクライアント：その上で動作するエージェント（Claude、ブローカーのチャットボット、スクリプト）が、ツールの返す内容を引用しながら、意味の解釈を行います。

信頼境界は明確です。ステージ4より下はすべて再現可能で、監査できます。ハルシネーションのリスクはクライアント内に限定されます。また、ツールのレスポンスは、クライアントが正確に回答できるように設計されています。具体的には、すべての単一商品向けレスポンスで、回答の根拠と引用の契約を明示し、曖昧な商品名には黙って推測せず候補を列挙して対応を拒否します。また、回答前にドキュメントに照らしてエージェント自身の草案を事実確認できる verify_claim ツールも用意しています。サーバードキュメントのレスポンス規律に関する注記を参照してください。

速度について。 サーバーは各ファイルを一度読み込み、メモリ上で処理します。このデータセットでのウォーム時のレイテンシは、ツールごとに0.01～約3ミリ秒です（計測方法を再現可能な形で記載しています：mcp/README.md）。実際のチャットボットでユーザーが感じる応答時間は、これらのツールではなく、LLM 自体の推論時間です。

これが必要な理由

保険商品は、数十の保険会社のウェブサイトに点在する、情報量の多いPDFに記載されています。ある国の市場に実際にどのような商品が存在するのかを示す、中立的で、機械可読かつ検索しやすいマップはありません。このプロジェクトは、公共の利益に資するものとして、AI エージェントが接続できる形式でそのマップを作成します。

また、標準化が進む市場にも対応しています。EU規則2017/1469では、すべての損害保険商品に標準化された概要（IPID）が定められており、EIOPAは商品比較と乗り換えを積極的に推進しています。また、オープン保険のアジェンダ（OPIN、EUのFIDA提案）は、保険データへの機械可読なアクセスを促しています。このプロジェクトは、その全体像に欠けている公開文書のレイヤーを担います。つまり、商品に実際に何が記載されているかを、オープンに公開します。

他との違いは、次の4点です。

1. 単独で実行可能で再現性があります。 リポジトリをクローンし、自分のLLMキーを追加して、make allを実行するだけです。最初からスクレイピング、ダウンロード、抽出を行います。隠れたデータセットはありません。すべての入力がコミットされ、すべての出力を再生成できます。
2. 抽出過程が透明です。 LLMに送信する正確なプロンプトは、このリポジトリ内のファイル（extraction-agent/）にあり、コードに埋め込まれていません。モデルへの指示内容を正確に確認でき、自分のモデル（Claude、Gemini、GPT、またはローカルモデル）を使って同じ抽出を実行できます。
3. 根拠があり、出典が明記されています。 すべての商品ページから元のPDFをたどることができ、ページ番号も記載されています。引用は生テキストと照合されます。文書に記載されていない情報は、ページにも掲載されません。
4. 対象範囲を限定しています。 ページの対象は、特定の保険商品の契約文書または契約前文書のみで、それ以外は扱いません。保険会社のダウンロードページには、会社定款、ファンドレポート、プロモーション用の特約などが混在していますが、これらは3段階のチェック（ソースに記録されたout_of_scopeマーカー、抽出エージェント自身の判定、CIでのブロッキングチェック）で除外されます。詳しくはCONTRIBUTINGをご覧ください。

---

Wikiの内容

国ごと（例：wiki/<cc>/、wiki/be/）：

フォルダー	内容	作成方法
products/<insurer>/	保険商品ごとに1ページ（約款／IPID）	PDFから自動生成
insurers/	保険会社ごとに1ページ。取扱商品をまとめて掲載	自動生成
branches/	保険種目ごとの概要（商品が存在する種目にはそれぞれページがあり、make validateで不足を一覧表示）	手動作成
regulations/	規制当局と主要法令（FSMA、強制自動車賠償責任保険、自然災害保険など）	手動作成
glossary/	国ごとの用語（ボーナス・マルス、免責金額、Branche 21/23など）	手動作成

自動生成ページと手動作成ページは別々のフォルダーに保存され、競合することはありません。事実を修正するには、抽出データを編集して再ビルドします。自動生成ページを直接編集することはありません。

自動生成レイヤーは4か国すべてにあります。手動作成レイヤーの充実度には差があり、その違いも意図的に隠していません。ベルギーには保険種目、規制、用語集のページがあります。フランスとルクセンブルクには保険種目のページと、それぞれ規制のページが1つあります。スイスにはまだいずれもありません。make validateを実行すると、商品が存在するにもかかわらず概要ページがない保険種目をすべて一覧表示します。すべての国に共通する概念は、wiki/universal-glossary/にあります。

すべてのページは、YAMLフロントマターと[[wikilinks]]を含むObsidian互換のMarkdownです。

---

最初から再現する

LLMキーが必要なのは、抽出ステップのみです。スクレイピングとダウンロードには、無料のツール構成（httpx + Playwright）を使用します。

git clone https://github.com/sluyasu/OpenInsurance.git
cd OpenInsurance
make setup                      # deps + playwright chromium (no paid scraping dependency)
cp .env.example .env            # set LLM_PROVIDER + your API key (any provider)

# Reproduce a slice end-to-end:
make download COUNTRY=be INSURER=<slug>   # fetch the public PDFs
make extract  COUNTRY=be INSURER=<slug>   # PDFs -> rich Markdown + JSON (uses YOUR model)
make build    COUNTRY=be                  # assemble the wiki
make validate COUNTRY=be                  # citation / wikilink / frontmatter gates

# ...or the whole chain:
make all COUNTRY=be

COUNTRYには、sources/にある任意の国を指定できます：be、fr、lu、ch。抽出は途中から再開できます（ソースチェックサムとプロンプトのバージョンをキーに既存の結果をスキップするため、大規模な実行でも安全に停止・再開できます）。

パイプラインの仕組み

sources/be/<insurer>.yml     (committed: where the public PDFs live)
        │  discover.py   crawl listing pages (httpx, Playwright fallback)
        ▼
data/be/pdfs/…               (downloaded; gitignored - regenerable; manifest.json committed)
        │  extract.py    PyMuPDF text  ──►  LLM (extraction-agent/ prompts)  ──►  MD + JSON
        ▼
data/be/extracted/…          (rich Markdown + structured JSON, page-cited)
        │  build_wiki.py
        ▼
wiki/be/…                    (the browsable, agent-readable knowledge base)

beを示していますが、同じ構成がfr/、lu/、ch/にもあり、コードはすべて同じです。

詳細については、CONTRIBUTING.md（国／保険会社／商品を追加する方法）と extraction-agent/（実際のプロンプト）をご覧ください。

プッシュのたびに、CI のゲートがすべて実行されます。Wiki の検証（フロントマター、--strict-linksによるリンク、引用、スキーマおよびスコープ規則に対するデータレイヤー）、pytest スイート、ビルドの冪等性（コミット済みの Wiki を再ビルドしても差分がゼロであること）、およびデプロイのゲートとなるビルド済みサイトのリンク切れチェックです。データセットの鮮度が低下すると、月次ワークフローが Issue を作成します。

---

国を追加する

1. sources/<cc>/_country.yml - 規制当局、言語、支店の分類体系。
2. sources/<cc>/<insurer>.yml - 各保険会社の公開 PDF の保存場所。
3. wiki/<cc>/ - 支店／規制／用語集の概要を手作業で作成します（または、まずスタブとして作成します）。
4. make all COUNTRY=<cc>。

スキーマに国固有のものはありません。分類体系はデータであり、構造ではありません。4 か国（be、fr、lu、ch）は、パイプライン内に国ごとの分岐を設けず、同じコードで処理されます。既知の制限が 1 つあります。商品ページのセクションタイトルは、まだpipeline/render.pyにフランス語でハードコードされているため、フランス語以外の文書を扱う国では、まずタイトルを国の設定に移す必要があります。

---

ライセンスと出典情報

デュアルライセンスです。コード（pipeline/、mcp/、アダプター、スキーマ）はMIT、オリジナルコンテンツ（wiki/、抽出データ、プロンプト、ソース）はCC-BY-4.0の下で提供されます。保険会社の公開文書から引用した短い逐語抜粋は、引き続き各発行元に帰属し、再ライセンスされません。詳細はLICENSE、LICENSE-CONTENT、NOTICEをご覧ください。

商品ページは、保険会社が公開している文書から事実を抽出したもので、各ソース PDF を出典として明記しています。保険会社の公式文書ではなく、抽出ミスが含まれる可能性があります。必ず引用元のsource_urlで内容をご確認ください。このプロジェクトが提供するのは情報であり、個別の保険に関するアドバイスではありません。