Microsoft 365 2026年9月26日

Microsoft 365の出張申請｜2フロー構成

Power Automateで出張申請を組むと、申請から精算までを1本のフローに載せられません。フロー実行期間30日という上限が理由です。事前承認フローと精算フローに分ける2フロー構成、SharePointリスト・Dataverse・Excelの置き場所の選び方、明細の持たせ方、90日未実行で自動無効化される運用上の罠までを整理します。

Power Automateで出張申請を作ろうとすると、最初に「申請から精算まで1本のフローで通そう」と考えます。それは動きません。 技術的な作り込みの問題ではなく、Power Automateの仕様上の上限に当たるためです。

本記事は、その制約から逆算した構成を扱います。承認アクションの使い分けはPower Automateで稟議フローは作れる？、画面つきの手順はMicrosoft 365で承認フローを作る方法にあるので、ここでは出張という業務に固有の設計に絞ります。

なお出張申請が他の申請と構造的に違う点（承認と支出の間に手配が挟まる／申請時点で金額が確定しない／1件から4種類の支出が出る）はkintoneの出張申請で整理しました。本記事はそれを前提に、Microsoft 365でどう実装するかを書きます。

この記事の要点

Power Automateのフロー実行期間は30日が上限。 承認アクションも承認者が応答しないまま30日でタイムアウトし、フローはエラー終了する。
出張は申請から精算まで数週間かかる。1本のフローに載せると、長期の出張や月締めの精算で確実に落ちる。
解は2フロー構成。事前承認フローと精算フローを分け、申請IDで紐づける。手配を代行するなら3フロー。
データの置き場所はSharePointリストが現実解。Dataverseは自然に書けるが、E5を持っていても Power Apps のライセンスが別途要る。
交通費の明細は親子2リストで持つ。1リストに固定列で持たせると必ず足りなくなる。
90日間実行されないフローは自動的に無効化される。 出張が少ない部署のフローは、これで静かに止まる。

最大の制約：1本のフローには載らない

ここが設計の出発点です。

Power Automateのフロー実行期間には30日という上限があります。 また承認アクションも、承認者が応答しないまま30日が経過すると強制的にタイムアウトし、フローはエラーで終了します。

出張の業務は次の流れです。

出張の2週間前に事前申請 → 承認
出張の実施（1〜3日）
帰着後、精算を申請 → 承認
月次で支払い

1から4まで、普通に1か月を超えます。 月末締めの会社なら、月初の出張は精算承認まで40日以上かかることも珍しくありません。

つまり「申請から精算まで1本のフロー」で組むと、長期の出張や月締めの精算で確実にタイムアウトします。 しかも失敗するのは作った直後ではなく、運用が始まって1か月後です。テスト時には短い期間で通るため、この問題は本番で初めて出ます。

2フロー構成

分ける単位は、承認が発生する回数です。

	フロー1：事前承認	フロー2：精算
トリガー	出張申請リストに項目が作成されたとき	精算リストに項目が作成されたとき
承認	上長（金額により追加）	上長＋経理
所要期間	数日	数日
終了条件	ステータスを「承認済」に更新して終了	ステータスを「精算承認済」に更新して終了

それぞれのフローは数日で完結するので、30日の上限に当たりません。出張の実施期間はフローの外側に置かれます。

紐づけは申請IDのルックアップで行います。精算リストに「出張申請ID」列を持たせ、精算の起票時に選択させる形です。

手配を代行するなら3フロー

総務が切符やホテルを手配する組織では、事前承認フローの終了後に手配フローを挟みます。承認済みで手配が終わっていない案件を一覧で見えるようにするためです。

これはkintoneの3アプリ構成と同じ考え方で、判断基準も同じです。承認済みで手配待ちの案件が見えないと、止まっていることが誰にも分かりません。

分けるデメリット

正直に書くと、2つあります。

申請せずに精算だけ起票できてしまう — ルックアップを必須にすれば防げますが、急な出張の事後申請が通らなくなります。事後フラグを立てて件数を数える設計にしてください
ステータスが2か所に分かれる — 全体像を見るにはビューを作るか、Power BIで結合する手間が増えます

それでも、1本で組んでタイムアウトするより確実に良い選択です。

データをどこに置くか

Microsoft 365では3つの選択肢があります。

	SharePointリスト	Dataverse	Excel（Teams上）
追加ライセンス	不要	必要（Power Apps Premium等）	不要
明細（親子）の表現	2リスト＋ルックアップ	ネイティブに可能	難しい
添付（領収書）	添付列で可	可	実質不可
権限制御	リスト単位・項目単位	セキュリティロールで細かい	弱い
件数の上限	Power Apps経由では委任の制約あり	大規模に耐える	小規模のみ
向く規模	多くの会社の現実解	全社・大規模	試作のみ

SharePointリストが現実解

Dataverseは設計としては自然です。 親子関係をそのまま表現でき、権限もロールで細かく制御できます。

問題はライセンスです。Microsoft 365 E5を契約していても Dataverse は使えません。 利用者全員に Power Apps Premium 等の追加ライセンスが必要です。出張申請のためだけに全社員分を買うのは、多くの会社で割に合いません。

一方SharePointリストは追加費用なしで使えます。制約はありますが、出張申請の規模なら収まることが多いはずです。

Excelは試作までにしてください。 同時編集と権限制御が弱く、件数が増えると壊れます。

明細は親子2リストで持つ

交通費は1回の出張で何行出るか分かりません。往復2行のこともあれば、乗り継ぎと現地移動で15行のこともあります。

1つのリストに「交通費1」「交通費2」…と固定列で持たせる設計は必ず破綻します。 足りなくなるか、大半が空欄のまま列だけ増えるかのどちらかです。

正しくは親子2リストです。

親：出張申請（1件＝1出張）
子：交通費明細（1件＝1区間）、親の申請IDをルックアップ

集計は Power Automate で子を合計して親に書き戻すか、ビューで集計します。

Power Apps を使うなら、件数の壁に注意

明細の入力画面を Power Apps で作る場合、SharePointリストに対する委任の制約があります。既定では一度に扱える件数に上限があり、それを超えると検索や集計が正しく動きません。

出張申請の親リストは年間数百件で収まることが多いですが、明細の子リストは桁が1つ増えます。 年間500件の出張で1件あたり5行なら2,500行です。設計時に見積もっておいてください。

入口をどう作るか

申請の入口は3択です。

Microsoft Forms — 作るのは最速ですが、明細の可変行が作れません。 出張申請の事前申請（行き先・期間・目的・概算）までなら使えますが、精算には向きません。

SharePointのリストフォーム — 追加費用なしで、添付も扱えます。見た目は素朴ですが、まず動かすならこれで十分です。

Power Apps — 明細の入力体験を作り込めます。規程の上限チェックをその場で出す、といったこともできます。ただし前述のライセンスと委任の制約、そして作った人しか保守できない問題が付いてきます。

推奨は、SharePointのリストフォームで始めることです。 運用が固まってから Power Apps を検討しても遅くありません。逆の順序だと、要件が固まる前に作り込んだ画面を捨てることになります。

運用で効く落とし穴：90日で自動無効化される

見落とされやすい仕様です。

90日間実行されていないフローは、自動的に無効化されます。 事前に作成者へ通知メールが届きますが、見落とせばそのまま止まります。

出張申請では、これが現実に起きます。

出張が少ない部署の専用フロー
海外出張だけを扱う別ルートのフロー
年度末にしか使わない特例のフロー

止まっていることに気づくのは、次に使おうとした瞬間です。申請者は「送ったのに承認が来ない」と言い、管理者はフローを見に行って無効化に気づきます。

対策は2つです。

フローを分けすぎない — 条件分岐で1本にまとめられるなら、そのほうが実行頻度が上がって無効化されにくい
通知メールの宛先を個人にしない — 作成者が異動すると誰も気づきません。共有メールボックスか、所有者を複数にしておく

これは承認フローが止まる原因でも扱った、内製フローの保守の問題そのものです。

承認ルートの設計

出張申請で使う分岐は2種類です。

金額による分岐 — 総額が一定額を超えたら承認者を追加します。ただし事前申請の時点では金額が確定していないので、判定に使うのは概算額です。実額との差をどう扱うかは後述します。

出張種別による分岐 — 日帰り／国内宿泊／海外でルートを変えます。海外は渡航先の安全情報確認や保険加入が入るため、別ルートにするのが普通です。

承認アクションの4種類（承認/拒否、全員の承認、カスタム応答など）の使い分けはPower Automateで稟議フローは作れる？で整理しています。代理承認の設計は代理承認の設計を参照してください。

申請額と実額のずれ

出張固有の論点です。事前申請に書く運賃と宿泊費は見積であり、実際の金額は予約した瞬間に決まります。

精算フローで全件を再承認すると承認者の負荷が2倍になるので、許容範囲を決めて自動で通す設計にします。「申請額の±10%または5,000円以内なら上長承認をスキップ」といった条件を、精算フローの分岐に書きます。

範囲を決めずに運用を始めると、承認者が毎回判断することになり、結局は全件が形式承認になります。

Power Automateで組んでも残るもの

2フロー構成にして、データも整理して、それでも残る問題があります。承認リードタイムが、そのまま運賃になることです。

事前購入運賃には期限があります。申請から承認までに数日かかると、その間に期限が切れます。出張費の相場｜規程額と実勢価格の差で整理したとおり、羽田〜福岡は事前購入と直前手配で往復約14,000円の差が出ます。1泊2日の総額約5万円に対して2割超です。

これはフローの設計では解決しません。 承認アクションのリマインダーを設定しても、承認者が見るまでの時間は短縮されますが、承認が降りてから人が予約するという順序は変わらないためです。

つまり、費用の2割を決めている部分は手つかずで残ります。 内製で削減できるのは工数であって、運賃ではありません。ここを期待値として最初に持っておくと、稼働後に「思ったより安くならない」とならずに済みます。

よくある質問（FAQ）

本当に1本のフローでは組めませんか？

技術的には、承認後にフローを終了させて別フローを起動する形にすれば繋がります。ただしそれは実質的に2フロー構成です。1つのフロー定義の中で申請から精算まで待たせる作り方は、30日の上限があるため避けてください。

30日のタイムアウトが来たらどうなりますか？

フローがエラーで終了します。承認待ちの状態が消えるため、申請者から見ると「送ったのに何も返ってこない」状態になります。リストのステータスも中途半端なまま残るので、手で直すことになります。

Teamsの承認アプリではだめですか？

承認そのものは回せますが、明細を持てません。 出張申請は交通費の可変行があるため、リストと組み合わせる必要があります。Teams上での承認体験はMicrosoft 365の承認ワークフローを参照してください。

Dataverse for Teams なら無料で使えませんか？

Teams内で完結する範囲なら追加ライセンスなしで使えますが、Teamsの外から参照・連携する用途には制約があります。 経費精算システムや会計への連携を将来考えているなら、SharePointリストから始めるほうが移行の選択肢が残ります。

領収書の添付はどこに置くべきですか？

SharePointリストの添付列が素直です。ただし明細ごとに添付が必要なので、親ではなく子リスト側に持たせてください。親に全部ぶら下げると、どの領収書がどの明細のものか分からなくなります。

既存の経費精算システムがある場合は？

事前申請をMicrosoft 365、精算を既存システムに置く構成は成立します。ただし申請と精算の紐付けが手作業になる点に注意してください。承認した出張と精算された金額が対応しているかを誰も突合していない、という状態になりがちです。この論点はPower Automateで経費精算を自動化する方法と注意点で扱っています。

1Approvalでの実現方法

1Approvalは、いま作ったPower Automateの承認フローの上で、承認が降りた時点で手配まで完了させる仕組みです。本記事の設計論点のいくつかが不要になります。

手配フローが要らなくなる — 承認がそのまま手配の実行になるため、3フロー構成にする理由が消える
申請額と実額のずれが小さくなる — 承認から予約までの時間が無くなるため、事前購入運賃の期限切れが起きない。許容範囲を設定しておけば差し戻しなしで進められる
明細の入力が減る — 手配データがそのまま費用データになるため、交通費の子リストへの転記が発生しない
立替と証憑回収が発生しない — 費用は法人一括請求にまとまる

承認フローの設計はそのまま使えます。 Power Automateを作り直す必要はなく、承認の完了をトリガーにできます。

本記事の設計のうち「承認をどう回すか」は引き続き必要で、「承認のあとをどう回すか」が不要になる、という関係です。

まとめ

Microsoft 365で出張申請を組むとき、最初に効いてくるのはPower Automateのフロー実行期間30日という上限です。申請から精算までを1本に載せると、長期の出張や月締めの精算で落ちます。しかも落ちるのは本番が始まって1か月後です。

解は事前承認フローと精算フローを分ける2フロー構成。手配を代行するなら3フローです。

データはSharePointリストから始めてください。Dataverseは設計として自然ですが、E5を持っていても追加ライセンスが要ります。 交通費の明細は親子2リストで持ち、固定列で持たせないこと。

そして90日間実行されないフローは自動的に無効化されます。 出張が少ない部署の専用フローは、これで静かに止まります。分けすぎないこと、通知の宛先を個人にしないことが対策です。

最後に期待値です。内製で減るのは工数であって、運賃ではありません。 承認リードタイムが事前購入運賃の期限を超える構造は、フローの設計では変わりません。

主な参照先

※仕様・制限値・ライセンス条件は2026年9月時点で確認した公開情報です。変更される可能性があるため、実装前にMicrosoftの公式ドキュメントで最新の条件をご確認ください。

監修

伏見匡矩

株式会社エイチ代表取締役社長

株式会社エイチ代表取締役社長。出張手配・会場手配の実務を起点に、申請・承認から購買実行までを一体で扱う1Approvalを立ち上げ、事業責任者としてプロダクト設計に携わる。承認されたあとの購買・手配をどう自動化するかという観点から、Microsoft 365を基盤とした申請・承認の設計を扱っている。

経歴・運営者情報を見る