わずか8分。
insureMOのAPIに対してAIコーディングを用い、動作する保険アプリケーションを構築するのに要した時間はそれだけでした。モックアップでもなければ、ワイヤーフレームでもありません。フロントエンドからビジネスロジックまで、完全にAIが構築した動作するアプリケーションです。
これこそ、機械のために設計されたAPIレイヤーに対してAIがコーディングしたときに起こることです。そして、すべての保険会社が「APIを持っていること」と「AI対応のAPIを持っていること」の違いを理解しなければならない理由でもあります。
AIは2つの形で保険を変えています。1つ目は、エージェント型エンジニアリング（agentic engineering）です。AIが保険アプリケーションを構築します。かつてチームで数ヶ月かかっていたことが、今は数日、場合によっては数分で済みます。2つ目は、エージェント型オペレーション（agentic operations）です。AIエージェントが保険プロセスを自律的に実行し、クレーム対応、ポリシーの保守、新規契約の処理を行い、真に判断が必要な場合にのみ人間にエスカレーションします。
どちらも根底で必要とするものは同じです。AIが実際に扱えるAPIレイヤーです。
ほとんどの保険会社にはそれがありません。APIを持っていないからではありません。彼らが持っているものが、機械のために設計されていないからです。
キッチンの問題
食材にラベルが貼られておらず、ナイフは電源コードと絡まり、香辛料は3つの部屋に散乱し、コンロは専門家でないと点火できない専用燃料で動くようなキッチンに、ロボットシェフを置いてみてください。
ロボットには卓越した能力があります。しかし、何も見つけられず、何も読めず、機器を操作することもできません。
次に、同じロボットを整然としたキッチンに置いてみてください。ラベル付きの食材。標準化された機器。使いやすいツール。ロボットはすぐに調理を始めます。
同じロボット。同じ食材。結果は劇的に異なります。
これこそ、今まさにAIと保険APIの間で起きていることです。AIコーディングツールやAIエージェントが典型的なコアシステムを扱おうとすると、3つの問題が起こります。
1つ目 — 独自言語
多くのコアプラットフォームは、独自のドメイン固有言語やカスタム設定フォーマットを使用しています。AIモデルは、数十億行のPython、JavaScript、Java、標準的なRESTパターンで学習されています。単一ベンダーのエコシステム内にしか存在しない言語では学習されていません。これらに対するコードの記述を求められると、AIは拒否しません。ハルシネーションを起こします。構文的には正しく見えるコードを生成し、実行時に失敗します。
2つ目 — 本当のAPIレイヤーの不在
レガシーコアシステムにはAPIがあるかもしれませんが、首尾一貫したAPIレイヤーはありません。1つのエンドポイントが、見積もり作成、保険料計算、適格性チェック、ドキュメント生成を1回の呼び出しで処理するかもしれません。数十のパラメータがあり、そのほとんどは文書化されていません。人間の開発者なら最終的に理解できるでしょう。しかしAIエージェントにはできません。それぞれの操作が独立し、自己完結し、個別に呼び出し可能であることを必要とします。
3つ目 — 暗黙知（トライバルナレッジ）
ほとんどのコアシステムのAPIは、仕様書ではなく人々の頭の中に存在する組織の文脈を前提としています。「code_47」や「flag_R」のようなフィールド名。設定ファイルに組み込まれたビジネスルール。すでにシステムを知っている場合にのみ機能する暗黙の順序。AIエージェントには組織の記憶がありません。知識が仕様書にないなら、それは存在しないのと同じです。
その結果、業界で最もコストのかかる錯覚が生まれます。中身に保険がない、見栄えの良いフロントエンドです。AIは美しいコードを生成しますが、それは実際には保険取引を行えません。
そして問題は良くならず、悪化します。業界がAI生成コードの品質を管理するためにガードレールを急いで追加する一方で、根本原因はAIではありません。その下にあるアーキテクチャです。
ガードレールはつぎ当てにすぎません。答えはアーキテクチャです。insureMOはそのアーキテクチャを構築しました。
insureMOはこれをどう解決したか
insureMOは根本的に異なるアプローチをとりました。既存のプラットフォームにAI機能を追加するのではなく、AIが運用するために最初から設計されたAPIアーキテクチャを構築したのです。
このアーキテクチャには、連携する2つの層があります。
この2層設計こそ、他社がそうでない中でinsureMOのAPIエコシステムがAIフレンドリーである理由です。
他社が「AIが生成するコードが多すぎる」という課題に苦しみ、ガードレールの追加に時間を費やす中、insureMOはアーキテクチャとシステムのレベルからこの問題を解決しました。iComposerのAPIコードは極めてクリーンで最小限です。AI生成のUIコードは、影響を与えることなく書き直せる小さな、状況に応じたページになります。アトミックAPIは安定しており、変更されることはありません。アーキテクチャそのものがガードレールなのです。
insureMOはまた、ネイティブのMCPサーバー（AIエージェントがツールを発見し操作するために使用するプロトコル）を提供します。insureMOのMCPサーバーは、単にAPIを公開するだけではありません。3層のメカニズムでそれらを制御します。使用できるのは登録されたMCPサーバーのみです。各サーバーから選択されたツールのみが利用可能になります。そしてエージェントを構築する際には、登録されたプールの中から特定のツールのみがそのエージェントに付与されます。これにより、実行時に膨大なセットの中からどのツールを使うべきかをAIが判断する必要がなくなり、ハルシネーション、トークンの無駄、精度の低下を防ぎます。汎用クラウドプラットフォームはこのために脆弱なロール権限設定を使用します。insureMOのアプローチは、ポリシーによるコンプライアンスではなく、設計によるコンプライアンス（compliance by design）です。
実際の運用イメージ
AIコーディングツールに、旅行保険商品の見積もりから締結までのフロー（quote-to-bind）の構築を依頼したとします。
典型的なコアシステムに対しては、AIエージェントがエンドポイントを探します。そして、見積もり、締結、発行、エンドースメントを1回の呼び出しにまとめた商品管理APIを見つけます。数十のパラメータがあり、そのほとんどは文書化されていません。プラットフォームで何年も作業した人にしか意味の通じない内部コード。エージェントは推測します。もっともらしいペイロードを生成します。実行時に失敗します。フィールドの依存関係が仕様書にありませんでした。順序のステップが飛ばされました。設定フラグが不足していました。開発者は、AIが20分で書いたコードのデバッグに2日を費やします。
insureMOに対しては、AIエージェントは個々のアトミックエンドポイント、すなわち商品検索、適格性、保険料計算、見積もり作成、締結を発見します。それぞれが1つのことだけを行います。それぞれに完全なOpenAPI仕様があります。標準的なREST。明確なレスポンス。あるいは、iComposerを通じて構成され、裏側で全シーケンスをオーケストレーションする単一のビジネスAPIを呼び出します。見積もりから締結までのフローは、最初の実行で動作します。
AIが賢いからではありません。キッチンが整然としていたからです。
だからこそ、8分でのアプリケーション構築が可能だったのです。AIはシステムを説明する人間を必要としませんでした。insureMOのAPIを発見し、それぞれが何をするかを理解し、それらをワークフローに組み合わせ、完全なアプリケーションを構築しました。わずか8分。レガシーコアシステムに対する同じタスクなら、チームで数週間かかり、しかもAI生成コードはまだ失敗するでしょう。
ビジョンは明確です。既存のコアシステムは、下部の記録系（system of record）として残ります。insureMOは中間に位置し、API、データ、AIのプラットフォームとして機能します。その上で、AIコーディングされたアプリケーションとAIエージェントは、コアに対して直接ではなく、insureMOのAPIレイヤーに対して動作します。
大規模な変革を計画したくなるのが自然な衝動です。それに抗ってください。insureMOのアプローチは、迅速な成果と多くの反復に焦点を当てています。
01 insureMOを既存のコアに接続
コアは残りますが、ビジネスロジックが少しずつinsureMOに移動するにつれて、徐々に記録系（SOR）へと縮小していきます。insureMOは既存のコアに接続します。ビッグバン移行はありません。
02 初期商品の抽出
insureMOのデジタル保険商品ライブラリ（DIPL）とAIを使用して、既存のコアから商品データをinsureMOに抽出します。商品を再構築するのではありません。機能しているものを、AI対応の環境へと持ち上げるのです。
03 ビジネスAPIの構築
iComposerとAIを使用して、最初のユースケースに必要なビジネスAPIを構成します。アトミックAPIはすでにそこにあります。iComposerがそれらをワークフローに組み立てます。
04 AIコーディングでアプリケーションを構築
insureMOのAPIレイヤーに対してAIコーディングツールを使用し、ユースケースが必要とするフロントエンドやエージェント体験を開発します。APIがAI対応しているため、コードは動作します。ハルシネーションはありません。中身に保険のない見栄えの良いフロントエンドもありません。
05 ローンチと反復
目に見える、測定可能な成果に焦点を当てます。ローンチする。学ぶ。次の商品、次のチャネル、次の市場へと反復します。
コアは引き続き記録系として機能します。それがデフォルトです。後から技術的または商業的な理由でその一部を置き換える場合、insureMOは独自の永続層を備え、完全なコアシステムを支えることができます。しかしそれは、すでに成果を出した後に下す決定です。前提条件ではありません。
おわりに
insureMOは、保険業界向けの唯一のAI対応APIプラットフォームです。
数千のアトミックAPI。クリーンで最小限なビジネスAPI構成を可能にするiComposer。設計によるコンプライアンスを備えたネイティブMCPサーバー。50以上の国にまたがる500以上の顧客。250億ドル以上の正味保険料（GWP）。1日12億回のAPI呼び出し。
もはや問われるべきは、AIが保険を変革するかどうかではありません。あなたのAPIレイヤーがそれを許容する準備ができているかどうかです。insureMOのAPIレイヤーは準備ができています。
初出：insureMO Medium。
