同意（Consent）のChange管理を「チケット化」する
- 山崎行政書士事務所
- 3月28日
- 読了時間: 9分
SharePoint＋Power Automate＋Teams承認で、監査に出せる“証跡パック”を自動生成する設計（台帳と棚卸しまで）
この記事の狙い：Microsoft Entra の OAuth同意（アプリ同意・権限付与） を、「やった」ではなく「提出できる」 形に落とし込み、申請→承認→証跡保全→台帳更新→定期棚卸し を“回る仕組み”として実装すること。
山崎行政書士事務所のクラウド法務でよく扱う「ログがあるのに説明できない」問題は、ログ収集量の不足というより、提出できる形・保全できる形・主語が割れない形に整っていないことが原因になりがちです。同意（Consent）はその典型で、いちばん静かに権限が増える入口になりやすいので、説明可能性（証跡）を前提に設計すべき領域です。
1. 情シスが詰まる“Consent変更”の本質：権限より「説明責任」
現場の実態はだいたいこうです。
プロジェクトが急ぎで、アプリ連携の同意が「とりあえず」付与される
しばらくすると、誰も覚えていない（担当者異動・委託先変更）
監査や取引先チェックで
「このアプリは誰が、いつ、何の権限を、なぜ付けた？」
と聞かれて詰まる
ログはある。でも提出物（台帳・承認・証跡）がない
解決策は「同意を止める」ではなく、同意を“変更管理の対象”として扱うことです。つまり、同意を (1)申請の型、(2)承認の型、(3)証跡の束ね、(4)棚卸しの型 に変換する。
2. 今回つくるもの（最小で強い“提出物”セット）
以下の4点が揃うと、監査・取引先照会で“強い組織”になります。
Consent Change Request（申請チケット）
Teams承認ログ（承認の証跡）
Evidence Pack（証跡パック：フォルダに束ねる）
Consent Registry（生台帳）＋棚卸し記録
そしてこれらを、M365標準の部品で“回す”構成がこちらです。
SharePoint（または Microsoft Lists）：申請・台帳のデータ保管（単一の真実）
Teams 承認（Approvals）：承認の入口（現場が使えるUI）
Power Automate：申請→承認→証跡格納→台帳更新→棚卸しの自動化
Microsoft Purview（保持ラベル）：証跡パックの保全（保持/削除/分類）
Power Platform DLP：フローでの“データ越境”を防ぐ統制
補足：Teamsの承認は “Power Automate基盤で直接トリガーされる（フロー不要の承認もある）” 一方で、前後の自動処理（証跡生成・台帳更新）までやるなら Power Automate で設計します。
3. 「承認データはどこに残る？」を先に押さえる（設計で事故を避ける）
これ、地味に重要です。
Teams承認（テンプレート等）では、承認データが Microsoft Dataverse に保存され、承認要求の応答は Forms に保存される旨が明記されています。
Power Automate の承認フローを使う場合も、承認フローは Dataverse に保存され、環境によっては初回のプロビジョニングに環境管理者権限が必要になることがあります。
つまり、「SharePointに全部残る」前提で作ると、監査でズレます。今回の設計では、SharePointを“台帳の真実”にしつつ、Dataverse（承認ログ）へも依存する前提でガバナンス（権限・監査・保持）を張ります。
4. 全体アーキテクチャ（分離が命：承認と実施を同一人物にしない）
文章で図解するとこうです。
[申請者] → (SharePoint List: ConsentChangeRequests) ↓（Power Automate） Evidenceフォルダ自動作成 + OnePager(PDF)生成 ↓ Teams Approvals（多段階承認） ↓ OK/NG OK → [IAM管理者]がEntraで同意を実施（PIM/最小権限） ↓ Evidence Packへ証跡格納（スクショ/エクスポート/ログ） ↓（Power Automate） SharePoint List: ConsentRegistry（生台帳）更新 ↓ 定期棚卸し（Teamsでレビュー要求→記録）なぜ「承認」と「実施」を分けるのか
不正同意（illicit consent grants）の対応ガイダンスでも、最小特権ロールの使用が推奨され、グローバル管理者は緊急時に限定すべきとされています。“承認した人がそのまま実施できる”構造は、統制上弱くなりがちです。
5. SharePoint（Lists）側の設計：列（フィールド）で勝負が決まる
ここを雑にすると、運用が回りません。（今回添付したブループリントExcelの 01_SharePoint_Schema にそのまま書いてあります）
5.1 申請リスト（ConsentChangeRequests）の必須列（最低限）
情シスに刺さるのは「いつでも撤回できるか」「責任が割れてないか」です。
RequestID（採番キー）
業務オーナー / 技術オーナー / セキュリティオーナー（主語を割らない）
AppDisplayName / AppId / （可能なら）ServicePrincipalObjectId
権限モード（Delegated / Application）
RequestedPermissions（権限の列挙）
権限分類（低/中/高）
取扱データ区分（個人情報/機密など）
BusinessJustification（Why）
RollbackPlan（取り消し手順・影響範囲）
期限（ExpiryDate：PoCは必須推奨）
EvidencePackUrl（証跡パックへのリンク）
5.2 台帳リスト（ConsentRegistry）の必須列
台帳は「現状」と「棚卸し」が命です。
RegistryId（不変キー）
RequestID（申請との紐付け）
GrantedDate / GrantedBy
CurrentStatus（Active/Expired/Revoked）
LastReviewDate / NextReviewDate
6. Teams 承認（Approvals）を“現場UI”として使うコツ
Teams の承認アプリは、承認の作成・管理・共有ができ、Power Automate で作成した承認もハブに表示されます。現場が「メール探し」から解放されるのが最大のメリットです。
また、未応答者へのフォローアップ通知も可能で、承認が滞った時の“追い回し”が標準機能としてあります。
だから、承認の入口はTeamsに寄せる。一方で、承認の判断材料（OnePager）と証跡保全（Evidence Pack）はSharePointへ寄せる。この分担が一番回ります。
7. Power Automate のフロー設計（4本で完成）
SharePoint コネクタには「アイテム作成時」「作成または変更時」などのトリガーがあり、申請→承認→更新の基盤になります。
Flow A：申請受付 → Evidenceフォルダ作成 → 承認開始
トリガー：SharePoint「アイテムが作成されたとき」
処理（実装の骨格）
RequestID採番（例：CCR-YYYY-連番）
Evidence Pack フォルダ作成（SharePointライブラリ）
OnePager（審査紙）をテンプレから生成してPDF化（Wordテンプレ運用が定番）
Teams承認を開始（多段階）
ステータスを In Review に更新
※「承認を開始」には Power Automate の承認アクションを使います。アクション差異（Start and wait / Create / Wait）を理解して選ぶのが安全です。
Flow B：承認結果 → 実施タスク化（情シス運用に落とす）
承認が通っても、Admin Consentは“実施者”が別にいることが多い。
Approved の場合：IAM管理者へTeams通知＋実施期限＋ロールバック手順を再提示
Rejected の場合：却下理由を残し、申請者へ返却
可能なら：Planner / チケット（Jira/Azure DevOps等）へ起票（※コネクタは組織のDLP設計に合わせる）
Flow C：実施完了 → 台帳（ConsentRegistry）へ反映
現場あるある：承認ログはあるが、台帳更新が抜ける。ここを自動化して“提出物”に固定します。
実施者が申請リストのステータスを Implemented に変更
Flowが台帳に Upsert（なければ新規、あれば更新）
Evidence Pack の必須証跡（スクショ/エクスポート/ログ）が揃っているかチェック
NextReviewDate を計算（権限分類「高」は短め等）
Flow D：定期棚卸し（レビュー要求 → 記録 → エスカレーション）
台帳の NextReviewDate を見て、期限到来分だけ回す。
Recurrence（週次/隔週/月次）
NextReviewDate <= 今日 の台帳を抽出
オーナーへ Teams でレビュー要求（承認として回収すると記録が残りやすい）
未応答はフォローアップ→SLA超過で部門長/セキュリティへエスカレーション
8. Entra側の統制ポイント（“同意を許す/許さない”の入口を固定する）
8.1 ユーザー同意を制御する
Entra では、ユーザーが同意できる範囲を構成して、リスクを軽減する考え方が示されています。「何でもユーザー同意OK」にしない。
8.2 アプリ同意ポリシー（App consent policies）
同意できる条件をポリシーで管理し、Graph/Graph PowerShell で制御できることが説明されています。
8.3 管理者の同意ワークフロー（Admin consent workflow）
ユーザーが自分で同意できない場合に、管理者承認を要求できる仕組みが提供されています。
実務の使い分け： Entraの管理者同意ワークフロー＝技術的な入口（同意の要求） Teams承認＋SharePoint台帳＝組織の提出物（説明責任） どちらか一方ではなく、目的が違うので“併用”が強いです。
9. 監査証跡のコア：Evidence Pack を「フォルダ設計」で勝つ
Evidence Pack は、「何を保存するか」より “どこに、どのIDで、同じ形で置くか” が9割です。
推奨フォルダ構成（例：Evidence/CCR-2026-0001/）
01_Approval/（承認ログ、チケット履歴、却下理由）
02_OnePager/（PDF）
03_Settings/（Entra設定スクショ、権限一覧エクスポート）
04_Logs/（アクティビティログ抽出）
05_Review/（棚卸し記録）
9.1 アプリ権限のアクティビティログを「台帳更新の根拠」にする
Entra には、アプリに付与/取り消しされているアクセス許可のアクティビティログを確認する手順があります。ここを定期的に見て、「台帳と現実がズレていない」ことを担保します。
9.2 不正同意（illicit consent）を前提に、週次レビューを回す
不正な同意付与の検出・修復では、監査ログの反映遅延が最大24時間になり得る点や、最小特権ロール推奨など注意点が明記されています。“週次で見る”運用を作っておくと、事故対応が「場当たり」から「Runbook」になります。
10. 証跡の“保全”まで設計する：Purview 保持ラベル × DLP
10.1 保持ラベル（Retention labels）
保持ラベルを発行して適用する手順が整理されています。また保持ラベルは「保持/削除」だけでなく、アクションを適用せず分類にだけ使う運用も可能です。
実務のおすすめ：Evidence Pack ライブラリには「監査証跡用ラベル」を付け、“削除できない/いつまで残す”を制度化しておく。
10.2 DLP（Power Platform / Purview）
Power Platform のデータ ポリシー（DLP）は、コネクタの扱い（同じデータをどこへ流せるか）を制御する仕組みです。さらに、保持ラベルをDLPポリシー条件として使える旨も示されています。
つまり：“証跡フォルダに保持ラベルが付いているものは外部共有させない”のような設計が可能になります（要件とライセンス前提で要検討）。
11. さらに上級：Defender for Cloud Apps で OAuthアプリを“見える化→制御”
同意の棚卸しは、どうしても「台帳の自己申告」になりがちです。Defender for Cloud Apps では、OAuth アプリを制御・許可・禁止する考え方が整理されており、OAuthアプリの可視化とガバナンスに使えます。
“申請を通ったものだけが存在する”状態に近づけるなら、こうした可視化・制御との組み合わせが効きます。
12. 付録：今回の提出物テンプレ（Excel）について
上のダウンロードファイル Consent_Change_Automation_Blueprint.xlsx は、以下を“提出できる形”で整理したものです。
SharePointリスト/ライブラリの列設計（01_SharePoint_Schema）
Power Automate フロー仕様（02_Flow_Specs）
RACI（03_RACI）
保持ラベル・DLPの観点（04_Retention_DLP）
承認マトリクス（05_Approval_Matrix）
このまま社内稟議・設計レビュー・監査資料のたたき台に使える形にしてあります。
13. 行政書士として支援できる範囲（非弁の範囲で）
本稿は、技術と運用の設計を中心に書いていますが、実務で一番効くのは「提出物に落ちる文書」です。山崎行政書士事務所では、Azure/M365/Entra運用を前提に、ログ・証跡を「見える」から「提出できる」「保全できる」形へ整える支援を掲げています。
台帳様式、運用手順、RACI、監査提出向けの説明文
委託・再委託・保全協力などの“提出できる条件”の整理（SOW/運用合意の作り方）
不正同意が出た場合の runbook（止血→追跡→報告）を「第三者に説明できる形」に整備
※個別案件の法的判断（権利義務の確定、紛争性の判断など）が必要な場合は、弁護士等の専門家へご相談ください。
免責
本記事は一般的な情報提供を目的としており、特定の事案に対する法的助言・代理・交渉等を行うものではありません。
参考リンク
■ Teams 承認（Approvals）
■ Power Automate（承認・SharePoint）
■ Power Platform DLP
■ Microsoft Purview（保持ラベル）
■ Microsoft Entra（同意・ワークフロー・ログ）
■ 不正同意（illicit consent）
■ Defender for Cloud Apps（OAuthアプリ）
■ 山崎行政書士事務所（関連）
コメント