Power Platform のローコードは行を作れる。多対多の繋ぎは作れない

「ローコードでどこまでやれるか」——その境界は難しいかどうかではなく、操作の種類で決まる。行の作成・更新・読み取りはローコードの射程内。多対多の関連付け（所属・権限割り当て）だけは、通常のローコード操作では届かない。Patch 関数での直接書き込みは構造的に不可で、専用の Relate アクションを使うにはプレミアムライセンスと制限の確認が前提になる（2026 年 7 月時点）。

難易度ではなく、操作の種類で境界を引く

Power Platform で業務ロジックを組むとき、ほとんどの処理はローコードで通る。Patch 関数でレコードを作成・更新し、Filter 関数で読み取り、条件分岐で制御する——これは難易度の問題ではなく、標準の道具が揃っているということだ。

壁になるのは多対多の「繋ぎ」だ。

比喩にすると：付箋に文字を書く・書き直す・読むことは自在にできる。このカードとあのカードを糸で結ぶ——多対多の関連付け——だけは、道具箱に入っていない。

Dataverse（マイクロソフトのクラウドデータプラットフォーム）の多対多関係には交差テーブル（junction table：テーブル間の関連を管理する中間テーブル）が存在するが、Canvas Apps の Patch / Collect 関数からは内部管理テーブルとして直接露出していない。Microsoft Learnのドキュメントには “the intersecting table is not available to use directly”（交差テーブルは直接使用できない）と明記されている。

覚え方：作れる・直せる・読める。ただ、繋げない（通常操作では）。

「できない」と「制限付きで可能」は別の話

Patch 以外の手段として、Relate / Unrelate という専用の関数・アクションが用意されている。ただし、使える範囲は限られている。

設計判断として押さえておきたいのは 2 点。

Power Automate の Relate rows は GA だが、Dataverse コネクター（プレミアムコネクター）が必要。Power Automate Premium ライセンスなしでは使えない。「専用のアクションがある」と知っただけで採用を決めると、ライセンスコストが設計後に発覚する。

Canvas Apps の Relate 関数はプレビュー段階が続いている。2019 年の導入以来、2024 年 3 月時点でも Preview 扱いだ。オフラインモードでは使えず、アプリ設定のフラグを有効にする必要がある。本番採用の判断は、現時点の制約を確認した上で行う。

繋ぎが一点で止まると、連鎖が全部止まる

「繋ぎだけできない」は小さな制約に見えて、影響は広い。所属も権限割り当ても、データ構造上は「繋ぎ」だからだ。

組織の改編を例にすると——廃止するチームのメンバーを引き取り先に移すには、レコードの所有権移行・ロールの再割り当て・チームの削除が連鎖する。その中に「繋ぎの操作」が一つでも含まれていれば、そこだけローコードで処理できず、廃止処理が一点で止まる。

これが要の一針の構造だ（要の一針：他のすべてを支える一か所の縫い目、の意）。行の操作をすべてローコードで通せても、繋ぎの一点が通せなければ完結しない。

→ ローコードとプロコードの役割分担を全体像で把握したい場合：ローコードとプロコードを分けて使う、4 つの設計スタイル

繋ぎ「だけ」を小さなコードに任せる

答えは「全部プロコードで書き直す」ではない。

繋ぎが要るのは所属と権限割り当ての 2 種類で、残り（レコードの生成・改名・階層の追従・廃止判定）はローコードのまま通る。境界の引き場所は「難しいところ」ではなく「繋ぐところ」だ。繋ぎだけを担う小さなコード（Azure Functions 等）を用意すれば、ローコード側の処理はそのままで機能する。

直接呼ばず、書いて発火させる

繋ぎコードをどう起動するかも設計の核心だ。ローコードから直接呼び出す設計は、呼び出し経路に依存が生まれてメンテナンスコストが上がる。

代わりに使えるのが「書いて発火させる」パターンだ：

1. ローコード側が Dataverse テーブルに行を書き込む
2. Power Automate の「When a row is added, modified or deleted」トリガーが変更を検知する
3. トリガーが Azure Functions 等のプロコード側を起動し、繋ぎ操作を実行する

ローコードとプロコードが直接依存せず、データの変更だけで連携する。Microsoft 公式の integration patterns（event-driven architecture）に相当する推奨パターンとして確認されている。

このパターンにも Dataverse コネクター（プレミアム）が必要で、Power Automate Premium ライセンスが前提になる。Relate rows を使うパターンも、書いて発火させるパターンも、どちらもライセンスの確認が先になる。

Power Automate 内のフロー疎結合設計（子フロー・変更コストの関係）はPower Automate の疎結合設計で詳しく扱っている。繋ぎが欠けると連鎖処理が止まるシナリオの具体例はバルク処理には受け取り側も必要だを参照してほしい。

まとめ

ローコードの境界は難易度ではなく操作の種類にある。行は作れる、直せる、読める——多対多の繋ぎだけは、通常の操作では届かない。専用手段はあるがプレミアムライセンスとプレビュー段階の制約がついてくる。繋ぎの一点にだけプロコードを疎結合で足す設計が、最小かつ保守しやすい構成だ。

次の一歩：使っている Power Platform のライセンスが Premium かどうかを確認する。Relate rows アクションと Dataverse トリガーはどちらも Dataverse コネクター（プレミアム）が必要なため、ライセンスの確認が設計の出発点になる。その上で、Microsoft の integration patterns ガイドで推奨パターンを確認してほしい。

本記事の境界は非本番の検証環境で確認したもので、使用したローコード拡張にはプレビュー段階の要素を含む。製品や構成によって射程は変わりうるため、本番採用は各社要件での確認を前提としてほしい。

関連記事

• ローコードとプロコードを分けて使う、4 つの設計スタイル
• Power Automate の疎結合設計：子フローと変更コストの関係
• バルク処理には受け取り側も必要だ