Microsoft Graph APIで標準のPlanner（Basic）を自動作成できても、Planner Premium（旧Project for the web相当）まで同じ仕組みで作れるとは限りません。本記事では「Graph APIでPremiumプランを作成できるのか？」を結論から整理し、実務で使える代替自動化（Project schedule API／Dataverse／Power Automate）の設計ポイントまで解説します。
結論：Microsoft Graph APIだけでPlanner Premium（プレミアム プラン）は作成・自動化できない
まず結論から言うと、Microsoft Graph の Planner API（/planner/plans・/planner/buckets・/planner/tasks など）は「Basic（標準）プラン」向けのAPIであり、Planner Premium（プロジェクトベースのプラン）を同じ流れで作成したり、Premium側のバケットやタスクをGraph経由で直接操作したりする用途には対応していません。
実装済みの「標準 Planner プラン → バケット → タスク」の自動作成ロジックを、そのまま Premium に横展開しようとすると、API上は“別物”として扱われるため詰まります。Premiumを自動化したい場合は、Plannerとしてではなく、Project for the web（Dataverse）側の仕組みとして設計し直すのが現実解です。
まず押さえる：Plannerは「Basic」と「Premium」でバックエンドが違う
Microsoft Planner には大きく2種類のプランがあり、UI上は同じPlannerアプリで扱えても、内部のデータモデルや機能、前提となるサービスが異なります。
| 観点 | Planner Basic（標準プラン） | Planner Premium（プレミアム プラン） |
|---|---|---|
| 主な用途 | ボード中心のタスク管理 | 依存関係・ガント・リソースなどを含むプロジェクト管理 |
| 代表的な機能 | バケット、ラベル、チェックリスト、繰り返しタスク など | タイムライン（ガント）、依存関係、マイルストーン、スプリント、目標、タスク履歴、カスタム項目 など |
| データの置き場 | Planner（Graph Planner API の対象） | Project for the web エンジン＋Dataverse（Power Platform） |
| 公式APIの中心 | Microsoft Graph Planner API | Dataverse Web API / Project schedule APIs（Scheduling entities） |
| Graph APIでの扱い | 作成・更新・削除を含め比較的整っている（ただし委任権限中心） | Premium固有の項目（依存関係、リソース、カスタム項目など）はGraphのPlanner APIでは扱えない |
特に重要なのは、Microsoft LearnのPlanner API解説で「Premium plans and tasks aren’t available … Only basic plans may be accessed」と明記されている点です。つまり、GraphのPlanner APIを“Premiumにも拡張して使う”という発想自体が、現状の公式仕様とズレています。
補足：標準Planner（Basic）のGraph自動作成で押さえるポイント
すでにBasicの自動化は実装済みとのことですが、Premium移行を考えるタイミングで「Graph側の制約」も一度棚卸ししておくと、運用設計がブレにくくなります。
| 論点 | 実務での注意点 |
|---|---|
| プラン作成（POST /planner/plans） | Graphの作成APIは委任権限が中心で、アプリケーション権限が用意されていないものがあります。また、コンテナがMicrosoft 365グループの場合、作成者がそのグループのメンバーである必要があります。 |
| 「作れたのに見えない」 | グループメンバーシップや権限不足で、UIや別ユーザーから見えないケースがあります。API設計と同時に「誰が作るか／誰が見るか」も設計対象です。 |
Basicの代表的な作成フローは、次のようにGraphのエンドポイントが素直に階層化されています（Premiumはこの前提が崩れます）。
POST https://graph.microsoft.com/v1.0/planner/plans
POST https://graph.microsoft.com/v1.0/planner/buckets
POST https://graph.microsoft.com/v1.0/planner/tasks「GraphでPremiumを作れない」ときに起きがちな症状
標準 Planner と同じ感覚で Premium を叩こうとすると、次のような形で“気づき”が訪れます。
| 症状 | 起きやすい場面 | 原因の考え方 | 対処の方向性 |
|---|---|---|---|
| Premiumで作ったプランIDを /planner/plans で参照できない | PremiumプランをGraphで取得・検索しようとした | Planner APIの対象外（Basicのみ） | Dataverse側でプロジェクトとして扱う |
| タスクは取得できる気がするが更新（PATCH）できない | 「新しいPlanner」上のPremiumタスクをAPIから更新しようとした | Premium固有のデータモデル／操作がGraph側に露出していない可能性 | Schedule API（PSS）/ Dataverse Web APIの利用を検討 |
| Power AutomateのPlannerコネクタでもPremium操作が思うようにいかない | 既存フローの流用 | Basic向けに作られたアプリ/ワークフローはPremiumでは修正が必要 | Dataverse/Project schedule API側へ設計を寄せる |
なぜPremiumは「Planner API」ではなく「Project/Dataverse」として考える必要があるのか
Planner Premiumは、UI上は「Plannerの上位版」に見えますが、Microsoftの説明ではProject for the webのエンジン上に構築され、データはDataverseに保存されます。そのため、依存関係・リソース割当・タイムラインなど、プロジェクト管理に必要な構造はDataverse（Project）側のエンティティとして管理されます。
また、Project for the webがPlannerへ統合される流れ（Project for the webの退役・移行）が進んでも、APIが即座にGraph側へ集約されるわけではありません。UIの統合とAPIの統合は別の話で、2025年後半のMicrosoft Q&Aでも「PremiumはGraphのPlanner APIでは扱えない／Dataverse Web APIがサポートされる方法」と整理されています。
Premium自動化の前提：Dataverse環境（どのURLに向けて呼ぶか）を特定する
PremiumはDataverseにデータがあるため、API連携は「どのDataverse環境のURLに向けるか」が出発点になります。Project for the webは、初回利用時に既定（Default）のDataverse環境へPower Appが展開されることが説明されています。
一方で、Plannerの統合が進む中で、非既定環境（non-default environment）にあるプランをPlannerで扱えるようにする動きも案内されています。UI上で見えているPremiumプランが“どの環境に属するか”を確認し、正しい環境のWeb APIエンドポイントに対して呼び出す設計にしてください。
代替案の全体像：Premiumを自動化するなら「Project schedule API」か「Dataverse Web API」
Premiumプラン相当の“プロジェクト”を自動作成し、バケット（工程）やタスク、依存関係、割当まで組み立てたい場合、選択肢は大きく次の2系統です。
- Project schedule APIs（Scheduling entities API / PSS）：スケジューリングエンジンと整合性を取りながら、作成・更新・削除を行うための専用API
- Dataverse Web API（OData）：Dataverse上のテーブル（エンティティ）をRESTで参照・更新するための汎用API
実務目線では「タスクを大量投入する」「依存関係や割当も同時に張る」など“スケジュールに影響する操作”をしたいなら、まずProject schedule APIsを軸に考えるのが安全です。
Project schedule APIsで実現できること（Premium自動生成の王道）
Project schedule APIsは、Project for the webのスケジューリングエンジンで管理される「Scheduling entities」に対して、作成・更新・削除（CUD）を提供します。つまり、Premiumの“中身”をAPIで組み立てたいときの中心です。
Planner Premiumの概念をDataverseのエンティティに対応づける
Premiumを自動化するときは、まず「Planner用語」を「Project/Dataverse用語」に翻訳できると設計がスムーズです。
| Planner Premiumで見えるもの | Project schedule API / Dataverseでの実体 | 論理名（例） |
|---|---|---|
| Premium プラン（プロジェクト） | Project | msdyn_project |
| バケット（工程・区分） | Project Bucket | msdyn_projectbucket |
| タスク | Project Task | msdyn_projecttask |
| 依存関係（先行/後続） | Project Task Dependency | msdyn_projecttaskdependency |
| 担当/割当（リソース） | Resource Assignment | msdyn_resourceassignment |
| スプリント | Project Sprint | msdyn_projectsprint |
典型的な自動作成フロー（設計の型）
Microsoft Learnのサンプル（Power Automate）でも示されている通り、Premium相当のプロジェクトを“それっぽく”作るには、だいたい次の手順が型になります。
- プロジェクトを作成（例：
msdyn_CreateProjectV1） - チームメンバーを作成（例：
msdyn_CreateTeamMemberV1） - OperationSetを作成（例：
msdyn_CreateOperationSetV1） - バケット・タスク・割当・依存関係などをOperationSetに積む（例：
msdyn_PssCreateV1/V2） - OperationSetを実行して反映（例：
msdyn_ExecuteOperationSetV1）
ここで重要なのがOperationSetです。複数の“スケジュールに影響する操作”を、トランザクション的にまとめて処理するための単位（ユニット・オブ・ワーク）として説明されています。
Project schedule APIs利用時の制約（ここを見落とすとハマる）
Premiumの自動化で躓く原因は、実装ロジックよりも「前提条件（ライセンス・実行主体・操作数制限）」であることが多いです。
| 制約 | 何が起きる？ | 回避・設計の工夫 |
|---|---|---|
| Project schedule APIsはProjectライセンスを持つユーザーのみ利用可能 | サービスアカウントや“アプリのみ”で動かしたいのに権限エラー | 委任（ユーザー）で実行する／運用ユーザーの選定と権限設計を先に固める |
| アプリユーザー／統合ユーザー等では利用できない | バックエンドジョブ（デーモン）構成が取りづらい | 実行基盤を「ユーザーコンテキスト前提」に寄せる（例：Power Automate、Interactive login） |
| OperationSetは1つあたり最大200操作、ユーザーあたり同時に最大10 | 大量作成で途中から失敗・詰まり | バッチ分割、リトライ設計、投入単位の最適化（タスク数×フィールド更新回数を減らす） |
Dataverse Web APIでできること：読み取り・分析・軽微な更新（ただし“スケジュール整合性”に注意）
Dataverse Web APIはOData v4.0に準拠したREST APIで、Dataverseのデータ（テーブルや列定義を含む）を幅広い言語・環境から扱えます。PremiumのデータがDataverseにある以上、参照・レポーティングの入口として非常に重要です。
読み取り（参照）の例：プロジェクトタスクを抽出する
Power BI / Power Query で msdyn_projecttask を参照する例がよく出てくるのも、PremiumタスクがDataverse上のProject Taskとして保存されているからです。
GET https://{org}.crm*.dynamics.com/api/data/v9.2/msdyn_projecttasks?$select=msdyn_subject,msdyn_start,msdyn_finish&$top=50ただし、Dataverseを直接叩いて“更新”までやる場合は、スケジューリングエンジンとの整合性（どの列が編集可能か／どの操作が禁止されるか）を必ず確認してください。Project schedule APIs側で「更新できない項目」「代わりに削除→作り直し」といった注意事項が列挙されています。
カスタム項目（カスタムフィールド）の落とし穴
Premiumを使っていると「カスタム項目もAPIで取りたい／初期値を入れたい」という要望が必ず出ます。ところが、Project for the web（Premium）のFAQでは、ローカルのカスタムフィールドはDataverseのProjectテーブル内にバイナリ形式で保存され、レポーティングには使えないと明言されています。Microsoft Q&Aでも同様に“個別の列としては露出しない”旨が回答されています。
つまり「PremiumプランをAPIで“完全に”再現する」のは、カスタム項目の扱い次第で現実的でなくなることがあります。自動化設計では、最初に次の判断が必要です。
- カスタム項目を必須とするなら：テンプレートコピー＋手動入力／UI操作の併用なども含めてプロセス設計
- カスタム項目が任意なら：APIで作れる範囲（タスク、依存関係、割当、日付）を優先して自動化
Power AutomateでPremiumを自動化する現実的なルート
「コードで全部やる」以外の現場では、Power Automate（クラウドフロー）でProject schedule APIsを呼び出してPremium相当の計画を組み立てるアプローチが取りやすいです。Microsoft Learnには、Power Automateでプロジェクト作成・チームメンバー作成・OperationSet作成・バケット作成・タスク作成・リソース割当・OperationSet実行までを一連の流れとして説明したサンプルが公開されています。
ポイントは、Power Automateの「Dataverse コネクタ」でUnbound Action（アクションの実行）として msdyn_CreateProjectV1 や msdyn_PssCreateV1 を呼び出せる点です。これにより、認証や接続管理をPower Platform側に寄せつつ、Premium側のスケジュールエンティティを操作できます。
「標準PlannerのGraph自動化」を捨てずに移行する設計案
すでにGraphで標準Plannerを自動化している場合、Premiumへ一気に置き換えるより、段階移行が失敗しにくいです。Support記事でも、Basic向けに作られたアプリやワークフローはPremiumで修正が必要とされています。
| 移行パターン | メリット | 注意点 | 向いているケース |
|---|---|---|---|
| Basicを継続しつつ、Premiumは“上位計画”として別管理 | 既存Graph資産を壊さない | 二重管理になりやすい | Premiumは一部の案件だけ |
| Basicを入力口（受け皿）にして、定期的にPremiumへ同期 | 入力の自動化はGraphのまま維持 | 同期ロジック（ID対応、差分、例外処理）が必要 | 現場はまず“タスク起票”を自動化したい |
| Premiumへ全面移行し、Dataverse/Project schedule APIで再実装 | 依存関係・リソースなどPremiumの価値を最大化 | 権限・ライセンス・運用設計の難易度が上がる | プロジェクト管理を標準化したい |
実装者向け：GraphとPremiumの“境界線”を明確にするチェックリスト
- 作成対象のプランが「Basic」か「Premium」かを、要件定義の段階で固定する（途中で混在すると設計が崩れる）
- Premiumで必要な機能（依存関係、割当、タイムライン、スプリント、目標、カスタム項目）を列挙し、APIで必要な範囲を確定する
- Project schedule APIsはユーザーライセンス前提。実行主体（どのユーザーで動かすか）を先に決める
- OperationSetの上限（200操作）を前提に、バッチ単位とリトライ設計を決める
- カスタム項目がレポーティングできない／列として露出しない前提で、代替（命名規則、タスク名への埋め込み、外部DB管理など）を検討する
Premiumプランの上限と設計上の注意（タスク数・依存関係数など）
Premium（Project for the web相当）側には、タスク数やリンク（依存関係）数などの上限があります。大量投入を前提にするなら、API実装より先に“上限に当たらない設計”を入れるのが安全です。
| 項目 | 上限（Project for the web / Premiumの目安） | 設計での対策例 |
|---|---|---|
| プロジェクトの総タスク数 | 3,000 | 案件を分割する／マイルストーン中心にする／詳細は別管理にする |
| リンク（successorのみ） | 2,000 | 依存関係を貼りすぎない／工程間だけに絞る |
| プロジェクトの総リソース数 | 300 | ロールで割当する、チームを適切に分割する |
| カスタムフィールド数 | 10 | 本当に必要な項目だけに絞る／外部に拡張データを持つ |
今後の対応：GraphでPremiumを操作したいならフィードバックを残す
「PremiumをGraph APIで作成・更新できるようにしてほしい」という要望自体はニーズが大きく、コミュニティでも繰り返し話題になります。一方で、現時点の公式情報ではPremiumはGraph Planner APIの対象外として整理されているため、今後の改善を期待する場合はフィードバックチャネルに要望を残すのが定石です。
PlannerチームはFeedbackボタンやPlanner Feedback Portalへの投稿を案内しています。要望を出すときは、単に「対応してほしい」だけでなく、次のように“実現したいユースケース”を具体化すると採用されやすくなります。
- Premiumプランを作成したい（テンプレートから複製したい／既定バケット・カレンダーを含めたい）
- 依存関係・割当・開始/終了日・スプリント・目標をAPIで一括投入したい
- 既存のGraphベース自動化（Planner Basic）をPremiumへ移行したい
- カスタム項目をレポーティング/自動化に使いたい
まとめ：Premiumの自動化は「GraphではなくProjectとして設計する」
標準Planner（Basic）はMicrosoft Graph APIで「プラン→バケット→タスク」という分かりやすいモデルで自動化できます。一方、Planner PremiumはProject for the webエンジン＋Dataverseに基づくため、同じGraphのPlanner APIでは作成・更新の前提が揃いません。
Premium相当のプランを自動生成したいなら、Project schedule APIs（OperationSet＋PssCreateなど）を軸に、Dataverse Web APIを参照・分析に組み合わせる構成が、現時点で最も現実的です。既存のGraph資産がある場合は段階移行を前提に、要件（カスタム項目、依存関係、割当、上限）から逆算して設計しましょう。
コメント