夜間ログをAIが整理し、障害候補の朝用メモを自動作成する

自動化する仕事とL4の完成形

夜間ログを読み、翌朝向けに事象の一覧と確認箇所を作る部分を定期処理へ変えます。初回に入力元・モデル・実行時刻を設定した後は、毎回のプロンプト入力や承認なしでローカルのMarkdownとJSONを保存します。人は必要なときに一覧を読み、失敗時やルール変更時に保守します。業務上の判断や外部への送信をすべてAIへ任せる意味ではありません。

入力と出力

入力：既存のログ収集処理が書き出す、対象期間のid/text JSON。収集・個人情報除去は前工程です。対象期間を各行のtextへ含め、毎日5:50までにinput.jsonを更新します。運用ログを勝手に取得するコードはありません。

出力：障害候補・警告・通常の件数と原文付きの朝用メモ。架空データは各1件。障害の確定・自動復旧・アラート配信の代わりにはしません。既存の即時監視は継続します。

共通の入力形式は [{"id":"R01","text":"原文"}]。1回1〜30件、1行1000字・本文合計6000字までです。数値の件数はプログラムで数え、AIの自己申告を使いません。

用意する環境と5つの添付

Python 3.10以降、cronが動作する常時起動のUbuntu PC、ローカルOllamaと取得済みモデルを使います。PCのメモリ・空き容量・モデルの利用条件は導入前に確認してください。停止中やスリープ中のPCでは処理は回りません。

• local_batch.py：一括生成・形式確認・結果保存・二重処理防止。
• l4-logs_job.json：この業務の分類ルール。
• l4-logs_input.json：架空の練習入力。
• l4-logs_fixture.json：人が作ったテスト応答。AI推論ではありません。
• l4-logs.cron：定期実行の設定例。

初回だけ行う準備

1. Ollama公式の手順で導入します。ローカル専用にするため、Ollamaサービス側でクラウド機能を無効にします。Ubuntuのsystemdで動く場合は sudo systemctl edit ollama.service を開き、次の設定を追加します。既存の設定は維持してください。

[Service]
Environment="OLLAMA_NO_CLOUD=1"
Environment="OLLAMA_HOST=127.0.0.1:11434"

保存後に sudo systemctl daemon-reload と sudo systemctl restart ollama を実行します。公式FAQに沿って、journalctl -u ollama -n 50 で Ollama cloud disabled: true を確認してください。Python側だけの環境変数ではサービスへ反映されません。ほかの用途で共有中のサービスは、管理者と変更を調整します。 2. モデルを取得します。大きなダウンロードが発生するため、先に容量を確認します。

ollama pull qwen3:8b
ollama list

3. 添付5件を同じ専用フォルダへ保存します。コードは127.0.0.1のOllamaへ接続します。クラウド機能は前項のサービス設定で止め、PythonのHTTPプロキシとリダイレクトも無効にしています。モデル取得時の通信とローカル推論は別です。保存する原文根拠にも業務情報が含まれるので、フォルダを chmod 700 . で本人だけが読めるようにし、共有フォルダへ直接置かないでください。

外部モデルを呼ばずに流れを試す

python3 local_batch.py --config l4-logs_job.json --input l4-logs_input.json --fixture l4-logs_fixture.json --out practice

practice/nightly-log-note/fixture/ にMarkdownとJSONができ、上の練習結果と一致すれば形式上の動作は確認できます。同じコマンドを再実行すると既存の検証済み出力を再利用します。fixture結果が出ても、AIモデルや定期実行が動いた証拠にはなりません。

実モデルを1回試し、導入可否を決める

python3 local_batch.py --config l4-logs_job.json --input l4-logs_input.json --out practice

今度は practice/nightly-log-note/model/ に出力されます。初回だけ、入力全件の分類・要約・原文根拠を見比べます。ローカルAPIのJSON形式はOllama公式に基づきます。根拠の一致やIDの全件対応は機械検証しますが、意味の正しさは判定できません。誤分類が多い場合は導入せず、分類ルールやモデルを見直します。

毎日6:10に自動実行する

既存の入力処理を接続し、最新のinput.jsonを自動で用意できる状態にします。読みかけのJSONを渡さないよう、一時ファイルに書いてから同名へ置き換えてください。前工程の時刻と対象期間は各textへ記載します。更新から36時間を超えた入力は設定の max_input_age_hours に従って失敗にします。ファイルの更新時刻の確認であり、本文の対象日の正しさまでは判定しません。古い内容のまま時刻だけ更新しないでください。

l4-logs.cron の /ABS/WORK を実在する専用フォルダの絶対パスへ置き換えます。パスに空白のない場所を使い、/usr/bin/python3 が目的のPythonか確かめます。PCのタイムゾーンを確認したうえで crontab -e を開き、この行だけ追加します。既存の設定は消しません。crontab -l で登録を確認します。cronの時刻・書式はマニュアルを参照してください。

本番の定期コマンドに --fixture は付けません。初回の時刻後に output/nightly-log-note/model/last_success.json とjob.logを確認し、実際に定期起動したことを確かめてからL4運用へ移します。手動実行しかしていない状態はL4稼働済みとは扱いません。

異常時の扱い・停止・復旧

同じ入力と設定ならモデルを再度呼びません。入力が変わった場合だけ新しい出力を作ります。同時実行は.lockで拒否します。タイムアウトは240秒、再試行は自動で繰り返しません。入力・モデル・形式の失敗では終了コードが非ゼロになり、ロック取得後の失敗はlast_failure.jsonにも残ります。設定を読めない場合やロック衝突などはjob.logで確認します。

前回の成果物が残っていても今回成功とは限りません。保守担当は成功・失敗の時刻と入力対象日を確認します。監視への通知連携はこの添付には含まれません。必要なら既存の監視で終了コードと成功時刻を監視してください。

止めるときは crontab -e で該当する1行だけ削除またはコメント化します。異常終了で.lockが残った場合は、対応するプロセスが動いていないことを確認してから保守担当がロックを除去し、手動で1回検証して再開します。モデル生成を正常化する前にテスト応答へすり替えて成功扱いにしないでください。

検証範囲

コード・テスト応答・入出力形式・処理漏れ拒否・同一入力の再利用・失敗記録をローカルで検証する記事です。実Ollamaでの精度・CPU所要時間・cronの継続稼働・実務の削減時間は未測定です。L4は到達する運用の設計として示し、導入時の実モデルと定期起動の確認を必須にしています。新たなクラウドAPI契約やモデルの自動インストールは行いません。