サーバーの障害調査は、突き詰めると「ログを読む」作業だ。だが見慣れないエラーメッセージや、数千行のログから異常を探す作業は骨が折れる。ここ最近は、その最初の「当たりをつける」部分をLLM(ChatGPTやClaude、あるいはローカルのOllama)に任せると、原因究明が明らかに速くなった。この記事では、実際のサーバー運用でどうAIを組み込むか、そして丸投げしないための注意点をまとめる。
AIが効く場面・効かない場面
まず期待値を正しく持っておきたい。LLMが得意なのは次のような場面。
- 見慣れないエラーメッセージの意味と、典型的な原因の列挙
- 長いログから「それっぽい異常行」を拾い上げる一次スクリーニング
- 設定ファイル(nginx.confやsystemdのunit)のレビュー、書き間違いの指摘
- 複雑なワンライナーやオプションの意味の解説
逆に、そのサーバー固有の事情(過去の変更履歴、独自構成)は当然知らないし、断定的に間違った対処を提案してくることもある。「原因の候補を出させる相棒」であって「最終判断者」ではない、という距離感が大事。
いちばん手軽な使い方:ログを貼るだけ
難しく考えなくてよい。まずは該当ログを抜き出して、チャットにそのまま貼るだけでも十分効く。
journalctl -u nginx -p err --since "1 hour ago" --no-pagerこの出力をコピーして、「以下のnginxのエラーログの原因を推定して、確認すべき点を挙げて」と一言添えて貼る。プロンプトにDebian 13 / nginx 1.26 / PHP-FPM構成のように環境を書いておくと、回答の精度が上がる。
コマンドラインから直接AIに投げる
毎回コピペするのが面倒なら、ログをそのままAPIに流し込むと速い。ここではAnthropicのClaude APIに投げる例。ログを安全にJSONへ埋め込むためjqでリクエストを組み立てるのがコツ(ログ内の引用符や改行でJSONが壊れるのを防げる)。
LOG=$(journalctl -u php8.3-fpm -p err -n 50 --no-pager)
jq -n --arg log "$LOG" '{
model: "claude-sonnet-5",
max_tokens: 1024,
messages: [
{ role: "user", content: ("次のログのエラー原因と対処を日本語で簡潔に:\n\n" + $log) }
]
}' | curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @- | jq -r '.content[0].text'APIキーは環境変数ANTHROPIC_API_KEYから渡し、コードやシェル履歴に残さない。jqとcurlさえ入っていれば動くので、そのままエイリアスにしておくと調査が捗る。
機密ログはローカルLLM(Ollama)に投げる
ここが実運用でいちばん重要な判断ポイント。ログには内部IP・ホスト名・場合によっては個人情報やトークンが混ざる。そういったログを外部APIに送るのは情報漏洩リスクそのものだ。マスクするのが面倒な機密ログは、外に出さずローカルのOllamaに投げる。
LOG=$(journalctl -u nginx -p err -n 50 --no-pager)
ollama run llama3.2 "以下のnginxエラーログの原因と対処法を説明して:
$LOG"ローカル実行なのでログが手元から出ない。精度は外部の大型モデルに劣るが、一次切り分けなら3B程度のモデルでも十分役に立つ。GPUなしVPSでの現実的なスペックについては別記事にまとめている。
実例:502 Bad Gatewayの切り分け
nginxが502を返している時、エラーログにはこんな行が出る。
connect() failed (111: Connection refused) while connecting to upstreamこれをLLMに投げると、「upstream(この場合PHP-FPM)がダウンしているか、ソケットのパスが食い違っている可能性」を即座に指摘してくる。あとは自分でsystemctl status php8.3-fpmやss -x | grep phpで裏を取ればよい。ゼロから調べるより、当たりがついている分だけ速い。
丸投げしないための鉄則
- 機密情報を外部AIに送らない。IP・鍵・個人情報を含むログはマスクするかローカルLLMで処理する。
- 提案されたコマンドは必ず理解してから実行する。特に
rmや設定上書き、権限変更を伴うものは、意味を確認せず打たない。AIは平気で破壊的な操作を提案してくることがある。 - 回答は仮説として扱い、必ず自分で裏を取る。それらしく間違える(ハルシネーション)ので、最終的な根拠は自分の目で確認したログとコマンド結果に置く。
まとめ
サーバー運用にAIを組み込むと言っても、やることは「ログを投げて当たりをつけてもらう」というシンプルな話だ。手軽さと機密性のバランスで、外部API(Claude/ChatGPT)とローカルLLM(Ollama)を使い分ければ実用に足る。あくまで一次調査の相棒として使い、最終判断と実行は自分の手で行う——この線を守れば、障害対応のスピードは確実に上がる。
