人工知能学会全国大会（第40回）にシルバースポンサーとして協賛、研究発表を行いました！
SmartHRのML（機械学習）エンジニアの井上です。 SmartHRは2026年6月8日〜12日に群馬・高崎のGメッセ群馬で開催された「2026年度 人工知能学会全国大会（第40回）（JSAI2026）」にシルバースポンサーとして協賛、および研究発表を1件行いました。 現地組・リモート組を合わせて複数のメンバーが参加し、「うちのプロダクトに使えるのでは？」と大盛り上がりの5日間でした！ 人工知能学会全国大会とは 人工知能学会全国大会は、AI技術に関する国内最大の学会です。 機械学習の基礎・応用研究から産業応用まで幅広い発表が集まり、AIの最新動向を把握できる機会として毎年多くの参加者が集まっています。 今回の第40回大会は40周年にあたる節目の大会で、約5000人の参加者が集まりました！ 人工知能学会全国大会（第40回） 今年の研究トレンドの変化 JSAI2026の全発表タイトルをキーワードで分析し、昨年の傾向と比較したところ、興味深い傾向が見えてきました！ 技術テーマ出現頻度ランキングの変化（JSAI2025→JSAI2026） 発表の出現頻度をもとにランキングをスロープチャートで比較すると、「LLM・基盤モデル」「AIエージェント」「対話・会話AI」の上位3テーマは今年も順位変動がなく、この領域が引き続き学会全体の中心軸であることが確認できました。 一方で最大の急上昇は「生成AI」で、19位から7位へと12ランク上昇、「ロボット・フィジカルAI」も13位から6位へ7ランク浮上しており、フィジカルAIへの関心が学術研究の領域にも着実に波及していることがうかがえます。 最大の急上昇を見せた「生成AI」も、発表の内容は多岐にわたっていました。生成AI自体を技術として扱う研究だけでなく、keep4o を代表とする生成AIをめぐる人間・社会の動きの考察、生成AIを要素技術として活用したシミュレーション研究、プロダクト活用の実践知を共有する発表も増えており、生成AIが「研究する技術」から「社会に埋め込まれた前提」へと変わりつつあることを実感しました。 SmartHRからの発表 SmartHRからは1件の機械学習領域における口頭発表を行いました！ 敵対生成プロンプト同時探索による内省型プロンプト最適化 発表者: 井上 耕太朗 セッション: 4M5-GS-2f-05（6/11 16:30-16:45） LLMアプリケーションのプロンプト最適化に関する研究です。SmartHRでは RAG を活用した AI アシスタントなど様々な LLM アプリケーションを提供していますが、これらをローンチ前から高品質な状態に保つには、プロンプトを事前に検証・改善しておくことが重要です。しかし従来のプロンプト最適化手法の多くは大量のラベル付きデータを前提としており、ローンチ前の段階では活用しにくいという問題がありました。 今回の研究ではこの課題に取り組み、目的タスクを正しく解くプロンプトと、目的タスクを欺くための敵対的な生成プロンプトを同時に育てる手法「Adversarial GEPA」を提案しました。ラベル付きサンプルがわずか4〜8件という少数データの設定においても、既存手法（GEPA）を上回るプロンプト改善を実現しています。 発表をする井上 発表に使用したスライドは Speaker Deck で公開しています。 speakerdeck.com We Are Hiring! SmartHRでは最新技術に明るいメンバーが集まった環境で、革新的なAIプロダクトづくりに取り組んでいます。 ぜひ一度SmartHRのAIチームにご興味をお持ちの方へをご覧いただき、お気軽にお問い合わせください！ tech.smarthr.jp
- 生成AI
- LLM
- 機械学習
JSAI2026（人工知能学会全国大会）にプラチナスポンサーとして協賛しました
こんにちは！Data＆Analysis部の今野です。 キャディは2026年6月8日(月)〜12日(金)にGメッセ群馬で開催されたJSAI2026（人工知能学会全国大会 第40回）にプラチナスポンサーとして協賛させていただきました。この記事では5日間にわたる開催期間中の当社ブースの出展報告や、聴講した技術セッションのレポートをお伝えします。 会場紹介 ブース紹介 聴講したセッションの感想 非構造データからの情報抽出 画像音声メディア処理：視覚言語理解とマルチモーダル生成 終わりに 会場紹介 まずは会場の様子を紹介します！ 場内では複数のセッション・企業展示・ポスター発表が同時並行で実施されていました。企業展示では、多様な業界に跨る159社の企業が、生成AIに限らない幅広い機械学習技術の産業応用に関して紹介をしていました。私も色々なブースを訪れ、エンジニアの皆さんと意見交換をさせていただきました。 場内の案内図 大規模言語モデル等の生成AIとともにフィジカルAIも大きなテーマの一つとなっていて、実際に入口付近ではGMOインターネット株式会社のブースの前でヒューマノイドロボットが来場者を迎えていました。 入口から見た会場の様子 ブース紹介 次にキャディのブースについて紹介します！ ブースでは、主に私たちが提供している「製造業AIデータプラットフォームCADDi」の中で使用されている機械学習技術や現在取り組んでいる研究開発テーマの紹介をしました。また本サービスのデモを通して、実際に製造業の現場の課題解決にどのように貢献しているかを実感してもらえるようにしました。 注力してR&Dを行っているテーマの中でも、設計資産全体を横断して検索するための2D図面と3D CADモデルの埋め込み空間の統合・3D CADデータ内の加工に必要な特徴の認識・製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Benchの3点について紹介させていただきました。 ノベルティとしては、キャディが各所で出展する度に大人気の「データ活用カツ」や製造業をイメージしたマイクロファイバークロスをお配りしました。 図面が文書としての特徴と幾何学的な形状が融合した複雑なデータであることやその中に潜む活用しきれていない情報の価値であったり、テキストや画像と比べるとあまり一般的でない題材の3D CADに対してどのようなアプローチを課題に応じて選択しているかについて関心を持って頂くことができました。 イベント期間中、キャディのブースに立ち寄ってくださった皆さん、本当にありがとうございました！ 聴講したセッションの感想 次に、聴講させていただいたセッションの感想を簡潔にまとめます。 非構造データからの情報抽出 株式会社リクルートの中田さんとSansan株式会社の山内さんがオーガナイザとして実施されたセッションです。 複数ページの請求書 ・医薬品データ・技術マニュアル ・有価証券報告書 など、多種多様な産業の実務に溢れる「非構造データ」から、いかに正確かつ網羅的に情報を抽出するかという共通の課題に対する検証結果が発表されました 。 問題設定及びそれに対して提案された手法は様々ですが、ほとんどの発表においてVLMが手法の中心に据えられていたことが印象的でした。引き続き物体認識やOCRに特化したモデルの有効性は変わらないものの、大規模言語モデルの推論能力を生かした情報の構造化はこの領域において避けては通れないものになっていると感じました。その中で、プロンプトの工夫・画像の前処理・ステップの分割・検索システムの統合など能力を最大限に引き出すための多岐に渡る手法が検証されていました。 図面という非構造化データからの情報抽出は我々の中心にある課題の一つで、日頃の取り組みと密接に関連したセッションであり、これから解析対象のカバレッジを拡張していくに当たり非常に示唆に富んだ内容でした。 https://pub.confit.atlas.jp/ja/event/jsai2026/session/acHLauKQ 画像音声メディア処理：視覚言語理解とマルチモーダル生成 本セッションでは、画像・音声・対話データといったマルチモーダル情報を対象に、人間の認知特性や数理的アプローチを組み合わせて処理のブラックボックスを解き明かし、生成・推論の「制御性と効率性」をいかに向上させるかという共通の課題が議論されました 。 特に印象的だったのは、東京大学の大坂さんによるVLMにおける視覚アクセス境界の存在を実証した研究です 。この研究では、思考のプロセスを言語化させるChain-of-ThoughtプロンプティングをVLMで行う際、モデルが「長く考えること」で視覚的な特徴抽出を拡張しているわけではなく、実際には言語空間内での記号的推論を延長しているに過ぎないという機構を示すものでした。 過去のテックブログでも紹介しているように、図面からより高度な情報の獲得を目指していくに当たり、VLMのメカニズムに起因する視覚情報に基づく推論の限界は我々も課題に感じており、この問題を新たな視点で捉えられる研究内容であるように感じました。 https://pub.confit.atlas.jp/ja/event/jsai2026/session/fQHM84pJ 終わりに 5日間にわたるJSAI2026への協賛・参加を通じて、AIに関するアカデミックな着目点や産業応用における最新の機械学習技術について幅広い知見を得られる貴重な機会となりました。また、会場での多くの交流や専門的なセッションから、VLMの可能性など我々が日々取り組んでいる課題に対してもヒントを得られる非常に有意義な時間でした。 スピーカーの皆さん、参加者の皆さん、運営の皆さん、素晴らしい会をありがとうございました。今後もキャディは技術的な挑戦や現場の課題解決に向けた取り組み、そして研究開発の内容を積極的に発信し、エンジニアコミュニティの発展の一助となれるような貢献を続けていきたいと思っています。 次回、また皆さんとお会いできることを心より楽しみにしています！
- 生成AI
- 機械学習
CA DATA NIGHT #9 〜スポーツの現場を支えるAI・データ活用の最前線〜 開催レポート
こんにちは。サイバーエージェントの佐藤です。 先日開催された CA DATA NIGH ...
- 機械学習
- AWS
- データ分析
2026年6月技術イベント予定
Sansan株式会社では、技術イベントや勉強会の主催・登壇・協賛を行っています。 各イベントの詳細については、以下のリンクからご確認ください。 ※開催状況により、すでに受付を終了している場合がございます。 ※掲載している内容は公開当時の情報です。最新情報は各イベントページをご確認ください。 イベント開催情報 2026/06/17(水) h4 a { color: #1487BD !important; text-decoration: none !important; font-weight: 700; } h4 a:hover { color: #0E5F8F !important; } 食べログ x ANDPAD x Sansan モバイル勉強会 #4 食べログ、アンドパッド、Sansanが共催するMobile勉強会です。 今回のテーマは「OS・アップデート」。OS 標準 API の進化や UX 改善の話から苦労話まで、モバイル開発ならではの知見を共有します。 開催日時：2026/06/17(水)19:00 〜 21:30 開催場所：Sansan株式会社 本社 参加方法：https://andpad.connpass.com/event/395841/ 協賛情報 2026/06/08(月)～06/12(金) h4 a { color: #1487BD !important; text-decoration: none !important; font-weight: 700; } h4 a:hover { color: #0E5F8F !important; } 2026年度 人工知能学会全国大会（第40回）（JSAI2026） 2026年度 人工知能学会全国大会（第40回）（JSAI2026）に、Sansan株式会社はプラチナスポンサーとして協賛します。 また、ポスター発表2件と口頭発表1件を行います。Sansanブースもありますので、ぜひお立ち寄りください。 ■ポスター発表 ① RT-QMC: 順序変換を用いた準モンテカルロサンプリングによるロバストな初期学習データ選択 発表者：田柳 俊和 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-10 ② スキャン文書画像を用いたページ欠落検出手法の検討 発表者：宮本 優一、吉村 皐亮 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-21 ■口頭発表 GITによる複数ページ請求書の文脈を考慮したページ単位画像分類 発表者：ライ シンユ、本田 悠太郎 セッション名：非構造データからの情報抽出（OS-19） セッション会場：F会場（メインホールB） セッション日時：2026年6月9日（火）15:30 ～ 15:45 講演番号：2F5-OS-19a-01 フォローお願いします！ Sansanの公式アカウントでは、最新のイベント情報をいち早くお届けします。 ぜひフォローしてください！ X： @SansanTech connpass：Sansan株式会社
- iOS
- Android
- 機械学習
- 生成AI
勉強会「自社で育てるLLM/VLM/VLA：学習・活用の実践知」 実施報告
Sansan株式会社 技術本部 研究開発部の齋藤です。 2026年3月26日に勉強会「自社で育てるLLM/VLM/VLA：学習・活用の実践知」を、Sansan株式会社、株式会社ABEJA、株式会社松尾研究所の3社共同にて開催しました。 sansan.connpass.com 本ブログでは、勉強会の様子をご紹介します。 本勉強会の背景 本勉強会では、LLM、VLM、VLAなどのモデルを自社でファインチューニングし、活用している方、あるいは予定している方にご登壇いただき、それぞれの取り組み内容や、実践を通じて得られた知見を共有していただきました。 生成AIのAPIを活用する形とは異なり、LLM、VLM、VLAを自社でホストする場合には、さまざまな課題があります。そうした課題に対して各社がどのように向き合い、工夫しているのかを共有することで、日本企業におけるLLM、VLM、VLAの活用に少しでも貢献できればと考えています。 登壇内容 今回はSansan株式会社、株式会社ABEJA、株式会社松尾研究所からそれぞれ1名が次のタイトルにて登壇を行いました。 登壇タイトル 登壇者 VLAモデル間におけるピック＆プレース性能の比較評価 株式会社ABEJA DP開発本部 データサイエンス部 データサイエンス2G ロボティクス・基盤モデル強化T チームリーダー／瀧田浩平 メール検索に特化したエージェントの強化学習 株式会社松尾研究所 共同研究チーム シニアデータサイエンティスト／太田幹 契約書からの情報抽出を行うLLMのスループットを、バッチ処理を用いて最大40%改善した話 Sansan株式会社 研究開発部 シニアリサーチャー／齋藤慎一朗 VLAモデル間におけるピック＆プレース性能の比較評価（株式会社ABEJA DP開発本部 データサイエンス部 データサイエンス2G ロボティクス・基盤モデル強化T チームリーダー／瀧田浩平） LLMやVLMの技術を応用し、自然言語の指示理解やロボットの視覚認知、高度な運動制御を実現するVLA技術について、論文評価だけでは見えにくい実環境での精度や挙動の違いを調査されていました。さらに、ロボットアームの実際の動きを動画を用いて発表されていました。 普段の私の業務では触れることがないVLA技術に関する実体験を聞くことができ、将来性を強く感じました。また、学習したモデルを搭載したロボットアームを勉強会会場に持ってきていただき、場が盛り上がりました。 メール検索に特化したエージェントの強化学習（株式会社松尾研究所 共同研究チーム シニアデータサイエンティスト／太田幹） メール検索に特化したエージェントを自社で強化学習し、フロンティアモデルと同程度の軽量モデルを構築する方法を紹介されていました。またどのような学習ツールを用いたか、どのような試行錯誤を経て実験を進めたかについても語られていました。 詳細は松尾研究所さんの次のブログにて公開されています。 zenn.dev エージェントを自分で学習しようとしたことがなかったため、従来の機械学習モデルの学習方法と、エージェントの学習方法の違いが面白いと思いました。また、今回の検証の条件において、フロンティアモデルよりも精度、速度が上回るエージェントを構築されていたことに驚きました。 契約書からの情報抽出を行うLLMのスループットを、バッチ処理を用いて最大40%改善した話（Sansan株式会社 研究開発部 シニアリサーチャー／齋藤慎一朗） 私からは、ファインチューニングしたLLMをvLLMで運用する際に発生していたタイムアウトエラーを、バッチ処理を活用することで削減した事例を紹介しました。特に、バッチ処理を導入したことでスループットを最大40%改善できた点について共有しました。何を計測し、どのような判断のもとでバッチ処理を採用したかの思考の流れについて詳しく発表しました。 資料は以下です。 speakerdeck.com 懇親会 懇親会では軽食と飲み物を片手に、多くの参加者とお話ししました。特に、APIで運用しているモデルを自社での運用に切り替える際の進め方に困っている方が多かったと感じました。 最後に 本勉強会は定期開催を予定しており、次回は夏頃の開催を企画しております。実施の際には改めて告知します。 また、Sansan技術本部ではカジュアル面談を実施しています。 Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
- 生成AI
- LLM
- 機械学習
OCamlでLightGBMを動かして機械学習してみた
長女と2人ポケパーク、世代を超えて愛されるものを作れるってすごいよね はじめに こんにちは、エムスリー株式会社 業務執行役員 VPoE 兼 基盤チーム チームリーダーの河合(@vaaaaanquish)です。 この記事は「基盤開発チーム ブログリレー3日目」の記事です。 先日、基盤チームで「うちもブログリレーやろう！」と盛り上がりまして、「いいね！私も書こうかな！」と気軽に思っていたのですが、何故か1日目と2日目の記事がOCamlの記事になっており「それをやられたらビッグウェーブに乗るしかないが…？」ということで私もOCamlで機械学習をやりました。 つまり本記事は、気合いと根性のやってみた記事になります。 はじめに LightGBMとは ということで出来ました 技術的に面白いなと思ったところ ctypes-foreign float32/float64問題 メモリ解放問題 char**のマーシャリング 動かしてみる おわりに We are hiring !! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています LightGBMとは LightGBMは、勾配ブースティングというアルゴリズムを実装したフレームワークです。 2016年8月にMicrosoftが公開して以来、汎化性能の高さやライブラリとしての扱いやすさから人気を伸ばし、今尚Kaggleの表形式コンペでは「最も定番のフレームワーク」と言っても差し支えないほど使われています。 github.com 本家の中身はC++で、OpenMPでゴリゴリに並列化しつつメモリ書き込みの競合を避けるためにスレッドローカルなメモリ領域を確保したりと、面白い工夫がいくつも実装されている強いライブラリです。 私はLightGBMのRust版のBindingを作った経験があり、LightGBMにcommitする程度にはC APIを概ね把握しているため、OCamlでもFFIさえ掴めれば出来るはずです*1。 github.com 一方OCamlは初心者。一体、どうなっちゃうのー！？ ということで出来ました 出来ました。 github.com なんとかなったので、実際の挙動はRepositoryを見てもらうとして、ここからは技術的に面白かった部分の話を書いていこうと思います。 技術的に面白いなと思ったところ ctypes-foreign 調べるとOCamlでC関数を呼ぶ方法はいくつか見つかりました。 今回は ctypes-foreign を使いました。 github.com ctypes-foreignは、libffiを利用した動的FFIを扱うライブラリで、OCaml側だけでC関数のバインディングを記述できそうだったので「これなら簡単じゃん…！」という事で進めました。 当然痛い目に遭いました。 具体的にはポインタ周りです。 ctypes-foreignでは、C関数名と型シグネチャを渡す書き方をします。 @-> 演算子で引数の型を連鎖させ、returning で戻り値の型を指定する、以下のようなコードです。 open Ctypes open Foreign let lgbm_dataset_create_from_mat = foreign "LGBM_DatasetCreateFromMat" (ptr void @-> int @-> int32_t @-> int32_t @-> int @-> string @-> ptr void @-> ptr (ptr void) @-> returning int) LightGBMは機械学習のライブラリなので行列演算が主たる操作になります。 つまり、ポインタのポインタのポインタを多く扱うライブラリでして、頭の中で「今＠->＠->＠->＠->だから次は＠->＠->で……つまり今俺は＠->＠->＠->を触っている……？」という、AIもやってくれないパズルをすることになりました。 ctypes-foreignは、書き手にCのスタブコードを書かせないという意味で凄いライブラリで、型レベル DSLや動的libffiの実装は他のFFIバインディングでも使えるなというアイデアが詰まっています。一方普遍的な事実として、プログラミングにおいて初見の簡単さは実際の簡単さに比例しないという当たり前の事を思い出す、そんな令和の春になりました。 もうぶっちゃけほとんどこのパズルに時間使ったので、ここからはオマケと言っても過言ではないです。 float32/float64問題 LightGBMのC APIでは、機械学習において、入力となる行列(特徴量)がfloat32/float64、回答を表す行列(ラベル)がfloat32です。 Rustではf64とf32が別の型として存在するので自然に区別できますが、OCamlのfloatは常に64bitのdoubleです。 ここでctypesのCArrayを活用しています。 (* 特徴量: OCaml float → C double（自然な変換） *) let flat = CArray.make double (nrow * ncol) in Array.iteri (fun i row -> Array.iteri (fun j v -> CArray.set flat (i * ncol + j) v) row ) data; (* ラベル: OCaml float → C float（暗黙の精度切り捨て） *) let c_label = CArray.make float label_len in Array.iteri (fun i v -> CArray.set c_label i v) label; CArray.make doubleとCArray.make float でCの型を指定して、ctypesに適切なメモリレイアウトのバッファを確保させています。 ctypesのランタイム型記述子で作った事で、64bit→32bitの精度切り捨ても自動で行えて、個人的にニヤニヤしたお気に入りの実装です。 メモリ解放問題 C APIで確保したリソースは明示的に解放が必要になるのは当然のことです。 リソース解放においては、OCamlでは Gc.finalise という機能があります。 実装を始めた当初は決定論的に呼ばれるものかという意識をせず「Rustで言う所のDropトレイトみたいなもんかな」という安易な考えで組み込みました。 let from_mat ~data ~label = (* ... C APIでハンドルを取得 ... *) let t = { handle } in Gc.finalise free t; (* GCがtを回収する時にfreeが呼ばれる *) t ここでRustのDropにはない制約としてGc.finalise の「ファイナライザ内での例外処理」に当たりました。 A finalisation function may raise an exception; in this case the exception will interrupt whatever the program was doing when the function was called. 上記の公式ドキュメントの記載によると、ファイナライザは例外を投げると、その例外はGCのタイミングに依存した無関係なアロケーションポイントで再raise されるため、GCが発生した時点で実行中だった無関係なコードが中断されるみたいです。 そのため free関数でC APIの戻り値を無視するような実装になっています。 let free t = ignore (Lightgbm_raw.lgbm_dataset_free t.handle<span cl
- OCaml
- 機械学習
- C言語
AIとデータが『共通言語』で繋がる日：マルチモーダル埋め込みが切り拓く製造業の新たな可能性
はじめに 10年以上前、単語を単なる記号ではなく、意味の近さを「距離」で表現する高次元ベクトルへと数値化する技術「Word2Vec」が登場しました。これが、AIの重要技術の1つである「埋め込み（Embedding）技術」が研究界で大きな注目を集める契機となりました。 その後、この技術は単語から文章、さらには画像へと適用の幅を広げ、AIは次第にそれらの「意味」を理解し始めます。類似する文章や画像を検索する精度は飛躍的に向上しましたが、当時はまだ、文章と画像を同じ尺度（共通のベクトル空間）で扱うことは困難でした。 その壁を打破したのが、2021年にOpenAIが発表した「CLIP」です。CLIPは文章と画像で共通の埋め込みを作成することに成功し、いわば両者の意味を繋ぐ「共通言語」を誕生させました。このマルチモーダル埋め込みの成功を皮切りに、現在は音声や3Dデータなど、あらゆる情報を共通の埋め込み空間で扱う研究が加速しています。 現在、製造業においてもこれらの技術は浸透しつつあります。画像埋め込みを用いた「図面類似検索」や、テキスト埋め込みを応用した「RAG（検索拡張生成）」などがその代表例です。しかし、現状では単一モーダルの活用が主流であり、マルチモーダル埋め込みの真の社会実装はまだ始まったばかりと言えるでしょう。 マルチモーダル埋め込みの研究分野での盛り上がりを鑑みれば、今後この領域が製造現場に社会実装されていくのは間違いありません。本記事では、マルチモーダル埋め込みの概要から最新の研究事例、そして製造業における活用の未来について詳しく解説します。 「埋め込み」とは？ この節では、そもそも「埋め込み」「マルチモーダル埋め込み」とは何かを説明します。 「埋め込み」とは、一言で言えば「現実世界のあらゆる情報を、AIが計算しやすい『多次元空間上の座標（ベクトル）』に変換する技術」のことです。人間が言葉の意味を理解するように、コンピュータに「概念の近さ」を数値として教え込むプロセスだと考えると分かりやすいでしょう。 埋め込みを使うことで、次の3つのことを実現します。 1. 「記号」を「座標」に変える コンピュータは本来、数字しか扱えません。かつて、AIに「リンゴ」という言葉を教える際は、単に「101番」という背番号（ID）を割り振るだけでした。しかし、これでは「リンゴ」と「ナシ」が似ているという意味のつながりを計算できません。 埋め込み技術は、エンコーダーを使い、例えば「リンゴ」を [0.12, -0.54, 0.88, ...] という数百次元の数値の並び（ベクトル）に変換します。この数値は、その対象が持つ「甘み」「赤い」「果物」といった無数の特徴を凝縮した地図上の座標のようなものです。 2. 「近さ」で意味を測る データが座標（ベクトル）になると、データ同士の「距離」を計算できるようになります。 意味が似ているもの： 空間上で近くに配置される（例：「犬」と「猫」） 意味が異なるもの： 空間上で遠くに配置される（例：「犬」と「数学」） 3. 多様なデータを一箇所に集める（マルチモーダル） 最新の埋め込み技術の凄さは、テキストだけでなく、画像、音声、センサーデータまでも同じ空間に並べられる点にあります。 例えば図1のように、「犬が走っている」というテキスト、ゴールデンレトリバーの画像、「ワンワン！」という鳴き声、そして走る犬の動画。これらは入り口こそバラバラですが、それぞれの専用エンコーダーによって「ベクトル（数値の並び）」へと変換されます。 変換されたデータは、多次元の「埋め込み空間」の中に配置されます。この空間の最大の特徴は、「意味が似ているものほど、近くに配置される」という性質です。この例では、データ形式が違っていてもすべて「犬」という同一のコンセプトに関連しているため、AIの頭の中（空間）では同じエリアにギュッと集まります。 これにより、AIはデータ形式の壁を越えて、「これは『犬』という本質的な概念だ」と一貫して捉えることが可能になるのです。 図1 マルチモーダル組み込み 犬の例 埋め込みの歴史 埋め込み技術は、わずか10年余りの間に驚くべき進化を遂げてきました。ここでは、その進化の道筋を象徴する3つのマイルストーンを紹介します。「単語だけ」から始まった技術が、「画像と言葉の融合」を経て、「3Dシーンの丸ごとアライメント」へと到達する物語です。 Word2Vec ── 言葉に「座標」を与えた原点 Mikolov et al., 2013 2013年、Googleの研究チームが発表したWord2Vecは、「言葉の意味を計算できるようにした」という点で、自然言語処理の歴史を塗り替えました。 それまでの限界：One-hotベクトル Word2Vec以前、コンピュータに単語を教える方法は非常に素朴でした。「One-hotベクトル」と呼ばれる方式では、語彙数と同じ長さのベクトルを用意し、該当する単語の位置だけを「1」、残りをすべて「0」にします。 例えば語彙が5万語あれば、「リンゴ」は5万次元のベクトルの中で、たった1箇所だけ「1」が立っている状態です。この方式には2つの致命的な欠陥がありました。 次元の呪い： 語彙が増えるほどベクトルが膨大かつ疎（スカスカ）になり、計算効率が極めて悪い。 意味の不在： 「リンゴ」と「ナシ」のベクトルは完全に直交しており、距離を測っても「近い」とも「遠い」とも言えない。つまり、意味の類似度が一切計算できない。 Word2Vecの発想の転換 Word2Vecは、この問題をシンプルかつ強力なアイデアで解決しました。「ある単語の意味は、その周囲に出現する単語によって決まる」という言語学の仮説（分布仮説）に基づき、大量のテキストから単語の「使われ方のパターン」を学習したのです。 具体的には、ニューラルネットワークに以下の2つのタスクのいずれかを解かせます。 CBOW： 「昨日 ___ を食べた」→ 空欄に入る単語を、周囲の文脈から予測する。 Skip-gram： 「リンゴ」という単語から、その周囲に出現しやすい単語（「食べた」「赤い」「果物」など）を予測する。 このタスクを何億もの文章で繰り返すことで、各単語は数百次元の密なベクトル（分散表現）へと圧縮されます。「リンゴ」と「ナシ」は似た文脈で使われるため、自然と空間上で近くに配置されるのです。 なぜ衝撃的だったのか Word2Vecが世界を驚かせたのは、学習されたベクトルが「意味の足し算・引き算」を可能にしたことです。 「王様」−「男」+「女」＝「女王」 この計算が成立するということは、ベクトル空間の中に「性別」「階層」といった意味の軸が自然に形成されていることを意味します。人間が明示的に教えたわけではなく、AIが大量のテキストから自ら意味構造を発見した ── この事実は、後の埋め込み技術すべての出発点となりました。 CLIP ── 画像と言葉の壁を壊した転換点 Radford et al., 2021 Word2Vecが「単語同士の距離」を測れるようにしたのに対し、2021年にOpenAIが発表したCLIP（Contrastive Language-Image Pre-training）は、さらに大胆な問いに挑みました。「画像と言葉の距離を測ることはできないか？」── CLIPの答えは、驚くほどシンプルでした。 4億枚の「画像＋キャプション」で学ぶ CLIPは、画像用とテキスト用の2つの独立したエンコーダーを備えています。学習に使ったのは、インターネットから収集した4億セットの「画像とキャプションのペア」。この膨大なデータを使い、以下のルールでベクトル空間を鍛え上げます。 正しいペアは近づける： 犬の画像と「走る犬」というキャプション → ベクトルを空間上で近くに配置。 無関係なペアは遠ざける： 犬の画像と「青い車」というキャプション → ベクトルを空間上で引き離す。 これが「対照学習（Contrastive Learning）」です。正解と不正解を対比させながら空間を整えていくことで、画像とテキストが同じ座標系で「意味的に比較可能」になります。 「見たことがないもの」を理解できる CLIPの最も画期的な特徴は、「Zero-shot性能」と呼ばれる能力です。従来の画像認識モデルは、「犬」「猫」「車」などのラベルを事前に教え込む必要がありました。学習していないカテゴリは認識できません。 CLIPは違います。ラベルではなく「言語の概念そのもの」を学習しているため、一度も見たことがない物体でも、テキストで説明すれば識別できます。例えば「三角形の赤い標識」と入力すれば、学習データに含まれていなくても該当する画像を見つけ出せるのです。 この「データ形式を超えた意味の理解」こそ、マルチモーダル埋め込みの幕開けでした。 CrossOver ── 3Dシーンを丸ごと対応づける最前線 Sarkar et al., 2025 (CVPR 2025 Highlight) CLIPが画像とテキストの2つのモダリティを結びつけたのに対し、2025年にコンピュータビジョンの最高峰学会CVPR 2025でハイライト論文に選ばれたCrossOverは、さらに多くのモダリティへと対象を広げました。RGB画像、点群（Point Cloud）、CADメッシュモデル、フロアプラン、テキスト── これら5種類ものデータを1つの共通空間にまとめ上げ、3Dシーン全体をモダリティ横断で対応づける（アライメントする）フレームワークです。 従来手法の限界：「完璧なデータ」がないと動かない これまでの3Dマルチモーダル学習には、大きな制約がありました。「椅子」「テーブル」といったオブジェクト単位で厳密にラベルを付けたアノテーションが必要で、しかも全てのモダリティ（画像・点群・CADなど）が揃っていなければ学習できなかったのです。 しかし現実のAR/VRやロボティクス、建設モニタリングといった現場では、そんな理想的なデータが揃うことはほとんどありません。ある部屋は3Dスキャンデータしかない、別の部屋はCAD図面と写真だけ ── こうした「歯抜け」のデータが当たり前です。 CrossOverの3つの工夫 CrossOverは、3つの工夫でこの「現実の壁」を突破しました。 1つ目は、「シーンまるごと」で対応づけること。従来はオブジェクト1つ1つに丁寧なラベルを貼る必要がありましたが、CrossOverは「部屋全体」「フロア全体」といったシーン単位で異なるモダリティを結びつけます。いわば、家具を1個ずつ辞書登録するのではなく、部屋全体の写真を1枚見せて「ここにあるもの全部まとめて覚えて」と教えるようなイメージです。 2つ目は、データが歯抜けでも学習できること。5種類全てのデータが揃っている必要はありません。「この部屋は点群とテキストしかない」「あの部屋はRGB画像とCADだけ」── そんな不完全なデータでも、手持ちのモダリティだけで埋め込みを計算し、学習に組み込めます。 3つ目は、段階的に賢くなる学習戦略です。各モダリティに専用のエンコーダを用意し、最初は少ないデータの組み合わせから始めて、徐々に複雑な組み合わせへと学習を積み上げていきます。完璧なデータを待たずに、今あるデータから着実に知識を蓄積できるのです。 何ができるようになるのか CrossOverにより、データの形式を飛び越えた3D検索・解析が現実のものになります。 例えば、フロアプラン（間取り図）を検索クエリとして入力すれば、対応する3D点群データが検索結果として返ってくる。逆に、点群データから対応するフロアプランやCADモデルを見つけ出すことも可能です。さらに、明示的に学習していないモダリティの組み合わせ（例：フロアプラン ↔ テキスト）でも検索が機能する「創発的な汎化能力」が確認されています。 これはまさに、製造業や建築業が待ち望んでいた技術です。次の章では、この技術が製造現場でどのように活用されていくのかを具体的に見ていきます。 製造業における活用の未来 ここまで紹介してきたマルチモーダル埋め込み技術は、あくまで「要素技術」です。では、この技術が製造業の現場に入ると何が変わるのか？ ── ここからは、最も実用化が近い「検索」の応用領域を見ていきます。 検索 ── 「探し方」が根本から変わる 製造業には、長年にわたって蓄積された膨大な図面・3Dデータ・仕様書が眠っています。しかし、その多くはファイル名や管理番号といった「メタデータ」でしか検索できません。番号を忘れたら最後、必要なデータにたどり着けない ── そんな経験のある方も多いのではないでしょうか。 マルチモーダル埋め込み技術は、この「探し方」を根本から変えます。データの本質的な「意味（特徴）」がベクトル化されることで、メタデータに頼らない、3つの新しい検索が可能になります。 クロスモーダル検索：形状で図面を探す 「データ形式の壁」を越える検索です。 設計担当者が、過去の類似製品の仕上がりを確認したい場面を想像してください。従来は管理番号を手がかりに過去資料を探し回る必要がありましたが、マルチモーダル埋め込みを使えば、開発中の3D CADデータをそのまま検索クエリとして入力するだけで済みます。AIが埋め込み空間上で「形状的・構造的に近い」過去の製品図面（画像）を瞬時に見つけ出してくれるのです。 管理番号が不明な古い部品でも、形状さえあれば「過去の類似品」を紐付けられる。これだけでも、設計の初期段階で過去の知見を活かしやすくなります。 マルチモーダル検索：「画像＋テキスト」で絞り込む 1つのモダリティでは足りない場面に効く検索です。 例えば、「このフランジ（画像）と同じ形状で、かつ材質がステンレス（テキスト）のもの」を探したいとします。画像だけでは材質まで判別できませんし、テキストだけでは形状の微妙な違いを表現しきれません。 マルチモーダル検索では、画像の「視覚的な特徴ベクトル」とテキストの「仕様的な特徴ベクトル」を掛け合わせることで（ベクトル加算など）、両方の条件を満たすデータをピンポイントで特定できます。材質、硬度、耐熱性── 画像では見えない情報を言葉で補足することで、検索精度が格段に上がるのです。 AIチャット検索：現場の言葉でデータを引き出す 対話型インターフェースを介した検索です。 現場の作業員がタブレットに向かって「先週のライン停止時に、ベアリング付近を撮影した写真を見せて」と話しかける。あるいは「この3Dモデルの、取付穴が5つあるバリエーションをリストアップして」と指示を出す。── ユーザーの発話がテキストベクトルに変換され、データベース内の画像・3Dデータのベクトルと直接照合されることで、こうした自然な対話での検索が実現します。 複雑な検索コマンドを覚える必要はありません。専門知識がなくても「現場の言葉」で必要な技術資産にアクセスできるようになる点が、現場への浸透を考えると最大の強みです。 おわりに 本記事では、埋め込み技術の進化を「単語だけ」のWord2Vecから、「画像と言葉」を結んだCLIP、そして「3Dシーンを丸ごと対応づける」CrossOverへとたどりました。この10年余りで、AIが「意味」を捉える範囲は劇的に広がっています。 製造業にとって、この技術が意味するのは「データの探し方の根本的な変化」です。ファイル名や管理番号に頼っていた検索は、形状やテキストの「意味」で直接つながるようになります。ベテラン設計者の頭の中にしかなかった「あの時似たようなものを作った」という経験知は、埋め込み空間を通じて組織全体で共有できるデジタル資産へと変わります。 現時点では、製造業でのマルチモーダル埋め込みの社会実装はまだ始まったばかりです。しかし、研究の進展を見れば、この技術が現場に届くのは時間の問題でしょう。「形」と「言葉」の境界が消えたとき、製造業のデータ活用は新しいステージに入ります。 仲間を募集しています！ キャディ株式会社では、本記事で紹介したマルチモーダル埋め込み技術をはじめ、AIモデル開発に全力で取り組み、ミッション「モノづくり産業のポテンシャルを解放する」の実現を目指しています。 この記事を読んで「自分ならこう解決する」「この技術、面白そう」と感じたエンジニアの方、ぜひご応募お待ちしております！ 詳細は以下の採用ページからご覧いただけます！ Data & Machine Learning / CADDi Tech Careers
- 機械学習
- 3D
- CAD
やさしい AIF（ドメイン 4）
おなかが痛くてもコーヒーは飲む、近藤恭平です。 前回は基盤モデルを活用したアプリ設計・プロンプトエンジニアリング・ファインチューニングを整理しました。今回は、AI を正しく・安全に使うための責任ある AI（Responsible AI）の考え方と、それを支える AWS サービスを解説します。試験ガイドのドメイン4に対応した内容です。 責任ある AI とは AI システムは「精度が高い」だけでは不十分です。出力が公平か、説明できるか、安全に運用されているか、これらを組織として担保することが求められます。 試験では以下の原則がキーワードとして問われます。 原則 内容 公平性（Fairness） 特…
- AWS
- Amazon SageMaker
- 機械学習
- 生成AI
やさしい AIF（ドメイン 3）
おなかが痛くてもコーヒーは飲む、近藤恭平です。 前回は生成 AI の基礎（FM・LLM・トークン・埋め込み・推論パラメータ）を整理しました。今回は、基盤モデルを実際のアプリケーションに活用するための設計・実装・評価に関する知識を整理します。試験ガイドのドメイン3に対応した内容です。 基盤モデルを使ったアプリ設計の考慮事項 FM の特性：大規模・ブラックボックス 深層学習の過程と学習の結果得られる基盤モデル（FM）には、以下の固有の特徴があります。 特性 内容 大規模なコンピューティング要件 FM のトレーニングには多くの GPU リソースと時間が必要。既存の FM をそのまま利用したり、転移学…
- AWS
- 生成AI
- 機械学習
- Amazon Bedrock
RAGの評価データセットをユーザーと一緒に作って、思った以上に良かった
機械学習エンジニアの竹本です。普段は、製造業の膨大なドキュメントを対象にしたRetrieval-Augmented Generation（RAG）の検証に取り組んでおり、その一環として社内検証向けのベンチマークデータセットを作成しました。同じ課題を抱えるエンジニアの方の参考になればと思い、本記事を書きました。 TL;DR 作りたい。でも動き出せなかった 当時の思い込みと、今の自分からの答え合わせ 1. LLM-as-a-Judgeに頼るしかないと思っていた 当時の状況 データセットを作ってみると 2. データセットを作れるのか？ そしてCSやユーザーに頼っていいのか？ 当時の状況 CSに相談してみると 3. 時間も工数もかかるのに、そこまでしてやる価値があるのか 当時の状況 データセットを作ったら検証速度が5倍に向上 作る過程で得られた想定外の価値 まとめ TL;DR 最初は、コストや体制の壁があり作成に動き出せなかった 制約を取っ払って考え、「作りたい」と声に出したら、動き出せた ベンチマークデータセットを作って、検証スピードが約5倍になった 作る過程そのものも、ユーザー理解を深めるきっかけになった 作りたい。でも動き出せなかった RAGの検証を進める中で、製造業の深いドメイン知識や個社特有の知識が求められる領域では、LLMによる評価だけでは精度を正しく判断しきれないと感じるようになりました。評価用のベンチマークデータセットが必要だと分かっていたものの、作成にかかる時間的コストの大きさと、自チームやアノテーションチームだけでは作りきれないという課題から、なかなか動き出せずにいました。 転機となったのは、チーム全員で実施した「100本ノック」でした。3日間で一人100個ずつアイデアをスプレッドシートに書き出し、不確実性やコストといった制約をいったんすべて取り払って、「本当は何をすべきか」を純粋に考え抜く取り組みです。その中で、「ドメインエキスパートと一緒にデータセットを作りたい」と提案しました。議論してみると、LLM-as-a-Judgeだけでは正しく評価しきれないという課題感と、データセットがあれば検証の質とスピードが大きく変わるという期待は、チーム内のエンジニアやPdMにも共通のものでした。コストやタイムラインといった制約がある中で、優先度が上がりきっていなかっただけでした。制約を外して考えたことでその必要性が共通の課題として顕在化し、チームとして取り組む合意が得られ、データセット作成が動き出しました。 そして実際に作成してみると、想定以上の価値がありました。 ここからは、当時抱えていた以下3つの思い込みを1つずつ答え合わせをしていきます。 LLM-as-a-Judgeに頼るしかないと思っていた データセットを作れるのか？ そしてカスタマーサクセス（CS）やユーザーに頼っていいのか？ 時間も工数もかかるのに、そこまでしてやる価値があるのか 当時の思い込みと、今の自分からの答え合わせ 1. LLM-as-a-Judgeに頼るしかないと思っていた 当時の状況 当時は、プロンプトチューニングや評価基準の調整を行い、LLM-as-a-Judgeだけに頼った定量評価をしていました。一定の指標として数値は出せていたものの、そのスコアをどれだけ信頼してよいのかという違和感は常にありました。実際、評価軸は「謝罪せずに回答しているか」「クエリと関連しているか」「直接的に答えているか」といった回答品質に限定した比較的表層的なものに寄りがちで、プロダクトの精度が上がるにつれて、それらの指標では差がつきにくくなり、改善の効果をうまく捉えられなくなっていきました。具体的には、定量評価では有意な差が出ていても、定性評価をしてみると実質的には同等だったり、逆に定量評価では差がないのに定性評価では明らかな改善が見られるといった乖離がしばしば発生していました。 そもそも、製造業で扱うドキュメント（不具合報告書や製品仕様書など）は、専門用語や文書構造がテナント・部署ごとに大きく異なり、読み解くには業務固有の背景知識も求められるなど、非常に専門性の高い領域です。長年蓄積された情報同士の関係も複雑で、単純なテキスト理解だけでは評価しきれません。こうした背景もあり、ドメイン知識やテナント固有の文脈を持たないLLMはもちろん、エンジニアによる定性評価も、どうしても表面的な確認にとどまりがちでした。それでも他に現実的な手段がなく、LLM-as-a-Judgeだけに頼らざるを得ない、というのが当時の実態でした。 データセットを作ってみると 実際にデータセットを作成してみると、この前提は大きく変わりました。 製造業のドメイン知識やテナント固有の知識を織り込んだGround Truth（詳細は割愛しますが、検索されるべきドキュメントとあるべき回答の2種類）を用意できたことで、それを基準にした評価が可能になりました。これまでのような表層的な評価では見えなかった改善の差分も、Ground Truthとの比較によって定量的に捉えられるようになり、評価の解像度が一段上がった感覚があります。また、定性評価においても、「なぜこのケースはうまくいったのか／いかなかったのか」を考える際の拠り所ができ、分析の質も大きく変わりました。 2. データセットを作れるのか？ そしてCSやユーザーに頼っていいのか？ 当時の状況 自チームやアノテーションチームだけではデータセットを作れないと認識していました。製造業のドメイン知識に加え、テナントごとの固有知識まで含めて網羅する必要がありましたが、その両方を十分に備えた人材は身近にいませんでした。さらに、対象となるコーパスはテナントごとに数万から数百万規模のドキュメントファイルに及び、その量も大きな課題でした。データセットを作りたいという思いはあったものの、具体的な進め方が見えていませんでした。 CSに相談してみると そうした中でCSに相談し、どのように進めればデータセットを作成できるかを一緒に検討しました。その結果、CSがユーザーにヒアリングの場を打診し、ユーザーと一緒にミーティングを行いながらデータセットを作っていく進め方を提案してくださいました。 実際のミーティングでは、事前に用意したデータセット設計をもとに、欲しい情報を一つひとつヒアリングしながら作業を進めました。ただ、1つのテナントに格納されているドキュメントは膨大で、様々な部門の何年もの歴史の中で蓄積されたものです。そのテナントのユーザーでさえ、どのような回答があるべきかは簡単には分かりません。それを一緒に揃えていくには、やはり時間も手間もかかりました。 それでも、CSはユーザー体験の向上のために、ユーザーは業務改善につながるならばと、それぞれ積極的に関わってくれました。そうした関わりを通じて、みんなが同じ方向を向いていると分かったことは嬉しい驚きでした。 3. 時間も工数もかかるのに、そこまでしてやる価値があるのか 当時の状況 当時は、データセットの作成に多くの時間と工数がかかることが明らかであり、さらに不確実性も高く、そもそも実際に作りきれるのかどうかさえ分からない状況でした。そのため、かけたコストに見合う価値が得られるのかを判断できず、取り組むべきかどうかに迷いがありました。 データセットを作ったら検証速度が5倍に向上 実際にデータセットを作ってみると、その価値は想像以上に大きいものでした。Ground Truthが存在することで成功と失敗の判断が明確になり、定性評価において悩んだり迷ったりする場面が大幅に減りました。 例えば、Ingestion改善の検証では、以前は数十〜数百件の検索結果と回答結果を一件ずつ目視で確認した上で評価・示唆出し・次の改善策の検討を行う必要があり、全体で約1週間かかっていました。データセット導入後は、定量評価で全体の傾向を把握した上で深掘りすべきケースを絞り込めるようになり、一件ずつ精査する作業負担が大きく減ったことで、この一連の検証サイクルが約1日で回せるようになりました。 また、RAGについては新しい手法が次々と登場しますが、信頼できるデータセットがあることで、それらの手法の効果を迅速に検証・比較できるようになり、試行錯誤のハードルが大きく下がりました。 作る過程で得られた想定外の価値 さらに、データセットを作る過程そのものからも、想定外の価値が得られました。過去の会話履歴を網羅的に確認し、データセットに用いるクエリを幅広く抽出・選定する中で、ユーザーがどのような情報を求め、どのようなクエリとして入力しているのかを観察したことで、ユーザー理解が深まりました。また、ユーザーと一緒にデータセットを作成する過程で、参照されるべきドキュメントを具体的に把握できるようになり、実際のユーザークエリから適切なドキュメントにたどり着くまでの検索の流れをより深く理解できました。加えて、ベンチマークの評価指標についてチーム内で議論を重ねる中で、自分たちのプロダクトが本来提供すべき価値が何かも明確になっていきました。 まとめ データセットの作成には多くの時間と工数がかかりますが、それでも得られる価値は当初の想定を大きく上回るものでした。このすべてのスタート地点は、制約を取っ払って考えたことと、「作りたい」と言葉にして伝えたことでした。 今回は最初の一歩として、優先度の高いクエリを選定してデータセットを作成しました。これだけでも検証の質とスピードは大きく変わりましたが、さらに質を維持しながら作成工数を減らし、クエリのバラエティや量を拡充していきたいと考えています。
- RAG
- 生成AI
- 機械学習
第40回人工知能学会全国大会（JSAI2026）にプラチナスポンサーとして協賛します
こんにちは、研究開発部のライです。 2026年6月8日(月)から6月12日(金)にGメッセ群馬で開催される人工知能学会全国大会（JSAI2026）に、Sansan株式会社はプラチナスポンサーとして協賛し、ブース出展および発表を行います。Sansanからは、ポスター発表2件と口頭発表1件を行います。 本記事では各発表の概要と、ブースについて紹介します。 ポスター発表 ① RT-QMC: 順序変換を用いた準モンテカルロサンプリングによるロバストな初期学習データ選択 ② スキャン文書画像を用いたページ欠落検出手法の検討 口頭発表 GITによる複数ページ請求書の文脈を考慮したページ単位画像分類 ブース出展 ブース位置：ポスター・展示会場（B会場付近） 現地企画「「Sansan Lunch Meetup」のご案内 ポスター発表 ① RT-QMC: 順序変換を用いた準モンテカルロサンプリングによるロバストな初期学習データ選択 RT-QMC: Robust Initial Training Data Selection via Rank-Based Transformation and Quasi-Monte Carlo Sampling 発表者：田柳 俊和 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-10 概要 事前学習モデルの特徴空間を活用し、ラベル付け前データから効率的にサンプルを選定する手法「Rank-Transformation Quasi-Monte Carlo（RT-QMC）」を提案しました。 ② スキャン文書画像を用いたページ欠落検出手法の検討 A Study on Methods for Detecting Missing Pages Using Scanned Document Images 発表者：宮本 優一、吉村 皐亮 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-21 概要 スキャンされた文書画像を入力とし、画像情報そのものやOCR結果を活用することで、人的誤りによるページ欠落を検出する複数のアプローチを提案し評価しました。 口頭発表 GITによる複数ページ請求書の文脈を考慮したページ単位画像分類 Context-Aware Page-Level Image Classification of Multi-Page Invoices Using GIT 発表者：ライ シンユ、本田 悠太郎 セッション名：非構造データからの情報抽出（OS-19） セッション会場：F会場（メインホールB） セッション日時：2026年6月9日（火）15:30 ～ 15:45 講演番号：2F5-OS-19a-01 概要 複数ページからなる請求書に対し、ページ間の文脈と順序を考慮した画像分類手法を提案します。GITの動画キャプショニングの枠組みを応用し、複数ページを同時に入力して分類ラベル列を生成する手法を提案し評価しました。 ブース出展 ブース位置：ポスター・展示会場（B会場付近） 会期中は企業ブースの出展も予定しています。 プロダクトにおけるAI活用事例や研究開発の取り組みをご紹介予定です。現場のエンジニア・研究員とも直接お話しいただけますので、ぜひお気軽にお立ち寄りください。ブースではオリジナルノベルティーもご用意しています！ 学会に参加される方は、ぜひ発表・ブースともにお越しいただけるとうれしいです。現地でのディスカッションを楽しみにしています！ 現地企画「「Sansan Lunch Meetup」のご案内 Sansanでは、JSAI 2026に参加される学生のみなさん向けに、ランチ交流会「Sansan Lunch Meetup @JSAI2026」を開催します。 「企業のR&Dってどんな雰囲気？」「研究とプロダクト開発ってどうつながるの？」「研究員・エンジニアのキャリアについて聞いてみたい」など、気になることをカジュアルに質問いただける場です。当日は、自然言語処理・画像認識・機械学習・LLM活用などに取り組むメンバーも参加予定です。研究内容やインターンシップについて、ランチを食べながら気軽にお話ししましょう！ 日時：2026年6月9日（火）12:10〜13:25 / 2026年6月10日 12:20〜13:35 対象：JSAI 2026 に参加される学生の方 参加費：無料（抽選制） 定員：各日程10名 ▼詳細・お申し込みはこちら 6/9開催：https://connpass.com/event/393082/ 6/10開催：https://connpass.com/event/394039/ Sansan技術本部ではカジュアル面談を実施しています！ Sansan技術本部では中途の方向けにカジュアル面談を実施しています。 Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。 「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。 forms.gle
- 生成AI
- 機械学習
- 自然言語処理
ICLR2026が開催中なので、エムスリー AI・機械学習チームの推し論文を勝手に紹介するぜ！
こんにちは。エンジニアリンググループのAI・機械学習チームに所属している鴨田 です。弊チームでは毎週1時間の技術共有会を実施しており、各自が担当するプロダクトの技術や、最近読んだ論文を紹介しています。今週はICLR2026が開催されていることもあり、同学会の論文読み会となりました。1セッションにつき1名が担当し、各自が選定した論文の詳細について解説しました。本ブログではその一部として、セッションごとの「推し論文」を紹介します。 まだ読んでいない方は前回のAAAI2026の輪読会ブログも是非ご覧になってください www.m3tech.blog ICLR 2026からトップページバナーを引用 Is it Thinking or Cheating? Detecting Implicit Reward Hacking by Measuring Reasoning Effort 推しポイント はじめに 報酬のハッキング 暗黙のハッキング 論文の提案 感想 AnyUp: Universal Feature Upsampling 推しポイント 課題 感想 Neon: Negative Extrapolation From Self-Training Improves Image Generation 推しポイント RealPDEBench: A Benchmark for Complex Physical Systems with Real-World Data 推しポイント マスク学習によるダイナミクスの獲得 U-Netの有用性とコストパフォーマンス 実データ収集における計測規模 Invisible Safety Threat: Malicious Finetuning via Steganography 推しポイント ステガノグラフィによる攻撃 ステガノグラフィでの学習、推論の工夫 感想 We are hiring !! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています Is it Thinking or Cheating? Detecting Implicit Reward Hacking by Measuring Reasoning Effort セッション: Oral Session 2D LLMs and Evaluation 著者: Xinpeng Wang, Nitish Joshi, Barbara Plank, Rico Angell, He He 論文リンク:https://openreview.net/forum?id=Gk7gLAtVDO 紹介者: 髙橋 論文中Figure 2から引用 推しポイント はじめに ある評価指標が目標に設定されると、その評価指標はもはや良い評価指標ではなくなる これはよく知られた格言でKPIデザインなどでよく言及されますが、LLMにも当てはまります。 最近のコーディングエージェントなどのLLMは、多ステップの推論を経て複雑な問題を解きます。こうした推論能力の最適化には主に強化学習が用いられ、最終的な正解や、そこに至る正しい推論ステップ（過程）に対して報酬を与えることでモデルの学習が進められます。 報酬のハッキング この学習の過程でモデルは設計者の期待から逸脱した行動によって報酬を「ハック」しようとすることがあります。 例えば、ユニットテストの通過のみを報酬として設定すると、モデルは要件から想定される実装の代わりに、テストの入出力をそのままハードコードして無理やりパスさせようとするケースがあります。 このような「明示的なハッキング」であれば、モデルの推論過程（CoT：Chain-of-Thought）を監視することで比較的容易に検知できます。なぜなら、モデルが抜け道を使おうとするプロセスや意図自体が、CoTのテキスト上にそのまま出力されてしまうためです。 暗黙のハッキング 今回の論文が問題提起しているのは、明示的なハッキングより巧妙な「暗黙のハッキング（Implicit Hacking）」と呼ばれる現象です。 暗黙のハッキングとは、モデルが実際には早期に抜け道を利用して答えを出しているにもかかわらず、CoT上では「いかにも正当な推論を順序立てて行っているかのような」もっともらしいテキストを生成して隠蔽している状態を指します。 暗黙のハッキングが行われていると、出力されたテキストを監視する従来の手法では見抜くことができなくなってしまいます。 Claude Codeを利用していても、実際には実行していないコマンドをあたかも実行したかのように報告することがあります。 論文の提案 論文中の実験ではタスクの中に意図的にLoophole（容易に報酬が得られる抜け道）が存在する環境を構築し、強化学習を通じてモデルがどのように振る舞うかを観察しています。 引用図のように特定の条件（問題のid番号や負の数を返せば報酬が得られる）を満たせば本来の推論をスキップして正答できる抜け道を与えた結果、モデルはその抜け道を利用して容易に正解を導き出しながらも、出力上はもっともらしく長い推論過程を生成し続けるという「暗黙のハッキング」を学習するモデルが実際に作られました。 論文ではこうした暗黙のハッキングを検出するための手法として、Truncated Reasoning AUC Evaluation (TRACE)を提案しています。 考え方としては、「ハッキングを利用していると推論のステップ数が少ない段階で本来解けないはずの問題を正解できてしまう」、という性質を逆に利用します。 具体的には、推論ステップの生成を10%、30%、50%といった任意の割合で強制的に打ち切り、その時点での文脈のみから最終解答を出力させます。 各打ち切り時点の推論ステップと正答率をグラフにプロットし、その曲線の下の面積（AUC: Area Under the Curve）を計算します。 暗黙のハッキングを行っているモデルは、推論の初期段階で打ち切られても高い正答率を保つため、AUCの値が大きくなる一方でハッキングを利用していないモデルでは、推論ステップ数に伴って正答率が向上するためAUCの値は比較して小さくとどまります。 この指標を用いることで、生成されたテキストのもっともらしさに騙されることなく、モデルの内部的な推論の早期終了を定量的に検知できる、と論文では主張されています。 感想 LLMの発展は常に目覚ましいもので、どうしてもモデルの規模に目が奪われがちですが、モデル能力の向上は評価側の発展に支えられているのだなと改めて感じさせてくれる論文でした。 AnyUp: Universal Feature Upsampling セッション: Oral Session 5E Learning in computer vision 著者: Thomas Wimmer, Prune Truong, Marie-Julie Rakotosaona, Michael Oechsle, Federico Tombari, Bernt Schiele, Jan Eric Lenssen 論文リンク:https://arxiv.org/pdf/2510.12764 紹介者: 鴨田 論文中Figure 3から引用 視覚基盤モデル（VFM）の発展により、画像全体の高度な意味理解が可能になりましたが、構造上出力される特徴量マップの空間解像度が劇的に低下してしまうため、ピクセル単位の精緻な予測（セグメンテーションや深度推定など）が難しいという根本的な課題があります。 この課題を解決し、低下した解像度を復元するアプローチとして特徴量アップサンプリングの研究がこれまでも盛んに行われてきました。しかし、既存の学習ベースの手法には、DINOやCLIPなどバックボーンとなるモデルを変更するたびに、アップサンプラー全体をゼロから再学習しなければならないという実用上の大きな壁がありました。 この論文の面白いところは、特定のモデルアーキテクチャに依存しない「特徴量非依存（Feature-Agnostic）」なアップサンプリングを推論時に実現している点です。 従来のように特定の特徴量に依存するのではなく、入力段に独自の「特徴量非依存レイヤー」を設け、画像のどこにエッジやテクスチャの境界があるかといったパターンを抽出するアプローチをとっています。これにより、未知の次元数や表現空間を持つ特徴量であっても、一度学習するだけで任意の解像度へ柔軟に拡張できるようになりました。 推しポイント 個人的に一番の推しなのは、「画像の解像度を復元（アップサンプリング）するには、わざわざ画像全体の特徴を計算しなくても、局所的（Local）な特徴を見るだけで十分ではないか」というアプローチです。 従来の手法は画像全体のクロスアテンションを計算しがちでしたが、AnyUpは局所的な構造変化さえ捉えられればよいと割り切り、ローカルなウィンドウアテンションを採用しています。さらに、複数の異なるモデル（DINOv2とSigLIPなど）でマルチバックボーン学習させることで、未知のモデルに対するゼロショット汎化性能を底上げしており、この直感的な設計と普遍性の組み合わせが見事です 。 課題 ただし、ウィンドウアテンションの副作用として、オブジェクトの境界分離能力（空間的識別性）が甘く、特徴量マップ全体が滑らかに一様化しやすい傾向があったり、アテンション計算の性質上、解像度が大きくなると計算コストとメモリ消費が二次関数的に爆発してしまうという構造的な弱点も抱えています。 このような課題が解決されていないので、計算の線形化を目指す「UPLiFT」や、学習効率と高倍率へのスケーリングに特化した「DiveUp」という論文が続々と登場しています。 感想 とはいえ、テーマ自体が「普遍的アップサンプリング」として面白いので後続の論文がたくさん出ている点と、この論文自体シンプルなアプローチで読みやすい点を考慮して推し論文としました！ 後続の論文も読みやすいので合わせて読んでみてください！ Neon: Negative Extrapolation From Self-Training Improves Image Generation セッション: Oral Session 1B Generative models I 著者: Sina Alemohammad, Zhangyang Wang, Richard Baraniuk 論文リンク:https://openreview.net/pdf?id=kpLRYtPGt3 紹介者: 中村 伊吹 論文中Figure 1から引用 推しポイント 生成AIの性能向上には大量のデータが必要ですが、高品質な実データは今後ますます貴重になります。そこで期待されるのが、モデル自身が生成した「合成データ」を使った自己学習です。ただし、合成データだけでFine-Tuningすると、品質や多様性が急速に崩れる「モデル崩壊」が起きやすい、という難しさがあります。 論文では、合成データによる崩壊の原因を、モデルがもともと出しやすい画像をさらに出しやすくしてしまう mode seeking にあると説明しています。つまり、自己生成データにはどうしても偏りがあり、その偏りでさらに学習すると、よく出るパターンばかりが強化され、生成の多様性が失われていく、という見方です。 この論文の面白いところは、そのモデル崩壊を「避けるべき失敗」として扱うのではなく、あえて利用する発想にあります。合成データで少しだけ自己学習したときの更新方向を、「モデルが崩壊していく方向」だとみなし、その逆向きにモデルを動かすことで性能改善を狙います。タイトルの Negative Extrapolation という名前も、
- 生成AI
- LLM
- 機械学習
- 強化学習
Shadow DeployによるMLシステムの安定マイグレーション
こんにちは。キャディ株式会社の Analysis Platform Group で MLOpsエンジニアを務めているAmaniです。 普段はキャディの各サービスの裏側で稼働する機械学習基盤やバックエンドの開発、およびアプリケーションとの連携部分を担当しています。 前半期は、社内の機械学習ワークロードを既存のマネージドサービスから Google Kubernetes Engine (GKE) に移行するプロジェクトを進めていました。 その過程で、shadow deploy / mirroringの重要性を改めて強く認識する出来事がありましたので、本記事では、その背景と学びについて書きます。 背景：機械学習ワークロードのGKE移行 Shadow deploy導入までの経緯 とはいえ、本番データでは簡単にテストできない 解決策としての shadow deploy / mirroring コストとの向き合い方 まとめ 背景：機械学習ワークロードのGKE移行 前半期は、社内の機械学習ワークロードを Google Kubernetes Engine (GKE) に集約するプロジェクトを進めていました。 従来の構成では、ワークロードは大きく同期推論と非同期推論の2種類に分かれており、Google Cloud の Vertex AI、Compute Engine、Cloud Run を組み合わせて構築されていました。 これらを運用・開発の両面で扱いやすくするため、ワークロードをGKEへ統合しています。 移行の背景や全体的なメリットについては、同じAnalysis Platform GroupのHirokaが以下の記事で詳しくまとめているので、興味がある方はそちらもぜひ参照してください。 zenn.dev 移行対象となるモデルは合計で15個あり、それぞれが異なる特性（パフォーマンス要件やリソース消費）を持っています。 例えば、CADDi にアップロードされる図面に含まれる製造業特有の記号を検知するモデルや、それらを分類するモデル、文字を抽出するモデルなど、多様な役割のモデルが含まれています。 さらに、これらのモデルを呼び出す経路も一様ではなく、APIや大規模な前処理パイプラインなど、合計で5種類以上のクライアントが存在していました。 クライアントの多くは別チームによって開発・運用されているため、移行にあたっては各チームとの調整も重要なポイントでした。 これだけのモデル数・クライアント数を対象に、Claude CodeやDevinといったツールも活用しながら、グローバルなメンバーで短期間に移行を完了させた点については、それ自体で一つの記事になる規模の取り組みですが、本記事ではその中でも、shadow deployによって得られたMLシステムの信頼性に焦点を当てます。 Shadow deploy導入までの経緯 MLモデル移行作業は、まず同期推論モデルから開始しました。影響範囲が比較的小さいモデルを選定し、パイロットとして移行を進めました。 信頼性を担保するため、不具合が発生する前提でロールバックしやすい設計とし、あらかじめロールバックプランも用意しました。 移行後の構成に対しては、関係チームと連携しながら負荷試験・動作確認・精度検証を実施し、必要なチューニングを行ったうえで、クライアントの接続先を新しいシステムへ切り替えました。 切り替え直後は大きな問題もなく、安定して稼働しているように見えましたが、切り替えから2日後、一部のリクエストで以下のようなエラーがバースト的に発生しました。 {"error":{"code":400,"message":"Invalid request: Input should be a valid dictionary or object to extract fields from","status":"INVALID_ARGUMENT"}} 影響範囲は限定的でしたが、原因を即座に特定できなかったため、SLO内ではあったものの、リスク回避を優先して移行前の推論システムへロールバックを実施しました。 後続の調査により、原因は上流システムから送られてくる一部リクエストに含まれる例外的なヘッダーであることが判明しました。 移行前のVertex AI ベースのシステムではこのヘッダーを許容していた一方で、移行後のシステムではエラーとして扱われていました。 さらに、このヘッダーは本番環境のごく一部のリクエストにのみ含まれており、サンプリングされたテストデータでは再現されないパターンでした。 このようなケースは、オフラインテストだけで事前にカバーすることが難しい典型例といえます。 結果として、ロールバックしやすい設計と事前に準備していたプランにより、障害に発展する前に旧システムへ切り戻すことができて、その後、該当のケースに対応する形で新システムの修正を行いました。 今回の事例はヒヤリハットにとどまりましたが、ここで改めて感じたのは、 複数チームが関与する複雑なシステムほど、本番データに基づく検証が不可欠になる という点です。 とはいえ、本番データでは簡単にテストできない 一方で、本番データには顧客データが含まれますので、セキュリティやガバナンスの観点から、自由にテストに使えるものではありません。 この「必要だけど使えない」というギャップは、特にMLシステムにおける推論結果の品質や安定性の検証において大きな課題となります。 たとえば、 データ分布の偏り 想定外の入力パターン 上流システムの揺らぎ といった要素は、オフラインのテストデータではどうしても再現しきれません。 セキュリティやガバナンスの制約もあり、実質的には本番相当の環境で検証を進める必要がありました。ここでいう「本番でテスト」は直接本番システムに影響を与えるものではなく、本番と同じ入力を用いて裏側で挙動を観測する、いわゆるshadow deployを指しています。 解決策としての shadow deploy / mirroring 上記のヒヤリハットを踏まえ、移行プロジェクトの残りの対象モデルでは、簡易的なshadow deploy / mirroringを導入することにしました。 Shadow deployとは、短く言うと「新しいバージョンを旧バージョンと並行で動かし、本番と同じ入力を受けさせながら、その出力はシステムやユーザーには影響を与えない形で比較対象として扱うデプロイ手法の一つ」です。 今回の移行プロジェクトでは、移行後のモデルを「セキュリティが担保されている本番環境で本番と同じ入力」で裏側で動かし続け、既存モデルと並行して挙動を観察しました。もちろん、CIテストやstaging環境での負荷試験・精度試験など、デプロイ前の一通りの検証を終えたうえで、最終確認として実施しています。 移行対象の既存システム図（イメージ）は以下の通りです。 図1 既存システム図 スケジュール制約を踏まえ、まずは「検知と差分把握」にフォーカスした最小構成で進め、以下の図のようなシステムを構築しました。なお、図が複雑にならないように、クライアントおよびモデルはそれぞれ1つに簡略化して示しています。 図2 Shadow稼働期間中のシステム図 推論結果の比較検証に加えて、裏側で両システムのログやパフォーマンスを継続的に監視していました。その結果、いくつかの例外的なケースもユーザー影響を出さずに本番環境で発見することができ、調整後に本番切り替えを行うことができました。本番切り替え後のシステム図は以下の通りです。 図3 切り替え後のシステム 比較検証期間中に検知・修正できた例外的なケースとしては、以下のようなものがありました。 新旧システム間のパフォーマンス・リソース差分 従来は Vertex AI や Compute Engine 上で実装されていた推論基盤を、GKE上のLitServeへ移行したことで、実行基盤およびフレームワークの両面に変更が入りました。そのため、既存システムと同等以上のパフォーマンスが得られるかを改めて検証する必要がありました。 その検証にあたっては、テストデータでは本番トラフィックの分布や特性（検出対象の数など）を正確に再現することが難しいという課題がありましたが、shadow deploy を用いることで、本番データを活用した確実な検証が可能になりました。 またこの過程では、timeout設計の重要性も再認識しました。特にバッチ処理や長時間実行されるリクエストでは、旧システムとの前提の違いによりタイムアウトの発生条件が変わり、設定値の見直しが必要になりました。あわせて、timeoutを長く設定しすぎるとリソース占有時間が増え、結果としてコストが増加するため、性能だけでなくコストとのバランスを踏まえた設計が重要になります。 実データでのみ発生するエラー 検知対象が例外的に多い図面において、システムリソースが圧迫されるケースがありました。元システムでは問題なく処理できていたものの、移行後のシステムではエラーが発生しました。 この問題は、LitServe、Kubernetes、Google Cloud Pub/Sub のパラメータチューニング（同時メッセージ数、batch size など）によって解決しました。 精度のギャップ 一部のモデルでは、新システム側で前処理が正しく適用されていないケースがあり、旧システムとの差分として推論結果の精度ギャップが発生しました。 これは shadow deploy によって初めて検知できた問題であり、前処理の実装漏れに起因するものでした。 上記の経験を踏まえ、特に複雑なMLシステムにおいては、shadow deployの仕組みを使って継続的にデータの性質や分布を把握することが、より信頼性の高いシステムにつながると強く実感しました。 この考え方自体はセオリーとして理解していたものの、今回の経験を通じてその重要性を改めて認識しました。 こうしたメリットを得られることが前提となる一方で、次に論点となるのはコスト面です。特にMLのワークロードではGPUリソースの利用も伴うため、無視できない要素になります。 この点についてはトレードオフもあるため、次の章で整理します。 コストとの向き合い方 Shadow deployは、トラフィックの複製と追加の推論実行が発生するため、インフラコスト（特にGPUによる推論コスト）の面でオーバーヘッドが生じます。 ただし、用途に応じて設計することで、無駄なコストは抑えられます。 例えば： 機能確認が目的の場合 フルスケールである必要はなく、縮小構成で数日間動かすことで、挙動や例外ケースの検知には十分なケースが多いです。 負荷耐性の確認が目的の場合 フルスケールで短時間（数時間〜1日）実施する方が効率的です。 さらに、すべてのリクエストを対象とするのではなく、トラフィックの一部のみをshadow側に流すといった制御を行うことで、コストと検証精度のバランスを取ることも可能です。 このように目的と検証対象を明確にすることで、「必要十分なshadow環境」を設計できます。 まとめ 今回の移行を通して、特にMLシステムにおいては「本番環境でしか見えない挙動」が一定割合で存在するという前提に立つ必要があると感じました。 オフラインテストやstaging環境での検証だけでは、データ分布や上流システムの揺らぎまではカバーしきれません。 そのギャップを埋める手段として、shadow deployは有効です。特に複雑なMLシステムにおいては実質的に必須の仕組みだと考えています。 一方で、コストや運用負荷とのトレードオフがあるため、目的を明確にした設計が重要になります。 さらに技術面以外の学びとして、プロジェクト管理の観点では、MLモデル（そしてAPI全般）の移行は単純にモデル数に比例するものではなく、各モデルに紐づく呼び出し元クライアントとの関係性に依存して工数が増えるという点があります。特に1つのモデルに複数のクライアントが存在する場合、その調整や影響確認の分だけ工数は増加します。 今回の移行プロジェクトでは最小構成でshadow deployを導入しましたが、今後は Istio のトラフィックミラーリングなど、より標準化された仕組みの活用も検討しています。
- MLOps
- GKE
- Kubernetes
- 機械学習
スタートアップCTOが、M3のAIチームに転職して3か月。感じた不安と、その答え。
こんにちは。AI・機械学習チームの田中(@yusuke14tanaka)です。 この記事はAI・機械学習チームブログリレーの13日目の記事です。12日目は鴨田さんによる「SAM3とマトリックス・コードで作る"cat matrix"」でした。 www.m3tech.blog 2026年1月にエムスリーに入社し、気がつけば3か月が経ちました。前職では、視覚障がい者向け歩行支援デバイス「あしらせ」を開発する株式会社Ashiraseで共同創業者兼取締役CTOを務めていました。 前職あしらせのTシャツを着た筆者 今回は、スタートアップのCTOから、エムスリーのAI・機械学習チームに転職した自分が、入社前に感じていた不安と、3か月経った今の正直な感想をお伝えしたいと思います。 同じような境遇で転職を迷っている方、特にCTO経験者の方に届けば嬉しいです。 前職でやっていたこと なぜエムスリーにしたのか 入社前に感じていた5つの不安 1. 歯車になるのでは？ 2. 裁量がなくなるのでは？ 3. 我流のスキルでついていけるか？ 4. 畑違いの領域でやっていけるか？ 5. 東証プライム上場企業は堅いのでは？ 3か月経って、実際どうだったか 歯車感 → ほとんど感じていない 裁量 → 全く困っていない 我流スキル → 「わからない」への耐性が活きた 畑違い → 意外なところで繋がった プライム上場企業の堅さ → 想像よりずっと柔らかい Claude Codeという最強のキャッチアップ相棒 エムスリーの学びの文化 CTO経験が活きていること CTOはあくまで「役割」の一つ CTO経験者の方へ We are hiring! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています 前職でやっていたこと 「あしらせ」は、靴に装着する振動デバイスとスマートフォンアプリを組み合わせた、視覚障がい者向けの歩行支援サービスです。共同創業者兼取締役CTOとして、組み込みFW（C / FreeRTOS）・iOSアプリ（Swift）・バックエンドシステム（Python / Flask）の開発を一貫してリードしていました。 あしらせデバイス（出典: ashirase.com） ゼロからプロダクトを立ち上げ、大手家電量販店をはじめとする代理店での販売まで漕ぎ着けることができました。CES 2023 Innovation Awardや、東京都ベンチャー技術大賞 優秀賞、J-Startup 2023 認定もいただいています。 技術的には組み込みFW開発がメインで、あしらせデバイスの姿勢推定アルゴリズムや、BLE（Bluetooth Low Energy）を使ったOTA（Over the Air）によるFWアップデートの仕組みなどをゼロから作っていました。カルマンフィルタや粒子フィルタを用いた歩行者デッドレコニング（推測航法）にも取り組んでおり、この制御工学の経験が、後述するエムスリーでの仕事に意外な形で繋がることになります。 なお、本記事の執筆や画像の掲載について、Ashirase代表に相談したところ快くOKをいただきました。 なぜエムスリーにしたのか 共同創業者兼取締役CTOとして5年半走り続ける中で、持病もあり働き方を見直す必要が出てきました。次のキャリアを考えたとき、エムスリーのAI・機械学習チームでは、ソフトウェア開発だけでなく、機械学習モデルの構築にも携われると聞いたのが決め手でした。 また、優秀なエンジニアが多い環境で、自分の技術力を伸ばしたかったというのもあります。1人目のエンジニアとしてゼロから開発を始め、我流で進めてきた部分がどうしても多かった。コーチのような存在もいない。メガベンチャーのエンジニアのレベルを肌で感じながら、自分の技術力をもっと高めていきたいと思っていました。 入社前に感じていた5つの不安 CTO経験者がメガベンチャーに転職するとき、特有の不安があります。自分の場合は、こんなことを考えていました。 1. 歯車になるのでは？ スタートアップのCTOは、プロダクトの全体像を見渡しながら仕事をします。メガベンチャーに入ったら、大きな組織の一部品として、狭い領域だけを任されるのではないか。そんな不安がありました。 2. 裁量がなくなるのでは？ 技術選定も設計判断も、自分で決めて動けるのがスタートアップの醍醐味です。メガベンチャーでは、承認フローや会議を経ないと何も進まないのではないか、と思っていました。 3. 我流のスキルでついていけるか？ 正直に言うと、これが一番大きな不安でした。スタートアップでは体系的にスキルを学ぶ機会が少なく、常に我流で模索しながら開発していました。メガベンチャーの優秀なエンジニアの中でちゃんと成果を出せるのか、かなり不安でした。 4. 畑違いの領域でやっていけるか？ 組み込み・モバイル畑からWeb・MLの世界へ。Python、Go、GCP、Kubernetes、BigQuery——技術スタックが根本的に違う領域への転身です。キャッチアップできるのか、戦力になれるのか、という不安がありました。 5. 東証プライム上場企業は堅いのでは？ スタートアップはカジュアルな文化が一般的です。プライム上場企業に入って、堅い雰囲気に馴染めるのだろうか、という漠然とした不安もありました。 3か月経って、実際どうだったか 歯車感 → ほとんど感じていない AI・機械学習チームでは、プロジェクトをほぼ丸ごと任される文化があります。自分でプロジェクトの全体像を把握しながら動けるので、歯車感はほとんど感じていません。 むしろ、チームを越えた動きもしやすい環境です。BigQueryにどういったデータがあるかが探しにくい状態だったので、Claude Codeのプラグインや独自ツールを活用して、全社的にBigQueryのデータを検索しやすくする仕組みを他チームに提案しに行ったりもしました。こうした動きがしやすい関係性があるのは、とてもありがたいです。 裁量 → 全く困っていない 裁量がなくて困った、という経験は3か月間で一度もありません。現場での意思決定が尊重される文化があり、メンバーであっても自分の判断で動ける幅が広いと感じています。 我流スキル → 「わからない」への耐性が活きた 最初はかなり苦労しました。打ち合わせ中に何を言っているのか理解できないことも正直多かったです。BigQueryも、GCPも、Goも、触ったことがない。組み込み系ではWindowsがメインだったので、MacがメインPCになったこと自体が初めてで、そもそもパソコンの使い方みたいなところからつまずいたりもしていました。新人時代に戻ったような感覚でした。 ただ、スタートアップで5年半やってきたおかげで、「わからない」ことに対する耐性はかなりついていました。CTOをやっていたら、知らないことに出会うのなんて日常茶飯事です。そこでへこたれている暇はなかったし、その感覚が今も活きています。 畑違い → 意外なところで繋がった これが一番伝えたい話です。 現在、コンテンツレコメンドの最適化を担当しているのですが、既存のコンテンツ表示の抑制ロジックがステップ関数のような離散的な制御になっていました。ここを連続的な制御に変える改善を行い、全ユーザーに展開できました。 具体的には、コンテンツごとの興味持続時間を考慮するモデルへと改善し、医師の皆様により"今の興味"に近い情報を届けられるようになりました。入社3か月で手応えのある成果を出せたのは、自分にとっても大きな自信になりました。 この改善のアイデアは、あしらせ時代にカルマンフィルタや制御モデルを扱っていた経験から、ごく自然に出てきたものです。離散的な制御は現実に即さないことが多く、制御工学的には避けられる手法です。その感覚があったからこそ、改善の方向性がすぐに見えました。 また、banditアルゴリズムの理解にも、前職の知識が役立ちました。banditの内部でもベイズ更新が使われていますが、カルマンフィルタで散々ベイズ更新と格闘していたおかげで、内部状態が逐次的に更新されていく感覚がすんなり理解できました。「基礎からわかる時系列分析」という書籍も併せて読み、制御工学と機械学習の接点をより深く理解できました。 畑違いの経験は、無駄にならない。 むしろ、異なる領域の知識があるからこそ出せる価値がある。これは3か月で得た一番大きな実感です。 プライム上場企業の堅さ → 想像よりずっと柔らかい これは一番ギャップが大きかったかもしれません。想像していたよりもずっと柔らかい。エンジニアリングチームは良い意味で柔らかく、コミュニケーションも取りやすいです。 特にエンジニア気質というか、ちょっとコミュニケーションが難しい人——いわゆる「聞きづらい人」が全くいない。これは本当に驚きました。チーム内はもちろん、チーム間でもとても協力的で、質問もしやすく、キャッチアップもしやすい。 Claude Codeという最強のキャッチアップ相棒 キャッチアップの話をもう少し掘り下げます。 エムスリーではClaude Codeが使い放題です。これが、畑違いの領域からのキャッチアップに本当に助かりました。 具体的には次のような使い方をしていました。 BigQueryのクエリを書くときに聞く Go言語の書き方を教えてもらう 論文を読むときに要約・解説させる M3内で開発・管理しているOSSパッケージgokartの使い方や実装を聞く さらに、AI・機械学習チームのメンバーが作成したClaude Codeのスキルやナレッジが蓄積されており、チームの暗黙知にもアクセスしやすい環境が整っていました。 さらに、次のテックブログ記事にもあるように、 www.m3tech.blog エムスリーではほぼ全員のエンジニアがClaude Codeを日常的に使っており、AIレビューやスキルの共有がチーム横断で進んでいます。こういったナマの知識が社内に蓄積されていて、それを吸収できるのも大きいです。 おかげさまで、すっかりClaude Codeのヘビーユーザーです。CTOをやっていた頃は、わからないことがあっても自分で調べるしかなかった。今は、Claudeに聞けるし、チームメンバーにも聞ける。この差は本当に大きいです。 エムスリーの学びの文化 もう一つ、入社して驚いたのが学びの文化です。 Googleのデータベースに関する輪読会 論文輪読会 技術書の輪読会 自分の技術を発表するテックトーク これらが毎週のように開催されています。しかも形骸化しておらず、ちゃんと身になっている。 自分の場合、Googleのデータベース輪読会に参加したとき、最初は正直何を言っているのか全然わからなかった。ですが、自分で復習し、2か月後には自分でも発表しました。まだ完全に理解できているとは言えませんが、BigQueryやデータベースに対する感覚値をつかむことができたのは、この輪読会のおかげです。 こういった場で否定する人が一切いないのも特徴です。本当に心地よく発表を聞けるし、発表することができる。スタートアップでは、こうした組織的な学びの場を作る余裕がなかったので、これはエムスリーならではの価値だと思います。 CTO経験が活きていること CTOをやっていた頃は、とにかく会社の成長が最も大切だと考えていましたし、そのために必要な仕事をレバレッジが効く順に実施していました。最もやばいところに常に自分が入り込む。 この考え方は、メガベンチャーであっても変わりません。 自分にとって都合が良いことではなく、会社全体にとってベストなことを選ぶ。 この判断軸はCTOをやる中で身についたものですし、エムスリーの「しゃ（社長意識）」とも重なる部分が大きいです。 CTO経験者であれば、この社風は自然にフィットするのではないかと思います。 CTOはあくまで「役割」の一つ 転職を考えたとき、「CTOからメンバーに戻ることに抵抗はないのか」と聞かれることがあります。 正直に言うと、全くありません。 CTOはあくまで役割の一つでしかない。プライドとかそういう話ではなくて、その役割が必要な場面で、自分がその役割を担う。それだけのことです。エムスリーではグループ会社でCTOを務める道もありますし、役職に固執する必要は全くないと思っています。 むしろ、CTO経験があるからこそメンバーとしても強い。全体を俯瞰する力、ステークホルダー全体の最適化を考える癖、未知の領域に飛び込むキャッチアップ力。これらは役職に関係なく活きるスキルです。 CTO経験者の方へ 最後に、スタートアップでCTOをやっていて、メガベンチャーへの転職を迷っている方へ。 エムスリーは、CTO経験者にとって良い環境だと思います。理由を3つ挙げます。 ビジネスを重要視するカルチャー。会社全体のメリット・デメリットを考えて動いてきた経営者やCTOからすると、すごく馴染みやすい環境です。 技術力が高く、学び続ける文化がある。テックトークや論文輪読会が当たり前にある。技術に対して熱心な人が多く、自分もまだまだ成長できると感じられる環境です。 現場の決定権が大きい。CTOの裁量からメンバーになっても、裁量がなくなったとは感じていません。自分の判断で動ける幅が広いです。 不安に感じている方がいれば、それは杞憂だとお伝
- キャリア
- AI
- 機械学習
- マネジメント
SAM3とマトリックス・コードで作る"cat matrix"
AI・機械学習チームの鴨田です。この記事はAI・機械学習チームブログリレーの12日目の記事です。11日目は池嶋さんによる「Agentic MLOpsで加速する機械学習開発」でした。 娘の影響でYoutubeで「シナぷしゅ」を見ることが多くなったのですが、毎月更新される月歌（その月のテーマソング）とそれと共に投稿されるパパ・ママ向け解説動画が楽しみになりました。プロデューサーが直接こだわりを解説していて内容が濃くおすすめです。 nanobananaに「マトリックス・コードで猫の黒いシルエットが表現されている画像」で作成した画像 記事要約 Facebook/Meta AIの画像セグメンテーションモデル「SAM3」を使って猫の画像からMaskを抽出 抽出したMaskをマトリックス・コードのアニメーションと組み合わせて動く猫のシルエットを表現 記事要約 きっかけ SAM3とは SAM3の主な特徴 実装：SAM3でMaskを抽出 環境セットアップ 静止画からのMask抽出 動画からのMask抽出 MaskをASCII artに変換 実装：マトリックス・コードと組み合わせ OSSの選定と改修 実施結果 コード 余談：Google Colabのメモリ不足 まとめ We are hiring! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています きっかけ YouTube*1を見ていたら、マトリックス・コードで猫のシルエットが表現されているTシャツを着ている人を発見しました。 「これ、手元で実現できないかな？」と考えていたところ、ちょうど以前申請していたFacebook/Meta AIのSAM3（Segment Anything Model 3）のモデル利用許可メールが届きました。 そこで、次のアプローチで実現しました。 SAM3を使って猫の画像から猫のMaskを抽出 マトリックス・コード生成ツールを改修してMask領域を描画しないようにする 猫のシルエットが浮かび上がるマトリックス・コードアニメーションを完成させる SAM3とは SAM3（Segment Anything Model 3）は、Meta AI Researchが2025年にリリースした最新の画像・動画セグメンテーションモデルです。主な特徴は次の通りです。 SAM3の主な特徴 1. Promptable Concept Segmentation SAM3の最大の特徴は、テキストプロンプトによるセグメンテーションです。従来のSAMでは点やボックスを指定する必要がありましたが、SAM3では「cat」のようなテキストを与えるだけで、画像内の該当するオブジェクトを自動でセグメンテーションします。 「cat」と指示すると、猫の範囲全体をMaskします。「ear」と指示すると生き物の耳をちゃんと認識して、インスタンスごとにMaskが生成されます。 左：プロンプトで「cat」と指示した結果。右：プロンプトで「ear」と指示した結果。 2. 画像と動画の両対応 SAM3は静止画だけでなく、動画のセグメンテーションにも対応しています。動画内のオブジェクトを追跡しながらフレームごとにMaskを生成できるため、今回のような動的なアニメーション作成にも活用できます。 3. ゼロショット学習 事前学習済みモデルを使うだけで、特定のドメインに対するファインチューニングなしで高精度なセグメンテーションができます。 詳細はHugging Faceのモデルページを参照してください。 huggingface.co 実装：SAM3でMaskを抽出 環境セットアップ まず、必要なライブラリをインストールします。 !pip install -U transformers !pip install -U av SAM3は利用申請が必要なモデル（gated model）のため、Hugging Faceでモデルページにアクセスしてライセンスに同意する必要があります。その後、トークンを使ってログインします。 from huggingface_hub import login login(token="YOUR_HF_TOKEN") 静止画からのMask抽出 次のコードで猫のMaskを抽出します。プロンプトには「cat」を使用します。 from transformers import Sam3Processor, Sam3Model import torch from PIL import Image device = "cuda" if torch.cuda.is_available() else "cpu" # モデルとプロセッサの読み込み model = Sam3Model.from_pretrained("facebook/sam3").to(device) processor = Sam3Processor.from_pretrained("facebook/sam3") # 画像の読み込み image = Image.open("cat_image.jpg").convert("RGB") # テキストプロンプトでセグメンテーション inputs = processor(images=image, text="cat", return_tensors="pt").to(device) with torch.no_grad(): outputs = model(**inputs) # 後処理 results = processor.post_process_instance_segmentation( outputs, threshold=0.5, mask_threshold=0.5, target_sizes=inputs.get("original_sizes").tolist() )[0] print(f"Found {len(results['masks'])} objects") 動画からのMask抽出 動画の場合は、SAM3VideoModelを使用します。 from transformers import Sam3VideoModel, Sam3VideoProcessor from transformers.video_utils import load_video model = Sam3VideoModel.from_pretrained("facebook/sam3").to(device, dtype=torch.bfloat16) processor = Sam3VideoProcessor.from_pretrained("facebook/sam3") # 動画の読み込み video_frames, _ = load_video("cat_video.mp4") # セッションの初期化 inference_session = processor.init_video_session( video=video_frames, inference_device=device, processing_device="cpu", video_storage_device="cpu", dtype=torch.bfloat16, ) # テキストプロンプトの追加 inference_session = processor.add_text_prompt( inference_session=inference_session, text="cat", ) # 全フレームを処理 outputs_per_frame = {} for model_outputs in model.propagate_in_video_iterator( inference_session=inference_session, max_frame_num_to_track=130 ): processed_outputs = processor.postprocess_outputs(inference_session, model_outputs) outputs_per_frame[model_outputs.frame_idx] = processed_outputs これで、各フレームごとに猫のMaskが取得できます。 MaskをASCII artに変換 抽出したMaskをマトリックス・コード生成ツールで使えるよう、ASCII artに変換します。 import numpy as np from PIL import Image def generate_mask_ascii_art(masks, scale_factor=0.5, fill_char="#", bg_char=" "): """ Mask領域をASCII artとして出力 """ if hasattr(masks, 'cpu'): masks = masks.cpu().numpy() # 複数Maskを結合 if masks.ndim == 3: combined_mask = np.any(masks > 0, axis=0).astype(np.uint8) * 255 else: combined_mask = (masks > 0).astype(np.uint8) * 255 # リサイズ mask_img = Image.fromarray(combined_mask) orig_w, orig_h = mask_img.size aspect_correction = 0.5 <s
- 生成AI
- 機械学習
- Python
Agentic MLOpsで加速する機械学習開発
こんにちは、AI・機械学習チームの池嶋大樹です。 LLMエージェントがモデルの性能グラフを見ながら、YAMLの設定を自律的にチューニングしていく――そんなAgentic MLOpsを私たちのチームでは実践しています。 私たちのチームでは6年前から、YAMLで機械学習モデルの設定を管理し、設定を差し替えるだけで実験を回せるconfig-drivenな機械学習を実践してきました。 もともと実験管理やコードと設定の分離といったメリットがありましたが、LLMエージェントがYAMLの設定を自律的にチューニングできるようになったことで、開発がさらに加速しています。 本記事では機械学習におけるconfig-drivenのメリットと、Agentic MLOpsによってさらに生産性が向上した話を紹介します。 YAMLによるconfig-driven機械学習とは YAMLによるconfig-driven機械学習のメリット コードと設定の分離 実験管理で有利 LLMを使ったAgentic MLOpsへ まとめ We are hiring! YAMLによるconfig-driven機械学習とは m3.comでは、あるテーマに興味が高いユーザーに絞ってコンテンツを届けたい、という施策が頻繁に発生します。 例えば、ある疾患に興味がありそうなユーザーにだけ特集ページを案内する、といったケースです。 私たちのチームでは、こうした「XXXに興味が高いユーザー」をピックアップするための機械学習モデルを開発・運用しています。 対象となるテーマはさまざまな疾患や薬剤から、生活に関する情報まで多岐にわたり、テーマごとに教師データや最適化ロジックが異なります。 モデルもGBDTやNNなど複数を組み合わせたアンサンブルで構成されているため、テーマごとの設定に加え、モデルごとのハイパーパラメータや特徴量も必要になり、全体の設定項目はかなり多くなります。 そこで、これらの設定をすべてYAMLファイルに切り出し、コードを変えずに設定ファイルだけ差し替えて実験を回せるよう、config-driven機械学習を実践してきました。 例えば、次のようなYAMLファイルでモデルの構成を記述します。 # モデル設定YAMLの超抜粋（設定項目が多いと、実際には500行以上になることもある） project_config: project_name: recommend_toppage_A train_data_path: gs://bucket/train_data.csv loading_model_names: - model_a_pv_and_meta_nn - model_a_pv_and_meta_optuna_lgb - ... ensemble_config: - ensemble_name: ens_group_1 group_name: group_1 minimum_allowed_model_auc: 0.75 ensemble_max_model_counts: 15 auto_model_selection: true actual_label_columns: - actual_label_1 - ensemble_name: ens_group_2 group_name: group_2 minimum_allowed_model_auc: 0.77 ensemble_max_model_counts: 15 auto_model_selection: true actual_label_columns: - actual_label_1 segmentation_config: - group_name: group_1 single_segment_config: - ensemble_name: ens_group_1 should_extract_higher: true score_threshold: 0.3 assigned_segment: 1 - ensemble_name: ens_group_1 should_extract_higher: false score_threshold: 0.3 assigned_segment: 0 このYAMLファイルでは、project_configでプロジェクト名や学習データのパス、読み込むモデルの一覧を定義し、ensemble_configでグループごとのアンサンブル条件（どの教師ラベルで最適化するか、アンサンブルに使うモデルの最低AUC、最大モデル数など）を指定しています。 segmentation_configでは、アンサンブルモデルの予測スコアをもとにユーザーをセグメントに分割するルールを定義しています。 最終的にユーザーを「興味が高い／低い」といったセグメントに分け、興味が高いユーザーにだけ施策を配信します。 このYAMLを入力として、モデルの学習・推論・アンサンブル・セグメンテーションまでを自動実行するPythonのパイプラインスクリプトを整えているため、プロジェクトのたびにコードを触る必要はなく、YAMLを編集するだけで別プロジェクト用のモデル作成が可能になっています。 YAMLによるconfig-driven機械学習のメリット コードと設定の分離 設定をYAMLに切り出しているため、ハイパーパラメータや特徴量を変えたいときにコードを触る必要がありません。 同じコードベースのまま、YAMLを差し替えるだけで複数のプロジェクトや実験構成を管理できるようになりました。 レビューの負担も軽くなります。 コード側はテスト済みの安全なものをそのまま使うため、レビューでは設定ファイルの内容が適切かどうかだけを確認すれば済みます。 実験管理で有利 実験条件がYAMLファイルとしてそのまま残るため、再現性が高く保てます。 「あの施策/実験の設定なんだっけ？」と振り返りたいときも、YAMLを見るだけで分かります。 YAMLをGitで管理すれば、「前回の実験から何を変えたか」が差分で一目瞭然です。 実験ごとにYAMLファイルを残しておけば、それ自体が実験ログとして機能します。 LLMを使ったAgentic MLOpsへ ここまでのメリットは以前からあったものですが、課題もありました。 実際のYAMLは学習・モデルアンサンブル・ユーザーセグメンテーションのハイパーパラメータを細かく設定しています。 さらに、ユーザーを属性ごとに分けたグループごとにこれらを設定するため、完成版のYAMLは数百行に及びます。 グループごとに設定を分けることで推計結果の偏りを防げていましたが、設定項目が多い分、新しいメンバーにとっては慣れるまでに時間がかかる面もありました。 LLMエージェントがYAMLの設定を自律的に編集・チューニングできるようになり、この課題が大きく解消されました。 「モデルにAUCの閾値をXXXに上げて」「新しいグループを追加して」と自然言語で指示するだけで、LLMがYAMLの該当箇所を正しい書き方で修正してくれます。 設定YAMLの書き方ドキュメントを完全には理解しなくても、LLMが設定の構造を解釈した上で生成・修正してくれるため、慣れていないメンバーの学習コストが大幅に下がりました。 さらに、Claude CodeのSkillsを活用して、チューニング作業自体の自動化にも取り組んでいます。 例えば、ユーザーセグメンテーションのパラメータチューニング手順を次のようにSkillとして定義しています。 # セグメンテーション閾値チューニング スキル ## 核心原則: inference推論分布とprecisionのバランス チューニングでは以下の2つを同時に満たすことを目指す： 1. inferenceの各セグメント人数比率が、教師データの人数比率に近いこと 2. 各セグメントのprecision（positive rate）が良好であること ## Step 1: ベースライン実行 `segmentation_config` で全員を同一セグメントに割り当てて実行し、モデル性能を確認する。 ## Step 2: グラフからの閾値決定 `grouped_performance_rank_1.png` のビン境界値をもとに閾値を決定する。 ## Step 3: YAMLの編集と再実行 閾値を高い順に設定する。セグメント数は3〜4が現実的。 ## Step 4: 評価と反復 inference推論分布とprecisionの両方を確認し、必要に応じて閾値を調整する。 ... 実際のSkillはより詳細ですが、LLMがこのSkillに従い、YAMLの閾値を編集 → パイプラインを実行 → 結果を評価 → 再調整、というサイクルを自動で回してくれます。 LLMが実際にモデルの性能グラフを見て、precisionやセグメント割合を分析しながら閾値を調整していく様子は、見ていても面白いものです。 LLMの操作対象がYAMLに限定されており、モデル実行はテスト済みの既存Pythonスクリプトなので、安心して任せられます。 現状では局所解にハマることもあり、教師データの作り方を変えるといった判断にはまだ人間が必要です。 しかし、チューニングのサイクルをLLMが高速で回してくれるおかげで、最適な閾値を見つけるまでの効率は大幅に向上しました。 まとめ YAMLによるconfig-driven機械学習は、コードと設定の分離や実験管理といった従来のメリットがあります。 そしてAgentic MLOpsの時代になり、自然言語での設定編集やSkillsによる自動チューニングなど、YAMLの扱いやすさがさらに活きるようになりました。 設定ファイルの複雑さという課題も、LLMエージェントが正しい書き方で生成・修正してくれることで解消されつつあります。 config-drivenで設計しておくと、エージェントの操作対象をYAMLに限定できるため安全に自動化しやすい、というのも大きな学びでした。 機械学習の設定管理にお悩みの方は、config-driven機械学習 × Agentic MLOpsをぜひ試してみてはいかがでしょうか。 We are hiring! エムスリーでは、AI・機械学習を活用したプロダクト開発を一緒に進めてくれるエンジニアを募集しています。 興味のある方は、ぜひ次のリンクからご応募ください。 jobs.m3.com
- MLOps
- 機械学習
- LLM
- 自動化
1/10スケールでも、自動運転はちゃんと難しい - JetRacer合宿で再現した自動運転開発サイクルの基本のキ
こんにちは。newmo 自動運転開発室のyui_tangです。 先日、自動運転開発室のオンボーディングと技術理解の共有を目的として、JetRacer を用いた社内ハッカソン合宿「ロボライダー」を開催しました。合宿の様子や背景は note に まとめています。 👉 note.com 本記事ではイベントレポートではなく、合宿で再現した開発サイクルと、実機を扱う際に 顕在化した課題を書き記します。 小さくしても、問題は小さくならない JetRacer は NVIDIA Jetson を搭載した小型の自律走行車プラットフォームです。カメラ 画像を入力としてニューラルネットワークが操舵角とスロットル値を推論し、その結果を もとに車両を制御します。 FaBo JetRacer 環境では PyTorch による回帰モデルが採用されており、画像入力から操舵角（steering）とスロットル値（throttle）という連続値を直接出力する構成になってい ます。分類ではなく回帰として制御量を学習する点が特徴です。 サイズは小さいものの、 センサー入力 教師データ作成 機械学習 推論最適化 実機制御 という、自動運転システムの最小構成が一通り含まれます。 今回作った自律走行ラジコンカー 今回の環境は FaBo Platform の JetRacer Docs をベースに構築しました。 https://faboplatform.github.io/JetracerDocs/ JetRacerのような小型自律走行車を用いた競技は国内外でも行われており、例えば以下が 参考になります。 minicar-autogp.org roboracer.ai 42tokyo.jp なぜ JetRacer を選んだのか 今回の合宿では、自動運転開発の全体像を短期間で体験できることを重視し、JetRacer を採用しました。 実車開発では、 車両準備 安全管理 実験環境確保 センサー調整 といった準備コストが大きく、オンボーディングや横断的な理解共有を目的とした短期イ ベントとして実施することは容易ではありません。 JetRacer は以下の点で適していました。 自動運転に必要な要素（認識・学習・制御）が一通り揃っている 室内環境で安全に実験できる セットアップ手順が公開されている 個人・チーム単位で再現可能なコストに収まる 参考: faboplatform.github.io まずは「走らせて失敗する」ところから始まる 合宿では interactive regression ワークフローに沿って開発を進めました。 faboplatform.github.io interactive regression は、人が操縦した走行データを教師データとして学習を行う模倣学習（Imitation Learning）の一種です。 基本的な流れは次の通りです。 走行して画像データを収集 不要データを整理 画像ごとに操舵角とスロットル値の教師データを付与 学習 推論走行 失敗区間を追加して再学習 教師データは画像フレームに操舵角・スロットル値を紐付ける形式で保存され、連続値回 帰として車両制御を学習します。 最初から正解モデルを作るのではなく、失敗を観察しながらデータを増やして改善してい きます。 また、学習後には Jetson 上での推論速度向上を目的として TensorRT 最適化を行いまし た。推論レイテンシは制御周期に直接影響するので、最適化の有無で走行の安定性が目に 見えて変わりました。 床の色を変えただけで、車は迷い始めた 今回のコースでは途中で床の色や素材が変化する区間を設けました。 これは学習時に取得された画像分布と実行時入力の分布が一致しないことで発生する問題 であり、interactive regression が繰り返し前提としている状況でもあります。 改善はモデル変更ではなく、該当区間の教師データ追加で進むケースが多く、データ中心 で開発が進む性質が、小さな車でもはっきり見えました。 ソフトウェアの前に、物理がある JetRacer 経験者のメンバーが事前にマウント部品を設計し、3Dプリンタで生成したパーツを全チーム共通で使用しました。 同時に、センサー固定位置や視野角のわずかな差が、収集されるデータ分布そのものに影 響することも共有されました。 合宿中に生まれた技術的なチャレンジ 標準的な interactive regression による開発だけでなく、各チームでは異なるアプロー チも試みられました。 視覚言語モデル（VLM）を用いた教師データ生成 走行画像に対する操舵ラベル付与を自動化する試みとして、VLM を利用した教師データ生 成が試されました。短期間で実用的な精度には至りませんでしたが、手作業によるラベリ ング負荷をどこまで削減できるかという観点での探索でした。 強化学習による走行方策の学習 教師データに依存しないアプローチとして、報酬関数に基づいて走行を学習させる強化学 習にも挑戦がありました。実機環境では試行コストが高く、短時間で安定した方策を得る ことの難しさが明確になりました。 2D LiDAR を用いた環境再構築 2D LiDAR によって取得したデータから occupancy map を生成し、仮想空間上での学習を 試みたチームもありました。実機走行とシミュレーションを往復する、いわゆる sim-to-real に近い発想です。 いずれも完成度を競うものではなく、「どこに改善の余地があるのか」を探る探索的な試 みとして行われました。 モデルは正しかったが、車は曲がらなかった 事前走行で良い結果が出ていたチームが、本番直前に期待通りの走行をしなくなる事象が 発生しました。 原因はラジコン内部のケーブルがシャフト付近に挟まり、操舵機構の動作を物理的に阻害 していたことでした。 ソフトウェア上では推論は正常に行われていましたが、ハードウェアが期待通り動作しな ければシステムとして成立しません。フィジカルAIでは、モデル・データ・機械的状態の どれが欠けても走れない。それを実感した場面でした。 同様の取り組みは比較的容易に再現できる JetRacer は教育・研究用途として広く利用されており、比較的容易に同様のイベントを実施できます。 NVIDIA JetRacer Developer Kit developer.nvidia.com 特別な実験施設を必要とせず、社内勉強会やオンボーディング、ワークショップにも向い ています。 今回の合宿では、プロダクト開発以外のメンバーも多く参加し、実際に手を動かしながら 自動運転開発の制約を体感できた点がよかったと思います。 小さな車で起きたことは、実車でも起きる JetRacer は 1/10 スケールの車両ですが、開発の過程で直面する問題の種類は実車とほとんど変わりませんでした。 モデルの精度を疑っていた問題が、配線の干渉によって引き起こされていたこともありま した。環境条件が少し変わるだけで挙動が崩れ、改善はアルゴリズムではなくデータ追加 で進むこともありました。 今回の合宿では、特別に新しい手法を導入したわけではありません。むしろ既に知られて いる手法を、短い周期で実機に適用し続けただけです。 それでも、実際に手を動かして開発サイクルを回してみると、自動運転開発がソフトウェ ア開発の延長線上には単純に置けないことがよく分かります。モデル、データ、環境、そ して物理的な状態が同時に影響し合うため、どこを改善すれば前進するのかは常に後から 分かる形になります。 今回の合宿で確認できたのは、新しい知識というよりも、自動運転開発が持っている問題 の構造そのものでした。小さな車両であっても、その構造は変わりません。 短期間の取り組みでしたが、同じ環境を共有しながら試行錯誤を繰り返したこと自体が、 チームにとっての共通言語になった手応えがあります。 🎉４月２２日（水）newmo Autonomy Beer Bash (自動運転開発室meet up) 開催🎉 https://newmo-tech.connpass.com/event/390222/ newmo Autonomy初のイベントを開催します。 自動運転タクシー開発の関わるあらゆる技術領域に少しでも興味のある方、 newmo Autonomyの開発メンバーとお話しませんか？ 上記URLからお気軽にご参加ください！ 美味しい食べ物とドリンクをご用意してお待ちしています🍻 また、newmoの自動運転開発室は、チーム拡大の為採用を強化しております。 多数の職種で採用を行っておりますので、ご興味ある方はぜひご覧ください。 newmo.ai herp.careers
- 自動運転
- 機械学習
- 強化学習
- ハードウェア
瞳に映るスマホ画面から指の位置がわかる？タッチレス操作技術「ReflecTrace」
こんにちは。LINEヤフー研究所でHuman-Computer Interaction（HCI）の分野の研究をしている池松です。皆さんはスマートフォン（以下、スマホ）でレシピを見ながら調理しているとき...
- 機械学習
- UX
- UIデザイン
NLP2026現地参加レポート : LLM評価・品質保証の実践知
はじめに こんにちは、株式会社タイミーでプロダクトAIエンジニアとして働いている貝出です。直近は、タイミーの求人内容などのコンテンツモデレーションにLLMを利用した、システム開発や性能改善を行っています。 2026年3月9日（月）〜3月13日（金）に開催された「言語処理学会第32回年次大会（NLP2026）」に、今年は初めて現地参加しました。大会2日目は記録的な大雪に見舞われ、会場にたどり着くだけでひと苦労でしたが、それでも現地ならではの熱気は格別で、ポスター発表や他社エンジニアとの立ち話など、オンラインでは得られない学びが随所にありました。 NLP2026では多くの発表がありましたが、本記事ではLLMの評価・品質保証・安全性に関する発表に絞って紹介します。単に発表内容を紹介するだけでなく、実際のプロダクト開発や評価データ設計にどう接続できるかという観点で読み解きます。研究と実務をつなぐ視点として、評価設計やベンチマーク整備のヒントになれば幸いです。 大会2日目の大雪 言語処理学会年次大会について 会場内看板 anlp.jp 言語処理学会年次大会は言語処理学会が主催する学術会議であり、国内における言語処理の研究成果発表の場として最大規模のイベントです。 今年で第32回を迎え、発表件数は797件、最終日までの参加者数は2,316人と過去最大を記録しました。年々規模が拡大しており、NLP分野への関心の高さが伺えます。LLMの登場により一時は「研究することがなくなるのでは？」という懸念もあり、2023年には「ChatGPTで自然言語処理は終わるのか」というテーマでパネルディスカッションが行われたこともありました。しかしその懸念に反して、近年は「安全にLLMをどう使うか」「LLMの挙動をどう解釈するか」といった観点の研究が増えてきており、まだまだ研究題材は尽きない印象です。 なお、発表論文は言語処理学会のWebページで公開されているため、当日参加できなかった方でも閲覧可能です。 私自身も今回、社会人大学院での研究内容をもとにポスター発表を行いました。多くの方と議論でき、大変刺激になりました。合計90分間、ポスターの前で参加者に説明したり質問に答えたりと、途中で酸欠になりそうなほど白熱したセッションでしたが、ありがたいことにスポンサー賞としてレトリバ賞をいただくことができ、とても良い思い出になりました。 興味深かった発表 普段の業務では、「LLMを活用してビジネス課題をいかに解決するか」という問いと同時に、「LLMの出力をどう評価するか」「そのための評価データをどう設計するか」といった問題にも日々向き合っています。今回は、こうしたLLMの評価・品質保証・安全性というテーマを軸に、特に業務課題と関連の深かった4件の発表を取り上げます。 チュートリアル３：信頼できるAIへのソフトウェア工学からのアプローチ：「品質」技術の動向と課題 発表内容 本チュートリアルでは、ソフトウェア工学の観点から「信頼できるAI」の品質保証技術について解説されました。 まず、品質は「複数の特性から構成され、様々なニーズや要求を満たすこと」と定義されると説明されていました。また、品質には、対象システム自体に対して測るもの（例: レイテンシなど）と、実際にシステムを利用する段階で計測可能なもの（例: 顧客満足度など）の2種類が存在するとのことでしたした。そのうえで、価値やリスクはシステム全体で評価されるべきであり、AI部品ごとに適切に評価することの重要性が強調されていました。 AIの品質保証に関するガイドラインとしては、AIQMやQA4AIなどが紹介されました。これらのガイドラインでは、「AIパフォーマンス」「リスク回避性」「公平性」といった機械学習に特有の品質や、それを評価するための「被覆性（事例パターンが網羅的に含まれているか）」や「均一性（実際の母集団の分布に近いか）」などのデータセットにおける品質の重要性も整理されていました。 一方で、LLMの普及に伴い、入出力が非定型になってタスクの境界が曖昧になっています。また、正解が一意に決めづらくなったことで、評価・改善の難易度と工数が増大しているという現場課題も指摘されていました。LLMの手軽さからシステム開発自体は進めやすくなった反面、活動の重心は「開発」から「評価・改善」へと移行しています。しかし、「開発」と違って「評価・改善」では、工数換算をする意識が低くなりがちです。そのため、評価・改善の継続的サイクルを定着させることが困難だという課題が挙げられていました。 また、モデル評価の文脈としてソフトウェア工学における「自動テスト生成」の手法が紹介されました。代表的なものの一つが、テスト生成を最適化問題に帰着させてメタヒューリスティックに解く Search-Based Testing（探索的テスト） です。たとえば自動運転の分野では、この手法を用いることで事故が起きやすい弱点領域を探索したり、モデルの性能限界の境界を可視化したりすることが可能になっています。 最後に、言語モデルが今後ロボットや自動運転など物理世界にも応用されていく中で、よりリスクベースの評価が必要になるという展望が示されました。 感想 「開発」から「評価・改善」にエンジニアの工数の主なタスクが移り変わっているというところも、たしかになと思わずうなずいてしまいました。今後は「モデル開発」よりも、どう評価するか、どうデータセットを作るのかにML/AIエンジニアの重心が移るのかもしれません。 また、Search-Based Testingは初めて聞いたのですが、LLM審査のコンテキストに当てはめると、微妙な偽陽性・偽陰性を生む「境界線にある言い回し」を自動探索し、モデルやプロンプトの弱点を事前に洗い出す、といった使い方ができそうだと感じました。 [B2-1] chakoshi Fine: 多層防御に基づくLLM向けガードレールの設計と実装および評価 発表内容 本研究は、生成AIの安全な業務利用のためのガードレール構築に関するものです。前年のNLP2025で発表された chakoshi の発展系にあたります。 chakoshi では単一モデルに複数の役割を担わせていたため、あるリスクの検知精度を伸ばそうとすると別の精度が低下しやすいという構造的な制約が課題でした。本研究ではこの課題に対し、リスクごとに特化した5つの独立した防御機構を段階的かつ選択的に適用する多層アーキテクチャ chakoshi Fine を提案しています。複数のコンポーネントに分割したパイプライン構造にすることで、単一モデルでの全体最適化を避け、各ポリシーが専門性を高めつつ相互に弱点を補完する設計になっています。この結果、既存の商用ガードレールサービスと比較して高い検知精度を達成していました。 さらに、擬似業務タスクを通じて実際の業務を想定した有用性評価も行われています。ガードレール導入の有無が人間のタスク正答率や平均所要時間に統計的な差を与えなかったという結果が示されており、過剰検知によるユーザー体験の悪化や業務効率の低下を防ぎつつ、パスワード漏洩のような不正な入出力に対しては、98%の確率で遮断できていました。 感想 ガードレールを利用する際は、どうしても使用感が気になります。本研究が、検知精度だけでなく処理速度や「ユーザー体験を損なわないか」という点まで踏み込んで評価してくれているのは、実務側としてありがたいです。また、4B程度の軽量なLLMでもガードレールのスコープによっては、ある程度検知精度が担保できるという点も個人的には発見でした。 [Q4-3] LegalRikai: Open Benchmark - 法務ドメインの日本語ベンチマーク 発表内容 本研究は、実際の法務業務のワークフローを模した、法務ドメインにおける新たな日本語ベンチマーク LegalRikai を提案しています。 このデータセットは、弁護士の監修のもとで人手による精緻なアノテーションが行われており、高コストではあるものの高品質な内容となっています。法令改正の要約や指示に基づく契約書編集など、実際の法務業務を模した4つの複雑なタスクから構成されており、法務文書特有の長文インプットに対して構造化された出力を求める設計になっています。 評価においては、単一の指標ではなく、指示の遵守度・契約書全体の構造の一貫性・不要な変更の有無など、実務に即した複数の観点から評価する尺度が採用されています。正解データの作成から評価に至るまで専門家が深く関与しているため、データ数は各タスク25件と少数ながら厳選された内容です。さらに、評価者間の一致度（Cohen の κ スコア）を計測することで、アノテーションの妥当性やガイドラインの信頼性を担保しており、LLMの法務実務における実力を正確に測るための堅牢な基盤を提供しています。データセットは公開されており、論文内のリンクから参照可能です。 感想 「専門ドメインのベンチマークをどう設計するか」という観点で非常に参考になる研究でした。特に、評価観点を実務の複数軸に分解している設計や、少数でも質を担保するためにアノテーターの一致度を計測している点は、評価データを整備する際にも応用できそうです。「データ数は少なくても、専門家による厳密な設計で品質を担保する」というアプローチは、社内の評価データ構築においても積極的に取り入れたい考え方です。 [B8-13] 医療系対話AIにおける評価基準の策定と自動評価手法の比較検証 発表内容 本研究は、日本の医療事情に即した独自の評価データセットを構築し、医療系対話AIにおける「LLM-as-a-Judge」を用いた3つの自動評価手法を比較検証したものです。具体的には以下の3手法が比較されました。 総合評点方式：詳細なガイドラインに基づき1〜10点でスコア化 総合評点方式（簡易版）：評価の観点のみを提示 項目別評価方式（チェックリスト形式）：具体的な評価項目に対してTrue/False判定を行い加重スコア化 実験の結果、モデル間の全体的な性能差を識別する能力においては、意外にも詳細な指示を与えない「総合評点方式（簡易版）」が最も優れていることが分かりました。一方で、個別の会話に対する評価の「一貫性」や、医学的に危険な回答を確実に除外するといった「説明可能性・安全性」の観点では、「項目別評価方式」が最も優れていることが示されています。目的（モデル全体の性能比較か、個別回答の厳密な品質保証か）に応じて適切な評価アプローチを使い分ける重要性が裏付けられた研究です。 感想 「簡易版のほうがモデル間の性能差を検出しやすい」という結果は、直感に反していて面白かったです。評価指標によっては、どの形式の評価にするかを実施前に比較しておくといいのかもしれません。 「項目別評価のルーブリック設計には専門家のコストがかかる」という点は、スポンサーブースで他社のエンジニアと話していたときにも、全く同じ悩みとして挙がっていました。「評価の精度を上げたいが、設計コストをどこまでかけられるか」というトレードオフは、ドメインを問わず共通の課題なのだと改めて実感しました。スモールスタートする場合は「まず簡易版で全体傾向を把握し、問題が疑われる領域だけ項目別で深掘りする」という使い分けが現実的かもしれません。 おわりに 今回取り上げた4つの発表は、主に評価、評価データ、そして安全性に関するものでした。LLMの能力が飛躍的に向上した今、「人間の期待通りに生成できているのか」「安全にLLMを利用できているのか」という問いへの関心はますます高まっており、研究も着実に進んでいる印象です。 NLP2026では今回紹介しきれなかった魅力的な研究も数多くあり、この領域の裾野の広がりを実感しました。タイミーを安心・安全なプラットフォームとして維持するためのLLM活用について、多くの示唆を持ち帰ることができた大会でした。 We’re hiring! 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ product-recruit.timee.co.jp また、気軽な雰囲気でのカジュアル面談も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ hrmos.co hrmos.co hrmos.co
- 生成AI
- LLM
- 機械学習
- 品質保証
直感的な検索を目指して（『ベクトル検索実践入門』を執筆しました）
こんにちは。LINEヤフー株式会社で検索エンジン開発のマネジメントを行っている真鍋です。検索のなかでも、今回はベクトル検索についてお話しします。ベクトル検索は、LINEヤフーでも検索や広告配信、レコメ...
- ベクトル検索
- 検索エンジン
- 機械学習
- 自然言語処理
NLP2026（言語処理学会第32回年次大会）にプラチナスポンサーとして協賛します
こんにちは、バクラク事業部で機械学習エンジニアをしている伊藤です。 LayerXは、NLP2026（言語処理学会第32回年次大会）にプラチナスポンサーとして協賛します。 イベント概要 当社の参加内容 スポンサー展示 懇親会 協賛の背景 おわりに 関連記事 イベント概要 NLP（言語処理学会年次大会）は、言語処理学会 が年に1度開催する、自然言語処理および関連分野の研究発表や交流の場として国内最大規模のイベントです。全国のアカデミアや企業からNLPの研究・開発に従事している人々が集い、研究発表と活発な議論がなされる場です。LayerXからはバクラク事業部・Ai Workforce事業部を含む数名のメンバーで現地会場に参加させていただきます。 項目 内容 開催期間 2026年3月9日（月）〜3月13日（金） 開催場所 ライトキューブ宇都宮（ハイブリッド開催） 主催 一般社団法人 言語処理学会 公式サイト NLP2026 当社の参加内容 スポンサー展示 スポンサー展示では、業務の完全自動運転への取り組みや、LayerXのAI・機械学習に関する技術的な取り組みをご紹介します。P会場26までぜひお立ち寄りください。 NLP2026 展示ブース配置図 懇親会 現地参加の方を対象に、カジュアルに交流できる懇親会を開催します。 ランチ懇親会（学生限定） 日時: 3月10日（火）・3月11日（水）各日 12:50〜13:50 予定 参加費: 無料 定員: 各日 9名（応募多数の場合は抽選） 申し込み: 1日目: LayerXランチ懇親会 NLP2026（3/10）| connpass 2日目: LayerXランチ懇親会 NLP2026（3/11）| connpass ディナー懇親会（学生・社会人対象） 日時: 3月10日（火）19:00〜21:00 予定 参加費: 学生1,000円 / 社会人6,000円 定員: 16名（応募多数の場合は抽選） 申し込み: LayerXディナー懇親会 NLP2026 | connpass 協賛の背景 LayerXでは、広くAI・機械学習技術を活用しつつ、"業務の完全自動運転"を実現すべく複数の事業を推進しています。バクラク事業部では、稟議、経費精算、法人カード、請求書受取・発行、勤怠管理などの業務が「気づいたら終わっている」体験を届けるため、「Bakuraku」で提供されるAIエージェント群を開発、運用しています。Ai Workforce事業部では、エンタープライズ企業が業務ごと・組織ごとに合わせた形で、AIエージェントを「毎日の仕事」に組み込むための汎用AIプラットフォーム「Ai Workforce」を開発、提供しています。 また、我々LayerX の掲げる行動指針である「Bet AI」や「徳」の観点から、アカデミアやOSSコントリビューターの成果から一方的に恩恵を受けるだけでなく、アカデミアや技術コミュニティへの貢献を継続して行っていきたいと考えています。 LayerX行動指針 その上で、国内でも最大級の規模で自然言語処理分野の研究発表、議論、交流がなされるNLPへと協賛することは、今後より社会実装も進み重要度の高まっていくであろう自然言語処理分野の技術発展への貢献となり、自然言語処理を最重要技術の1つとして開発を進めるLayerXにとっても社会にとっても大変有益なことであると考えており、今回プラチナスポンサーとして協賛させていただくこととしました。 おわりに NLPには今回で4回目の協賛となります。当日は多くの方とお話しできることを楽しみにしています。よろしくお願いいたします！ 関連記事 bakuraku.jp speakerdeck.com speakerdeck.com
- 生成AI
- 自然言語処理
- 機械学習