Teams承認の履歴・監査証跡はどこまで残せるか

Teamsの承認アプリは、日々の承認を回すぶんには軽快に動きます。問題が表面化するのは監査のタイミングです。「昨年度の購買申請を、申請者・承認者・金額つきで一覧にしてほしい」と求められたとき、どこから出せばよいのか。この記事では、Teams承認のデータがどこに残り、どこまで取り出せるのか、そして統制要件を満たすために何を補う必要があるのかを整理します。

この記事の要点

• Teams承認のデータは、Dataverse（申請本体）、Power Automateの実行履歴、Microsoft Purviewの監査ログという3か所に分かれて残る。
• 承認アプリのUIから追えるのは、自分が関わった申請の履歴のみ。全社横断の一覧機能は用意されていない。
• 3か所それぞれ保持期間と取得に必要な権限が異なるため、監査の要求に応えるには事前の設計が要る。
• 承認の記録だけでは統制は完結しない。発注・支払側の記録と突き合わせられる状態にしておく必要がある。

Teams承認のデータはどこに残るのか

Dataverse — 申請と承認の本体

承認アプリで作成した申請は、バックエンドのMicrosoft Dataverseに格納されます。申請のタイトル、内容、添付、承認者、承認・却下の結果と日時が、ここに記録されます。

このデータは承認アプリのUIからは「履歴」タブとして見えますが、表示されるのは自分が申請者または承認者として関わった申請だけです。情シスや監査部門が全社の申請を横断して検索する画面は、承認アプリには存在しません。Dataverseを直接参照するにはPower Platform管理センター側の権限が必要で、環境の構成によってはそもそも参照できないこともあります。

Power Automateの実行履歴 — 処理の経過

Power Automateからフロー経由で承認を出している場合、フローがいつ起動し、各アクションがいつ成功・失敗したかという経過が実行履歴に残ります。承認がいつ送信され、いつ応答があったかを時系列で追えるのはここです。

ただし実行履歴の保持期間には上限があり、無期限には残りません。監査で過去数年分を求められる可能性があるなら、必要な情報をフローの中で別途リストやデータベースに書き出しておく必要があります。

監査ログ — 誰が何を操作したか

Microsoft Purview（旧コンプライアンスセンター）の監査ログには、ユーザーの操作記録が残ります。承認アプリ固有の詳細な記録というより、Microsoft 365全体の操作ログの一部として記録されるものです。保持期間はライセンスの種類によって異なり、既定より長く保持するには上位のライセンスまたは追加の構成が必要です。

3か所の性格の違い

同じ「承認の記録」でも、この3か所は性格が違います。Dataverseは申請の内容、実行履歴は処理の経過、監査ログは人の操作を持っています。監査で求められる情報がどれに当たるかを最初に切り分けないと、探す場所を間違えます。

たとえば「この申請はいくらだったか」はDataverse、「承認依頼はいつ送られ、いつ応答されたか」は実行履歴、「誰がいつこの環境にアクセスしたか」は監査ログです。そして「承認された金額どおりに発注されたか」は、この3つのどこにもありません。

監査で求められることと、標準機能とのギャップ

求められるのは「網羅性」と「再現性」

監査対応で問われるのは、個別の申請を1件見せられるかではありません。指定された期間の対象取引が漏れなく抽出できること（網羅性）、そして同じ条件で何度抽出しても同じ結果になること（再現性）です。

承認アプリのUIから1件ずつ確認する方法では、この2つを満たせません。抽出漏れが起きていないことを証明できず、担当者によって結果が変わる余地も残ります。

承認の記録だけでは足りない

もうひとつのギャップが、承認の記録と実際の取引の突合です。承認記録が示すのは「買ってよいと判断した」という事実までで、実際にいくらで何を買ったかは購買サイト側の注文履歴に、支払の事実は会計システムに残ります。

この3つが別々のシステムに分かれていると、承認された内容と実際の発注が一致しているかを確認する作業が手作業になります。金額が承認額と異なっていた場合に、それが承認範囲内の変動なのか、承認を経ていない変更なのかを説明できる状態にしておく必要があります。

同じ構造の問題はkintoneでも起きます。標準の監査ログでどこまでカバーでき、どこから先を補う必要があるかはkintone監査ログの限界を内部統制でどう埋めるかで詳しく扱っています。

承認者の妥当性を示せるか

統制上もうひとつ問われるのが、承認者がその申請を承認する権限を持っていたかどうかです。承認アプリは指定された承認者に依頼を送りますが、その指定が社内規程に照らして正しかったかまでは保証しません。

承認ルートをフロー内にハードコードしている場合、当時のルート定義が残っていないため、後から妥当性を証明できません。承認者マスタをリストで管理し、その変更履歴が残る構成にしておくことが、統制上の実質的な要件になります。

代理承認とエスカレーションの扱い

見落とされやすいのが、代理承認とエスカレーションの記録です。「本来の承認者が不在だったため上位者が承認した」という経緯は、承認記録上は単に上位者が承認した事実としてしか残りません。

規程上それが認められた運用であることを示すには、代理・エスカレーションが発生した事実自体をログに残し、発生条件（何日応答がなかったか）もあわせて記録しておく必要があります。エスカレーションの設計についてはTeamsの承認通知が届かない・見落とす原因と対策で扱っています。

標準機能の範囲でできる補強

承認結果を独立した台帳に書き出す

もっとも現実的な補強は、Power Automateのフローの中で、承認結果をSharePointリストなどの台帳に書き出しておくことです。申請ID、申請者、申請日時、金額、承認者、承認日時、結果を1行として残せば、期間指定での抽出と集計ができるようになります。

台帳に持たせる列は、最低限として次の構成を推奨します。申請ID（一意キー）、申請日時、申請者、部門、金額、用途、発注先、適用した承認ルートのバージョン、承認者、承認日時、結果、そして代理・エスカレーションの有無。適用したルートのバージョンを持たせるのがポイントで、これがあると後から当時のルート定義と突き合わせられます。

台帳を用意する際は、書き込み後の編集を制限してください。台帳が自由に編集できる状態だと、「後から書き換えられた可能性を否定できない」という理由で証跡としての価値が下がります。この論点はスプレッドシートを台帳にする構成でも共通で、スプレッドシートの経費精算管理が破綻する理由とGoogle Workspaceで稟議・ワークフローを電子化する方法でも扱っています。

承認ルートの定義を外出しし、履歴を残す

承認者をフロー内に書かず、承認者マスタのリストから引く構成にします。リスト側でバージョン履歴を有効にしておけば、いつルートが変わったかが記録として残ります。これにより、過去の承認について当時のルートの妥当性を示せます。

保持期間を要件から逆算する

Power Automateの実行履歴と監査ログには、それぞれ保持期間の制約があります。自社が求められる保持年数（業種や上場準備の状況によって異なります）を先に確認し、その期間を満たせない部分については、前述の台帳への書き出しで補ってください。

抽出手順を文書化しておく

補強として意外に効くのが、抽出手順そのものを文書に残すことです。「どのリストの、どの列を、どの条件で絞ると、監査で求められる一覧になるか」を書いておけば、担当者が変わっても同じ結果を再現できます。前述の再現性は、仕組みだけでなく手順の明文化でも担保されます。

承認と実行を1本の記録にする

ここまでの補強は、分かれて残っているデータを後から束ねる作業です。より根本的なのは、承認と実行が同じ仕組みの中で起きるようにして、最初から1本の記録として残す構成にすることです。

承認した瞬間に発注が確定する形であれば、「誰が申請し、誰が承認し、いくらで何を発注し、いつ支払われたか」が分断なく1つの記録に収まります。承認額と発注額が一致することが仕組みで保証されるため、突合作業そのものが不要になります。

1Approval for Teamsは、Teamsのチャットを申請承認の入口としながら、承認と発注・決済を同じ流れの中で完結させます。申請から支払までの証跡は1本につながった状態で残るため、期間を指定した抽出がそのまま監査資料になります。購買側の設計についてはTeamsで購買申請から発注までを完結させる方法もあわせてご覧ください。

よくある質問（FAQ）

承認アプリの履歴は何年分残りますか？

Dataverseに格納された申請データ自体は、環境の設定とデータ保持ポリシーに従います。一方、Power Automateの実行履歴には保持期間の上限があり、長期の保存には向きません。監査要件が数年単位であれば、必要な項目を別途台帳に書き出しておく運用が必要です。

情シスが全社の承認履歴を一覧で見ることはできますか？

承認アプリのUIからはできません。Dataverseを直接参照するか、Power Automateのフローで承認結果を台帳に書き出しておく必要があります。

承認済みの申請内容を後から変更できますか？

承認アプリ上で承認済みの申請を書き換えることはできません。ただし、承認結果を書き出した先の台帳（SharePointリストなど）は、権限を持つユーザーが編集できます。証跡として扱うなら、書き込み後の編集を制限し、バージョン履歴を有効にしてください。

内部統制の観点で最低限そろえるべき記録は何ですか？

承認記録、発注記録、納品または役務提供の確認、請求・支払の記録の4点です。この4点が揃って初めて、取引の経緯を説明できる状態になります。承認記録だけでは不足します。

代理承認が行われたことは記録に残りますか？

標準では、上位者が承認した事実としてしか残らず、それが代理として行われたという文脈は記録されません。代理・エスカレーションの発生自体をフローの中でログに書き出しておく必要があります。

まとめ

Teamsの承認アプリは、承認を回す道具としては優れていますが、監査証跡を残す仕組みとしては設計されていません。データはDataverse・実行履歴・監査ログの3か所に分かれ、それぞれ保持期間と参照権限が異なります。

標準機能の範囲で補強するなら、承認結果を編集制限つきの台帳に書き出し、承認者マスタを外出しして変更履歴を残し、抽出手順を文書化すること。この3点でかなりの部分をカバーできます。そのうえで、承認と発注・支払の記録を突き合わせられる状態を作れるかが、統制の完成度を分けます。