「膨大なログ調査も自然言語で」 生成AIとRAGを使った運用効率化：ITインフラ担当者のための生成AI活用術（3）
ITインフラの構築・運用フェーズで生成AIがどう役立つのかを解説する本連載。今回は、インフラ運用における生成AI活用のアプローチを解説します。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
ITインフラの構築・運用フェーズで生成AI（人工知能）がどう役立つのかを解説する本連載。前回は「インフラ構築における生成AIの活用」をテーマに、MCP（Model Context Protocol）を使って「Terraform」の最新ドキュメントを参照し、最新仕様に基づいてITインフラを構築する方法を解説しました。
今回は「インフラ運用における生成AIの活用」をテーマに、RAG（Retrieval Augmented Generation：検索拡張生成）を用いてインフラ運用業務を効率化する具体例を解説します。
パフォーマンス監視、障害対応、セキュリティ管理……インフラ運用担当者の課題
インフラ運用担当者は、システムのパフォーマンス監視、障害対応、セキュリティ管理など、幅広い業務を担っています。その際に必要となる主な情報源が、サーバやネットワーク機器から収集されるログデータです。障害が発生した際には、この膨大なログデータを分析し、原因を特定して対策を講じる必要があり、これが大きな負担となっています。
熟練した担当者であれば、ログから異常の兆候を素早く見つけ出し、適切に対応できます。しかし、経験が浅い担当者にとっては簡単ではありません。とはいえ、組織として業務を行う以上、誰が担当しても同じレベルの成果を出せるように、いわゆる「業務の標準化」が求められます。
この課題を解決に導く技術が、RAGです。RAGは、生成AIが外部の知識ベースから必要な情報を検索し、その結果を踏まえて回答を生成する手法です。これにより、膨大なログデータの中から関連情報を正確に取り出し、自然言語での質問に対して適切な回答を提示できるようになります。
そこで本稿は、このRAGを用いてインフラ運用を効率化するアプローチを解説します。
生成AIやRAGがITインフラ運用の課題解決に役立つ理由
まずRAGとは何かを語るために、「RAGのない世界」と「RAGのある世界」を対比してみましょう。
RAGのない世界
ユーザーが「有給は何日取得できる？」と質問したとします。RAGを使わない場合、チャットアプリケーションはこの質問をそのままLLM（大規模言語モデル）に渡し、モデルに回答させようとします。
しかし、LLMは、公開されているインターネット上の情報を基に事前学習されており、一般的な知識については答えられるものの、企業独自の就業規則といった社内固有の情報は学習していません。そのため、こうした固有情報に関しては、正確な回答を返すことができません（図1）。
RAGのある世界
RAGのある世界では、チャットアプリケーションが質問の意図を解析し、関連する情報を外部の知識ベースから検索します。例えば、社内の就業規則ドキュメントから「有給取得に関する規定」を見つけ出し、LLMがその内容に基づいて回答を生成します（図2）。
図2の処理をもう少し詳しく説明します。図中の番号を追ってみましょう。
- 管理者はまず、社内の就業規則ドキュメントを外部データベースに格納します。このような用途では、キーワード検索を行える全文検索システムや、文章を数値ベクトルに変換して保存し、高速に類似検索を実行できるベクトルデータベースを利用することが一般的です。サービスとしては「Elasticsearch」やMicrosoft Azureの「Azure AI Search」があり、ローカル環境で利用する場合は「ChromaDB」などがあります
- ユーザーがチャットアプリケーションに「有給は何日取得できる？」と質問します
- チャットアプリケーションは、質問の意図を解析し、外部データベースに対して関連情報を検索します。この際、質問文をそのままキーワードとして検索する方法や、質問文をベクトル化して類似度の高い文章を検索する方法などがあります
- 外部データベースは、質問に関連する情報をチャットアプリケーションに返します。例えば「有給取得に関する規定」が見つかります
- チャットアプリケーションは、ユーザーからの質問と外部データベースで取得した関連情報をまとめてLLMに渡し、その情報を基に回答を行わせます
- LLMは、提供された情報を基に回答を生成し、チャットアプリケーションに返します
- チャットアプリケーションは、生成された回答をユーザーに提示します
このように、RAGを活用することで、LLMは外部の知識ベースから必要な情報を取得し、その情報を基に正確な回答を生成できるようになります。これにより、企業固有の情報に関する質問にも対応可能となり、インフラ運用においては、ログ分析や障害対応といった業務の効率化にも期待できるというわけです。
ITインフラの状態をAIに問い合わられる仕組み どう構築するのか
RAGを活用したインフラ運用の具体例として、サーバのログ情報を基にインフラの状態を問い合わせるシナリオを考えてみましょう。
ある企業では、複数のサーバが稼働しており、各サーバから定期的にログ情報が収集されています。インフラ運用担当者は、これらのログ情報を基にシステムの状態を把握し、異常が発生した場合には迅速に対応する必要があります。
しかしながら、ログ情報は膨大であり、手動で分析するのは困難です。前述したように、熟練者であれば容易な異常検知であっても、経験の浅い担当者にとってはハードルの高い作業となります。
この問題を解決するために、RAGを活用したチャットbotシステムを導入します。このシステムは、サーバから収集されたログ情報を外部データベースに格納し、インフラ運用担当者が自然言語で質問できるようにします。チャットbotは、質問に関連するログ情報を検索し、その情報を基に回答を生成します。
システム構成
このシナリオにおけるシステムの構成を、図3で示します。
図3の構成を図中の番号を追って説明します。
1. ログ収集
まずは各サーバからログを収集します。ログの収集には、オープンソースのテレメトリーエージェント（ログ・メトリクス収集ツール）である「Fluent Bit」を利用します。Fluent Bitは軽量であり、多様な出力先に対応しているため、ログ収集に適しています。このFluent Bitを各サーバにインストールし、定期的にログを収集して、HTTP経由でログ収集APIに送信します。
2. ログ登録
ログ収集APIは、受け取ったログを整形し、ベクトルデータベースに保存します。その際、ログのタイムスタンプ（日時）とログ本文を分けて格納します。ログ本文はベクトル化して保存し、ログの日時はメタデータとして記録します。
このように「本文（ベクトル）」と「日時（メタデータ）」を分離して保存する理由については、後述する「Metadata Filtering」で詳しく説明します。
ログを登録するデータベースについては、ローカル環境で動作するChromaDBを利用します。ChromaDBは、文章をベクトル化して保存し、高速に類似検索を実行できるベクトルデータベースです。
3. 質問入力
インフラ運用担当者は、チャットアプリケーションのインタフェースを通じて、自然言語で質問を入力します。例えば「2026年1月13日の11時ごろに起きたOOM-Killerの原因を教えて」といった質問です。チャットアプリケーションの画面は、Pythonで簡単にUI（ユーザーインタフェース）を構築できる「Streamlit」というライブラリを利用して実装します。
4. 検索
チャットアプリケーションは、質問の内容をベクトル化して、ベクトルデータベースに対して類似検索を行います。
5. 生成
チャットアプリケーションは、ベクトルデータベースから取得した関連ログ情報を基に、LLMに質問内容と関連ログを渡し、回答の生成を行わせます。LLMには以下のようなプロンプトを渡します。
あなたはインフラ運用担当者です。以下のログ情報を基に、質問に回答してください。 ログ情報から得られる内容以外からの回答は避けてください。 質問: 2026年1月13日の11時ごろに起きたOOM-Killerの原因を教えて ログ情報: [2026-01-13 11:45:22 +0000] kernel: Out of memory:…
6. 回答返却
チャットアプリケーションは、LLMから生成された回答をインフラ運用担当者に返却します。「2026年1月13日の11時ごろに発生したOOM-Killerの原因は、メモリ不足によるものであり、特定のプロセスが過剰にメモリを消費していたことがログから確認されました」といった回答です。
このようなプロセスで、インフラ運用担当者は自然言語で質問するだけで、膨大なログ情報から必要な情報を迅速に取得できるようになります。これにより、インフラ運用の効率化と障害対応の迅速化が期待できます。
Metadata Filtering（メタデータフィルタリング）について
インフラ運用におけるRAGの活用例において、ログをベクトルデータベースに保存し、質問に関連するログを検索する仕組みを紹介しました。その際、詳しくは説明しませんでしたが、実はログを丸ごと保存するのではなく、ログのタイムスタンプ（日時）をメタデータとして分離して保存しています。
なぜログのタイムスタンプを本文とは分けて、メタデータとして保存するのでしょうか。その理由は検索精度を高めるためです。
ベクトルデータベースでは、ログ本文をベクトル化することで、エラー内容や障害の傾向といった「意味的な類似性」に基づいた検索が可能になります。しかし、検索対象となるログの件数が多ければ多いほど、無関係なログが混ざりやすくなり、検索結果のノイズも増えてしまいます。
そこで重要になるのが、検索対象をあらかじめ絞り込むことです。ログの場合、ユーザーの質問に「◯月◯日の◯時ごろ」といった日時情報が含まれることは珍しくありません。このような場合、まず日時を条件としてログを絞り込み、そのうえでベクトル検索を行うことで、より少ないログ集合を対象に意味検索を実行できます。
検索対象が少なくなればなるほど、無関係なログが混ざる可能性は下がり、結果としてベクトル検索の精度が向上します。このため、ログの日時情報はベクトル化せず、メタデータとして保持し、フィルタリングに利用するという設計を採用しています。この改善手法をMetadata Filteringと呼びます。
つまり、ログ本文は「意味で検索するため」にベクトル化し、日時は「検索範囲を狭めるため」にメタデータとして扱うという役割分担です。この分離によって、ログ検索におけるノイズを抑え、より的確な検索結果を得られるようになります。
Metadata Filteringの処理の流れを、図4に示します。
図4の処理を図中の番号を追って説明します。
1. 整形
Fluent Bitはサーバから受け取ったログを整形し、ログ本文とタイムスタンプに分離します。ログからタイムスタンプを抽出する方法は、ログフォーマットに依存しますが、一般的には正規表現を用いて抽出します。例えば、以下のようなログエントリがあるとします。
[2026-01-13 11:45:22 +0000] kernel: Out of memory:…
この場合、正規表現を使って「2026-01-13 11:45:22 +0000」というタイムスタンプ部分を抽出し、残りの部分をログ本文として以下のように分離します。
- ログ本文： kernel: Out of memory:…
- タイムスタンプ： 2026-01-13 11:45:22 +0000
2. ログ送信
Fluent Bitは、整形したログ本文とタイムスタンプをログ収集APIに送信します。
3. ログ登録
ログ収集APIは、受け取ったログ本文をベクトル化し、ベクトルデータベースに保存します。その際、タイムスタンプはメタデータとして保存します。
4. 質問入力
運用管理者は、チャットアプリケーションのインタフェースを通じて、自然言語で質問を入力します。「2026年1月13日の11時ごろに起きたOOM-Killerの原因を教えて」といった質問です。
5. 生成依頼
運用管理者がチャットアプリケーションに入力した質問文から、まず日時情報を抽出します。この場合、「2026年1月13日の11時ごろ」といった表現から、検索に使用する時間範囲を特定します。
自然言語で書かれた質問文のような非構造化データから特定の情報を取り出すタスクは、LLMが得意とする分野です。ここでは、日時情報の抽出に特化したプロンプトを用います。
あなたは日時抽出専用のアシスタントである。
ユーザーの日本語の質問文から、「検索したい時間範囲（開始と終了）」だけを抽出し、次のJSON形式で出力せよ。
{
"start": "2026-01-14T17:00:00+00:00",
"end": "2026-01-14T18:00:00+00:00"
}
制約:
- 出力はJSONオブジェクト1個のみとする
- 出力の前後に改行や説明文を付けてはならない
- 「```」で囲むコードブロックや「json」という文字列を絶対に出力してはならない
- 悪い例: ```json\n{...}\n```
- 出力は必ず次のような1行のJSONだけにすること:
{"start": "...","end": "..."}
- ISO8601形式（YYYY-MM-DDTHH:MM:SS）で出力すること
- タイムゾーンは考慮せず、そのままローカル時刻でよい。つまり必ず+00:00を付与すること（例: 2026-01-14T17:00:00+00:00）
- もし終了時刻が明示されていない場合は、開始から1時間後をendとしてよい
- 日付が特定できない場合は、今から24時間以内の範囲を仮置きでよいが、その場合でも必ず上記JSONフォーマットで出力せよ
- JSON以外の文字は一切出力してはならない
このプロンプトでは、ユーザーの質問文から日時情報を抽出し、検索に使用する開始時刻（start）と終了時刻（end）をJSON形式で出力するよう指示しています。また、質問文に終了時刻が含まれていない場合には、開始時刻から1時間後を終了時刻として補完するルールを設けています。
このようにして抽出された時間範囲を基に、ログをメタデータで絞り込み、ベクトル検索の対象を最小限に抑えることで、検索精度を高めています。
6. 結果返却
LLMが抽出した時間範囲をチャットアプリケーションに返します。
7. 検索
チャットアプリケーションは、LLMから取得した時間範囲を基に、ベクトルデータベースに対してメタデータフィルタリングを適用し、指定された時間範囲内のログのみを対象にベクトル検索を実行します。
このようにメタデータフィルタリングを活用することで、ログ検索の精度を向上させ、より的確な情報を取得できるようになります。
まとめ
今回は、インフラ運用における生成AI活用の具体例として、RAGを用いた自然言語によるログ情報の検索および回答生成の仕組み、システム構成のイメージを解説しました。
次回は、今回紹介したシステムをどのように実装するのかを、動作するサンプルコードを交えながら詳しく解説します。
筆者紹介
武井宜行
サイオステクノロジーに所属し、AzureやAI領域でのシステムインテグレーションや製品開発に取り組むエンジニア。Microsoft MVPとして認定され、YouTubeなどのメディアで「わかりみ深い」Azureの情報を日々発信している他、執筆活動（書籍『世界一やさしいRAG構築入門』）を通じて知識を広く共有している。
Copyright © ITmedia, Inc. All Rights Reserved.
アイティメディアからのお知らせ
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。