AIに全部作らせない。通知・ログの緊急度判定をローカルLLMに任せ、人間は最後の決定ボタンを押すだけの二層防御

[!NOTE]
【この記事の要約（TL;DR）】
* 課題: クラウドLLMへの生ログ送信は、ログ量に伴うAPI費用の増加や、機密情報を含むログの外部送信リスクを伴いやすい。
* 解決策: 文章生成ではなく「緊急度トリアージ（分類・要約）」に特化した軽量ローカルLLMを配置し、端末内で安全かつAPI従量課金なしで一次選別を行う。
* 設計思想: AIに全自動で対処させず、「機械側の選別（ルール＋ローカルLLM）」と「人間側の承認（決定ボタン）」を明確に分ける二層防御が最も破綻しにくい。

---

1. 「AIによる全自動化」が現場で直面する現実

近年、AIエージェントにすべてを任せて自律的にタスクを完結させる「完全自動化」の話題が注目を集めています。しかし、日々の開発やサーバー監視などの運用現場において、すべてをクラウドAIに丸投げしようとすると、2つの現実的な課題に直面しやすくなります。

一つ目は 「API費用の管理コスト」 です。日々出力される大量のエラーログやヘルスチェック通知をすべてクラウドの商用LLMへ送信し続けると、ログの急増時にトークン消費が跳ね上がり、想定以上のAPI課金が発生するリスクがあります。

二つ目は 「データプライバシーの管理」 です。システムのエラーログや通知には、内部パス、個人情報、アクセスキー、スタックトレースといった機密情報が含まれがちです。これらを無防備に外部APIへ送信することは、セキュリティポリシー上好ましくないケースが多く見られます。

---

2. 生成ではなく「判断・トリアージ」に特化させるアプローチ

そこで有効なアプローチが、AIに長文を書かせるのではなく、「判断特化（トリアージ役）」 としてローカルLLMを活用する設計です。

1B〜3Bクラスの軽量なローカルLLM（Ollama等で動作するオープンウェイトモデル）は、長大な文章生成では上位モデルに及ばないものの、「このエラーログは即時対応が必要な重大障害か、定時警告か」といった 「限定的な分類・重要度判定」 であれば十分に機能します。

ただし、モデルの精度や応答速度はマシンスペック、量子化方式、入力長によって変動します。そのため、実務では 「第0層として正規表現やログレベルによるルールベース判定を前置し、既知の定型ログや明白な重大障害を先に仕分けた上で、未分類のログのみをローカルLLMに渡す」 というハイブリッド構成が不可欠となります。

---

3. 実装の骨格：構造化検証と安全側に倒す振り分け設計

ローカルLLMを実運用に組み込む際は、「モデル出力を過信せず、検証失敗時は安全側に倒す」 3段階のバリデーションを設けます。

1. JSONスキーマ強制: OllamaのStructured Outputs等を活用し、決まった形式のみを出力させる。
2. スキーマ検証: 出力が期待通りのキーと値（High / Medium / Low）を持つかプログラム側で検証する。
3. 安全側へのフォールバック: パース失敗やタイムアウトが発生した場合は、無視せず「要確認キュー」へ回す。

### ローカルLLMへの判定指示プロンプト例（構造化指定）

あなたはシステム運用のトリアージ担当です。
入力ログを解析し、緊急度と理由をJSON形式で出力してください。

【緊急度の基準】
- High: サービス停止の兆候、セキュリティ警告、複数機能の障害
- Medium: 軽微なタイムアウト、再試行可能な一時的警告
- Low: 定期バッチの正常完了、既知の軽微な通知

【入力ログ】
{system_log_content}

【出力JSONスキーマ】
{
  "level": "High" | "Medium" | "Low",
  "reason": "判定理由（50文字以内）"
}

誤判定を見逃さない振り分けルール

軽量LLMによる誤判定（重大な警告を Low と判定してしまう等）のリスクに備え、通知の振り分けは以下のように多重化します。

---

4. 人間は「最後の決定ボタンを押すだけ」という二層防御

この設計の核心は、「機械側の選別」 と 「人間側の承認」 を明確に切り分ける二層防御にあります。

AIの役割は、膨大な生ログからノイズを削ぎ落とし、緊急度を分類して、人間が判断しやすいように 「下準備（トリアージと要約）」 を整えることまでです。

人間側には、SlackのInteractiveボタン（「再試行」「再起動」「無視」）やWebダッシュボード上に優先度順で配膳され、開発者はコンテキストを把握した上でボタンを押すだけで対処が完了します。

flowchart TD
    subgraph Layer1["【第1層：機械側の選別（自動化）】"]
        A["膨大な生ログ・通知"] --> B0{"第0層：ルールベース判定"}
        B0 -->|重大インシデント| D["即時アラート通知"]
        B0 -->|既知の定型正常ログ| E["自動記録・破棄"]
        B0 -->|未分類・異常ログ| B1["ローカルLLMトリアージ"]
        B1 -->|High判定| D
        B1 -->|Medium判定| F["確認トレイへ蓄積"]
        B1 -->|Low判定| E
        B1 -->|パース失敗・エラー| F
    end

    subgraph Layer2["【第2層：人間側の承認ゲート（決定権）】"]
        D --> G["Slack / Webダッシュボード<br>（要約付き1タップ承認UI）"]
        F --> G
        G --> H["開発者が確認・決定ボタンを押下"]
        H --> I["安全な復旧・対処アクション"]
    end

AIに最後の復旧コマンド実行まで自動で委ねる「完全自動化」は、予期せぬ誤動作を引き起こす傾向があります。

「機械（ルール＋ローカルLLM）が一次選別と要約を泥臭くこなし、人間は優先順位のついたトレイから決定ボタンを押すだけ」

この二層防御スタイルこそが、API課金やプライバシー流出に悩まされず、個人開発や中小規模のシステムを最も長く安定して運用し続けるための現実的な解となります。

---

まとめ：判断の分担がもたらす持続可能な開発

「AIにすべてを任せる」のではなく、「AIに適切なトリアージ役を任せる」。

1. 生ログの一次判定はローカルLLMを活用し、API従量課金と機密データ送信リスクを抑制する。
2. 第0層のルールベース判定と組み合わせ、マシンの推論負荷と誤判定リスクを抑える。
3. 判定失敗時は安全側に倒し、最後の実行トリガーは人間が承認する「二層防御」を敷く。

AIに適切な役割分担を与えることで、開発者は通知疲れから解放され、本当に重要な判断に集中できるようになります。

---