Google Cloud 公式ブログが2026年7月に公開した、損害保険ジャパンとSOMPOホールディングスの事例を取り上げる。AIエージェントに機械学習モデルの改良プロセスを任せた取り組みだが、私がこの記事で重要だと思ったのは削減された工数ではなく、担当者が「AIにはまだできない」と名指しした部分のほうである。
要点 (出典の事実)
- 損害保険ジャパンは、社員向けツール「おしそんLLM」の回答品質を上げるため、検索用の機械学習モデルを改良するプロセスを自動化した。従来この改良は属人化していた。
- 仕組みは3つの構成要素からなる。ML実行基盤、探索的データ分析を自動化する「EDA Agent」、そしてコーディングエージェントである「実験オーケストレータ」。
- Gemini、Agent Development Kit (ADK)、BigQuery / BigQuery ML などを組み合わせて構築している。EDA Agent はデータ件数の偏り(自動車保険が多く火災保険が少ない等)やノイズを自動検査し、BigQuery ML で小規模モデルを試して前処理の効果と処理コストを事前に見積もる。
- 実験サイクルは1週間から1日に短縮された。SOMPOホールディングスのキム ヘン氏は「以前は1回の実験サイクルに3日以上かかっていたが、いまは1日のうちに何度も試せる」と述べている。
- 損害保険ジャパンの眞方篤史氏は、コーディングエージェントに全部やらせることもできるが「なぜこのデータ分析をしたのかというログが残らない。だから分けている」として、EDA Agent と実験オーケストレータを意図的に分離したと説明している。
- 同氏は「ビジネス上の課題を機械学習のタスクに落とし込んで、そのためにデータセットを加工する。ここが一番大変で、まだAIにはできないところなんです」とも述べている。
「一番大変なところ」が自動化の外に残った
AIで開発は確かに速くなった。この事例でも実験サイクルは1週間から1日になっている。だがその上で眞方氏が「一番大変」と呼んだのは、ビジネス課題を機械学習のタスクに翻訳し、そのためのデータセットを設計する工程だった。ここは自動化されていない。
私はこれが偶然の線引きだとは思わない。自動化できたのは、目的が確定した後の反復である。どの特徴量を試すか、どの前処理が効くか、どのモデルが精度を出すか。これらは評価関数さえ決まれば探索問題になり、探索はエージェントが得意とする領域だ。一方で「何を評価関数にするか」は、業務の側にしか答えがない。おしそんLLMの回答品質とは何か、どういう検索結果が現場にとって正しいのか。この定義を外注できる相手はいない。
受託開発とAIエージェント事業をやっている立場から言えば、いま多くの現場で詰まっているのは、まさにこの手前の工程だ。実装が遅いから進まないのではない。「業務のどこにシステムを差し込むのか」「何をもって良しとするのか」が決まっていないまま、実装だけが速くなっている。この構造は「使われないシステム」が生まれる要件定義の失敗と地続きであり、AIによって解消されるどころか、実装が速くなったぶん相対的に目立つようになった。
ログが残らない自動化を避けた判断
もう1つ実務的に重要なのは、コーディングエージェント1本に統合せず、EDA Agent を分離したという設計判断である。理由は性能ではなく「なぜその分析をしたのかというログが残らない」から、という説明だった。
これは運用を知っている人間の判断だと思う。エージェントに一気通貫でやらせると、結果は出るが根拠が残らない。精度が落ちたときに、モデルの問題なのか、データの偏りなのか、前処理の判断ミスなのかを切り分けられなくなる。自動化の目的が「速く回すこと」なら統合したほうが速いが、目的が「改良を継続できる状態を作ること」なら、意思決定の痕跡が残る形に分割するほうが正しい。属人化を解消するための自動化が、エージェントという新しいブラックボックスに置き換わるだけでは意味がない。
自社で同じものを作るとしたら、難所はエージェントの実装ではなく、EDA Agent が読める形でデータが整っていることと、実験結果を蓄積して比較できる基盤のほうだ。BigQuery に業務データが載っていて、BigQuery ML で小規模検証まで回せる、という前提条件がこの事例を成立させている。この土台の話はAIはERPと業務基盤なしには機能しないで書いたことと同じ構造である。
中堅・中小企業が持ち帰れる順番
規模も予算もそのまま真似できる事例ではない。それでも順番は再現できる。
- 反復している試行錯誤を1つ特定する。 毎回同じ手順で条件を変えて試している作業があれば、そこが自動化の候補になる。逆に、毎回考えることが違う作業は候補ではない。
- その反復の「良し悪しの判定基準」を人間の言葉で書けるか確認する。 書けないなら、自動化ではなく定義の作業が先である。
- 判定に必要なデータが、いま継続的に取れているかを棚卸しする。 取れていないなら計装が先。
- 自動化するときは、結果だけでなく判断の根拠が残る単位に分ける。
順番を飛ばして4から入ると、動くデモはできるが運用に乗らない。逆に1と2さえ固まっていれば、使うモデルやツールは後から差し替えが効く。眞方氏自身が「今のやり方も、半年後には陳腐化している可能性が全然ある」と述べている通りで、寿命が長いのはツール選定ではなく、業務の側の定義のほうだ。
自社の業務のどこからAIを差し込むべきかを整理する段階で詰まっている場合は、開発のご相談からお問い合わせいただければ、要件定義の手前の切り分けからご一緒します。
出典: 損保ジャパン、AI エージェントで機械学習モデルの開発を自動化 (Google Cloud 公式ブログ, 2026-07)
