はじめに
2026年5月に、Power Platformをフル活用して意思決定支援システム DecisionFlow を作った記事を書きました。
その後、2026年8月の夏休みに短期集中で、DecisionFlowを実運用に近づける更新を行いました。利用者が迷わず、少ない手数で判断を進められるよう、使い勝手とUXをもっと良くしたかったからです。
開発面でも、5月のMVP時点にはなかった、接続をCLIで探索・作成・アプリへ配線するCode Apps CLIの機能が、6月のプレビューを経て7月にGAとなったことが追い風でした。DataverseやPower Automateフローをアプリへ接続して型付きクライアントを生成し、今回も関連資料の説明生成フローを追加しています。Copilot Studioコネクタの生成クライアントを使った画面内アシスタントも、その延長にあります。
まずは動画で
申請の提出から、AI支援を使った判断までを紹介した動画を公開しています。
DecisionFlowでできること
DecisionFlowは、AIに判断を丸投げするツールではありません。判断者が必要な情報に短く到達し、根拠を残したまま人が決めるための仕組みです。
| 目玉機能 | できること | うれしい場面 |
|---|---|---|
| AI判断支援 | 申請本文・会話・関連資料・カテゴリ別ルール・過去案件をまとめ、概要、推奨判断、リスク、判断コメントのたたき台を生成する | 判断前に「何を確認すべきか」を短時間で把握したい |
| 画面内アシスタント | いま開いている申請の文脈を渡したまま、Copilot Studioエージェントへ質問できる | 画面を離れずに、背景や関連情報を確認したい |
| 関連資料の説明生成 | SharePoint / OneDriveの資料を、その資料を読める本人の資格でだけ読み、説明欄へ追記する | 資料を何本も開く前に、内容と論点をつかみたい |
| 判断キューの読み切り | 前後移動、キーボード操作、判断直後に次の申請へ進む導線で、キューを探し直す手間を減らす | 提出済みの申請を連続して確認したい |
| 経緯と権限の管理 | 会話・関係者・判断履歴を案件単位で追跡し、ロールと行単位共有で閲覧範囲を分ける | 「誰が、何を根拠に、いつ決めたか」を説明したい |
試してみるには
ソースコードとセットアップ手順はGitHubで公開しています。既存業務と分けたPower Platformの開発・検証環境で、まずはサンプル申請から試すのがおすすめです。
DecisionFlowが解きたい問題は変わらない
意思決定が滞る理由は、意外と「判断そのもの」だけではありません。
| 困りごと | 起きること |
|---|---|
| 情報が散らばる | メール、チャット、資料、過去の判断を行き来することになる |
| 判断キューが長い | 次に何を読むか探すだけで集中が切れる |
| 根拠が残らない | なぜその結論になったかを後から説明できない |
| 権限が曖昧 | 関係者に見せたい情報と、見せてはいけない情報が混ざる |
DecisionFlowは、申請、会話、関連資料、判断、AIによる補助をDataverseに集約し、Power Apps Code Appsで操作する仕組みです。Power Automateが通知・共有・AI実行を担い、Copilot Studioは画面内アシスタントとTeams / Microsoft 365 Copilotからの照会導線になります。
MVPの後で大きく変わったのは、画面の派手さよりも、判断を進める操作を短くし、境界を壊さないための設計でした。
1. 判断を急がせず、書きかけを守る
判断コメントは、書き始めてから画面を離れることがあります。コメント下書きはブラウザのローカルストレージへ、申請ごと・利用者ごとに保存するようにしました。
ただし、保存するのはコメント本文だけです。承認・却下・差し戻しという判断選択肢は復元しません。以前選んだ結論が残ったまま確定されるほうが危険だからです。
| 設計 | 理由 |
|---|---|
| 本文だけを保存 | 文章を書き直す負担は大きいが、判断選択は読み直して選び直すべき |
| 30日で期限切れ | 古い下書きを「現在の考え」として確定しない |
| 保存状態と時刻を表示 | 利用者に見えない場所で状態を変えない |
さらに、カテゴリごとの申請テンプレートを本文末尾へ安全に挿入できるようにし、判断記録を申請内容・AI推奨・経緯とともに印刷できるようにしました。ここでも「既存の入力を上書きしない」「画面に出ていない事実を印刷しない」を守っています。
2. AIに資料を読ませる前に、誰の資格で読むかを決める
今回もっとも慎重に設計したのが、関連資料の説明を自動生成する機能です。
利用者がSharePoint / OneDrive上の資料URLを貼ると、AI Builderがテキストを抽出し、関連資料の説明欄へ追記します。判断者は資料を開く前に「何が書かれているか」をつかめます。
しかし、ここには重大な落とし穴があります。フローを管理者の接続で動かすと、利用者が本来読めない資料まで読めてしまうからです。
そこで、SharePoint接続だけを invoker（呼び出した本人） として実行する構成にしました。
| 許可すること | 許可しないこと |
|---|---|
| 本人がすでに開ける資料の要約 | 管理者の資格での代理閲覧 |
| 生成文を資料の説明欄へ追記 | 申請本文や判断結果の書き換え |
| 共有リンクの解析 | URLを貼っただけで新しい権限を付与すること |
未受諾の共有リンクを「読めるようにする」処理も、あえて行っていません。失敗ではなく、権限がまだ無いという正しい状態です。
この挙動は設定ファイルだけで終わらせず、権限の薄い利用者で実機確認しました。本人の資格で読める資料は説明を生成し、管理者のOneDriveにある読めない資料は403として拒否されることを確認しています。
3. ロールと共有を二層に分ける
企業で使う意思決定システムでは、「誰が読めるか」と同じくらい「誰が変更できるか」「権限が外れた瞬間に本当に見えなくなるか」が重要です。DecisionFlowでは、最小権限を基本に、職位による共通権限と案件ごとの例外共有を分けています。
DecisionFlowのアクセス制御は、Dataverseのセキュリティロールと行単位共有（Share API）を組み合わせる二層構造です。
職位ごとの権限は、Dataverseロールで固定する
| ロール | 主な対象 | 主な権限 | ガバナンス上の意味 |
|---|---|---|---|
ds_Applicant |
申請者 | 自分の申請の作成・閲覧・下書き編集、申請に紐づく会話の作成 | 他者の案件や判断キューを既定では見せない |
ds_Decider |
M365グループで管理する判断者 | 全申請・会話・判断結果の閲覧、自分が行う判断の作成・更新 | 判断に必要な全体像は読めるが、運用設定まで変更できない |
ds_Admin |
限定した管理者 | 業務データとマスタの組織レベル管理 | 例外対応・設定変更を担い、通常業務のロールと分ける |
このような細やかなアクセス制御を、アプリケーション個別の実装に閉じず、Power Platformのロール・チーム・監査の仕組みとして運用できることも、DecisionFlowをPower Platformへデプロイする大きなメリットです。誰がどの案件を読めるか、誰が判断を確定できるか、誰が設定を変えられるかを業務ロールに対応させ、組織の運用に合わせて見直せます。
判断者ロールは、個人へ直接ばらまかず、DecisionFlow-Deciders というM365グループとDataverseのグループチームを紐付けて付与します。異動・兼務・退任があっても、管理者はグループのメンバーシップを更新すればよく、判断者権限の棚卸し先を1か所に集約できます。
ロール変更、環境設定、Solutionのimport / publishは、日常の申請操作とは別の管理操作です。対象と影響を確認したうえで、管理者が明示的に扱う前提にしています。
関係者への共有は、案件単位で追加・解除する
申請者や判断者という職位だけでは、個別案件にレビュー担当や協力者を加えたい場面を表せません。そこで関係者として追加された利用者だけに、Share APIで対象申請の閲覧権を付与します。
- 共有対象は申請と、その既存の会話・関係者・判断・関連資料
- 判断が後から作成された場合も、申請者と関係者にその判断結果だけを明示共有する
- メンション通知だけでは権限を付与しない。通知を受け取っただけで案件が見える状態を避ける
- 関係者を外すときは、共有解除が成功してから参加レコードを削除する
最後の順序が重要です。先に参加レコードを消して共有解除に失敗すると、「画面上は外れたのに、資料はまだ読める」という監査上もっとも困る不整合が残ります。DecisionFlowでは、解除に失敗した場合は参加レコードを残し、アクセス権が消えたことを確認できるまで処理を完了させません。
Dataverseの権限と、資料の権限は混同しない
Dataverseロールが守るのはDataverse内のデータです。SharePoint / OneDriveの資料そのものには、その権限は及びません。そのため資料の説明生成では、管理者の接続ではなく、呼び出した本人のSharePoint資格情報でファイルを読ませます。
これは「申請を読める人なら、貼られた資料も必ず読める」とは限らないからです。本人が元の資料を開けない場合は、説明生成も拒否されます。共有リンクを貼っただけで権限を作ることもありません。
AIの提案と、データを書き換える権限を分ける
Copilot Studioは申請の要約や判断コメントのドラフト作成を支援できますが、会話文やモデルの推論から実行者を推測して書き込む経路は置きません。書込みフローへ渡す実行者の識別子は、認証済みユーザー情報だけを使います。
さらに、判断の確定では申請が提出済みであること、実行者がその案件の判断者であること、理由があることなどを確認します。関係者の追加・削除、マスタ変更、ロール変更、環境設定といったアクセス制御に直結する操作は、エージェントの書込み対象から外しています。
AIは判断材料を整理する。誰が閲覧・変更できるかは、Dataverse、SharePoint、認証済みユーザー情報というシステム側の境界で決める。この責務分離が、AIを業務で使うためのガバナンスだと考えています。
4. テストが緑でも、実機で初めて見つかることがある
この期間で一番学んだのはここです。純関数のテストを増やし、TypeScriptの型チェック、ESLint、Vitestを通しても、画面の配線や権限の組み合わせまでは保証できません。
2026年8月時点で、ローカルでは21ファイル・324件のテストを通しています。それでも実機確認では、次のような問題が見つかりました。
- 判断タブを開くと、キューの前後移動が消える
- 管理者では再現しない403が、判断者ロールでは起きる
- 共有解除や通知のように、書き込みが別の検証データを変えてしまう
- トーストが3秒で消え、観測タイミング次第で「出ていない」と誤認する
そのため、複数利用者を置いた検証環境へソリューションを移送し、管理者ではなく申請者・判断者の薄いロールで確認する運用に切り替えました。
「コードを読んで確認した」と「実際にその利用者で動いた」は、別の成果です。
5. ローコードを、再現できる成果物として残す
Power Platformは画面から素早く作れる反面、設定が個人の環境に閉じると引き継げません。DecisionFlowでは、テーブル定義、フロー定義、デプロイ用Pythonスクリプト、Copilot StudioのYAML、セットアップ手順をGitで管理しています。
ソリューションを別テナントへ移送する検証も行いました。移せるものと、移送先でやり直すべきものを分けて記録しています。
| そのまま移送しやすいもの | 移送先で設定が必要なもの |
|---|---|
| テーブル・列・リレーション、ロール定義、Code Apps、フロー | 接続参照の実体、ロールの利用者への割り当て、グループチーム、利用者ごとのSharePoint接続 |
AI Builderプロンプト、Power Automate接続、Copilot Studioの公開状態のように、UI操作が必要な部分もあります。だからこそ「手順書に書いてある」だけで終わらせず、実環境と照合し、差分を更新するところまでを開発に含めています。
6. AIファースト開発を、再現できる仕組みにする
DecisionFlowの開発でAIを使うとき、目指したのは「AIに丸投げして速く作ること」ではありません。AIが力を発揮できるように、標準 → 実装 → 検証 → 学びの再利用という循環を作ることでした。
この章の土台になる考え方は、先に書いた次の2記事に詳しくまとめています。
標準は「全部入りfork」ではなく、独立したoverlayにする
ベースには、Geek氏のCodeAppsDevelopmentStandardとMicrosoft公式の各種Skillsがあります。ただし、それらをコピーして抱え込むのではなく、PPDevStandard を独立したoverlayとして育てています。
PPDevStandardが担うのは、上流の製品知識を複製することではありません。複数のAIクライアントでも同じ開発体験を再現するための、次のような土台です。
- 利用する機能・プラグインの台帳と、クライアントごとの対応表
- 秘密情報を含まないMCP設定テンプレート
- 設計・承認・実装・検証の順序を守る安全ルール
- 環境準備を確認する
doctorと、最小の接続・機能確認を行うcanary
これにより、AIに渡す前提が毎回ぶれにくくなります。AIの出力を採用するかどうかは、標準と検証の結果で判断し、正本はGit管理されたスクリプト、YAML、ソリューション成果物へ戻します。
標準を使う側で終わらず、実装中に見つけた課題は上流の CodeAppsDevelopmentStandard にIssueとして還元しました。作者から貢献への反応をもらえたことも励みになりました。
自分の改善が上流へ戻り、次の利用者の開発を少しでも楽にできる。この循環も、AIファースト開発を個人の工夫で終わらせないために大切だと感じています。
つまずきは、次のAI支援で使える形にする
開発中の発見は、会話ログに埋もれると次回のAI支援に渡せません。そこで個人のVaultには、プロジェクト固有の経緯と、別の案件にも使える「つまずき」を分けて蓄積しています。
DecisionFlowでは、特に次の3件が開発方法を変えました。
| 発見 | 次に活かしたルール |
|---|---|
| AI判断が人の過去判断ではなく、AI自身の推奨を参照していた。テストもその誤りを固定していた | テストの期待値だけで安心せず、実データと照合して「何を根拠にしているか」を確認する |
| Code Appsからフローを呼ぶバインディングを消すと、pushは通っても「AI判断更新」が壊れる | エラー回避のために環境設定を削らず、設定が担う実行時の役割を先に確かめる |
| エージェントの書込みで、会話文やモデルの推論から実行者を組み立てると、なりすまし経路になる | 書込みの実行者は、認証済みユーザー情報からだけ渡す |
ここで重要なのは、記録を増やすこと自体ではありません。プロジェクトにしか当てはまらない事実はプロジェクトへ戻し、横展開できる失敗と対策だけを標準へ戻す。この分け方があると、AIは毎回ゼロから学び直すのではなく、過去の失敗を避けながら次の実装を進められます。
これから
DecisionFlowは完成品というより、意思決定の摩擦を見つけては小さく減らしていくプロジェクトです。
- 読む量が増えたとき、本当に必要になった改善だけを追加する
- 複数の判断者が実データを積み上げた段階で、負荷の見せ方を検討する
- 下書き・公開版・別テナントの差を、より再現可能な形で管理する
まずは「便利そうだから足す」のではなく、どの利用者がどの場面で困ったかを観測する。その上で、権限や操作の境界を壊さずに改善する。この積み重ねが、AIを業務の判断に近づけるための現実的な道筋だと感じています。
おわりに
2日で形にしたMVPを土台に、2026年8月の夏休みで短期集中のアップデートを行いました。判断キューを読み切りやすくし、書きかけを守り、資料とAIを必要な場所で使えるようにしたことで、利用者が少ない手数で判断に進める形へ近づけられたと思います。
公式CLIやSDKの進化を取り込みながら、アプリとフロー、エージェントをつなげられたことも今回の収穫でした。ローコードでも、画面の使い勝手を磨き、必要な接続を型で扱い、実機で確かめるところまでを短い期間で回せます。
DecisionFlowが目指すのは、AIに判断を任せることではありません。情報を集め、迷いどころを見えるようにして、人が納得して判断できる流れを作ることです。次も「便利そうだから」ではなく、利用者が実際に困った場面から改善を重ねていきます。
ソースコードとセットアップ手順はGitHubで公開しています。Power Platformで「判断待ち」を減らしたい方の参考になればうれしいです。