ローカルLLMに工場の現場を「読ませる」：simpliSOCでセキュリティアラートと機械ログを解説する

日本のある製造拠点で、同じ一つの出来事について、二人の担当者がそれぞれ別の理由で理解できずにいる場面を想像してください。

SOCアナリスト(もしいれば)はWazuhのアラートを目にします。FC 15 write multiple coils, srcip 10.0.4.71, dst PLC-04, 02:14。これはセキュリティのシグナルであり、Modbusのファンクションコードを知っていれば読み取れます。

現場のシフトリーダーには何も見えないか、HMIにFAULT 0x22という表示と赤いランプだけが見えます。これは設備側のシグナルであり、そのラインの故障コード0x22の意味を知っていれば読み取れます。

どちらの担当者も、理解できなくて当然です。どちらのログも人間ではなく機械のために圧縮された形式であり、実際のリスク——物理的にせよサイバー的にせよ——に最も近い場所に立っている人が、その形式を解読する訓練を受けているとは限らないからです。本稿では、この隔たりをローカル言語モデルで埋めるパターンについて解説します。片方はsimpliSOCがすでに本番環境で行っていること、もう片方は同じ発想の自然な延長として、私たちが構築する価値があると考えているものです。

1. 振り返り:まずOT層の可視化を得ること

モデルが何かを説明できるようになる前に、まず「聞く」仕組みが必要です。可視化の部分については、Why Your Factory Floor Is the Softest Target in Your Networkで詳しく取り上げました。OTスイッチ上のパッシブなネットワークTAPまたはSPANポート、Modbus TCPとEtherNet/IPを構造化ログへとデコードするZeekセンサー、そしてそのログをSOCバックエンドへ転送するWazuhエージェント——これらすべてが、PLCに対してうまく処理できないかもしれないアクティブなプローブパケットを一切送信せずに実現されます。

このアーキテクチャによって、構造化されたOTイベントのストリームが得られます。誰がどのPLCと、どのプロトコルで、どのファンクションコードを使って、いつ通信したか。これが素材です。本稿が扱うのは、Wazuhが何かにフラグを立てた後、そのストリームに何が起きるか——そして同じ発想を、隣にある設備ヘルスログにも拡張できるかどうかという問いです。

flowchart TD
    PLC1["PLC Modbus TCP"]
    PLC2["PLC EtherNet IP"]
    HMI["HMI Workstation"]
    SW["OT Switch SPAN Port"]
    TAP["Network TAP"]
    ZEEK["Zeek Sensor"]
    WZ["Wazuh Manager OT Rules"]

    PLC1 --> SW
    PLC2 --> SW
    HMI --> SW
    SW --> TAP
    TAP --> ZEEK
    ZEEK --> WZ

2. 前半:セキュリティアラートの解説——これは今日すでに実現していること

この部分は推測ではありません。simpliSOC製品ページに記載されているAI支援トリアージは、条件を満たすWazuhアラートに対してすでにローカルLLMを実行しており、クライアント自身のネットワーク内で動作するOpenAI互換エンドポイント(Ollama、llama.cpp、vLLM、LocalAI)を通じて提供されています。アラートと周辺のアクティビティを読み取り、平易な言葉での説明とtrue/false-positiveの判定を、自動または要求に応じて付与します。

同じ仕組みを、上記のパッシブタップアーキテクチャから得られるOTルールに向けると、IT向けのアラートよりも大きな効果が期待できます。対象となる読み手が異なるからです。SOCアナリストはすでにWazuhの「言葉」を理解していますが、現場の設備担当者やシフトリーダーは通常そうではなく、何かが発報したときに実際の設備に最も近い場所にいる最初の人物であることが多いのです。

生のアラートと、モデルが返す内容を比較してみましょう。

Wazuhの生アラート:

rule.id: 100045
rule.level: 12
agent: zeek-ot-sensor-01
modbus.func_code: 15
modbus.dst_ip: 10.0.2.14 (PLC-04)
modbus.src_ip: 10.0.4.71
timestamp: 2026-09-02T02:14:03+09:00

モデルによる構造化出力:

{
  "severity": "high",
  "asset": "PLC-04 (押出成形ライン2)",
  "summary": "このPLCへの書き込み履歴がないホストが、午前2時14分にwrite-multiple-coilsコマンドを送信しました。予定されている22:00-23:00のメンテナンス時間帯外です。",
  "context_check": "本日夜間、ライン2に対する保守チケットは開かれていません。送信元IPはベンダーVPNの範囲と一致しません。",
  "recommended_action": "escalate_and_verify_physically",
  "confidence": 0.78
}

この2番目のブロックは、コイルが何かを知らなくても、シフトリーダーが行動に移せる内容です。モデルが保守時間帯との比較を勝手に作り出しているわけではありません——SOC Integratorが、Using Small Language Models to Detect Cyber Attacks from Wazuh Logs and Firewall Syslogで説明されているパターンと同様に、IT向けアラートですでに行っているのと同じ方法で、その文脈(開いている保守チケット、既知のベンダーIP範囲)を取得しているのです。OT向けに実際に変わるのは、プロンプト内の語彙と、SOC Integratorが付与するフィールドだけです——ユーザー名の代わりに設備名、通常の営業時間の代わりに保守時間帯、従業員のIP範囲の代わりにベンダーVPNの範囲、といった具合です。

3. 後半:同じパターンを設備ヘルスログへ——これはロードマップの構想であり、出荷済み機能ではありません

ここで、何がすでに存在し、何を私たちが構築すべきだと考えているかを正確に区別することが重要です。simpliSOCはセキュリティスタックです。今日の時点では、PLCの故障コード、historianタグのドリフト、HMIのアラームログを読み取ることはなく、本セクションの内容はsimpliSOCの現在の機能を説明するものではありません。

私たちが構築する価値があると考えているのは次のことです。同じローカルモデルを、同じオンプレミスのエンドポイントから提供しつつ、第二の役割を与える。WazuhのOTアラートを読む代わりに、simpliFactoryのようなシステムがすでに工場の現場レベルで取得している運用ログのストリーム——故障コード、仕様範囲を外れてドリフトするタグ値、HMI上のアラームバースト——を読み取り、セキュリティアナリストではなく保守担当者に向けた、同種の平易な言葉による構造化された説明を生成する、というものです。

この構想が単なる図解以上の価値を持つ理由は、経済性にあります。Choosing Hardware for Local LLMs in 2026: A Practical Sizing Guideで示されているような形でローカル運用される7B〜14Bのモデルは、1回の呼び出しあたりのコストが十分に低く、単一のワークロードだけで正当化する必要がありません。工場にすでにセキュリティトリアージを行うローカルエンドポイントがあれば、異なるプロンプトと異なる出力スキーマを持つ第二の利用者を追加することは、新規プロジェクトというよりも設定変更に近いものになります——これはWhy Enterprises in Southeast Asia and Japan Are Moving LLMs Inside the Firewallで述べられている、オンプレミス方式そのものの論拠でもあります。個人情報保護法(APPI)の下でのデータ越境移転に関する制約に加え、経済安全保障推進法が特定重要物資・基幹インフラの供給網に求めるデータ管理の厳格さや、NISCが製造業の重要インフラ事業者に求めるセキュリティ対策の観点からも、機微な運用データを一つのオンプレミス基盤に閉じて扱えることは、単なる技術選択以上の意味を持ちます。

flowchart TD
    OTLOG["OT Security Log Stream Wazuh"]
    MESLOG["Machine Health Log Stream MES Historian"]
    LLM["Local LLM Endpoint Ollama or vLLM"]
    SOCOUT["Plain Language Security Explanation"]
    MESOUT["Plain Language Fault Explanation Roadmap"]

    OTLOG --> LLM
    MESLOG --> LLM
    LLM --> SOCOUT
    LLM --> MESOUT

設備ヘルス側で想定される構造化出力の例——あくまでパターンを示すもので、実在するスキーマではありません:

{
  "asset": "押出成形ライン2 - ゾーン3ヒーター",
  "fault_code": "0x22",
  "summary": "過去40分間でゾーン3の温度が設定値より8パーセント低い方向にドリフトしており、センサー故障よりもヒーター素子の部分的な劣化と一致するパターンです。",
  "similar_history": "同様のドリフトパターンが、2026年3月14日のゾーン3ヒーター交換の直前にも見られました。",
  "recommended_action": "schedule_inspection_before_next_shift",
  "confidence": 0.65
}

これを既製の予知保全ソフトウェアと分けるものが二つあります。セキュリティのユースケースですでに正当化されている同じオンプレミスモデル上で動く点、そして保守チームにトレンドグラフを読ませるのではなく、彼らの言葉で故障を説明する点です。

4. ガードレールは両方の半分に適用され、OTではその重要性がさらに増す

セキュリティ側のルールはそのまま引き継がれ、ここではむしろ重要性が増します。モデルはあくまで助言に留まります。 要約し、分類し、推奨するだけであり、セキュリティケースを自動で閉じることも、設定値を自動で調整することも、機械のアラームを自動で確認することもありません。定められた重大度のしきい値を超えるすべての行動は、人間が確認します。

これはITよりもOTにおいて重要性が増します。失敗のモードが物理的だからです。ITアラートでfalse positiveを誤って判定しても、失うのはアナリストの時間だけです。しかし「これは無視していい、ヒーターがドリフトしているだけだ」というfalse negativeが、実際には未承認の設定値変更だった場合、結果はまったく異なるレベルのものになります。逆に、実際の機械的な故障をセキュリティインシデントとして扱ってしまえば、工場は誤った理由で生産ラインを止めることになります。このパターンのセキュリティ側も設備ヘルス側も、判断を委ねられるべきものではなく、実際に判断する人物へ迅速に説明するために信頼されるべきものです。

もう一つのガードレールは、OT可視化の取り組みからそのまま引き継がれます。ここで説明する仕組みは、PLCへの書き込みや設定値の調整、OTネットワークへの能動的な操作を一切行いません。モデルはすでに存在するログを読み取り、テキストを生成するだけです。これはZeekセンサーが採用しているのと同じパッシブな姿勢を、収集層で止めるのではなく推論層にまで広げたものです。

5. 工場のセキュリティやMESに関する検討への示唆

すでにOTルール付きでWazuhを運用している場合、それらのアラートにローカルLLMによる説明層を拡張することは、新しいアーキテクチャの検討ではなく、スコープの検討です。IT向けアラートですでに本番運用されているエンドポイント、SOC Integratorのエンリッチメントのパターン、ガードレールの設計をそのまま再利用できます。

まだそれ以前の段階にある場合——工場現場のデータを取得するMESはあるがOTセキュリティの可視化がまだない、あるいはその逆の場合——検討すべきは、どちらのストリームから計装するかという順序の問題です。私たちの標準的な推奨は、6月の記事で説明したパッシブなOTタップとWazuhルールから始めることです。監視されていないOTネットワークは今日すでに存在するリスクであり、下振れリスクが最も大きい部分だからです。その上で、ローカルLLMによる説明層と設備ヘルスへの拡張は、説明する価値のあるログストリームが整った段階で進めるのが適切です。

よくある質問

simpliSOCは現在、セキュリティイベントだけでなく機械の故障も診断できますか?
いいえ。simpliSOCのローカルLLMトリアージは、セキュリティアラート向けにすでに出荷されている機能です。本稿で説明した設備ヘルスへの応用は、同じアーキテクチャの延長として提案しているものであり、現時点での機能ではありません。

このいずれかによって工場のデータが工場ネットワークの外へ送信されることはありますか?
ありません。ローカルLLMはクライアント自身のネットワーク内にあるハードウェア上で動作し、OpenAI互換のエンドポイント(Ollama、llama.cpp、vLLM、またはLocalAI)を通じて提供されます。セキュリティログであれ機械ログであれ、これが機能するためにネットワークの外へ出るデータはありません。

モデルはPLCに対して操作を行ったり、設定値を調整したりできますか?
できません。構造化されたログデータを読み取り、テキストを生成するだけです。推奨されるすべての行動は人間が実行する必要があり、このパターンのいかなる部分もOT機器へ書き戻しを行いません。

まだOTネットワークの可視化ができていない場合はどうすればよいですか?
まずそこから始めてください。ローカルLLMによる説明層には、読み取るべきログストリームが必要です。私たちのOT可視化に関する記事で説明したパッシブなZeek/Wazuhタップは、稼働中のPLCに触れることなく、それを最も低いリスクで得る方法です。

出典:

• simpliSOC — Open-Source Security Operations Platform
• Why Your Factory Floor Is the Softest Target in Your Network
• Using Small Language Models to Detect Cyber Attacks from Wazuh Logs and Firewall Syslog
• Choosing Hardware for Local LLMs in 2026: A Practical Sizing Guide
• Why Enterprises in Southeast Asia and Japan Are Moving LLMs Inside the Firewall
• simpliFactory