この記事を読んでわかること
- Claude Code を使うと、Power Platform の開発がどんなふうに進むのか
- その進め方の中で、人間は何をすればよくて、何を AI に任せればいいのか
- Premium ライセンスなしで、自分のアプリ・フロー一覧を収集する仕組みの作り方（と、そこで踏んだ地雷）
突然ですが、自分が今まで作ったアプリ、把握できていますか？
私は把握できていませんでした。作っては忘れ、作っては忘れ。気づけば環境の中に、名前を見ても中身を思い出せないアプリが溜まっています。
そんなとき、Power Automate には環境内の Power Apps 一覧を取得できるコネクタがあるらしい、という話を知りました。じゃあそれを使えば、自分の資産を管理する仕組みが作れるのでは？
……と思ったものの、調査するのもやってみるのも、正直ちょっと大変です。コネクタの仕様を調べて、Premium かどうか確認して、SharePoint リストを設計して、フローを組んで。考えただけで週末が溶けます。
ということで、Claude Code に丸投げしてみることにしました。
何を作ったか
自分が作った Power Apps と Power Automate の一覧を Power Automate で自動収集して、博物館のように展示するキャンバスアプリを作りました。その名も「おれ作 博物館」です。
なぜ「管理台帳」ではなく「博物館」なのか。これは調査の結果、方針を変えたからです。
一般的なメーカー権限（管理者権限なし）で取得できるのは、環境全体ではなく「自分が所有・共有している分」だけでした。全社の資産を棚卸しする台帳にはできません。
でも、逆に考えると「自分が作ったものしか取れない」なら、いっそそっちに振り切ればいい。管理する台帳ではなく、自慢する博物館にしてしまえ、と。制約をコンセプトに変換したわけです。
結果、収集できたのはアプリ 262 件、フロー 84 件でした。我ながら作りすぎです。
前提・制約
- Premium ライセンスなしで作る（＝標準コネクタと SharePoint リストだけ）
- 管理者権限なしで動く（一般メーカーのままで完結させる）
- 人間が細かく口を出すこともできますが、今回はあえて丸投げする
そもそも Claude Code で Power Apps を作るとはどういうことか、という話は以前にも書いています。
あわせて読みたいClaude Codeと意思決定Power Appsを作ったログこの記事を読んでわかること Claude CodeとPower Appsを開発してみて分かったこと どんな風にClaude Codeと作業をしたのか はじめ…この記事を読む →
丸投げの実況
ここからは、実際にどう進んだかを時系列で書いていきます。
1. まず統括役を立てる
いきなり作らせません。最初にやるのは、一番賢いモデルを現場監督にすることです。
私は /delegate という自作スキルを使っています。中身はシンプルで、「統括役のモデルは発明・裁定・最終検品だけをやり、実作業はサブエージェント（Opus / Sonnet / Haiku）に振れ」という分担ルールを恒久化したものです。
スキルの中身は、ほぼこの表だけです。
| 仕事の種類 | 担当 |
|---|---|
| 発明・統率・最難関・最終検品 | メインループ（統括モデル） |
| 調査・実装・執筆・レビュー | Opus |
| 事務・台帳更新・整理・commit 文面 | Sonnet |
| 単純機械作業 | Haiku |
これに、運用の型を数行だけ添えてあります。
- 並列 fan-out：独立したタスクは1メッセージで同時に起動する（直列に待たない）
- バックグラウンド既定：起動したら待たずに次の仕事を進める
- 続投 > 新規：同じ成果物の修正は、新しく起こさず同じエージェントに続けさせる
- プロンプトは自己完結：サブエージェントは会話履歴を見られないので、前提を毎回書く
- 検品は統括の責任：委任しても品質責任は監督側にある
迷ったら1段安いモデルに振って、検品で品質を担保する。要は、社長が全部自分で手を動かさない体制を最初に作る、ということですね。
なお、サブエージェントをぽんぽん起動するとその分お金もかかります。1タスクいくらだったのかを測る仕組みは、別の記事で作りました。
あわせて読みたい【AI従量課金時代】「このタスク、いくらだった？」に答えられないので、Claude Code に自分の消費を測らせて台帳に記録させたAI コーディングエージェントの従量課金時代、「このタスクにいくら使ったか」を測る仕組みを作りました。Claude Code のトランスクリプトから消費トークンを自己計測して Notion 台帳へ記録。実測15セッション分の生データと、コストの支配項が「書いた量」ではなかった話。この記事を読む →
2. 勝手に調査を始める
ここがすごいところなのですが、「作って」と言うと、まず作り方を調べ始めます。
今回で言えば「Power Apps for Makers / Power Automate Management / Power Platform for Admins の各コネクタは標準（非 Premium）なのか」「一般メーカー権限で取れる範囲はどこまでか」「ページング・スロットリングのハマりどころは」あたりを、調査専門のサブエージェントがバックグラウンドで調べていきます。
しかも頼んでいないのに、CoE Starter Kit（Microsoft 公式の管理キット）との比較まで気を利かせて調べてくれていました。結論は「CoE Starter Kit は保守終了済みで、後継は管理者専用。だからメーカー権限方式の存在意義は『軽いから』ではなく『管理者じゃなくても使えるから』だ」というもの。
自分では思いつかなかった角度で、作る理由を言語化してくれたわけです。ちょっと悔しいですね。
3. 人間の判断を求めてくる
調査が終わると、人間にしか決められないことだけを聞いてきます。今回は3問でした。
- 台帳のスコープをどうするか（自分の所有分だけしか取れない、という調査結果を踏まえて）
- 台帳に手動管理列（人間が書く列）を付けるか
- 見る画面はどうするか
ありがたいのは、選択肢に (Recommended) が付いていることです。迷ったらとりあえずこれを選んでおけば OK です（笑）。私は3問とも推奨どおりに答えました。
もう一点、地味に優秀だと思ったのが、調査結果を使い捨てにせず、根拠ファイル（一次 URL 付き）として残しているところです。後から「なんでこの判断にしたんだっけ？」と辿れます。
4. たまに、人間が HaaS として働く
とはいえ、Claude Code にもできないことがあります。そういうときは人間に仕事が発注されます。
HaaS（Human as a Service）とは 人間が AI に呼び出されて、主に API キーの取得や物理空間での作業を担うこと。
今回発注されたのは、コネクタの接続の認証でした。実は Power Automate の接続そのものは API から作成できて、しかも 201 Created が返ってきます。ところが中身を見ると認証が通っておらず、使えません。OAuth の同意画面はブラウザ以外に経路がないからです。
なので、AI が出してきた URL を人間がブラウザで開いて、ポチッと同意する。従順な手足です。
同じ理由で、空のキャンバスアプリを作って「共同編集を有効にする」のも人間の仕事でした。ここまでやったら、あとは URL を Claude Code に渡して MCP で接続してもらうだけです。
詰まったところ
ここからが記事の本番です。丸投げとはいえ、横で見ているとそこそこ派手に転んでいます。無かったことにはしません。
1. 「1回しか実行していないのに 426 行入る」
一番の山場でした。収集フローを1回だけ実行したのに、SharePoint リストが 426 行になっています。しかしアプリの ID でユニークを取ると 262 件しかない。つまり 164 行が重複です。
面白いのは、2回目・3回目に実行しても1行も増えないことでした。突合ロジック自体は正しいのです。
犯人は、「マップに無ければ POST する」という処理が冪等ではなかったことでした。SharePoint がスロットリングでエラーを返しつつ、実際には書き込みがコミットされていた。そこに Logic Apps の自動リトライがもう1行作る。だから1回の実行の中で二重に増える。重複が、書き込みの集中した環境（251 件）に偏っていたのも、スロットリング説と一致していました。
対策は、アプリ側のロジックではなくデータ層の制約で保証すること。キー列に「重複禁止」（EnforceUniqueValues）を付けて、リトライ側の POST を SharePoint 自身に弾いてもらう構成に変えました。修正後は 262 行 / ユニーク 262 / 重複 0 です。
ここで得た教訓が、今回の一番の収穫でした。
POST は冪等ではない。「事前に存在チェック → 無ければ作る」は、競合とリトライには勝てない。 そして「重複が無いこと」は件数ではなくキーのユニーク数で検査する。
件数だけ見ていると「1回目も2回目も 426 行」なので、冪等に見えてしまうんですよね。実際そう見えていました。
2. 何も言わないのに 1/3 しか取れない
Get Apps アクションは、既定だと 98 件しか返しません。ドキュメント上の既定値は 250 なのに、実測は 98 でした。
しかもエラーは一切出ません。ページングの設定を付け忘れると、静かに 1/3 だけ収集して成功します。これは怖い。設定を入れたら 251 件が返るようになりました。
3. 調査レポートを、実測がひっくり返した
これは AI との付き合い方として面白かった話です。
事前の調査レポートには「フローの所有者は creator から取れる」と書いてありました。ところが実際にデータを取って数えてみると、返ってきた 71 本がきれいに2群に割れていたのです。
| 件数 | creator | owningUser | |
|---|---|---|---|
| ソリューションフロー | 51 | null | あり |
| 非ソリューション（マイフロー） | 20 | あり | null |
つまり所有者のフィールドがフローの種別で排他になっている。レポートどおりに実装していたら、資産の主力であるソリューションフロー 51 本すべてで、所有者が空欄になっていました。
調査は当たりを付けるためのもので、正解は実測でしか確定しない。 ここは AI の調査結果でも、人間の記憶でも同じですね。
4. 部品が丸ごと消える（キャンバスアプリ編）
最後にキャンバスアプリ側でも一つ。展示写真をアップロードする画面を作ったのですが、添付ファイルの UI が画面に丸ごと出てきませんでした。
原因は、フォームの幅でした。既定の 292px がデータカードの最小幅を下回っていて、カードごと描画されていなかったのです。320px に広げたら普通に出ました。エラーも警告も出ないので、これも気づきにくいタイプです。
結局、人間は何をしたのか
丸投げした結果、私がやったことを並べてみます。
- 最初に「こういうものが作りたい」と言った
- 「自分の所有分しか取れないなら、いっそ博物館にしよう」と方針を決めた
- 3問の質問に (Recommended) で答えた
- ブラウザを開いて接続の同意を押した（HaaS）
- 空のキャンバスアプリを作って共同編集をオンにした（HaaS）
- できたものを実機で触って「写真も飾りたい」と言った
コンセプトの裁定と、手足。 それだけです。コネクタの仕様調査も、フローの実装も、重複バグの切り分けも、私は横で見ていただけでした。
逆に言えば、この6つはAI には決められない・できないということでもあります。特に2番の「制約をコンセプトに反転させる」は、私が一番楽しかったところでした。ここを AI に譲ってしまうと、たぶん面白くない管理台帳ができあがっていたと思います。
この「判断と手足だけ担当する」進め方は、Power Platform に限りません。CAD を一度も触らずに3Dモデリングしているときも、やっていることはほぼ同じでした。
あわせて読みたい【3Dプリンター】CADを一度も触らずに、Claude Code だけで3Dモデリングしてみている話（手法編）CADのGUIを一度も操作せず、Claude Code との対話だけで OpenSCAD の設計を書き、干渉体積・構造計算・断面検品の3チェックを通して Bambu A1 で刷る。その手法と、シミュレーション路線から撤退した正直な話。この記事を読む →
まとめ
- Power Automate の標準コネクタだけで、自分の Power Apps・Power Automate は収集できる（Premium も管理者権限も不要）
- ただし取れるのは自分の所有・共有分だけ。そこは制約として受け入れて、コンセプトごと寄せてしまうのが早い
- Claude Code に丸投げすると、調査 → 裁定の依頼 → 実装 → 検証まで走る。人間の仕事は「判断」と「手足」に寄っていく
- とはいえ転ぶときは派手に転ぶ。件数だけ見て安心しない（重複はキーのユニーク数で数える）
自分の作ったものが博物館に並んでいるのを眺めるのは、想像よりずっと良かったです。262 件も作っていたのかと、素直に驚きました。皆さんもぜひ、自分の環境を棚卸ししてみてはいかがでしょうか。（数を見て「これ全部メンテするのか」と青ざめる可能性はあります）
