この記事でやりたかったこと
環境もプロジェクトも変わるのに、AI 駆動開発の「準備」だけは毎回まったく同じことをやっている。あれを 1 回にしたい。
Power Platform（Power Automate、Dataverse、Copilot Studio など）を AI に手伝わせる公式のスキルやプラグインは、かなり充実してきました。ところが新しいリポジトリを切るたび、私は同じことを繰り返していました。
- どのプラグインを入れるんだったか思い出す
- 前のプロジェクトから
.mcp.jsonをコピーして、自分のテナントの値が紛れていないか目で追う -
AGENTS.mdを書き直す。前回どう書いたか覚えていないので、プロジェクトごとに少しずつ違うルールができる - そして前に踏んだのと同じ落とし穴をもう一度踏む
3 つ目まではまだ我慢できます。4 つ目がつらい。学びがどこにも溜まっていないからです。
もうひとつ、Claude Code・Codex・GitHub Copilot CLI を気分で使い分けているのも大きいところでした。準備の手間がそのまま 3 倍になるうえ、設定の書き方も確認方法もクライアントごとに違う。放っておくと「Claude では止めていたはずの操作が、Codex では素通り」になります。
そこで、準備を 1 回で済ませる置き場と、踏んだ学びが溜まる置き場を、同じ 1 つのリポジトリにまとめました。minoru365/PPDevStandard（MIT）です。
準備を「3 つの層」に分けた
いちばん効いたのは、準備を頻度で 3 層に割ったことでした。混ぜていたから毎回全部やり直していたわけです。
| いつやるか | やること | どこでやるか |
|---|---|---|
| PC ごとに一度だけ | AI クライアント、公式プラグイン、.NET / Node.js を用意する。Dataverse を使うならローカルで開発環境へ接続する | 自分の開発 PC |
| 新しいリポジトリごと | 共通設定をプレビューして適用し、正本・開発環境・検証方法・承認条件を書く | 対象リポジトリ |
| AI に作業を頼むたび | 対象・影響・検証方法を確認してから、調査 → 変更 → 検証する | 対象リポジトリと開発環境 |
真ん中の機能台帳（1 個の JSON ファイル）が全部の層の根拠です。そして ③ から台帳へ太い矢印が戻っている。ここが無いと、手順をいくら整えても同じ穴に落ち続けます。
層 ①：PC ごとに一度だけ
普段使うクライアントを 1 つ選べば十分です。あとから増やしても、プロジェクトのルールは共有できます（層 ② の話）。
Claude Code と GitHub Copilot CLI は marketplace 経由で入ります。
/plugin marketplace add microsoft/power-platform-skills
/plugin install canvas-apps@power-platform-skills
/plugin install power-automate@power-platform-skills
Codex は開発者プロファイルの Plugins から同じ公式パッケージを入れます。どのパッケージをどのクライアントに入れるかは台帳に書いてあるので、思い出す必要はありません。
そのうえで、ローカルの前提だけを確認します。
$client = 'codex' # codex / claude-code / github-copilot-cli
$capability = 'all' # all / canvas-apps / code-apps / power-automate-flowagent / dataverse / copilot-studio / power-cat
pwsh -NoProfile -File scripts/check-prerequisites.ps1 -Client $client -Capability $capability
やるのはコマンドの有無と最低メジャーバージョンの確認だけで、導入も MCP 接続も認証もしません。「確認のつもりで環境を触る」のがいちばん怖いので、意図的に絞っています。
💡 前提はだいたいここで引っかかります。Canvas Apps と PAC の MCP は .NET 10 以上、FlowAgent・Copilot Studio・Power CAT は Node.js 18 以上、GitHub Copilot CLI 自体は Node.js 22 以上。バラバラなので暗記は諦めて台帳に持たせました。
層 ②：新しいリポジトリごと
ここが「毎回やっていた作業」の本体です。まずプレビューします。
$targetPath = 'C:\work\my-power-platform-project' # 対象リポジトリ
$clients = 'all' # codex / claude-code / github-copilot-cli / all
$capabilities = 'canvas-apps' # all / canvas-apps / code-apps / ...
pwsh -NoProfile -File scripts/initialize-project.ps1 `
-TargetPath $targetPath `
-Client $clients `
-Capability $capabilities
この時点ではまだ 1 ファイルも作りません。出力の would create は「これから作る予定」、manual merge required は「同名ファイルがあるので上書きせず自分で統合して」の意味です。納得できたら、同じコマンドの末尾に -Apply を足します。-Apply が唯一の書込みスイッチで、既存ファイルは絶対に上書きしません。
作られるのは 4 つです。
| ファイル | 役割 | 最初にすること |
|---|---|---|
AGENTS.md |
AI が読む共通のプロジェクトルール | 正本・開発環境・検証・承認条件を書く |
docs/AI_DEVELOPMENT_TOOLING.md |
導入と運用のガイド | チームへ共有する |
.mcp.json |
Claude Code / Copilot CLI 用の MCP 設定 | 接続先や資格情報が入っていないことを確認 |
.codex/config.toml |
Codex 用の設定 | Codex を使う場合だけ確認 |
MCP 設定の中身はクライアントで違います。たとえば Canvas Authoring の MCP は、Claude Code と Copilot CLI では公式プラグイン側から提供されるので書きませんが、Codex には書き出します。この手の差分を毎回思い出す作業が消えたのが、地味にいちばん嬉しいところでした。
指示ファイルは 1 か所にだけ書く
同じルールを 3 つのクライアント用ファイルにコピーすると、必ずずれます。正本・環境・検証・承認条件はリポジトリの AGENTS.md に一度だけ書き、クライアント専用ファイルはそのクライアントにしかない補足だけにします。
| クライアント | 個人（全リポジトリに効く） | リポジトリ（チームで共有） |
|---|---|---|
| Codex | ~/.codex/AGENTS.md |
AGENTS.md |
| Claude Code | ~/.claude/CLAUDE.md |
CLAUDE.md または共通の AGENTS.md
|
| GitHub Copilot CLI | ~/.copilot/copilot-instructions.md |
.github/copilot-instructions.md と共通の AGENTS.md
|
読み込まれているかの確認方法も違います。Claude Code は /memory、Copilot CLI は /instructions、Codex は新しいセッションで「いまの指示を要約して」と頼む。
層 ③：AI に作業を頼むたび
スクリプト必須にしたら、遅くなった
安全側に倒すなら「クラウドは直接触らせない、すべて Git 管理のスクリプト経由」が簡単です。やってみて、試行の速度が落ちました。フローの形を 1 つ確かめたいだけでもスクリプトを書いてレビューして実行する必要がある。AI を入れた意味が薄れます。
そこで MCP とスクリプトを、競合する手段ではなく用途の違う二レーンとして整理しました。
| モード | 何をするか | クラウドを直接触ってよいか | 正本の扱い |
|---|---|---|---|
| 探索・試作 | 開発環境で、新規・一時的なフローやエージェントを AI に直接作らせて検証する | よい（新規かつ一時的なものに限る） | クラウドの試作は「作業中の根拠」であって正本ではない |
| 採用・運用 | 共有する、継続保守する、複数環境へ展開する、業務に影響する | だめ。Git 管理の正本を経由する | Solution / YAML / スクリプトを正本にし、差分レビュー後に適用 |
そして昇格（試作 → 正本）の契機を先に決めておきます。再利用する / 他人と共有する / 長期保守に入る / 複数環境へ展開する / 外部への副作用が出る / データまたはセキュリティに影響する。どれかを踏んだ瞬間に、定義・接続参照・依存関係・検証結果を正本へ書き写す。
💡 これは Power Platform に限らない話でした。「AI に直接やらせていいのはどこまでか」を操作の種類で線引きすると必ず破綻します（読み取りだって環境を間違えれば事故る）。**「その成果物を後で誰かが再現する必要があるか」**で切ると、線が引けました。
させないこと（3 つだけ）
AGENTS.md に書くのは実質これだけです。
- Dataverse は読取りを既定にする。 メタデータ確認とクエリは自由。既存の管理対象データの変更・削除・ロール変更・環境変更・Solution の import / publish は、対象と影響を示した明示承認のあとだけ。
- AI が作った新規フローは停止状態で作る。 定義の検証と接続参照のレビューを通してから、承認を得て有効化する。接続は自動作成させず、既存 Solution の接続参照を優先する。
- 既存資産を AI の生成結果で直接置き換えない。 採用する試作は、レビュー済みのスクリプトか Solution 成果物に反映してから適用する。
学びが溜まる場所にする
準備を自動化しても、同じ落とし穴を踏み直す問題は解けません。README に散文で書き足すと、すぐ埋もれるからです。そこで、機能ごとに機械が読める形で持つことにしました。1 件を必ず 3 項目で書きます。
| 項目 | 何を書くか |
|---|---|
trigger |
どういうときにこれを読むか（症状ではなく状況） |
symptom |
何が起きるか。なぜ紛らわしいか |
resolution |
どうするか。回避策なら回避策と明記する |
ポイントは、まだ記録が無い機能も空リスト [] を明示すること。「書き忘れ」と「まだ無い」が区別できます。
台帳を正本にすると、README もスクリプトも台帳に従う形になるので、整合性を CI で見られます。回しているのは 2 つだけです。台帳自体の整合性チェックと、一時ディレクトリで初期化スクリプトを実行する回帰テスト（秘密情報の混入も機械的に検査します）。
AI に「まず公式ドキュメントを引かせる」
台帳にはもう 1 つ、Microsoft Learn の MCP を標準の読み取り専用の知識源にするというルーティングを書きました。認証もテナント URL も要りません。
Power Platform は仕様も制限も変わります。AI の記憶で答えさせると、もっともらしく古い制限を語る。「公開仕様を知る道具」と「自分の環境を知る道具」を分けて指示する、というだけの話ですが、書いておかないと AI は平気で混同します。
上流だけでは埋まらなかったところ
私が参照しているのは、Geek Fujiwara氏のCodeAppsDevelopmentStandard と、Microsoft 公式の Power Platform Skills / Dataverse Skills / Copilot Studio Skills / Power CAT Skills です。Geek 氏の標準は Code Apps を中心に、Dataverse、Power Pages、Generative Pages、モデル駆動アプリ、Power Automate、Copilot Studio、AI Builder まで広く扱っていて、公式プラグインはそれぞれの製品機能を深く実装しています。足りなかったのは上流の製品知識ではありません。 むしろ逆で、同じものを自分で書き直す理由がどこにもありませんでした。
足りないのは、それを自分の環境で回すための情報のほうでした。
| 層 | 誰が持つのが自然か | 担うもの |
|---|---|---|
| 製品スキル・プラグイン | 上流・公式配布元 | 製品機能の実装と更新 |
| overlay（今回作ったもの） | 使う側の個人・チーム | 機能台帳、クライアント対応、設定テンプレート、初期化、前提確認 |
| 個別プロジェクト | プロジェクトチーム | 正本、Solution、YAML、CI/CD、本番承認 |
真ん中が空いていた、というだけの話です。空いていた理由は 3 つあります。
① クライアント差分は、上流が持てる情報ではない。 公式プラグインは各クライアント向けに配られていますが、「自分の PC の、そのクライアントの、そのバージョンで実際に動いたか」は使う側にしか分かりません。さきほどの powercat-dataverse が Skills 0 だった件がまさにこれで、上流の不具合ではなく組み合わせの問題です。上流に書いておけと言うのは筋が違います。
② 組織固有の判断は、上流に書くべきではない。 どの環境なら触ってよいか、誰が公開を承認するか、正本はどこか。テナント権限もセキュリティ基準も既存資産も組織ごとに違います。ここを上流の標準に持ち込むと、むしろ標準のほうが使いにくくなります。
③「どれを採ってどれを採らないか」は、組み合わせる側にしか決められない。 配布元は 5 つ以上あって、それぞれ自分の領域では正しい。実験段階と明記されているものを標準構成に入れるか、同じ領域に候補が 2 つあるときどちらを既定にするか——この判断は、上流のどこにも書きようがありません。
上流へ返すもの、手元に置くもの
ここを曖昧にすると、overlay はただの「上流への不満置き場」になります。なので分類を先に決めました。
| 見つけたもの | 行き先 |
|---|---|
| 誰の環境でも再現するバグ、ドキュメントの誤り、宣言漏れの前提 | 上流へ Issue / PR |
| 自分のテナント権限、承認者、正本の場所 | 手元の overlay（上流に置くべきではない） |
| クライアント × バージョンの動作確認 | 手元の overlay（ただし再現するなら上流にも報告する） |
ただ、分類を決めただけでは動きませんでした。上流へ返すつもりの候補を 2 件も溜めたままにしていて、いざ検証したら片方は上流の問題ですらなく、こちらの使い方の誤りでした（上流のスクリプトが「対象外」と明記している用途に使っていた）。手元に書いた時点で分かったことにして、相手の現物を見に行っていなかったわけです。残る 1 件は再現を取ってから Issue にしました。overlay は、上流へ返す作業を先送りする言い訳にもなれてしまう。
上流は置き換える対象ではなく、乗る土台です。overlay が薄いままでいられるのは、土台のほうが厚いからでした。
まとめ
- 準備を頻度で 3 層に割る。 PC ごとに一度だけ / 新しいリポジトリごと / 作業を頼むたび。混ぜていたから毎回全部やり直していました。
- 層ごとの根拠を 1 つの台帳に集める。 どのパッケージを入れるか、前提バージョンはいくつか、どのクライアントで確認できたか。思い出す作業が消えます。
- 踏んだ学びを、散文ではなく機械が読める形で台帳に書き戻す。 空なら空と明示する。この「戻りの矢印」が無いと、手順を整えても同じ穴に落ち続けます。
- 自分が持つのは、空いている真ん中の層だけにする。 製品スキルは上流が厚く、組織固有の判断はプロジェクトが持つ。使う側が持つべきは「自分の環境で回すための横の情報」だけでした。
以前、5つのAIに「共通の記憶」を持たせてみたで「AIは取り替えのきく道具、記憶だけは自分の資産」と書きました。開発環境でも同じでした。
クライアントもプロジェクトも環境も入れ替わる。積み上がるのは、準備の型と、踏んだ穴の記録だけです。 それを 1 か所に置いておけば、次のプロジェクトは「準備」からではなく「作業」から始められる。明日出てくる新しい AI クライアントにも、同じ紙を 1 枚渡すだけで済みます。