【Power Platform × AI】SharePointリストと承認フローを自然言語でつないで、アプリを動かしてみた

こんにちは！DXソリューション営業本部の近藤です。

本記事は【Power Platform × AI】シリーズの第2回です。
第1回では、Claude Codeにcanvas-apps／power-automateプラグインを導入し、キャンバスアプリとPower Automateのフローを自然言語で作成しました。

ただし、第1回の時点でできたアプリのデータは、アプリを閉じると消えてしまうメモリ上のコレクションでした。
申請書アプリとして使うには、データを保存する場所と、承認して結果を通知する仕組みが必要です。

そこで今回は、SharePointリストを作成し、承認フローとキャンバスアプリをそこに接続して、申請から通知までが一気通貫で動く状態を目指しました。
結論から言うと全経路が動作しましたが、1か所だけClaude Code側から実行できない操作がありました。
その内容も含めて、実際の画面キャプチャとともにご紹介します。

今回のゴール：アプリ・フロー・データの3点をつなぐ

今回目指したのは、次の経路が実機で通しで動く状態です。

キャンバスアプリで申請
  → SharePointリストに登録
  → 承認フローが起動
  → 承認
  → リストの承認状態を更新
  → Teamsに結果を通知
  → アプリの一覧に反映

第1回で、キャンバスアプリとPower Automateのフローは自然言語で作成できることが分かっています。
残るのは、データの保存場所となるSharePointリストの作成と、3者の接続です。

SharePointリストを自然言語で作成する

執筆時点では、SharePoint向けのプラグイン（スキル）は用意されていませんでした。
ただし、Microsoft Graph APIやWork IQ（SharePoint）を使うなど、SharePointリストを作成する方法はいくつか考えられます。
今回はその一例として、Power AutomateのHTTP要求アクション（SharePointのREST APIを直接呼び出すアクション）を使い、フロー経由でリストを作成しました。

具体的には、リストを作成するフローそのものを次の内容で依頼しました。

SharePointのHTTP要求アクションを使って、経費申請用のリストを作成するフローを作ってください。
列は、件名・申請者・申請日・金額・用途・承認状態です。用途と承認状態は選択肢にしてください。

できあがったフローに対しては、実行前に4点だけ追加で指示しています。
リストを内部名ExpenseRequestで作成してから表示名を「経費申請」へ変更すること、備考にあたる複数行テキスト列を追加すること、削除できない既定のTitle列の表示名を「件名」に変えることです。
4点目として、検証中に再実行する前提があったため、同名のリストがあればスキップして正常終了する分岐も入れてもらいました。

実行結果

フローは約6秒で完了し、失敗したアクションはありませんでした。
各アクションのHTTPステータスがアクション単位で列挙され、スキップされたアクションについても「リストが未存在だったため作成ブランチが正しく走った」という説明が添えられていました。

作成された列は、内部名・表示名・型のすべてが指示どおりでした。
内部名はASCII、表示名は日本語という方式が機能し、リストのURLに日本語は入っていません。

実機で確認する

SharePointの画面を開くと、表示名「経費申請」のリストが作成され、既定ビューに7列が並んでいました。

入力フォームも日本語の表示名で自然に表示されます。
申請者はユーザーピッカー、申請日は日付ピッカー、備考は複数行入力になっており、用途の選択肢も指定した5件がそのまま反映されていました。

承認フローをSharePointリストに接続する

データの入れ物ができたので、第1回で作成した承認フローをこのリストに接続します。
投入したプロンプトは次の内容です。

承認フロー「経費申請の承認フロー(骨組み)」を改修してください。
トリガー: SharePoint「アイテムが作成されたとき」
処理:
1. 承認アクションに、件名/申請者/申請日/金額/用途/備考 を本文として渡す
2. 承認された場合 → ApprovalStatus を「承認済」に更新
3. 却下された場合 → ApprovalStatus を「却下」に更新
4. いずれの場合も、既存の Teams 通知に結果を含めて送信

トリガーが手動から「アイテムが作成されたとき」へ変更され、旧構成にあった入力5項目とプレースホルダーは削除されました。
トリガーはポーリング方式で、複数件が同時に登録された場合もアイテム1件ずつ独立して実行される設定になっています。

承認者の設定と分岐の構成

「経費申請」リストには承認者を保持する列がないため、トリガーから承認者を取得できません。
ここは自動では埋められないため、今回は固定アドレスを設定して先に進めました。

分岐は次の構成になっていました。
承認と却下のそれぞれで「結果ラベル」という変数に値を入れ、Teams通知は分岐の外に1つだけ置く形です。
承認・却下のどちらでも通知が1回だけ送信されるため、アクションの重複がありません。

承認フロー単体での通し確認

アプリをつなぐ前に、まずはSharePointリストから直接アイテムを登録して、承認までが通ることを確認しました。

リストにテスト用のアイテムを登録すると、約1分後にフローが起動し、承認センターとOutlookの両方に承認依頼が届きました（トリガーが起動するまでの時間は、ライセンスによって異なります）。
依頼の本文には、件名・申請者・申請日・金額・用途・備考の6項目と、SharePointアイテムへのリンクが含まれています。

承認を実行すると、リストの承認状態が「申請中」から「承認済」に更新されました。
同じタイミングでTeamsにも結果通知が届いています。

ここまでで、SharePointリストと承認フローの接続は問題なく動作することが確認できました。
残るはキャンバスアプリ側です。

キャンバスアプリをSharePointリストにつなぎ替える

第1回で作成したアプリは、メモリ上のコレクションを唯一のデータ源としています。
これをSharePointリストにつなぎ替えるには、アプリにデータソースを追加したうえで、コレクションを参照している数式をリスト参照に書き換える必要があります。
まずは現状の調査と改修方針の提示を依頼しました。

キャンバスアプリ「MCP検証_空アプリ」を改修してください。
現在メモリ上のコレクションを使っている箇所を、SharePointリストに
差し替えたいです。
まず現在のアプリの画面構成とデータソースの使われ方を調べて、
改修方針を提示してください。実装は私の確認後にお願いします。

どこを直す必要があるのか

調査の結果、外部接続は1つも存在せず、起動時の処理にハードコードされたコレクションが唯一のデータ源であることが分かりました。

続いて提示されたのが、SharePointリストと現在のアプリの差分です。
ここが改修の核心にあたります。

• 件名と備考は、アプリ側に入力欄そのものが存在しないため新規追加が必要
• 申請者は、アプリ側がテキストの自由入力なのに対し、SharePoint側はユーザー型のため書き込み方法が異なる
• 用途と承認状態は選択肢型のため、参照と書き込みで書式が変わる
• 承認状態は列名そのものも異なる

つまり、フィールド名・型・参照方法の3種類の変更が同時に必要で、単純な文字列置換では済まないということです。

データソースの追加だけは手作業だった

書き換えに入る前に、ひとつだけClaude Codeでは進められない操作がありました。
SharePointリストをデータソースとしてアプリに追加する操作には、MCP側に機能がありません。
この最初の1手だけは画面での手作業が必要で、今回の検証で唯一、自然言語では置き換えられなかった工程です。

そのため、追加手順が案内され、こちらがPower Apps Studioの画面で手作業を行う形になりました。
前提として、このアプリのPower Apps Studioセッションは開いたままにしておく必要があります。共同編集セッションが切れていると、追加してもMCP側から見えないためです。

案内どおりに操作すると、データパネルに「経費申請」が追加されました。

数式の書き換えはClaude Codeで完結した

データソースさえ追加してしまえば、ここから先の実装はClaude Code側で完結しました。
変更は3画面すべてとアプリ全体にわたり、コントロールの追加・削除と数式の修正がまとめて行われています。

つまずいた点：接続の同意が未了で画面が真っ白に

データソースを追加した直後、アプリの画面が真っ白になり、アプリチェッカーにエラーが14件表示されました。
内容はすべて「ネットワークからデータを取得...」というもので、数式の記述エラーではなく、SharePointからデータを取得できていない状態でした。

当初は接続アカウントの権限不足を疑いましたが、原因はもっと単純でした。
アプリを開き直した際に表示された接続の同意（consent）ダイアログを許可したところ、それだけで解消しました。
解消後はKPIも一覧も正しく描画され、残ったのは軽微な警告のみです。

アプリ経由での通し確認

最後に、アプリから申請して通知まで届くかを確認します。
アプリは公開せず、Power Apps Studioのプレビューで実行しました。
プレビューでもSharePointへの書き込みは実データとして行われます。

新規申請フォームの確認

新規申請の画面では、件名が先頭に「※必須」ラベル付きで配置され、未入力時のバリデーションが動作しました。
申請者は「※自動設定」と明記されたうえでログインユーザー名が入った読み取り専用、備考は末尾に「(任意)」表記の複数行入力です。
用途のラジオボタン5件も、SharePointの選択肢と一致していました。

申請から通知まで

アプリから申請を登録すると、レシートにIDと承認状態が表示されました。
このIDはSharePointが採番した実際のIDで、アプリ内で生成した値ではありません。

登録から約1分後に承認フローが起動し、承認依頼が着信しました。
本文には件名・申請者・申請日・金額・用途・備考の6項目が並び、アプリのフォームで入力した備考「キャンバスアプリから登録」もそのまま反映されています。
申請者には、アプリ側でログインユーザーを自動セットする設定にしたとおりの値が入っていました。

承認を実行すると、SharePointリストの承認状態が「申請中」から「承認済」に更新され、続いてTeamsのFlow botとの1:1チャットに結果通知が届きました。
通知には承認結果と応答者が含まれており、承認者を差し替えても本文の組み立てを直す必要はありませんでした。

アプリの一覧を再読込すると、SharePointリストから直接登録した1件とあわせて2件・合計4,700円・承認済2件として反映されました。
状態フィルターの件数（申請中0／承認済2／却下0）も一致しており、KPIカードの数値がリストの実データから計算されていることを確認できました。
承認済みのアイテムは、編集・削除ボタンがグレーアウトしていました。

あわせて、フローの実行履歴も確認しました。
承認結果の判定では承認側の分岐のみが実行され、却下側はスキップされています。
Teams通知は分岐の外で1回だけ実行されており、設計どおりの挙動でした。
SharePointから直接登録した1件目とアプリから登録した2件目の2回とも、エラーなく完了しています。

よくある質問

Q. SharePointリストもClaude Codeで作成できますか？

はい、作成できました。
執筆時点ではSharePoint向けのプラグインは用意されていませんが、今回は一例として、Power AutomateのHTTP要求アクション（SharePointのREST API）を呼び出すフローを自然言語で作成し、列の型・選択肢・表示名まで指定どおりのリストを作成しています。
Microsoft Graph APIやWork IQ（SharePoint）を使う方法も考えられますが、今回は検証していません。

Q. キャンバスアプリへのデータソース追加もClaude Codeに任せられますか？

いいえ、この操作にはMCP側の機能がなく、Power Apps Studioの画面での手作業が必要でした。
ただし、追加後の数式修正・コントロール追加・画面整理はすべてClaude Code側で完結しています。
なお、データソースを追加する際はアプリのPower Apps Studioセッションを開いたままにしておく必要があります。
今回はSharePointリストで検証したもので、Dataverseなど他のデータソースでの動作は未検証です。

Q. データソースを追加したらアプリの画面が真っ白になりました。

今回の検証では、接続の同意（consent）が未了だったことが原因でした。
アプリを開き直した際に表示される同意ダイアログを許可したところ解消しています。
数式のエラーではなくランタイムのエラーが並んでいる場合は、権限不足を疑う前に接続の同意状態をご確認ください。

Q. 申請書アプリを作るなら、SharePointとDataverseのどちらがよいですか？

用途とライセンスによります。
SharePointリストとPower Automateの組み合わせであれば、Microsoft 365付帯のライセンスの範囲で収まります。
一方、Dataverseを使う場合は利用者全員にPower Apps Premiumが必要になる点にご注意ください。

まとめ：全経路は動くが、役割分担は必要

2回にわたる検証の結論は、次の3つです。

1. アプリ・フロー・データの3点は自然言語で接続できる：キャンバスアプリで申請し、SharePointリストに登録され、承認フローが起動し、承認結果がリストに反映され、Teamsに通知され、アプリの一覧に戻ってくるところまで、すべて実機で動作しました。
2. SharePoint向けのプラグインがなくても対応できる：今回は一例として、Power AutomateのHTTP要求アクション経由でリスト作成まで実施できました。専用のプラグインが用意されていない領域も、既存の仕組みを組み合わせることで対応できます。
3. ただし、Claude Code側から実行できない操作も存在する：データソースの追加はMCPに機能がなく、Power Apps Studioでの手作業が必要でした。「どこまで任せられて、どこから人が操作するのか」を把握しておくことが、実務では重要になります。

第1回と今回をあわせると、Claude Codeとプラグイン経由であればアプリもフローもデータ連携も自然言語で開発できることが確認できました。
一方で、導入にはコマンド操作が必要で、初心者向けとは言えません。
開発者やエンジニアが使うのであれば十分実用的で、提案やPoCのスピード向上が見込めるというのが、2回を通じての率直な感想です。

まずは検証用の環境で、SharePointリストと承認フローの接続から試してみてはいかがでしょうか。

また、QESでは、今回のようにアプリ・フロー・データを連携させた仕組みづくりから、業務で使えるAIエージェントの開発までをご支援しています。
セキュリティ・ガバナンス設計からPoC・本番構築、運用と継続改善まで一貫して対応していますので、以下のリンクからサービスの詳細をご確認ください。

※このブログで参照されている、Microsoft、Power Apps、Power Platform、Power Automate、SharePoint、Microsoft Teams、Outlook、Microsoft 365、Dataverseは、米国およびその他の国におけるMicrosoft Corporationの商標または登録商標です。
※Claude、Claude Codeは、Anthropic PBCの商標または登録商標です。