LINEヤフーが社内RAG「team-brain」を構築、AIに任せる前提を整備

編集: グリットアーツ編集部

公開日：2026年9月30日

3行解説

ニュースの概要

LINEヤフーは、社内の知識を横断検索できるRAG「team-brain」の開発内容を公開しました。対象はConfluence、GitHub Enterprise、Slack、Jiraの4ソースで、毎日取り込みを行い、OpenSearchで検索できるようにしています。開発を担当したのは、モニタリングプラットフォーム「Yamas」を支えるメトリクスチームです。チームは6〜9名規模で、開発と運用を兼ねながらこの仕組みを作っています。

team-brainは、AIコーディングツールがチーム固有の情報を知らないという課題に対し、出典付きの検索結果を返す基盤として設計されています。回答文を生成するのではなく、検索結果をClaude Codeなどに渡す前提で作られている点が特徴です。

何が新しいのか

新しさは、RAGを「回答生成まで含むAI機能」ではなく、「一次情報を集める検索基盤」として割り切った点にあります。team-brainは生成LLMを持たず、検索結果と出典URLを返すだけです。そのため、プロンプト設計や会話管理、UIを作り込む必要がなく、責任範囲も「検索が正しいか」に絞れます。

もう1つの特徴は、4ソースを毎日取り込み、約11万チャンク規模のコーパスをOpenSearchのハイブリッド検索で扱っていることです。キーワード検索とベクトル検索を組み合わせ、チケットIDや関数名のような文字列検索と、意味で探す検索の両方に対応しています。さらに、Slack取り込みでは3,735チャンク中3,325件を再利用し、埋め込みAPI呼び出しを約89%削減しました。

グリットアーツ編集部の分析

この事例で重要なのは、AIの精度を上げる前に、検索の土台を整えていることです。Confluence、GitHub、Slack、Jiraのように情報が分散している現場では、生成AIだけを入れても根拠が弱く、誤回答の確認コストが残ります。team-brainは、まず出典を集めて検索できる状態を作り、その上でAIに任せる構造にしています。

また、差分埋め込みで再利用率を高めている点は、運用コストの見積もりに直結します。RAGは作るより、毎日更新し続ける方が難しいためです。埋め込みAPIの呼び出しを約89%減らせたのは、更新頻度を落とさずにコストを抑える設計として評価できます。一方で、gold setが10件と小さいため、検索品質の評価はまだ限定的です。

日本の現場で考えると

日本企業では、文書が日本語、コードが英語、会話がSlack、履歴がJiraという形で情報が分かれやすく、検索の難しさがそのまま属人化につながります。今回のように、検索対象を社内の一次情報に絞る設計は、開発・運用チームで特に相性がよいです。障害対応の経緯や設定値の決定理由を追う場面では、AIが答えるより、まず根拠を引けることが重要だからです。

一方で、生成まで一体化したRAGをいきなり入れると、誤回答の切り分けが難しくなります。既存のドキュメント管理、コード検索、チャット、チケット管理がすでにある企業ほど、まずは検索層を分けて整備する方が運用しやすいでしょう。日本語文書ではトークン数が増えやすく、長文やminifyされたコードの前処理も必要になるため、取り込み失敗時の扱いも事前に決めておくべきです。

導入・検討時に確認したいこと

• どの情報源を対象にするか。文書、コード、チャット、チケットの優先順位を決める。
• 検索精度の合格基準をどう置くか。recall@5やMRRのような指標を事前に決める。
• 更新頻度とコストの関係。毎日再取り込みする場合の埋め込みAPI利用量を確認する。
• 日本語文書や長いコードの前処理。トークン上限を超えたときの切り詰め方を確認する。
• 削除・更新時の安全策。取り込み失敗時に古い情報を消しすぎない仕組みが必要かを確認する。

現時点で分かっていないこと

公開情報だけでは、team-brainを他チームへ横展開できるかは分かりません。また、gold setが10件と小さいため、検索品質が他の業務領域でも同じように出るかは未確認です。OpenSearchや社内LLM APIゲートウェイの運用条件も、この記事だけでは判断できません。

社内の文書、コード、チャット、チケットが分散しているほど、AIより先に検索基盤の整備が効いてきます。既存環境の整理や運用設計を見直す際は、インフラ側の持たせ方も含めて検討すると判断しやすくなります。

出典: LINEヤフー Tech Blog