パソコンと周辺機器の購入・移動・廃棄の申請からIT資産台帳の更新案を作り、台帳と申請の食い違いを毎月洗い出す

処理の起点を決める

申請の経路ごとに、入口のフローを分けます。 Microsoft Forms の申請は「新しい応答が送信されたとき」をトリガーにし、「応答の詳細を取得する」で回答の中身を取ります。メールで届く申請は、申請用の共有メールボックスの「共有メールボックスに新しいメールが届いたとき (V2)」で受けます。どちらの入口も、同じ子フローに申請の本文と添付を渡し、そこから先は区別しません。

チャットで届いた急ぎの申請は、担当者がフォームに転記する運用を残します。 経路を増やすほど、どれか1つだけ処理されない期間ができます。入口は2つに絞ります。

月1回の突合は、別のフローにします。 「繰り返し」トリガーで頻度を月にすると、毎月同じ日に動きます。毎月1日の朝、前月分を対象に動かします。月の途中で動かすと、承認待ちの申請が食い違いとして大量に出ます。

入力データを集める

質を決めるのは、いちばん下の2つです。 社員の一覧が無ければ、「田中さん」が誰なのかを決められません。設置場所の一覧が無ければ、AIは申請に書かれた「5階の東側」をそのまま更新案に入れ、第3章の（d）の書き方のゆれがそのまま残ります。

添付の写真は、資産番号のシールが写っていれば使います。 プロンプトには画像やドキュメントの入力を足せ、対応する形式は PNG、JPG、JPEG、PDF です。シールの写真が1枚あるだけで、対象の資産を探す手間がほとんど消えます。 申請フォームに「資産番号のシールの写真（任意）」という欄を足すのが効きます。

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

台帳は SharePoint コネクタの「アイテムを取得」で引きます。全件を取らず、フィルター クエリで絞ります。 抜き出した資産番号があれば資産番号で、無ければシリアル番号で、それも無ければ利用者のメールアドレスで絞り込みます。

4番目では確定させません。 「会議室Bのモニター」は、会議室Bに2台あれば決められません。候補を並べて担当者に選んでもらいます。

利用者名から社員を引くときは、氏名ではなくメールアドレスに直してから引きます。 同じ姓の社員は必ずいます。AIに抜き出させるのは申請に書かれた氏名までで、社員の一覧と照らしてメールアドレスに直すのはフローの側です。一致が2人以上なら、そこで止めて担当者に回します。

SharePoint コネクタには、接続ごとに60秒あたり600回という呼び出しの調整制限があります。組織変更で数十件の申請がまとめて届いた日は、台帳を1件ずつ何度も引く作りにすると、この制限に近づきます。 申請1件につき台帳を引くのは1〜2回に収めます。

AIへ渡す前に整形する

1. 申請の種類の確認 … フォームの選択式の値（購入／移動／廃棄）を読みます。メールの申請には種類が無いので、AIに判定させます
2. 署名と引用の除去 … メールの署名と、過去のやり取りの引用部分を落とします
3. 添付の確認 … PNG、JPG、JPEG、PDF 以外は渡しません。合計が25MB未満、ページ数が50ページ未満であることを確かめます
4. 重複の確認 … 同じ申請者から同じ内容が、フォームとメールの両方で届いていないかを確かめます
5. 社員の一覧と設置場所の一覧を渡せる形にする … 申請者の所属に関係する範囲だけに絞ります

3番目の制限は、プロンプトに画像やドキュメントを渡すときのものです。 公式ドキュメントでは、ファイルの合計が25MB未満、ドキュメントのページ数が50ページ未満、処理は最大100秒とされ、大きなドキュメントから抽出した情報は、特にテーブルの行で不正確または不完全になる可能性があるとされています。納品書の明細が長いものは、ここに当たります。

5番目で一覧を絞るのは、渡す量を減らすためだけではありません。 800名全員の一覧を渡すと、AIは同じ姓の誰かを選びます。選ばせる範囲を、申請者の部署とその周辺に限ります。

AIに処理させる

させるのは、申請の文面から「申請の種類」「対象の資産」「変更の中身」を抜き出し、それぞれの根拠にした文字列を書き出すことだけです。

1つの申請に複数の資産があれば、資産ごとに1行ずつ出させます。 「PCとモニター2台とドック」なら4行です。第3章の（b）の反映漏れは、ここで機械的に防ぎます。

2行目がいちばん起きやすい失敗です。 「田中さんの2023年に買ったPC」と書かれていると、AIは台帳の候補を見て資産番号を埋めたくなります。埋めた番号が正しくても、根拠が申請の文面に無ければ、それは推測です。 だから台帳はAIに渡さず、候補を引くのはフローに任せます。

指示内容を固定する

あなたは情報システム部で、IT資産台帳の更新を担当する立場です。
社員から届いた申請の文面と添付だけを見て、台帳の更新に必要な事実を抜き出してください。
推測で埋めないでください。

【抜き出すもの】
1. 申請の種類（purchase / move / dispose。複数あれば mixed）
2. 対象の資産（1台ごとに1行）
   - asset_no（資産番号）、serial_no（シリアル番号）、category（種別）、model（型番）
   - current_user（現在の利用者の氏名）、current_location（現在の設置場所）
3. 変更の中身（1台ごとに1行）
   - new_user（新しい利用者の氏名）、new_dept（新しい所属）
   - new_location（新しい設置場所）、new_status（新しい状態）、effective_date（希望日）
4. evidence（各項目を抜き出した元の文字列をそのまま）
5. questions（読み取れなかった点、矛盾している点）

【厳守事項】
- 申請の文面と添付に書かれていない値は、空欄にしてください。
- 資産番号とシリアル番号は、書かれた文字列をそのまま入れてください。
  桁を補う、似た番号に直す、型番や購入時期から推測することをしないでください。
- 写真に資産番号のシールが写っている場合は、読み取れた文字列を入れ、
  evidence に「添付写真のシール」と書いてください。読み取れない文字があれば空欄です。
- 1つの申請に複数の機器があれば、機器ごとに別の行にしてください。
  「一式」「まとめて」と書かれていても、機器の種類ごとに分けてください。
- 氏名は書かれたとおりに入れ、同じ姓の別の人に置き換えないでください。
- 設置場所は【設置場所の一覧】の表記に合わせてください。
  一覧のどれに当たるか決められなければ、書かれたとおりに入れて questions に書いてください。
- 廃棄してよいか、購入してよいかの意見は書かないでください。
- 台帳の行を選ぶことはしないでください。

【申請の文面】{request_text}
【添付】{attachments}
【申請者】{requester}
【設置場所の一覧】{locations}

「型番や購入時期から推測しない」を明記しないと、資産番号が埋まります。 申請に「2023年度のPC」とあれば、それらしい番号の形を作って入れてきます。禁じるのは、番号を作る判断そのものです。

「一式」と書かれていても分ける、を入れるのは、移動の申請の大半がこの書き方だからです。 何も言わなければ「PC一式」を1行で返し、モニターとドックの移動が台帳から落ちます。

出力形式を固定する

プロンプトの出力は、次の形の JSON で固定します。

{
  "request_id": "",
  "request_type": "purchase | move | dispose | mixed",
  "items": [
    {
      "asset_no": "", "serial_no": "", "category": "", "model": "",
      "current_user": "", "current_location": "",
      "new_user": "", "new_dept": "", "new_location": "",
      "new_status": "", "effective_date": "",
      "evidence": { "asset_no": "", "new_user": "", "new_location": "" }
    }
  ],
  "questions": []
}

この JSON を受けて、フローが更新案を作ります。 更新案は AI の出力とは別の形にします。

1つ目の理由は、AIの出力と台帳への書き込みのあいだに、規則の層を置けることです。 ready は対象の行が1つに決まり、新しい値が一覧の表記に合っているもの、needs_choice は候補が複数あるもの、conflict は申請の「現在の利用者」と台帳の値が違うもの、not_found は台帳に見つからないものです。判定を決めるのはフローの条件分岐で、AIではありません。

2つ目は、conflict を拾えることです。 申請に「田中さんのPCを」と書かれていて、台帳ではそのPCの利用者が鈴木さんなら、台帳がすでにずれているか、申請が別の機器を指しています。 どちらにしても、そのまま書き換えてはいけない1件です。

3つ目は、承認の画面に差分だけを出せることです。 担当者が読むのは文面ではなく「PC-0412：利用者 田中→佐藤」の行です。

システムへ連携する

購入の申請は、承認の時点では台帳に行を足しません。 申請が承認されても、機器が届くまでは資産番号もシリアル番号もありません。「購入予定」として申請記録にだけ残し、納品の連絡で行を足します。 承認の時点で行を足すと、届かなかった機器が台帳に残ります。

承認の待ち時間には上限があります。 Power Automate のフロー1回の実行は30日が上限で、承認のような保留中のステップも含まれ、30日を過ぎると保留中のステップはタイムアウトします。 承認が止まっている申請は、第7章の月次の突合で拾います。

人が確認する

更新案は全件、担当者が承認します。 ただし見るのは差分の行だけで、ready のものは一覧で流し見て承認します。

1. conflict を先に見る … 申請の「現在の利用者」と台帳が食い違うもの。台帳のずれを見つける入口です
2. needs_choice で候補を選ぶ … 候補の中から正しい行を選びます。選べなければ申請者に問い合わせます
3. not_found を確かめる … 台帳に登録されていない機器か、申請の書き間違いかを確かめます
4. ready を流し見る … 差分の行を見て、まとめて承認します
5. 修正したら記録する … どの列を、どの値に直したかを残します

1番目を省かないでください。 conflict は1件ずつの処理の中で台帳のずれが見つかる、数少ない機会です。そのまま上書きすると、ずれの痕跡が消えます。

廃棄の承認には、もう1人を足します。 状態を「廃棄済」にするのは、データ消去の証明を受け取ってからです。消去証明の受け取りを確かめる人と、台帳を書き換える承認をする人を分けます。

例外に対処する

プロンプトが JSON を返さないときについて、公式ドキュメントは原因の1つとして、モデルが JSON をメタデータ情報で囲む場合を挙げています。 対処として「回答に JSON マークダウンを含めないでください」という指示をプロンプトに足すことが示されています。最初からプロンプトの末尾に入れておきます。

記録を残す

• 申請の原文（フォームの回答、メール本文）と添付
• プロンプトが返した JSON の全文
• フローが作った更新案（対象の行、列名、現在の値、新しい値、判定）
• 承認の結果と、担当者が直した内容（どの列を、何から何へ）
• 台帳に書き込んだ日時と、書き込んだ行の「最終更新の申請番号」
• 月次の突合で出た食い違いと、その原因と対応

ログは Power Automate の実行履歴に頼らず、SharePoint の申請記録に残します。 実行履歴の保持は、実行の開始時刻から30日です。台帳がいつ、どの申請で変わったかは、何か月も後の棚卸しで必要になります。

台帳の「最終更新の申請番号」の列が、月次の突合の鍵になります。 台帳の行が変わっているのに、この列が前のままなら、誰かが申請を通さずに台帳を直接書き換えたということです。