はじめに
2026年9月、Power Platformで取引先台帳アプリ PartnerLedger を作りました。取引先・担当者・契約・名刺を1か所で管理し、会社名や取引状態のような大事な変更は、承認を通してから反映するアプリです。
作った動機は、業務アプリそのものと同じくらい、Dataverse と Power Apps Code Apps を使うメリットを、実際に動くアプリで示して広めたいということにありました。
- Dataverse：セキュリティロール・所有者・チーム・共有といった標準のアクセス制御を使えば、「誰が見てよいか」「誰が変えてよいか」を、アプリごとに作り込まずにプラットフォームへ任せられる
- Code Apps：Entra IDの認証、Dataverseへの接続、ホスティング、DLPや条件付きアクセスといったPower Platformの標準の恩恵を受けたまま、React + TypeScriptで柔軟でモダンな画面を作れる
この2つを組み合わせると、「ローコードの手軽さか、コードの自由度か」の二択ではなく、ガバナンスは標準に任せ、画面は自由に作るという分担ができます。この記事では、PartnerLedgerでその分担をどう実現したかを紹介します。
そしてもう1つ、もっと身近な動機もありました。机の上に山積みになった名刺を、なんとかしたい。
交換した名刺は、その場では大事なのに、あとで台帳へ入力する手間が重くて、つい引き出しや名刺入れに溜まっていきます。気づけば「あの会社の担当の人、名刺はどこだっけ」となり、せっかくの接点が誰にも共有されないまま眠ってしまう。PartnerLedgerでは、名刺の画像をまとめて選ぶだけでAIが読み取り、人は確認して確定するだけ、という流れを作りました。
これまで、意思決定支援システム DecisionFlow でも同じ考え方で開発してきました。
PartnerLedgerはDecisionFlowに続く2作目です。DecisionFlowが「判断」を支えるアプリだとすると、PartnerLedgerはどの会社にもある「台帳」の業務で、同じ考え方が通用するかを確かめたアプリでもあります。
ソースコード、マネージドソリューション、手順書は、MITライセンスでGitHubに公開しています。
まずは動画で
取引先・名刺・契約・承認の流れを紹介した動画を、PLUG Channelで公開しています。
PartnerLedgerでできること
| 機能 | できること | うれしい場面 |
|---|---|---|
| 取引先・担当者・契約の台帳 | 会社・人・契約を登録し、一覧で検索・並べ替えできる。担当者は必ず取引先マスタに所属させ、会社名の自由入力はさせない | 「この会社の担当は誰だっけ」「どの契約がいつ切れる？」をすぐ引きたい |
| 取引先ごとの共有設定 | 取引先単位で、誰が閲覧・編集できるかを個人・グループに設定できる | 部署や案件によって、見せてよい取引先が違う |
| 変更の承認 | 会社名・取引状態・主担当、契約の更新・終了判断などは「変更申請」になり、承認されると自動で反映される。どの項目に承認が必要かは管理者が切り替えられる | 大事な情報を、誰かが勝手に書き換えないようにしたい |
| 名刺から登録 | 名刺の画像をまとめて選ぶと、AI Builderの名刺リーダーが1枚ずつ読み取る。人が確認して確定するまで正式登録しない | 机に山積みの名刺を、手入力せずに台帳へ入れたい |
| 期限と滞留の通知 | 期限が近い契約や、処理されずに残っている名刺を毎朝メールで知らせる | 解約通知期限を過ぎてから気づく、を防ぎたい |
| 掲示板 | 取引先・担当者ごとに、見られる人どうしで連絡事項を書き込める | 「先週この会社から連絡があった」を台帳に残したい |
画面はPower Apps Code Apps（React + TypeScript）の1本だけです。PCでもスマホでも、同じアプリをブラウザで開いて使います。
構成：標準に任せたこと、自分で書いたこと
PartnerLedgerで一番大事にしたのは、プラットフォームが標準で持っているものは作らないことです。
| 標準に任せたこと | 使った標準機能 |
|---|---|
| サインインと利用者の特定 | Code AppsのMicrosoft Entra ID認証 |
| どの行を読める・変えられるか | Dataverseのセキュリティロール、所有者、チーム、共有 |
| グループ単位の権限 | Entraグループに紐づくDataverseのグループチーム |
| 承認依頼と応答 | Power Automateの承認（Teams・Outlook・承認センター） |
| 名刺の読み取り | AI Builderの名刺リーダー |
| 別の環境への配布 | マネージドソリューション（アプリ・テーブル・ロール・フロー・Pluginをまとめて移送） |
| 自分で書いたこと | 理由 |
|---|---|
| 画面（React + TypeScript） | 業務に合わせた使いやすさは、ここで作り込む |
| 最小の同期Plugin | 「承認が必要な項目は直接書き換えさせない」「承認者グループの共有は外させない」など、標準のロールや共有だけでは表せない業務ルールを守る |
PartnerLedger独自のCustom APIは、1本も作っていません。開発の途中では5本ありましたが、すべて標準の行操作と同期Pluginへ置き換えました。画面は標準のCRUDを呼ぶだけで、「その操作をしてよいか」はDataverseとPluginが判断します。
1. アクセス制御は、Dataverseの標準に任せる
台帳アプリで一番難しいのは、画面ではなく「誰に何を見せるか」です。取引先ごとに見せてよい相手が違い、担当者が替わり、異動もあります。これをアプリの中で作り込むと、画面を1つ増やすたびに権限チェックを書き足すことになり、どこか1か所で漏れます。
PartnerLedgerでは、この判断をすべてDataverseの標準のアクセス制御に任せました。
画面に「見せない」コードを書かない
取引先の一覧を取得するコードには、権限で絞り込む条件がありません。条件は「有効な取引先」だけです。
// 取引先一覧の取得（Code Appsが生成した型付きサービスを呼ぶだけ）
listPartners: async () => asOperationResult(await Pl_partnersService.getAll({
select: partnerDirectorySelect,
filter: partnerDirectoryActiveFilter, // 有効な行だけ。権限の条件は書かない
orderBy: ['pl_name asc'],
maxPageSize: 100,
})),
それでも、利用者には自分がアクセスできる取引先だけが返ります。Dataverseが、サインインした本人のロール・所有・チーム・共有を合わせて、読める行だけを返すからです。一覧も、検索も、名刺から既存の取引先を探す候補も、同じ仕組みで自動的に絞られます。
これは画面の外でも同じです。Web APIを直接呼んでも、同じ本人の権限で評価されます。実際に、一般利用者の権限で直接APIを呼ぶ確認も行い、画面で見えない行は読めず、許されていない操作は拒否されることを確かめました。
「画面が隠しているから見えない」のではなく、「Dataverseが渡さないから見えない」。この違いが、画面を何枚増やしても権限が漏れない理由です。
職位はロールで、取引先ごとの例外は共有で
Dataverseの権限は、セキュリティロール（職位ごとの共通権限）と、行ごとの共有（個別の例外）を組み合わせて決まります。PartnerLedgerもこの2層で設計しました。
ロールは4つに絞りました。最初は7つありましたが、使う人の立場で整理しています。
| ロール | 用途 |
|---|---|
PL 利用者 |
許可された取引先・担当者・契約・名刺の通常操作と、自分の申請 |
PL 承認 |
全申請の閲覧と承認業務 |
PL システム保守 |
移送後の接続設定、OCR・通知・再処理の保守 |
PL システム管理 |
契約種類、承認対象、管理者による取消などの設定 |
PL 利用者 は、取引先を全件は読めません。自分が登録した取引先と、共有された取引先だけです。どの取引先を誰に見せるかは、取引先ごとの共有で決めます。
グループの管理は、Microsoft 365側に任せる
承認者はMicrosoft 365グループで管理し、Dataverseのグループチームに紐付けています。グループチームにロールを割り当てておけば、承認者の追加・異動・退任は、Microsoft 365グループのメンバーを変えるだけです。PartnerLedgerの中に「承認者の一覧」を持つ必要がありません。
取引先の共有先にも、個人のほか、セキュリティグループやMicrosoft 365グループを選べます。会社で普段使っているグループを、そのまま台帳の権限に使えます。
標準の共有に、業務ルールを少しだけ足す
標準の共有だけでは表せないルールもあります。そこだけを同期Pluginで補いました。
新しい取引先を登録すると、その場でサーバーが次の共有を付けます。
- 承認者グループへの閲覧。この共有は誰も外せない
- 主担当が登録者と別の人なら、主担当への編集
登録した人は所有者なので、最初から閲覧・編集できます。以前は「承認者がアプリで初期共有を設定する」手順がありましたが、登録と同時にサーバーが完了させることで、手順ごと無くしました。
共有を管理できる人にも、制限を設けています。
| 許可すること | 許可しないこと |
|---|---|
| 自分がアクセスできる取引先への共有の追加・変更・取消 | 自分が持っていない権限を人に付けること |
| 自分と同じか低い共有の変更・取消 | 閲覧だけの人が、編集の共有を外したり閲覧へ下げたりすること |
| 個人・セキュリティグループ・M365グループへの共有 | 承認者グループの共有を外すこと、グループ自体の作成・メンバー変更 |
ここでも、共有そのもの（誰がどの行を読めるか）はDataverseの標準の共有です。Pluginが足しているのは「この共有の変更を許してよいか」という業務ルールだけです。
標準に任せるときの注意点
メリットばかりではなく、Dataverseの権限には守るべき性質もあります。
-
権限は足し算で効く。ロール・チーム・共有のうち、最も広いアクセスが勝つ。組織全体の閲覧を一度与えると、特定の行だけ隠すことはできない。だから
PL 利用者には全件の閲覧を与えず、共有で広げる設計にした。保守用のロールを一般の利用者に付けないことも手順書に書いている - 共有は例外のために使う。Microsoftの公式ドキュメントでも、共有は多用しすぎると性能やトラブルシューティングに影響するとされ、個人よりチームへの共有が効率的とされている。PartnerLedgerでも、承認者はグループチームで扱っている
参考：Dataverseのセキュリティの概念、グループチームの管理
2. Code Appsで、標準の恩恵を受けたままモダンな画面を作る
アクセス制御を標準に任せられるなら、画面は自由に作りたい。そこで選んだのが Power Apps Code Apps です。
標準のまま受け取れるもの
Code Appsは、Visual Studio Codeなどでコードとして書いたWebアプリを、Power Platform上で動かす仕組みです。公式ドキュメントでは、主な特長として次が挙げられています（Code Appsの概要）。
- Microsoft Entra IDによる認証・認可
- Power Platformのデータソースと1,500以上のコネクタを、JavaScriptから直接呼べる
- 業務用Webアプリを、Power Platformで簡単に公開・ホストできる
- 組織のマネージドプラットフォームのポリシー（アプリの共有制限、条件付きアクセス、DLPなど）に従う
- デプロイとALM（アプリケーションのライフサイクル管理）が簡単
PartnerLedgerで具体的に助かったのは、次の点です。
| Code Appsの標準 | PartnerLedgerで作らずに済んだもの |
|---|---|
| Entra IDの認証 | ログイン画面、トークンの取得・更新、独自のHTTP認証 |
| Dataverseを追加すると生成される型付きサービス | APIクライアント、テーブルごとの型定義 |
| Power Platformでのホスティング | Webサーバー、証明書、デプロイ先の管理 |
| 共有制限・条件付きアクセス・DLP | アプリ独自の利用制限 |
| ソリューションへの格納 | アプリだけ別の手順で配布する仕組み |
たとえばDataverseのテーブルをデータソースとして追加すると、Pl_partnersService や Pl_contractsService のような型付きのサービスが生成されます。PartnerLedgerでは14のカスタムテーブルとユーザー・チームに対して生成し、画面からはこれを呼ぶだけです。列名を間違えれば、TypeScriptの型チェックで気づけます。
そして何より、前章のDataverseのアクセス制御が、そのまま効きます。生成されたサービスはサインインした本人としてDataverseを呼ぶので、画面側で権限の仕組みを持つ必要がありません。
画面は、普通のReactアプリとして自由に作れる
画面の中身は、React 19 + TypeScript + Viteの普通のWebアプリです。
- 取引先の詳細は、基本情報・契約と期限・掲示板・共有設定のタブで切り替えるモーダル
- ヘッダーから取引先・担当者を横断で検索し、候補から詳細を開く
- 明るい表示・暗い表示・端末の設定に合わせる、の切り替え
- 画面幅に合わせてレイアウトを変え、スマホ（幅390px）でも崩れない
- 保存中・送信中は、どの画面でも同じ待機表示を出す
Canvasアプリでも多くのことはできますが、こうした画面の細部や、部品の使い回し、テストのしやすさは、コードで書けるCode Appsの強みです。画面のロジックはVitestでテストし、型チェック・lint・ビルドと合わせて npm run check 1回で確認しています。
「ローコードかプロコードか」ではなく、ガバナンスと基盤はPower Platformの標準、画面の体験はコード。これがCode Appsで得られる一番のメリットだと考えています。
知っておきたい前提
一方で、Code Appsを使う前に確認しておくべき前提もあります。
- 環境の設定で、Code Appsを有効にする必要がある
- 利用者には、Power Apps Premiumライセンス（または従量課金・App Passなど）が必要
- Power Platform Git統合など、まだ対応していない機能もある
最新の条件は、公式のCode Appsの概要で確認してください。
3. 山積みの名刺を、「確認するだけ」の作業に変える
名刺の登録は、PartnerLedgerを作ったきっかけの1つです。溜まる原因は、1枚ずつ手で入力する重さにあります。そこで、入力はAIに任せ、人は確認だけする流れにしました。
まとめて選んで、あとは待つだけ
- 名刺の画像を一度に20枚まで選べる。撮った写真を選ぶだけなので、スマホで撮ってその場で登録してもよいし、あとでPCからまとめて入れてもよい
- 読み取りはAI Builderの名刺リーダーが1枚ずつ順番に行う。途中の1枚が失敗しても、後ろの名刺は止まらない
- 同じ画像を二重に送っても、読み取りや登録候補が重複しないようにしている
AIの結果を、そのまま台帳に入れない
名刺の読み取りは便利ですが、社名の表記ゆれや読み間違いは起きます。そこで、人が確認して「確定する」を押すまで、正式な取引先・担当者にはしないことにしました。確認画面では、読み取った内容を直してから登録できます。
確定するとき、自分が見られる取引先に同じ会社があれば、「既存の取引先に担当者として追加」が選ばれた状態で候補が出ます。見つからなければ、新しい取引先を「未承認」として登録します。名前が同じでも自動でまとめることはせず、どうするかは確認した人が選びます。
ここでも、1章のDataverseのアクセス制御が効いています。既存の取引先の候補には、自分がアクセスできる取引先しか出ません。名刺の登録画面のために特別な権限チェックを書いたわけではなく、Dataverseが本人の見られる行だけを返すからです。名刺をきっかけに、見てはいけない会社の存在を知ってしまうこともありません。
溜まったら、知らせる
それでも確認が後回しになることはあります。受け付けてから3日たっても処理されていない名刺は、毎朝のメールで知らせます。メールのリンクから、その名刺の確認画面を直接開けます。
「読み取る」「確認する」「思い出させる」をそれぞれAI Builder・Code Appsの画面・Power Automateに分担させることで、名刺が引き出しで眠る前に、台帳の中で共有される情報に変わります。
4. 承認は「承認された」と「反映された」を分ける
承認の仕組みも、独自に作らずPower Automateの**承認（Approvals）**を使いました。承認依頼は承認者グループのメンバー一人ひとりへ届き、OutlookのメールやTeamsの「承認」アプリから応答できます。誰か1人が応答すると結果が反映され、ほかの人の依頼は閉じます。
そのうえで一番気を使ったのが、承認されてから反映するまでの間です。
- 提出した内容は固定する。提出後に申請内容は書き換えられず、差し戻し後の修正は新しい版になる
- 反映の直前に再確認する。承認待ちの間に、申請した項目そのものが別の操作で変わっていたら、古い申請の内容で上書きせず「反映失敗」にし、申請者にメールで理由を知らせる
- 同じ対象・同じ種類の申請は1件まで。Dataverseの代替キーで二重の申請を防ぐ。取り下げ・取消・期限切れになれば、すぐに出し直せる
- 21日間応答が無い申請は自動で取り消す。承認者が退職・休職した場合に備えて、管理者が理由付きで取り消す操作も用意した
承認依頼の件名と本文（申請者・対象・「変更前 → 変更後」・アプリへのリンク）は、提出時にサーバーが作ります。申請者が書き換えることはできません。承認者が見ている内容と、実際に反映される内容がずれないようにするためです。
5. 「完成」の定義を、まっさらな環境へのインポートにした
標準機能に寄せるもう1つのメリットは、ソリューションとして別の環境へ持ち運べることです。アプリ・テーブル・ロール・フロー・Pluginが、1つのマネージドソリューションに入ります。
この利点を本当に活かせているかを確かめるため、完了の定義をこう決めました。
未使用の新しい環境へマネージドソリューションをインポートし、手順書だけで設定して、決めておいたシナリオが通ること。
実際に英語ベースの新しい環境へインポートしてみると、開発環境では見えなかった問題がいくつも出ました。
| インポート試験で見つかったこと | どう直したか |
|---|---|
| 配布したzipの中に、開発者の表示名が入っていた | Pluginの実行ユーザー指定そのものを無くした（下の行） |
| Pluginの「実行ユーザー」を、インポート後に13か所手作業で設定する必要があった | 内部処理をSYSTEMの権限で行い、実行ユーザーの設定を不要にした。要求者の認可は、あくまで呼び出した本人の権限で先に確認する |
| 承認設定の行をDataverseで作る手順が、英語の環境では列が画面に出ず実行できなかった | 設定行が無いときは既定値で動き、管理者がアプリの設定画面から保存できるようにした |
| インポート画面の環境変数の入力欄に、名前が出なかった | 環境変数に英語の表示名と説明を付けた |
| チームIDの欄に、EntraグループのIDを入れてしまいがち | EntraグループのIDでも受け付けるようにした |
どれも「開発者が自分の環境で動かしているだけ」なら気づかないものでした。手順書を書き、それだけを頼りに別の環境へ入れてみて、初めて見えます。これらを直したうえで、改めて新しい環境への移送テストを行い、完了しました。
一方で、ロールの利用者への割り当てや、承認者グループとチームの紐付け、接続の作成は、移送先の環境ごとに行う作業です。これはDataverseのセキュリティの設計どおりで（ロールはソリューションで運べるが、チームや割り当ては環境ごと）、手順書に明記しています。
DecisionFlowへの依存も外した
最初の設計では、PartnerLedgerの申請をDecisionFlowへ送り、判断結果を受け取る予定でした。しかし、それではDecisionFlowが入っていない環境にPartnerLedgerを導入できません。
「連携できたら便利」より「単独で入る」ほうを優先し、DecisionFlowへの参照を撤去して、承認はPower Automateの承認で行う形にしました。DecisionFlowとの連携は、必要になったときに別の設計として追加します。
6. 作らないと決めたことも、設計の一部
期間内に「確実に動くもの」を出すために、いくつかの機能はあえて外しました。
| 外したもの | 理由 |
|---|---|
| スマホ専用のCanvasアプリ | Code Appをスマホのブラウザで使えば足りると判断。アプリが2本になると、同じ業務ルールを2か所で守ることになる |
| オフラインでの閲覧・登録 | 端末に残したデータを、権限や最新状態の根拠にしたくない。オンライン専用にし、権限の判断を常にDataverseに置く |
| 名刺からの重複候補の自動提示 | 初回リリースでは見送り。同じ名前の会社も登録でき、名前だけで自動統合はしない |
| アプリでのカメラ撮影 | 撮った写真を画像として選べば足りる |
一度作ったスマホ用Canvasアプリも、この判断で廃止しました。Code Appsの画面は幅に合わせて調整できるので、PCとスマホを1本のアプリで賄えます。守る場所を1か所にできたことのほうが大きいと感じています。
7. テストが緑でも、実機で初めて分かること
2026年9月28日時点で、Plugin（C#）のテストが615件、アプリのテストが293件あり、型チェック・lint・ビルドと合わせて通しています。それでも、実機では次のようなことが見つかりました。
- 共有先に選んだユーザーによっては、プラットフォーム側で共有が拒否される。Microsoftのサポート用アカウントのような通常以外のユーザーが候補に出ており、選ぶと拒否された。しかもアプリはそれを「あなたの権限が足りない」と表示していた。候補から通常以外のユーザーを外し、共有先側の理由による拒否は別の文言で出すことにした
- Power Appsのモバイルアプリでは、レコード作成の結果（ID）がアプリに返らないことがある。ブラウザでは起きない。作成後に代替キーで読み直す共通部品を作り、作成を行う8か所すべてに入れた
- 名刺の既存取引先の検索が、空白を含む社名でうまくヒットしない。E2Eの途中で見つけて修正した
どれも、純関数のテストやモックでは見つけられないものです。
「成果物ができた」と「意図どおりに動いた」は別の確認です。レコードができた、ソリューションが入った、は前者にすぎません。後者は、実際の利用者の権限で動かした結果だけが根拠になります。
特にアクセス制御は、管理者で確かめても意味がありません。管理者はたいてい何でも見えるからです。一般利用者のロールだけを持つアカウントで画面を操作し、見えてはいけない取引先が見えないこと、許されていない操作が拒否されることを、節目ごとに確かめています。
8. AIと一緒に作る
PartnerLedgerも、AIエージェントと一緒に開発しました。考え方の土台は、先に書いた次の記事にまとめています。
DecisionFlowのときと同じく、ベースにはGeek氏のCodeAppsDevelopmentStandardとMicrosoft公式の各種Skillsがあり、その上に独立したoverlayとして育てている PPDevStandard を重ねています。PartnerLedgerの画面設計の指針も、CodeAppsDevelopmentStandardのデザインの考え方（コンポーネントの再利用、レスポンシブ設計、一覧から詳細への導線）を、この台帳向けに絞り込んだものです。
Code Appsは普通のTypeScriptプロジェクトなので、AIエージェントがコードを読み、型チェックやテストで自分の変更を確かめられます。Dataverseのメタデータも公式のMCPやCLIで読めます。標準の仕組みに寄せたことは、AIと一緒に開発しやすいことにもつながりました。独自の仕組みが少ないほど、AIが公式ドキュメントを根拠に判断できるからです。
そのうえで、今回は次のことを意識しました。
正本をリポジトリに置き、どのAIからでも再開できるようにする
開発中は、要件・実装計画・引継ぎを、リポジトリ内の文書として1か所に置きました。複数のAIクライアントで作業しても、どれも同じ文書から読み始め、同じ文書へ書き戻します。特定のAIのメモだけに大事な判断を残さないのがルールです。公開リポジトリには、このうち要件と設計資料、そしてAIへの共通指示であるAGENTS.mdを含めています。
危ない変更は、先に表を書く
権限・共有・データ削除・並行処理に関わる変更は、実装の前に次の表を書き、表が書けないうちは実装を始めない、と決めました。
- 許可する状態と操作／拒否する状態と操作
- いつの時点の値で判定するか
- 競合・再試行・途中失敗が起きても守ること
- 自動テストで守ることと、人が実機で確かめること
- 変更する範囲／変更しない範囲
そのうえで「テストを先に書く → 範囲を固定して実装 → 機械的なチェック → 独立した監査を1回」の順で進めます。監査で設計の抜けが見つかったら、同じ論点で監査を繰り返さず、表とテストを直して計画からやり直します。
これは、以前別のアプリで権限ルールを直したとき、設計を固めずに実装を始めて「実装 → 監査 → 追加修正」を何往復もした反省から来ています。
クラウドの状態は、クラウドを見て判断する
「手順書にこう書いてある」は、書いた時点のスナップショットです。インポート後の環境変数・接続参照・フローの有効／無効・ロールの割り当ては、毎回その環境を読み取って確かめました。AIにも、リポジトリの文書ではなく実際の環境を見て判断するよう指示しています。
これから
新しい環境への移送テストを終え、PartnerLedgerをGitHubで公開しました（MITライセンス）。
ただし、公開した内容は完成形ではなく、たたき台です。取引先台帳は会社ごとに運用が違い、1人の開発で想定できる使い方には限りがあります。重複候補の提示のように、初回では見送った機能もあります。
だからこそ、コミュニティのみなさんと一緒にブラッシュアップしていけたら幸いです。「うちの会社ならこう使う」「この権限設計はこうしたほうがいい」「ここが分かりにくい」といった声が、次の改善のいちばんの材料になります。
試してみるには
Releases から、マネージドソリューションのzipをダウンロードし、インポート手順書に沿って進めます。zipには、画面（Code App）、Dataverseの表、Plugin、フロー5つ、セキュリティロール4つ、環境変数、接続参照が入っています。
- Dataverseのある環境で、Code Appsを有効にしておく
- 接続を用意する（Microsoft Dataverse、承認、Office 365 Outlook、Office 365 Groups）
- 承認者のMicrosoft 365グループと、それに紐づくDataverseのグループチームを用意する
- 専用のアプリケーションユーザーは要らない
既存業務と分けた検証用の環境で、まずは架空の取引先や名刺で試すのがおすすめです。
資料もまとめて公開しています
| 資料 | 内容 |
|---|---|
| 説明書 | 利用者・承認者・管理者向けの使い方 |
| 要件定義 | 要件と受入条件。設計を決めたときの日付付きの経緯も残している |
| データ設計・セキュリティロール | 表と権限の設計。1章で紹介したロールと共有の詳細 |
| 改造・開発の手順 | 自分の環境で改造するとき |
| AI共通指示（AGENTS.md） | Codex・Claude Code・GitHub Copilotと一緒に開発するときの指示 |
Dataverseのアクセス制御とCode Appsを組み合わせる実例として、ぜひ自分の環境で動かしたり、改造したりしてみてください。気づいたこと、改善のアイデア、使ってみた感想は、GitHubのIssueやPull Request、この記事へのコメントで気軽に教えてください。たたき台を、みんなで育てていければうれしいです。
おわりに
取引先台帳は、どの会社にもある地味な業務です。それでも「誰が見てよいか」「誰が変えてよいか」「変えたことを後から説明できるか」は、きちんと守る必要があります。
PartnerLedgerを作って改めて感じたのは、この一番難しいところを、Dataverseの標準のアクセス制御に任せられることの大きさです。ロール・所有者・チーム・共有がプラットフォームにあるから、アプリは画面の使いやすさに集中できます。そしてCode Appsなら、その標準の恩恵を受けたまま、Reactで思いどおりの画面を作れます。
山積みの名刺も、AI Builderに読ませ、人は確認するだけ、という形にできました。名刺が引き出しで眠るのではなく、見てよい人どうしで共有される台帳の情報になる。身近な困りごとを、Power Platformの標準の組み合わせで解決できるのも、このプラットフォームの良さだと思います。
「Power Platformは手軽だけど、本格的な業務アプリには物足りない」「コードで書くと、権限やガバナンスを全部自分で作ることになる」。そう感じている方にこそ、Dataverse × Code Appsという選択肢を試してみてほしいです。PartnerLedgerとDecisionFlowが、その参考になればうれしいです。
謝辞
DecisionFlowに続き、今回もGeek氏（@geekfujiwara）のCodeAppsDevelopmentStandardに大変お世話になりました。Code Appsの開発の進め方や画面設計の考え方を標準として公開してくださっているおかげで、AIと一緒に開発するときの前提がぶれず、業務の設計に集中できました。この場を借りてお礼申し上げます。