研究所の分析グループにメールとフォームで届く分析依頼を取り出して受付台帳に載せ、装置の予定と納期の回答を下書きする

処理の起点を決める

トリガーは2つあり、フローも2本に分けます。 1本は受付のメールボックスへの新しいメールの到着、もう1本は依頼フォームの回答の送信です。入口が違うだけで、AIに渡したあとの処理は同じです。 後段を子フローにまとめると、直すところが1か所で済みます。

メールのトリガーには、受信フォルダと件名の条件を付けます。 受付のメールボックスには、依頼のほかに依頼者からの催促や、試料を発送したという連絡も届きます。件名の先頭に「分析依頼」と付けてもらう運用を案内しつつ、付いていないメールも捨てずに後段で仕分けます。 件名で絞りすぎると、書き方を知らない工場からの依頼が入口で落ちます。

公式の説明では、トリガーは受信日時をもとに動き、設定したフォルダだけを見ます。仕分けのルールで別のフォルダへ移されたメールでは動かないことがあるので、受付のメールボックスには自動の仕分けを置きません。また、Defender の動的配信を使っている環境では、1回目は添付が空の配列のまま、2回動くことがあるとされています。添付の数が0より多いかを条件で見てから進めます。

フォームのトリガーは、回答が送信されるたびに1回動きます。フォームの回答には受付番号がまだありません。 番号はフローが台帳に登録した時点で振ります。

入力データを集める

質を決めるのは、2つ目の「測定項目と装置の対応表」です。 いま受付担当の頭の中にある「この測定ならこの装置、前処理に2日」を、表に書き出します。この表が無いと、AIが取り出した測定項目から先へ進めません。

依頼者の一覧は、費用負担部門の既定値のために作ります。 コードが書かれていなければ所属から既定値を入れ、「既定値を使った」と台帳に残します。

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

SharePoint の Get items には Filter Query と Top Count があります。 Filter Query は OData の条件式で、装置予約なら「装置が GC-MS で、日付が今日から21日後まで」のように絞ります。絞らずに全件を取ると、予約の履歴が増えるほど遅くなります。

添付の扱いは種類で分けます。 プロンプトの文書入力に渡すのは PDF と画像だけにし、Excel の依頼票は文書入力に渡しません。 古い依頼票は Excel のまま届くので、受付担当が PDF にしてから再投入するか、フォームでの依頼を案内します。種類を見ずに渡すと、プロンプトの段で止まります。

AIへ渡す前に整形する

1. 差出人の確認 … 差出人が依頼者の一覧にあるかを見ます。社外からのメールは処理せず、受付担当へ回します
2. 催促・連絡との仕分け … 件名と本文の先頭で、依頼か、催促か、試料発送の連絡かを分けます。依頼でないと分かったものは台帳に載せません
3. 返信の引用の除去 … 「-----Original Message-----」以降や「>」で始まる引用を落とします。過去の依頼の内容が引用に残っていると、前回の試料を取り出します
4. 署名の除去 … 署名の部署名と電話番号は依頼者の一覧から引けるので、本文からは落とします
5. 添付の振り分け … PDF・画像はプロンプトへ、Excel は受付担当へ、それ以外は無視します
6. 同じ依頼の重複の確認 … 同じ依頼者から同じ件名のメールが24時間以内に2通あれば、2通目を「重複の疑い」として台帳に載せずに受付担当へ回します

3番目がいちばん効きます。 依頼者は前回の依頼メールに返信する形で次の依頼を出すことが多く、引用を残したまま渡すと、新しい依頼と古い依頼の試料名が混ざります。

AIに処理させる

させるのは、依頼の文面から決まった項目を取り出し、書かれていない項目と読み取れない項目を分けて返すことです。

試料の危険性の扱いが、この構成で最も大事です。 危険性について何も書かれていない依頼は、「危険性は無い」ではなく「書かれていない」です。AIは書かれていないことを「無し」と読みがちです。 そのまま台帳に「危険性：無し」と載ると、分析者が保護具なしで試料を開けることになります。

指示内容を固定する

あなたは研究所の分析グループで、他部門から届いた分析依頼を受け付ける担当です。
渡された依頼の文面（メール本文、添付、フォームの回答）だけを見て、
決まった項目を取り出してください。推測で埋めないでください。

【取り出す項目】
1. 費用負担部門のコード
2. 試料（試料名と試料数。試料ごとに1件）
3. 測定項目（書かれた言葉のまま。装置名に直さない）
4. 目的（1文）
5. 希望納期（日付として書かれていれば YYYY-MM-DD、そうでなければ原文のまま）
6. 試料の危険性（有機溶剤、毒物・劇物、粉じん、生体由来など、書かれた内容のまま）
7. 測定後の試料の返却（要／不要）

【status の選び方】
- ok ......... 文面に書かれており、その項目として読める
- missing .... 文面に書かれていない
- unreadable . 添付の文字がつぶれている、手書きが読めないなどで確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 試料の危険性について何も書かれていなければ missing にしてください。
  「書かれていない」を「危険性は無い」として扱わないでください。
- 試料数が書かれていなければ missing にしてください。
  「サンプル一式」「数点」を数字に直さないでください。
- 希望納期の「来週中」「なるべく早く」「月末」を日付に直さないでください。
- 測定項目を装置名に言い換えないでください。「異物を調べたい」は
  そのまま「異物を調べたい」と写してください。
- 引用部分（過去のメール）に書かれた試料や測定項目は取り出さないでください。
- evidence には、その値の根拠にした文字列をそのまま写してください。
- 納期の約束、試料を受けられるかの判断、装置の選定は書かないでください。
- 依頼ではない連絡（催促、発送の連絡、お礼）と判断した場合は、
  項目を取り出さず message_type にその種類を書いてください。
- JSON のマークダウンの囲みを付けずに答えてください。

【メールの件名と本文】{mail_text}
【フォームの回答】{form_answers}
【添付】{attachment}

「書かれていないを危険性無しとして扱わない」を明記しないと、ok で「なし」と返ってきます。 依頼者の多くは危険性を書かないので、何も言わなければ、もっともらしい値で埋めます。禁じるのは、空欄を「無し」と読む判断そのものです。

最後の1行は、公式の FAQ にある対処です。 JSON を作れなかったときの原因として、モデルが JSON をメタ情報で囲んでしまうことが挙げられ、「Don't include JSON markdown in your answer」という指示を足すよう案内されています。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "message_type": "request | reminder | shipping_notice | other",
  "cost_center": { "status": "ok | missing | unreadable | ambiguous", "value": "", "evidence": "" },
  "samples": [
    { "name": "", "count": "", "status": "ok | missing | unreadable | ambiguous", "evidence": "" }
  ],
  "measurements": [
    { "text": "", "evidence": "" }
  ],
  "purpose": { "status": "", "value": "" },
  "due_date": { "status": "", "value": "", "is_date": true, "evidence": "" },
  "hazard": { "status": "", "value": "", "evidence": "" },
  "return_sample": { "status": "", "value": "要 | 不要 | " },
  "missing_items": []
}

1つ目の理由は、台帳の列にそのまま入れられることです。 SharePoint の受付台帳は、試料名・試料数・測定項目・希望納期・危険性・返却を列に持たせています。JSON の各項目を列に当てるだけで、受付担当が写す作業がなくなります。

2つ目は、status で次の分岐を決められることです。 missing_items が空でなければ聞き返しの下書きへ、空なら納期の候補を出して回答の下書きへ進みます。分岐をフローの条件に置くので、AIの文面の出来に左右されません。

3つ目は、is_date で希望納期を扱い分けられることです。 日付として書かれていれば装置の空きと比べ、原文のままなら比べずに受付担当へ回します。

AI Builder の JSON 出力は、保存したときの形がそのまま実行時に使われます。 公式の説明では、JSON のスキーマは画面で確かめられますが、いまはスキーマを直接編集できず、キーの無い配列（["abc", "def"] のような形）は定義できません。 上の例で samples と measurements を「キーを持つオブジェクトの配列」にしているのはこのためです。missing_items も、実装では [{"item": "hazard"}] の形にします。

システムへ連携する

納期の候補は、フローが数えます。 測定項目から引いた装置について、今日から21日後までの予約を取り、予約の入っていない日のうち、前処理の日数を足した最初の日を候補にします。測定項目が複数あるときは、いちばん遅い装置の日を候補にします。希望納期が日付で書かれていれば、候補と比べて「間に合う／間に合わない」を台帳に入れます。

対応表に無い測定項目は、装置の候補を空にします。 「異物を調べたい」のように装置が1つに決まらない言い方は、AIに装置を選ばせず、受付担当が台帳で装置を選んでから、納期の候補を出し直します。

送信は Outlook の下書きまでです。 Office 365 Outlook には Draft an email message があり、フローから下書きを作れます。下書きを受付担当が開き、装置と納期を確かめてから送ります。 送信したら、受付担当が台帳の「受付済」に印を付け、その変更でフローが受付番号を確定させます。

人が確認する

受付担当が見るのは、台帳の「仮受付」の行と、Outlook の下書きです。

1. missing_items を見る … 聞き返しの下書きが出ている依頼は、聞き返す項目が正しいかを確かめて送ります
2. 危険性を見る … hazard が ok の依頼は、書かれた内容で試料を受けられるかをリーダーに確かめます。missing のまま受けることはしません
3. 装置と納期を確定する … 装置の候補が空なら選び、納期の候補が混んでいる装置に当たっていれば日を動かします
4. 下書きを直して送る … 回答の文面の日付と装置名を確かめて送ります
5. 取り出しを直したら記録する … どの項目を、どう直したかを台帳の修正欄に残します

2番目を省かないでください。 取り出しが正しいことと、その試料を受けてよいことは違います。

目標は、180件をならして1件6分です。 そろっている依頼は台帳と下書きを見て送るだけで数分、聞き返しの要る依頼と装置の決まらない依頼に時間を使います。

例外に対処する

上から3行目が、受付担当がいちばん迷うところです。 品質保証部からの依頼は「返品された部品の異物の確認と、同じロットの原料の組成の確認」のように、目的の違う2つの依頼が1通に入っていることがあります。 台帳では2件に分けたほうが、装置も納期も別々に管理できます。分けるかどうかは受付担当が決めます。

記録を残す

• 元のメール（受信日時・差出人・本文・添付）と、フォームの回答
• プロンプトに渡した文面（引用と署名を落としたあとのもの）
• プロンプトが返したJSONの全文
• 台帳に入れた値と、受付担当が直した項目と直した後の値
• 装置と納期の候補、受付担当が確定した装置と納期
• 回答メールの送信日時と、聞き返しの送信日時・返事の受信日時

4つ目の「直した項目」は、プロンプトを直す材料になります。 毎月どの項目を直しているかを数えると、たとえば「試料数を ok で取り出したのに違っていた」が多いのか、「測定項目の言い方が対応表に無い」が多いのかが分かります。前者はプロンプト、後者は対応表を直します。