Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AI Agentの精度改善に見るML開発との共通点 / commonalities in ac...

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for shimacos shimacos
January 27, 2026

AI Agentの精度改善に見るML開発との共通点 / commonalities in accuracy improvements in agentic era

「ML/DSバックグラウンドだからこそ面白い。AIエージェントをプロダクトに実装する、泥臭い裏側と挑戦」での登壇資料です。
https://layerx.connpass.com/event/379705/

LLMの登場により、機械学習エンジニアの仕事は「賢いモデルを作る」ことから「モデルを賢く使う」ことに変化しつつあります。両者は一見全く違うスキルが必要になるように見えますが、実は従来の機械学習エンジニアとしての経験や勘所が活きる場面がたくさんあります。本発表では、発表者のAgent開発の実体験に基づき、従来の経験が武器になる領域と、逆に考え方やスキルの拡張が必要となる領域についてAI Agentの精度改善プロセスを元に話しました。

Avatar for shimacos

shimacos

January 27, 2026
Tweet

More Decks by shimacos

Other Decks in Research

Transcript

  1. © LayerX Inc. 2 バクラク事業部 AI-OCRグループ Tech Lead/ 機械学習エンジニア 経歴

    • 2019/04 京都⼤学⼤学院 ⼯学研究科 修⼠課程修了 • 新卒では、事業会社でタクシー配⾞アプリに関する機械学 習システムの構築や、ライブストリーミングサービスにお ける推薦システム構築に携わる • 現在 ◦ 株式会社LayerX AI-OCRグループ Tech Lead ◦ バクラク事業部において、AI-OCRの改善や 新規機械学習システムの構築を担当。 現在はAgent系の新規機能開発に携わる。 ◦ Kaggle Competitions Grandmaster ⾃⼰紹介 島越 直⼈(Naoto Shimakoshi) @nt_4o54
  2. 5 © LayerX Inc. 機械学習エンジニアの役割 機械学習エンジニアの役割の変化 ⼀部のリソースを所有している企業や(まだ)LLMが得意でないドメインの会社を除いて LLM APIを⽤いたシステム開発は直近避けられない 従来の機械学習エンジニア

    これからの機械学習エンジニア 賢いモデルを作る モデルを賢く使う • 少数のモデルを学習させて運⽤ • 学習させたいコンテキストを定義し て、内部パラメータを学習 • ラベル定義、アノテーション 再学習パイプライン整備 etc • 複数のモデルやAPI、ロジックを運⽤ • 適応させたいコンテキストに合わせて 外部パラメータを適応 • モデルのOrchestration、全体設計 プロンプト管理 etc
  3. © LayerX Inc.  9 「バクラク」の事業領域 Coming Soon AIエージェント HCM領域 (人的資本管理)

    稟議・ワークフロー 領域 BSM / ARM領域 (債務・債権管理) Payment 領域 Coming Soon (※)2025年11⽉時点
  4. © LayerX Inc. 11 請求書の明細から表を抽出し、LLMによって仕訳を過去の修正データやマスタデータから補完する 表抽出 + ⼈⼿のチェック + LLM

    + ルールベースでの名寄せによる仕訳の補完のワークフローを構築 AI明細仕訳 Agent機能の事例
  5. 13 © LayerX Inc. Feature EngineeringとContext Engineering Context EngineeringはFeature Engineeringそのもの

    どちらもモデルの気持ちになって「コンテキスト」を理解させるという点では変わらない Feature Engineering (パーソナライズドAI-OCR) Context Engineering (AI明細仕訳) ⽬的 コンテキストを理解できるように 識別モデルが理解できる形で 特徴量を作成して⼊⼒する コンテキストを理解できるように ⽣成モデルが理解できる形で ⾃然⾔語‧システムを組み⽴てて⼊⼒する 具体例 過去にユーザがその取引先で 発⾏⽇を使った回数に加⼯して⼊⼒ 過去に同じ明細に対して どのような仕訳を切っていたかを Markdown形式で⼊⼒ 従来の機械学習エンジニアの仮説構築⼒、検証⼒、分析⼒が武器になる部分
  6. © LayerX Inc. 14 AIシステムを⼀つのブラックボックスと考えた時に改善を回すサイクルは変わらない 評価と改善のプロセスは不変 評価フローの違い • 特徴量の追加 •

    コンテキスト収集⽅法の修正 • 論⽂などで⼿法の探索 • 評価指標設計 • 仮説構築 • 過学習検知 • モデルの気持ちになる • まずE2Eで動くものを最速で作成 • データセット作成
  7. 16 © LayerX Inc. タスク分解の共通点 例1: パーソナライズドAI-OCR ⾊々な役割を持たせないように学習しやすい形でモデルを分離する 汎⽤的なモデルに対応 パーソナライズモデルに対応

    プロダクトやお客様毎の ドメインに依存せず 書類だけを⾒て判断できるような 項⽬抽出に特化させて学習 プロダクトやお客様毎の ドメインに合わせて 項⽬抽出した値を 並び替えることに特化させて学習 過去事例から特徴量を作成
  8. 17 © LayerX Inc. タスク分解の共通点 例2: AI明細仕訳 汎⽤的な部分とお客様毎に変わる部分に分けてチューニングを⾏う System Prompt

    {{ few_shot_example}} {{ specific_insight}} 汎⽤的なモデルに対応 パーソナライズモデルに対応 ドメインエキスパートに聞きながら 「⼀般的に」どのようなことを考えながら 仕訳を切っているかを 仮説を⽴てながら⾔語化して⼊⼒ 細かく仕訳を切りたいのか ある程度粗く仕訳を切りたいのかなど お客様毎に変わる部分を 吸収できるように過去事例を⼊⼒ 過去事例からの インサイトを抽出してから⼊⼒ 特徴量エンジニアリングと同じ
  9. 19 © LayerX Inc. データセット作成における違い LLM APIは検証においても時間と⾦銭コストがかかる 従来の検証サイクル • ⼤規模なデータ(~1M)で

    オフラインで定量評価 • オフラインで 精度が担保できたらデプロイ • オンラインでのモニタリング Agentの検証サイクル • ⼩規模なデータ(~1k)で オフライン評価 • AIによる評価で評価にも不確実性 • 検証速度重視で早期に 体験を含めて設計することが重要 • 検証データの質が重要 ⼩規模なデータセットでしか検証できないからこそ、機械学習エンジニアのデータセット構築⼒は重要
  10. 21 © LayerX Inc. システム開発における違い Software Engineering能⼒やPdM能⼒の重要性が⾼まる できることが増えている分、Contextの収集やタスク分解を⾏っていくと システムとしての設計難易度が従来より格段に上がる Model

    Selection 複数の特化モデルの使い分け 従来の識別モデルの利⽤ ルールベースロジックの利⽤ RAG & Tools 検索APIなどのツールや DBなどとの接続設計 Human-in-the-Loopの設計 Data Infrastructure 検証⽤に再現性を担保するログ設計 フィードバックループを 回すためのDB設計 機械学習スキルが必要
  11. 23 © LayerX Inc. まとめ 従来の経験を活かしつつ積極的に新しい領域に⾶び込んでいく Unlearning • 従来の評価プロセスに囚われすぎずに、体験を含めてまず作ることが重要 •

    LLMは思ったよりなんでもできる、斜に構えずにまずは動かす Relearning • 精度改善の考え⽅のフレームワークは従来と同じで、Howが異なるだけ ◦ むしろできることが広がって、従来じゃ実現できないようなモデルの適応も可能になる • 従来の機械学習エンジニアとしてのメタ的なスキルや引き出しを活かして ⾼精度なAgentを実現するためにSoftware EngineeringやPdMの領域へ染み出していく!