Microsoft Planner Premium（プレミアム プラン）のタスクをAPIで取りたいのに、Microsoft GraphのPlanner APIでは取得できない――この壁に当たる人は多いです。本記事では、PremiumがDataverseに保存される理由と、Dataverse Web API/TDS/Power BIを使った現実的な取得ルート、更新まで踏み込む場合の注意点を整理します。
結論：GraphのPlanner APIはPremiumのプラン／タスクを取得できない
まず押さえておきたいのは、Microsoft GraphのPlanner APIが対象にしているのは「Basic（従来Planner）」のプラン／タスクであり、Premium（Project系の新しいPlanner）のデータは同じ方法では取得できない、という点です。
公式ドキュメントでも、Premium plans / Premium tasks がGraphのPlanner APIでは利用できない旨が明記されています。Graph側でエンドポイントを叩いても、Premiumで作ったプランが見えない・タスクが空になる・そもそもIDが引けない、といった症状が起きるのは仕様に近い動きです。
この「取れない問題」は、あなたの権限設定や実装ミスというより、データの保存先が違うことに起因します。ここを理解すると、最短で解決ルートに乗れます。
BasicとPremiumの違い：データの居場所が変わる
Plannerには大きく2系統の世界が混在しています。乱暴に言えば、BasicはGraphで扱いやすいPlanner世界、PremiumはDataverseで動くProject世界です。PremiumのタスクはDataverse（Microsoft Power Platformのデータ基盤）に格納されるため、GraphのPlanner APIが見に行く場所と一致しません。
| 観点 | Planner Basic（従来） | Planner Premium（プレミアム） |
|---|---|---|
| 主な用途イメージ | チームの軽量タスク管理 | プロジェクト指向の計画・依存関係・スケジュール管理 |
| データ保存先の考え方 | Planner（Graphで取得できる領域） | Dataverse（Project for the web / Project系スキーマ） |
| APIの第一候補 | Microsoft Graph Planner API | Dataverse Web API / TDS（Dataverse SQL）/ Power Platformコネクタ |
| スキーマのわかりやすさ | 比較的ドキュメントが豊富 | テーブルが多く、関係性が把握しづらい（探索が重要） |
| 更新の難しさ | GraphでCRUDしやすい | 直書き更新は制約に当たりやすく、専用API（Schedule API等）が必要になることがある |
Premium側のデータがDataverseにある以上、「Graphで取れないなら、Dataverseから取る」のが基本方針になります。ただし、いきなりDataverse Web APIでクエリを書こうとすると、スキーマの壁にぶつかりがちです。そこで次章から、現実的に詰まらない手順で進めます。
Premiumデータを取得する選択肢：目的別に最適解が変わる
Premiumのタスクを取り出す方法はいくつかあります。選択肢ごとの向き不向きを先に整理しておくと、遠回りを防げます。
| 手段 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Dataverse Web API（REST/OData） | 自社システム連携、定期バッチ、細かいフィルタ・結合が必要 | プログラムから柔軟に取得できる。認可設計もしやすい | テーブル/列の特定が必要。権限（アプリユーザー/ロール）で詰まりやすい |
| TDS（Dataverse SQL） | 分析・参照中心。SQLでサクッと見たい。Power BI/SSMS/Azure Data Studioで扱いたい | SQLライクに参照でき、探索が速い。既存のBIスキルが生きる | 読み取り専用（INSERT/UPDATE不可）。行数が多いと設計が重要 |
| Power BI / Power Automate などのDataverseコネクタ | まずは見える化・抽出・試作。非エンジニアも巻き込みたい | GUIでテーブル探索しやすい。認証や接続が比較的楽 | 最終的に本番連携するなら、API方式へ移行が必要なことも |
おすすめの進め方は、「まずPower BI（またはPower Apps）でテーブルを見つける → その後、Web APIやTDSで自動化」です。PremiumのProject系スキーマは、最初の“地図作り”が成功の9割です。
最短で迷子にならない：Power BIでDataverseのテーブルを探索する
Premiumタスクの格納先として、代表的に登場するのが msdyn_projecttask テーブルです。実際のスレッド事例でも、Power BIからDataverseに接続し、msdyn_projecttaskを読むことでタスクを取得しています。
Power BI（Power Query）での接続例
Power BI Desktopで「Dataverse（Common Data Service）」へ接続し、該当環境を選択すると、dboスキーマ配下のテーブルとしてProject系テーブルが見えます。例として、次のようなPower Queryが共有されています。
let
Source = CommonDataService.Database("org*****.crm4.dynamics.com"),
dbo_msdyn_projecttask = Source{[Schema="dbo",Item="msdyn_projecttask"]}[Data]
in
dbo_msdyn_projecttask
ここで重要なのは、コードそのものよりも「どの環境（org〜.dynamics.com）にPremiumデータがあるか」と、「どのテーブルにタスクが入っているか」を確定できる点です。Premiumのデータは、あなたが想像している環境ではなく、Planner Premiumが紐づいたDataverse環境に存在します。環境を取り違えると、正しい権限があっても“空振り”します。
探索のコツ：テーブル名で決め打ちせず「関連する列」で当たりを付ける
msdyn_projecttaskが代表例とはいえ、組織や機能の使い方によっては周辺テーブル（プロジェクト、バケット、割当、依存関係など）も絡みます。Power BIやPower Appsのテーブル一覧で、次のキーワードを軸に探すと早いです。
- project（プロジェクト本体）
- task（タスク）
- assignment（担当者割当）
- bucket（列/バケット相当）
- link / dependency（依存関係）
また、列（カラム）側に「名称」「開始日」「終了日」「進捗率」「ステータス」「親プロジェクトID」のようなフィールドがあるかで、タスク実体テーブルかどうかを判断できます。
本命：Dataverse Web APIでPremiumタスクを取得する
テーブルが特定できたら、次はDataverse Web API（REST/OData）でプログラムから取得します。Web APIの強みは、アプリケーション連携に向いた形で、フィルタや選択列を制御できることです。
Dataverse Web APIの基本形
Dataverse Web APIは、環境URL配下の /api/data/v9.2/（バージョンは環境で異なる場合あり）を叩くイメージです。タスクを取得する最小構成は次のようになります。
GET https://<yourorg>.crm<region>.dynamics.com/api/data/v9.2/msdyn_projecttasks?$top=10
Authorization: Bearer {access_token}
Accept: application/json
実運用では、$select と $filter を必ず使い、必要な列・必要な行だけに絞り込みます。Dataverseは「何でも取れる」分、雑に全列・全件を引くと、速度もスロットリングも一気に悪化します。
よく使うクエリパターン
Premiumで「あるプラン（プロジェクト）配下のタスクだけ」を取りたいことが多いはずです。まずはプロジェクトID（またはプロジェクト名）を確定し、そこに紐づくタスクを引く形が安全です。
GET https://<yourorg>.crm<region>.dynamics.com/api/data/v9.2/msdyn_projects?$select=msdyn_projectid,msdyn_subject&$filter=contains(msdyn_subject,'マーケ')&$top=5
プロジェクトが特定できたら、そのIDでタスクをフィルタします（実際の参照列名は環境のメタデータで確認してください）。
GET https://<yourorg>.crm<region>.dynamics.com/api/data/v9.2/msdyn_projecttasks?$select=msdyn_projecttaskid,msdyn_subject,msdyn_scheduledstart,msdyn_scheduledend,msdyn_percentcomplete&$filter=_msdyn_project_value eq <project-guid>&$orderby=msdyn_scheduledstart asc
Dataverseの列名は見た目が似ていても環境で差が出ることがあります。“動く列名”は、Power BIで列一覧を見て確定するのが確実です。
認証・権限設計でつまずかないポイント
Dataverse Web APIはAzure AD（Entra ID）認証です。ポイントは「トークンを取れた＝データを読める」ではないことです。Dataverse側の権限（セキュリティロール）がないと、APIは通っても0件になったり403になったりします。
| 項目 | 押さえるポイント |
|---|---|
| ユーザー実行（委任） | 実行ユーザーがDataverse環境に存在し、対象テーブルにRead権限を持つロールが必要 |
| アプリ実行（アプリケーション） | アプリ登録だけでなく、DataverseにApplication Userとして登録し、ロール付与が必要 |
| 環境の取り違い | Premiumデータが入っているDataverse環境に対して権限を付ける。別環境に付けても意味がない |
| 最小権限 | いきなり管理者ロールにせず、対象テーブルのReadから段階的に付けると運用が安定する |
特にアプリケーション権限は「Azure ADで許可したのに読めない」という混乱が起きがちです。Dataverseは“環境内のセキュリティ”が最後の砦なので、アプリユーザーとロール付与までセットで考えましょう。
TDS（Dataverse SQL）で読む：分析・探索に強い読み取り専用ルート
「まずはSQLでサクッと中身を見たい」「BIで読みたい」という用途なら、TDS（Tabular Data Stream）エンドポイントが便利です。DataverseをSQL Serverライクに参照できる機能で、Power BIやSSMS、Azure Data Studioから接続してテーブルを直接SELECTできます。
ただし、TDSは基本的に読み取り専用です。INSERT/UPDATE/DELETEのような更新系はできません。Premiumのタスクを取得してデータウェアハウスに貯めたい、というケースには向きますが、「タスクを作りたい・更新したい」用途には別ルートが必要になります。
SQLクエリ例（イメージ）
環境に接続できたら、まずはタスクテーブルを少量だけ確認します。
SELECT TOP (100)
msdyn_projecttaskid,
msdyn_subject,
msdyn_percentcomplete,
createdon,
modifiedon
FROM dbo.msdyn_projecttask
ORDER BY modifiedon DESC;
次に「どのプロジェクトに紐づくタスクか」をJOINで追います（関係列は環境により異なるため、実列名は確認してください）。
SELECT TOP (200)
p.msdyn_subject AS project_name,
t.msdyn_subject AS task_name,
t.msdyn_percentcomplete,
t.modifiedon
FROM dbo.msdyn_projecttask t
LEFT JOIN dbo.msdyn_project p
ON t.msdyn_project = p.msdyn_projectid
ORDER BY t.modifiedon DESC;
TDSは探索が速い一方で、Dataverseの権限制御・行レベルの可視性の影響を受けます。想定よりデータが少ない場合は、クエリの問題よりもロール/権限や環境選択を疑う方が早いです。
スキーマが分かりにくい問題への対処：まず「必要最小限」を定義する
Premium（Dataverse）側のProjectスキーマは、Q&Aでも「公開ドキュメントが十分ではなく、スキーマが分断されていて直接クエリが難しい」と整理されています。ここで大事なのは、最初から完璧なテーブル設計を目指さないことです。
まずは「レポートや連携に必要な項目」を列挙し、それを満たす最低限のテーブルと列だけを確定していきましょう。
まず押さえたいmsdyn_projecttaskの代表的な情報
環境によって列名は異なる可能性がありますが、一般的にタスクの実務連携で必要になるのは次のような項目です。
| 目的 | 欲しい情報の例 | 確認のしかた |
|---|---|---|
| タスク識別 | タスクID、タスク名（件名） | msdyn_projecttaskの主キー列、subject/name系列 |
| 進捗 | 完了率、ステータス、完了フラグ | percentcomplete/status系列を探索 |
| 期間 | 開始日、終了日、予定/実績 | scheduled/start/finish系列の有無を確認 |
| 所属 | どのプロジェクト（プラン）配下か | project参照列（lookup）を確認し、msdyn_projectへ結合 |
| 更新検知 | 作成日時、更新日時 | createdon / modifiedon を使う |
「バケット（列）」や「担当者」などを取りたくなったら、その時点で関連テーブルを追加で調べれば十分です。最初から全体像を把握しようとすると、スキーマの森で迷子になります。
Power Automate / Power BIでの“現実的な回避策”
Premiumデータの抽出という点では、Power Platformのコネクタを使うのが手堅い選択肢です。理由はシンプルで、GUIでテーブルと列を探索できること、認証や権限のトラブルが相対的に少ないこと、運用担当者が引き継ぎやすいことです。
Power BI：レポート用途なら最優先
- Dataverseに直接接続して、msdyn_projecttaskなどのテーブルを読み込む
- 必要ならPower Queryで列を整形し、データモデルを作る
- 行数が多い場合は増分更新やデータフローを検討する
Premiumのデータ取得は、まずPower BIで“取れること”を確認してからAPI実装に移ると、手戻りが劇的に減ります。
Power Automate：抽出・通知・連携の試作に向く
Power AutomateのDataverseアクション（「行を一覧表示」など）を使えば、コードを書かずに抽出や通知フローを組めます。たとえば「特定プロジェクトのタスクが更新されたらTeamsへ通知」「毎朝CSVをSharePointへ出力」など、運用に直結する自動化を短期間で試せます。
更新・作成もしたい場合：Dataverse直書きは危険、専用APIの検討が必要
読み取りは比較的進めやすい一方で、Premiumタスクの作成/更新を「msdyn_projecttaskにCreate/UpdateすればOK」と考えると、そこで詰まる可能性があります。実際に、Power Automate等からmsdyn_projecttaskにタスクを追加しようとして拒否されるケースが報告されています。
これは、Project系のタスクが単純なレコードではなく、スケジュール計算・依存関係・整合性チェックなどの業務ロジックと一体で扱われるためです。テーブル直書きではロジックが動かず、整合性を崩すリスクがあるため、制限されることがあります。
更新が必要なら「Project schedule API（Operation Set）」が候補
公式導線として、Project for the web / Scheduling系の「Project schedule APIs」（Operation Setを使って一連の操作を実行するAPI）が案内されています。更新・作成・依存関係などを正しく反映させたい場合は、こちらの利用を検討するのが安全です。
| やりたいこと | 推奨アプローチ | 理由 |
|---|---|---|
| タスク一覧を定期的に取得して分析したい | Power BI / TDS / Dataverse Web API | 読み取り中心なら実装コストが低い |
| 外部システムからタスクを作成したい | Project schedule API（Operation Set） | スケジュール整合性を保ったまま更新できる可能性が高い |
| 簡易な自動化（通知・抽出）を早く回したい | Power Automate（Dataverse） | GUIで組めて保守しやすい |
もし「読み取りだけ」なのか「更新も必要」なのかが曖昧なら、まず読み取りで成果を出し、更新は専用APIに切り分けるのが実務的です。更新は要件・権限・ライセンスの影響を受けやすく、難易度が一段上がります。
実務で役立つチェックリスト：失敗パターンを先回りで潰す
最後に、Premiumデータ取得でハマりやすいポイントをチェックリストにまとめます。導入時の自己診断として使ってください。
| チェック項目 | YesならOK | Noなら見直すこと |
|---|---|---|
| 対象プランがPremiumであることを確認した | Graphで取れない理由が明確になる | BasicならGraph Planner APIで取得可能な場合がある |
| Premiumデータが存在するDataverse環境URLを特定した | 接続先の迷子を防げる | 環境を取り違えると0件になりやすい |
| msdyn_projecttaskなど、必要テーブルをPower BI/Power Appsで確認した | 列名・関係性を安全に把握できる | API実装前に“地図”を作る |
| DataverseのセキュリティロールでRead権限を付与した | API/TDSの0件・403を回避しやすい | Entra IDの権限だけでは不足する |
| 更新要件がある場合、直書きではなく専用APIを検討している | 将来の破綻を防げる | Project schedule API（Operation Set）等を検討 |
まとめ：PremiumはDataverse、まず探索してから自動化する
Microsoft Planner PremiumのタスクがGraphのPlanner APIで取得できないのは、仕様としてデータの保存先が異なることが主因です。Premiumのデータ取得は、Dataverse Web API、TDS（Dataverse SQL）、Power BI/Power AutomateのDataverseコネクタが現実的な解です。
最短で成功するためには、いきなりAPI実装に入るのではなく、まずPower BI等でmsdyn_projecttaskを起点にテーブルと列を特定し、必要最小限のデータモデルを作ってから自動化へ進めるのがおすすめです。更新まで必要な場合は、Dataverse直書きの限界を理解した上で、Project schedule APIのような専用APIを検討してください。
コメント