Teamsで購買申請から発注までを完結させる方法

購買申請をTeams上で回すと、承認そのものは確実に速くなります。承認者が普段見ている画面に依頼が届き、別システムへのログインが不要になるためです。一方で、承認が終わった後の発注は多くの組織で手作業のまま残り、そこで手戻りが発生します。この記事では、Teamsで購買申請を運用する3つの方法と、承認と発注の分断をどう埋めるかを整理します。

この記事の要点

• Teamsで購買申請を回す方法は、標準の承認アプリ／Power Automateでの作り込み／承認と発注が一体のサービス、の3通り。
• 標準の承認アプリは始めるのが最も速いが、金額別の承認ルートと発注の自動化には対応しない。
• Power Automateで作り込むと発注まで届くが、購買サイトごとに連携を持つことになり保守対象が増える。
• 承認と発注が分断されている限り、在庫切れや価格変動による再申請はなくならない。

購買申請でTeamsを使う意味

承認待ちが短くなる

購買申請の全工程のうち、実作業の時間よりも承認待ちの時間のほうが長いのが一般的です。専用のワークフローシステムに申請を出すと、承認者はそのシステムにログインして初めて依頼に気づきます。ログインの頻度が週に数回であれば、承認待ちはその頻度に律速されます。

Teamsを入口にすると、承認者は常時開いている画面で依頼を受け取れます。これだけで承認待ちが短くなるため、購買申請とTeamsの相性は本来良好です。

ただし「承認が速い」だけでは購買は速くならない

購買業務のゴールは、承認を得ることではなく、必要なものが必要なタイミングで届くことです。承認が速くなっても、そのあと購買担当者が購買サイトにログインして手で発注する運用が残っていれば、全体のリードタイムはそこで決まります。

さらに厄介なのが、承認と発注の間に生じる時間差です。承認時点の価格と在庫が、発注時点で変わっていることがあります。金額が上振れすれば再申請が必要になり、承認をもう一巡することになります。この構造は出張手配でも同じ形で現れ、出張申請の手動再予約はなぜ多発するのかで詳しく分解しています。

承認の前に決めておく申請項目

方法を選ぶ前に、申請フォームの項目を決めてください。ここが曖昧だと、どの方法を選んでも差し戻しが増えます。最低限必要なのは、品目・数量・単価・金額合計・希望納期・用途・発注先・予算科目の8項目です。「品名と金額だけ」の申請は、用途の確認で1往復、予算の確認でもう1往復が発生します。

あわせて、発注先と品目は自由記述ではなく選択式にしてください。後述する分割発注の検知は、この2つが集計可能な形で記録されていないと成立しません。

方法1：標準の承認アプリで運用する

できること

Teamsの承認（Approvals）アプリには購買申請のテンプレートが用意されており、品目・数量・金額・用途を入力して承認者に送るところまでを、設定なしで始められます。承認者はメッセージ上のボタンで承認・却下でき、履歴も残ります。

部門内で完結する少額の備品購入や、月に数件程度の発注であれば、この方法で十分に回ります。導入コストがほぼゼロという点は、他のどの方法にも真似できない利点です。

できないこと

3つの制約があります。ひとつめは金額による承認ルートの切り替えで、標準機能では組めません。ふたつめは発注との接続で、承認後に何かを自動実行する仕組みを持ちません。みっつめは横断的な集計で、情シスや経理が全社の購買申請を一覧・集計する画面がありません。

とくに3つめは、購買が全社に広がった段階で効いてきます。四半期ごとに「この期間の購買申請をすべて出してほしい」と求められた時、個別のチャット履歴を追うしかない状態になります。この論点はTeams経費申請のワンクリック承認｜標準機能の限界でも扱っています。

標準アプリで運用を続けるための工夫

標準アプリのまま少し延命したい場合、承認者を役職ではなくグループで指定すること、そして月次で申請の一覧を手動でエクスポートして保管することの2点をやっておくと、後からの移行が楽になります。前者は異動時の修正を減らし、後者は移行時に過去分の申請データを引き継ぐための保険になります。

方法2：Power Automateで作り込む

基本構成

申請フォーム（Microsoft FormsまたはSharePointリスト）を入口にし、Power Automateで金額別の承認ルートを分岐させ、承認後にSharePointリストへ書き戻し、購買担当者に通知する——というのが標準的な構成です。承認カードをAdaptive Cardsで作り込めば、承認者はカード上の情報だけで判断できます。

作成と管理はTeamsの「Workflows」アプリからも行えます。標準の承認アプリとの役割の違いはTeamsのWorkflowsアプリとは？承認アプリとの使い分けで整理しています。

設計上の勘所

承認者をフロー内に直接書かないこと、これが最大のポイントです。承認者マスタ用のリストを別途用意し、部門コードや金額帯をキーに承認者を引く構成にしておくと、組織改編のたびにフローを編集せずに済みます。

もうひとつが分割発注への対策です。「30万円超は役員承認」と決めると、29万円の申請が2件に分かれる運用が生まれます。同一申請者・同一取引先の申請を一定期間で合算して検知する仕組みを、最初から入れておいてください。実装としては、承認フローの中で過去30日の同一組み合わせを検索し、合算額が閾値を超える場合に承認カードへ警告を表示する、という形が現実的です。完全に止めるのではなく、承認者が気づける状態にするのが落としどころです。

本記事はTeamsのチャット上で申請から発注までをどう回すかに絞っています。フォーム項目や承認ルート、ステータスをMicrosoft 365全体でどう設計するかはMicrosoft 365で購買申請を自動化する設計の勘所にまとめています。

どこで詰まるか

発注の自動化まで届かせようとすると、購買サイト側のAPIを叩くことになります。HTTPアクションはプレミアムライセンスが必要で、認証情報の管理も発生します。そして購買サイトが複数に分かれている場合、その数だけフローと認証を持つことになります。

オフィス用品、工具、PC周辺機器はそれぞれ強い通販サイトが異なるため、実務では3〜5サイトを使い分けている組織が珍しくありません。サイトごとの性格の違いはオフィス用品通販6社比較｜主要サイトの違いと選び方で比較しています。

もうひとつの詰まりどころが、証跡の分散です。承認履歴はApprovalsアプリ、申請データはSharePointリスト、実行ログはPower Automate、発注記録は購買サイトの注文履歴——と4か所に分かれるため、監査対応時の突合が手作業になります。この構造はTeams承認の履歴・監査証跡はどこまで残せるかで詳しく扱っています。

方法3：承認と発注が一体のサービスを使う

「承認＝購買」という形

3つめは、承認した瞬間に発注が確定する仕組みを使う方法です。申請の時点で購買カタログから商品を選び、在庫を仮押さえした状態で総額つきの承認依頼を出します。承認者が承認すると、その場で発注が確定します。

この形にすると、承認と発注の間の時間差が消えます。在庫切れによる取り直しも、価格変動による再申請も発生しません。承認後に購買担当者が発注する工程そのものがなくなるため、削減されるのは時間ではなく工程です。

1Approval for Teamsは、Teamsのチャットを申請の入口としてこの形を実現します。承認者に届くカードには、品目・数量・総額・納期が確定した状態で表示され、承認ボタンがそのまま発注の実行になります。

統制と証跡

承認と発注が同じ仕組みの中で起きるため、「誰が申請し、誰が承認し、いくらで何を発注したか」が1本の記録として残ります。承認額と発注額が一致することが仕組みで保証されるため、突合作業そのものが不要になります。Teams標準の承認アプリで課題になる横断的な集計や監査対応は、この時点で解消します。

金額帯ごとの統制設計の考え方は消耗品購買の内部統制｜リスクと承認フロー設計で整理しています。

買ったあとの台帳につなぐ

発注の記録がそのまま資産台帳に流れる構成にしておくと、誰に何を貸与したかを追える状態が自動的に維持されます。購買と台帳が別運用だと、入社・退職のたびに現物と記録がずれていきます。備品台帳と端末管理の役割の違いは備品管理システム比較7選｜選定の進め方で扱っています。

3つの方法をどう選ぶか

判断軸は、購買申請の年間件数と、発注先の数、そして統制要件の3つです。

年間の申請が数十件で、発注先が1〜2サイトに収まり、監査で証跡を求められる可能性が低いなら、標準の承認アプリで十分です。件数が増えて金額別のルートが必要になったらPower Automateへ。発注先が複数に分かれ、承認後の発注作業が担当者の負担として無視できなくなったら、承認と発注が一体の仕組みを検討する段階です。

移行を考えるサインとして分かりやすいのは、購買担当者が「承認待ちの一覧」を自分でExcelやメモに転記し始めたときです。これは、仕組みが担うべき状態管理を人が肩代わりし始めた合図で、件数がさらに増えれば必ず破綻します。

よくある質問（FAQ）

Teamsの標準機能だけで購買申請は運用できますか？

申請と承認までであれば、承認アプリのテンプレートで運用できます。金額別の承認ルート、承認後の発注、全社横断の集計が必要になった時点で標準機能の外側になります。

購買申請の承認ルートは金額で分けるべきですか？

分けることを推奨します。全件に同じ重さの承認をかけると現場が止まり、逆にすべて軽くすると統制が効きません。少額は事後承認と月次モニタリング、一定額以上は事前承認、という段階を決めるのが実務的です。

承認後の発注を自動化するには何が必要ですか？

購買サイト側にAPIまたはPunchOut等の連携手段があることが前提です。Power Automateから呼ぶ場合はHTTPアクション（プレミアムライセンス）と認証情報の管理が必要になります。発注先が複数にわたる場合は、それぞれについて用意することになります。

在庫切れで再申請が発生するのを防げますか？

申請の時点で在庫を仮押さえし、確定した総額で承認を取る仕組みであれば防げます。承認を取ってから発注する順序である限り、その間の在庫変動は避けられません。

分割発注はどう検知すればよいですか？

同一申請者・同一取引先・同一品目の申請を、一定期間で合算して閾値と比較します。検知したら自動で却下するのではなく、承認カードに警告として表示し、承認者が判断できる状態にするのが実務的です。この検知には、発注先と品目が選択式で記録されている必要があります。

まとめ

Teamsで購買申請を回すこと自体は、承認待ちを短くする確実な打ち手です。ただし購買業務全体のリードタイムを決めているのは、承認後の発注工程であることが多く、そこに手を入れなければ体感は変わりません。

標準の承認アプリで始め、件数と統制要件の増加に応じてPower Automateへ、そして承認後の発注作業が無視できない負担になったら承認と発注が一体の仕組みへ——という段階を踏むのが、無理のない進め方です。どの段階でも、申請項目の設計と承認者マスタの外出しだけは最初にやっておくと、次の段階への移行が楽になります。