病院の薬剤部で、医薬品の出荷調整・供給停止の情報をエージェントが毎日見回り、院内の採用薬と在庫と照らして、代替薬の検討が要る品目を一覧にする

処理の起点を決める

毎日朝7時に、Schedule Trigger で動かします。 一覧は掲載のたびにファイルが替わり、いつ載るかは決まっていません。毎日見に行き、リンクが前回と同じなら何もせずに終えます。 担当の薬剤師が病棟に出ている日も、見回りは止まりません。第3章の（a）は、ここで解きます。

Schedule Trigger は、ワークフローのタイムゾーンが無ければ n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にし、保存して公開します。公開しないと Schedule Trigger は動かないとされています。

朝7時にするのは、薬剤部の朝の打ち合わせの前に一覧を出すためです。 その日の発注と、病棟への連絡の段取りに、そのまま使えます。

入力データを集める

質を決めるのは、院内の同効薬の対応表です。 同じ成分・規格の他社品は一覧から機械的に引けますが、成分が違う同効薬は、薬効分類が同じというだけでは代わりになりません。 用量の換算、適応の違い、院内の採用の経緯は、薬剤部が持っている知識です。対応表に無い同効薬を、エージェントに挙げさせません。

払い出しの量は直近28日で取ります。 曜日の偏りをならし、季節で使用量が変わる薬でも直近の傾向を見られるからです。

一覧の「限定出荷/供給停止の理由」の列も、そのまま渡します。 製造の問題なのか、他社品の影響で注文が集中しているのかで、同じ成分の他社品に頼れるかの見通しが変わるからです。理由の言葉は一覧の区分のまま写させ、AIに理由を推し量らせません。

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

比べる列は、出荷対応の状況、限定出荷の解除見込み・供給停止の解消見込み、出荷量の状況、その改善の見込み時期の4つです。 それ以外の列（薬効分類の書き方など）の変化は、検討の対象にしません。Compare Datasets には比べない項目を指定する設定があり、そこに他の列を入れます。

「今回掲載時の更新有無」の「New」は、照らし合わせに使います。 自分の比較で出た品目と、「New」の付いた採用薬が食い違えば、前回の版を取り損ねていないかを人が確かめます。

AIへ渡す前に整形する

1. 見出しの行を外し、列の位置で名前を付け直す … 1行目の見出しは長く改行を含むので、列Eを yj_code、列Lを ship_status のように付け直します
2. 日付の値を直す … 更新日などの列は、Excelの日付の通し番号（46260 のような数）で入っていることがあります。日付に直してから比べます
3. 全角をそろえる … 規格単位や成分名は全角で書かれています。採用薬のマスタの側と同じ規則でそろえます
4. 行数を確かめる … 前回より極端に少なければ、ファイルの取り損ねか列のずれを疑い、比較を止めます
5. 写しの日付を確かめる … 前夜の採用薬のマスタと在庫の写しが作られていなければ、照合を止めます
6. 在庫の持つ日数を計算する … 在庫数を、直近28日の1日あたりの払い出しの量で割ります。計算はワークフローで行い、エージェントには結果を渡します

4番目と5番目は、止めることを選んでいます。 列がずれた一覧で比べると、全品目が「変わった」に見えます。誤った大量の候補を出すより、止めて人に知らせるほうが安全です。

6番目をAIにさせないのは、数字を作らせないためです。 在庫の持つ日数は並べ順を決める数字で、誤れば急ぎの品目が後ろに回ります。

AIに処理させる

させるのは、状況が変わった採用薬1品目ごとに、検討の材料を道具で集め、検討表の下書きに並べることです。

同じ成分・規格の他社品は、状況まで並べさせます。 限定出荷が他社品の影響で起きていることも多く、一覧の出荷対応には「限定出荷（他社品の影響）」という区分があります。候補の他社品が「通常出荷」かどうかを並べないと、候補を挙げても使えません。 第3章の（c）は、ここで解けます。

1行目と3行目は、この構成の線引きの中心です。 生成AIは、同効薬の一般的な換算を知っていて、聞かれなくても書き添えることがあります。検討表に換算が書かれていると、確かめずに使われるおそれがあります。 指示で禁じ、出力の形にも換算の欄を設けません。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは病院の薬剤部で、医療用医薬品の供給状況の変化を、院内の採用薬と
在庫に照らして、検討表の下書きを作る担当です。入力は、供給状況が変わった
採用薬1品目の前回と今回の行（YJコード、品名、成分名、規格単位、
出荷対応の状況、理由、解除の見込み、出荷量の状況）と、在庫の持つ日数です。

【やること】
1. 前回と今回の違いを、一覧の言葉のまま書く。
2. 在庫と払い出しの道具で、在庫数、1日の払い出し、発注残を引く。
3. 一覧の写しを、同じ成分名・規格単位で引き、他社品の出荷対応の状況と、
   院内の採用の有無を並べる。
4. 院内の同効薬の対応表を引き、載っている品目の供給状況と在庫を並べる。
5. 前回の検討の記録を引き、前回の結論を添える。

【厳守事項】
- 出荷対応、理由、解除の見込みは、一覧に書かれた文言をそのまま写して
  ください。「未定」「－」は、そのまま写してください。
- 代わりに使う薬を推奨しないでください。切り替えの可否も書かないでください。
- 同効薬は、対応表に載っている品目だけを挙げてください。
  対応表に無い薬を、知識から挙げないでください。
- 用量の換算を書かないでください。
- 在庫の持つ日数は、入力の値をそのまま使ってください。計算し直さないでください。
- 他社品が同時に限定出荷・供給停止のときは、check_points にそう書いてください。
- 規格や剤形が違う候補は、check_points に違いを書いてください。

【出力】指定のJSONの形で返してください。

「対応表に無い薬を知識から挙げない」が、この指示の要です。 指示しないと、一般的な同効薬を挙げます。院内で採用していない薬が候補に並ぶと、採用の手続きのない薬を検討することになり、確認の時間が増えます。

「未定」をそのまま写させるのは、一覧の「解除見込み」の欄に「未定」が多いからです。 生成AIは「数か月で解除の見込み」のように言い換えることがあります。言い換えは、在庫の持たせ方の判断を誤らせます。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "yj_code": "", "product": "", "ingredient": "", "strength": "",
  "change": { "ship_before": "", "ship_after": "", "reason": "",
              "outlook": "", "volume_before": "", "volume_after": "" },
  "stock": { "on_hand": "", "daily_use": "", "days_left": "", "open_order": "" },
  "same_ingredient": [
    { "yj_code": "", "product": "", "maker": "", "ship_status": "", "adopted": false }
  ],
  "alternatives_in_table": [
    { "product": "", "ship_status": "", "on_hand": "", "days_left": "" }
  ],
  "previous_review": "",
  "check_points": [""],
  "priority": "today | this_week | monitor"
}

1つ目の理由は、days_left で並べられることです。 第3章の（d）は、ここで解けます。priority は、ワークフローが規則で上書きします。

2つ目は、same_ingredient の ship_status で、使える候補と使えない候補を分けられることです。 通知では、通常出荷の候補があるかどうかを1行目に出します。

3つ目は、check_points を検討表の「確認すること」の欄にそのまま流せることです。

チャットへの通知は、JSONから次の形に組み立てます。1品目を3行に収め、詳しくは検討の一覧で見る作りにします。

【今日中】◯◯錠5mg（院内在庫 9日分）
  通常出荷 → 限定出荷（他社品の影響）／解除見込み：未定
  同成分の他社品 4品目：通常出荷 1／限定出荷 3　同効薬（対応表）2品目：在庫あり
【今週中】△△注射液（院内在庫 41日分）
  出荷量 A → B／同成分の他社品なし　同効薬（対応表）：未登録
【様子見】□□軟膏　限定出荷 → 通常出荷（代替に使った品目の戻し方を確認）

通常出荷に戻った品目も通知に残します。 代替薬に切り替えていた品目は、元に戻すかどうかを決める必要があり、戻ったことに気づかないと、臨時採用の代替薬を使い続けることになります。

システムへ連携する

検討の一覧への書き込みは、ワークフローの側で行います。 エージェントの道具には Insert を含めず、写しを引く Select と Execute Query だけを渡します。Execute Query では $1 のようなパラメーターに値を渡す形を使い、公式の説明では、クエリパラメーターのデータは n8n が無害化し、SQL インジェクションを防ぐとされています。

物品管理の仕組みと電子カルテには、何も返しません。 発注の数や採用の変更は、薬剤師が既存の手順で入力します。

人が確認する

1. today から見る … その日のうちに、発注の調整と代替薬の検討の要否を決めます
2. 在庫の数字を確かめる … 病棟の定数配置の分が在庫に入っているかなど、写しの数字と実際の差を見ます
3. 同じ成分の他社品の状況を確かめる … 卸に出荷の可否を問い合わせ、一覧の状況と実際の入手の可否を照らします
4. 同効薬の候補を検討する … 用量・適応・剤形の違いを、薬剤師が確かめます。ここが薬剤師の仕事の中心です
5. 判断を記録する … 検討の要否、対応（発注の調整、他社品への切り替え、同効薬の検討）、診療科への連絡を一覧に残します

3番目を省かないでください。 一覧の状況は製造販売業者の届出に基づくもので、卸の手元の在庫や配分の状況とは一致しないことがあります。

目標は、1件をならして8分です。 下書きの確認と在庫の確かめに4分、候補の状況の確認に3分、記録に1分という見込みです。

例外に対処する

上から4行目までは、一覧の作りが変わったときに起きます。 令和8年3月31日に新しいシステムの稼働が始まったように、公表の仕方は変わりえます。 止めて知らせる仕組みを先に作ってください。

記録を残す

• 実行ごとの、取得したリンクとファイル、取得の成否
• 前回との差分（変わった品目、新しく載った品目）
• エージェントのJSON出力と、呼んだ道具の順番
• 薬剤師の判断 … 検討の要否、対応、診療科への連絡、判断した日
• 状況が変わった日、一覧に載った日、拾った日、対応を決めた日、在庫が切れた日（切れた場合）

最後の行が、この構成の物差しです。 在庫の持つ日数のうちに対応を決められたかを並べると、見回りの遅れと、院内の手続きの遅れが分かれて見えます。