Python で SharePoint のファイルを取得してみた その① 〜アーキテクチャ選定〜

はじめに

業務要件で Teams にアップロードされたファイルをサーバーから定期的に取得する処理を実装する必要がありました。調査・検証の中で得た知見を書いていきます。

要件

要件は大まかに以下の2つです。

　1. サーバーから Teams の既存チャンネル内の「ファイル」タブにあるExcelファイルを定期的に取得したい
　2. 重要： サーバー（プログラム）がアクセスできる範囲は、できるだけ絞りたい

技術調査

1. Teams のファイルはどこにあるの？

実は、Teams 自体はファイルを保持していません。ファイルの保存先は、裏側にある SharePoint というストレージサービスになっています。

この SharePoint にプログラムからアクセスする標準的な手法を調べたところ、 Microsoft Graph API を利用するのが一般的であることがわかりました。

そこで今回は、この Microsoft Graph API を採用することにしました。
なお、APIを利用するためには、認証基盤である Microsoft Entra ID（旧 Azure AD） へのアプリ登録が必要になります。

2. 権限の種類（Delegated vs Application）

Graph API を使う際、もっとも悩んだのが「権限のタイプ」です。

Application 権限（アプリケーション許可）：
アプリ自体に権限を付与します。ユーザーがログインしていなくても動くためバッチ処理に向いていますが、Files.Read.All などの権限を付けると、テナント内すべてのサイトのファイルが見えてしまうというリスクがあります。（要件2に反する）

Delegated 権限（委任された権限）：
「ログインしたユーザー」の身代わりとしてアプリが動きます。
そのユーザーがアクセスできないファイルは、アプリもアクセスできません。セキュリティ的には安心です。（要件2もにっこり）

今回の選定：Device Code Flow（デバイスコードフロー）

今回は、運用負荷とセキュリティのバランスを考え、Device Code Flow を採用しました。

「サーバーの自動実行なのに、ユーザー操作が必要なの？」と疑問に思うかもしれません。
Device Code Flow のリフレッシュトークンを活用することで自動化が可能となります！

• 初回の認証： サーバーが発行したコードを、人間が自分のPCのブラウザに入力してログインします。
• 2回目以降： 認証時に発行される「リフレッシュトークン」をサーバー内に安全に保存（キャッシュ）しておくことで、次回からは人間が介在することなく自動でトークンを更新し、ファイルをダウンロードできます。

まとめ

最終的に、以下の構成で実装することに決めました。

• 　・言語： Python（バッチを同居させる既存のサーバーアプリで Python を採用しているため）
• 　・認証方式： OAuth 2.0 Device Code Flow
• 　・メリット： 管理者への「全サイトアクセス承認」の依頼が不要。実行ユーザーがアクセスできる範囲だけに限定されるため安全。

次回の記事では、少し具体的に Microsoft Entra ID でのアプリ登録手順 について解説します。ここを間違えると認証が通らないので、ハマりポイントを重点的にまとめていきます！

みなさまが良き Graph API ライフを送れますように。