気象庁の予報と警報の電文を毎夕取り込み、翌日の高所作業・クレーン作業・コンクリート打設を中止するかの判断材料を現場ごとにまとめて所長に送る

処理の起点を決める

Schedule Trigger で、毎日17時30分と翌朝5時30分に動かします。 時系列情報は17時と5時までに定時発表されるので、その30分後に取りに行きます。 Schedule Trigger の公式ページでは、ワークフローに時間帯が無ければ n8n のインスタンスの時間帯に従い、自前で置いた場合の既定は America/New York とされています。Asia/Tokyo を指定しないと、判断材料が夜中に届きます。

17時30分の回が本番で、5時30分の回は変わったことの確認です。 夕方の判断材料で所長は職長と生コンの工場に連絡しています。朝の回で判定が変わらなければ、何も送りません。 変わった現場の所長にだけ、変わった作業と値を知らせます。毎朝同じ内容が届くと、所長は読まなくなります。

所長の作業予定表の締切を16時にしているのは、17時30分の回に間に合わせるためです。 締切までに埋まっていない現場は、判断材料を作らずに「予定が未記入」と所長に知らせます。

入力データを集める

質を決めるのは、いちばん下の中止基準の表です。 法令の悪天候の目安を下限にし、クレーンは機種ごとのメーカーの基準、打設は施工計画の基準を、作業の種類ごとに数値で持たせます。基準が文章のままでは、規則で照らせません。

時系列情報の最大風速は、気象庁の用語では10分間平均風速の最大値です。 気象庁の予報用語のページでは、最大風速は10分間平均風速の最大値とされています。厚生労働省の群馬労働局のページでは、労働安全衛生規則の強風は10分間の平均風速が毎秒10メートル以上の風、大雨は1回の降雨量が50ミリメートル以上の降雨とされています。同じ10分間平均の値なので、比べる単位はそろいます。 ただし、値は市町村単位の予測の最大値で、現場の高さや地形の風ではありません。

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

電文の一覧から、対象の府県の最新のものを選びます。 フィードの各項目には電文の題名と URL があり、URL に電文の種類のコード（VPWP50 など）と府県のコードが含まれます。現場のある府県の分だけを選び、取り終えた URL は記録して二度取りません。

取りすぎに注意します。 気象庁の情報の取得方法のページでは、公開の URL に1日10GB以上のダウンロードを伴うアクセスがあると、アクセス元の IP アドレスを遮断するとされ、一度取得したファイルを再度取得しないなどの改修を求めています。1日2回の取得なら量は小さいですが、取り直しの処理の誤りで同じ電文を繰り返し取らないよう、取得済みの URL を必ず記録します。

電文は XML ノードで JSON にします。 n8n の公式ページでは、XML ノードは XML と JSON の相互の変換を行い、属性を親の項目にまとめる設定（Merge Attributes）や、子の要素を常に配列にする設定（Explicit Array）があります。電文の値は type="最大風速" のような属性で区別されるので、属性を残したまま変換し、Code ノードで種類ごとに取り出します。

AIへ渡す前に整形する

1. 市町村の値を引く … 時系列情報から、現場の市町村コードの要素を取り出します
2. 時刻の対応を作る … 電文の時刻の定義（3時間ごとの区切り）を、翌日の時刻に直します
3. 作業の時間帯と重ねる … 作業の開始・終了の時刻にかかる3時間の区切りを選び、その区切りの値の最大を取ります
4. 基準と照らす … 作業の種類ごとの基準と比べ、超える区切りに exceed、基準の8割以上に near の印を付けます
5. 文章の注意を集める … 府県気象情報が出ていれば、その府県の文章を取り出します
6. 欠けを記録する … 現場の市町村が電文に無い、作業予定が未記入、などを記録します

3番目を規則で行うのが、この構成でいちばん効く部分です。 打設が9時から12時なら、9時〜12時の区切りの値だけを見ます。一日の最大値で決めると、午後の雨で午前の打設を止めることになります。 区切りにまたがる作業は、かかる区切りすべての値の最大を取ります。

値を補いません。 現場の市町村が電文に無いときに、隣の市町村の値で代えることはしません。欠けとして所長に知らせ、所長が気象庁のページで確かめます。 隣の値で代えることは、内挿と同じ性質の加工になるからです。

AIに処理させる

Basic LLM Chain に、規則の判定と文章の注意事項をあわせた判断材料を作らせます。 公式ページでは、Basic LLM Chain はプロンプトを決めるノードで、出力の形を求めるときは Structured Output Parser などのパーサーをつなぐとされています。

区分の名前を「中止」ではなく「中止を検討」にしているのは意図してのことです。 判断材料が「中止」と書けば、所長は確かめずにそれに従うか、反発して読まなくなります。どちらも、所長の判断を支える材料にはなりません。

指示内容を固定する

Basic LLM Chain のシステムメッセージに、次のように書きます。

あなたは建設会社の安全品質課の担当として、翌日の作業を中止するかを所長が
判断するための材料を作ります。決めるのは所長です。

【入力】
- 現場名と、翌日の作業の一覧（作業の種類、開始・終了の時刻）
- 作業ごとの規則の判定（exceed / near / none）と、根拠になった区切りの時刻と値、
  比べた基準の値、電文の種類と発表時刻
- 府県気象情報の文章（発表されていなければ空）

【区分の選び方】
- 規則の判定が exceed の作業 → consider_stop
- 規則の判定が near の作業 → conditional
- 規則の判定が none の作業 → as_planned。ただし、府県気象情報の文章に、
  その作業に関係する注意（落雷、突風、急な強い雨など）があれば conditional
規則の判定より軽い区分にしないでください。

【厳守事項】
- 値は入力の値と発表時刻をそのまま書いてください。
  値を補ったり、現場の高さや地形に合わせて推定したりしないでください。
- 「やや強い風」などの言葉から、風速の数値を作らないでください。
- 府県気象情報の文章から注意を写すときは、原文の言葉をそのまま引いてください。
- 入力に無い情報（一般的な天気の傾向、他のサービスの予報）を足さないでください。
- 「中止します」「中止してください」とは書かないでください。
  所長が判断するための事実と、当日の朝に現場で確かめることだけを書いてください。

「規則の判定より軽い区分にしない」が最も大事な一文です。 AIは、府県気象情報に強い表現が無いと「予報は穏やか」と読み、exceed の作業を conditional に下げることがあります。ワークフローでも、出力の区分が規則の判定より軽ければ、規則の判定で上書きします。

「言葉から数値を作らない」も効きます。 書かないと、地域時系列予報の風の階級や「やや強い」から、「10m/s程度」のような値を自分で書き足します。 電文に無い値は、所長に誤った確からしさを与えます。

出力形式を固定する

Structured Output Parser で、次の形に決めます。 公式ページでは、JSON の例から生成するとすべての項目が必須として扱われ、JSON Schema で定義することもできるとされています。

{
  "site_id": "S-07",
  "target_date": "2026-10-15",
  "works": [
    {
      "work_id": "W-2",
      "work_type": "crane | high_place | concrete",
      "category": "consider_stop | conditional | as_planned",
      "rule_result": "exceed | near | none",
      "evidence": [
        { "element": "最大風速", "period": "12時-15時", "value": "12 m/s",
          "threshold": "10 m/s", "source": "VPWP50", "issued_at": "2026-10-14T17:00+09:00" }
      ],
      "text_cautions": [],
      "message": "",
      "check_on_site": ""
    }
  ]
}

1つ目の理由は、規則の判定と区分を並べて検査できることです。 ワークフローは rule_result と category を比べ、区分が規則より軽ければ上書きして記録します。 AIの誤りが所長に届く前に止まります。

2つ目は、根拠を発表時刻とともに残せることです。 issued_at があれば、所長はどの時点の予報で判断したかを記録に残せます。朝の回で値が変わったときも、前の値と並べて知らせられます。

3つ目は、メールと作業予定表に同じ内容を書けることです。 メールは現場ごとに1通で、作業ごとに次の形で並べます。

システムへ連携する

作業予定表には「判断材料」の列だけを書き込みます。 Google Sheets ノードの公式ページでは、シートの行の操作に Get Row(s)・Update Row・Append Row などがあります。所長が書く「判断」の列には触れません。 判断材料と判断を同じ行に並べると、安全品質課は翌朝に電話をかけずに記録を集められます。

メールは Gmail ノードの Send a message で送ります。 公式ページでは、既定で本文の末尾に n8n から自動で送られた旨の一文が付くとされています。社内の連絡なので付けたままでもよく、むしろ自動の判断材料であることが所長に伝わります。

人が確認する

所長が、判断材料を読んで翌日の作業を決めます。

1. consider_stop の作業を先に見る … 根拠の時間帯と値を見て、作業の時間をずらせるか、別の作業に入れ替えられるかを考えます
2. conditional の作業を見る … 当日の朝に何を見て決めるかを、職長と決めておきます
3. 判断を書く … 作業予定表の「判断」の列に、実施・入れ替え・中止と理由を書きます
4. 連絡する … 職長、クレーンの会社、生コンの工場に連絡します
5. 当日の朝に最終的に決める … 現場の風速計と空の様子で、作業を始めるかを決めます

5番目は、この構成が代わりにならない部分です。 労働安全衛生規則第522条は、高さ2メートル以上の作業で強風・大雨・大雪等の悪天候のため危険が予想されるときに作業を禁じ、クレーン等安全規則第31条の2は、強風のためクレーンの作業に危険が予想されるときに作業の中止を求めています。危険が予想されるかを、その場で見て判断するのは事業者と所長です。

目標は、1件をならして5分です。 as_planned だけの日は判断材料を流し読みして終わり、consider_stop がある日は入れ替えを考えて連絡するので15分を超えます。

例外に対処する

最後の行は、組む前に決めておいてください。 気象庁の情報の取得方法のページでは、サーバーのメンテナンス等で配信が停止・遅延する場合があるとされ、迅速かつ確実な配信については気象業務支援センター等に問い合わせるよう案内されています。判断材料が届かないことを、「問題なし」と読まれないようにします。 届かないときは、届かないという知らせを送ります。

記録を残す

• 取得した電文の URL・種類・発表時刻
• 現場ごと・作業ごとの、照らした区切りの値と基準、規則の判定
• AIの出力と、ワークフローが上書きした区分とその理由
• 所長に送ったメールの日時と、作業予定表に書いた判断材料
• 所長の判断（実施・入れ替え・中止）と理由
• 当日の実際の作業の実施・中止と、現場の風速計の記録

最後の2行が、中止基準の見直しの材料になります。 判断材料と所長の判断、当日の実際を並べると、基準が厳しすぎて入れ替えが多いのか、甘すぎて当日の朝に止めているのかが分かります。