SSII2026（画像センシングシンポジウム）にスポンサー・登壇しました
Data＆Analysis部の稲葉です。 キャディは2026年6月10日(水)〜12日(金)にパシフィコ横浜で開催されたSSII2026（第32回 画像センシングシンポジウム）にプラチナスポンサーとして協賛しました。また、キャディから3名が登壇しましたので、当日の様子をレポートします。 オーガナイズドセッション：産業界における生成AIの利活用 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 インタラクティブセッション 終わりに オーガナイズドセッション：産業界における生成AIの利活用 生成AIが産業界でどのように価値を生み、どのような条件で実運用に乗るのかを議論するセッションです。 キャディからは、オーガナイザーとしてシニアリサーチエンジニアの福原（@gatheluck）、また講演者として私、稲葉（@mi_spindel）が登壇しました。会場には約450名と、非常に多くの方にお越しいただきました。 登壇資料はこちらです。 speakerdeck.com speakerdeck.com 私からは、Data＆Analysis部として取り組んでいる生成AI活用事例として製造業RAGを紹介しました。 （本当は、他にも様々な取り組みがあるのですが、また機会を見て紹介したいと思います。） また、この中で直面した課題の一つが「各LLM/VLMモデルが我々のドメイン特有のタスクをどこまで実行できているかが不明」というものでした。 そこで、製造業LLM/VLMベンチマークとしてManuDraw-Benchを独自構築し、比較評価したお話しをしました。 皆様からのたくさんの質問をいただきまして、ありがとうございます。当日は時間の関係で回答しきれませんでしたので、ここで回答したいと思います。 Question： CADでのDXFはパースせずに図面の見た目で拾ってしまった方が総合的なコストが安いという判断でしょうか？ Answer：DXFなどベクター図面のまま処理した方が、QualityやCostの観点で良いタスクは存在していると思います。ただ、結局はimage encoderが必要なタスクはありますし、処理プロセスの種類が増えることによって運用負荷も増えますので、QCDを総合的に判断して技術選定をしています。 Question：会社の固有知識については基本的にはRAGで対応となると思うのですが、RAGでは対応しきれないのではないか、モデルの Fine Tuning が必要ではないかという意見も社内であり、意見が分かれています。 Fine Tuning まで実施したというような事例はあるでしょうか？ Answer：Fine Tuningまで実施した事例があるかないかの詳細はお答えできないのですが、Fine Tuningを考える前に基本はナレッジ管理とGroundingで対応できないかを先に考えるべきだと思っています。また、Fine Tuningと言えど一定のデータ量は確保しなければならないですが、機密情報の漏洩を考えると個社ごとに調整をすることになりがちです。確保できるデータ量とその労力に対する効果を検討する必要があります。 Question：過去の故障事例などは、設計改善に使用可能なレベルで、原因情報が現場から上がってくるモノでしょうか？実は、原因をLLMが把握するところに課題はないでしょうか。 Answer：おっしゃる通りで原因とその対応が上がってくる仕組みを作ることが重要ですし、そこは課題です。その解決のためにも、キャディが提供しているような部横断のデータ基盤を構築しデータを紐づけることが必要になります。 Question：P15のVLMによる3次元点群予測は1点1点を文字列として出力しているわけではないのだと思いますが、Pythonスクリプト出力などでCADモデリングさせて、表面に点を生やしているのでしょうか？ Answer：1点1点を点群を文字列として出力させているのではなく、メッシュモデルとして形状を面の組み合わせで出力させてから点群サンプリングをしています。おっしゃるようにPythonスクリプト出力などでCADモデリングする方法もありますが、コーディング能力や各LLM/VLMが扱える開発環境にも依存するため、このような方法を取っています。 Question：位置やサイズなど幾何的な理解の性能は、モデルの進化を待てばある程度上がってきそうなベンチの結果になっているのでしょうか？ Answer：そのあたりは今後の傾向を見てみないと何とも言えないところですので、今後もトラッキングしていきます。ただ、自然画像や文字列で表現されている位置やサイズの理解は進化が見られます。 Question：3面図とアイソメ図でVLMからみた理解度にどれだけ差があるのでしょうか？VLMの訓練にメインで使われているであろう写真データには三面図的な見え方は珍しそうに思います。写真に近そうなアイソメ図の方が理解してくれたりするのでしょうか？ Answer：とても良いご指摘です。三面図をそのまま与えるよりは、斜めから見たアイソメ図の方が形状の理解力は高い印象です。ただ、アイソメ図には寸法など必要な情報が抜けているので、処理プロセスのどこかでアイソメ図にリフトするとかデータを組み合わせて利用するとか工夫は必要にはなると考えています。 共に登壇いただいたエクサウィザーズの加藤様、LayerXの松村様、素晴らしい発表をありがとうございました。エクサウィザーズ様はやはり取り組まれていることの幅が広いですし、生成AIの性能だけでなくUI/UXやガバナンスといった活用推進の重要なポイントを俯瞰して抑えられているなと感じました。LayerX様はAgentありきの業務フローに変革していく強い意思を伝えながらも、結局は当たり前をやりきれるかという話に共感しました。 登壇の様子 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 昨今の3D基盤モデルなどの潮流を概観し、CAD解析技術の実プロダクト適用における「研究と実践」のリアルを解説するセッションです。 キャディから、Data Platform本部長の今井（@imaimai0）が登壇しました。こちらも500名近い方に聴講いただくことができました。 speakerdeck.com なぜ製造業においてCADが重要なのか、CADの活用において何がボトルネックになっているのか、最新研究の動向はどうなっているのかをお話ししています。 詳細は資料をご確認いただけると幸いですが、私からは特に、CAD（Geometric系）やMechanical Engineering系の研究開発をもっと盛り上げたいと思っていることをお伝えしたいです。 資料の中でもCVPRにおいてGeometric系の論文は5%程度というお話しがありましたが、製造業のGDPが日本の2割程度を占める巨大産業にも関わらず日本においても類似の研究開発が少ないように思います。我々もResearchチームの規模を拡大中ですし、共同開発や共同研究の機会も探しているところです。一緒に盛り上げていただける仲間を募集中です。 インタラクティブセッション 6/11（木）のブース出展では、多くの方にキャディブースへお越しいただきました。セッションを聴講して「話を聞いてみたい」と立ち寄ってくださった方もいらっしゃいました。 ポスター発表では、現在取り組んでいる研究開発テーマを紹介しました。注力しているテーマとして、以下の3点をご紹介しました。 設計資産全体を横断して検索するための、2D図面と3D CADモデルの埋め込み空間の統合 3D CADデータ内の加工に必要な特徴の認識 製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Bench ManuDraw-Benchは公開されているのか？されないのか？といった質問をたくさんいただきましたが、権利の関係上公開は難しいです。ただ、業界の研究開発を促進したいと思っていますので、何かしら対応を考えていきたいとは思っています。 お話いただいた皆様、本当にありがとうございました！ 終わりに SSII2026への協賛・参加を通じて、製造業領域におけるAIの研究開発の現状や、その中でのキャディのチャレンジについて知っていただく貴重な機会となりました。また、来場者の方との交流から、日々取り組む課題に対してもヒントを得られる非常に有意義な場でした。 運営の皆様、素晴らしい会をありがとうございました。 今後もキャディは技術的な挑戦を続け、画像センシング・コンピュータビジョン研究コミュニティの発展と、モノづくり産業のポテンシャル解放の両面に貢献していきたいと思っています。 また皆さんとお会いできることを楽しみにしています！
- 生成AI
- LLM
- CAD
人工知能学会全国大会（第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
- 機械学習
OpenAIエンジニアによるCodexを「自律エージェント」として使い倒すための勉強会レポート
こんにちは、DeNA ヘルスケア事業本部ウェルビーイング事業部DXソリューション部の川上知宏です。 現在弊社では「AI オールイン」を掲げ、プロダクト開発のあり方そのもののアップデートに取り組んでいます。 今回はその一環として、OpenAI 社から 3 名の講師をお招きし、OpenAI が提供する、複雑なタスクを自律的に実行し、人と協働しながら仕事を前に進める AI エージェント「Codex」に関する勉強会を開催しました。 オンラインで開催された 1 時間のセッションには、300 名を超える社員が集まり、大規模な勉強会となりました。
- 生成AI
- LLM
Claude Fable 5 とは Mythos級モデルの実力とClaude Codeでの使い方
はじめに サーバーワークスの池田です。 2026年6月9日、Anthropic が Claude Fable 5 をリリースしました。Fable 5 は、これまで一般公開されず審査済みパートナーにのみ提供されていた Mythos クラスのモデルを、一般向けに安全に利用できる形に調整したものです。 Anthropic は「これまで一般公開したいかなるモデルをも上回る性能」と述べており、SWE-bench Pro（ソフトウェアエンジニアリングのエージェント評価）で 80.3% を記録しています。Claude Code での利用も即日から可能です。 本記事では、公式発表をもとに Fable 5 が「…
- 生成AI
- LLM
マルチモーダル知識グラフ「RAG-Anything」を用いた複雑な実世界ドキュメントの理解
※本記事は、2026年5月までLayerXのAi Workforce事業部でR&Dインターンとして活躍してくれた kemotoさんによる執筆です。本人のインターン期間終了に伴い、LayerX の koichi（こいち）が代理で投稿いたします。最先端のAI協業の現場で得られたリアルな学びを、ぜひご覧ください！ -- こんにちは。LayerX AiWorkforce 事業部 R&D チームでインターンしております竹本（@kemotohuman）です。 当事業部では、エンタープライズのお客さま向けに『Ai Workforce』というプロダクトを提供しています。Ai Workforce では、エンタープライズの業務に用いる複雑なドキュメントを「AIの力でいかに正確に処理・分析するか」というテーマに日々向き合っています。 しかし、実務で扱われるドキュメントの解析は一筋縄ではいきません。複雑なグラフや図表、緻密なレイアウトが施されたPDF資料を最新のAIに読み込ませ、「この内容を正確に分析してほしい」と依頼したとき、期待外れの回答にガッカリした経験はないでしょうか。現在のLLM（大規模言語モデル）技術は飛躍的に進化しましたが、依然として「実世界のドキュメント」を真に理解しているとは言い難いのが現状です。 今回は、このような課題を解決するために提案されたフレームワーク「RAG-Anything」について、そのアプローチと仕組み、そして実務への応用可能性を解説します。 元論文：https://arxiv.org/abs/2510.12323 GitHub：https://github.com/hkuds/rag-anything 一般的な情報抽出が抱える課題 複雑なビジネスドキュメントからAIを用いて情報を抽出する際、従来の一般的なシステム（テキストベースのRAGなど）では、主に3つの構造的な壁に直面します。 1. 視覚的・マルチモーダルな情報の欠落 一般的にドキュメントをAIに処理させる場合、まずは一度「テキストデータに変換（文字起こし）」してからLLMに入力するアプローチが広く使われています。しかし、この方法ではグラフの推移やフロー図のように、「視覚的な理解が必要な要素」から情報を正確に抽出することが極めて困難になります。 テキストデータへの変換が情報抽出に悪影響を及ぼす例 ページ全体をそのまま画像としてマルチモーダルLLMに入力するという手段もありますが、レイアウトが緻密で複雑なドキュメントほどノイズが増えてしまい、ピンポイントでの情報抽出において精度が出ないというジレンマを抱えています。 2. 散在する情報や多段階推論への弱さ 回答の根拠となる記述がドキュメント内の1箇所にまとまっていれば良いのですが、根拠が複数かつ離れたページに散在している場合、一般的なアプローチでは抽出の難易度が急激に上がります。 ドキュメント全体の内容を俯瞰し、離れた位置にある複数の要素を整理しながら、多段階で答えを導き出すような高度なタスクにおいて、ナイーブな処理の場合LLMの純粋な処理能力（モデルの賢さ）まかせになってしまい、システム側での制御が難しいという弱点があります。 3. 回答根拠の不透明さとハルシネーション 実務でAIを活用する上で、「AIの回答が、ドキュメントのどの部分に基づいているか」をユーザーに明示することは、信頼性の観点から不可欠です。一般的な情報抽出では「LLMに回答と同時に参照元のテキストも出力させる」という手法がよく取られます。 この場合、LLMがプロンプトの指示を途中で省略してしまったり、実際にはドキュメントにないテキストを出力してしまうハルシネーションのリスクが常に伴います。また、「根拠を正確に出力する」という余分なタスクをモデルに強いることで、本来の情報抽出性能そのものが低下してしまう懸念も存在します。 このように、従来のやり方では「視覚情報の欠落」「散在する情報の整理」「根拠の不透明さ」という3つの壁にぶつかってしまいます。 これらの課題、特に「散在する情報の整理」や「複雑な関係性の欠落」を根本から解決するためのアプローチとして、近年大きな注目を集めているのが「知識グラフ（Knowledge Graph）」の活用です。 次のセクションでは、まずこの知識グラフとLLMを融合させることで何が可能になるのかを詳しく説明します。 知識グラフとLLMの融合 前セクションで触れた「情報の散在」や「複雑な関係性の欠落」といった従来のRAGの限界を突破するための鍵となるのが、「知識グラフ（Knowledge Graph）」とLLMの融合です 。 1. 知識グラフとは？ 知識グラフとは、実世界に存在する人・場所・組織・概念などの「エンティティ」と、それらの間にある「エッジ（関係性）」を用いて、情報をネットワーク構造で記述したものです 。 知識グラフの例（はじめての知識グラフ構築ガイド より抜粋して作成） 例えば上の例だと、「KarlとFredは友達（FRIEND）同士で、2人とも東京（Tokyo）に住んでいる（LIVES_IN）」という情報を、それぞれの人物や場所をノード（丸）で表し、それらの関係を矢印（エッジ）で繋いで構造化して表現しています。 こうしたデータはNeo4jなどの専用のグラフデータベースで管理され、Cypherなどのクエリ言語を使って操作されます。 知識グラフは情報同士の複雑なつながりや暗黙的な関係性を明示的かつ正確に表現できる一方で、データの構築や運用のハードルが高い点が長年の課題でした。 2. LLMとの統合 近年のLLM（大規模言語モデル）の発展は、知識グラフの構築や活用のあり方にも大きな変化をもたらしています。 まず大きな変化として挙げられるのが、LLMによって知識グラフの構築が圧倒的に容易になった点です。従来、テキストからエンティティやエッジを抽出してグラフデータを構築するには、固有表現認識（NER）をはじめとする複雑な自然言語処理の技術をいくつも組み合わせる必要があり、開発や運用のハードルが非常に高いものでした。しかし現在では、LLMに対してプロンプトで「この文章から要素と関係性を抽出して」と指示するだけで、柔軟かつ制御しやすい形でデータをパースできるようになり、構築のコストが大幅に下がっています 。 一方で、こうして構築した知識グラフを、今度はLLMのコンテキストとして与えて活用するアプローチも進化しています。これが、近年検索拡張生成の発展形として注目されている「GraphRAG」です 。LLMに構造化された知識グラフを組み合わせることで、従来のテキストを細切れにして検索するだけの方法では解けなかった、ドキュメント内の離れた情報を跨いで整理するような、高度で複雑な多段階推論が可能になります 。 3. 従来のRAGとGraphRAGの違い Naive RAGとGraphRAGの比較（「**When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation**」 より抜粋して作成） ドキュメントの検索において、一般的なテキストベースの従来のRAG（Naive RAG）と、知識グラフを活用したGraphRAGには決定的なアプローチの差があります 。 Naive RAGの限界 ：ドキュメントを一定の長さでチャンク化し、質問文とのベクトルの類似度（セマンティック検索）で関連箇所を探します 。しかし、この方法では情報同士の暗黙的な関係性が削ぎ落とされてしまい、適切な回答を導き出せないケースが多発します。 GraphRAGの強み：ドキュメント内の要素をインデックス化する際、あらかじめ要素間の関係性をネットワーク構造として保持します 。そのため、質問に対して関連するグラフ構造を辿る検索を行うことができ、離れたページに散在している情報や暗黙的な関係性も取りこぼさずに網羅して抽出することができます 。 このように、LLMにドキュメントの構造や関係性を教え込むアプローチとして、GraphRAGは極めて強力なソリューションです 。 しかし、一般的なGraphRAGは依然としてテキストデータをベースにグラフを構築するものが大半です。PDF資料にあるような「グラフや図表、複雑なレイアウトそのものが持つ視覚的な意味」までを知識グラフに融合させることは、容易ではありません。 RAG-Anything RAG-Anythingは、テキスト、画像、表、数式といった異なるモダリティ（データの種類）の情報を、すべて「相互に繋がりを持つ知識エンティティ」として再定義し、包括的に検索・生成を行うオールインワンのマルチモーダルRAGフレームワークです。 RAG-Anythingの概要 1. インデックスの作成 RAG-Anythingにおけるマルチモーダルなインデックス作成（元論文より抜粋） まず、入力されたPDF資料を高度なレイアウト解析パーサー（オープンソースの「MinerU」など）を用いて、テキスト、画像、表、数式などのコンポーネントに分離・抽出します。 このとき、単にデータを細切れ（チャンク化）にするのではなく、「図とそのキャプション」「数式とその定義文」「表とその説明テキスト」といった、ドキュメント内で密接に関わっている周囲の文脈を保持したまま、知識単位に分解するのが大きな特徴です。 次に、分解された知識単位から、役割の異なる2つの独立した知識グラフを並行して構築します。 クロスモーダル知識グラフ（Cross-Modal Knowledge Graph）画像や表、数式などの非テキスト情報をVLM（視覚言語モデル）に入力し、検索用の「詳細な説明文」と、グラフ用の「エンティティ要約」の2つのテキスト表現を出力させます。これらを起点（アンカー）として、周囲のテキストチャンクと「belongs_to（〜に属する）」などのエッジ（矢印）で結び、ビジュアル要素をドキュメントの文脈構造の中に正しく位置づけます。 テキストベース知識グラフ（Text-based Knowledge Graph）ドキュメント内の純粋なテキスト部分に対しては、従来のGraphRAGの手法を用い、固有表現抽出や関係性抽出を行って文字ベースの知識ネットワークを構築します。 こうしてできた2つのグラフを、同一の概念や単語のマッチングによって1つの包括的な知識グラフへと融合させます。同時に、高速なセマンティック検索を可能にするため、すべてのノードや関係性を高次元のベクトルに変換したベクトルデータベースも裏側で構築されます。 2. クロスモーダル検索と回答生成 RAG-Anythingにおける情報検索と回答生成の流れ ユーザーから質問（クエリ）が投げかけられると、RAG-Anythingはまずクエリを分析し、文中に「図」「グラフ」「表」といった、特定のモダリティを指し示す語彙が含まれているかを識別します。 その上で、以下の2つの経路を組み合わせたハイブリッド検索を実行します。 構造的ナビゲーション（Structural Knowledge Navigation）：融合された知識グラフを探索し、キーワードが直接ヒットした要素だけでなく、グラフの繋がりを辿ることで、離れたページに散在している「暗黙的な関係性」を持つ関連要素まで取りこぼさずに抽出します。 意味的類似度マッチング（Semantic Similarity Matching）：クエリのベクトルを用いて、ベクトルデータベースから意味の近いチャンクやエンティティをピンポイントで検索します。 こうして両方の経路から集められた候補は、グラフ構造上の重要度、ベクトルの類似度、クエリから推測されたモダリティの優先度などを統合したスコアリングによって再ランキングされ、本当に必要なコンテキストだけが厳選されます。 従来の検索システムであれば、検索にヒットした「テキストによる説明」だけをLLMに渡して終わりでした。しかしRAG-Anythingは、検索結果に画像や図表由来のノードが含まれていた場合、元のドキュメントから該当する「生の画像データ」をピンポイントで取得します。 そして、厳選された構造化されたテキストコンテキストと、取得された生の画像の両方をVLMに同時に入力し、最終的な回答を生成します。これにより、テキストの文脈理解と、画像そのものが持つ生の情報を掛け合わせて回答を生成できます。回答の根拠となる図表が元データに直接ひも付くため、「どの視覚情報に基づいた回答なのか」を追跡しやすくなり、根拠なき出力（ハルシネーション）の混入を検知・抑制しやすいという利点があります。 3. 精度評価 RAG-Anythingの有効性を検証するため、論文ではマルチモーダルなドキュメントQAのベンチマークである「DocBench」および「MMLongBench」を用いた性能評価が行われています 。比較対象として、ネイティブマルチモーダルLLMへの直接入力（GPT-4o-mini）や、テキスト中心のGraphRAG手法（LightRAG）、画像要素のみをグラフ化する手法（MMGraphRAG）などが選定されました 。 （DocBenchデータセット による精度評価結果（元論文より抜粋） 実験の結果、RAG-Anything は各種ベースラインと比較して、特にドキュメントのページ数が多くなる長文コンテキストにおいて良好なパフォーマンスを示す傾向が確認されています 。例えば DocBenchデータセットにおける100ページを超える長大なドキュメントの検証では、DocBench の正答率〔Accuracy, %〕で MMGraphRAG に対して13ポイント以上の精度向上が見られました。また、MMLongBenchにおいても同様の傾向が見られ、情報が複数ページに分散している状況での優位性が示されています 。 さらに、どのコンポーネントが精度向上に寄与しているかを分析するアブレーション研究も行われており、RAG-Anything における性能のコアは、単なるリランカー等の工夫ではなく、デュアルグラフの構築によってドキュメント内の構造や要素間の関係性を保持できている点にあることが示唆されています 。 実際に使
- 生成AI
- LLM
- RAG
コミットからPR作成までのリードタイムを26%短縮 AI活用の「定着 × 成果」の測り方
こんにちは。ファインディ株式会社でアプリケーションエンジニアをしている西村です。 ファインディの開発組織ではここ1年ほど、Claude Codeを使った開発プロセスのSkill化を進めてきました。Issue生成やセルフレビュー、タスク分解といった作業をSkillにして、社内のClaude Code Pluginに追加するのが日常になっています。 ただ、便利なSkillを揃えて配っただけでは、それが開発フローの中でどれだけ使われ、成果につながっているかまではわかりません。 そこで今回は、開発組織内で配布したPluginやSkillの利用データをどう集め、どう見て、どう改善に回しているか、その考え方と運用を紹介します。 作成したSkillが使われ続けるかを見る 定着と成果を組み合わせて評価する 利用データから使われ方そのものを変える 定着と成果のデータをFindy AI+で可視化する まとめ 作成したSkillが使われ続けるかを見る 開発プロセスのSkill化については、これまでのテックブログでも何度か紹介してきました。 【Claude】Pluginsで簡単横展開 - 開発手法の標準化 - Findyの爆速開発を支えるAI×チェックリスト型セルフレビュー Findyの爆速開発を支えるAIによるタスク分解の粒度設計 繰り返す作業があればSkillとして作成し、社内のClaude Code Pluginへ追加する流れは今も続いています。 一方で、配ったSkillが日々の開発に定着するかどうかは別の話です。配布した当初は新しい取り組みに前向きなメンバーが使ってくれますが、その後も使い続けるとは限りません。Skillの数と種類は充実しているのに、実際に利用されているのは一部だけ、という状況が生まれます。 「作った」で満足せず、配ったあとも「使われているか」を継続的に見ていく必要があります。 定着と成果を組み合わせて評価する ファインディでは、Claude Codeの活用度や作成したSkillの利用状況を計測して可視化しています。集めたデータから、開発工程のどこでどのSkillが効いているかを見て、改善しつづけています。 データを見てみると、よく使われていても成果につながっていないSkillもあれば、利用回数は少なくても効きどころで使われて大きな効果を出しているSkillもあります。つまり、Skillの利用回数だけを成果とみなすと、この違いを見落とすことがわかりました。 そこで私たちは、Skillが定着しているかを測る指標と、成果への貢献を測る指標を組み合わせて評価することにしました。 定着を測る指標は、一定期間内にSkillがどれくらいの頻度で使われているか、つまり利用頻度です。 成果への貢献を測る指標は、Skillを使い始めた後にPRの作成からマージまでの時間といったリードタイム等が短縮したかです。 利用データから使われ方そのものを変える ファインディでは2026年3月に、セルフレビューSkillを導入しました（導入の経緯はこちらの記事で紹介しています）。ただ作成するだけでなく、ドッグフーディングして、AgentTeamに対応させたり、テストのカバレッジが十分かを見る観点を加えたりと、Skillの中身を改善してきました。 セルフレビューSkillは、変更したコードのバグを見つけたりテストの網羅性を高めたりする効果があり、組織全体での定着率を上げていきたいSkillです。 ただ、利用データを見て気づいたのは、改善すべきは中身だけではないということでした。導入直後の3月時点で月298回と一定の利用はあったものの、セルフレビューSkillを呼ぶかどうかは各メンバーの判断に委ねていました。そのため、エンジニア全員の開発フローに浸透するほどには使われていませんでした。 2026年3月時点のSkillの利用回数（左：アウトプット上位5名、右：組織全体96名）です。セルフレビューSkillの呼び出しは、アウトプット上位で117回、組織全体でも298回でした。 アウトプット上位 組織全体 そこで、Skillの使われ方そのものを変えました。SlackのPluginリリース告知チャンネルで使い方を周知し、あわせてPR作成Skillの中からセルフレビューSkillを呼び出すようにして、PRを作るときには必ずセルフレビューSkillを使用する環境に変えました。 その結果、セルフレビューSkillの呼び出しは、アウトプット上位で185回、組織全体で479回まで増えました。セルフレビューSkillが組織全体の標準的な動作として定着したことがわかります。 アウトプット上位 組織全体 さらに、導入前後でリードタイムを比べると、コミットからオープンまでの平均時間は22.2時間から16.3時間に縮みました。AIが書いたコードを人間がセルフレビューしていた手間を減らせたことが、短縮の一因だと考えています。 定着と成果のデータをFindy AI+で可視化する これまで紹介してきたSkillの呼び出し回数データは、Findy AI+の分析機能を使っています。Findy AI+ではClaude CodeのMonitoring機能を活用し、Skillやコマンドの実行ログを収集して、「どのSkillがいつ実行されたか」を一元的に追えるようにしています。 集めたログからは、Skillごとの呼び出し回数や、それが一部のメンバーに偏っているか組織全体に広がっているかといった定着の度合いが見えてきます。ここにTeam+のPR作成数やレビューのリードタイムといった成果指標を重ねると、定着と成果のデータが揃い、「どのSkillで、どの指標に効いているのか」を分析できます。 まとめ PluginやSkillは、配って終わりにすると少しずつ使われなくなっていきます。配ったあとも「使われているか」さらに「アウトプットの増加に貢献できているか」まで見て初めて、改善の打ち手が定まります。 もしすでにPluginやSkillを配っている方がいれば、まずは「どのSkillが、誰に、どれだけ使われているか」を1つでも数字で見えるようにするところから始めてみてください。配ったあとのデータがそろうと、次にどこへ手を入れるべきかが自然と見えてきます。 Findy AI+の分析機能については、Findy AI+の紹介ページもあわせてご覧ください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- 生成AI
- LLM
- 開発生産性
AIエージェントに1年分のニュースを読ませて4,500件の長期記憶を作って見えた課題
はじめに LayerX Ai Workforce事業部でApplied R&D をしているtyoyoです。 AI Agentの長期記憶に関して様々な手法が提案されていますが、そのどれもが実際に長期間で運用されたことはほとんどないはずです。なぜなら、それらが台頭したのが最近だからです。 個人的に長期記憶についての肌感覚がなかったので、実験として「1年分のAIニュースの長期記憶」を作ってみることにしました。 最大6並列で約20時間、607回のセッション、4,552個のmemoryファイル ー 動かしてみないと分からない「長期記憶の課題」にぶつかるため、今回はこういった規模でシミュレーションを行いました。 Claude Codeを参考にした簡易的な長期記憶システムの作成 基本的にはClaude CodeのMemoryを参考に、以下のような frontmatter（ファイル先頭のメタデータ記述部分）つきのMarkdownファイルを1つの単位とします。これらが memory/ ディレクトリ以下に大量に配置されるシンプルな構成です。 memoryファイルの具体例 --- date: 2024-08-14 description: "GartnerによるPoC後に見送られる生成AIプロジェクトが30%に達するという2025年末予測、生成AIのROI・短期投資回収困難・データ品質・コスト問題、企業の生成AIPoC失敗率統計を調べている時。" sources: - https://atmarkit.itmedia.co.jp/ait/articles/2408/14/news067.html related: - 2024-08-07-gartner-ai-investment-business-fit-failure-4-reasons.md --- # Gartner：生成AIプロジェクトの30%が2025年末までにPoC後に見送りになると予測（2024年8月） Gartnerは2024年8月、生成AIプロジェクトの30%が2025年末までに概念実証（PoC）後に見送られると予測した。IT Mediaが同日付で報じた。 バイスプレジデントアナリストのリタ・サラム氏は、「生成AIの2023年の過熱ぶりを経て、経営幹部は投資に対するリターンを急いで求めているが、組織は価値を証明し実現することに苦戦している」と述べた。見送りの主な背景として、$500万〜$2000万規模のコスト、短期的なROIが出にくい構造、データ品質の問題が挙げられている。CFOは将来の間接的価値のために投資することに抵抗感を持ちやすいとされ、長期コミットより短期成果を優先する傾向がある。 一方で早期導入企業はビジネス改善を報告しており、Gartnerの2023年9〜11月に822人のビジネスリーダーを対象とした調査では、平均売上高15.8%増加・コスト15.2%削減・生産性22.6%向上という自己報告値が示されている。ただしサラム氏は「ビジネス価値の推定は容易でなく、企業・ユースケース・役割・人材によって大きく異なる」と留保している。 この記憶は、生成AIのPoC後廃棄率・ROI困難・コスト構造に関するGartnerの定量予測として位置づける。楽観的な効果数字と廃棄リスクの両方を持つ点が特徴。 生成AIプロジェクトの投資判断・経営説得・リスク評価の文脈でGartnerの見解を参照したい時に見るとよい。 記憶の追加については、qmem-add というSkillを作り、そこに保存すべきものや保存形式などの指示を記載しました。 記憶呼び出しは、qmem-search というSkillを作り、そこに4つのアクセス手段を提示しました。 tobi/qmd を用いた検索（BM25（キーワードベースのランキングアルゴリズム）, ベクトル） description + ファイル名 の一覧を提示する qmem-ls コマンドによる、SKILL.md風遅延読み込み frontmatterのrelated によるグラフ辿り grep などを用いたキーワードマッチ またHook を用いたリマインダーによる自動的な記憶呼び出しも作成しました。各ユーザーからのpromptとツールの呼び出し結果をクエリとし、BM25検索で一定の閾値を超えた場合に <qmem> {filename}: {description} </qmem> のようにAgentに記憶が提示されます。 Dreaming（記憶のライフサイクル管理）としては qmem-maintain Skillを作り、20セッションに1回 Agent自身に記憶の重複削除・古い記憶の更新・related フィールドを用いた記憶の関連付けを行いました。 Agentに1日で1年分のニュースを読ませる データとしては LayerX AI・LLM Newsletter を60号分（2024年1月-2025年2月まで）使用しました。各Newsletterは平均2万文字、リンクとしては111個と大きなファイルです。Agentは10分割されたNewsletterファイルを読み込み、それぞれのニュースについて記憶を追加するように指示を受けます。 Claude Codeのデフォルト設定を使用し、モデルはSonnet 4.6 (200k) を利用しました。 Dreaming以外は6並列でまわし、およそ20時間程度かかりました。合計で607回のセッションが実行されました。まれにプロセスが固まってしまうため、Claude Codeの /loop を使い実験を監視・再開させていました。またそのClaude Code自体がレートリミットで落ちてしまうことがあったため、codexbar cli を用いてレートリミットがリセットされるタイミングで監視を蘇生させていました。実験はClaude Code Maxプランを用いて行いましたが、API換算だと合計で$407 かかっている計算です。 1年分の記憶をもつAgent 結果として4,552個のmemoryファイルが生成されました。これらの記憶をもつAI Agentに 「RAG の評価設計を相談したい。retriever / reranker / generator のどこから手を付けるべきか?」 と質問をしてみると、 ...記憶によると（2024-08-19-aws-ragchecker-claim-level-rag-evaluation-framework.md）、 Amazon/AWS が 2024年8月に公開した RAGChecker は 「Retriever モジュールと Generator モジュールのそれぞれに対して独立した診断メトリクスを持つ」設計で、 個々の claim レベルで評価を行うことで「どのモジュールに問題があるかを切り分けられる」とされています。 8 つの RAG システムを評価した論文で、GitHub（amazon-science/RAGChecker）でオープンソース公開されています。... のように、過去に読んだ記事をもとにした回答ができています。 Dreamingプロセスの分析 記憶のライフサイクル管理、Dreamingは計18回実行され、450件のファイルを更新・245件のファイルを削除しました。更新では主に記憶同士の関連付け（relatedフィールドの更新）、削除では主に重複した内容の削除（技術ブログとそれを題材にしたSNS投稿など）が行われていました。 またClaude自身が誤ったフォーマットでmemoryファイルを記述してしまい、それをDreamingプロセスで直しているケースも見受けられました。例えばファイル名だけを記述するように指示していたがファイルパスごと記述してしまったり、日付を書くように指定してたものの 2024-08 のように月までしか書いていなかったケースも有りました。これらを防ぐには、長期記憶のシステムにもハーネスのような可能な限りLLMではなくプログラムで守る仕組みが必要です。 個人的に残念だったのは、関連ノードのグラフがほとんど育たなかったことです。全ファイル中 related フィールドをもつのはわずか11.3%で、残りはほぼ孤立していました。もちろん全てのmemoryファイル自体に関連があるわけではありませんが、定性的に確認していても関連しているのにrelated ではないものが見受けられました。relatedを追加するかどうかのpromptは、もっと積極的にrelatedを追加せよ、と書くべきだったかもしれません。 またDreamingのプロセスは「新規追加されたmemoryファイルは全文読み込み、それ以外はfile名とdescriptionのカタログのみ読み込み」を行ってから関連記憶の紐づけを行っていたのですが、4,552ファイルの段階でこのカタログだけで200k contextの228% を占めてしまっていました。DreamingにおいてAgentに自身の記憶を修正させるのは強力ですが、その分扱えるmemoryファイルの数は有限で、「何を忘れるか」の設計も重要そうです。あるいはAgentを使わない埋め込みベースのライフサイクル管理や、階層的なデータ構造なども考えられます。 まとめ 実際に長期記憶の作成をシミュレーションしてみて感じたのは、動かしてみないと見えてこないことがたくさんあるということです。 構想段階では「どのベクトル検索ライブラリを使おうかな」「どんなデータ構造にしようかな」ということを考えていましたが、実際には「何を記憶するか」「いつ繋ぐか」などの細かいプロンプトの影響が大きかったです。またmemoryは容易に膨れ上がるので、「忘れさせる」という戦略をとるか、「スケールするようにする」という戦略の2軸があるように思いました。 この記事で紹介したR&Dチームの詳細はこちらです。 open.talentio.com
- 生成AI
- LLM
ターゲットユーザーの“意識のズレ”をどうAIに組み込むか？——「AIペルソナ」が開発メンバーの相談相手になる日を目指して
社内のリアルなAI活用事例を発信する連載企画「AIジャーニーの足跡」。今回は「AIペルソナ」をテーマに、顧客理解のプロフェッショナルである森本修さんにインタビューを行いました。主務としてゲームサービス事業本部開発運営統括部分析部インサイトアナリティクス第三グループ、兼務としてソリューション本部マーケティング統括部マーケティング部コンシューマーインサイトグループに所属されています。兼務側で「AIペルソナ」について研究を行いながら、主務であるゲーム事業に活かす動きをされています。このインタビューでは、ゲーム開発の意思決定を加速させる「AIペルソナ」の構築手法と、それがもたらすプロダクト開発の未来について迫ります。
- 生成AI
- LLM
- Gemini
- マーケティング
GDC2026で実感したAI時代のゲーム開発と現地参加でしか得られない学び
はじめに 皆さん、こんにちは！ ゲームサービス事業本部開発運営統括部の九谷（ @4_mio_11 ）です。普段はUnityエンジニアとしてアウトゲーム関連を担当しています。AIの活用による業界内変化の激しい中、3月にサンフランシスコで開催された世界最大のゲーム開発者会議「Game Developers Conference（GDC）」に参加しました。 本稿では、AI技術の進化と業界全体のレイオフの波が交錯する中で、私が現地で何を感じ、どのような知見を得たのかをお伝えします。このレポートが、GDC 2026現地参加の価値を皆さんと共有し、世界のゲーム業界の現状とスタンダードをアップデートする一助となれば幸いです。公式セッションだけでは得られない 非収録のセッションであるラウンドテーブルセッションからの学びや、現地で肌で感じたゲーム業界の熱量 を中心に、イベント概要、現地での戦略などについてご紹介します。
- ゲーム開発
- 生成AI
- LLM
- イベントレポート
Deepgram Flux Multilingual のEnd-of-Turn判定を試す
本記事では Deepgram Flux Multilingual の EoT 検出に焦点を当てますが ...
- 音声認識
- Deepgram
- LLM
勉強会「自社で育てる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
- 機械学習
LLMの「聞きすぎ」を止める：ラベル付きデータで自己分析させたプロンプト改善
はじめに バクラクのQAエンジニアをしているteyamaguです。 バクラクでは、カスタマーサポート担当者やカスタマーサクセス担当者が開発チームへ問い合わせをエスカレーションする際、QAエンジニアが一次対応を担当しています。一次対応の中では、調査開始時点では追加確認が必要になるケースがありました。このような場合、不足情報を確認するために担当者がお客様へ連絡し、回答が返ってくるまで調査が止まっていました。このタイムラグが積み重なると、対応リードタイムの長期化につながっていました。 そこで、LLMを使って不足情報を自動検出し、「お客様へ確認すべき質問」を生成するボットを社内に構築し、試行しています。担当者がエスカレーションとして問い合わせ入力をSlackに入力すると、その入力をボットが検知し、Slack上に確認すべき質問が出力される仕組みです。 このボットを運用し始めてすぐ、想定外の問題に直面しました。LLMが「お客様にこの時点では追加で確認しなくてよい情報」まで質問として出力してしまっていたのです。 本記事では、この問題に対して「LLM自身に分析・提案させる」アプローチを試し、改善した過程をまとめます。 何が起きていたか ボットが生成する質問を実際に確認したところ、調査に不要と判断できる出力が含まれていることがわかりました。 ケース1: 再現済みなのに継続確認を求める 問い合わせ内容（抜粋）: - 再現環境: ステージング環境にて再現確認済み - 再現手順・スクリーンショット: 提供済み ボットの出力: 「現在も本番環境で同様の事象が発生しているか確認してください」 「事象発生日時（日時と可能であれば時刻）をご教示ください」 ステージング環境で再現済みで、手順もスクリーンショットも提供済みなのに、発生日時や本番環境でも継続して発生しているかの確認を求めています。再現確認と手順が揃っているため、調査の開始にあたってはこれらの情報は不要でした。 ケース2: 内部で確認できる情報を聞く 問い合わせ内容（抜粋）: - テナントID: 提供済み - 問い合わせ種別: 仕様確認（ステータスを元に戻せるか） ボットの出力: 「ご利用中の連携先サービス名および連携設定状況をご教示ください」 「ご契約情報をご教示ください」 仕様確認の問い合わせに対して、テナントIDがあれば内部で確認できる情報を質問しています。弊社のシステムでは、お客様の環境ごとにテナントIDが割り当てられており、そのIDがあれば一定の情報を取得でき、お客様に聞く必要がありません。 データで見る問題の規模 実際の11件の出力に含まれる46個の質問項目に、OK/NGラベルを付けて分類しました。 評価 件数 割合 OK（適切な質問） 9個 20% NG（不要な質問） 37個 80% 出力された質問の8割がNGでした。 NGをパターン別に分類すると、以下のようになります。 パターン 件数 割合 再現状況から判断すると不要（再現済みなのに継続確認を求める等） 18個 49% 内部で確認できる情報を聞いている 13個 35% 問題の性質に合わない情報を聞いている（仕様確認に環境情報など） 4個 11% 問い合わせ文から自明な情報を再確認している 2個 5% 最多は「再現状況から判断すると不要」で、半数近くを占めていました。 なぜ起きていたのか プロンプトの初期設計を振り返ると、「何を聞くべきか」は詳細に書いていましたが、「何を聞いてはいけないか」は書いていませんでした。 LLMは「不足情報を見つけて質問を生成する」という指示に対して、忠実に、ときに過剰に最適化します。つまり、あらゆる不足情報を質問として出力しようとします。「内部で確認できるか」「再現済みで不要か」といった判断は、明示的に指示しないと、安定しにくい傾向があります。 「何を聞くべきか」を詳細に指示するだけでは足りませんでした。では、「何を聞いてはならないか」と書けばよいのでしょうか。それを人間が網羅的に考えるのは容易ではありません。 そこで、ラベル付きデータをLLM自身に渡して、プロンプトの改善を依頼するというアプローチをとりました。 解決策: LLM自身に出力を分析・提案させる プロセス ボットの実際の出力にOK/NGラベルを付けてデータ化する そのデータをLLMに渡し、プロンプトの改善案を提示するよう依頼する LLMが提案した改善内容をプロンプトに組み込む ポイントは、人間が「禁止ルール」を考えるのではなく、LLMにNGパターンを分析させ、LLM自身に「自分が聞くべきでないこと」を導かせた点です。LLMの提案内容は、人間がレビューした上でプロンプトに組み込みました。 LLMへの依頼はシンプルで、改善案の提示を求めるものでした。禁止ルールという形式はLLM自身が提案したものです。 LLMが導いた禁止ルール 元のプロンプトは、以下の5つのStepで処理を行うものでした。 問い合わせ内容の分類 提供済み情報の確認 プロダクト別不足情報の特定 事象固有の追加確認項目 優先順位・出力ルール これらのStepに、LLM自身がStep 2.5として追加ステップを提案しました。Step 3〜4で候補に挙がる質問のうち「聞くべきでないもの」をあらかじめ定義することで、過剰な質問生成を抑制します。 LLMが提案した内容を整理・確認し、プロンプトに追加しました。以下にそのステップを示します。 ### Step 2.5: 質問してはいけない情報の除外 Step 3〜4で候補に挙がった質問について、 以下に該当するものは必ず除外してください。 ■ 内部確認可能なため聞かない - 連携先サービス名および連携設定状況 - 契約情報 - 対象データの現在のステータスや操作日時 - ユーザーIDが提供済みの場合の関連データ（社内で確認できる情報） - 調査用IDが提供済みの場合の発生日時（IDをもとに社内で特定できる場合） ■ 再現状況に基づいて聞かない - 再現済みと明記されている場合 →「現在も継続して発生しているか」「本番でも発生するか」は不要 - 再現手順・スクリーンショットが提供済みの場合 → 発生日時は確認不要 ■ 問題の性質に基づいて聞かない - 仕様確認の場合 → 環境情報・継続確認は原則不要 - サーバー側処理が原因の事象 → ブラウザ・OS・アプリバージョンは不要 - データ処理・計算ロジックの問題 → ブラウザ・OS情報は不要 ■ 問い合わせ文から自明な場合は聞かない - 期待結果が問い合わせに明記されている場合 → 期待結果を再確認しない - 事象の対象が特定されている場合 → 同じ情報を別の呼び方で再度聞かない あわせて、除外後に質問が0件になった場合の出力も定義しました。 【追加確認は不要です】 調査に必要な情報は揃っています。 このまま開発チームへ共有・調査を進めてください。 結果 禁止ルール追加後の出力についても同様にOK/NGラベルを付けて集計したところ、NG率は改善前の80%から約61%に低下しました。ただし、今回の集計は改善前11件・改善後13件という限られたサンプルに基づいており、統計的な有意性は保証できません。傾向の把握を目的とした参考データとしてご覧ください。また、61%はまだ高い数値です。今回この記事で伝えたいのは最終的なNG率そのものではなく、「ラベル付きデータをLLMに渡してルールを導かせる」というアプローチ自体の再現性です。数値はあくまで手法の有効性を示す参考指標として読んでいただければと思います。 NGパターン別の内訳比較 以下の割合はNG全体に占めるパターン別の比率を示しています。 パターン 改善前（NG内訳） 改善後（NG内訳） 再現状況から判断すると不要 49% 40% 内部で確認できる情報を聞いている 35% 50% 問題の性質に合わない情報を聞いている 11% 0% 問い合わせ文から自明な情報を再確認している 5% 10% 「問題の性質に合わない情報を聞く」パターンが完全に消えました。 仕様確認なのに環境情報を聞く、計算ロジックの問題なのに連携先サービスを聞く、といった出力がゼロになりました。「再現状況から判断すると不要」なパターンも減少しました。 一方、「内部で確認できる情報を聞く」パターンは残存し、むしろ割合が増えました。 NG全体の数が減った結果として相対的に目立つようになった面もありますが、このカテゴリの禁止ルールがLLMにとって判断しにくいことも示しました。「内部で確認できるかどうか」はシステムの知識が必要な判断であり、プロンプトに列挙できる具体例には限界があります。この点は継続的な改善課題と認識しています。 振り返って気づいたこと データが先、ルールが後 最初からこのルールが書けたわけではありません。まずデータを集めてラベルを付け、それをLLMに渡して初めて「どういう条件のときに不要な質問が生まれるか」が言語化されました。 人間がルールを先に考えると「もれなく書かなければ」という意識が働き、かえって抽象的で使いにくいルールになりがちです。実際のNGパターンから帰納的にルールを作る順序が重要でした。今回は11件という少量のデータでも4つのパターンが出揃い、ルールの骨格を作ることができました。 ラベル付きデータをLLMに渡す LLMに「あなたの出力のどこが問題か」を分析させることができました。その際、単に問題のある出力を見せるより、OK/NGのラベルを付けて渡す方が、LLMはパターンを把握しやすくなると考えています。 この「ラベル付きデータを渡してLLMに改善を依頼する」というアプローチは、プロンプト改善の汎用的な手順として使えると考えています。 「質問しない」という出力を定義する 改善前のプロンプトは「質問を生成する」ことを前提に設計されていたため、情報が十分に揃っている場合でも、何かしら質問を出力しようとする傾向がありました。 LLMの提案により「質問が0件のときは追加確認不要と出力する」というルールが加わったことで、質問を生成しないことも正しい出力であると明示できました。当初は想定していませんでしたが、実運用上の価値が大きいことがわかりました。 おわりに 「LLMの出力精度を上げる」というと、モデルの選択やFew-shot（プロンプトに具体例を埋め込む手法）の工夫に目が向きがちです。しかし今回の改善の核は、実際の出力データをLLM自身に分析させるというアプローチでした。 QAエンジニアとして、この流れはテスト設計の改善サイクルと近いものがあります。不具合を収集し、パターンを分析し、設計にフィードバックします。LLMのプロンプト改善も、同じ考え方で進められました。 今回解消しきれなかった「内部で確認できる情報を聞く」パターンについては、Few-shotで具体例を増やす、あるいはラベリングを継続して次のルール改善サイクルに入るといったアプローチを検討しています。改善サイクルを回し続けることが、プロンプトの精度を高める近道だと考えています。 LayerX バクラク事業部QAでは、こうした試行錯誤を一緒に楽しみながら品質に向き合える仲間を募集しています。興味のある方はぜひエントリーください。 【バクラク】QAエンジニア_ポテンシャル枠 / 株式会社LayerX 【バクラク】QAエンジニア / 株式会社LayerX 【バクラク】シニアQAエンジニア / 株式会社LayerX また、カジュアル面談も行っていますので、興味のある方是非お話ししましょう！ jobs.layerx.co.jp
- LLM
- プロンプトエンジニアリング
- 品質
- 自動化
AI時代の新規プロダクト立ち上げ 〜バクラク給与の開発で見えたこと〜
こんにちは。バクラク給与の開発を担当しているakahaneです。 新規プロダクトとしてバクラク給与を立ち上げ、2026年3月にリリースしました。その開発の進め方について振り返ります。 はじめに バクラク給与の立ち上げでは、Claude CodeやCodexなどのコーディングエージェントを積極的に活用しました。 ただし、これは「AIにコードを書かせたら速かった」という話ではありません。 給与計算は、間違いが許されない領域です。計算結果が1円ズレれば、それは従業員の生活に直結する。「それっぽく動くコード」が最も危険な領域とも言えます。 一方で、新規プロダクトの立ち上げは変化の連続です。仕様も設計もプロダクトの形も日々変わる。このフェーズでは、試作・修正・検証のサイクルをどれだけ速く回せるかが勝負になります。 「間違えてはいけない」と「速く試行錯誤したい」。この一見矛盾する要求の中で、コーディングエージェント時代の新規プロダクト立ち上げが実際どのように進んだのかを紹介します。 フィードバックループを「翌スプリント」から「翌日」に変えた 新規プロダクトの立ち上げでは、最初から正解の仕様・設計は存在しません。 バクラク給与でも、初期は「まず動くものを作る」「実際に触れる形にする」「チームやドメインエキスパートと議論できる材料を作る」ことが最優先でした。仮で作った画面を翌日に作り直す。一度決めたデータ構造を、ドメイン理解が進んだことでゼロから見直す。そうしたことが日常的に起きていました。 ここでコーディングエージェントが大きく効きました。 たとえば、ある日の仕様検討会で「この画面の構成を変えるべき」というフィードバックがありました。一見すると画面上の表示変更に見えますが、実際にはAPIのレスポンス構造やフロントの表示ロジックにも影響するほどの変更です。以前なら次のスプリントに回していたような規模感ですが、コーディングエージェントを使うことで、その日のうちに方針を整理し、翌日にはチームにデモできる状態にできました。 こうしたサイクルは、この一度きりではありませんでした。 立ち上げ期には、毎日のように仕様検討会やレビュー会を実施していました。顧客ヒアリングで得たフィードバックも、翌日の別の顧客のヒアリングで意見を伺う。そこでまた反応を見て改善する。そういう短いループを日々回していました。 実装速度が上がることで、チームや顧客との対話の頻度も上がる。仮説を早く形にし、早くぶつけ、早く直す。結果として、プロダクトの解像度を上げるスピードが変わりました。 ただし、速く作れることは、何でも作ってよいという意味ではありません。作るコストが下がったからこそ、「本当に作るべきか」「使われ続けるものか」「将来の開発速度を落とさないか」を、以前よりも強く意識する必要がありました。新規プロダクトにおいては、作らない判断やシンプルに保つ判断も、同じくらい重要です。 note.layerx.co.jp 実務の温度感は、コーディングエージェントには判断できない 給与計算領域では、AIにいきなり実装を依頼してもうまくいきませんでした。 コーディングエージェントに聞けば、給与ドメインに関する一般的な情報はある程度得られます。所得税の計算方法、社会保険料の算出ロジック、基本的な用語の説明。しかし、それだけでは足りません。 実際の日々の業務で、その作業がどのくらい大変なのか。労務担当者がどの部分を特に慎重に確認しているのか。間違えたときにどのくらい影響が大きいのか。なぜ一見面倒に見える確認ステップが必要なのか。こうした現場の温度感は、コーディングエージェントには持ちようがありません。 たとえば、社会保険料の控除ひとつとっても、法令上のルールだけを見れば「翌月徴収」で「端数処理は五捨五超入（50銭以下切り捨て、50銭超切り上げ）」とシンプルに見えます。しかし実務では、慣習的に当月徴収を採用している企業や、法令とは異なる端数処理を用いている企業が少なくありません。こうした現場ごとの運用実態は、法令の条文やインターネット上の情報だけでは把握できず、コーディングエージェントに聞いても出てきません。 また、給与計算そのものだけでなく、計算後のチェックをどう行うかも重要でした。労務担当者は計算結果をただ眺めるのではなく、前月との差分を見て異常値を探す、特定の項目を重点的に確認する、といった独自のチェックフローを持っています。どの画面で何を見れば安心して確定ボタンを押せるのか。こうした確認プロセスは法令に書かれているものではなく、ドメインエキスパートとの議論を通じて初めて見えてきた部分でした。 そのため、AIに実装を任せる前に、労務ドメインエキスパートと一緒に仕様を言語化するプロセスが不可欠でした。そして言語化した仕様をもとに議論を重ね、重要度の濃淡を設計判断に落とし込むこと。それがプロダクトの土台になりました。 note.layerx.co.jp 給与計算ロジックの中心は、あえて人間が書いた 給与計算ロジックの中心部分は、コーディングエージェントの利用をあえて控え、人間が中心となって実装しました。 理由は明確で、この領域ではAIが「それっぽいコード」を書けてしまうこと自体がリスクだからです。 給与計算では、単に数式を書けばよいわけではありません。支給、控除、勤怠、締め日、支給日、月途中入社・退職、休職、端数処理。さまざまな条件が絡む。さらに、「計算結果が合っている」だけでなく、「なぜその金額になったのか」を説明できることも求められます。 コーディングエージェントに正しく実装させようとすると、業務上の前提、計算の意図、例外条件、端数処理、保存すべき計算根拠、将来の拡張可能性を、すべて正確に言語化して渡す必要がある。そして、出てきた実装が正しいかをレビューするには、結局人間がロジックを同じレベルで理解していなければなりません。 であれば、そのコンテキストを作る時間とレビューの時間を考えると、人間が自分で書いたほうが早く、確実でした。 AIが生成するコードの怖さは、エラーになる、動作しないことではなく、それっぽく動作してしまうことにあります。画面上も問題なく見える。しかし、特定の条件で1円ズレている。給与計算では、こうした「動くが正しくない」コードが最も発見しにくく、最もダメージが大きいリスクになります。 テストケースの洗い出しでは、AIが強力なレビュアーになった 一方で、テストケースの作成にはAIを大いに活用しました。 計算ロジックでは、正常系だけでなく、境界値や例外パターンをどれだけ洗い出せるかが品質を左右します。人間だけで考えていると、自分が実装した前提に引っ張られて、どうしても見落としが出る。 そこで、実装したロジックや仕様メモをAIに渡し、「この仕様に対して、漏れやすい境界値や異常系を洗い出して」と依頼しました。「テストコードを書いて」ではなく、テスト観点の網羅性を問う使い方です。 たとえば、月途中入社・退職のテストケースでは、人間が考えた「月初入社」「月末退職」「月途中入社」に対して、AIは「入社日と退職日が同月」「締め日をまたぐ入社」「支給日前日の退職」「休日に重なる場合」といった観点を追加で出してきました。すべてが有効なケースではありませんでしたが、ドメイン上検討すべき観点として有用なものが多くありました。 AIにテスト観点を出させ、人間がドメイン上正しいかを確認し、必要なケースをテストコードに落とし込む。この進め方により、給与計算ロジック周辺でカバレッジ90%以上を達成できました。 AIは実装者としてだけでなく、「自分たちが見落としている観点はないか」を問うレビュアーとして有効でした。 ボトルネックは「コードを書く」から「何を作るか決める」に移った コーディングエージェントを使うことで、実装速度は確実に上がりました。しかし、実装が速くなると、ボトルネックは別の場所に移ります。 以前は「考えたことを形にする」のに時間がかかっていました。今は、形にすること自体は速い。すると、「何を形にすべきか」を決める部分が律速になる。 何を作るべきか。何を作らないか。仕様の曖昧さをどう解消するか。ドメイン上の正しさをどう判断するか。AIが出したコードをどう評価するか。 コードを書く時間は確かに減りました。しかし、それは「よいコンテキストを作る」「AIに適切に依頼する」「出てきたものを評価する」「ドメイン上正しいかを判断する」という時間に置き換わっています。 言い換えると、コーディングエージェントはエンジニアの仕事をなくすのではなく、エンジニアの仕事の重心を変える。手を動かす比重が減り、判断する比重が増える。新規プロダクトの立ち上げでは、この変化の意味は大きいと感じました。 特に重要なのは、実装の前段にある「何を、なぜ、どう作るか」を整理する力です。ドメインエキスパートとの議論を設計に落とす力、仕様の曖昧さを言語化する力、AIが正しく動けるだけの精度で要件を整理する力。コーディングエージェントが強力になるほど、この上流の質がプロダクトの質を決めるようになります。 まとめ 「間違えてはいけない」と「速く試行錯誤したい」。この二つの要求に対して、バクラク給与の立ち上げでたどり着いた答えはシンプルでした。速く回すべきところはコーディングエージェントで速く回し、間違えてはいけないところは人間が責任を持つ。 結果として、バクラク給与は当初のリリース予定より2ヶ月前倒しでリリースすることができました。これはコーディングエージェントの力だけで実現したものではありません。ドメインエキスパートとの仕様言語化、顧客との高速なフィードバックループ、人間が主導した計算ロジックの実装。それらすべてが噛み合った結果です。 実装が速くなった分、エンジニアの仕事の重心は「コードを書く」から「何を作るかを決め、正しさを判断する」に移っています。バクラク給与の新規プロダクト立ち上げではこの変化がより鮮明に見えました。 LayerXの「すべての経済活動を、デジタル化する。」というミッションに共感いただける方、技術の力で社会課題解決に貢献したい方は、ぜひ以下からご応募ください！ jobs.layerx.co.jp
- 生成AI
- プロダクト開発
- LLM
人からAIへのフィードバックデザインパターン
こんにちは。バクラク事業部で機械学習エンジニアをしている伊藤（@sbrf248）です。最近はオンライン上で日々流れてくる情報が膨大なので、頭の整理のため紙とペンをよく使うようになりました。GWには（手の届く範囲で）少し高価なボールペンを買ってみました。 さて、近頃はAI・LLMを組み込んだプロダクトやシステムが当たり前になってきています。 私の携わる「バクラク」でも様々なAIエージェントをプロダクトに組み込み、あらゆるバックオフィス業務の自動化を進めています。 bakuraku.jp AI・LLMを組み込む場合、最初に作ったものがそのまま完成ということはあまりなく、継続的な性能の改善が求められるケースが多くあります。特に、ユーザーごとに体験を最適化するパーソナライズされたシステムの場合は、ユーザーのフィードバックをいかにして収集し活用するかが重要です。 日々重要性が高まってきている「ユーザーのフィードバックをいかにして収集し活用するか」について、先日開催されていたHuman-Computer Interactionの学会であるCHI（CHI2026, CHI2025）の論文を中心に事例を調査してみました。このブログでは、調査した研究事例やポイントを紹介します。 全体像 LLMに限らず、機械学習モデル等を組み込むAIシステムは多々ありますが、ここではLLMを中心に考えます。LLMを組み込んだシステムは、大まかには次のような構成になると思います。 流れとしては、何らかの出力に対してユーザーからのフィードバックがシステムに与えられると、それを使ってシステムの一部が更新され、結果的に出力に反映されます。 更新する対象は、大まかに3種類に分けられます。 モデル自体 プロンプト その他（入力データや前処理、LLMの出力のフィルタ処理など） LLM本体を自前でservingするのは運用コストが大きいため、OpenAIなどのプロバイダが提供するAPIを利用するのが一般的だと思います。また、フィードバックを反映するコストを踏まえると、多くのケースで更新対象はプロンプトやその他の部分になるでしょう。 ここからは、「ユーザーから何らかの形式で与えられたフィードバックをプロンプトやその他の部分に反映し、システムの出力を改善する」問題についての研究事例を見ていきます。 研究事例 Feedback by Design: Understanding and Overcoming User Feedback Barriers in Conversational Agents [1] この論文では、会話エージェントにおけるユーザーのフィードバックの品質について調査しています。 会話エージェントはチャットを使ってAIとやりとりするプロダクトで、代表的なものにChatGPTやClaude Codeなどが挙げられます。ここで、ユーザーのフィードバックは「自然言語」として与えられます。つまり、「〜〜みたいに修正して」のような文章を入力してシステムに送信することで、それがプロンプトなどの形式でLLMに渡され、出力が更新されます。 この論文の著者は、会話エージェントのフィードバックは低頻度・低品質になりやすいと指摘しています。理由は大きく4つ挙げられています。 AIの出力が文脈・目的からずれていく: 会話エージェントが元々あったゴールを維持できず、制約を無視したり別の方向に進んだりした結果、ユーザーが「追加で説明しても直らない」と判断してしまう。 出力を検証するコストが高い: 出力にハルシネーションや存在しない引用があると、ユーザーはまず文章自体の正しさを確認しなければならず、負荷が重くなる。 モデルが曖昧さを確認しないため、ユーザーだけが説明責任を負う: ユーザーの指摘が曖昧でも、モデルが確認質問をせず修正を入れてしまうことがある。そのためユーザーは「何を・どの粒度で・どう直すべきか」を自分で言語化し続ける必要がある。 どの程度の情報を与えればよいかわからない: モデルが重要な点を落としたり、逆に不要な変更を加えたりする。それら1つ1つに対するフィードバックが難しく、「try again」のような最小限の指示になってしまう。 要するに、どこをどう直せばいいのかユーザーにとってわかりづらい状況で、かつ自由形式の入力欄だけが与えられていると、今の出力をより良くするためにどうフィードバックすればいいかをユーザーが考えて言語化する必要があります。これは負荷が大きく、結果として短く曖昧な修正やセッションのリセットなどに退避してしまうため、品質の低下やそもそもフィードバック自体を避けてしまう結果につながってしまいます。 これを踏まえて、論文では出力の一部をハイライトして「この部分が違う」と指摘できるようにする、修正前後の差分を見せる、AIがどのようにフィードバックを解釈したかを明示する、Undo/Redoを用意する、といったインターフェース設計を考案・検証し、体験の改善を確認しています。 この研究から、ユーザーの操作にある程度の型を用意し、その中で試行錯誤しやすい状況を作り出すことで、高品質なフィードバックが期待できるようになると示唆されます。 End User Authoring of Personalized Content Classification [2] この論文では、ユーザーが自身の好みに合わせてYouTubeコメントの分類器を作るというタスクについて、3つのフィードバック方式を実験的に比較しています。 Label System: サンプルとなるコメントが与えられるので、それを分類器の学習に使うかどうかを選択する。分類器は簡単なMLベースのモデルを利用する。 [2] より引用 Rule System: 用意されたインターフェースを使い、コンテンツを分類するルールを作成する。 [2] より引用 Prompt System: LLM分類器のプロンプトを調整（文章の修正やfew-shot exampleの変更）する。 [2] より引用 結果としては、Prompt Systemが最も早く高精度の分類器を作成できました。一方で、参加者はLabel SystemやRule Systemの方が、やることが明確で使いやすいと感じたようです。またRule Systemについては、特定の語句やイベントに基づくフィルタリングという観点では高い精度を出していたようです。 この結果を踏まえて著者は、それぞれのメリットを活かすハイブリッドな手法が適切ではないかと述べています。例えば、少数のLabel Exampleからプロンプトを生成したり、Rule SystemとPrompt Systemを併用した手法などが挙げられています。 この研究からも、プロンプトをユーザーが直接編集するよりは、操作にある程度の制約を設けつつ、ユーザーが迷わない形でフィードバックを送れる設計が良い選択肢となり得ることがわかります。 Promptimizer: User-Led Prompt Optimization for Personal Content Classification [3] この論文は、ユーザーに様々な形態のフィードバック方式を提供しつつ、コンテンツ分類器のプロンプトを改善する手法を提案しています。 [3] より引用 具体的には、ユーザーは初期説明の記述、誤分類された例へのラベル付け、失敗パターンの優先付けなど、複数の粒度のフィードバックを段階的に与えることができます。重要なのは、最終的に出来上がるプロンプトがユーザーにとって読める・解釈可能な形で残ることです。完全自動の最適化だと、内部でプロンプトがどんどんブラックボックス化していき、ユーザーがよくわからないままプロンプトが更新されていく状況に陥ってしまう場合があります。 論文中の実験では、ユーザーは完全自動のプロンプト最適化よりもPromptimizerの方式（人間が途中に介入できる形）を有意に好むという結果が示されています。また、YouTubeのコメント管理ツールへの組み込み実験では、3週間の実利用を通じて、ユーザーがそれぞれの目的に合った多様なフィルタを作り、運用できることが確認されています。 この研究からは、自動最適化を導入する場合でも、ユーザーが過程に関与できる余地と、結果を解釈できる出力を残すことが重要だとわかります。 Preference-Guided Prompt Optimization for Text-to-Image Generation [4] この論文も同様にプロンプト最適化の手法ですが、ユーザーは2つの選択肢からより良いものを選ぶだけというかなり限定的なフィードバック方式です。 [4] より引用 対象タスクはtext-to-imageの画像生成で、ユーザーが画像生成のプロンプトを直接書いて調整するのは負担が大きいという課題に取り組んでいます。画像生成は出力が予測しにくく、頭の中のイメージを文章に落とし込むこと自体が難しい一方で、「2つ並べたらどちらが好みか」は比較的簡単に判断できます。この性質を利用して、ユーザーには2択選好だけを返してもらい、システム側がプロンプトを自動的に更新していきます。 提案手法の特徴は、ユーザーのフィードバックを使って探索方向を狭めていく（exploit）一方で、適度に新しい方向も試す（explore）バランスを取っている点です。選好フィードバックだけでは、初期の好みに引きずられて局所最適に陥りやすいので、このバランスは実用上重要です。実験では、手動でプロンプトを書き換える場合に比べて少ない反復回数・低い認知負荷で満足のいく結果に到達できることが示されています。 ここから言えるのは、「ユーザーに言語化させずに済むフィードバック方式」も有力な選択肢になるということです。タスクによっては、自由記述や明示的なルール記述よりも、選好比較の方がユーザーの認知負荷が小さく、フィードバックを継続的に集めやすくなります。 Data-Prompt Co-Evolution: Growing Test Sets to Refine LLM Behavior [5] この論文は、フィードバックループの中でプロンプトの更新とそれを検証するテストデータの更新を同時に行う手法を提案しています。 [5] より引用 ここで扱っているのは、「プロンプトを直してもそれが過去にうまく動いていたケースを壊していないかわからない」という問題です。 従来の機械学習開発でもありましたが、テストデータを十分に整備せずプロンプトエンジニアリングを進めると、今注目しているサンプルの精度は改善したものの、実は過去問題なかったサンプルの精度が悪化する、といった問題に直面する可能性があります。 論文は、この問題に対して、テストデータとプロンプト指示を一緒に育てていくワークフローを提案しています。具体的には、ユーザーが運用中に見つけたエッジケースをテストセットに追加し、なぜその挙動が望ましいのか・望ましくないのかという根拠を明文化し、修正したプロンプトを成長したテストセットに対して評価する、というループを回します。 この研究の重要な視点は、ユーザーからのフィードバックを「単発の修正要求」で終わらせず、「テストケース＋期待挙動＋根拠」というセットで保存していくところにあります。こうしておくと、後からプロンプトを変更した際にも回帰的に検証でき、改善の積み上げが効きやすくなります。 まとめ ここまで、人間からAIへのフィードバック方式を、研究事例をふまえて紹介しました。個人的には、適切な制約を加えることで、自由記述形式よりもユーザーが使いやすく、かつ高品質なフィードバックが実現できる事例が見られたのが印象的でした。 もちろん前提として、考えているタスクの性質やシステムへの組み込み方によって、最適なフィードバック体験は異なります。その上で、（当たり前のことではありますが、）ユーザーが迷わずにフィードバックでき、それが出力の改善に納得できる形で結びつくような一連の体験を目指すべき、ということは一貫していると感じます。 LLMの表現力が高まっているからこそ、プロダクトを作って提供するだけでなく、使っていただくユーザーと共にプロダクトを磨き込めるような体験を目指していきたいと思います。 最後になりましたが、LayerXではAI・機械学習に携わるエンジニアを募集中です。ユーザー価値を第一に考えたAIエージェントの社会実装に興味のある方は、ぜひご応募ください！ open.talentio.com <a href="https://jobs.layerx.co.jp/opend
- 生成AI
- LLM
- UIデザイン
- UX
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
- 機械学習
- 強化学習
社内AIヘルプデスク「精度80%の壁」を突破-ナレッジ管理ツール開発の意思決定
1. はじめに こんにちは！IT戦略部の森嶋です。 先日、当社では 「DeNA × AI Day 2026」 が開催され、そこで「AI Workspace」プロジェクトについての発表をしました。 社内AIヘルプデスク「Findout」は技術的な最適化を積み重ね、回答精度は当初の44%から80%へと劇的に改善しましたが 、そこから先、どうしても80%を超えられない「壁」に直面しました。この壁の正体を分析すると、原因の70%が「ドキュメント（=ナレッジ）不足」という、RAGチューニングだけでは解決できない事実に行き着きました 。 もちろん、AI に「解決策」を提示させること自体は簡単です。しかし、AI が描く理想論をすべて受け入れることは、リソースの限られた現場では現実的ではありません。
- AI
- RAG
- LLM
セキュリティ分析AIエージェント実装にみるハーネスエンジニアリング
先日、zennの記事にて紹介したセキュリティアラートに関する分析を担うAIエージェント Warren のハーネスエンジニアリングについて社内で共有したところ、思いの外盛り上がったので記事にしてみました。一般的な生成AIエージェントの話だけでなくセキュリティ分析に特化した話も織り交ぜていますが、何かのご参考になれば幸いです。 今回対象となるWarrenは各サービス・監視装置から受け取ったアラートを分析するための生成AIエージェントになります 前提：ハーネスエンジニアリングとは 一般的な定義 ハーネスエンジニアリングという言葉は、2026年2月のMitchell Hashimoto...
- 生成AI
- AIエージェント
- セキュリティ
- BigQuery
- LLM
人手のリサーチをデータパイプラインに。dbt Python model × LLM Web Searchで公開情報をSnowflakeに載せるまで
LayerX BizOps 部データグループのさえない (@saeeeeru) です。最近は娘と『名探偵プリキュア！』にハマっています。「自分で見て、感じて、考えて、"本当"の答えを出す」。AI 時代だからこそ刺さるメッセージです（推理パートをちゃんと解けるようになりたい）。 前回の記事では、dbt Python model から外部 API を呼び出す実装パターンを紹介しました。今回はその応用として、LLM の Web Search 機能を使って公開情報を取得し、それをデータパイプラインに組み込む実践例を書きます。 この記事では、まず LLM の Web Search 機能をどう使うとデータパイプラインに載せやすい形になるのか を説明し、そのうえで Snowflake / dbt にどう載せたのか、そして本番運用の中でどんな品質課題が見えてきたのか、という順に整理します。 Web Search を Snowflake / dbt のパイプライン設計にどう載せるか この記事の技術が必要になった背景には、分析基盤である Snowflake にない外部の公開情報を継続的に取り込みたい、というモチベーションがありました。たとえば、既存の属性情報だけでは判断材料が不足し、企業サイトやニュースリリースのような一次情報を補助的に参照したくなるケースがあります。 こうした情報を毎回人手で見に行く運用は継続しづらい一方で、自然言語のまま取得しても構造化データではないためデータ処理対象として扱いづらいです。この章では、外部 Web 上の公開情報をどう取得し、どうすれば Snowflake / dbt のパイプラインで扱える形にできるか を説明します。 外部 Web Search の実装パターン 外部の公開情報を取得する手段として、まず古典的なスクレイピングがあります。しかし、企業サイト・ニュースリリース・メディア記事など多様なソースの Web ページを対象にする場合、サイトごとにパーサーを書いて構造化するのは現実的ではありません。取得したい情報が「資金調達をしたか」「事業内容は何か」といった、自然言語の意味を解釈したうえでの抽出である以上、LLM を介する必要がありました。 LLM を使って外部の公開情報を取得・構造化する場合、実装パターンは大きく 2 つあります。 検索 API と LLM API を分けるパターン : 検索と要約・抽出を別々の API で組み合わせる Web Search を内包した LLM API を使うパターン : 検索と応答生成を 1 つの API でまとめて扱う 今回の設計では、検索から構造化までを LLM に任せて実装と運用をシンプルに保ちたかったため、後者の Web Search を内包した LLM API を採用しました。具体的には Azure OpenAI の Responses API + web_search_preview を使っています。 ただ、LLM の応答を自然文のまま返させるだけでは後続のデータ処理につなぎにくいため、Responses API の応答は JSON として返させるよう設計しました。Snowflake 上ではまず半構造化データとして保持し、必要な情報を後段で扱いやすい形に整えていきます。次の節では、「何を抽出し、どの粒度で持つか」という出力スキーマの設計を説明します。 スキーマ設計の重要性 スキーマの具体的な定義はユースケースによって異なりますが、重要なのは以下の 2 つの補助情報を含めることです。 Web Search を使っても誤りは残るため、重要なのは「誤りをなくすこと」よりも、「後から確認ができる情報を残すこと」だと考えています。 confidence: high / medium / low の 3 段階で、モデル自身の確信度を自己申告させる evidence: 出典 URL と該当箇所のスニペットを配列で返させる これにより、利用者が情報を鵜呑みにせず、「根拠を確認してから判断する」運用を組み込みやすくなります。confidence はあくまで自己申告であり、evidence も正しさそのものを保証するわけではありませんが、少なくとも確認を始める手がかりは残せます。 ここまでが、「Web Search をどう実装し、データパイプラインに載せるにはどんな出力スキーマが必要か」という話です。続いて、その処理を Snowflake / dbt の中でどう実装・運用したかを見ていきます。 なぜ dbt Python model で LLM API を呼び出す構成にしたのか 今回の本番構成では、dbt Python model から LLM API を呼び出す形を採用しました。 正直なところ、一番大きかったのは、Snowflake / dbt の既存パターンの延長として、データエンジニアが実装・運用しやすかったことがあります。 LayerX のデータ基盤では、各種 SaaS API を呼び出す dbt Python model の実装がすでに多数あります（前回の記事で紹介したパターン）。そのため、LLM API の呼び出しも同じパターンに載せるのが自然でした。 全体像は次の通りです。 graph TD subgraph Snowflake MASTER["マスターデータ"] subgraph dbt["dbt レイヤー構成"] PY["dbt Python model<br/>対象レコードの抽出 / API 呼び出し / JSON 格納"] LND["landing<br/>取得直後の RAW_JSON"] SRC["src<br/>不正データ除外 / 取得手段の隠蔽"] DWH["dwh<br/>再利用を意識した再構成"] MART["mart<br/>用途特化の利用データ"] end end subgraph RESP["Responses API"] API["Web Search<br/>+ JSON 応答"] end MASTER --> PY PY -- "Snowflake から<br/>外部 API へ接続" --> API API -- "JSON 応答" --> PY PY --> LND LND --> SRC --> DWH --> MART MASTER -.-> DWH MASTER -.-> MART ここでいうデータのレイヤーは、社内では大きく landing、src、dwh、mart に分かれています。役割としては、landing は取得直後のデータを保持する層、src は取得手段を隠蔽しつつほぼ生データとして扱いやすくする層、dwh は再利用を意識して再構成する層、mart は用途特化で利用する層です。今回の記事で主に扱うのは、landing -> src までです。 このように、dbt に載せておくと、Snowflake 上の既存データを参照しながら、Responses API の呼び出し対象を絞り込めます。これはコストを抑えるのに効くため、後述する Incremental 戦略の前提になります。それに加えて、 Snowflake 上の他のユースケースにも展開しやすいという見通しもありました。 実装: dbt Python model × LLM API （Web Search） dbt Python model の実装 この節では dbt Python model 側の実装を紹介しますが、Snowflake に寄った実装詳細になっています。 コードのポイントを先に整理しておきます。 並列実行: Responses API は 1 リクエストあたり 10〜30 秒かかるため、ThreadPoolExecutor(max_workers=10) で並列化しています。10 は Snowflake 上での実行負荷と API 側の待ち時間を見ながら調整した値です Incremental: dbt.is_incremental + leftanti join で、直近 N 日以内に処理済みのレコードをスキップします。N の値は取得対象の情報の更新頻度を意識して設計します リトライ: JSON パースエラーと API エラー（429 等）を Exponential backoff で共通処理しています Note: 認証情報は Snowflake の Generic Secret + External Access Integration で管理しています。また、 dbt.ref() と dbt.is_incremental は、どちらも dbt が組み込みで用意している参照・条件分岐のための機能です # landing レイヤー : dbt Python model の疑似コード import json import logging import time from concurrent.futures import ThreadPoolExecutor, as_completed from datetime import datetime, timezone import _snowflake import pandas as pd import requests from snowflake.snowpark import Session from snowflake.snowpark.functions import col # ユースケースに応じた JSON Schema を定義 # 構造化出力オプションに渡し、出力形式を一定範囲で制約する OUTPUT_SCHEMA = { "type": "json_schema", "json_schema": { "name": "web_search_result", "strict": True, "schema": { # ... ユースケースに応じたスキーマ定義 ... }, }, } SYSTEM_PROMPT = "ここにプロンプトを入れる" MAX_WORKERS = 10 MAX_RETRIES = 3 BACKOFF_BASE_SECONDS = 1 SKIP_DAYS = 30 def build_payload(input_text: str) -> dict: return { "input": input_text, "instructions": SYSTEM_PROMPT, "tools": [{"type": "web_search_preview"}], "text": {"format": OUTPUT_SCHEMA}, } def extract_output_text(response_json: dict): """ Responses API のレスポンスから JSON 文字列を取り出す。 実際のレスポンス構造は SDK / API バージョンに合わせて実装する。 """ for item in response_json.get("output", []): if item.get("type") != "message": continue for content in item.get("content", []): if content.get("text"): return content["text"] return None def call_llm_api(input_text: str, api_key: str, endpoint: str, deployment: str) -> dict: """1 件分の Web 検索 + 構造化出力を取得する。""" # 実際の URL 形式は利用中の API に合わせて組み立てる url = f"{endpoint}/openai/deployments/{deployment}/responses" head
- dbt
- Snowflake
- Python
- LLM
- データ基盤
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
- 自動化
LLM as a Judgeで生成物の品質を担保する
こんにちは、エムスリー AI・機械学習チームの氏家（@mowmow1259）です。 この記事はAI・機械学習チームブログリレーの10日目の記事です。9日目は苅野さんによる「Claude Code と進める Ingress から Gateway への移行」でした。 移行をゴリゴリ進めていただいている苅野さんによる解説記事です！ www.m3tech.blog 私は福岡に住んでいるんですが、最近同僚と大濠公園でお花見BBQをしてきました。 お花見と言いつつ桜はまだ咲いていなかったのでただBBQをしただけになりました。 お花見シーズンに限らず、大濠公園は落ち着いて過ごせるいいところなので福岡に来た際にはぜひ立ち寄ってみてください。 桜が咲き掛けの大濠公園 さて、生成AIの台頭により、画像・テキスト・コードとあらゆるコンテンツ生成が飛躍的に容易になりました。 エムスリーでも業務効率化だけでなく、生成AIの各種プロダクトへの組み込みを積極的に推進しています。 一方で、生成物を直接利用する場合には、低品質な生成物はユーザー体験の悪化や意図しない情報漏洩にも繋がるため、品質担保は避けて通れない課題です。 本記事では、LLMによる生成物をプロダクトに組み込む際の品質担保戦略として、エムスリーで実践しているLLM-as-a-Judgeを中心としたアプローチを紹介します。 なお、本記事は先月福岡で行われたPythonのコミュニティイベント Python Meetup Fukuoka #6 *1での登壇内容です。 ご興味がある方はぜひ登壇資料もご覧ください。 LLM as a Judgeとは 基本的な考え方 LLM-as-a-Judgeに潜むバイアス バイアスを考慮した評価 ① 評価観点の明確化 ② 複数モデルでのバリデーション ③ 人間による生成との対決（ペアワイズ法） ④ 評価理由やリファレンスを生成させる ⑤ 人手評価によりプロンプトをチューニング ⑥ プロンプトのチューニングもLLMにやらせる LLMの評価をプロダクトの一部としてとらえる まとめ We are Hiring! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ エンジニア新卒採用サイト！ LLM as a Judgeとは 基本的な考え方 LLM-as-a-Judge とは、生成AI（LLM）自身に評価をさせるアプローチです。 近年ではレビュー論文*2も公開されるなど活発に議論されている分野です。 例えば、このブログについて、5点満点で評価してくださいのような形でプロンプトを作り、LLMの出力を直接評価に使います。 出された評価でフィルタリングをしてもいいですし、評価を元に改善のサイクルを回すこともできます。 人手による評価と比較して圧倒的にスケールするのが最大の利点です。 LLM-as-a-Judgeに潜むバイアス ただし、先ほどの例のように素直に評価させても多くの場合うまくいきません。 LLMの生成にバイアスやハルシネーションがあるように、LLMを評価に用いる際にもさまざまなバイアスは避けて通れません。 例えば代表的なバイアスとして次のものがあります。 Position Bias: 複数選択肢のうち最初のものを高く評価しがち Length Bias: 長く冗長な文章ほど高く評価しがち Self Enhancement Bias: 自身が生成した出力を高く評価しがち これらのバイアスを踏まえた上で「どうやってLLMに公正・妥当な評価をさせるか」がLLM as a Judgeの研究分野であり実用上の肝になります。 バイアスを考慮した評価 では、どのようにしてバイアスを排除しながら評価させたら良いのでしょうか。 ここでは例として、プログラミングクイズを出題するプロダクトのために、LLMでクイズを生成したとします。 問題: 次のデータ型のうち、一度作成すると中身を変更できない（イミュータブルな）ものはどれ？ A. リスト (list) B. 辞書 (dict) C. タプル (tuple) D. セット (set) 当然答えはCです。 ここからはこのクイズに対して適切に評価させる方法を紹介していきます。 ① 評価観点の明確化 「いい評価をしてください」という曖昧な指示では一貫性のある評価になりません。 まずは、何の観点で、どういう基準で評価するかを明示することが重要です。 次のPythonクイズを次の4つの観点から、5点満点（1〜5）で評価し、総合評価を同じく5点満点で評価してください。 評価項目： - 有用性: 実務や学習の初期段階で、知らなければ困る重要な知識か。 - 選択肢の罠: 誤答の選択肢に「他言語の癖」や「直感的な勘違い」を誘う説得力があるか。 - 意外性: 正解や解説を聞いたときに「なるほど！」という驚きや納得感を得られるか。 - 汎用性: その問題の答えが他の文法やライブラリの理解にも繋がる根本的なルールか。 評価観点を明示することで評価軸やスケールが揃い、妥当な評価になりやすくなります。 冒頭のクイズだと選択肢の罠の観点でGeminiに3をつけられてしまいました。 ここから、setの代わりにdataclassを選択肢に入れるなどの改善が考えられます（その場合Geminiの評価は5に上がります）。 ② 複数モデルでのバリデーション コストとの兼ね合いになりますが、単一モデルの評価はそのモデルのバイアスをそのまま反映してしまいます。 Gemini、GPT、Claude Sonnetなど異なるLLMに同じプロンプトで評価させ、複数の評価結果を統合することで、self enhancement biasを考慮したより頑健な評価が得られます。 モデルA: 5点 モデルB: 2点 → 平均: 2.7点 モデルC: 1点 また、スコアのばらつき自体も「評価が難しい問題かどうか」の指標になります。 ③ 人間による生成との対決（ペアワイズ法） ここまでは絶対評価を前提に紹介しましたが、絶対評価だけでなく相対評価も品質担保に有効です。 生成物と人間が作ったコンテンツを並べて比較させ、相対的に品質の高いクイズかを評価できます。 次の2つはPythonに関するクイズです。どちらがよりソフトウェアエンジニアが監修した クイズとして質が高いでしょうか。 クイズA: XXXXX クイズB: YYYYY Position Biasへの対策として、クイズAとBの順番を入れ替えたパターンを実施するのもよいでしょう。 ④ 評価理由やリファレンスを生成させる スコアだけでなく評価理由も生成させることで、CoTの文脈で評価精度の向上が期待できますし、人手で後から確認する際の効率も上がります。 ... ただし、評価は次の形式で理由も含めて出力してください。 修正や批判を行う場合はそれが正しいと主張できる箇所を原文から抽出して併記してください。 { "has_issues": true/false, "issues": [ { "category": "有用性" | "意外性" | "汎用性", "description": "具体的な問題点の詳細説明", "severity": "high" | "medium" | "low", "details": "カテゴリ分析結果や具体的な指摘内容" } ] } 根拠を原文から抽出させる指示を加えることで、ハルシネーションのチェックの効率も上がります。 ⑤ 人手評価によりプロンプトをチューニング ここまで評価のためのTipsを紹介してきましたが、一発で実用に足る評価プロンプトを作ることは困難です。 解いている問題のドメインや難易度によってプロンプトの調整は必須だと思っています。 そのため、従来の機械学習と同様に人手評価 → プロンプト改善のサイクルを回すことが重要です。 プロンプトv1で評価 → 人手評価と比較 → ずれを修正したプロンプトv2を作成 「LLMが3点と評価したが人間は5点と評価した」というようなずれを収集し、そのずれのパターンに基づいてプロンプトを改善していきます。 ⑥ プロンプトのチューニングもLLMにやらせる 人手評価を進めていく中で、プロンプトの修正案作成自体もLLMに任せるのもよく行っている方法です。 [正解例] 問題: XXXXX 人手評価: 5点、理由: 〇〇 LLM評価: 2点、理由: △△ → このずれを修正するプロンプトv2の改善案を生成してください 人手アノテーションのコストを抑えつつ、評価プロンプトの品質を継続的に向上させられます。 LLMの評価をプロダクトの一部としてとらえる LLMによりいかにバイアスを排除した評価を実施しても、ドメインやプロダクトの特徴によっては生成物をそのまま利用することが難しい場合ももちろん多くあります。 LLMが高評価したから大丈夫だ、というような使い方ではなく、プロダクトによって適切に道具の一つとして使っていくのが重要です。 例えば、コンテンツを大量生成・評価させた上で人手による評価ができる程度にフィルタリングしたり、LLMによる評価をプロダクトそのものにすることも考えられます。 まとめ LLM-as-a-Judgeを活用した生成物の品質担保戦略を紹介しました。 生成AIをビジネスに組み込む際、「生成できること」と「信頼できる品質で生成できること」の間には大きなギャップがあります。LLM-as-a-Judgeをそのギャップを埋める現実的な手段として、ぜひ活用してみてください。 We are Hiring! エムスリーではエンジニアを絶賛募集しています！ 少しでもご興味をお持ちの方は、ぜひカジュアル面談等にご応募ください！ エンジニア採用ページはこちら jobs.m3.com カジュアル面談もお気軽にどうぞ jobs.m3.com エンジニア新卒採用サイト！ fresh.m3recruit.com *1:LINEヤフーさん、GMOペパボさん、エムスリーの共同開催 *2:Jiawei Gu, et al. (2025). A Survey on LLM-as-a-Judge. arXiv:2411.15594. https://arxiv.org/abs/2411.15594
- 生成AI
- LLM
AIエージェントの成功率をどう引き上げるか。Long-running taskにおけるスケーリング則と検証器の役割
こんにちは！Ai Workforce事業部FDEの恩田（さいぺ）です。 AIエージェントの進化も凄まじく、どんどん長時間のタスクをこなせるようになっています。この分野のベンチマークの第一人者であるMETRでも、最新のClaude Opus 4.6で10時間のタスクが50%の確率で完了できることが示されています（80%だと1時間）。 （出典: https://metr.org/ , 2026/4/7アクセス） とはいえ、長時間に渡るタスクは、ステップ数も膨大です。各ステップの成功確率を上げたり、リトライや失敗の原因を考え、失敗しても復帰できるような仕組みが必要になりそうです。この分野をいくつか読んだので、その中でもおもしろかった論文をピックアップし、紹介します。 100万ステップのタスクをノーミスで解く 最初に紹介するのは2025年11月に公開された Solving a Million-Step LLM Task with Zero Errors (Elliot Meyerson et al.) です。論文のタイトルにもあるように100万ステップもの長さのタスクをLLMで解こうという論文です。これほどステップ数が膨大になると、各ステップの成功確率がほぼ100%でないと、最後まで成功し切ることができません。 そこで、本論文は以下のようなプロセスを考え、スケーリング則を示しています。 （1）最小限にサブタスクへの分解。ただし、適切なサブタスクへの分解は本論文のスコープ外で、個に分解できたタスク列を所与のものとしている （2）サブタスクレベルの投票に基づくエラー訂正 （3）相関エラーを減らすためのレッドフラッグ 特におもしろいのが、セクション3.2「First-to-ahead-by-k Voting and Scaling Laws」です。First-to-ahead-by-k Votingは、1つのステップを複数回実行し、他のどの候補よりも回多くサンプリングされたものを回答とする手法です。 この手法では、各ステップの成功確率について、の場合、このプロセスを通じて正しい候補が選択される確率が計算できます。さらに任意のエラー率 に対して、この投票プロセスが確率で正しい回答をもたらすようなあるが存在することが示せます（つまりを十分小さく取れば、各ステップがほとんど100%と成功するようなが存在する）。 さらに、個のタスクすべてを成功させるために必要ながでスケールするというのがこの論文の一番の見どころです。 導出を簡単に紹介します。まず、以下の定式化、仮定を置きます。 すべてのタスクを完了するために合計ステップが必要 固有のステップあたりの成功率をとする 解析は最悪のケース（確率の正しい候補が確率の単一の代替案と競合する）を仮定 サブタスクをステップに分解可能とする 各サブタスクのアクションを決定するために票の差が必要 このとき、すべてのタスクが成功する確率が計算できます。 （論文より引用） ここで式(10)は、あるサブタスクは個のステップに分解でき、各ステップの成功確率がであることから、全てのステップが成功する確率です。これを図示したのが以下のFigure 3です。100万ステップを高い確率で成功するために、がそこまで大きくならないのは嬉しいですね。 （論文より引用） また、に対するスケーリング則だけでなく、LLMの実行コストも計算できます。 （論文より引用） 特に（サブタスクが個に分解されるので、全個のステップに分解されるワーストケース）でも、以下のようにでスケールします。 （論文より引用） 別の観点として、式(17)は（は単一ステップあたりのLLMのコストなので、は成功するために必要なコストの期待値と見なせる）に対しても線形のオーダーとなっていることもわかります。が最小化されるようなLLMを選択するというのも一つポイントです。 また、を小さくできる点と、コストもで減衰できる点で、単位ステップの成功確率を上げる施策も重要です。この論文では信頼性の低い以下2つの兆候をレッドフラグとして利用することにも言及しています。 （1）過度に長い応答 （2）誤ってフォーマットされた応答 こういった「誤りである確率が著しく高い兆候」を見つけたらリトライしてしまうのもLong-running taskの実装では重要なヒューリスティックになる可能性があります。 検証器に求められる「正誤判定」の質 次に紹介するのは、On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks (Kaya Stechly et al.)です。2024年2月の論文で、検証しているモデルもGPT-4と、現在の最新モデルと性能に大きな差があるので、少し割り引いて結果を解釈する必要があるのですが、内容はとても興味深いです。 先ほどの論文では、各ステップの成功確率を上げるためにFirst-to-ahead-by-k Votingやヒューリスティックな誤り検知を採用していましたが、こちらの論文では、LLMによる自己批判と、信頼できる検証器によるフィードバックでLLMが再考することの効果を検証しています。特に信頼できる検証器とは何なのか、具体例があったほうがわかりやすいので本論文で扱っている3つの題材「Game of 24」、「グラフ彩色」、「STRIPSプランニング」で紹介します。 Game of 24は、4つの数字を括弧と基本的な算術演算（加算、乗算、減算、除算）で組み合わせ、計算結果が24になる式を作る数学パズルです（個人的には車のナンバーを四則演算で10にする問題を暇つぶしでやったりします）。LLMによる自己批判は、提示された式が正しいかをLLMに判断させます。信頼できる検証器は、Pythonで24に等しいかどうかを検証させます。プログラムで計算するだけなので、24に等しいかどうかをbooleanで確実に判定できます。 グラフ彩色問題は、エッジで結ばれた隣接するどの2つの頂点も同じ色にならないように、各頂点にn色のうちの1色を割り当てる問題です。こちらもLLMには同じ色になっていないかを判定させます。信頼できる検証器は、すべてのエッジの色を確認するだけで、Game of 24と同じく機械的な正誤判定が可能です。もし、結ばれている2つの頂点が同じ色であるエッジが一つでも存在すれば不正解と判断できます。 STRIPSプランニング（Blocksworld, Mystery Blocksworld）は、離散的で決定論的な空間で実行できる計画を自動立案するものです。こちらはPDDLという計画立案用の言語を用いて、前提条件に違反することなく初期状態から実行でき、最終的にゴールに到達できる一連のアクションとして記述されます。こちらはアクションを順番に実行し、ゴールに到達できるかを検証しています。 本論文では、これら3つの題材について、n=100で検証を実施しており、結果は以下です。S.P. (Standard Prompting) が標準的なプロンプトで自己批判なしに実行された結果で、ベースラインになるものです。LLM+LLMがLLMによる自己批評です。LLM+Sound Critiqueが上記の「信頼できる検証器」によるもので、B.F. (Binary Feedback)が正解・不正解のフィードバック、F.E.F. (First Error Feedback) が最初にエラーが発生したもののみをフィードバック、A.E.F. (All Error Feedback) が誤りがあったすべてをフィードバックするものです。 （論文より引用） S.P.とLLM+LLMを見比べると、むしろLLMによる自己批判は悪影響となっていることがわかります。GPT-4でモデル自体の性能が低いことも多分に影響していると思われますが、自己批判そのものが正しくない場合、せっかく正しい回答が出力されていたのに批判することでかえって誤りを導いてしまうようです。また、誤解を招くようなフィードバックを生成することもあり、結果的に再考で正解から遠ざかってしまうことがあるとのことでした。 また、B.F., F.E.F, A.E.F.を見ると、二値のみのフィードバックと内容を含めたフィードバックでは、Blocksworld以外ではさほど差はなく、フィードバックが最初のエラーのみと全てのエラーかでも、全てのエラーのほうがむしろ性能が低下していることがわかります。 注意点として、Game of 24とBlocksworldでは、検証器としてのLLMの精度はそれなりに高く、結果としてLLM+LLMの性能低下が低く抑えられたのではと考察されています。これらを踏まえると、LLMかどうかが課題というよりは、正しいか正しくないかを正確に判定できることが重要、かつ、その中身は問わない（具体的なフィードバックであることよりも誤っていることを正しく誤っているとフィードバックできることが重要）ということが言えそうです。 また、反復回数とパフォーマンスについての結果も述べられています。 （論文より引用） 各色ごとに、信頼できる検証器が▲、LLMによる自己批判が●でプロットされていますが、▲が試行を繰り返すことで性能が上がっていくのに対し、●はむしろパフォーマンスが崩壊してしまっており、LLMによる自己批判がマイナスの結果となっています。 相互一致による正しい回答の判定 上記の論文で正しいか正しくないかを正確に判定できることが重要ということがわかりましたが、現実の問題は上記3つの題材のようにルールベースで正しいか判定できない問題もあります。そこで次に紹介したいのが、Mutual Reasoning Makes Smaller LLMs Stronger Problem-Solvers (Zhenting Qi et al.)です。こちらも2024年8月の論文のため、少し古い点は留意が必要なのですが、アイデアがおもしろかったので紹介します。 こちら論文のモチベーションは、LLMというより、SLM（Small Language Model）を活用することにあります。ただ、SLMは多くの試行を繰り返しても、低品質な推論ステップを含む解空間に陥りがちで、どの最終回答が正しいかを判断することは難しいというissueが述べられています。１つ目に紹介した論文のFirst-to-ahead-by-k Votingもを前提としているので、SLMがこの前提を満たせないとなると、複数回実行しても各ステップが正しい回答にたどり着けなくなってしまいます。 論文では、rStarという手法を提案しており、これは推論ステップをモンテカルロ木探索する手法をベースに相互一致プロセスで拡張しています。具体的には、サンプリングされた部分的な推論軌跡を2つ目のSLMに提示し、残りの推論ステップを完了させるよう促し、rStarは相互に一致した回
- 生成AI
- LLM
- AI Agent
- MLOps
ドメインエキスパートとの評価サイクル構築による、WEARのファッション特徴抽出とプロンプト改善
はじめに こんにちは、データ・AIシステム本部の冨田です。ファッションコーディネートアプリ「WEAR」において、ユーザーのコーディネート投稿データを分析し、「似合う」を届けるための機能開発を担当しています。 WEARには日々膨大な数のコーディネートが投稿されています。それらを活用して、経営戦略でもある「ワクワクできる『似合う』を届ける」ためには、画像やテキストからファッションに関する特徴を抽出する必要があります。本記事では、リサーチャーとの協業による評価サイクルを構築しながら、プロンプトエンジニアリングのみで特徴抽出の精度目標を達成した事例を紹介します。 背景・課題 独自定義「似合う4大要素」の抽出 現在私たちは、WEARのコーディネートデータから「似合う」を構成する4大要素を抽出するプロジェクトを進めています。本システムでは、まずLLMを用いてコーディネートの画像やテキストから言語化された特徴を抽出します。その後、説明可能なルールベースのロジックに入力して最終的な4大要素を判定するというハイブリッドな構成をとっています。この仕組みを正しく機能させるためには、まずは前段となるLLMが「オーバーサイズ」や「丈感」といったファッション特有の曖昧な特徴を正確に抽出する必要があります。 一般的なプロンプトの限界 ファッションの言語化は非常に曖昧です。例えば「オーバーサイズ」といっても、少しゆとりがある程度を指すのか、極端にシルエットが大きいものを指すのか、人によって解釈が異なります。単純に「この画像はオーバーサイズですか？」とLLMに尋ねるだけでは、サービスが求める基準（ZOZOとしての正解）とLLMの出力が乖離してしまい、実用レベルの精度が得られないという課題がありました。 アプローチ（技術選定） 手法の比較検討 LLMの回答精度を向上させる手法として、一般的に以下の3つが検討されます。私たちは開発コスト・運用コスト・データ準備の観点から比較しました。 手法 概要 メリット デメリット 今回の判断 プロンプトエンジニアリング 指示文（Prompt）の工夫のみで精度を上げる 開発・運用コストが最小。即時反映が可能。 モデルの知識外のことは回答できない。 採用 RAG 外部知識を検索してプロンプトに含める 最新情報や独自データに対応できる。 検索システムの構築・運用コストがかかる。 不採用 ファインチューニング 追加データでモデル自体を再学習させる 特定のタスクや出力形式に特化できる。 高品質な大量の学習データと計算コストが必要。 不採用 選定理由 近年、LoRA(Low-Rank Adaptation)1などの効率的な手法の普及により、ファインチューニングのハードルは大きく下がりました。それでも、まずはプロンプトエンジニアリングで限界まで性能を引き出し、ベースラインを確立してから次の手法を検討する、というワークフローがベストプラクティスとなっています。 OpenAIの公式ドキュメント内のOptimizing LLM Accuracy2では、モデルの最適化を「Context（知識）」と「Behavior（振る舞い）」の2軸で定義しています。まずはプロンプトでベースラインを測定します。その上で、独自の知識が不足していればRAGを、特定の振る舞いや出力形式の徹底が必要であればファインチューニングを選択する、というアプローチです。また、多くの場合、プロンプトエンジニアリングだけで本番レベルの精度に到達できるという旨も記載されています。 今回のタスクにおいても、ファッションの一般的な知識自体はLLMが既に学習済みであり、最大の課題は「ZOZO独自の定義へのすり合わせ」にありました。そのため、いきなりコストや運用負荷のかかる手法に移行するのではなく、まずはプロンプトを徹底的に磨き込むことにしました。 プロンプト改善・評価サイクル Google Cloudの「プロンプト設計の戦略」ドキュメント3より、プロンプト設計は反復的なプロセスであるとされており、継続的なテストと評価の重要性が説かれています。私たちはこれに則り、本格的なプロンプトチューニングへ着手する前に、以下のプロセスで評価サイクルを構築しました。 1. 開発用データセットの作成 エンジニアがプロンプト改善を試行錯誤するための正解データを用意します。社内のリサーチャー（ドメインエキスパート）に依頼し、WEARに投稿されたコーディネートの中から評価対象の特徴を持つ画像を探してラベルを作成してもらいました。 今回は100項目以上の特徴抽出が必要になるため、全件に対して十分なアノテーションを用意することは工数面で非現実的でした。そこで、本施策では各特徴量につき10件という最小限のデータで精度を検証するアプローチを採用しました。少数のデータでは特定のアイテムへの過学習（汎化できているか）が課題になります。これについては後述する定性評価にて、後段のルールベースを通した最終結果で担保する割り切ったアプローチをとりました。 2. プロンプト改善 開発用の評価データセットがあるおかげで、エンジニアは「なんとなく良さそう」といった感覚値ではなく、目標とした定量指標に向かってプロンプトを改善できるようになりました。今回は正解率70％を目標に設定しています。もちろん100％が理想ですが、開発リソースやリリースまでの期間には限りがあります。そこで、「抽出した特徴でコーディネート検索を行った際、結果として並んだ10枚のうち、何枚までならノイズが混ざっても体験を損なわないか」というシナリオをもとにプロジェクト内で議論しました。その結果、リリースに向けた開発コストとユーザー体験のバランスをとる現実的な落とし所として、この70％という目標値を決定しました。このように明確な基準と評価データが揃ったことで、エンジニアが手元で自律的かつ高速にチューニングを回すことができました。 3. ルールベースのロジックを通した最終出力による定性評価 開発用データセットに対する過学習を防ぎ、本番環境での網羅性を確認するために定性評価します。本来はLLMが抽出した特徴を直接評価したいところですが、無作為に収集した画像に対する抽出結果では出現頻度の低い特徴をうまく引き当てられません。また、評価する特徴が多過ぎるため、効率的な評価が困難です。そこで、後段のルールベースのロジックを通した結果のラベルを使って定性評価することにしました。開発段階でWEAR上の全データを推論すると時間とコストがかかり過ぎてしまうため、ファッションの季節性を網羅するように評価用データセットを作成しました。評価用データセットに特徴抽出とルールベースの判定をしてラベルを付与しました。最終的に付与されたラベルごとに300枚をサンプリングし、リサーチャーによる定性評価（こちらも目標正解率70％）をしました。 評価サイクルで得られた効果と結果 エラー分析による「曖昧さ」の解消 定量評価が可能になったことで、冒頭で触れた「ファッションの曖昧さ」に対して、「具体的に何ができていないのか」が可視化されるようになりました。例えば、評価結果のFalse Positive（誤検知）を分析した結果、以下のような原因が判明しました。 「厚底」の特徴：LLMの持つ一般的な厚底の基準と、ZOZOが求める基準にズレがある。 「柄や装飾」の特徴：服のシワや影を、柄として誤認識してしまっている。 原因が具体的に特定できたことで、リサーチャーと「どうすればLLMに伝わるか」を擦り合わせることが容易になりました。結果として、単純な2値（Yes/No）で判定させるのではなく、「度合いを複数のクラスに分類させてから判定する」といったプロンプトの改善に繋げられました。こうした改善の積み重ねにより、目標の正解率70％を達成しました。 適切なモデル選択 今回のプロジェクトでは非常に多くの特徴量を抽出するため、色や柄などのファッション特徴のカテゴリごとにプロンプトを分けています。 タスクの難易度に応じて、より上位のモデルを採用したものもあれば、逆に軽量なモデルへ落としても精度を維持できたものもありました。定量評価によって「どこまでモデルを落としても許容できるか」が数値化されたことで、システム全体での推論コストや処理時間の最適化を安全に進められました。 今回の手法の確からしさ 全ての特徴の開発とラベルの評価が完了したあとに、4か月分のデータセットに対してラベルの付与率などを分析しました。また、サービスリリース前にWEAR上のコーディネート画像全件に対しても同様に推論・分析し、付与率に大きな差がないことを確認しました。非常に少ないアノテーション画像からのスタートでしたが、特定の期間やアイテムに特化した調整（過学習）にはなっておらず、本番環境のデータに対しても適切に汎化できていることが確認できました。 課題と展望 今後の展望：LLM-as-a-judgeの導入 一方で、評価用データセットの作成にはリサーチャーの人手コストがかかるという課題も残りました。今後は、作成した正解データと評価基準を用いて別のLLMに評価担当を任せるLLM-as-a-judgeの導入を検討しています。LLMによる一次評価で大まかな傾向を掴み、判断が分かれる際どいケースのみリサーチャーが確認するフローにすることで、評価コストを下げつつ、より高速な改善サイクルを実現できます。 まとめ 本記事では、WEARの機能開発におけるLLM活用事例として、RAGやファインチューニングを使わずに高精度な特徴抽出を実現したプロセスをご紹介しました。 ZOZOでは、ファッションの曖昧な感性を技術で解き明かし、ユーザーに新しい体験を届けるエンジニアを募集しています。ご興味のある方は、ぜひ採用ページをご覧ください。 corp.zozo.com 参考文献 Hu, E. J., et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models.↩ Optimizing LLM Accuracy↩ プロンプト戦略の概要↩
- 生成AI
- LLM
- プロンプトエンジニアリング
- MLOps
Claude Code の Plugin Marketplace でスキルをオプトイン配布にする
Claude Code のスキルが数十個に増えてきたのですが、全員に一律で適用されるのがつらくなってきたので、Plugin Marketplace を使ってオプトイン配布に移行しました。 スキルが増えると何が起きるか Claude Code のスキルは .claude/skills/ に配置すると、リポジトリを開いた全員に適用されます。数個なら問題ないのですが、数十個に増えてくるとスキルの description マッチングで意図しないスキルまで発火するようになってきました。QA 向けのスキルがバックエンドエンジニアの作業中に反応したり、フロントエンド向けのスキルがインフラの作業で発火したりといった具合です。 使わないスキルの description がコンテキストウィンドウに載り続けてトークンを消費するのも気になっていました。改めてスキルの棚卸しをしたところ、全員に必須と言えるものは半分以下で、残りは「あると便利だが、全員には要らない」ものでした。 Plugin と Marketplace Claude Code には Plugin と Marketplace という2つのネイティブ機能があります。 Plugin は skills、hooks、agents をひとつのパッケージにまとめる仕組みです。Marketplace はその Plugin のカタログで、source の種類によって配布方法を選べます。 Marketplace の source は3種類あります。 directory はローカルディレクトリを指定する方法です。外部に公開する必要がなく、そのリポジトリ限定の Marketplace を作れます。リポジトリを clone するだけで使える状態になるので、社内のモノレポで使うなら一番手軽です。 github は GitHub リポジトリを owner/repo 形式で指定します。Marketplace を独立したリポジトリとして管理できるので、組織をまたいだ配布に向いています。 url は Git の URL を直接指定する方法で、GitLab やセルフホストの Git サーバーなど GitHub 以外のホスティングに対応できます。 今回は directory を採用しました。モノレポなので同じリポジトリを見ている人が多く、clone するだけで Marketplace が使える状態になります。 この仕組みで「チーム向け」「QA 向け」のようにロール別のスキルパックを作り、各自が必要なものだけインストールする運用が可能になります。 リポジトリ内に Marketplace を作る .ai/marketplace/ ├── .claude-plugin/ │ └── marketplace.json └── plugins/ └── my-team/ ├── .claude-plugin/ │ └── plugin.json └── skills/ └── some-skill/ └── SKILL.md marketplace.json でカタログ全体を定義しています。 { "name": "my-org", "plugins": [ { "name": "my-team", "source": "./plugins/my-team", "description": "チーム向けスキルパック", "version": "0.1.0", "strict": false } ] } 社内向けであれば plugin.json は名前だけで十分です。strict: false を marketplace.json 側で指定しておけば、メタデータはカタログに一元管理されます。 { "name": "my-team" } あとはリポジトリの .claude/settings.json に Marketplace を登録しておきます。この設定がリポジトリに含まれているので、他のメンバーは pull するだけで Marketplace が利用可能になり、すぐに Plugin をインストールできる状態になります。 { "extraKnownMarketplaces": { "my-org": { "source": { "source": "directory", "path": "./.ai/marketplace" } } } } インストール /plugin で一覧を確認して、必要なものをインストールします。 /plugin install my-team@my-org 不要になったらアンインストールするだけです。 /plugin uninstall my-team@my-org Namespace の設計 Plugin 名がスキルの namespace になるため、ディレクトリ名に my-team- のような prefix を付ける必要はありません。 ただし、スキルを呼び出すときの補完候補には namespace を除いた名前が表示されます。既存スキルと名前が被ると区別しにくいので、SKILL.md の name フィールドで明示的に namespace を含めておくのがおすすめです。 # skills/prd-guide/SKILL.md name: my-team:prd-guide こうしておくと、補完時に my-team:prd-guide と表示され、どの Plugin のスキルか一目で分かります。 やってみての所感 まだ移行を始めたばかりなので、誤発火やコンテキスト汚染が実際に減ったかはまだ分かりません。ただ、「全員に適用されるのはちょっと……」と追加を迷っていたスキルを Plugin に気軽に足せるようになったのは良い変化でした。 ちなみに、Claude Code 以外の Agent を使う人のために、1つのソースから各 Agent 向けの設定を自動生成する仕組みを作っていました。Marketplace は Claude Code 特有の機能なので、ここだけポータビリティが落ちているのが気になっています。 どうやら Codex にも最近入った同様の Plugin Marketplace の仕組みがあり、1つのソースから両方のプラグインを生成できるようにしたいなと企んでいます。
- Claude Code
- LLM
- AI
FDEって何するの？ 現場の泥臭さが「はずみ車」となってプロダクトを強くするリアル
こんにちは。fjm2uです。昨年の11月からAi Workforce事業部のFDE（Forward Deployed Engineer）チームでインターンさせていただいております。 この記事では、Ai Workforce事業部のFDEチームへの応募を検討している方向けに、FDEという仕事の特徴と、インターンとして実際に経験した「現場での課題解決がプロダクト改善につながる」流れを紹介します。 FDEの業務 FDEの詳細は以下の記事でも紹介されていますので、そちらをご参照ください。 note.com blog.allstarsaas.com note.layerx.co.jp 私が理解しているFDEとは、お客様の業務を理解しながら、プロダクトをテコとして短期間で顧客課題の根本解決を行い、その経験で得た知見をプロダクトの改善に繋げる職種です。 そして、そのプロダクト改善がはずみ車となり、次回はもっと早く・深く顧客課題を解決することが可能となります。 FDEに主に求められているのは、 知らないドメインへの業務理解の質（広さ、深さ、スピード） 業務の課題を根本的に解決するための提案力 提案を具体的な実装に落とし込む開発力 チーム内・お客様とのコミュニケーション能力 です。求められる幅が広い職種ですが、だからこそインターンでも日々成長を実感できる環境です。 Ai WorkforceのFDEチームの実態 現在は、FDEチームの中でも開発中心の方・顧客案件中心の方で分かれている印象です。 開発中心の方は、プロダクトでFDEが利用する部分を中心とした開発を担当されています。開発の難易度が高く、実装のボリュームも大きいです。 顧客案件中心の方は、プロダクトを利用してお客様の課題解決を行い、DS（Deployment Strategist：顧客の業務設計や導入支援を担う職種）と一緒にお客様との商談に参加します。この過程でお客様の現場に出向くこともあります。 情報管理は徹底されており、チーム内でもアサインされていない案件のデータなどは見えません。ただ、チーム内の定期ミーティングではプロダクトのTipsや改善の知見が常に共有され、常にフィードバックループが回っています。 Ai Workforce FDEチームで働く魅力 情報の質と透明性が高い 若手でも、意見を出しやすい雰囲気がある 先端技術の動向を踏まえた流動的な事業環境がある 相談しやすい人が多く、OJTで力をつけられる 実際、どんなことをしたのか ここからは、私が参加したトライアル案件を例に、FDEの仕事が実際にどう進むのかを紹介します。 FDEとDSの先輩方と、トライアル案件に参加しました。トライアル案件は、お客様が本番導入の可否を判断するために、プロダクトを実務に近い形で試す取り組みです。 やったことの概要 大量の資料から必要な情報を正確に抽出・分類し、特定形式のレポートとしてまとめるという業務でした。1件あたり数十ページに及ぶ資料もあり、業界の専門知識がないとそもそも着手すら難しい内容です。人手でやると膨大な時間がかかるうえに、分類や判定の判断には業務ドメインへの深い理解が求められるタスクでした。 やったことの詳細 以前に別のFDEの方が作った成果物をベースに、FDEとDSの先輩方と基本3人チームで案件に取り組みました。案件の中心は、精度向上のサイクル（プロンプトを調整し、その結果を評価し、また調整する）の繰り返しでした。 1. 正解データの作成 精度評価の基盤として、受領サンプル全件の正解データを手作業で作成しました。元資料から値を一つ一つ確認し、正解データ自体の不整合も発見・報告し、お客様と認識をすり合わせました。地道な作業ですが、この作業がなければ精度を測ることすらできず、案件の土台として重要でした。 2. プロンプト調整 別のFDEの方が作成したプロンプトを改善しました。資料には専門用語や独特のフォーマットが多く、文脈によって分類結果が変わりうる項目も少なくありません。同じプロンプトでも資料が変わると誤分類が発生しました。不正解パターンを一つずつ分析し、Few-shot例の追加や分類ルールの構造化を繰り返すことで、幅広い資料に対応できるよう調整していきました。 最初の時点で8割以上は正しく処理できている状態から、残りの不正解パターンを一つずつ潰して精度を引き上げていく作業です。最後の数%が最も手強く、この数%とずっと戦っていました。 3. ワークフローの修正・構築 ワークフローとは、Ai Workforce上で構築する処理パイプラインのことです。ノードと呼ばれる処理単位を組み合わせて定義し、LLMによる情報抽出・分類、Pythonによる計算処理などノードにはいくつかの種類があります。プロンプトもノードの中に組み込まれています。 情報抽出ロジックの修正、エラーハンドリング、出力項目名の統一など、案件に合わせたワークフローの修正を行いました。要件に合わせた新しいワークフローも作成しました。 4. 精度評価と自動化の試み プロンプト調整以上に時間がかかったのが精度評価でした。正解データとの照合・集計をすべて手作業で行っていたため、「調整→評価」の1サイクルに大きなコストがかかっていました。案件の途中で自動評価スクリプトの開発に着手しましたが、時間的制約もあり、案件中に使えるレベルには達しませんでした。 この課題感はプロダクトへのフィードバックとしてチーム内に共有しました。そして案件を終えた今、自動で精度評価するための仕組みを作っています。まさにFDEモデルの「現場→プロダクト改善」のループを経験しています。 5. 商談への同席 先輩方と一緒にお客様との定例会に参加しました。 案件を通じての学び 「正しい出力」から「正しい問い」へ 案件参加前の私は、ワークフローの改善は「正しい出力を出すこと」とぼんやり考えていました。しかし正解データを作成する過程で、正解の定義が一意に定まらないケースがありました。そこで「そもそも正解とは何か」をお客様とすり合わせなければ、いくら精度を追っても意味がないことに気づきました。技術だけでなく、ドメイン知識の深さがソリューションの品質を左右することを実感しました。 評価駆動という方法論 案件中の最大の反省は、精度評価の仕組みを後回しにしたことでした。手動で評価していたため、「プロンプトを修正したら再評価」というサイクルのたびに大きな時間を取られ、調整のスピードが上がりませんでした。もし最初に自動評価の仕組みを整えていれば、同じ期間でもっと多くの調整サイクルを回せたはずです。 この経験から、まず評価の仕組みを整えてから開発に入るという方法論を自分の中に持つことができました。ソフトウェア開発におけるTDD（テスト駆動開発）の考え方に近いですが、LLMを使った案件では特に重要だと感じています。通常のソフトウェアは同じ入力に対して同じ出力を返しますが、LLMの出力には揺れがあり、「本当に良くなったのか」を定量的に測れないと、調整が勘になってしまいます。だからこそ、評価の自動化が先に来るべきだったのです。 プロジェクトの中での動き方 3人チームで案件を進める中で、技術以外の動き方も学びました。商談では先輩方にフォローいただきながらチームとして対応し、定例会ではネクストアクションを毎回確認することでプロジェクトを着実に前に進める。こうした「チームの一員としての立ち回り」は、一人で開発しているだけでは得られなかった経験です。 プロダクトがあったからこそ この案件は、プロダクトなしでは到底こなせない難易度でした。LLMの不確実性をプロダクトが吸収してくれること、複雑で長い処理でも安定して動作すること。この2つがあったからこそ、少ない工数で高品質な成果物を出すことができました。 さらに、以前のFDEの方が別案件で得た知見がプロダクトに蓄積されていたおかげで、ゼロからではなく「積み上げ」の上で仕事ができました。記事の前半で書いたはずみ車を、インターンの立場でも実感できた経験でした。 トライアルの結果、お客様から 「作業時間が大幅に削減できそうだ」 という評価をいただきました。自分が関わったプロジェクトでこうしたフィードバックを直接聞けたのは、大きなやりがいでした。 さいごに 1.5ヶ月ほど、学業・プライベートでやる事が多く、お休みをいただいてました。お休みをいただく際も復帰した際も、チームの方々は温かかったです。良い環境だと思います。 復帰してみると、移動等でFDEチームのインターンが私1人になってしまっていて、なんか寂しいので募集要項を貼っておきます。以下からご連絡お待ちしております！ open.talentio.com open.talentio.com
- LLM
- 生成AI
- プロダクト開発
- インターン