この記事の結論：Dataverse MCP ServerがCustom APIをサポートした（2026-10-26）。これにより、Copilotエージェントは複数の書き込み操作を1つのアトミックなトランザクションとして実行できる。ただしCustom Actions（Power Automateのカスタムアクション）は現時点で非対応。
対象読者
- Copilot StudioまたはCopilot Chatでエージェントを設計している人
- DataverseテーブルへのCRUD操作をMCPまたはカスタムコネクタで呼び出している人
- 「エージェントが複数テーブルに横断書き込みするシナリオ」でトランザクション管理に悩んだことがある人
出典：Power Platform blog, 2026-10-26
Copilot Studioでエージェントを設計するとき、「画面の向こうでAIが複数のテーブルに書き込む」設計になる場面がある。サポートケースを作成し、そこに注記（annotation）を追加し、フォローアップタスクも作る——たった1つのユーザー依頼から3つの書き込みが走る。
大企業の環境で問題になりやすいのは、ここだ。ステップ2でエラーが起きたとき、ステップ1で作られたケースはどうなるか。何もしなければ孤立したレコードが残る。フォローアップも入らず、しばらくしてから「対応漏れ」として浮かび上がる。
Power Automateフローでも、エラーハンドリングのスコープを正確に書かないと同じことが起きる。「書き込みを3回に分けて、失敗したら巻き戻す」補償ロジックを自分で実装するのは本来あってはならない手間だ——データベースのトランザクションは本来それをタダで解決するものだから。
2026年10月26日、Power Platform blogがこの問題に直接関係する発表を出した。Dataverse MCP ServerがCustom APIをサポートした。
Custom APIとは何か
Custom APIはDataverseの既存の機能だ。「Win Opportunity」や「Qualify Lead」のような組み込みアクションと同じように、自分でファーストクラスのサーバーサイド操作を定義できる。
通常のDataverse Custom APIは次の要素から構成される。
-
一意な名前：
api/_CreateCaseWithFollowUpのように、他のDataverseメッセージと同じく検索・識別できる - バインドタイプ：非バインド（グローバル）、エンティティバインド、エンティティコレクションバインドの3種
- 型付きリクエストコントラクト：呼び出し元が渡すべき入力パラメータ（Guid・String・DateTimeなど）の定義
- 型付きレスポンスコントラクト：呼び出し元が受け取る出力プロパティの定義
- プラグイン：実際に実行されるC#コード。Dataverseの組織サービスに完全アクセスできる
重要なのは、このプラグインがDataverse内で単一のトランザクションとして実行される点だ。プラグイン内のどこかでInvalidPluginExecutionExceptionがスローされれば、Dataverseがそこまでの書き込みをすべてロールバックする。孤立したケースも、宙ぶらりんのノートも残らない。
エージェント（AIモデル）が見るのは、「ケースを作れ」「ノートを付けろ」「タスクを入れろ」という3つの別々の操作ではなく、「_CreateCaseWithFollowUpを呼べ」という1つの操作だ。呼び出し元の視点から見ると、単一の入力コントラクトと単一の出力コントラクトだけが存在する。
なぜMCPとの組み合わせが重要か
MCP（Model Context Protocol）は、AIモデルがツールを発見・呼び出すための標準プロトコルだ。Dataverse MCP Serverは、DataverseのテーブルやAPIをMCPツールとして公開する。
今回の発表以前、Dataverse MCP ServerはDataverseの標準テーブルには対応していたが、Custom APIには対応していなかった。エージェントがカスタムビジネスロジックを呼ぶには、Power Automateフローを経由するか、自前のAPIエンドポイントを立てるかしかなかった。
今回の対応で、Custom APIをDataverse MCP Server経由で直接呼び出せるようになった。これは「既存のカスタムビジネスロジックを、新規実装なしでエージェントから呼べる」ことを意味する。
もう一点、設計上の重要な変化がある。MCPのsearchツール自身の指示に「まずここにCustom APIが存在しないか確認せよ。あれば自分でやらずそれを使え」と書かれているという。これはエージェントが独自にロジックを組み立てる前に、必ず既存のCustom APIを優先して使うよう誘導される設計だ。
3ステップの呼び出しの仕組み
ブログの説明によれば、Dataverse MCP ServerがCustom APIを呼び出すまでの流れは3つのMCPツール呼び出しで構成される。
ステップ1：検索（search）
エージェントはまずCustom APIが存在することを知らない。プロンプトからキーワード（「ケース作成」「フォローアップ」「損傷」など）を抽出してMCPサーバーのsearchツールを呼ぶ。
Dataverse MCP Serverはテーブル・スキル・スコープと並んでCustom APIもインデックスしており、api/_CreateCaseWithFollowUpというパスを返す。ファイルシステムのパス形式で返ってくる点が特徴だ。
ここで重要なのは、searchツールの指示がエージェントに「先にCustom APIを確認せよ」と明示的に伝えていることだ。エージェントが直接テーブルを書き換えるのではなく、既存のカスタムオペレーションがあればそれを優先する動作になる。
ステップ2：スキーマ解決（describe）
名前が分かっても、呼ぶためには入力パラメータのコントラクトが必要だ。エージェントはdescribeツールを呼んで、_CreateCaseWithFollowUpの完全なリクエストスキーマを取得する。
返ってくるのは、Custom API登録時に定義したメタデータそのものだ——各入力パラメータの名前、型（string・Guidなど）、必須かどうか、説明文。手書きのツール定義は不要で、Dataverse側で正規化したメタデータがそのままMCPのツール定義になる。
これは実運用上の大きなメリットだ。Custom APIを更新すれば、MCPサーバー経由でエージェントが見るスキーマも自動的に更新される。ツール定義を別途管理する手間がない。
ステップ3：呼び出し（invoke）
スキーマに基づいて入力を揃えたら、エージェントはCustom APIを呼び出す。Dataverse側でC#プラグインが動き、ケース作成・ノート追記・タスク作成が1トランザクションで完了する。どれかが失敗すれば全部ロールバック。成功すればCopilotがプレーンテキストで結果を報告する。
3ステップのうちstep 1（search）とstep 2（describe）はエージェントが内部的に行うもので、ユーザーには見えない。ユーザーが入力したのは「Adventure Worksのケースを作って、損傷の説明をノートに追記して、金曜の午後にフォローアップのタスクも入れて」という1文だ。それを受けてエージェントが3つのMCPツール呼び出しを経て、1つのアトミックな操作を実行する。
Custom Actionsとの違い（現時点）
ここで注意が必要な点がある。ブログに明記されている：Custom Actionsは現時点でDataverse MCP Serverに非対応。
Custom ActionsとCustom APIsは混同されやすいが、別物だ。Custom Actionsは主にPower Automateフローやモデル駆動型アプリから呼ぶためのもので、Custom APIとは定義方法・バインド方式が異なる。
Power Automateのカスタムアクションを多用している環境では、それをCopilotから直接呼ぶことは現時点ではできない。今後Custom Actionsが対応するかどうかは、現時点では確認できていない。
企業のCopilot設計への影響
この発表を受けて、企業環境でCopilot AgentやMCPを設計する場合に考え方を変えた方がよい点がある。
トランザクション境界をDataverse側に置くという考え方だ。これまでは「エージェント→複数のDataverse書き込み→補償ロジック」という設計が必要だったが、Custom APIを使えば「エージェント→Custom API（内部でアトミックに実行）」で済む。
実際の設計変更としては次のような方向が考えられる。
- 既存のビジネスロジックがC#プラグインで実装されていれば、Custom APIとして公開するだけで、エージェントが自動的に発見して呼べるようになる
- まだCustom APIが無い場合、複数テーブルへの横断書き込みが発生する処理を洗い出し、Custom APIとして定義することを検討する価値がある
- Power Automateフロー経由の処理は、引き続きカスタムコネクタやHTTPアクション経由になる（Custom Actions非対応のため）
企業環境で注意が必要なのはCustom APIの登録・管理ガバナンスだ。どのCustom APIがMCPサーバー経由で公開されているかを把握しておかないと、エージェントが意図しない操作を呼ぶリスクがある。特に本番データに影響するロジックが複数のエージェントから呼ばれるようになる状況では、アクセス権限の設計と合わせて管理する必要がある。
既存のDataverse環境にCustom APIがどれだけ存在するかは、組織によってまちまちだ。Copilot Studioを導入する際のフェーズで、Custom APIの棚卸しを合わせて行うことが今後のベストプラクティスになるかもしれない。少なくとも「エージェントから呼ばれる可能性があるCustom APIは何か」を把握する観点は今後必要になる。
今回分かったこと
- Dataverse MCP ServerがCustom API対応した（2026-10-26公式発表）
- Custom APIはC#プラグインで実装した処理をアトミックなDataverseトランザクションとして公開する仕組み
- MCPサーバーがCustom APIを自動でインデックスするため、エージェントはsearch→describe→invokeの3ステップで呼び出せる
- Custom Actions（Power AutomateのCustom Actions）は現時点で非対応
- 複数テーブルへの横断書き込みがあるシナリオでは、Custom APIへの設計変更を検討する価値がある
- ガバナンスの観点から「MCPサーバー経由で公開されているCustom API一覧」を把握する仕組みを作っておくとよい
この変更に関して、実際のCopilot Studioへの展開がどう変わるかはまだ手元では検証できていない（リリースされたばかりのため）。設計段階で組み込む価値がある機能だという判断はしている。
WSL2の自動化基盤については別途まとめている。
https://note.com/light_tern636/n/n0af91154f91c