AIエージェントは、データ活用・AI開発をどう変えるのか

生成AIエージェントの登場により、これまで専門人材の手作業に依存していたデータ分析やモデル検証の工程が、自動化されつつあります。本講演では、探索的な分析から前処理の効果検証、学習データの生成までをエージェントに任せ、人は要所の承認だけを担う（Human-In-the-Loop）で実際の事例をもとに自動化がどの程度実現性があるのかを紹介します。専門人材の不足を補い、分析から検証までのリードタイム短縮と試行回数の増加、属人化の解消といったビジネス上の効果と、それでも「人の判断を挟むべき」理由・自動化が現実的に効く範囲・プロジェクトで押さえるべき勘所（コスト・品質・スコープ管理）を共有します。

Transcript

1. AIエージェントは、 データ活用・AI開発を どう変えるのか？ 眞方 篤史｜チーフエンジニア・損害保険ジャパン株式会社
2. 01 導入 自己紹介 眞方 篤史 役職・所属 損害保険ジャパン株式会社 チーフエンジニア 担当領域 内製開発における リードエンジニア業務 MLOps・LLMOps推進 AIエージェント開発 ｜ 導入 2
3. 01 導入 本日の構成 AI開発は6つの工程でできている。工程ごとに、自動化できることとできないことは全く異なる。 01 導入 ソフトウェア開発の自動化の状況 02 全体像 AI開発の工程と、最近の自動化トレンド 03 プロジェクト例 AI開発の工程をどう自動化しているか 04 何が自動化できないのか 実例から見る、人がレビューすべきポイント 05 これからのAIプロジェクト 成功条件・良いMLタスク・AIエンジニアの 役割 06 サマリ AIプロジェクトの成功条件のまとめ ｜ 導入 3
4. 01 導入 ／ ソフトウェア開発を先行指標として見る コーディングエージェントの使われ方が変わった 補完から自律実行へ。実行はAIに、レビューは人に。 一度に自律実行で きる長さ 数分 → 数時間 一回の指示で完了する範囲が拡 大（2025後半） Anthropicレポートの事例 7時間 大規模ライブラリへの実装を1 回の実行で完了／精度99.9% 開発作業でAIを使う割 合 約60% “完全委任”は0〜20%。レ ビューは人が担う ｜ 出典: Anthropic「2026 Agentic Coding Trends Report」 4
5. 01 導入 生産コードへのAI貢献は多くのデータで実績あり Googleでは新規コードの30%超をAIが生成（2025年4月・CEO発言）。 生産コードのAI支援率 41～ 42% 新規コードのAI生成率（Google） 30%超 ｜ 出典: Sonar "State of Code 2025" / Google（Alphabet 2025 Q1 決算） 5
6. 01 導入 一方で「速くなれない」ことを示すデータも 熟練者がAIで 19%遅くなった という検証結果も存在する。 AIへの信頼はむしろ低下 AIが生成したコードをそのまま信頼する開発者の割合は低下。確認・検証のコストは残る。（Sonar 2025） 熟練者が −19% の生産性 慣れたコードベースを持つ熟練エンジニアが、AIを使うことで生産性が低下。自分より賢くないAIの出力を 検証するコストが上回った。 AI生成コードの脆弱性は 2.74倍 同一機能を実装した場合、AI生成コードの脆弱性含有率は人間が書いたものの約2.74倍。レビューなしの 本番投入はリスクが高い。 ｜ 出典: METR RCT (arXiv:2507.09089) / Sonar 2025 / Veracode 2025 GenAI Code Security Report 6
7. 01 導入 ソフトウェア開発はAI開発の「先行指標」か？ 似ている部分も、本質的に異なる部分もある。 共通点 ✓ 実装はAIに任せられる 実験用のコード生成も、コーディン グエージェントが担える ✓ 検証コストは残る AI出力を無批判に使う人は減少傾向。 人のレビューは外せない ✓ 速くなる・遅くなる人が共存 適用領域・熟練度によって効果が 大きく変わる AI開発固有の難しさ ! 評価指標の設計が難しい バグは実行時に明確に出る。しかし モデルの「良さ」は曖昧 ! データ品質は見えづらい データの汚れはエラーにならない ! 問題定義が曖昧なことが多い 「解きたい課題」は決まっていても 「どんな予測問題に落とすか」は 決まっていない ｜ 導入 7
8. 02 S E C T I O N AIエンジニアリングの全体像
9. 02 AIエンジニアリングの全体像 AI開発の6工程 現時点では工数の重心は データ・評価系にある。 1 ビジネス理解・ タスク設計 技術調査を含む 30% › 2 データ作成 収集・合成 20% › 3 可視化・分析 傾向の把握 15% › 4 データ加工 特徴量生成 5% › 5 モデリング 学習 10% › 6 評価 定量・定性 20% ｜ 6工程の枠組み: DS Agent Survey (arXiv:2510.04023) ／ %は一般的な目安 9
10. 02 AIエンジニアリングの全体像 ／ 工程① タスク設計 ① ビジネス理解・タスク設計 → 何をAIに解かせるか決める ｜ 工程① タスク設計 10 ① タスク設計 › ② データ作成 › ③ 分析 › ④ データ加工 › ⑤ モデリング › ⑥ 評価 この工程でやること ・現場の課題を整理し、AIで解ける予測・分類の形に 翻訳する ・何を入力し何を予測するか、成功の定義を決める 具体例：照会内容の分類タスク ・「照会対応を効率化したい」 →「照会文を保険種別に自動分類する」 成功＝正しく分類でき、担当者の振り分けが自動化
11. 02 AIエンジニアリングの全体像 ／ 工程② データ作成 ② データ作成 → 学ばせる材料を集める・作る ｜ 工程② データ作成 11 ① タスク設計 › ② データ作成 › ③ 分析 › ④ データ加工 › ⑤ モデリング › ⑥ 評価 この工程でやること ・社内DB・ログ・文書から学習データを集める ・足りなければ合成データやラベル付与で補う 具体例：照会内容の分類タスク ・過去の照会文を抽出・集計する ・照会文に対して正解の保険種別ラベルを付与する （アノテーション）
12. 02 AIエンジニアリングの全体像 ／ 工程③ EDA・可視化 ③ 可視化・分析 → データの健康診断・傾向把握 ｜ 工程③ EDA・可視化 12 ① タスク設計 › ② データ作成 › ③ 分析 › ④ データ加工 › ⑤ モデリング › ⑥ 評価 この工程でやること ・分布・欠損・偏り・外れ値・リークを確認し、 データの素性を掴む ・後工程のリスクを早めに洗い出す 具体例：照会内容の分類タスク ・クラス不均衡（約12倍）を発見 ・正解に近い情報が学習データに紛れている可能性や、 同じ照会の重複に気づく
13. 02 AIエンジニアリングの全体像 ／ 工程④ データ加工 ④ データ加工 → AIが使いやすい形に整える ｜ 工程④ データ加工 13 ① タスク設計 › ② データ作成 › ③ 分析 › ④ データ加工 › ⑤ モデリング › ⑥ 評価 この工程でやること ・ノイズ除去・表記統一・特徴量づくりを行う ・モデルが学びやすい形にデータを整える 具体例：照会内容の分類タスク ・定型句やIDの除去、表記揺れの統一 ・長すぎる文の切り詰めで重要情報に集中させる
14. 02 AIエンジニアリングの全体像 ／ 工程⑤ モデリング ⑤ モデリング → 予測・判断モデルを作る ｜ 工程⑤ モデリング 14 ① タスク設計 › ② データ作成 › ③ 分析 › ④ データ加工 › ⑤ モデリング › ⑥ 評価 この工程でやること ・複数の前処理・特徴量・モデルを試し、予測モデルを 作る ・試行回数を増やすほど精度を上げやすい 具体例：照会内容の分類タスク ・まずはシンプルな基準モデルを作る ・改善案を多数試して最良のモデルを選ぶ
15. 02 AIエンジニアリングの全体像 ／ 工程⑥ 評価 ⑥ 評価 → 本当に使えるか判定する ｜ 工程⑥ 評価 15 ① タスク設計 › ② データ作成 › ③ 分析 › ④ データ加工 › ⑤ モデリング › ⑥ 評価 この工程でやること ・指標で性能を測り、ビジネスで使えるかを判定する ・最終的な採用可否を人が承認する 具体例：照会内容の分類タスク ・多数派だけでなく、少数派の分類も含めて性能を 確認する ・少数派クラスの精度や誤りの中身まで確認する
16. 02 AIエンジニアリングの全体像 ／ 自動化トレンド 「実行・探索」はすでに幅広く自動化され始めている 特定のツールの話ではない。すべての工程で自動化の実例が登場している。 ① 技術調査 文献調査から仮説・実験・レポート 作成までを自律実行する研究事例も 出ている。 ③④ 傾向分析・加工 「このデータで〇〇を予測したい」 の一言で、分析から予測モデル構築 まで自動実行。 ⑤ モデル構築 機械学習コンペ相当の課題。 到達度はこの1年で急上昇（詳細は 次ページ）。 ② データ生成 LLMが合成データを生成。品質で従 来手法を上回る事例が確立されてき た。 ② ラベリング LLMが一次ラベリングを担うハイブ リッド運用が実用化。コスト・速度 で大幅改善。最終品質は人が担保。 ⑥ 評価・採点 AIの出力を別のAIが自動採点（LLM- as-Judge）。定性分析のコーディン グ作業も代替可能に。 ｜ AIエンジニアリングの全体像 16
17. 02 AIエンジニアリングの全体像 ／ モデリングの自動化 モデリングの自動化は加速度的に進む MLE-bench の指標（メダル獲得率）では、約1.5年で 16.9% → 50%超 に。 16.9% 2024.10 AIエージェント＋ 自動化ツール 34.1% 同左・8回試行 （最良を採用） 35.1% 2025 別のAIエージェン ト 50%超 2026 最新のAIエージェ ント（複数手法） 約1年で 16.9% → 50% 試行回数を増やせること 自体が競争力になって きている。 出典: MLE-bench (OpenAI, arXiv:2410.07095) ／ R&D-Agent (arXiv:2505.14738) ／ ML-ACE(ML-Master 2.0) 17
18. 03 S E C T I O N プロジェクト例
19. 03 プロジェクト例 人は「設計と承認」を担い、AIは「実行と探索」を担う 自動化＝人員削減ではない。人が見る場所が変わる。 人が握る（設計・判断） AIで自動化（実行・探索） 1 タスク設計 成功の定義は人。 技術調査はAI。 › 2 人・AI データ作成 収集・合成を実行。 品質は人が承認。 › 3 AI 可視化・分析 分析レポートを 自動生成。 › 4 AI データ加工 複数の加工・改善 案を自動で試す。 › 5 AI モデリング 試行回数を 一気に増やす。 › 6 評価 評価設計は人。 定量実行はAI。 ◆ レビューは人が実施：① 方針レビュー → ②/④ データ品質 → ⑥ 最終評価 19 人・AI 人・AI 人・AI ｜ プロジェクト例
20. 03 プロジェクト例 実例：6工程を、人と2つのエージェントで動かす ｜ プロジェクト例 20 タスク設計と最終判断は人。下流の②～⑤を、2つのエージェントが担う。 人が握る（設計・判断） エージェントが実行（探索・実験） 工程 ① 人：タスク設計 「このタスク・このデータで AIの開発を行いたい。 まず分析して」と依頼 工程 ②・③ 分析エージェント データ理解・品質チェック・ 傾向分析 → 分析レポートを出力 工程 ④・⑤ 実験計画エージェント レポートを基に実験計画 → 前処理・学習を実行 工程 ⑥ 人：評価・方向づけ 精度など結果を見て、採否と 次の方向性を決める → 依頼 → レポート → 結果 ◆ 人が結果（精度など）をレビューし、採否と“次の方向性”を決める → それが次のループの依頼になる
21. 03 プロジェクト例 分析自動化の例：データ理解から改善仮説まで ユーザの指示を受けて、エージェントがデータを読み・品質を確認し・改善仮説を出す。 ｜ プロジェクト例 21 入力 「このデータで予測モデルを作る前に、データの問題点と改善案を整理して」 プロファイル結果（自動抽出） ▸ 行数 / 列数：46,924行 × 4列 ▸ 予測対象：保険種別の15分類 ▸ クラス不均衡：最頻 21.4% ⇄ 最低 1.8%（約12倍） ▸ 注意点：正解に近い情報が学習データに混ざる可能性 ▸ 注意点：同じ照会が複数行に重複している可能性 エージェントの出力結果
22. 03 プロジェクト例 分析自動化の例：データ理解から改善仮説まで ユーザの指示を受けて、エージェントがデータを読み・品質を確認し・改善仮説を出す。 ｜ プロジェクト例 22 入力 「このデータで予測モデルを作る前に、データの問題点と改善案を整理して」 タスク判定と改善仮説 ▸ タスク種別：テキスト多クラス分類（15クラス） ▸ ベースライン：文字n-gram + ロジスティック回帰 ▸ 仮説1：定型句・IDなどノイズ除去で macro-F1 改善 ▸ 仮説2：クラス重み付けで少数派クラスの Recall 向上 ▸ 仮説3：長文クエリの切り詰めで重要情報に集中 ▸ 仮説4：リーク源（answer列など）の確実な除去 エージェントの出力結果
23. 03 プロジェクト例 実験自動化の例：精度を探索し、計画を立てて実行する ①の依頼を受け、②〜⑤を回して 最も良い精度を探索（左）。立てた計画と、その結果を残す（右）。 ｜ プロジェクト例 23 効果 ②～⑤をエージェントが自動実行 → これまで1実験に数日かかっていたものが数時間に。多くの実験を回せるようになった。
24. 04 S E C T I O N 何が自動化できないのか
25. 04 何が自動化できないのか ／ 実例から見えたこと 試して分かった：AIの得意・苦手 実行・探索は速い。前提の問い直しは人が担う。 ｜ 何が自動化できないのか 25 AIが得意（速くなった） ・膨大なデータを高速に確認する ・欠損・外れ値・分布の偏りを機械的に検出 （＝怪しい箇所の洗い出し） ・データリーク候補を見つける ・表記揺れ・ノイズを見つける ・改善仮説を大量に出す ・複数の前処理・特徴量・モデルを試す ・実験結果をレポート化する AIが苦手（人がレビューすべき） ・そもそものMLタスク設定が間違っていないか ・評価指標がビジネス価値と一致しているか ・評価データ自体が間違っていないか ・ラベルの定義は妥当か ・改善フィードバックが溜まる業務になっているか
26. 04 何が自動化できないのか ／ どこをAIに任せられるか 3段階で見る、AIと人の役割分担 実例を踏まえると、任せられる作業と人が握る判断が見えてくる。 AIに任せやすい ・データの確認 ・傾向の分析 ・加工・改善案の探索 ・実験の実行 AIが支援できる ・タスク設計のたたき台 ・モデリング ・評価の実行 人が握る ・成功の定義 ・評価指標の妥当性 ・データ品質の承認 ・最終判断 ｜ 何が自動化できないのか 26
27. 04 何が自動化できないのか ／ 現実は自分で設計する ベンチマークと現実の違い：現実に「お膳立て」はない 現実のAI開発には、その「お膳立て」がそもそも存在しない。 MLE-benchの「お膳立て」 Kaggle相当の競技。すべてが所与の条件。 ✓ 課題が与えられている ✓ データが与えられている ✓ 評価指標が与えられている 全てが揃った状態で 50% → 現実のAI開発 この3つはすべて、自分で設計する必要がある。 ✕ 課題は自分で定義する ✕ データは自分で調達・設計する ✕ 評価指標は自分で設計する 設計＝人に残る仕事 ｜ 出典: MLE-bench (OpenAI, arXiv:2410.07095) 27
28. 04 何が自動化できないのか ／ ① タスク設計 AIは「指示通り」に動く。「何を指示するか」は人が決める 問いの設定が間違えば、AIが正確に動くほど悪くなる。 指標の最大化 ≠ ビジネス目標の達成 「問い合わせ件数を減らす」だけを目標にすると、必要 な問い合わせまで抑制してしまう 件数は減っても、必要な対応まで止め、ビジネス目標を損なう。 AIは「与えられた指標」を最大化する。その指標がビジネス 目標を正しく表しているかは、人が設計する必要がある。 人が担う：問いの設計 1 ビジネス課題を「AIが解ける形」に正しく変 換する 2 「この結果が出たら成功」を事前に定義する 3 指標が現場の実態を正しく反映しているか検 証する ｜ 何が自動化できないのか 28
29. 04 何が自動化できないのか ／ ② データ品質 データの問題は、エラーにならない AIが“異常”は検出できても、“現実とのズレ”はエラーにならず、人が判断する。 コードのバグ バグが混入 → 実行エラーが発生 エラーログで問題箇所を特定できる 気づきやすい ─ 検知・修正が可能 データの問題 ラベル誤りや現実とズレたデータが紛れ込む 学習・予測は正常に動く。エラーは出ない 気づきにくい ─ 誤った結論を出し続ける 学習データが現場の実態を正しく反映しているか。 その判断は人が担う必要がある。 ｜ 何が自動化できないのか 29
30. 05 S E C T I O N これからのAIプロジェクトは こう変わる
31. 05 これからのAIプロジェクト ／ 成功条件 成功条件はこう変わる 「モデルを作る力」 から 「設計する力」 へ。 ｜ これからのAIプロジェクト 31 従来の成功条件 ・精度の高いモデルを作れるか ・実装できるか ・実験をたくさん回せるか ・どのツール・モデルを使うか これからの成功条件 ・良いビジネス課題を選べるか ・AIが解けるタスクに落とし込めるか ・評価指標を正しく設計できるか ・改善フィードバックが継続的に溜まるか
32. 05 これからのAIプロジェクト ／ 設計すべき4点 自動化が進むほど「設計」の質が成否を分ける 実行はAIに任せられる。「何を解くか・何で測るか・何で学ばせるか・どう改善し続けるか」は人に 残る。 1 タスク設計 「何を解くか」 ビジネス課題をAIが解ける問 いに変換する。 2 評価設計 「何で測るか」 指標がビジネス価値と一致し ているか。落とし穴を見抜く。 3 データ設計 「何で学ばせるか」 学習データの品質・代表性を 担保する。 4 改善フィードバック設計 「どう改善し続けるか」 結果と学びが溜まる仕組みを 設計する。 ｜ これからのAIプロジェクト 32
33. 05 これからのAIプロジェクト ／ 良いMLタスク 良いMLタスク：「育つように設計」できるかどうか 高精度なモデルづくりより、良いタスク・評価・データ・改善ループが回るビジネスプロセスを設計できるか。 ｜ これからのAIプロジェクト 33 01 予測・判断の「後のアクション」が決まっている スコアを出して終わりにせず、「誰が何を変えるか」まで業務に組み込む。 02 結果が観測でき、改善フィードバックが自然に溜まる 成功／失敗・採用／修正が、特別な作業なしに業務の中に残る。 03 前提の問い直しは、人が担う AIは探索・実験（局所最適）に強い。タスク・評価・データ・ループの妥 当性は人が見る。 フィードバックループが回る業務設計 業務で使う 結果・判断が残る 学習データになる モデルが改善 ↻ 育つ
34. 05 これからのAIプロジェクト ／ 良いMLタスク（実例） 実例①：コーディングエージェント 当初は小さな修正だけ。今は大規模改修まで任せられるように"段階"が上がった。 ｜ これからのAIプロジェクト 34 何が起きたか 当初 簡単なコードのみ。大規模改修は人手。 ↓（1〜2年） 現在 大規模な改修まで任せられる実用域へ。 なぜ伸びた？ ・正誤がテストですぐ・自動で分かる ・だから試行錯誤を高速でくり返せる 任せられるタスクの"段階"が上がった 小さな 修正 機能の 実装 複数ファイル の改修 大規模 改修 当初 現在 正誤がすぐ分かる → 高速で回せるループ AIがコードを書く テストで正誤を自動判定 ↺ 誤りは即わかる → すぐ直して、高速で何度もくり返す 正誤を自動で即判定 → 高速でくり返せる → 小さな修正から大規模改修まで任せられるように
35. 05 これからのAIプロジェクト ／ 良いMLタスク（実例） 実例②：RAGエージェント（自社） ユーザーの「回答への評価」が、そのまま検索モデルの学習データになる設計。 ｜ これからのAIプロジェクト 35 やったこと・設計のポイント ・ユーザーの5段階評価を学習データに変える ・高評価（3以上）＝「検索が的確」とみなし 正例として学習に使う ・低評価は検索／生成どちらの失敗か 切り分けられず、学習からは除外 ・仮説を先に立て、後から実験できる形で取得 結果 acc@5 67.5% → 82.0%（+14.5pt） ユーザー評価が学習データになる仕組み ① ユーザーが質問する ② RAGエージェントが関連文書を検索 → 回答生成 ③ ユーザーが回答を5段階で評価 評価 3以上 検索は的確 → データとして使う 評価 2以下 原因を特定できず → 使わない ↻ 共通項は「検証しやすさ」と「学びが自然に溜まる業務設計」。タスクの良し悪しは最初の精度ではなく、この2点で決まる。
36. 05 これからのAIプロジェクト ／ AIエンジニアの役割 AIエンジニアの役割はこう変わる 実装者から、設計者・判断者・レビュアー へ。 ｜ これからのAIプロジェクト 36 01 ビジネス課題をMLタスクに翻訳する 解くべき問いを定義し、AIが解ける形に落とし込む。 02 KPIと評価指標のズレを見抜く 指標を最大化してもビジネスが良くならない罠を防ぐ。 03 AIが出した実験結果・改善案をレビューする リーク・ノイズ・ラベル品質・前提の妥当性を確認する。
37. 06 S E C T I O N サマリ
38. 06 サマリ ／ Biz側の視点 ビジネス・企画側がAIプロジェクトを見る軸も変わる 「設計に投資する」を、ビジネス側の3つの判断に翻訳する。 スコープ 大元のタスク設計がズレていな いか AIは与えられた範囲を最適化す るだけ。タスク設計のズレに、 人が定期的に立ち返る。 評価・承認 指標の妥当性と承認ゲートを 工程に組み込む AIが指標を最適化する前提で、 指標の妥当性とデータ品質の承 認ゲートを置く。 投資先 モデルより、データと設計に お金を置く 高品質なデータの作成・蓄積に コストを配分する。プロジェク トの成否はここで決まる。 ｜ サマリ 38 ¥
39. 06 まとめ 「何を解くか・何で測るか・何で学ばせるか・どう改善し続ける か」を設計できるチームが、次のAI活用で差をつける 1 実行・探索・実験の自動化は、加速度的に進んでいる 2 タスク設計・評価設計・データ設計・改善ループは人が握る 3 自動化で浮いたリソースを「データ・設計」に充てる組織が、次のAI活用で差をつける 39