テクブロ — 技術ブログの新着まとめ

既読のみLayerX

38件

フィード

LayerX·2026/06/09

マルチモーダル知識グラフ「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

koichiro_otani_layerx

LayerX·2026/06/03

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

tyoyo

LayerX·2026/05/19

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
プロンプトエンジニアリング
品質
自動化

teyamagu

LayerX·2026/05/12

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

hanenao

LayerX·2026/05/08

人から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

sbrflx

LayerX·2026/04/14

人手のリサーチをデータパイプラインに。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 対象レコードの抽出 / API 呼び出し / JSON 格納"] LND["landing 取得直後の RAW_JSON"] SRC["src 不正データ除外 / 取得手段の隠蔽"] DWH["dwh 再利用を意識した再構成"] MART["mart 用途特化の利用データ"] end end subgraph RESP["Responses API"] API["Web Search + JSON 応答"] end MASTER --> PY PY -- "Snowflake から 外部 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
データ基盤

saeeeeru

LayerX·2026/04/08

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

cipepser

LayerX·2026/03/31

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
プロダクト開発
インターン

fjm2u

LayerX·2026/03/24

OpenClaw-RLで学ぶAgentic RLの報酬設計

はじめにこんにちは！LayerXのバクラク事業部で機械学習エンジニアをしている宇都(@kuto_bopro)です。最近エージェントに関する論文を読んでいると「Self-Evolving」というキーワードを持つ論文をよく目にします。Self-Evolvingは自己進化・自己改善を意味しており、自動で性能が上がっていくAIエージェントの文脈で使われます。 A Survey of Self-Evolving Agents, Figure3より引用 arxiv.org 上記のサーベイ論文で、 Self-Evolving Agentに関して整理されており、エージェントの進化対象(What)はコンテキスト、モデル、ツール、エージェントアーキテクチャと多岐に渡っています。従来の機械学習では更新対象はモデルパラメータのみでしたが、LLMに対してはそれ以外の選択肢があるのが特徴的です。特にコンテキストに関してはコーディングエージェントを使用する際にAGENTS.mdやSkillsを作成・更新することでAIエージェントの性能を改善することが可能であるため多くの方が馴染み深いのではないかと思います。一方、Fine Tuningによってモデル自体を更新するアプローチは、実施コストの大きさから現状では選択肢として上がりにくいのが実情です。しかしFine Tuningには、数理的なプロセスを通じてデータから直接学習できること、またコンテキストの肥大化を抑えられることといった利点もあります。こういった背景も踏まえ、本記事ではAIエージェントのモデルを強化学習で改善するAgentic RLというアプローチについて、OpenClaw-RLというプロジェクトを題材に紹介します。 github.com Agentic RLとは Agentic RL（エージェント型強化学習）とは、AIエージェントが環境と対話しながら、強化学習によって自身の性能を継続的に向上させる手法です。強化学習は、エージェントが環境と試行錯誤を繰り返しながら、得られる報酬が最大になるよう行動を学習していく機械学習の手法であり、近年のLLMの推論能力やエージェント性能の向上を支える中心的な技術となっています。 AIエージェントの振る舞いを強化学習の枠組みで整理すると、次のように定義できます。状態: コンテキスト（過去の行動・観測の履歴）行動: エージェントの応答（テキスト生成、ツール利用など）観測: ユーザーの応答や環境からのフィードバック（エラー情報など）報酬: 各行動に対するスコアリング OpenClaw-RLのコンセプトコーディングエージェントやパーソナライズエージェントを利用する際、対話中に発生するユーザ応答や環境フィードバックは、個人利用の観点では(メモリ保存を除いて)多くの場合改善には利用されずに捨てられます。この課題に対してOpenClaw-RLは、対話ログから学習信号を得て、非同期のAgentic RLを実行することで「対話するだけでモデルが賢くなる」という仕組みを設計しています。なお、名前にある通りAIエージェントとしてOpenClawを動かす想定で設計されたものになっています。OpenClawについては以下を参照ください。 openclaw.ai OpenClaw-RLの概要を表したのがこちらの図です。 OpenClaw-RLの概略図 OpenClawのようなAIエージェントの推論を個人環境やクラウド環境で動かす想定 AIエージェントとの対話を行うと、そのログをリアルタイムに強化学習サーバに連携し非同期で強化学習を行う更新されたモデルパラメータを学習サーバからAIエージェントが実際に動作する推論環境に連携する対話ログからどう学習信号を得るか OpenClaw-RLの論文では非同期強化学習や汎用エージェントなどいくつか面白いトピックはありますが、今回はパーソナライズエージェント向けに実際の対話ログからどのように学習信号を取得するかをテーマに紹介します。事後学習との違い現在私たちの身の回りで利用されるAIエージェントの多くは事後学習の段階でAgentic RLが行われています。この時よく利用されるのが、正解がある数学タスクやテストやコンパイラによる検証が可能なコーティングタスクに対して強化学習を行うというものです。これはRLVR(Reinforcement Learning with Verifiable Rewards)と呼ばれています。こういった事後学習で使われるデータセットは、あらかじめ検証環境や報酬が整備されたものです。一方、今回対象とするのはユーザとのインタラクティブなやり取りが含まれる実際の対話ログです。このようなリアルタイムの対話データを用いる場合、ルールベースで明確な正解を定義するのが難しいケースも多く、報酬をどう設計するかが重要なポイントとなります。 OpenClaw-RLの報酬設計 OpenClaw-RLでは２つの学習信号を利用しています。　　　　　　　　　　　　　　　 ①Binary報酬 Binary報酬の概略図こちらはフィードバックをもとにエージェントの行動の良し悪しを判定する学習信号として機能しますエージェントの行動の次に得られた観測（ユーザ応答・環境フィードバック）を評価用LLMに渡す観測に対し評価用LLMで以下のいずれかを複数回出力させ多数決で報酬を決定 +1: 良い 0: 何もなし -1: 悪いつまりAIエージェントの行動によって発生した観測に対してAIのフィードバックをもとに報酬を生成するというものです。このように検証可能でないタスクに対する報酬設計としてAIのフィードバックによる報酬生成は他の論文でも採用されており有力な手段の1つです。OpenClaw-RLの工夫点として1回のフィードバックだと報酬が不安定になることから多数決を取る方法が採用されています。一方で報酬が評価用LLMの性能に依存する、ユーザ応答のたびに評価用LLMの推論を裏で回す必要があり推論コストがかかるという課題はあります。 ②蒸留報酬蒸留報酬の概略図こちらはフィードバック情報そのものを学習信号として利用しますエージェントの行動の次に得られた観測（ユーザ応答・環境フィードバック）を評価用LLMに渡す評価用LLMに観測がエージェントの行動を改善する上で有益かどうかを+1, -1の2値で判定させる※1 有益と判定した場合に以下の2つのモデルを用意する教師モデル：コンテキストに観測を加えてエージェントの行動を出力生徒モデル：コンテキストに観測を加えずエージェントの行動を出力(元のエージェントの行動そのもの) 生徒モデルの出力を教師モデルの出力に近づけるように報酬※2を決定 ※1 Binary報酬はエージェントの行動をLLMで評価している一方、蒸留報酬はフィードバックの有益さをLLMで評価という違いがある ※2 厳密にはトークン単位のアドバンテージ ①のBinary報酬はエージェントの応答全体に対して離散的な報酬が与えられますが、蒸留報酬はトークン単位で教師モデルから確率分布の違いに応じたフィードバックが与えられます。そのため、観測に具体的な指示が含まれている場合に、その指示を踏まえた行動をモデルに直接学習させられるという意味で、より密なフィードバックといえます。余談ですが、通常の蒸留は大きな教師モデルから小さな生徒モデルへ性能を引き継ぐ用途で使われることが多いです。今回の場合はモデル自体は同じで、コンテキストの有無によって教師と生徒を分けています。これは自己蒸留やコンテキスト蒸留と呼ばれる手法の1つで、別モデルを用意しなくて済む手軽さもあり、最近の論文でもよく見かける手法です。学習時の注意点ここまでOpenClaw-RLで利用されている報酬について説明しましたが実際にこれらの報酬を元に学習をする上での注意点もあります。その1つがGRPOアルゴリズムはそのまま利用できないという点です。 LLMに対する強化学習のアルゴリズムではGRPOがよく採用されています。GRPOは1つのプロンプトに対して複数の推論（rollout）を実行し相対評価を行うことで、従来主流だったPPOで必要とされていた価値評価モデルを不要にできるのが特徴です。しかし実際の対話ログを使う場合、ある行動に対して得られるユーザ応答（観測）は1つだけです。LLMの推論自体は裏で複数回実施できるものの、その行動に対する観測は1つしか得られないため、学習に利用可能なrolloutも実質1つとなります。そのため複数のrolloutを前提とするGRPOはそのままでは使えません。OpenClaw-RLでは報酬をそのまま相対評価値として使う簡易的な方法を採用しており、この点については改善の余地がありそうです。おわりに OpenClaw-RLを通して、対話ログからAgentic RLをする場合の学習信号設計について紹介しました。今回は割愛したのですが、非同期の強化学習によるリアルタイムのモデル更新というコンセプトも面白いなと感じたので興味がある方は原論文も読んでみてください。 arxiv.org 今回はモデル更新を前提とした話題でしたが、多くの場合単純なパーソナライズや性能向上はコンテキスト・メモリ管理の方がシンプルで効果的な場面が多いというのが実情だと思います。ただし冒頭でも挙げた自己進化という方向性は今後のAIエージェント開発においてもますます重要になっていくと思いますし、その選択肢の1つとして今回紹介したAgentic RLも現実的な手段として注目されていくのではないでしょうか。個人的にも興味のある領域なので引き続き動向をウォッチしていきたいと思います。最後になりましたが、LayerXでは機械学習エンジニアを募集しております！ユーザ価値を第一に考えたML/AIエージェントの社会実装を高速に進めておりとても面白い環境です！興味ある方はぜひこちらからご応募ください。 open.talentio.com

生成AI
強化学習
LLM

kutohonn

LayerX·2026/03/16

言語処理学会第32回年次大会(NLP2026) 参加レポート

こんにちは、Ai Workforce事業部プロダクト部 FDEグループエンジニアの堤(@ozro_223) です。この記事は2026年3月9日〜13日に栃木県宇都宮市のライトキューブ宇都宮で開催された言語処理学会第32回年次大会(NLP2026)の参加レポートです。 LayerXとしては、昨年に引き続きプラチナスポンサーとして協賛させていただき、スポンサーブースの出展と非公式で懇親会を開催しました。 NLP会場告知看板プラチナスポンサーとしてLayerXのロゴが掲載されている様子スポンサーブースの様子スポンサー展示では、学生・研究者・企業の方など、多くの方にお立ち寄りいただきました。ありがとうございます。展示ブースでは、Bakuraku と Ai Workforce の2つのプロダクトを紹介しました。 BakurakuやAi Workforceの開発を通じて私たちが目指すAIエージェント時代のビジョンと、その実現に向けた開発の取り組みをご紹介しました。また、私はAi Workforce事業部のエンジニアとして、最近話題のFDE（Forward Deployed Engineer）やDS（Deployment Strategist）の役割・働き方について多くお話しました。ブースの様子自然言語処理やLLMに深く携わる学生・研究者・エンジニアの方々と直接話せる機会は貴重で、私たちのプロダクトが取り組む課題について、技術的な知見を深く交換できる機会となりました。懇親会・交流 3月10日の夜はディナー懇親会、3月11日のランチタイムはランチ懇親会をLayerX主催で開催しました。 NLPの研究トレンド、企業でのAIエージェント活用事例、エージェント時代の働き方について、参加者と活発に意見交換しました。転職理由、社内でのAIエージェント活用方法、フレックスな働き方といった、外部からは見えにくいLayerXの内側についても話せ、会社をより深く知ってもらえる機会となりました。一般発表今回聴講した発表のなかから、個人的に面白く、印象に残ったものをピックアップして紹介します。 [P4-1] 訓練不要レビュー生成のための会話形式プロンプトレビュー履歴が少ないユーザーを模倣したレビュー文生成において、過去レビューを1つのプロンプトにまとめて与えるより、user/assistantの対話形式に再構成して与えるほうが、対象ユーザーらしいレビューをより高精度に生成できることを示した論文です。改めて「何を与えるか」だけでなく「どういう構造で与えるか」が重要だと実感しました。今回はOpenAI APIのChat Completionsを使用して実験をしたと伺いましたが、OpenAIの Responses API は会話状態の保持やマルチターンでの文脈再利用を前提にした設計になっているため、過去履歴参照が重要なユースケースでは、こちらのほうがより効果的になるかもしれないと思いました（既にResponses APIを使用した実験を進めているようでした）。 [B3-4] Lost in the Files：長コンテキスト LLM による複数専門文書からの網羅的情報抽出とその限界長コンテキスト対応のマルチモーダルLLMに複数のPDFを直接入力した場合、単一文書では高精度に情報抽出できても、複数文書では特に入力列の中間に置かれたファイルの情報が抜け落ちやすく、PDFのファイル入力でも Lost in the Middle に近い現象が起こることを示した研究です。 Ai Workforce は PDF・Excel・Word などのドキュメントを入力として扱うことが多く、この示唆は非常に勉強になりました。これまで OCR → テキスト入力の文脈で Lost in the Middle を意識してきましたが、ファイル入力でも中間ドキュメントの情報が抜けやすいと示された点は重要で、プロダクト設計に活かせる気づきでした。 [B2-3] 機械文としての検出されやすさと文章の品質は両立する LLM生成文の「機械文として検出されやすさ」と「文章品質」は必ずしもトレードオフではなく、両者を同時に高める学習フレームワークD-PUPPETを提案し、その有効性を示した研究です。機械っぽい表現を検出・修正するだけでは、機械文らしさは下がってもタスク性能まで落ちてしまう可能性がある、という問題意識からスタートしている点がまず面白いと感じました。DPOの学習に品質指標（metrics）の良し悪しも組み込むことで、自然さと性能の両方を同時に改善できると示している点が興味深かったです。 [B2-17] ハルシネーションから学ぶ：内部表現への介入によるハルシネーション抑制従来は2つのLLMを同時に動かしていたanti-expertによるハルシネーション抑制を、単一モデルの内部表現への介入で実現する in-model anti-expert（IMAE）を提案し、精度を保ちながら推論コストとレイテンシを改善した研究です。「嘘をつく方向のモデルをあえて作り、そのモデルの出力確率をペナルティとすることでハルシネーションを抑制する」という発想自体を初めて知り、とても勉強になりました。そのアイデアを関心のみで終わらせず、単一モデル化によって実運用しやすい形に最適化している点が特によく、精度だけでなくコストやレイテンシまで含めて改善を目指す姿勢は実務的で非常に参考になりました。さいごに ChatGPTの登場以降、NLPの分野は加速度的に人気が高まっており、今回のNLP2026も非常に大盛況でした。個人的には、日本語特有の課題に着目したニッチな研究が多い点が、他の学会とは異なる魅力だと感じています。来年以降も、NLPの益々の発展にLayerXとして引き続き貢献できればと思います。 LayerXのインターンシップや新卒、中途採用にご興味のある方は、下記リンクをご覧いただきぜひお気軽にご応募ください！ jobs.layerx.co.jp また、FDEや新卒スタートアップというキャリアについて興味のある方は是非以下のサイトからカジュアルにお話しましょう！ jobs.layerx.co.jp

生成AI
LLM
AI Agent
自然言語処理

hat223ena

LayerX·2026/03/10

AIエージェントを強くする『合成データ』作成のニッチなTips集

0. はじめに LayerX Ai Workforce事業部でR&Dチームマネージャーの澁井（しぶい）と申します。実業務でLLMやAIエージェントを活用するときに頻繁に課題になることとして、作ったLLM/AIエージェントシステムを評価するデータが足りない、ということがあります。こうした課題に対処するため、LLMやAIエージェントを用いて合成データを作ることは一般的なプラクティスと言えます。しかし、必要な品質の合成データを大量かつ多様に作ることは相応に難しく、エンジニアリングが伴います。本テックブログでは、合成データの作り方に関するTips集を紹介します。このTipsが読者の合成データ作成に貢献できると幸いです。 1. 合成データとは何か？ AIエージェント時代に注目される理由合成データ（Synthetic Data）とは、実データの統計的特性や意味構造を保ちながら、プログラムやモデルによって人工的に生成されたデータのことです。従来は GAN やルールベースの手法が主流でしたが、LLM の登場で状況が一変しました。 AIエージェント時代に注目される理由は3つあります。第一に、エージェントの評価データが慢性的に不足している点です。ツール呼び出しの成否判定、マルチステップ推論のゴールドラベルなど、エージェント固有のベンチマークは実データだけではカバーしきれないことが多いでしょう。たとえば「契約書の条項抽出」タスクでも、世の中には多様な種別の契約書（売買契約書、ライセンス契約書、業務委託契約書、賃貸借契約書、秘密保持契約書、等々）が多様なフォーマットで存在し、網羅的なパターンの実データを用意することは工数がかかります。合成データであれば網羅的に自動生成できます。第二に、LLM 自体が合成データの生成器として極めて優秀であるという点です。自然言語の多様性、ドメイン知識の埋め込み、フォーマットの柔軟性――これらを一つのモデルで同時に扱える生成器は LLM 以前には存在しませんでした。第三に、AIエージェントのアーキテクチャそのものが合成データパイプラインと相性が良い点です。Planner → Generator → Validator のようなマルチエージェント構成は、そのままデータ生成ワークフローに転用できます。つまり「エージェントを作る技術」と「エージェントのためのデータを作る技術」が同一のスキルセットで完結します。 2. Pydantic × LLM で型安全な合成データを生成合成データの品質を安定させるうえで最も効果的なのが、出力スキーマを Pydantic モデルで厳密に定義し、LLM の出力をバリデーションにかけるパターンです。 2.1 基本構成 from pydantic import BaseModel, Field, field_validator from openai import OpenAI import json class SyntheticTicket(BaseModel): """カスタマーサポートチケットの合成データスキーマ""" ticket_id: str = Field(pattern=r"^TKT-\d{6}$") category: str = Field(description="問い合わせカテゴリ") severity: int = Field(ge=1, le=5) customer_message: str = Field(min_length=20, max_length=500) expected_action: str = Field(description="エージェントが取るべきアクション") requires_escalation: bool 2.2 Responses API の Structured Outputs で型安全を API レベルで保証する従来は LLM の出力を自前でパースし、バリデーションエラー時にリトライするループを書く必要がありました。しかし OpenAI の Responses API が提供する Structured Outputs 機能を使えば、API 側がスキーマ準拠を保証してくれます。 Pydantic の BaseModel をそのまま text_format パラメータに渡すだけで、レスポンスがパース済みのオブジェクトとして返ってきます。 from pydantic import BaseModel, Field, field_validator from openai import OpenAI client = OpenAI() def generate_ticket(prompt: str) -> SyntheticTicket | None: """Responses API + Structured Outputs による型安全な生成""" response = client.responses.parse( model="gpt-5.2", input=[ { "role": "system", "content": ( "あなたは合成データジェネレータです。" "指示に従い、リアルなカスタマーサポートチケットを生成してください。" ), }, {"role": "user", "content": prompt}, ], text_format=SyntheticTicket, ) # モデルが安全性の理由で拒否した場合のハンドリング if response.output_parsed is None: # refusal が返された場合 for item in response.output: if hasattr(item, "refusal") and item.refusal: print(f"モデルが生成を拒否しました: {item.refusal}") return None return response.output_parsed # 使用例 ticket = generate_ticket( "日本語で、配送遅延に怒っている顧客のチケットを生成してください。" "severity は 4 以上にしてください。" ) if ticket: print(ticket.model_dump_json(indent=2)) 2.3 Tips: スキーマ設計のコツ Field(description=...) を必ず書く: LLM はスキーマの description フィールドを手がかりに出力を生成します。説明が丁寧なほど出力品質が上がります。 Literal 型で選択肢を制限する: category: Literal["billing", "shipping"] のように書くと、JSON Schema 上で enum として表現されるため LLM が逸脱しにくくなります。ネストモデルを活用する: 複雑なデータは BaseModel をネストして構造化しましょう。フラットな JSON よりも LLM が構造を理解しやすくなります。 model_json_schema() の出力をそのまま渡す: 手書きでスキーマを説明するよりも、Pydantic が生成した JSON Schema を直接プロンプトに含めるほうが正確です。 3. 答えから合成データを作る ― 逆方向生成合成データ生成でもっとも見落とされがちで、かつ強力なテクニックが逆方向生成です。 3.1 なぜ「答え」を先に作るのか通常の発想では「ドキュメントを作り、それに対する正解を作る」と考えます。しかし、LLM がドキュメントを生成した後に正解ラベルを抽出しようとすると、ドキュメントの曖昧性によって正解が一意に定まらないケースがあります。逆方向生成では、先に「処理結果（正解）」を確定させ、その正解が自然に導出されるようなドキュメントを後から合成します。 3.2 具体例: 請求書データの抽出タスク【Step 1: 正解の定義】 { "vendor_name": "AAAAAAA", "invoice_number": "INV-2025-003847", "total_amount": 1254000, "tax_amount": 114000, "line_items": [ {"description": "クラウド基盤構築費", "quantity": 1, "unit_price": 800000}, {"description": "運用保守（月額）", "quantity": 3, "unit_price": 120000}, {"description": "セキュリティ監査", "quantity": 1, "unit_price": 94000} ] } 【Step 2: 正解に整合するドキュメントの合成】 → LLM に「上記の構造化データが抽出結果として正しくなるような請求書のテキスト（レイアウト崩れ・表記ゆれを含む）を生成せよ」と指示。 3.3 プロンプト設計のポイント逆方向生成プロンプトでは、ドキュメントに意図的なノイズを注入する指示が鍵になります。以下の構造化データから、現実の請求書テキストを生成してください。制約: - 金額表記は「¥1,254,000」「1,254,000円」「￥1254000」のいずれかをランダムに使用 - 品目名は微妙に異なる表現（例:「クラウド基盤構築」→「クラウドインフラ構築作業」）を含めてよい - 会社名にはふりがなや英語表記を併記するケースを20%の確率で含める - フッターに無関係な定型文（振込先情報、免責事項など）を追加する - 行の順序は元データと異なってもよいこのアプローチの利点は「正解ラベルの正確性が保証された状態で、入力側の多様性だけを自由に拡張できる」ことにあります。 3.4 応用: 要約タスクへの適用要約タスクでは「理想的な要約」を先に定義し、その要約が正当化される元文書を合成します。 Step 1: 要約 = "2025年Q1の売上は前年比12%増。主因はAPAC市場でのSaaS契約増加。" Step 2: → 上記要約の根拠となるような四半期報告書のセクションを生成。副次的な話題（人事異動、設備投資）も含めて情報量を膨らませる。 4. 異常検知モデル向けに「異常パターン」だけを狙って合成するエージェント設計 4.1 課題: 正常データは豊富だが異常データが極端に少ない異常検知では、正常:異常 = 99:1 以下の極端な不均衡が一般的です。単純に「異常データを作って」と LLM に頼むと、パターンが単調になりがちでしょう。 4.2 分類体系ドリブンデータ合成有効なのが、異常パターンの分類体系（Taxonomy）を先に設計し、それに基づいて生成を制御する方法です。そのために以下のように各フェーズでエージェントを用意します。 4.3 Taxonomy Agent による異常カテゴリの自動設計 Taxonomy Agent の役割は、ドメイン知識と正常データの特徴を入力として、「どんな種類の異常がありえるか」を体系的に洗い出すことです。人間が手動でカテゴリを設計するとどうしても既知の異常に偏るため、LLM のドメイン知識を活用して分類木を自動生成させます。もちろん、人間の既知の情報を補足として与えることで、より品質の高い分類木が作れるでしょう。 TAXONOMY_PROMPT = """ あなたは{domain}ドメインの異常検知の専門家です。以下の正常データの特徴量サマリを分析し、発生しうる異常パターンの分類木（Taxonomy）を設計してください。正常データの特徴: {normal_stats} 以下の軸で異常を分類してください: 1. 値の異常（範囲逸脱、統計的外れ値、物理的にありえない値） 2. 時間の異常（頻度変化、周期性の崩壊、時系列の逆転） 3. パターンの異常（通常と異なるシーケンス、欠損パターン） 4. 関係性の異常（フィールド間の相関崩壊、因果関係の逆転） 5. 複合異常（上記の組み合わせ）各カテゴリについて以下を出力してください: - category_name: カテゴリ名 - description: どのような異常か - subtypes: 具体的なサブタイプ（最低3つ） - generation_hint: この異常を生成する際の具体的な指示

LLM
生成AI
Pydantic
データセット
AIエージェント

shibuiyusuke

LayerX·2026/03/06

DEIM2026参加レポート

こんにちは、機械学習エンジニアの宇都(@kuto_bopro)です。この記事は2026年2月28日 ~ 3月5日にオンライン・オンサイト（兵庫県神戸市）のハイブリッドにて開催されたDEIM2026 第18回データ工学と情報マネジメントに関するフォーラム（第24回日本データベース学会年次大会）の参加レポートです。 LayerXとしては、昨年に引き続きプラチナスポンサーとして協賛させていただき、企業ブースの展示と技術報告に参加させていただきました。 https://pub.confit.atlas.jp/ja/event/deim2026 今年は 2月28日〜3月2日にオンラインによる一般発表セッションの後、 3月4日と5日に兵庫県神戸市にある神戸国際会議場・展示場で開催されました。神戸のオンサイトでは、チュートリアルやスポンサーによるランチョンセミナー、インタラクティブセッション (ポスター発表) 　などが行われました。 DEIM会場告知看板技術報告前半日程でオンラインで実施された一般発表セッションでは、技術報告として『AIエージェントによる「業務の自動運転化」に向けた技術的挑戦と実践例』というタイトルで機械学習エンジニアの松村(@yu__ya4)が発表いたしました。 https://pub.confit.atlas.jp/ja/event/deim2026/presentation/8B-05 発表では、「気づいたら仕事が終わっている」という体験を届けるためにLayerXが提供するバクラクで実際に導入されているAIエージェントの開発事例やその実現に向けた技術的な課題についてお話しさせていただきました。登壇の様子スポンサー企業展示展示ブースでは学生や企業の方など多くの方にお立ち寄りいただきました。 LayerXが提供するバクラクとAI Workforceのプロダクト紹介を通して、我々が目指す世界やそのために現在どういう取り組みをしているかというお話をさせていただきました。また学生向けに毎年実施しているサマーインターンシップについても案内をさせていただきました。ブースの様子インタラクティブセッション後半日程のオンサイトではインタラクティブセッションとしてポスター発表が行われていました。会場を見渡すとLLMを扱った研究が多く並んでおり、中には「AIエージェント」をキーワードに掲げる発表も一部あり、研究コミュニティの関心が時代の流れとともに変化しつつあるのを実感しました。ここでは執筆者である宇都が聴講したポスターセッションから面白かったものをピックアップして紹介します。なおポスター画像は発表者からの承諾を得て撮影・掲載しております。文書拡張プロンプト最適化に基づく同時更新文書検索概要ある文書を更新した際に関連する他の文書も同時更新するための文書検索手法としてLLMによる文書拡張と自動プロンプト最適化を組み合わせた検索手法を提案面白かった点今回は日本法とEU法の法改正を題材にした研究でしたが、同時更新文書検索は社内ドキュメント更新など応用範囲も広く面白い題材だなと思いました。また提案手法に関してもLLMによる文書拡張に留まらず、プロンプトの自動最適化まで踏み込んで取り組んでいる点が印象的でした。利用しているプロンプト最適化手法についても聞くことができ勉強になりました。ペルソナRAG: ペルソナ類似性に基づくパーソナライズ仮想レビュー生成概要レビュー履歴を元にしたペルソナ情報をLLMによって生成し類似ペルソナのレビュー検索結果を元にユーザのレビュー内容を予測する手法を提案面白かった点年齢や性別といったユーザ属性ではなく、ユーザのレビュー履歴からそのユーザが気にする観点や好みを抽出して利用している点が興味深かったです。レビュー結果の要約などは既存サービスでも増えてきていますが、レビュー内容のパーソナライズ化はあまり見ないため着眼点としても面白いなと思いました。意味埋め込みを用いた連邦型知識グラフ問い合わせにおける情報源選択概要分割された複数の知識グラフからグラフ内のエンティティの意味埋め込みを元に問い合わせに対応する知識グラフを選択する手法を提案面白かった点計算量を抑える工夫として、埋め込みで知識グラフをクラスタ化した上でクラスタ重心と問い合わせクエリとの類似度をとっているのは説明を聞いてなるほどと勉強になりました。知識グラフの検索はLLM時代において重要な技術の1つだと思うので今後の研究が楽しみだなと感じました。 Model Context Protocolを用いた二層知識継承による建築制約を持つ屋内シーン生成の自律的品質保証概要自然言語による3Dオブジェクト生成タスクにおいて幾何学的ハルシネーションを改善するためにMCP(Model Context Protocol)と静的・動的の知識データベースを用いた推論手法を提案面白かった点 3次元の建築物の情報を2次元画像としてLLMに与えるのではなく数値的に検証可能な3次元のjsonオブジェクトとして与える点、ユーザとのやりとりから知識データベースを動的に更新していく点が面白いなと感じました。本研究で扱っているようにフィードバックループによって利用回数を重ねるごとにどんどん賢くなる仕組みは私たちが取り組む機械学習やAIエージェント開発においても重要な観点だなと再認識しました。 BoF オンサイト1日目の夕方にはBoF(Birds of a Feather)と呼ばれる学生主催のワークショップが開催されていました。今年は「研究ライフをN倍ブチ上げるためにキミたちはどうしますか」というメインテーマのもと、各テーブルごとに下記のようなお題が与えられ、テーブル内の学生同士で意見を交わしていました。教授とのコミュニケーションどうしてる？後輩の面倒ってどのくらい見れてる？ AIをどう研究に活用している？ *(その他多数) この時間は食事やお酒も提供されてリラックスした雰囲気の中行われており、学生同士の会話の中には笑い声なども広がっているのが印象的でした。地元の日本酒も提供されていましたディナー懇親会オンサイト1日目の夜にはLayerX主催のディナー懇親会を開催しました。事前の申し込みやブース展示で興味を持っていただいた10名以上の学生とLayerX社員で食事をしながら交流をしました。 https://layerx.connpass.com/event/384917 この懇親会では、学生が取り組んでいる研究やコーディングエージェントの活用法について話題が上がり、研究への積極的な取り組みが伺えました。またLayerXへの入社理由やAIエージェント開発の現状、インターンシップの内容など、会社についても興味を持ってもらえる良い機会となりました。スポンサー賞オンサイト最終日はスポンサー賞授賞式も行われ、産学連携副委員長を務める松村が司会を担当しました。スポンサー各社が選出した発表チームへ、それぞれ賞の授与が執り行われました。スポンサー賞授賞式の様子さいごに登壇の機会をいただき、LayerXが目指す世界や機械学習技術そしてAIエージェントが切り開く未来について広くお伝えすることができました。また、企業展示ブースでは多くの方と直接お話しすることができ、非常に有意義な学会参加となりました。学会の運営に携わってくださった方々に感謝いたします。来年も開催されるDEIMのますますの発展に、LayerXも引き続き貢献できればと思います。 LayerXのインターンシップや新卒採用にご興味のある方は、下記リンクをご覧いただきぜひお気軽にご応募ください！ jobs.layerx.co.jp