介護事業所が各フロアから届く介護用品の発注の依頼を Power Automate と AI でまとめ、発注の一覧と在庫の不足を作る

処理の起点を決める

トリガーは2つあります。 1つ目は依頼のフォームの回答の送信、2つ目は発注日の決まった時刻です。

1つ目のフロー（依頼の受け付け）は、Forms の「When a new response is submitted」で動かします。 フロアの職員が送るたびに1回動き、その依頼だけを読み替えて依頼の明細に入れます。まとめて読み替えないのは、要確認をその日のうちに返したいからです。 夜勤明けの職員が帰る前に聞き返せれば、翌日まで待たずに済みます。

2つ目のフロー（発注の一覧づくり）は、スケジュール済みクラウドフローの Recurrence で動かします。 月曜と木曜の13時に動かし、その時点で「未発注」の依頼の明細をすべて集めます。 締めの時刻はフォームの説明文にも書き、13時を過ぎた依頼は次の発注日に回ることを職員に見えるようにします。

手動のボタンも用意します。 感染症の流行で手袋が急に要るときなど、発注日を待たずにフロー②を動かせるようにします。

入力データを集める

質を決めるのは、品目マスタの「現場での呼び名」の列です。 「テープL、アテントL、大人用おむつL、テープ止めL」のように、その品目を職員がどう呼ぶかを読点で並べておきます。 AIはこの列を見て読み替えるので、ここに無い呼び方は要確認になります。

依頼の文は、品名と数だけを書いてもらいます。 フォームの説明文に「利用者さんの名前は書かないでください」と入れます。個別の利用者のための品（特定の方だけが使うサイズなど）は、品目マスタに「個別対応」の品目として持ち、名前ではなく品目で頼んでもらいます。

急ぎかどうかは選択肢で取ります。 「なるべく早く」の解釈がぶれるので、AIの判定から外します。

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

フロー①は次の順で動きます。

1. When a new response is submitted … Form Id を指定する。返るのは Response Id
2. Get response details … Form Id と Response Id で回答の中身を取る
3. Get items（SharePoint） … 品目マスタのリストから、使用中止でない品目を取る。Filter Query に Discontinued eq 0 を入れ、Limit Columns by View で品目コード・品名・規格・単位・呼び名の列だけのビューを指定する
4. Select … 取った品目を「品目コード｜品名｜規格｜払い出しの単位｜呼び名」の1行ずつの文字列にして、改行でつなぐ
5. Run a prompt … 依頼の文と、4番目の品目の一覧を入力に渡す
6. Apply to each … 返った lines の配列を1行ずつ回し、Create item で依頼の明細に登録する

3番目で列を絞るのは、渡す文字を抑えるためです。 仕入先や単価の列は読み替えに要らず、渡すほど読み違いの材料が増えます。コネクタの説明でも、ビューで列を絞ると列のしきい値の問題を避けられるとされています。

品目マスタは毎回丸ごと渡します。 120品目なら数千字に収まり、候補を先に絞る仕組みを入れると、そこで正しい品目が落ちることがあるからです。

フロー②は次の順です。

1. Get items … 依頼の明細から Status eq '未発注' の行を取る
2. Get items … 在庫のリストと品目マスタを取る
3. Apply to each（品目） … 品目ごとに Filter array で依頼の明細の行を絞り、数量を変数に足していく
4. Compose … 品目ごとに「依頼の合計」「在庫」「未着」「発注点」から発注の数を式で出す
5. Create item … 発注の一覧のリストに、仕入先・品目・発注の数・在庫の不足の印を書く

AIへ渡す前に整形する

1. 空の回答を外す … 依頼の文が空か、数文字しか無い回答は、AIに渡さずに要確認にします
2. 全角・半角をそろえる … 数字とアルファベットを半角に、「ｍ」「Ｍ」のゆれを「M」にします。サイズの読み違いの多くは、ここで消えます
3. 改行と区切りをそろえる … 「、」「・」「／」で1行に並べた依頼も、改行で並べた依頼も、そのまま渡します。区切りの判断はAIに任せます
4. 品目の一覧を作る … 使用中止の品目を外し、1品目1行の文字列にします
5. 同じ依頼の二度送りを見つける … 同じフロア・同じ依頼者・同じ依頼の文が10分以内に2回来たら、2回目を「重複の疑い」にします

4番目で使用中止の品目を外すのが大事です。 メーカーが変わっても職員は前の呼び方を続けるので、前の品目が残っていると、取り扱いのない品が発注の一覧に出ます。 前の呼び名は新しい品目の列へ移します。

AIに処理させる

させるのは、依頼の文を1品目ずつに分けて、品目マスタのどれに当たるか・いくつか・何の単位かを書き出すことだけです。

表の右端の列が、この構成の安全装置です。 決められないときに、近い品目を選ぶのではなく、決められない理由を付けて返させます。 理由が付いた行は要確認になり、購買の担当が見ます。

3行目がいちばん起きやすい失敗です。 「テープ 1ケース」とだけ書かれた依頼に、AIは「多くの施設ではLが一番使われる」と考えてLを選びます。それがMのフロアなら、1ケースのLが棚に残り、Mが欠品します。 だから、サイズが書かれていない依頼は推測させずに ambiguous にします。

指示内容を固定する

あなたは介護施設の購買の担当として、フロアの職員から届いた介護用品の依頼を、
施設の品目マスタの品目に読み替えます。

【入力】
- 依頼の文：{request_text}
- 品目の一覧（1行に1品目。品目コード｜品名｜規格｜払い出しの単位｜現場での呼び名）：
  {item_list}

【やること】
1. 依頼の文を、品目ごとの行に分けてください。
2. 行ごとに、品目の一覧から当てはまる品目コードを1つ選んでください。
   品名・規格・現場での呼び名のどれかと一致するものを選びます。
3. 書かれている数量と単位を、そのまま写してください。
4. その行の根拠にした依頼の文の部分を source_text にそのまま写してください。

【status の選び方】
- ok ......... 品目が1つに決まり、数量と単位が書かれている
- ambiguous .. 当てはまる品目が2つ以上ある（サイズや昼用・夜用が書かれていない等）
- not_found .. 品目の一覧に当てはまるものが無い
- no_quantity  数量が書かれていない
- no_unit .... 単位が書かれていない
迷ったときに ok を選ばないでください。

【厳守事項】
- 書かれていないサイズ・規格を補わないでください。よく使われるサイズを選ばないでください。
- 数量の計算や単位の換算をしないでください。「2袋」は quantity=2、unit=袋 のまま返します。
- 「いつもの」「前と同じ」など、品目が書かれていない依頼は not_found にしてください。
- 品目の一覧に無い品を、似た品目に当てはめないでください。
- 代わりの品を提案しないでください。
- 人の名前が書かれていても、どの項目にも写さないでください。
  source_text に名前が含まれる場合は、その部分を「（名前）」に置き換えてください。
- 介護用品でない依頼（設備の修理、食材など）は、item_code を空にし、status を not_found、
  note に「介護用品以外」と書いてください。
- 出力は指定した JSON だけにしてください。JSON の前後に説明やマークダウンを付けないでください。

「よく使われるサイズを選ばない」を、わざわざ書いています。 書かないと、AIは親切のつもりで空いている規格を埋めます。埋めた値が正しいかどうかではなく、「書かれていなかった」という事実が消えることが問題です。

名前を「（名前）」に置き換える指示は、フォームの説明文とあわせて二重に置いています。 職員は急いでいると「〇〇さんの分」と書きます。依頼の明細は施設の中で広く見られるリストなので、そこへ名前を持ち込まないための指示です。

入力に指示を入れないことにも注意します。 AI Builder の入力の説明には、入力に指示を含めることはできず、セキュリティの理由で禁じられていると書かれています。指示はプロンプトの本文に書き、フォームの依頼の文はあくまで読み替える材料として入力に渡します。

出力形式を固定する

次の形の JSON で受け取ります。 プロンプトの出力を JSON にし、例を入れて「Custom」の形で保存します。

{
  "lines": [
    {
      "line_no": 1,
      "item_code": "DP-TL-L",
      "quantity": 1,
      "unit": "ケース",
      "status": "ok",
      "source_text": "テープL 1ケース",
      "note": ""
    },
    {
      "line_no": 2,
      "item_code": "",
      "quantity": 2,
      "unit": "袋",
      "status": "ambiguous",
      "source_text": "パッド2袋",
      "note": "昼用・夜用とサイズが書かれていない"
    }
  ],
  "has_unresolved": true
}

1つ目の理由は、行ごとに状態を持てることです。 1件の依頼に5品目あって1品目だけが分からないとき、残りの4品目は依頼の明細へそのまま入り、1品目だけが要確認になります。 自由文で受けると、その切り分けを人が読み直すことになります。

2つ目は、後段の式で使える形にそろうことです。 単位は書かれたままで受け、換算はフロー②が入り数で行います。 AIに換算させると、間違いがどこで入ったかが分からなくなります。

JSON の形には制約があります。 プロンプトの JSON 出力は、キーの無い配列（["a", "b"] のような形）を定義できません。 上の例のように、配列の要素は必ずキーを持つオブジェクトにします。また、保存した時点の形が固定されるので、項目を足したらプロンプトを保存し直し、フローの側の参照も直します。

指示の最後の行は、「A JSON could not be generated」のエラーへの対処として公式の FAQ が案内している書き方です。

システムへ連携する

状態の列は、書く主体を分けます。 「未発注」「要確認」はフロー①、「発注済み」は承認のあとのフロー②が書き、要確認を「未発注」に戻すのは人だけです。

フロー②の発注の数の式は、次の形です。

発注の数（発注の単位） ＝ 切り上げ（（依頼の合計 ＋ 発注点 − 在庫 − 未着）÷ 入り数）

0以下なら発注しません。 ここで在庫が依頼の合計より少ない品目には「在庫の不足」の印を付け、次の配達までの払い出しを減らすか、フロア間で融通するかを相談する一覧に載せます。

承認は Approvals のアクションで、購買の担当の2名を承認者にします。 発注の一覧と在庫の不足を載せ、数を直したいときは却下して一覧のリストを直し、もう一度承認に回します。

人が確認する

人が見る場面は3つです。

1. 要確認の行（毎日） … ambiguous・not_found・no_quantity・no_unit の行をメールで受け、品目を選び直すか、フロアへ聞き返します。聞き返しはその日のうちに。 依頼した職員がまだ勤務しているうちに確かめます
2. 在庫の数（発注日の朝） … 倉庫の棚を数えて在庫のリストに入れます。この数だけは、AIでも式でも代わりができません
3. 発注の一覧の承認（発注日の昼） … 仕入先ごとの発注の数と、在庫の不足の一覧を見て承認します。特に、急ぎの依頼と在庫の不足が重なる品目を見ます

2番目を省かないでください。 在庫の数が古いと、式が正しくても発注の数は間違います。数えた日時が前回の発注日のままなら、フロー②は一覧を作らずに在庫の入力を促します。

目標は、240件をならして1件1.5分です。 要確認の行は全体の1〜2割、残りはそのまま入る想定です。要確認が3割を超える週は、品目マスタの呼び名の列が足りていません。

例外に対処する

上の4行が大半を占めます。 どれもAIの読み違いではなく、依頼の書き方と品目マスタの問題です。 多い理由から呼び名とフォームの説明文を直します。

AI Builder のプロンプトは利用量の上限や容量の制限を受けることがあるとされています。失敗しても回答が「未処理」で残るようにしておけば、取りこぼしは起きません。

記録を残す

• 依頼の回答の全文（フォームの側に残る）と、送信の日時・フロア・依頼者
• AIが返した JSON の全文と、そのとき渡した品目の一覧の版（品目マスタの最終更新日時）
• 依頼の明細の行ごとの状態の変化（未発注→要確認→未発注→発注済み）と、直した人
• 発注日ごとの発注の一覧と在庫の不足、承認した人と承認の日時
• 要確認の理由ごとの件数（月ごと）

2つ目で品目の一覧の版を残すのは、品目マスタが後から変わるためです。 呼び名を足したり品目を使用中止にしたりすると、同じ依頼の読み替えの結果が変わります。当時の一覧が分からないと、読み違いがAIのせいか、マスタのせいかを見分けられません。

最後の行が、運用を直す材料になります。 「サイズが書かれていない」が多いフロアにはフォームの説明文を見せ直し、「品目の一覧に無い」が多い品は呼び名の列に足します。