医療材料の使用記録と手術の予定から、部署ごとの定数の補充と中央在庫の発注の案を毎朝出す

処理の起点を決める

平日の朝5時30分に動かします。 物品管理システムの定時出力が5時に終わり、物品管理係が7時30分に出勤して補充リストを見る、という順に合わせます。n8n の Schedule Trigger ノードは、秒・分・時間・日・週・月の間隔か、cron 式で起動の時刻を決められます。平日だけ動かすなら、週の間隔で月曜から金曜を選びます。

時刻の基準に注意してください。 Schedule Trigger は、ワークフローのタイムゾーンが設定されていればそれを、無ければ n8n のインスタンスのタイムゾーンを使います。 公式の説明では、自分で運用するインスタンスの既定は America/New York です。ワークフローのタイムゾーンを Asia/Tokyo に設定しないと、朝5時30分のつもりが日本時間の夜に動きます。

もう一つ、ワークフローを保存して公開（publish）しないとスケジュールは動きません。 編集画面で試しに動かして満足し、公開を忘れる、という失敗が起きやすいところです。

予定の変化の抽出は、別のワークフローに分けます。 こちらは平日の15時に動かし、その日に届いた連絡メールを読みます。夕方のうちに人が採用を済ませておけば、翌朝の予測に入ります。

入力データを集める

質を決めるのは、術式別の標準材料の表です。 手術室の使用量は、翌日の予定件数と術式でほぼ決まります。この表が「長く担当している1名の頭の中」を書き出したものになります。最初から全術式をそろえる必要はなく、件数の多い上位30術式から作ります。

補充の間隔は部署ごとに持ちます。 平日毎日の部署、週3回の部署、手術室のように前日の夕方にそろえる部署があります。金曜の補充は翌営業日までの3日分を見込むので、予測を「補充の間隔の日数分」で合計します。

使用記録の粒度も確かめてください。 定数カードの回収だけで記録している部署は、カードを外し忘れると使用数が実際より少なく出ます。 予測の元になるので、バーコードの読み取りに寄せていくほど予測が安定します。

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

ファイルは Read/Write Files from Disk ノードで読みます。 ファイルの指定にはワイルドカードが使えるので、/data/spd/usage_*.csv のように日付入りのファイル名をまとめて指定できます。

読めるフォルダには制限があります。 自分で運用するインスタンスでは、N8N_RESTRICT_FILE_ACCESS_TO という環境変数で読めるパスが決まり、n8n 2.0 からは既定が ~/.n8n-files です。院内のファイルサーバーの出力先を読むには、このパスを出力先に合わせて設定するか、Docker で動かすならホストのフォルダをボリュームとしてマウントします。

読んだCSVは Extract From File ノードでJSONに変えます。 このノードはCSV、XLS、XLSXなどに対応し、ヘッダー行の設定を外すと、列名ではなく番号付きの行として出力されるとされています。物品管理システムのCSVは1行目が列名なので、ヘッダー行を有効にします。

AIへ渡す前に整形する

1. ファイルがそろっているかの確認 … 5つのCSVのどれかが無い、または0行なら、予測を出さずに止めて知らせます
2. 品目コードの突き合わせ … 使用記録にあって品目マスタに無い品目は、新しく採用された材料か、コードの誤りです。別の一覧に出します
3. 休日の扱い … 前日が休日の場合、使用記録は休日分を含めて集計し、曜日別の実績には休日を平日と混ぜません
4. 外れ値の印 … 災害訓練や大量の廃棄など、普段と違う日の記録には、物品管理係が印を付けられる列を持たせ、印の付いた日は実績から除きます
5. 包装単位への丸め … 補充と発注は最小の包装単位でしかできないので、計算の最後に切り上げます

1番目を省かないでください。 手術予定のCSVが出ていない日に予測を出すと、手術室の補充が曜日の平均だけになり、翌日の大きな手術の材料が足りません。 出さないほうが、担当者は手で確かめます。

AIに処理させる

予測と補充・発注の計算は、Code ノードの計算で行います。生成AIは使いません。

生成AIにさせるのは、次の2つだけです。

説明文の下書きでは、計算済みの数を言い換えずに使わせます。 「目安は12、現在の定数は20、直近8週で1日に10を超えた日は無い」という事実を並べ、定数を下げるべきだという結論は書かせません。 決めるのは部署の責任者です。

1行目がいちばん大事です。 生成AIに「明日の補充数を出して」と頼むと、それらしい数が返ってきます。しかし、なぜその数なのかを誰も説明できず、翌日同じ条件で頼むと違う数が返ることがあります。 補充と発注は、足りなければ医療が止まり、多すぎれば期限切れで捨てる仕事です。数は計算で出し、生成AIは言葉の側だけを受け持ちます。

指示内容を固定する

予定の変化の抽出に使う指示です。

あなたは病院の物品管理係の補助です。
部署から届いた連絡のメール本文を読み、医療材料の使用量に影響する
「予定の変化」だけを抜き出してください。推測で埋めないでください。

【抜き出すもの】
- department ... 連絡してきた部署
- target ...... 影響する品目名、または診療・処置の種類（書かれたとおり）
- start_date .. 変化が始まる日（書かれていなければ null）
- end_date .... 変化が終わる日（書かれていなければ null）
- direction ... increase / decrease / stop（使わなくなる）/ new（新しく使う）
- amount ...... 書かれた数や割合（書かれていなければ null）
- evidence .... 根拠にした文をそのまま写す

【厳守事項】
- 数が書かれていない場合、amount は null にしてください。
  「増える」「多くなる」から数を推測しないでください。
- 日付が「来週から」のように相対的に書かれている場合は、
  start_date を null にし、evidence にその言葉を残してください。
  メールの受信日から日付を計算しないでください。
- 医療材料の使用量に関係しない内容（会議の案内、お礼など）は抜き出さないでください。
- 1通に複数の変化があれば、それぞれを別の要素にしてください。
- 品目名は書かれたとおりに写してください。品目コードに置き換えないでください。
- 変化が1つも無ければ、changes を空の配列にしてください。

【メールの受信日時】{received_at}
【差出人】{sender}
【本文】{body}

「受信日から日付を計算しない」を明記しているのは、計算を人の確認の場に残すためです。 「来週から」を生成AIが日付に直すと、週の始まりを月曜と取るか日曜と取るかで1日ずれます。 日付の確定は、物品管理係が採用するときに画面で行います。

「数を推測しない」も同じ理由です。 「化学療法の患者が増える」と書かれていても、何名増えるかは書いた看護師長にしか分かりません。数が空の変化は、採用するときに物品管理係が電話で確かめます。

出力形式を固定する

予定の変化は、次の形のJSONで受け取ります。 Claude API の構造化出力で、output_config.format に JSON スキーマを指定します。

{
  "changes": [
    {
      "department": "5階東病棟",
      "target": "化学療法",
      "start_date": null,
      "end_date": null,
      "direction": "increase",
      "amount": null,
      "evidence": "来週から化学療法の患者さんが増える予定です"
    }
  ]
}

スキーマの制約を先に知っておきます。 公式の説明では、構造化出力ではすべてのオブジェクトに additionalProperties: false を設定する必要があり、minimum・maximum のような数の制約や、minLength・maxLength のような文字列の制約はサポートされていません。amount が負にならないか、といった検証はワークフローの側で行います。 direction は enum で4つの値に絞れます。

予測と補充の案は、Code ノードが次の列の表で出します。

「内訳」と「根拠」の列が、この表の要です。 補充の数が普段と違うとき、物品管理係はどの要素で増えたのかを1行で読めます。 部署から「なぜこんなに持ってきたのか」と聞かれても、その列を見せれば答えになります。

システムへ連携する

物品管理システムへ発注のデータを自動で取り込ませることはしません。 発注の案に誤りがあれば、そのまま業者に届き、納品と請求まで進みます。案を出すところまでを自動にし、確定は人が行います。

生成AIに渡すのは、メール本文と見直しの候補の数だけです。 患者の氏名や病名が連絡メールに書かれていることがあるので、本文から患者の個人情報らしい部分を伏せてから渡します（第13章）。

人が確認する

1. 予定の変化の採用（前日の夕方） … 抜き出された変化を読み、採用するものに印を付けます。数や日付が空のものは、連絡してきた部署に確かめてから埋めます
2. 注意点の付いた行を見る（当日の朝） … 「定数不足の恐れ」は、補充の数を定数より多くするか、部署に一時的な増量を相談します
3. 期限の近い在庫を見る … 期限の近いロットがある品目は、使用の多い部署へ先に回します
4. 補充リストを確定する … 印刷して部署を回ります
5. 発注の案を確かめて発注する … 期限の近い在庫、発注残、納品までの日数を見て、数を直してから発注します

1番目を省くと、この構成の前提が崩れます。 予定の変化は、予測の数を大きく動かす入力です。生成AIの読み違いを止められるのは、この採用の場だけです。

目標は、400件をならして1件3分です。 注意点の無い部署は1分ほどで確定でき、手術室や注意点の多い部署は数分かかります。

例外に対処する

上から4行目が、稼働の初めによく起きます。 表に無い術式の上乗せを0にすると、その手術の材料が曜日の平均でしか補充されません。 0ではなく「分からない」として注意点に出すのが大事です。

生成AIが止まっても、予測と補充は止めない設計にしています。 生成AIが受け持つのは予定の変化の抽出と説明文だけなので、止まっても補充の案は出ます。

記録を残す

• 読み込んだCSVの日付と行数（どのファイルで計算したか）
• 部署×品目ごとの予測、内訳、補充の案、発注の案
• 物品管理係が補充の数や発注の数を直した記録（元の案、直した数、理由）
• 生成AIが抜き出した予定の変化と、採用したか、採用時に埋めた数と日付
• 欠品しかけた記録（部署から借りに来た、緊急の払出をした）
• 期限切れで廃棄した品目と数

3つ目の「直した記録」が、予測を育てる材料になります。 同じ品目で毎回人が数を増やしているなら、術式別の標準材料の表か定数のほうに理由があります。

最後の2行は、月1回の定数の見直しの根拠になります。 欠品しかけた品目は定数を上げる候補、期限切れで捨てた品目は下げる候補です。