ラベルデバッグで原因が掴めないとき、次に使うのが監視（モニター）機能です。データソースへのリクエストとレスポンスをリアルタイムで確認できるので、接続エラーやPatchの失敗原因を素早く特定できます。
この記事はエラー・デバッグクラスターのサテライト記事です。ラベルを使った基本的なデバッグ手法はPower Apps 式が動かないときの調べ方で解説しています。
監視（モニター）機能とは何か
監視（モニター）はPower Apps Studioに内蔵されたデバッグツールです。アプリが動いている間、データソースへのHTTPリクエストとレスポンスをリアルタイムでログに記録し続けます。どのコントロールがどのデータを取りに行ったか、Patchがどんなデータを送ったか、エラーが返ってきたときのステータスコードとメッセージ、これらすべてを一覧で確認できます。
Webブラウザの開発者ツール（DevTools）のネットワークタブに近いものだと思ってもらうと分かりやすいです。ただし監視（モニター）はPower Apps専用なので、SharePointやDataverseへのリクエストが見やすい形で整理されて表示されます。
私が監視（モニター）を使い始めたきっかけは、Patchが失敗しているのにエラーメッセージが画面に出ないケースでした。ラベルデバッグで変数の値を確認しても問題は見当たらず、でもデータが保存されない。監視（モニター）を開いてPatchのログを見たら、SharePointのある列の型が違うというメッセージがレスポンスに含まれていました。あの瞬間から、デバッグの考え方が変わりました。
監視（モニター）の起動方法
Power Apps Studioから起動する
- Power Apps Studioでアプリを開く
- 上部メニューの詳細設定をクリック
- ドロップダウンからモニターを選択
- 別タブで監視（モニター）画面が開く
- 監視（モニター）画面でアプリのモニターボタンをクリック
- 別ウィンドウでアプリのプレビューが起動する
アプリのプレビューウィンドウで操作すると、そのたびに監視（モニター）画面にログが積み上がります。エラーが起きる操作（ボタンを押す、データを保存するなど）を再現すると、その操作に関するログが赤くハイライトされます。
監視（モニター）画面の見方
ログ一覧の列の意味
監視（モニター）画面のログ一覧には複数の列があります。それぞれの意味を把握しておくと、問題のある行を素早く見つけられます。
| 列名 | 内容 | 確認ポイント |
|---|---|---|
| 時刻 | リクエストが発生した時刻 | 操作のタイミングと照合する |
| 操作 | 発生したイベントの種類（GetItems、Patch等） | どのデータ操作か確認する |
| コントロール | 操作を発生させたコントロール名 | どのコントロールが原因か特定する |
| プロパティ | 該当するプロパティ（Items、OnSelectなど） | どのプロパティに書いた式か確認する |
| 結果 | 成功 / エラー | 赤字の行がエラー |
| 状態コード | HTTPステータスコード（200、403、404等） | エラーの種類を大まかに判断する |
エラー行をクリックすると右ペインに詳細が表示されます。リクエストに送ったデータと、サーバーから返ってきたレスポンスの両方が確認できます。
HTTPステータスコードで原因の大枠を掴む
状態コード（HTTPステータスコード）の数字を見るだけで、エラーの種類を大まかに絞り込めます。
| ステータスコード | 意味 | よくある原因 |
|---|---|---|
| 200 | 成功 | エラーではない |
| 400 | リクエストが不正 | 送ったデータの型・形式が間違っている |
| 403 | アクセス権限なし | そのSharePointサイト・リストへの権限がない |
| 404 | リソースが見つからない | リスト名・サイトURLが間違っている |
| 429 | リクエスト過多 | 短時間に大量のリクエストを送った（スロットリング） |
| 500 | サーバーエラー | SharePoint側・Dataverse側の問題 |
監視（モニター）の使いどころ3パターン
パターン1：ギャラリーにデータが出ないとき
ギャラリーが空表示になっているとき、監視（モニター）を開いてアプリを起動すると、データ取得（GetItems）のログが表示されます。このログの結果列を見ることで、データソースへのアクセス自体が失敗しているのか、データが0件で返ってきているのかを区別できます。
- 監視（モニター）を起動してアプリのプレビューを開く
- ギャラリーが表示されたタイミングでGetItemsのログを確認する
- 結果がエラー→ステータスコードで原因を特定する
- 結果が成功でも0件→Filter条件を見直す
結果が成功でも件数が0の場合は、データソース自体は繋がっているのでFilter条件の問題です。数式エラー解決の全体マップのデバッグ手順と組み合わせて、Filter式を段階的に確認していきます。
パターン2：Patchが失敗しているとき
ボタンを押しても保存されない、エラーメッセージも出ない、そういうときは監視（モニター）でPatchのログを確認します。Patchが発生したタイミングのログを開くと、送信したデータの内容とサーバーの応答が両方確認できます。
Patchログの右ペイン要求タブに送ったデータが表示されます。列名・値・型が意図通りになっているかを確認してください。応答タブにはSharePointやDataverseが返したエラーメッセージが含まれており、この列の型が不正です、この列は必須ですといった具体的な情報が得られます。
パターン3：パフォーマンスが遅いとき
アプリの動作が遅いとき、監視（モニター）で各リクエストの所要時間を確認できます。特定のGetItemsに時間がかかっている場合、委任が効いていない（アプリ側で全件取得してから絞り込んでいる）可能性があります。
ログの期間列（ミリ秒）を見て、1秒を超えているリクエストがあれば改善の余地があります。Power Appsが重いときの改善方法の記事と組み合わせて対処してください。
ラベルデバッグと監視（モニター）の使い分け
2つのデバッグ手法をどう使い分けるかは、問題の場所によって決まります。
| 問題の場所 | 使うべきツール | 理由 |
|---|---|---|
| 変数の中身が正しいか | ラベルデバッグ | データソースに関係ない式の確認はラベルが速い |
| Filter条件で件数が合っているか | ラベルデバッグ（CountRows） | 式の結果をそのまま表示できる |
| データソースへの接続が成功しているか | 監視（モニター） | HTTPレベルの結果が必要 |
| Patchの書き込みが失敗している | 監視（モニター） | 送信データとサーバー応答の両方が必要 |
| アプリが遅い原因を調べる | 監視（モニター） | リクエスト単位の所要時間が分かる |
簡単にいうと、式の中の問題はラベル、データソースとの通信の問題は監視（モニター）です。ラベルデバッグで原因が見つからないときにMonitorを開く、という順番が実務的には効率的です。
まとめ
監視（モニター）は最初こそとっつきにくく感じますが、使い方を覚えると、データが来ない、保存されない系の問題が格段に速く解決できます。ステータスコードと右ペインのメッセージを読む習慣をつけるだけで、原因不明のまま延々と試行錯誤する時間がなくなります。
デバッグツールを使いこなすことは、開発の腕前を上げることと同じくらい大切です。ラベルデバッグと監視（モニター）の2つを組み合わせて、問題を素早く特定できるようになりましょう。
