Microsoft Power Apps Advent Calendar 2025

Power Apps初心者がAIを共同開発者にして、AI統合型アプリ開発環境へ辿り着くまで

Last updated at 2025-12-07Posted at 2025-12-07

0. はじめに

　
私は普段、UX/UIデザイナーとして活動しています。
いわゆるソフトウェア開発の世界で言えば「非エンジニア」と呼ばれる側の人間です。

そんな立場から、Power Apps を使った業務アプリの開発に本格的に関わるようになり、気がつけば Azure SQL Databaseとデータ連携し、画面数も表示処理もそれなりに複雑なアプリ を AIと協働しながら作るようになりました。

今では、なんとかAIの出してきたコードをレビューし、必要であれば設計方針の変更を指示できるようにもなっています。この記事では、

この記事で伝えたいこと

なぜAIを使い始めたのか
どうやってPower Appsの開発知識を身につけたのか
どのようにAIとの付き合い方・開発環境のあり方をアップデートしていったのか

　
を、「きれいな成功ストーリー」ではなく、Power Fx 構文に難儀しながら、AIと殴り合ってきた過程を書いてみます。

結果的に盛りだくさんになってしまいましたが...Power Apps で効率的にDX施策を進めたいと試行錯誤する中で、同じように悩む人の背中を少しだけ押せる記事になれば嬉しいです。

構築できた最新の環境へスキップする方はこちら

1. AIに頼る前、Power Fxに悩まされていた頃

Power Appsアプリ開発で必要になるPower Fx言語は、「Excelに似た数式ベースのローコード言語」 のように、簡単そうに言われますが、そもそもExcel関数もあまり使ったことのなかった私にとっては、なかなか馴染めなかったです。

1-1.Visibleひとつ変えたいだけなのに、変数だらけになる

最初にぶつかったのは、「Visibleを外部から変えたいだけなのに、やたら変数が必要」 という違和感でした。

たとえば、あるコンポーネントの表示 / 非表示を、別のスクリーンやボタンから制御したいだけなのに
　

直接 ThisComponent.Visible をいじるのではなく、
いったん rocIsDetailVisible のような中間変数を作って、
Visible プロパティにはその変数を参照させておいて、
別の場所で UpdateContext({ rocIsDetailVisible: true }) のように切り替える。

// ボタンの OnSelectプロパティ
UpdateContext({ rocIsDetailVisible: !rocIsDetailVisible });

// コンポーネントの Visibleプロパティ
rocIsDetailVisible

リアクティブ的な？「状態を間接的にいじる」設計思想と言われればそうなのですが、JavaScriptをちょこっとかじった程度の私からは、最初、 まわりくどくて、訳がわからない感覚 でした。

「ただダイアログの 表示 / 非表示 を変えたいだけなのに？」

そんなところから、既にPower Fx に引きずり回されていました。

1-2. コレクション変数との距離感：LookUp と Patch に馴染めない

たくさんのデータを処理するようになって、次に来たのが コレクション変数との距離感問題 です。
　

値を取り出したいときは LookUp() が必要
更新したいときは Patch() を書かないといけない
しかも「その場で代入して終わり」ではなく、レコードを指定して更新する
　
たとえばこんな処理です。

// コレクションから特定行を取得して更新
With(
    {
        target: LookUp(
            colLists,
            ListId = locSelectedListId
        )
    },
    Patch(
        colLists,
        target,
        {
            Status: "Completed",
            ModifiedAt: Now()
        }
    )
)

　
率直に、

「なぜこんなにまわりくどく書かないと、1件のステータス更新ができないのか？」

という戸惑いがありました。
　

「レコード」という概念
「データを直接書き換えず、新しい値として作り直す更新の仕方」
一度レコードを変数に束縛してからPatch

などなど、JavaScriptっぽさもあるのにJavaScriptではない不思議な世界観で、
ひたすら 「訳がわからない」 というのが正直なところでした。

ちなみに今だったら、これはWith使わなくてもまとめて書けますが、当時はWithの意味すら曖昧のままでしたので...。
　

Patch(colLists,
    LookUp(colLists,
        ListId = locSelectedListId,
        {
            Status: "Completed",
            ModifiedAt: Now()
        }
    )
)

1-3. スキーマ固定と型エラーの解消で半日溶けちゃう

データソースと連携してコレクション変数を大量に使うようになった頃、特に苦しかったのが、 データソース（Azure SQL / Excel / SharePoint List...）側での変更が、アプリ側のコレクションに全然反映されない問題 でした。

頑固すぎる「データスキーマ固定」

例えば、データソースからデータを取得して、アプリ内部でコレクション変数として管理していたとします。
　
データソースのテーブル

UserId	Name
U123456	Junichi Suzuki

データソースからコレクション変数に格納

Refresh(DataSourceView);

ClearCollect(
    colData,
    Filter(
        DataSourceView,
        UserId = gblMyUserId
    )
);

このcolDataをアプリのいろんなところで参照している状態で

データソースを変更

UserId	Name	Role ※追加
U123456	Junichi Suzuki	Designer

このように列を追加したりして変更しても、コレクション変数に反映されないことがよくありました。

具体的にはPower Apps Studio環境で、「変数」メニューからコレクション変数の内容を確認することができますが、列は確かに追加されているのに、値が入ってこない、空白のままという現象がよくありました。

よくある対策としては、
　

データソース/コネクタを一旦削除して追加し直す
コレクション変数を一回削除して作り直す
コレクション変数生成時に列を明示して初期化する
　
のようなことを見かけますが、経験上、「1回コレクション変数への参照をすべて断ち切ってから、初期化処理を実行させて元に戻す」 というようなことをしないと、同じコレクション変数でのスキーマ更新はなかなか達成されなかったです。

これは、コレクション変数の初回設定時の列構造がスキーマ固定されるという仕様でした。スピード感持ってガンガン開発してすぐ変更を試す。みたいな進め方でやっていると陥りそうなケースだと思います。

いくら、ローコードといっても、大元のデータ設計やその運用は、最低限きちんと計画されるべきだなと学びました。
　

厳しい型エラー

スキーマ固定の問題もそうですが、もう1つ時間を溶かされるのが型エラーでした。

データソース

UserId	Name	Status（数値）
U123456	Junichi Suzuki	0

こうなってたものを

データソースを変更

UserId	Name	Status（文字列）
U123456	Junichi Suzuki	disabled

こう変更したりすると、スキーマ固定も相まって、静かに値が入ってこなくなったりします。さらに、この状態に気がつかないまま「文字列前提」に実装を修正しようとして、コードをどんどん置き換えていってしまうと、

If(Status = "disabled",
    ...,
    ...
)

よくみる

型に互換性がないため比較できません。Text と Number の型は比較できません。

もうコードエラー出まくりです。

当時きちんとデータの流れを追わず、Text()やValue()で部分的にキャストして解決しようとして、 どハマり したのを覚えています。

ただし、このスキーマ固定や厳密な型チェックがあるおかげで、あまり厳格なコーディングをアプリ開発者自身ができなくても、一定の動作が担保されたアプリを業務に適用できるというのも、今ではわかります。

1-4. こういった「訳がわからない」が積み上がったフェーズ

この頃の感情を一言で言うと、

訳がわかりません！

コードフォーマットについても、なんとなくの感覚ですが、かっこ「()」の数と、カンマ区切りのネストが多くなりがちで、少し構造を変更しただけでコードエラーだらけになり、

「どこから触っていいのか分からない」

状態になることも多かったです。よくローコードは全然簡単じゃない！と愚痴を言ってました。このあたりから、「自力のみで理解して進む」ことに限界を感じ始め、AIに頼る比重が一気に上がっていきます。

状況と課題

ちょっとした「理解のとっかかり」もつかめていない状態
情報はあっても、まだそれらが「相互に結びついていない」状態
じっくり取り組んで、Power Fxそのものを理解するモチベーション低い
実装して動作することにばかり注目しがち

2. AIを「コード自販機」だと思っていた頃

自力では「作れるようになれない」と思った私はちょうど話題になっていた「AI」に頼り始めました。皆さんもご存知、ChatGPTやClaudeのチャット（2025年4月時点）です。
ちなみにこの頃のAIモデルはPower Fx構文の理解もあまり進んでいない感じでした。

それでも私はAIのことを

「コードを投げると答えが返ってくる便利な存在」

だと認識していました。先述したようにPower Fxの構文をちゃんと自身で理解しようとしていなかったからです。理解するのに時間がかかるだろうな〜（面倒）と思っていて、頼りやすかったAIに注目したのかもしれません。
　

　

作りたいものを伝えて、コードを生成してもらって適用
コードエラーが出たら、コピペしてAIにそのまま聞く
修正版のコードをまるっとそのまま貼り付ける
またエラー → またAIに聞く...の繰り返し

「開発してる時間よりも、AIとの対話の方が長かった」 のが正直なところです。コードエラーのことばっかり話していて、何にも機能実装できなかった1日が何回もあったほどですw
この頃のAIの役割は、完全に 「コード自販機」 でした。

状況と課題

AIに「コードがどうあるべきか」を委ねている状態
コードエラーが出ても、自分で理解して判断できない。
うまくいくかどうか「ガチャ」引いているに近い

3. AIを「コードガチャ自販機」から「共同開発者」に変えるための文脈設定

　
コードエラーでもかなり苦戦していましたが、それ以外のAIとのやり取りの中で、難儀していたのは以下のようなことです。
　

チャットが新しくなるたびに、毎回0から説明しないといけない
そもそもAIがPower Fx構文に詳しくない。他の言語の前提や書き方が混ざったりする
カッコやカンマ、セミコロンが正確でない時がある
チャットが新しくなるとリセットされてしまうのに、会話してるとすぐにチャンク制限でチャットが終了してしまう。いい感じで前提や情報を受け渡せていたのに...

Power Appsは特に画面数が増えると、画面間の連携や状態管理が複雑化します。
Power Fxのコードもプロパティごとになっていて、分散しがちです。部分だけ見ても全体像が掴みにくいです。そのためAIは、その時点で渡された情報内でしか推論できず、

表面的には正しそうだが、動かないコード

を返す場面が非常に多かったと思います。

3-1. いよいよ文脈管理とトークン節約が必須になったきっかけ

それでもなんとかアプリの機能実装も進んで、OnVisible や OnSelect で1000行規模のコードになってきた頃、AIにコード全文とやりたいことを渡して、編集してもらおうとしたところ、コードの確認だけで 「チャット自体が強制終了」 しました。軽く絶望したのを覚えていますw
　

渡す情報が多すぎたら、そもそも処理できない
途中まで読めたとしても、その後のやり取りすらできない

　
この辺りから、「必要な情報を必要なだけ適切に渡したい！」 と思うようになりました。
しかし、前提を手作業で丁寧に毎回説明するのは、手間的にも、気持ち的にも限界が来ていました。

ここで、AIが開発の文脈を継続して理解できる仕組みをようやく作り始めました。

3-2. プロジェクトファイルとナレッジの活用〜文脈設計の基盤

ChatGPT：プロジェクトファイル

ChatGPTでは、きちんと「プロジェクト」を作成して、以下の内容を前提情報として含んだ、プロジェクトファイルを整理し始めました。

アプリ開発の背景と目的
アプリ仕様
データモデル設計
データベース仕様
現在の状況（何をやっているところで、どこまで進んでいるか）

などを整理して保存しました。
例えば一番最初にまとめ始めた内容はマークダウン形式でこんな感じから始まり、情報が増えるに従って、徐々にファイルを分割して整理を進めていきました。
　
アプリ仕様.md

# アプリ目的
商品の販売在庫計画の管理を行うための、週次データ入力と更新の業務効率化

# 構造
Screen01：アプリ初期化
Screen02：商品一覧
Screen03：詳細編集
:

# データ構造
colPlanData：週次の計画データ
| PlanId  | PlanName   | w1  | w2  | w3  | ... |
| ------- | ---------- | --- | --- | --- | --- |
| P123456 | 販売        | 100 | 120 | 110 | ... |

colProductMaster：商品マスタ
:

# 変数命名規則
グローバル変数：glb*
コレクション変数：col*
コンテキスト変数：loc*
:

　
その後、開発チームでClaudeの契約をしたので、Claudeに移行してからは、

Claude：ナレッジ

アプリ開発の背景と目的
アプリ仕様
データモデル設計
データベース仕様
画面構造 [New!]
コーディングルール [New!]
Power Fxの制約 [new!]
進捗管理リスト（旧：現在の状況） [New!]

などをナレッジとして蓄積していきました。こういった整理を続けていくと、AIの回答が明らかに変わってきます。

進捗管理リスト

進捗管理リストは、自分で手動で書くのも気が進まなかったので、AIに直接

一旦ここまでの進捗を整理してまとめてください。

と指示して、あまり内容の精度は気にせず、書いてもらっていました。
もしチャットが途切れて新しく始める場合でも

作業の続きをします。
ナレッジファイルの進捗管理リスト.mdを確認してください。
いきなり進行せず、まずは私とすり合わせを行った後、何から進めるかを明確にします。

と伝えて、どこから始めたら良いのかをすり合わせするように強制して、いきなりコードを生成しようとするのを止めていました。

3-3.AIと「話が合う」瞬間が突然来る

これまでの前提や文脈にそった提案が返ってくる
「何をしたいか」を理解した上でアドバイスしてくれる
部分コードだけ渡しても、全体構造を踏まえた改善コードが出てくる
コードエラーがだんだん少なくなる

これが 「AIをコード自販機から共同開発者に変える」 ための、最初の一歩でした。

状況と課題

依然としてチャットのチャンク制限は残っている
進捗管理ファイルのおかげで、0から全部を説明し直す手間がなくなった
「該当箇所」を特定してやりとりするようになった

4. Power Appsアプリ開発の学習〜「理解して開発」への転換

　
チャット強制終了事件を経て、AIに丸投げして「コードを生成してもらう」は無理。「必要な情報を必要なだけ適切に渡したい！」と思うようになった と書きました。

AIの適切な理解のために、背景や文脈を揃えても、依然としてコードを丸投げできない課題はそのまま残ります。
特定部分のコードをAIに渡してやりとりするためには、「どこをどう修正したいのか」 自分自身が理解できていないと、適切なやりとりができません。

「自分でもきちんとPower Fxをわかっていないといけない」 と思った私は、AIとのやり取りを意図的に変えて、 開発しながら「ついでに学ぶ」 ことにしました。
　

AIとのコミュニケーションの仕方を変えた

それまでは、

このエラーを修正してください。（要望）

こんなエラーが出ています。（報告）

とだけ聞いていましたが、ここからは毎回こう聞くようになりました。

このエラーは何が原因で起きていますか？（エラー内容の深掘り）

このエラーを修正するとしたら、どんな方法がありますか？（エラー修正のアプローチ方法）

このエラーを起きにくくするためにはどんな書き方がありますか？（エラー防止の王道がないか）

AIに提案されたコードについても、

この処理は具体的に何をしていますか？（コード内容の理解）

処理に無駄な部分はありませんか？（コード品質の再確認の要求）

別のアプローチがあれば教えてください（同じ処理実現のためのアプローチの選択肢）

と 1つ1つ壁にぶち当たったその度に、理解するための質問を経由することで、学習するプロセスを組み込みました。
もちろん、1つ1つの関数の仕様についても、その都度Microsoft Learnで調べたり、URLを渡して 「AIに解説を頼む」 ようになりました。

結果的に何が変わったのか？

Before	After
コードが動くかどうかしか見れなかった	設計意図と影響範囲を理解できるように
コードをまるっと貼り替える	変更点だけを抽出して修正できる
AIに任せて、うまくいくように祈る	AIと議論して決める
コードレビューできない	AIのコードをレビューできるように！

さらに、

今後を見据えて、予想される変更がしやすい設計にするにはどう書くべきか
依存関係を少なくするにはどのような構造にすべきか
後で自分がわかりやすいコードにしておくには、どの書き方を採用するか

といった話が 「AIと成立するようになりました。」
　

5. そしてAIが進行管理を担当し始める...瞬間

　
背景と文脈の設計、部分単位での修正依頼が可能になって、少しずつAIと対話できる状態が整ってきました。

5-1. AIが「タスク管理」を始める

文脈設計が進んだある日、私とAIとのやりとりがありました。

私：ナレッジの中の進捗管理リストが複数存在しているので、最新のものをベースに整理、1つに統合してください。

Claude：了解しました、マスタータスクリストを作成します。
現在の課題、次に取り組むべき改善項目、ステータス、優先順位をまとめます。

マスタータスクリスト？！（名前がダサいが...）AI自身が、「今やるべきこと」を期待を超えて整理し始めました。

現在の進捗状況
進行中タスク（⏳待機 / 🔄進行 / ✔完了）
待機中タスク
完了済みタスクリスト
バージョン情報
実装詳細（直近タスクのコードを記録）
次回実装計画

AIとの協働プロセスが大きく変化する 「マスタータスクリスト」 の爆誕の瞬間でした。

AIが作業者ではなく、共同開発者になった感

単なるコード修正や回答のみではなく、次にやるべきことを自律的にまとめ、作業の順番に従って進捗を管理してくれる。さらに、次のチャットへの引き継ぎがスムーズに行われる。

この出来事が、本格的に 「AIと一緒に開発する」 フェーズへの入り口でした。

5-2. 作成されたマスタータスクリストの中身

AIが作成したマスタータスクリストは、以下のようなフォーマットでした。

マスタータスクリスト v20250602.1.md

# PowerApps 販売在庫管理システム - マスタータスクリスト v20250602.1

## 📋 **バージョン情報**
- **バージョン**: v20250602.1
- **更新日**: 2025年6月2日
- **前バージョン**: なし（初回統合版）
- **変更内容**: マスタータスクリスト統合＋バージョン管理導入
- **次回更新予定**: Task 3.2完了後 → v20250602.2予定

## 📊 プロジェクト概要

**目標**: PowerApps上で商品リストがGalleryで表示され、各商品の詳細テーブルで行ごとのアコーディオンがスムーズに動くシステムの構築

**基盤仕様**:
- **商品数**: 5商品（テスト版：ID 1000-1004）
- **項目数**: 54項目（7セクション構成）
- **データ量**: 270レコード（5商品×54項目）

**技術スタック**:
- **データソース**: SharePoint Excel（dummy_商品.xlsx → colPlanData）
- **UI構成**: Gallery（商品リスト） + HTMLTextコントロール（詳細テーブル）
- **状態管理**: colPlanExpandState（商品別アコーディオン状態）

---

## 📈 **最新進捗サマリー（2025年6月2日更新）**

**全体進捗**: **75%** (5/8タスク完了)

**Phase別進捗**:
- ✅ **Phase 1 (基盤構築)**: **100%** (2/2タスク完了)
- ✅ **Phase 2 (商品別独立)**: **100%** (2/2タスク完了)
- 🔄 **Phase 3 (機能拡張)**: **50%** (1/2タスク完了、Task 3.1 100%完了)
- ⏳ **Phase 4 (完成準備)**: **0%** (0/2タスク)

**最新マイルストーン**: 🎉 **Task 3.1完了** - 新仕様アコーディオンシステム基盤完成

---

## 📋 **Phase別タスク詳細**

### **Phase 1: 基盤構築** ✅ **完了**

#### **Task 1.1: データ構造確認・整理** ✅
- **状況**: **完了**
- **成果**: 10週対応データ構造確認完了、SharePoint接続設定完了

#### **Task 1.2: 基本Gallery+アコーディオン実装** ✅
- **状況**: **完了**
- **成果**: Gallery（5商品表示）実装完了、HTMLTextコントロール埋め込み完了

---
:
:
省略

---

## 🔧 **重要な技術的知見**

### **With関数制約対応**
- **問題**: 同一階層変数参照でエラー発生
- **解決**: 2段階（または3段階）With方式で安定性確保

---

## 🎯 **次回チャットでの作業予定**

1. **Task 3.2実施**: パフォーマンス検証
2. **Task 3.3検討**: UI調整・チューニング（新規）
3. **Task 4.1準備**: 残り5セクション追加

---

**📝 プロジェクト管理ルール**
1. **進捗更新**: チャット完了時に必ず本ファイルを更新
2. **情報一元化**: 引き継ぎ資料は本ファイルに統合、重複管理禁止
3. **技術的知見**: 重要な発見は必ず「技術的知見」セクションに記録
4. **マイルストーン**: 重要な完了時点は明確に記録・祝賀
5. **バージョン管理**: 更新時は新バージョン作成、旧ファイル削除

**バージョン**: v20250602.1
**最終更新**: 2025年6月2日
**更新者**: AI Assistant
**次回更新予定**: Task 3.2完了後 → v20250602.2

マスタータスクリスト.mdに私は一切手を触れていないのが驚きです。「チャット引き継ぎ時のロスを無くしたい」「ファイルが複数に分割されたくない」のような要望はやり取りの中で伝えていました。

5-3. この転換点での意味

この出来事が示していたのは、「AIは単にコードを書くツールではなく、プロジェクトを理解させる対象だ」 という事です。

Before	After
エラーが出るたび丸投げ	タスク計画含めて共同設計
修正作業の作業員	設計・計画・管理を行うパートナー
その場限りの修正	プロジェクトとしての進行管理
「書く」AI	「考える」AI

私はこの瞬間、自分の認識としても 「何かが切り替わった」 感覚がありました。

AIは受取る情報の品質に応じて、役割が変わってしまう。

状況と課題

マスタータスクリストのおかげで、より確実なチャット間の引き継ぎが可能になった
AIに任せて、頼ることのできる部分が増えてきた
長いコードは一括で読めず、部分でのやり取りはそのまま

6. AI統合型開発環境への移行（最新の開発体験）

文脈設計と自身のPower App開発の理解、マスタータスクリストによって、
AIと対話しながら開発する土台がほぼ整いましたが、これ、どうにかならないのかな...という課題が残りました。

Power Apps開発環境からのコードコピペが非常に面倒

自身の理解が深まったこともあって、「どこを修正したら良いか」 はわかってはいるものの、画面間の依存関係、変数の影響範囲、データフローは、Power Apps Studio のUIでは結局あちらこちらを確認しないといけませんし、そもそも、私がいちいちコードを抜き出してAIに伝えるのが嫌だwと思っていました。

AIを共同開発者として本格的に機能させるには、

AIがソースコードを直接解析できる環境

が必要だと思いました。ちょうどこの頃、Claude Codeで盛り上がった頃です。

6-1. ソースコードのYAMLファイルからPower Fxコード展開＋AI統合環境へ

前提と決め手になったのは：
　

チャンク節約のためとはいえ、手動で文脈管理することに疲れたこと
Claude Code のような「ファイルベースでのAI協働」が現実になったこと
Power AppsのソースコードのYAMLをAIで編集させると、フォーマットエラーが頻繁で起きやすいこと
Reactのような技術スタックと違い、AI自身が動作をブラウザでデバックすることが現状難しく、結局Power Apps Studioで動作確認をしないといけないということ
　
これらから、試行錯誤の上、Cursorを導入して、開発環境を以下のように構築しました。Cursorでなくても、VSCode+プラグインでも同じようなことができると思います。

※全量は膨大になるので要所だけ

▼ ローカル開発環境

├── src/
│   └── .msappを展開して、YAMLで構成されたアプリソース
├── improvements/
│   ├── _TEMPLATE/（改善作業に必要なファイルテンプレート）
│   ├── 001_product-list-fixed/
│   │   ├── implementation/
│   │   │   ├── MainScreen/
│   │   │   │   ├── Button_1/
│   │   │   │   │   ├── OnSelect_fx.txt（Power Fxコード）
│   │   │   │   │   ├── Visible_fx.txt（Power Fxコード）
│   │   ├── README.md（実装手順書）
│   │   ├── SPEC.md（仕様書）
│   │   ├── TESTING.md（テストケース）
│   │   ├── LESSONS_LEARNED.md（Good & More、AI自身の振り返り）
│   ├── ：
├── docs/
│   ├── POWER_APPS_CODING_STANDARDS.md（コーディング規約）
│   ├── IMPROVEMENT_START_GUIDE.md（改善作業開始時のガイド）
│   ├── POWER_FX_YAML_GRAMMAR.md（Power AppsのYAML文法仕様）
│   ├── ：（省略）
│   ├── PROPERTY_FILE_FORMAT.md（プロパティファイルのフォーマット定義）
│   └── DEV_GUIDELINE.md（開発ガイドライン）
└── .ai-context/
    └── PROJECT_MEMORY（以前のマスタータスクリスト的な、今何をやってるかなどの記憶領域）

何をすると何が起こるか

src/ディレクトリに、Power Appsアプリから「コピーのダウンロード」で取得した.msappを.zipにして解凍した最新のソースファイルを手で配置
Cursorのチャットパネルから、AIに対して「改善を始める」意図と、内容を伝える。
AIは適時、どんな改善が必要か？を私とすり合わせる。
AIはsrc/ファイルの中のYAMLファイルを検索して、どのファイルの修正が必要かを分析する。
AIはimprovements/ディレクトリに新しく採番したディレクトリを新しく作成する。
AIはこのディレクトリの中に、改善仕様、実装手順のドキュメントを作成する。
AIはこのディレクトリの中に、解析したYAMLから、各スクリーン、各コンポーネントごとにプロパティコードを抜き出して、xxx_fx.txtというファイルを作成する。改善のための修正コードはこのファイルごとに記載される。
AIは実装完了後のテストケースを作成する。

これにより、以下が可能になりました。

Before	After
Power Apps Studio上でコピペしてAIにコードを伝える	AIがYAMLソースを直接解析できる
修正箇所を自身で網羅的に特定するのが手間	AIが依存関係を追跡して対象プロパティを抽出
修正方針・方法の提示の仕方が毎回違う	手順・フォーマットが固定化

6-2. 実際のAI対話フロー（例）

例として、既存のアプリを修正・改善する時のやり取りは、ざっくりこんな流れです。

新しく改善を始めたいです。
商品リスト画面の商品リストに並び替えの機能を追加します。
主にMainScreenに変更が入りますが、他に影響のある箇所も調査して実装方針を立ててください。

これに対してAIは、一通りの実装ファイルを作成した後、

実装完了内容

作成したファイル
1. Button_1.OnSelect 修正
2. MainScreen.OnVisible 修正
README.md - 実装手順ガイド

実装内容の要約
1. Button_1.OnSelect 修正
  - 並び替えパネルを表示するためのlocSortPanelVisibleを更新
  - ：
2. MainScreen.OnVisible 修正
  - locSortPanelVisibleを初期化
  - ：

すべての実装ファイルとドキュメントが作成済みです。Power Apps Studioで適用してください。

このように返してくれます。
この体験は、もはや

「AIに指示を出す」段階ではなく、
「AIと共同でプロジェクトを進める」段階に入った

と感じさせるものでした。

今後の課題と留意点

現在は手動でアプリのソースコードを配置していますが、Microsoft Power Platform CLIを導入して、pacコマンドで直接最新のコード取得もできそう
ディレクトリとファイル構造は、全てのケースに当てはまってうまくいくとも限らないので参考情報として

6-3. まとめ

Before	After
長いコードから自分で探して抜き出す	AIがYAMLコードから特定して抽出
出力されたコードを適用。なんとなくで動作確認	実装手順＋テストケース＋リスクをチェックしつつ修正
AI＝回答者	AI＝共同設計者＋進行管理者

AIはコードを書く“手”であると同時に、
既存コードを読み解き、改善設計とテスト計画まで生成する“頭”にもなり得る。

6. まとめ ― AIと共同開発するフェーズへ

この約半年間、私は Power Apps と AI を使いながら、DX推進のためのアプリを開発してきました。

最初はPower Fxの作法に馴染めず、AIにコードを丸投げしては、その度に難儀する開発を続けていました。
しかし、文脈を共有し、目的と前提を伝え、AIを「共同開発者」として認識できるようになったとき、開発のスタイルはまったく別物に変わりました。
　

目的と前提を共有して検討・議論できる
修正箇所を明確に特定して改善設計できる
ソースを解析し、実装手順やテストケースまで情報を繋げて生成する
タスク管理をAIが行い、プロジェクト進行のサポートをする

AIは、渡した情報の質に応じて、役割を変える。

渡した情報の質に応じて 「変わってしまう」 以上、渡すこちら側も 「訳がわかっている」 ことが大事だとわかりました。

　
そして、開発環境をいうものを構築しなくても、最近マイクロソフトから発表があった、「Vibe.PowerApps.com」「App Builder in M365 Copilot」を始め「Power Apps Code Apps」など、AIエージェントとの自然言語でのやり取りを通じて完全なアプリを構築できる未来がすぐそこに来ています。

この時、AIモデルが進化して推論の精度がさらに上がったら、「訳わかっていなくても」 自律してくれるようにさえ、なるかもしれませんが...。

AIがすべてを自律的に完結させる未来は、すぐそこまで来ている。

でもその未来に向かう今のフェーズは、開発と理解と試行錯誤が共存していて、我々にとって最も面白い過渡期 なのかもしれないなと思うのと同時に、今のところ 一番面白いところを捨てたくはないなと。

まとめ

AIが完全に自律できる未来に向かっている今の過渡期において
AIを「共同開発者」として認識すると、開発スタイルは変わる
AIに渡す「情報の質」で「役割や振る舞い」が変わる
そのためには、情報を渡す側の人間が、わかっている必要がある
そもそもわかっている状態になるためにおいても、AIと共同で学習できる可能性がある

最後に：同じ場所にいる人へ

もしあなたが非エンジニアでPower Appsを触り始めたところなら、まずAIにこう聞いてみてもらうといいかもしれません。

Power Appsアプリ開発の初心者なんですが、開発を効率的に進められる環境を
どう構築したら良いか、一緒に考えてください。

たった一人でアプリがきちんと出来上がるか？不安になりながら独学する必要はなく、「パートナー」としてAIを頼ることができるかと思います。

Claude Opus 4.5の回答

まず、いくつか確認させてください。
1. 現在の状況について

普段のお仕事ではどんなツールを使っていますか？（Excel、SharePoint、Teamsなど）
作りたいアプリのイメージはありますか？（データ入力、承認フロー、レポートなど）
会社でMicrosoft 365は使えていますか？

2. 「効率的な環境」で気になるポイントは？

コードを書く場所や方法？
バージョン管理？
チームでの共同開発？
それとも、まずは学習しやすい環境？


とはいえ、一般的な初心者向けの出発点としては：
最小構成でスタートする

Power Apps Studio（ブラウザ版）だけでまず1つ簡単なアプリを作ってみる
データソースはSharePointリストかExcel（OneDrive上）から始める
最初は「キャンバスアプリ」がおすすめ（UIを自由にデザインできるので、デザイナーの方には馴染みやすいはず）

慣れてきたら追加で検討

ソース管理（Git連携）
外部エディタでのYAML編集
Power Automate連携

まずは何を作りたいか教えていただけると、より具体的なアドバイスができます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up