Microsoft 365で購買申請を自動化する設計の勘所

備品購入やソフトウェアの購買申請は、稟議の中でも件数が多く、金額の大小もばらつきが大きい業務です。Microsoft 365を全社導入している企業であれば、Microsoft Forms・SharePoint・Power Automate・Teamsの組み合わせで、申請から承認までを追加ライセンスなしに電子化できます。一方で、実際に運用を始めると「承認は速くなったのに、発注は結局これまでどおり担当者が手作業」という状態に落ち着きがちです。本記事では、購買申請ワークフローをMicrosoft 365で構築する具体的な手順と設計の勘所に加え、承認の先に残る発注・支払い・経費計上をどう扱うかまでを整理します。

この記事の要点

• 購買申請の自動化が失敗する典型的な原因は、ツール選定ミスではなく「どこまでを自動化の対象にするか」を決めないままフローを作り始めること。
• 申請・承認・記録・通知までなら、Microsoft Forms、SharePointリスト、Power Automate、Teamsの組み合わせで構築できる。
• 購買申請は経費精算やSSO申請と違い、承認の先に「発注」という実行行為があるため、標準機能だけでは埋めにくい部分が残る。
• 残る壁はいずれも「承認と発注が別々の行為として分かれている」ことに起因する。

購買申請を自動化する前に何を決めるべきか？

購買申請の自動化がうまくいかない典型的な原因は、ツールの選定ミスではなく、購買プロセスのどこまでを自動化の対象にするかを決めないままフローを作り始めることです。

購買プロセスは、大きく「申請 → 承認 → 発注 → 支払い → 受領 → 経費・会計計上」の6段階に分かれます。このうちMicrosoft 365の標準機能で完結できるのは、申請・承認と、その記録・通知までです。発注以降は、購買サイトでの注文操作、支払手段の選択、納品物の受領確認、証憑の保存といった、システムの外側の作業が中心になります。

「承認の電子化」と「購買の自動化」は別物

Power Automateで承認フローを組むと、押印や口頭承認はなくなり、承認履歴も残ります。ただしフローが最後に生み出すのは「承認済み」というステータスであって、物やライセンスそのものではありません。承認が下りた後、申請者か購買担当者が改めて購買サイトを開いて注文する作業は残ります。

この引き継ぎ部分を設計せずにフローだけ作ると、次のような問題が起きます。

• 承認済みのまま発注されない案件が滞留する（申請者が「承認された＝手配された」と誤解する）
• 承認された内容と実際に発注した内容（数量・型番・金額）がずれる
• 担当者が個人で立て替え、後から経費精算する運用が温存される
• 承認履歴はSharePointに、発注の記録は購買サイトに、支払いの記録は精算システムにと、情報が分断される

先に決めておく4つの論点

フローを作り始める前に、次の4点を関係部署で合意しておくと、後戻りを減らせます。

1. 承認の対象：金額いくらから承認を必要とするか。少額のものは事後報告でよいか
2. 承認者の決め方：金額帯・部門・購入カテゴリ（IT機器・消耗品・ソフトウェア）のどれで分岐させるか
3. 発注する人：承認後に誰が発注するのか。申請者本人か、購買担当に集約するか
4. 支払手段：法人カード、請求書払い、個人立替のどれを標準とするか

特に3と4は、情シスだけで決められない論点です。総務・経理を巻き込んで先に合意しておかないと、フローの完成後に運用が回らなくなります。

購買申請ワークフローの設計4ステップ

ここからは、実際の構築手順に沿って設計のポイントを整理します。Power Automateのフローエディタ上での基本操作（トリガーの設定、「承認の開始と待機」アクションの追加、条件分岐）はMicrosoft 365で承認ワークフローを設定する方法【画面付き】で画面キャプチャつきに解説していますので、あわせてご覧ください。

ステップ1：申請フォームを設計する

申請の入り口は、Microsoft FormsかSharePointリストのフォームを使うのが一般的です。購買申請で最低限そろえたい項目は次のとおりです。

• 品名・型番・数量・単価・合計金額
• 購入先（URLまたは取引先名）と見積書の添付
• 希望納期
• 予算科目・部門コード（費用の計上先）
• 利用目的と、代替品を検討したかどうか

設計上の勘所は2つあります。ひとつは、合計金額を自由入力にしないことです。単価×数量の計算値にしておかないと、後続の金額分岐の判定がぶれます。もうひとつは、後から集計したい軸を必ず選択式にすることです。部門・カテゴリ・購入先を自由記述にすると、年間の購買実績を集計する段階で必ず手作業が発生します。

ステップ2：SharePointリストのステータスを設計する

申請データの保存先となるSharePointリストでは、ステータス列の設計が要になります。「申請中／承認済／却下」の3つだけにすると、承認の記録は残っても、購買が完了したかどうかが分からないという状態になります。

• 申請中 → 承認済 → 発注済 → 受領済 → 計上済
• 却下、取り下げ

このように発注以降のステータスまで持たせておくと、「承認されたが発注されていない案件」を一覧で洗い出せるようになります。あわせて、承認者・承認日時・承認コメント、発注番号、実際の購入金額を記録する列も用意しておきましょう。申請額と実績額の差額を追えるかどうかは、予算管理の精度に直結します。

ステップ3：承認ルートを設計する

購買申請の承認ルートは、金額帯で分岐させるのが基本です。

金額帯（例）	承認者
〜3万円	直属の上長のみ
〜30万円	上長＋部門長
30万円超	上長＋部門長＋経理（＋役員）

これに加えて、IT機器・SaaSは情シスの承認を挟む、といったカテゴリ別の分岐を重ねるケースが多くなります。

Power Automateで実装する際の勘所は、承認者をフロー内に直接書かないことです。承認者のメールアドレスをアクション内にハードコードすると、組織改編や異動のたびにフローを直接編集することになり、保守できる人が限られていきます。承認者マスタ用のSharePointリストを別途用意し、部門コードをキーに承認者を引く構成にしておくと、以降の変更はリストの更新だけで済みます。

金額分岐や合議、代理承認を含む稟議ルートをPower Automateでどこまで作り込めるかはPower Automateで多段階承認の稟議フローは作れる？金額分岐・代理承認・組織改編の限界で詳しく整理しています。

もうひとつ忘れがちなのが、分割発注の抜け道です。「30万円超は役員承認」と決めると、29万円の申請を2件に分ける運用が生まれます。同一申請者・同一取引先の申請を一定期間で合算してチェックする仕組みか、少なくとも定期的に検知して確認する運用を用意しておきましょう。

金額分岐や多段階承認をどこまでPower Automateで作り込めるか、どこから内製の限界に達するかについてはMicrosoft 365の承認ワークフロー｜Teams標準機能の限界と全社展開の3つの選択肢で3つの選択肢として整理しています。

ステップ4：承認後の引き継ぎを設計する

最後に、承認後の動線を決めます。Power Automateの条件分岐で「承認済」になったとき、次の処理を自動化しておくと、滞留を防ぎやすくなります。

• 購買担当者のTeamsチャネルへ、発注に必要な情報（品名・数量・購入先URL・予算科目）をまとめて投稿する
• 申請者に「承認されたので発注を依頼した」旨を通知する
• 一定日数が過ぎても「発注済」に変わらない案件を、リマインドとして再通知する

このリマインドの仕組みがあるかどうかで、運用の安定度が大きく変わります。承認後に人の手を介する以上、その人が動いたかどうかを追う仕組みまでがワークフローの設計範囲です。

標準機能だけで運用すると何に突き当たるのか？

購買申請は、経費精算やSSO利用申請と比べても、承認の先に「発注」という実行行為がある分、標準機能だけでは埋めにくい部分が残ります。

承認内容と発注内容の一致を保証できない

Power Automateが承認するのは「申請フォームに入力された内容」であって、実際にどの商品をいくらで発注したかではありません。承認後に価格が変わっていた、型番違いを買っていた、といったズレは、後から人が突き合わせるまで分かりません。内部統制の観点では、この突き合わせ作業が残り続けること自体がリスクになります。

個人立替が温存される

承認が電子化されても、支払手段が変わらなければ、現場の担当者が自分のカードで購入して後から精算する運用は残ります。この場合、経費精算の工数が別途発生し、月末に精算処理が集中する状況も変わりません。経費精算側の自動化についてはPower Automateで経費精算を自動化する方法と注意点で整理しています。

取引先ごとに請求書が分散する

購買先が増えるほど、請求書は取引先ごとにばらばらの形式・締日で届きます。経理は請求書と社内の承認記録を1件ずつ突き合わせることになり、購買件数に比例して消込作業が増えていきます。

ライセンスと保守の制約

Power Automateの実行回数の上限や、プレミアムコネクタが必要になる条件も、全社展開の前に確認が必要です。あわせて、分岐が増えたフローを誰が保守するのかという属人化の問題も残ります。SaaSの利用申請で同様の課題を扱ったMicrosoft 365 SSO申請承認、標準機能の限界と解決策も参考になります。

本記事はFormsやSharePointを含めたMicrosoft 365全体での設計を扱っています。申請の入口をTeamsのチャットに寄せて運用する場合の3通りの組み方と、分割発注への対策はTeamsで購買申請から発注までを完結させる方法にまとめています。

承認と発注をつなぐとどうなるのか？

ここまでの壁は、いずれも「承認と発注が別々の行為として分かれている」ことに起因します。裏を返せば、承認した時点で発注そのものが実行される仕組みにできれば、まとめて解消できる課題でもあります。

1Approval for Microsoft 365は、この「承認と実際の購買をつなぐ層」を担う仕組みです。Microsoft 365やTeams上で承認が下りた時点で購買が実行されるため、「承認済みの申請」と「実際の発注」が別々に存在する状態が生まれません。承認後の発注漏れや、申請内容と異なる発注が構造的に起きにくくなります。

支払いの面でも、法人決済の仕組みによって従業員の個人立替を前提としない運用に切り替えられ、複数サービス・複数取引先の利用料は月1回の法人一括請求にまとめられます。購買データは実行された時点で経費データとして自動生成され、会計・経費精算システムと連携できるため、購買と経費の情報が分断されません。事前承認時の価格と実際の購買時点の価格に差が出た場合も、あらかじめ許容範囲を設定しておけば差し戻しなしに購買を進められる「ダイナミック・ポリシー」により、承認から購買完了までのリードタイムを短縮できます。

比較項目	Microsoft 365の標準機能で内製	1Approval for Microsoft 365
承認まで	Forms・SharePoint・Power Automate・Teamsで構築できる	既存の承認フローをそのまま入口にできる
承認後の発注	申請者または購買担当が別途手配	承認と同時に購買を実行
承認内容と発注内容の一致	後から人が突き合わせる	承認された内容がそのまま購買される
支払い	個人立替・カード・請求書が混在しやすい	法人決済で立替を前提としない
請求	取引先ごとに請求書が分散	複数サービス・複数取引先を月1回の一括請求に集約
経費・会計連携	別途フローや手作業で連携	購買実行時点で経費データを自動生成し連携

まず承認フローをPower Automateで作り、運用が固まった段階で発注・支払いまでつなぐか判断する、という進め方も現実的です。購買件数が多く、立替精算と請求書の突き合わせに工数がかかっている場合は、1Approval for Microsoft 365の詳細を見るから具体的な仕組みを確認してみてください。

よくある質問（FAQ）

購買申請のワークフローはMicrosoft 365の標準機能だけで作れますか？

申請・承認・記録・通知までであれば、Microsoft Forms、SharePointリスト、Power Automate、Teamsの組み合わせで構築できます。多くの場合、Microsoft 365ライセンスに含まれる標準コネクタの範囲で対応可能です。ただし、承認後の発注・支払い・経費計上は標準機能の対象外で、担当者の手作業として残ります。

金額によって承認者を変える設定はできますか？

できます。Power Automateの条件分岐（If/Switch）で金額帯ごとに承認アクションを振り分ける構成が一般的です。ただし分岐の数が増えるほどフローは複雑になり保守しづらくなるため、承認者はフロー内に直接書かず、承認者マスタ用のSharePointリストから引く設計にしておくことをおすすめします。

申請フォームはMicrosoft FormsとSharePointリストのどちらがよいですか？

入力項目が少なく、社内の誰でも手早く申請できることを優先するならMicrosoft Formsが向いています。申請データの一覧管理、ステータスの更新、添付ファイルの扱いまで含めて一元化したい場合は、SharePointリストのフォームを申請の入り口にするほうが運用しやすくなります。購買申請は発注後のステータス管理が重要になるため、後者を選ぶケースが多くなります。

承認された購買申請が発注されないまま放置されるのを防ぐには？

SharePointリストのステータスに「発注済」「受領済」を用意したうえで、承認から一定日数が経過しても発注済に変わらない案件を検知してリマインドするフローを追加してください。人の手を介する工程が残る以上、その工程が完了したかどうかを追う仕組みまで含めて設計する必要があります。

購買申請の電子化は電子帳簿保存法への対応になりますか？

承認の記録を電子化することと、電子帳簿保存法が求める証憑（見積書・注文書・請求書・領収書）の保存要件を満たすことは別の話です。Power AutomateやSharePointは、タイムスタンプ付与や検索要件を標準で満たすわけではないため、証憑の保存方法は別途設計が必要です。

まとめ

Microsoft 365の標準機能だけでも、購買申請の申請・承認・記録は十分に自動化できます。重要なのは、フローを作る前に「承認の対象」「承認者の決め方」「発注する人」「支払手段」の4点を関係部署で合意しておくこと、そしてSharePointリストのステータスを「承認済」で終わらせず、発注・受領・計上まで持たせておくことです。

そのうえで、承認の先に残る発注・支払い・経費計上をどう扱うかが、購買業務全体の工数を左右します。承認は速くなったのに購買のリードタイムが変わらない、立替精算と請求書の突き合わせが減らない、という状態が続く場合は、承認と購買の実行そのものをつなぐ仕組みまで含めて検討する段階といえます。