保険商品の「Web募集」に対応するため、社内SaaSを開発
浪山氏は「Miracraw」を含む、損害保険ジャパンで保険のWeb募集プロジェクトをリードするチーフエンジニアだ。浪山氏はまず、「保険のWeb募集」とは何か説明した。
「紙と対面が主流だった保険の契約手続きをWebで完結させるものです。Webサイトで自分に合うプランを選び、お客様情報を入力し、確認画面で入力内容を確認します。最後に支払いをして契約完了といった流れになります」（浪山氏）
従来の紙や対面での契約手続きだけでは、デジタルネイティブな若い世代の顧客が獲得しにくい。そのため、保険会社としてはできるだけWeb募集化を進めたいという方針がある。
しかし、そういった意向とは裏腹にWeb募集化は「なかなか進まなかった」と浪山氏。
というのも、保険の販売方式は1000種類以上あるため、一つひとつスクラッチ開発するのは採算が合わない。既存のSaaSの活用も検討し、一部は導入している。一方で、当社の業務に合わない部分やコストの高さから、SaaSだけですべてをまかなうことはできなかった。
そこで、Web募集のSaaSを社内で開発しようという結論に至り、Miracrawの開発がスタートした。保険の加入フローは、基本的にどの商品でも同じ。「プランを選択し、情報を入力し、入力内容や保険料を確認して決済に進む」という基本の流れを押さえれば、多岐にわたる販売方式をWeb募集化できると考えたのだ。
信頼も知識も予算もない。できたての開発チームは何から始めたか
Web募集のSaaSを内製化することを決めたものの、開発チームは立ち上がったばかりで実績も信頼もない。メンバーは浪山氏自身を含めて異業種からの転職組で、保険のドメイン知識も乏しかった。実績がなければ予算も下りない。まさにゼロからの開発スタートだった。
「こんなチームに会社が予算を下ろしてくれるわけもなく、SaaSを作りたいと言っても投じるお金がない。そこで、社内での信頼獲得のために『小さい案件の開発』から着手しました」（浪山氏）
具体的には、SaaSをいきなり開発するのではなく、まずは単一のWeb募集のサイト作成を請け負った。いくつものWeb募集サイトを構築するにはコストと工数がかかるものの、実装自体は難しくない。社内での信頼を得ながら、開発メンバーがドメイン知識やノウハウを蓄積するのには最適だった。
さらに、Web募集サイト構築の過程で、SaaS開発に使えそうなパーツを抽出した。単一のサイト構築を繰り返す中で、共通化できそうな部品を見つけて蓄積していったのだ。「最初は案件をこなしながら信頼を獲得し、ノウハウやパーツをブラッシュアップ。ある程度ノウハウやパーツが揃った段階でSaaS化に取り掛かる」という作戦だ。
いくつもの案件で実績を重ねるうちに社内からの信頼を得て、案件の依頼も増加していった。リソースが限られた状況下でも、SaaS開発の準備と組織内での信頼構築を効率的に両立させることができた。
「Schemaドリブン」で量産体制へ。バックエンドは一度捨てて作り直した
浪山氏の開発チームは、案件ごとにWeb募集サイトを構築しながら、SaaS化に使えそうなパーツを抽出していった。そこで抽出して共通化した「Schemaファイル」を元に「Schemaドリブン方式」で開発することで、より多くの案件を高速にさばけるようになっていった。
Schemaドリブン方式では、共通のSchemaファイルによってデータやAPIの構造を最初に定義し、それに従ってフロントエンドやバックエンド、DBスキーマを実装する。一度Schemaファイルを作成すれば、次の案件では少しの書き換えで構築できるため、金太郎あめのようにWebサイトを量産できるアプローチだ。
浪山氏らはまず、フロントエンドをJSON Schemaを元に構築し、バックエンドとDBスキーマはPrisma Schemaを元に構築した。Prismaは、スキーマをベースにDDLを記述してDBへの反映やコード生成を自動化できるNode.js向けのORMで、Prisma Schemaはその定義ファイルにあたる。
フロントエンドには、JSON Schemaを元に申し込みフォームのUI画面を構築できる「React JSON Schema Form」（RJSF）というライブラリを採用し、独自に改良。案件を重ねるごとにコーディングが必要な箇所が減っていき、現在はほぼすべての画面がJSON Schemaのみで作れるようになった。
バックエンドとDBスキーマについては、当初Prisma Schemaを基にDBとAPIを自動実装しようと考えた。Prisma Schemaを1つ作れば、テーブルもエンドポイントも自動で生成される仕組みだ。APIにはREST APIではなく、Prismaと相性のよいGraphQLを選んだ。
ところが、このアプローチは案件ごとの構築には向いているものの、SaaS化には適さないことがわかった。というのも、個別の案件用のコードを生成してしまうと、SaaSの基盤に載せられないためだ。SaaS化では、1つの基盤に案件ごとのスキーマを追加していく形になる。加えてGraphQLも、データストアのようなシステムには適するが、保険のWeb募集には過剰だった。
そのため、SaaS化にあたってはPrismaを廃止して、コード生成という発想自体を捨てた。
SaaS基盤は、「安定性の高い堅牢なシステムにする必要があった」と浪山氏は振り返る。そこで、バックエンドの言語をNodeから、後方互換が安定しているJavaへ変更した。Nodeではライブラリのバージョンアップで後方互換が壊れることが多かったためだ。あわせて、契約情報はJSON形式で管理するスキーマレス方式に刷新した。
具体的には、案件ごとのバリデーションチェックを通った内容を、そのままJSON形式でDBに格納する仕組みだ。案件ごとに異なる項目が来てもDBのカラムを増やす必要がなく、そのまま保管できるメリットがある。バリデーションはSchema Validatorで定義しており、一部Schemaドリブンを残した形だ。
ただし、JSONのまま格納するとアプリの処理では扱いにくい。そこで、処理で使う一部の項目のみ、他の列から計算した値を仮想カラムに自動展開する「Computed Column」で展開している。補償開始日や保険料といった特別な意味を持つ項目を、JSONカラムから自動的に抜き出してアプリから使えるようにする仕組みである。
その他、アーキテクチャをモノリスからマイクロサービスへ、実行環境をCloud RunからGKEへ、DBをPostgreSQLからSpannerへと変更し、安定したSaaS基盤を目指した。
生成AIが追い風に──加速するMiracraw開発
こうしてWeb募集のSaaS基盤としてMiracrawが動き出すと、より多くの案件の構築が求められるようになった。
Schemaドリブンで効率化されているとはいえ、開発者が案件一つひとつの販売方式を理解し、JSONファイルを書くのは骨の折れる作業だ。カスタマイズを増やすたびにJSON項目が増え、ドキュメントの整理も追いつかない。ここで大きな助けになったのが生成AIの導入だ。
「Schemaドリブン開発と生成AIは相性がよい」と浪山氏は言い、「案件ごとのカスタマイズ項目の理解が追い付かない問題も、生成AIにナレッジを渡せば一瞬で作成され、解決されました」と説明する。
生成AI×Schemaドリブン開発には、他にもメリットがある。まず、リーダブルコードの観点でのレビューが不要になる。エラーハンドリングやログ、コードの書き方といった観点でのレビューは、書いているのがJSON Schemaである以上「汚く書きようがない」ため発生しない。また、JSONファイルは別ファイルを参照できないため、AIによるコード生成の落とし穴である「意図しないデグレ」が起きず、修正のたびにデグレを確認する手間もかからない。
Miracrawを基盤に、Schemaドリブン開発を行うことでどのような成果を得られたのか。浪山氏は、以下のように現在の開発フローを説明する。
「私たちの開発では、要件を記載したドキュメントをClaude CodeのAgent Skillsに渡し、フロントエンドのJSON SchemaとバックエンドのSchema Validation、その他の設定が自動で生成されます。この一回のフローで、およそ8〜9割の品質に到達します」（浪山氏）
最初の案件では7人のチームが半年以上かけて開発していたところ、現在はエンジニア1人が1か月かからずに開発できる。浪山氏は「Agent Skillsのブラッシュアップや共通機能の追加によりスピードを上げることができるのでは」と語り、さらなる開発スピードの加速に意気込みを見せた。
大量生産を支える運用も、AIとテストの整備でまわしている。アラートの1次調査はAIがすべて実施し、そのレポートを基に「顧客に影響があるか」「アプリを直す必要があるか」を人が判断する。E2EテストとAPIテストを整備したことで、月1回リリースできる体制になった。プルリクエストを投げると1万以上のAPIテストが走り、パスしたものだけがマージできる。運用負荷が高くなりがちなマイクロサービスを、少人数で回せているのはこうした整備の成果だ。
なお、Miracrawは2025年11月にリリースされ、講演の1か月前となる6月16日に本格展開が始まっている。損害保険ジャパンの発表によると、パートナー企業が展開するオンラインサービスに保険を組み込む「エンベデッド・インシュアランス」の共通基盤として提供されており、社内SaaSとして生まれたMiracrawは社外へと広がりつつある。名称はMiracle（奇跡）とRaw stone（原石）を組み合わせた造語だ。
最後に浪山氏は、Miracrawの開発を振り返り、以下のようにセッションを締めくくった。
「当初はゼロからのスタートでしたが、試行錯誤を重ね、一つひとつ着実に積み上げてきたことで、社内SaaSを構築することができました。チームとして実績を重ねるうちに、社内の各部署から『自分たちの案件も任せられないか』と声がかかるようになり、世の中に必要とされていることを日々実感しながら開発できています。Miracrawはまだ進化の途上にあり、今後もさらに加速していきます」（浪山氏）
損保ジャパンからのお知らせ
Sompo Digital Labでは、保険・介護・ヘルスケアなど、SOMPOグループの幅広い事業領域を対象に、デジタル技術を活用したサービス開発に取り組んでいます。
社会課題に近い現場を、AIとソフトウェアで変えていく。そんな開発に興味があるエンジニアを募集しています。
