OllamaでLinuxのログを自動解析する方法|journalctlとシェルスクリプトでエラーを要約・分類してcronで自動化する

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)ローカルLLM > OllamaでLinuxのログを自動解析する方法|journalctlとシェルスクリプトでエラーを要約・分類してcronで自動化する
「journalctlのエラーログが多すぎて、毎朝ログ確認だけで30分以上かかっている」
「重大なエラーを見落としていないか不安だが、複数台のサーバーログを目視確認するのは現実的ではない」

そんな悩みを抱えるLinuxサーバー管理者は多いはずだ。この記事では、OllamaのREST APIとシェルスクリプトを組み合わせて、Linuxのエラーログをローカル環境で自動要約・分類する仕組みの構築方法を解説する。
journalctlでエラーを抽出し、curlでOllamaに渡して原因と対処案を日本語で出力させ、cronで日次実行するまでを順を追って説明する。ログデータを外部サービスに送ることなく、サーバー上だけで処理が完結するのがこのアプローチの核心だ。

この記事のポイント

・journalctl -p err の出力をcurlでOllamaのAPIに渡してエラーを自動要約できる
・シェルスクリプト1本で取得・解析・メール通知まで一気に自動化できる
・cronで日次実行することでログ確認の工数をほぼゼロに近づけられる
・プロンプトに役割指定と出力フォーマットを明記すると解析精度が大きく上がる


OllamaでLinuxのログを自動解析する方法|journalctlとシェルスクリプトでエラーを要約・分類してcronで自動化する

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

なぜLinuxログの自動解析にローカルLLMが有効なのか

Linuxサーバーの運用で毎日直面する作業の一つがログ確認だ。journalctl -xeで流れてくるエラーを見ながら「これは重大か、それとも無視していいのか」を判断するのは、熟練者でも時間がかかる。

複数台のサーバーを少人数で管理している環境では、全台のログを毎日目視確認するのは現実的ではない。重大なエラーが埋もれてしまい、気づいた時には障害が広がっていた、というケースは現場でよくある話だ。

ELKスタックやDatadogを使えばログの可視化・集約ができる。しかし初期構築コストと運用負荷が高く、1人や2人で管理する規模のサーバーには過剰になりやすい。ローカルLLMを使うアプローチは、そこまで大げさな構成を取らなくても「重大なエラーを自然言語で要約してもらう」ことが手軽にできる点が特徴だ。

クラウドのAI APIを使えばもっと簡単に実現できる。しかし、サーバーログには認証失敗の記録、IPアドレス、ユーザー名など機密性の高いデータが含まれることがある。外部サービスにログデータを送るリスクを考えると、Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイドで紹介した構成を活用して、社内ネットワーク内だけで処理を完結させる方が安全性の面では正しい選択だ。

情報セキュリティの観点から社内でクラウドAIが使えない環境での代替策としてローカルLLMがどう機能するかは、社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢でも詳しく解説している。

事前準備|Ollamaの起動とモデルの確認

Ollamaが起動しており、ログ解析に使うモデルが取得済みであることを確認する。
ログ解析には推論力の高いモデルが向いている。7Bクラスでも動作するが、エラーの原因分類と対処案の具体性を上げたいなら14B以上が安定する。VRAM容量に合わせて量子化モデルを選択する。量子化タグの選び方についてはローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイントで詳しく解説しているので合わせて参照してほしい。

1. Ollamaが起動しているか確認する

systemctlでサービス状態を確認し、APIが応答するかをcurlで確認する。

# サービス状態の確認 $ systemctl status ollama * ollama.service - Ollama Service Loaded: loaded (/etc/systemd/system/ollama.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2026-07-20 06:00:00 JST; 2h 30min ago # APIエンドポイントへの疎通確認 $ curl -s http://localhost:11434/api/version {"version":"0.6.1"}

2. 使用するモデルを確認・取得する

ollama listで取得済みモデルを確認する。ログ解析に使うモデルがなければollama pullで取得する。

# 取得済みモデルの一覧確認 $ ollama list NAME ID SIZE MODIFIED llama3.3:70b-instruct-q4_0 a1b2c3d4e5f6 40 GB 2 hours ago mistral:7b-instruct-q4_K_M b2c3d4e5f6a7 4.1 GB 3 days ago # モデルが未取得の場合はpullする(VRAMが8GB程度ならmistral:7b-instruct-q4_K_Mから始める) $ ollama pull mistral:7b-instruct-q4_K_M pulling manifest... pulling f974a74358d6... 100% ▕████████████████▏ 4.1 GB success

VRAMが8GB程度の環境では mistral:7b-instruct-q4_K_M(4.1GBクラス)から始めるとよい。
32GB以上あるなら llama3.3:70b-instruct-q4_0 を使った方が要約の質と原因特定の精度が上がる。

基本動作の確認|journalctlの出力をcurlでOllamaに渡す

シェルスクリプトを作る前に、まず手作業でjournalctlの出力をOllamaに渡す一連の流れを確認する。
コマンドの挙動を把握してから自動化するのがトラブルを減らすコツだ。

1. journalctlでエラーログを抽出する

journalctlの -p(priority)オプションを使うとログレベルで絞り込める。err以上を過去1時間分だけ取り出す。

# 過去1時間分のerrレベル以上のログを取得する $ journalctl -p err -S "1 hour ago" --no-pager -o short-iso 2026-07-20T03:12:05+09:00 srv01 sshd[3901]: error: PAM: Authentication failure for user01 2026-07-20T03:14:22+09:00 srv01 postfix/smtp[4022]: connect to mail.example.com:25: Connection refused 2026-07-20T03:15:01+09:00 srv01 kernel: EXT4-fs error (device sda1): ext4_validate_block_bitmap_csum

-p errはerr・crit・alert・emergの4レベルを含む。warning(警告)も対象にしたい場合は -p warning に変える。
--no-pagerを付けないとlessが起動してしまうので必ず付けること。
-o short-isoはISO8601形式のタイムスタンプで出力するオプションで、ログ解析スクリプトで時刻を扱う際に便利だ。

2. curlでOllamaのREST APIにログを送る

journalctlの出力をシェル変数に入れてcurlでPOSTする。これで基本的な流れが確認できる。

# ログをシェル変数に格納(先頭50行に絞る) LOG_TEXT=$(journalctl -p err -S "1 hour ago" --no-pager -o short-iso 2>/dev/null | head -50) # JSONエスケープしてOllamaにPOSTする PROMPT="以下のLinuxサーバーログにあるエラーを、原因と対処案を含めて日本語で3行以内に要約してください:\n${LOG_TEXT}" curl -s http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d "{\"model\":\"mistral:7b-instruct-q4_K_M\",\"prompt\":\"${PROMPT}\",\"stream\":false}" \ | python3 -c "import sys,json; print(json.load(sys.stdin)['response'])"

3. レスポンスの出力例を確認する

上記コマンドを実行すると以下のような応答が返ってくる。

# Ollama(mistral:7b-instruct-q4_K_M)の応答例 3種類のエラーが確認されます。 (1) sshd の PAM 認証失敗はブルートフォース攻撃の可能性があります。 fail2ban-client status sshd でブロック状況を確認し、ログイン試行上限を設定することを推奨します。 (2) postfix の SMTP 接続失敗はメール送信先サーバーへの到達不可を示します。 dig MX mail.example.com でDNS解決を確認し、ファイアウォール設定も見直してください。 (3) ext4-fs のビットマップ検証エラーはディスク異常の前兆の可能性があります。 smartctl -a /dev/sda で SMART 情報を確認してください。深刻度:高

streamをfalseにすると全レスポンスを一括で受け取れる。jqがインストールされていれば `jq -r '.response'` の方がシンプルだ。
LOG_LINES=50 程度に絞っているのは、一度のプロンプトに大量のログを詰め込みすぎるとコンテキストウィンドウを超えて精度が落ちるためだ。

シェルスクリプトで自動化する|log-analyze.shの実装

動作確認ができたら、実運用で使えるシェルスクリプトに仕上げる。
ここでは「毎朝AM6時に昨夜のエラーを要約してメールで受け取る」という典型的なユースケースを実装する。

1. スクリプト置き場を作成する

# スクリプト用ディレクトリを作成する $ sudo mkdir -p /opt/scripts $ sudo chown "$(whoami):$(whoami)" /opt/scripts

2. log-analyze.sh を作成する

以下がスクリプトの全体構成だ。set -euo pipefailで予期しないエラーを即座に検知できる構成にしている。

#!/bin/bash # log-analyze.sh - Ollamaでerrログを要約してメール通知する set -euo pipefail # ---- 設定値(環境に合わせて変更する) ---- OLLAMA_URL="http://localhost:11434/api/generate" MODEL="mistral:7b-instruct-q4_K_M" MAIL_TO="admin@example.com" LOG_LINES=80 TIME_RANGE="8 hours ago" # ---- 設定値ここまで ---- # エラーログを取得する LOG_TEXT=$(journalctl -p err -S "${TIME_RANGE}" \ --no-pager -o short-iso 2>/dev/null | head -${LOG_LINES}) # ログがなければ正常終了する if [[ -z "${LOG_TEXT}" ]]; then echo "[$(date '+%Y-%m-%d %H:%M:%S')] エラーログなし。処理を終了します。" exit 0 fi # プロンプトを組み立てる(改行をJSONエスケープする) PROMPT_RAW="あなたは10年以上の経験を持つLinuxサーバー管理者です。 以下のエラーログを解析し、次の形式で回答してください。 1. エラーの種類を列挙する 2. 各エラーの深刻度(高/中/低)と推定原因を示す 3. 対処が必要なものは実行可能なコマンドを1つ提示する 回答は日本語で番号付き箇条書きにしてください。 --- ${LOG_TEXT}" ESCAPED_PROMPT=$(printf '%s' "${PROMPT_RAW}" \ | python3 -c "import sys,json; print(json.dumps(sys.stdin.read()))") # Ollamaへリクエストを送る RESPONSE=$(curl -sf "${OLLAMA_URL}" \ -H "Content-Type: application/json" \ -d "{\"model\":\"${MODEL}\",\"prompt\":${ESCAPED_PROMPT},\"stream\":false}" \ | python3 -c "import sys,json; print(json.load(sys.stdin)['response'])") # メールを送信する SUBJECT="[LOG-ALERT] $(hostname) - エラーログ要約 $(date '+%Y-%m-%d')" printf "ホスト: %s\n日時: %s\n\n%s\n" \ "$(hostname)" "$(date '+%Y-%m-%d %H:%M:%S')" "${RESPONSE}" \ | mail -s "${SUBJECT}" "${MAIL_TO}" echo "[$(date '+%Y-%m-%d %H:%M:%S')] 要約メールを送信しました: ${MAIL_TO}"

3. 実行権限を付けて動作確認する

# 実行権限を付与する $ chmod 755 /opt/scripts/log-analyze.sh # 手動で一度実行して動作を確認する $ /opt/scripts/log-analyze.sh [2026-07-20 06:00:01] 要約メールを送信しました: admin@example.com

4. cronで日次実行する

cronに登録して毎朝AM6時に自動実行するよう設定する。

# crontabを編集する $ crontab -e # 以下を追記する(毎朝6時にスクリプトを実行してログに記録) 0 6 * * * /opt/scripts/log-analyze.sh >> /var/log/log-analyze.log 2>&1

cronは通常のインタラクティブシェルと環境変数が異なるため、スクリプト内のコマンドはすべてフルパスで書くか、スクリプト冒頭でPATHを明示的に設定するようにする。
動作しない場合は /var/log/log-analyze.log にエラーが記録されているのでまずここを確認する。

解析精度を上げるプロンプト設計

自動化した後に気になるのがLLMの出力品質だ。同じログデータでも、プロンプトの書き方次第で回答の質は大きく変わる。
現場のインフラエンジニアから聞いた話をもとに、実用的なポイントを3つに絞って解説する。

1. 役割指定と出力フォーマットを明示する

プロンプトの冒頭にLLMの役割を明示すると、回答の方向性が定まりやすい。さらに出力フォーマットを指定すると、メールで受け取った時に読みやすい形式で返ってくる。

# 役割指定と出力フォーマットを加えたプロンプト例 あなたは10年以上の経験を持つLinuxサーバー管理者です。 以下のエラーログを解析し、次の形式で回答してください: 【エラー名】sshd 認証失敗 【深刻度】高 【推定原因】ブルートフォース攻撃の可能性 【推奨コマンド】fail2ban-client status sshd --- ${LOG_TEXT}

「推奨コマンドを実行可能な形式で」と指定すると、「smartctl -a /dev/sda」や「fail2ban-client status sshd」のようにそのまま実行できるコマンドが返ってくるようになる。この指定がないと「ログを確認してください」のような曖昧な回答になることが多い。

2. ログを絞り込んでからLLMに渡す

コンテキストウィンドウは有限だ。80行を超えるログを一度に渡すと後半のエラーが無視されることがある。対策として、grep・sortでサービス別に集計してから渡すと精度が上がる。

# サービス別エラーを集計して上位パターンだけ渡す例(sshd関連) $ journalctl -p err -S "8 hours ago" --no-pager -o short-iso \ | grep "sshd" | sort | uniq -c | sort -rn | head -10 42 2026-07-20T03:01:05+09:00 srv01 sshd[3901]: error: PAM: Authentication failure for invalid user admin 18 2026-07-20T04:22:11+09:00 srv01 sshd[4012]: error: PAM: Authentication failure for user root 3 2026-07-20T05:00:44+09:00 srv01 sshd[4103]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key

同一パターンのエラーが50件あっても、LLMに送る際は uniq -c で集計した数行に圧縮すると効率がよい。1つのリクエストに詰め込みすぎず、サービス別に分けて複数回リクエストを送る構成の方が出力品質が安定する。

3. 深刻度フィルタで通知量を絞る

すべてのエラーを毎日メールで受け取ると通知疲れが起きる。LLMの応答に「深刻度:高」が含まれる場合だけ追加アラートを送る二段階構成が実用的だ。

# 深刻度「高」を含む場合は別途緊急通知を送る(log-analyze.shに追記する) if echo "${RESPONSE}" | grep -qE "深刻度.*(高|CRITICAL|HIGH)"; then printf "[CRITICAL] %s で深刻なエラーを検出\n%s\n" \ "$(hostname)" "${RESPONSE}" \ | mail -s "[CRITICAL] 緊急ログアラート $(hostname)" oncall@example.com fi

ログ量が多い日の対応|サービス別分割処理

週末や長期連休明けにログが大量に蓄積することがある。一度に全件を処理しようとするとOllamaへのリクエストがタイムアウトしたり、コンテキストウィンドウを超えたりする。

対策として、ログをサービスごとに分割して複数回のリクエストに分けて処理する方法が安定する。

# サービスリストを定義して1つずつ処理する例(log-analyze.shに追加する) SERVICES=("sshd" "postfix" "nginx" "httpd" "kernel") FULL_REPORT="" for SERVICE in "${SERVICES[@]}"; do LOG_TEXT=$(journalctl -p err -S "${TIME_RANGE}" --no-pager -o short-iso \ | grep "${SERVICE}" | head -30 2>/dev/null) if [[ -z "${LOG_TEXT}" ]]; then continue fi echo "[$(date '+%Y-%m-%d %H:%M:%S')] ${SERVICE} のログを解析中..." # 各サービスの解析結果をFULL_REPORTに蓄積する # (前述のcurl部分でRESPONSEを取得し、FULL_REPORT="${FULL_REPORT}\n${RESPONSE}" で追記) done

サービス別に処理を分けることで各リクエストのプロンプトサイズが一定に保たれ、出力品質が安定する。
curlの --retry 3 --retry-delay 5 オプションを付けると簡易リトライが機能するので、Ollamaが高負荷時にタイムアウトした場合の対策としても有効だ。

また、num_ctxパラメータでモデルのコンテキストサイズを明示的に設定することで大きめのログをまとめて処理できる。

# num_ctx を指定してコンテキストサイズを増やす例(VRAMに余裕がある場合) $ curl -s http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d "{\"model\":\"${MODEL}\", \"prompt\":${ESCAPED_PROMPT}, \"stream\":false, \"options\":{\"num_ctx\":8192}}"

注意点とトラブルシュート

ログデータの取り扱いについて

journalctlの出力にはユーザー名・IPアドレス・メールアドレスなど個人情報に該当する可能性があるデータが含まれることがある。このスクリプトはローカル処理のため外部送信は行わないが、解析対象のログ範囲は最小限にしておくことが望ましい。
特定ユーザーのアクセス履歴を含むログを使う場合は、社内のデータ取り扱いポリシーに沿っているか事前に確認する。

curlが「Failed to connect」になる場合

Ollamaが起動していないか、ポートが異なる可能性がある。

# Ollamaプロセスの状態を確認する $ systemctl status ollama # 環境変数でポートを変更している場合はoverride.confを確認する $ cat /etc/systemd/system/ollama.service.d/override.conf [Service] Environment="OLLAMA_HOST=0.0.0.0:11435" # 上記の場合はスクリプト内のOLLAMA_URLを変更する OLLAMA_URL="http://localhost:11435/api/generate"

python3コマンドが見つからない場合

pythonコマンドのエイリアスが通っていない環境がある。jqがインストールされていれば代替として使うことを推奨する。

# jqをインストールする $ sudo dnf install jq # RHEL/AlmaLinux系 $ sudo apt install jq # Ubuntu/Debian系 # curlの応答からレスポンスを取り出す(jq版) $ curl -s http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d "{\"model\":\"mistral:7b-instruct-q4_K_M\",\"prompt\":\"テスト\",\"stream\":false}" \ | jq -r '.response'

LLMの応答が空文字になる場合

モデルのコンテキストウィンドウを超えている可能性がある。LOG_LINESの値を50以下に下げるか、num_ctxパラメータでコンテキストサイズを明示的に設定する。
Ollamaの応答が遅く途中で接続が切れる場合は、curlに --max-time 120(秒)を付けてタイムアウトを延ばすとよい。

本記事のまとめ

journalctlとOllamaを組み合わせることで、Linuxサーバーのエラーログを毎朝自動で要約・分類できる仕組みが構築できる。ログデータを外部に送らずローカル処理で完結する点は、業務環境での採用ハードルを大きく下げる。プロンプトの役割指定と出力フォーマットを丁寧に設定すれば、実運用に耐えるレベルの自動化基盤になる。
やりたいこと コマンド・手順
Ollamaの起動を確認する systemctl status ollama
取得済みモデルを確認する ollama list
過去8時間のerrログを取得する journalctl -p err -S "8 hours ago" --no-pager -o short-iso
curlでOllamaに問い合わせる curl -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d '{"model":"モデル名","prompt":"質問","stream":false}'
JSONレスポンスからテキストを取り出す curl ... | jq -r '.response'
スクリプトをcronで毎朝6時に実行する 0 6 * * * /opt/scripts/log-analyze.sh >> /var/log/log-analyze.log 2>&1
コンテキストサイズを増やして精度を上げる curl ... -d '{"model":"...","prompt":"...","stream":false,"options":{"num_ctx":8192}}'

ローカルLLMとLinuxサーバー自動化を2日間のハンズオンで体験する

実際にOllamaをセットアップし、ログ解析スクリプトを構築して実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。

>> ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。