研究開発の部門が長時間の試験を回す試験機の運転ログから、条件外れ・停止・設定変更を拾い、試験機ごとの日々の要約にする

処理の起点を決める

起点は Schedule Trigger で、毎朝6時に動かします。 研究者が出社する前に要約がそろっているようにします。

ワークフローのタイムゾーンを必ず設定します。 公式のページでは、ワークフローにタイムゾーンが無ければインスタンスのタイムゾーンを使い、自社で動かすインスタンスの既定は America/New York とされています。「前日の0時から24時」の区切りもこのタイムゾーンで決まるので、設定しないと区切りが半日ずれます。

休日は動かしたうえで送らない、にします。 休み明けの朝に、休日の日数分の要約を1日ずつ並べて送ります。まとめて1つの要約にしないのは、日ごとに区切っておくと、どの日の何時に起きたかを試験記録の表にそのまま写せるからです。

Schedule Trigger は、ワークフローを保存して公開しないと動きません。 公式のページにそう書かれています。

入力データを集める

質を決めるのは、イベントの語の表です。 機種ごとに「STOP」「停止」「Halt」「Interlock」のように言葉が違うので、どの語がどの種類に当たるかを機種ごとに1行ずつ書きます。 この表で印を付けておけば、AIに渡す前に行の種類が決まっています。

試験計画の表には、許容幅を数字で書きます。 「おおむね一定」のような書き方では、規則で外れを拾えません。数字で書けない試験は、この構成の対象から外します。

データの取得方法を決める

ファイルは Read/Write Files from Disk で読みます。 File(s) Selector にはパスか glob のパターンを書けます。公式のページでは * がパスの区切りを含まない任意の文字、 がパスの区切りを含む任意の文字とされています。試験機ごとのフォルダの下の前日の日付のファイルを、パターン1つで取ります。**

n8n 2.0 以降は、読める場所が既定で絞られています。 公式のページでは、2.0 から N8N_RESTRICT_FILE_ACCESS_TO の既定が ~/.n8n-files になり、それ以外の場所を読むにはこの変数をはっきり設定するとされています。ファイルサーバーの共有をマウントしたディレクトリを、この変数に指定します。 Docker で動かす場合は、パスはコンテナの中のものを指すので、共有をボリュームとしてコンテナにマウントします。

マウントは読み取りだけにします。 n8n からログのファイルを書き換えられる経路を作りません。

文字コードを最初に確かめます。 古い機種の制御ソフトは、ログを日本語の古い文字コードで書くことがあります。読み込んだ行が文字化けしていないかを、機種ごとに1回ずつ確かめます。 文字化けした行は、イベントの語の表に当たらず、黙って「その他」に落ちます。

AIへ渡す前に整形する

1. 前日分への切り出し … ワークフローのタイムゾーンで0時から24時の行だけを残します
2. 繰り返しのまとめ … 同じメッセージが続く行は、最初と最後の時刻と回数の1行にまとめます
3. イベントの印 … イベントの語の表で、停止・アラーム・設定の変更・破断・扉の開閉・その他の印を付けます
4. 条件外れの区間 … 制御値の各行を許容幅と比べ、外れが続いた区間を、開始・終了の時刻と最大の外れの値の1行にします
5. 区間の前後のイベントの添付 … 各区間の開始の前後30分にあるイベントの行を、その区間に添えます
6. 記録の欠け … 制御値の記録の時刻の間隔が、決まった間隔の数倍空いていれば「記録の欠け」の区間にします

2番目を省くと、AIに渡す行が数千行になります。 アラームが鳴り続けた夜のログは、同じ行がほとんどを占めます。まとめても、最初と最後の時刻と回数が残るので、何が起きたかは失われません。

6番目は、条件外れより見落とされやすい異常です。 記録が欠けた区間は、制御値が許容幅の中にあったのか外れていたのかが分かりません。外れの区間と同じ重さで研究者に出します。

4番目の「外れが続いた区間」には、続いた時間の下限を置きます。 制御値の記録は一定の間隔で書かれるので、1点だけ許容幅を外れて次の点で戻るものもあります。1点ごとに区間にすると、試験機によっては1日に数百の区間が出て、要約が区間の羅列になります。 何点続いたら区間とするかは、試験計画の表に試験ごとの列として持たせ、研究者が決めます。決まるまでは1点でも区間にし、件数を見てから下限を決めます。

破断と試験の終了は、区間を拾う前に確かめます。 試験片が破断した時刻より後の制御値は、試験の条件として意味を持ちません。破断の印の付いた行があれば、その時刻より後は区間を拾わず、「破断後」として切り分けます。

AIに処理させる

させるのは、前処理が出した「条件外れの区間」「記録の欠け」「印の付いたイベントの行」を、試験機ごとに時刻の順の短い要約にまとめることだけです。

各文には、根拠にしたログの行をそのまま写した quotes を付けさせます。 Claude の公式の案内では、作り話を減らす方法として、主張ごとに引用を付けさせて検証できるようにすることと、分からないときは分からないと言ってよいと明示することが挙げられています。

指示内容を固定する

Basic LLM Chain の Chat Messages の System に次の文を入れます。

あなたは研究開発部の評価グループで、試験機の前日の運転の記録を
研究者向けに短くまとめる立場です。
渡された「条件外れの区間」「記録の欠け」「イベントの行」だけを使ってください。

【まとめ方】
- 前日の運転の状態を、次のどれか1つで書く
    運転を続けた／止まって再開した／止まったまま／試験片が破断した
- 起きたことを時刻の順に、1つの出来事を1文で書く
- 条件外れの区間と記録の欠けは、時刻と値を渡された値のまま書く
- 設定の変更は、時刻・項目・変更前と変更後の値を書く
- 理由がイベントの行から読み取れないものは、ask_researcher に入れる

【厳守事項】
- 各文の quotes に、根拠にしたイベントの行を一字一句そのまま写してください。
  写す行が無い文は書かないでください。
- 渡された行に無い出来事を書かないでください。
- 停止やアラームの原因を言い切らないでください。
  「〜の直後に停止」のように、ログに書かれた順序だけを書いてください。
- 数値を計算し直したり、丸めたりしないでください。
- 試験を有効・無効とする判断や、再開・設定についての勧めを書かないでください。
- 分からないことは「ログからは分からない」と書いてかまいません。
- 何も起きていなければ、状態を「運転を続けた」とし、events を空にしてください。

【試験機】{machine_id}　【試験の番号】{test_id}
【許容幅】{tolerances}
【条件外れの区間と記録の欠け】{segments}
【イベントの行】{event_lines}

「写す行が無い文は書かない」を入れるのは、もっともらしい説明を止めるためです。 停止の行の前にアラームの行があると、AIは「アラームにより停止」と書きたくなります。ログが言っているのは順序だけで、因果は研究者が判断することです。

「何も起きていなければ events を空に」を明記するのは、何も無い日に何かを書かせないためです。 指示しないと、平穏な日にも「温度は安定していた」のような文を足し、根拠の行が付かない文が混ざります。

出力形式を固定する

Require Specific Output Format をオンにして Structured Output Parser をつなぎ、次の形で受け取ります。

{
  "machine_id": "F-07",
  "test_id": "T2026-118",
  "date": "2026-10-27",
  "run_state": "止まって再開した",
  "events": [
    { "time": "02:14", "kind": "停止",
      "text": "02:14 に停止。直前の 02:11 から槽内温度のアラームが38回続いていた",
      "quotes": ["2026/10/27 02:14:05 STOP by INTERLOCK"] }
  ],
  "segments": [
    { "start": "02:09", "end": "02:31", "item": "槽内温度", "max_dev": "+3.1℃" }
  ],
  "ask_researcher": ["03:02 の再開の前に荷重の上限が変更されている理由"],
  "summary": "02時台に温度のアラームの後に停止し、03時に設定を変えて再開した。"
}

1つ目の理由は、quotes を Code ノードで照らせることです。 写された行が前日のログに一字一句あるかを文字列で探し、1つでも見つからなければ、その要約は研究者に送らず、ログの抜粋のまま送ります。 要約が無くても、拾い出しの結果は届きます。

2つ目は、segments を前処理の値と照らせることです。 AIが値を書き写すときに丸めたり桁を変えたりしていないかを、Code ノードで前処理の値と比べます。

3つ目は、run_state を試験記録の表の列にそのまま入れられることです。 4つの値に決めてあるので、月末に「止まって再開した」日を試験機ごとに数えられます。

スキーマは $ref を使わずに書きます。 公式のページでは、Structured Output Parser の JSON Schema で参照（$ref）を使えないとされています。

システムへ連携する

研究者の「確認済み」は、Slack の Send and Wait for Response で受けます。 Response Type を Approval にし、Capture Who Responded をオンにして、誰が確かめたかを記録に残します。 Restrict Who Can Approve で、その試験の担当の研究者に絞ります。

週の終わりには、1週間分の要約を Summarization Chain でまとめます。 公式のページでは、Map Reduce は塊ごとに要約してから要約どうしをまとめる方法で、推奨の選択肢とされています。日ごとの要約を塊にして、試験ごとの週の動きを評価グループの会議に出します。

人が確認する

1. 要約と根拠の行を読む … 要約の文と、付いているログの行が合っているかを見ます
2. ask_researcher を必ず片付ける … 理由が分からない停止や設定の変更は、試験の担当や夜間の当番に確かめます
3. 気になる区間はグラフで確かめる … 条件外れの区間は、制御値の記録を開いて形を見ます
4. データの扱いを書く … その区間のデータを使うか除くかを、研究者が試験記録の表に書きます

4番目は、AIにも規則にも任せません。 許容幅をわずかに外れた区間を除くかは、試験の目的と規格の求めによって変わります。この構成は、外れた事実と順序をそろえるところまでです。

担当が休みの日は、確認する人を代わりの研究者に切り替えます。 試験計画の表に副担当の列を持たせ、担当が休暇の日は送り先と Restrict Who Can Approve の相手を副担当にします。誰も確認しないまま要約がたまると、止まった試験機が何日も放置されます。

目標は、400件をならして1件3分です。 何も起きていない要約は数十秒で済み、停止のあった要約はグラフと照らして数分かかります。

例外に対処する

1行目と7行目で、「要約が来ない」と「何も起きていない」を分けます。 どちらの場合も研究者には何かが届くようにし、届かない日を作りません。 要約が届かないことを「異常なし」と読むと、止まっている試験機を1日放っておくことになります。

記録を残す

• 前日分の運転ログと制御値の記録のファイル名と、読み込んだ日時
• 前処理の結果（条件外れの区間、記録の欠け、印の付いたイベントの行）
• AIの要約（JSON）と、引用の照合の結果
• 研究者の「確認済み」と、確認した人・時刻
• 研究者が書いたデータの扱い
• イベントの語の表と許容幅の、その日に使った版

最後の行は、規則が後から変わるために残します。 許容幅や語の表を直すと、過去の日の拾い出しの意味が変わります。どの版で拾ったかが残っていれば、試験の結果をまとめるときに、拾い直す範囲を決められます。