CData Office365ドライバーは、Outlookのメール・カレンダーだけでなく、Microsoft To Do(Graph API上では TodoTaskLists / TodoTasks)にもSQLライクにアクセスできます。ただし、自分以外のユーザーのTo Doタスクを取得・操作する場合は、通常のOAuth接続だけでは権限不足になりがちです。この記事では、他ユーザーのTo Doタスクへアクセスするための2つの代表的な方法(委任権限+リスト共有/アプリケーション権限)を、設定手順とSQL例つきで解説します。
前提条件
CData Driver for Office 365 がインストール済みであること
Microsoft 365(Azure AD / Entra ID)の管理者権限、またはアプリ登録の権限があること
対象ユーザーがMicrosoft To Do上でタスクリストを保持していること
方法1:委任権限+Todoタスクリストの共有
Microsoft To Doは、Outlookの共有メールボックスやカレンダーのように「管理者がある1ユーザーに他ユーザーのタスクをまるごと閲覧させる」機能を、Graph APIレベルでは持っていません。そのため、他ユーザーのTo Doタスクを見る現実的な方法は、To Doの「リスト共有」機能でリストのメンバーになってもらい、そのメンバー自身のアカウントでドライバーを接続するという形になります。
1. To Doでリストを共有する
タスクの所有者側でMicrosoft To Doを開き、共有したいリストで「共有」→「招待リンクを作成」を選択し、アクセスさせたいユーザーを招待します。招待されたユーザーは共有リンクにアクセスして「リストに参加」が完了している状態にします。

共有を受けたユーザーの画面では、そのリストが「共有」または「他の人のタスク」セクションに表示されます。
2. Azure ADアプリでOAuth委任権限を設定する
CDataドライバー用にカスタムOAuthアプリを作成し(Azure Portal > アプリの登録)、以下の委任されたアクセス許可(Delegated permissions)を追加します。
API | 権限 | 用途 |
|---|
Microsoft Graph | Tasks.ReadWrite
| 自分自身のTo Doリストの読み書き |
Microsoft Graph | Tasks.ReadWrite.Shared
| 自分に共有されたTo Doリストの読み書き |
Microsoft Graph | User.Read
| 基本プロファイル情報の取得 |
Microsoft Graph | offline_access
| リフレッシュトークンによる継続アクセス |

3. 共有を受けたユーザーの認証情報でドライバーを接続する
接続文字列は、共有されたユーザー自身の資格情報でOAuth認証します。
OAuthClientId=[your_client_id];
OAuthClientSecret=[your_client_secret];
AuthScheme=AzureAD;
InitiateOAuth=GETANDREFRESH;
4. 共有されたリストのタスクを取得する
SELECT Id, ListId, Title, Status, DueDateTime_dateTime, Importance
FROM TodoTasks
WHERE ListId = 'MySharedListId'
リストIDが分からない場合は、まず自分(=共有を受けたユーザー)から見えるリスト一覧を取得します。
SELECT Id, DisplayName, IsShared, IsOwner
FROM TodoTaskLists
IsShared = true の行が、共有されて表示されているリストです。
方法1のポイントと制約
共有された本人のアカウントで接続する必要があるため、タスク所有者本人のUserIdを指定して他人のリストを直接覗く用途には向きません。あくまで「共有された人が自分のアクセス範囲でタスクを見る」構成です。
Microsoft To Doのリスト共有には、閲覧のみ/編集のみといった細かい権限レベルがなく、共有された相手は原則フルアクセス(閲覧・追加・完了・削除)になります。組織のセキュリティ要件次第では、方法2の方が管理しやすい場合があります。
方法2:アプリケーション権限でアクセスする
組織全体で任意のユーザーのTo Doタスクを横断的に取得したい場合(管理レポート、監査、ダッシュボードなど)は、アプリケーション権限(Application Permission)を使ったクライアントクレデンシャルフローが適しています。この方式では、個々のユーザーの同意やリスト共有設定に依存せず、テナント管理者の同意だけで任意のユーザーのTo Doデータへアクセスできます。
1. Azure ADアプリでアプリケーション権限を設定する
Azure Portal上のアプリ登録で、アプリケーションのアクセス許可(Application permissions)として以下を追加し、管理者の同意を付与します。
API | 権限 | 用途 |
|---|
Microsoft Graph | Tasks.Read.All
| 全ユーザーのTo Doタスク読み取り |
Microsoft Graph | Tasks.ReadWrite.All
| 全ユーザーのTo Doタスク読み書き(更新・作成が必要な場合) |
2. クライアントクレデンシャルフローで接続する
OAuthClientId=[your_client_id];
OAuthClientSecret=[your_client_secret];
AuthScheme=AzureAD;
InitiateOAuth=GETANDREFRESH;
3. UserIdを指定してタスクリストを取得する
クライアントクレデンシャル(アプリケーション権限)接続では、/me エンドポイントに相当するコンテキストが存在しないため、取得対象ユーザーを UserId で明示する必要があります。
SELECT * FROM TodoTaskLists WHERE UserId = ''
には、対象ユーザーのMicrosoft GraphオブジェクトID(GUID)またはUPN(例:[email protected])を指定します。ユーザーIDが分からない場合は、あらかじめ Users テーブルから調べておくと確実です。
SELECT Id, DisplayName, UserPrincipalName
FROM Users
WHERE DisplayName LIKE 'Yamada%'
タスクリストのIDが取得できたら、個々のタスクも同様に UserId を指定して取得します。
SELECT t.Id, t.Title, t.Status, t.DueDateTime_dateTime
FROM TodoTasks t
WHERE t.ListId = 'MyListId'
AND t.UserId = ''
方法2のポイントと制約
ユーザー本人の同意やリスト共有操作を必要としないため、多数のユーザーのタスクを定期的に集計・監査するようなバッチ処理に向いています。
反面、アプリケーション権限は組織全体のTo Doデータへの広いアクセスを意味するため、Azure ADの管理者同意が前提になり、情報セキュリティ部門との調整が必要になることが多い点に留意してください。
執筆時点でTo Do関連のアプリケーション権限は一部テナント設定や条件付きアクセスポリシーの影響を受ける場合があるため、想定通りに動作しない場合はMicrosoft Graphの公式ドキュメントで最新の対応状況を確認してください。
動作確認
いずれの方法でも、接続後に以下のようなシンプルなクエリで疎通確認するとトラブルシューティングが容易です。
SELECT Id, DisplayName FROM TodoTaskLists
まとめ
他ユーザーのTo Doタスクへアクセスするには、「共有された本人のアカウントで委任権限を使う方法」と「アプリケーション権限で UserId を指定して横断的に取得する方法」の2通りがあります。個人の共有ベースで十分なら方法1、組織横断のレポートや監査目的であれば方法2が適しています。用途に応じて使い分け、Azure ADでの権限設定を丁寧に行うことがスムーズな接続の鍵になります。