自己修復インフラの構築：単純なスクリプトからAI駆動の自動復旧へ

Table of Contents

従来の自動化 vs. AIによる自己修復の比較

以前の私は、PrometheusのアラートとBashスクリプトを頼りに、夜通しサーバーの監視に明け暮れていました。NginxがクラッシュすればSystemdの再起動ポリシーで対処し、200GBのルートパーティションが90%のしきい値に達すれば、Cronジョブで機械的に/tmpを削除していました。これは「決定論的自動化」です。問題を定義（if）し、解決策をハードコード（then）する手法です。

これらのスクリプトは、想定外の事態が起きるまでは機能します。しかし、非常に脆いのが難点です. エラー文字列のわずかな変更や、APIの高並列実行時のみ発生するメモリリークのような複雑なマイクロサービスの相互作用により、標準的なスクリプトは役に立たなくなります。ほとんどのスクリプトは「盲目的」であり、サービスがなぜ停止したのかという本質を理解せず、単に特定の文字列を探しているに過ぎません。

AI駆動の自己修復は、この状況を一変させます。500個もの壊れやすい正規表現パターンをメンテナンスする代わりに、生のログを大規模言語モデル（LLM）に投入します。AIは意図を解釈し、異常を特定し、的確な修正案を提示します。これにより、場当たり的なトラブルシューティングから、予期せぬエッジケースにも対応できるインテリジェントな自動復旧へと移行できるのです。

本番環境インフラにおけるAIの現実

従来のシステム管理者から現代のプラットフォームエンジニアへと転身するには、新たな思考モデルが必要です。パイプラインにLLMを追加することは魔法の解決策ではありませんが、正しく使えば強力な武器になります。

メリット

深い相関関係の把握: LLMsは、深夜の障害対応中に人間が見落としがちな、データベースの負荷急増と認証サービスのログエラーの間の関連性を見抜くことができます。
文脈に応じたインテリジェンス: 単なる grep とは異なり、AIは「Connection refused」というエラーが、ある状況ではファイアウォールの遮断を、別の状況ではリスナー의 クラッシュを意味していることを理解します。
可読性の高い監査ログ: AIに判断理由を平易な言葉で説明させることができるため、自動出力されるログはポストモーテム（事後分析）において非常に価値のあるものになります。

トレードオフ

ハルシネーション（幻覚）: これは避けて通れない課題です。AIが存在しないCLIフラグを捏造したり、最悪の場合、システムディレクトリの再帰的な削除を提案したりする可能性があります。
レイテンシの代償: GPT-4o-miniの呼び出しには2〜5秒の遅延が生じます。これはミリ秒単位のフェイルオーバーではなく、複雑な診断タスクに向いています。
運用コスト: すべてのログ行をAPIで送信すると、コストが瞬く間に膨れ上がります。100万入力トークンあたり0.15ドルという価格を考慮し、分析対象を慎重に絞り込む必要があります。

初心者のための実践的なラボ環境の構築

いきなり本番環境のデータベースで試してはいけません。まずは月額5ドルのVPSなどで小規模に始めましょう。信頼できるプロトタイプ構築のためのおすすめの構成（スタック）は以下の通りです。

言語: Python 3.10以降（AI統合の標準）。
ログ監視: watchdog ライブラリ、またはシンプルな tail -f サブプロセス。
AIの脳: 速度を重視するならOpenAI API、データのプライバシーを重視するならLlama 3をローカルで実行するOllamaインスタンス。
実行環境: 壊滅的なコマンド実行を防ぐため、制限されたシェル環境。

実装ガイド：最初の自動復旧ツールの構築

私はこれらのシステムを、監視、コンテキスト収集、推論、安全な実行の4つの段階で構成しています。今すぐデプロイできる設計図を紹介します。

ステップ1：監視（ログモニタリング）

syslogを常時監視するスクリプトが必要です。エラーが発生してから数時間後ではなく、発生した瞬間に捉える必要があります。

import subprocess
import time

def tail_logs(logfile):
    # 古い履歴を無視するためにファイルの末尾に移動
    with open(logfile, 'r') as f:
        f.seek(0, 2)
        while True:
            line = f.readline()
            if not line:
                time.sleep(0.1)
                continue
            if any(word in line.upper() for word in ["ERROR", "FAILED", "CRITICAL"]):
                yield line

ステップ2：システムコンテキストの収集

単独のエラーログだけでは不十分です。AIが適切な判断を下すためには、サーバーの「バイタルサイン」（ディスク容量、RAM使用量、アクティブなプロセスなど）を知る必要があります。

def get_system_context():
    # ディスク統計とメモリ消費量トップ5のプロセスを取得
    df = subprocess.getoutput("df -h /")
    top_proc = subprocess.getoutput("ps aux --sort=-%mem | head -n 5")
    return f"ディスク使用量:\n{df}\n主要プロセス:\n{top_proc}"

ステップ3：JSON出力による推論

構造が重要です。AIにJSONオブジェクトを返させることで、Pythonスクリプトが面倒な文字列解析なしにプログラムで出力を処理できるようにします。

def ask_ai_for_remediation(error_log, context):
    prompt = f"""
    システムエラー: {error_log}
    サーバーの状態: {context}
    
    役割: シニアSRE。エラーを分析し、安全なBashコマンドを提案してください。
    制約: JSONのみを返してください。
    形式: {{"reason": "説明", "command": "bash_command"}}
    """
    # ここでAPIクライアントを使用（OpenAI、Anthropic、またはローカルのOllama）
    # return response.json_content

ステップ4：キルスイッチ（安全な実行）

最初からAIにコマンドを自律実行させてはいけません。私は、暴走したスクリプトがパーミッションの問題を「解決」しようとしてWebルート全体をchmod 777にしようとしたことで、痛い目を見ました。必ず手動の確認ステップを挟みましょう。

import json

def execute_fix(ai_json_response):
    data = json.loads(ai_json_response)
    print(f"診断結果: {data['reason']}")
    print(f"提案された修正案: {data['command']}")
    
    # セーフティネット
    if input("実行しますか？ (y/n): ").lower() == 'y':
        result = subprocess.run(data['command'], shell=True, capture_output=True, text=True)
        print(f"出力: {result.stdout}")
    else:
        print("ユーザーにより操作が中断されました。")

完全な自律化に向けて

自信がついてきたら、 systemctl restart や docker-compose pull のようなリスクの低いコマンドを自動化できます。私は、許可されたアクションの厳格な「ホワイトリスト」を維持しています。もしAIがリスト外のことを提案した場合、システムは即座に人間のエンジニアにエスカレーションします。

自己修復インフラの構築は、プロンプトを洗練させ、安全境界線を強化していく道のりです。このフレームワークに従うことで、火消しに追われる日々を脱し、自ら修復するシステムの構築を開始できます。そうすれば、アーキテクチャの設計や新機能の開発により多くの時間を割けるようになるでしょう。