LINEヤフーがセキュリティ業務向けAI基盤「SAGE」を公開　人間判断を残す3段階設計

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

公開日：2026年10月16日

3行解説

ニュースの概要

LINEヤフーのSecurity Development Division（LINE Plus Security R&D）チームは、社内のセキュリティガバナンス運用を支援するAIエージェント基盤「SAGE」について、開発記の第1弾を公開しました。記事では、セキュリティ業務にAIを入れる際の考え方として、完全自律ではなく、人間の判断を前提にした段階導入を採用した経緯を説明しています。SAGEは、Jiraベースの相談アシスタント、Slackベースの運用案内アシスタント、担当者向けWebの分析ワークベンチという3つの入口を持ち、共通の知識資産とAIオーケストレーション層を共有します。

何が新しいのか

新しい点は、AIを「答えを出す装置」としてではなく、判断の前段を支える仕組みとして設計していることです。第1段階では、AIが一次整理と根拠の収集を担当し、セキュリティ上の判断や例外承認は人間が行います。さらに、Jira、Slack、Webという入口ごとに役割を分けながら、裏側では同じ知識資産とオーケストレーション層を使う構成になっています。

また、技術面ではLangflow、GPT系モデル、Langfuse、MCP、OpenSearch Vector Store、Confluence、Jira、Slack、FastAPIなどを組み合わせています。単一のチャットボットではなく、役割の異なる複数エージェントでワークフローを分担している点も特徴です。セキュリティ業務のように、誤回答の影響が大きい領域では、この分割設計が実運用のしやすさにつながります。

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

注目すべきは、SAGEが「AIで自動化する範囲」を最初から広げすぎていない点です。記事では、Confluence、Jira、Slackに分散した資料をAIが集め、最終判断は人が担うと明示されています。これは、誤回答がそのまま誤った運用判断につながるセキュリティ業務では、実装の難しさよりも責任分界の設計が重要だということを示しています。導入企業は、AIの精度だけでなく、どこで人が止めるかを先に決める必要があります。

一方で、3つの入口を共通基盤で運用する構成は、便利な反面、権限管理や監査、ナレッジ更新の整合性が崩れると運用負荷が増えやすい設計でもあります。特に、Slackの一次案内とJiraの相談支援では、求められる厳密さが異なります。用途ごとに出力の責任境界を分けられるかが、実用化の分かれ目になるとみられます。

日本の現場で考えると

日本企業でこの種の仕組みを入れる場合、まず論点になるのは、社内規定や相談履歴がどこに散らばっているかです。記事のようにConfluence、Jira、Slackに情報が分かれている環境では、検索できるだけでは足りず、どの情報を正式な根拠として扱うかを決める必要があります。セキュリティ部門だけでなく、情シスや監査部門との役割分担も重要です。

向いているのは、問い合わせの一次整理、関連規定の提示、過去事例の検索のような定型寄りの業務です。慎重に見るべきなのは、例外承認や対外説明のように、誤りがそのまま事故につながる業務です。日本の現場では、AIの回答をそのまま使うのではなく、担当者が確認してから使う運用にしないと、現場定着は難しいでしょう。

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

• AIが参照する規定・履歴・チケットの権限分離をどう設計するか。
• Jira、Slack、Confluenceなど各入口で、回答の責任境界をどう分けるか。
• 検索精度と根拠提示の品質を、どの指標で確認するか。
• Langfuseのようなトレースで、失敗時に原因追跡できるか。
• モデルやワークフローを切り替える際、既存運用を止めずに移行できるか。

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

記事では、本番運用中であることは分かりますが、処理件数や精度指標、応答時間の改善幅は示されていません。また、権限設計の詳細、監査ログの保持方針、障害時の手動切替手順も一般化されており、外部からは確認できません。導入判断では、ここを追加で確認する必要があります。

セキュリティ業務のAI化は、モデル性能だけでなく、権限設計や監査、ナレッジ連携の作り込みが成否を分けます。社内のIT運用や保守業務でも同じ論点があるため、導入前の整理が重要です。

出典: LINEヤフー Tech Blog