2026.11.03 業務システム

SharePoint APIとは？REST APIとGraphの使い分け・Sites.Selected権限とリスト操作の実装例

Q: SharePointの検索をAPIで行うにはどうすればよいですか？

検索には専用の窓口があり、Graphなら Microsoft Search API の search/query 、RESTなら _api/search/query を使います。リストアイテムの取得APIで条件を付けて探す方法は、インデックスの無い列だと5,000件のしきい値に当たるため、サイトをまたいだ全文検索には向きません。2つの検索APIの違いとページングの書き方は Microsoft Search APIの使い方 で詳しく扱っています。

SharePoint APIとは？REST APIとGraphの使い分け・Sites.Selected権限とリスト操作の実装例

SharePoint APIとは、SharePointのサイト、リスト、ファイルを外部のプログラムから読み書きするためのHTTPの窓口です。入口は2つあり、サイトのURLに /_api を付けて呼ぶSharePoint REST APIと、graph.microsoft.com 経由で呼ぶMicrosoft Graphのどちらでも同じデータに届きます。この記事では、2つの入口の違いと選び方、2026年4月2日のAzure ACS廃止で変わった認証、Sites.Selectedでアクセスを特定サイトだけに絞る手順、リストアイテムの追加とファイルのアップロードのコード例、スロットリングの上限値までを、Microsoft Learnの記載に沿って整理しました。

まとめ：新規開発はGraphで書き、REST APIは足りない操作だけで呼ぶ

これから作る連携なら、Microsoft Graphで書き始めます。Microsoftは新機能をGraph側で出しており、リソースユニットの消費もRESTより少ないと公式に書いています。REST APIは廃止されていませんが、Graphに無い操作、たとえばリストのビュー定義やフォームダイジェストを前提にした既存コードの保守に使う位置づけです。

認証は、Microsoft Entra IDにアプリを登録し、アプリ専用アクセスなら証明書を使う形に統一します。権限は Sites.ReadWrite.All のようなテナント全体のものを避け、Sites.Selected を付けたうえで対象サイトだけを割り当てる方式が、情報システム部門の承認を得やすい構成です。

SharePoint APIの2つの入口：_apiのREST APIとGraphの対応

_api配下で呼ぶSharePoint REST APIのURL構造と応答形式

SharePoint REST APIは、サイトのURLの後ろに /_api/web を付け、その下にリストやファイルのパスをつなげて呼びます。SharePoint REST エンドポイントを使用して基本的な操作を完了するでは、読み取りはGET、作成はPOST、更新はPOSTに X-HTTP-Method: MERGE を添える形と説明されています。

応答はOData形式です。Acceptヘッダーに application/json;odata=verbose を指定すると型情報つきのJSON、odata=nometadata なら値だけのJSONが返ります。サイトごとにURLが変わるため、複数サイトを扱うアプリではサイトURLを設定値として持つ設計になります。

Graphのsites・lists・drivesとREST v2エンドポイントの対応表

Microsoft Graph REST API を介した SharePoint REST 操作には、Graphの各URLがSharePoint内部のREST v2エンドポイントに対応する表が載っています。下の表では、Graph側のホスト graph.microsoft.com とバージョン v1.0、SharePoint側のホスト {tenant}.sharepoint.com を省いてパスだけを並べました。

主な対象	Graph のパス	SharePoint のパス
サイト	/sites	/_api/v2.0/sites
リストとアイテム	/lists	/_api/v2.0/lists
ライブラリ全般	/drives	/_api/v2.0/drives
既定のライブラリ	/drive	/_api/v2.0/drive

同じページは、他のGraph APIを既に使っているならGraph経由で呼ぶほうがコード管理が楽だと勧めています。Graphの呼び出しがSharePointで処理されるかを確かめたいときは、クエリの末尾に $whatif を付けると、内部で使われるSharePointのURLが出力されます。

2026年4月2日のACS廃止で止まった認証方式とRESTが残る範囲

「SharePointのREST APIは廃止された」という話を見かけますが、廃止されたのは認証の仕組みです。Azure ACS retirement in Microsoft 365によると、Azure ACSによるSharePoint Onlineの認証は、新しいテナントで2024年11月1日、既存のテナントで2026年4月2日に使えなくなり、延長の手段はありません。同じ日にSharePointアドインも提供を終えています。

同ページは、この廃止がREST API、CSOM、JSOM、SPFxを廃止するものではないと明記しています。AppRegNew.aspxで発行したクライアントIDとシークレットで動いていた連携は、REST APIの書き方を変えなくても、認証をEntra IDへ移さない限り動きません。オンプレミスのSharePoint Serverは影響を受けません。

REST APIとGraph APIを操作の範囲とスロットリングの重さで選ぶ基準

Graphで足りる操作とREST APIでしか書けない操作を比べた一覧表

リストアイテムの読み書き、ファイルのアップロード、サイトの取得、権限の付与といった日常的な処理は、Graphで書けます。RESTを選ぶのは、Graphに相当するAPIが無い操作に限られます。

やりたいこと	Graph	REST API
リストアイテムの追加・更新・削除	可（listItem）	可
250MBを超えるファイルのアップロード	可（アップロードセッション）	可（チャンク分割）
サイト単位・リスト単位のアプリ権限付与	可（permissions）	不可
ビューの定義どおりの一覧取得	不可	可（RenderListDataAsStream）
Teams・Outlookとの同時連携	同じトークンで可	不可

この表の「不可」に当たる処理が要件に入るときだけ、RESTを併用します。1つのアプリでGraphとRESTを混ぜる場合、トークンの対象（audience）が別になる点に注意が必要です。Graph用は https://graph.microsoft.com/.default、REST用は https://{tenant}.sharepoint.com/.default で、それぞれ取得し直します。

スロットリング：Graphは1回1〜5単位、RESTは単価非公開で重い

Avoid getting throttled or blocked in SharePoint Onlineでは、Graphの呼び出しにリソースユニットの単価が決まっています。1件取得は1、複数件取得と作成・更新・削除・アップロードは2、権限操作は5です。CSOMとRESTには決まった単価がなく、同じ処理でもGraphより多く消費するとされています。

アプリごとの上限は、テナントのライセンス数が1,000以下なら1分あたり1,250ユニット、24時間で1,200,000ユニットです。平均2ユニットで割った場合の目安は、1分あたり約600回です。上限を超えると429か503が返り、Retry-After の秒数だけ待つ必要があります。待たずに再試行した要求も消費にカウントされるため、即時のリトライはかえって制限を長引かせます。

アプリ登録とSites.Selectedで特定サイトだけに権限を絞る手順

REST APIのアプリ専用アクセスは証明書が必須でシークレットは拒否

夜間バッチのように利用者がサインインしない処理では、アプリ専用アクセスを使います。Granting access via Entra ID App-Onlyは、SharePointのCSOMとREST APIをアプリ専用で呼ぶには証明書が必要で、それ以外の方法はアクセス拒否になると答えています。

Graph側はクライアントシークレットでもトークンを取れますが、RESTを1本でも呼ぶ可能性があるなら、最初から証明書で統一します。証明書の秘密鍵を持つ人は誰でもアプリの権限を使えるため、鍵はAzure Key Vaultなどに置き、開発者のPCに残さない運用にします。

Sites.Selectedを同意してからpermissionsでサイトを割り当てる

Understanding Resource Specific Consentによると、アプリにSites.Selectedを付けて管理者が同意しただけでは、どのサイトにもアクセスできません。全体管理者か、Sites.FullControl.Allを持つ別のアプリが、対象サイトごとに権限を割り当てて初めて読み書きできます。

# 1. サイトIDをパスから取得する（管理用アプリのトークンで実行）
GET https://graph.microsoft.com/v1.0/sites/contoso.sharepoint.com:/sites/soumu

# 2. 連携アプリに write を割り当てる
POST https://graph.microsoft.com/v1.0/sites/{site-id}/permissions
Authorization: Bearer {admin-token}
Content-Type: application/json

{
  "roles": ["write"],
  "grantedToIdentities": [{
    "application": {
      "id": "{連携アプリのクライアントID}",
      "displayName": "総務部リスト連携"
    }
  }]
}

# 応答の id を控えておくと、PATCH で権限変更、DELETE で取り消しができる
DELETE https://graph.microsoft.com/v1.0/sites/{site-id}/permissions/{permission-id}

roles に指定できる値は read、write、manage（Graphの一覧では owner）、fullcontrol の4つです。Sites.SelectedはGraph用とSharePoint用の2種類があり、RESTで呼ぶならSharePoint側のSites.Selectedも登録します。サイトの取得にはsite getByPathの書式を使い、ホスト名とパスの間にコロンを入れます。

リスト単位とファイル単位のSelected権限で継承が切れる注意点

サイトより細かく絞る権限も用意されています。Overview of Selected permissions in OneDrive and SharePointによると、Lists.SelectedOperations.Selected はリスト単位、ListItems.SelectedOperations.Selected はアイテムやフォルダー単位、Files.SelectedOperations.Selected はファイル単位でアクセスを与え、いずれも委任とアプリ専用の両方で使えます。

ただし、リスト以下に権限を割り当てると、その対象の権限継承が切れます。サイト単位の割り当てだけは継承の根なので切れません。固有の権限を持つアイテムが増えるとライブラリの上限に近づき、棚卸しも難しくなるため、実務ではサイト単位のSites.Selectedを基本にし、機密リストだけを別サイトへ分ける設計をとります。継承の解除が増えたときの確認方法はSharePointのアクセス権設定と棚卸しの手順で扱っています。

リストアイテムとファイルを操作するリクエスト例：GraphとRESTを比較

Graphでサイトをパスから引き、リストにアイテムを追加するPython

次のコードは、証明書でアプリ専用トークンを取り、総務部サイトの「問い合わせ台帳」リストに1件追加します。必要なライブラリは msal と requests です。list getはリストIDの代わりにリストのタイトルも受け付けます。

import time
import msal
import requests

TENANT_ID = "{テナントID}"
CLIENT_ID = "{クライアントID}"
G = "https://graph.microsoft.com/v1.0"

app = msal.ConfidentialClientApplication(
    CLIENT_ID,
    authority=f"https://login.microsoftonline.com/{TENANT_ID}",
    client_credential={
        "private_key": open("app-key.pem", encoding="utf-8").read(),
        "thumbprint": "{証明書の拇印}",
    },
)
token = app.acquire_token_for_client(scopes=["https://graph.microsoft.com/.default"])["access_token"]
headers = {
    "Authorization": f"Bearer {token}",
    # 推奨形式の User-Agent を付けると、制限時に優先的に扱われる
    "User-Agent": "NONISV|Contoso|InquirySync/1.0",
}

def call(method, url, **kw):
    # 429・503 は Retry-After の秒数だけ待ってから再試行する
    for _ in range(5):
        r = requests.request(method, url, headers=headers, timeout=30, **kw)
        if r.status_code not in (429, 503):
            r.raise_for_status()
            return r.json()
        time.sleep(int(r.headers.get("Retry-After", "10")))
    raise RuntimeError("スロットリングが解除されませんでした")

site = call("GET", f"{G}/sites/contoso.sharepoint.com:/sites/soumu")
lst = call("GET", f"{G}/sites/{site['id']}/lists/問い合わせ台帳")
item = call("POST", f"{G}/sites/{site['id']}/lists/{lst['id']}/items",
            json={"fields": {"Title": "請求書の再発行", "Requester": "営業部"}})
print(item["id"])  # 201 Created で返るアイテムID

listItem の作成は fields に列の内部名と値を入れます。表示名が日本語の列は内部名が _x で始まる文字列に変換されていることが多く、表示名をそのまま書くことは、処理が失敗する原因です。列を作るときに英字の内部名を付けておくと、APIからの扱いが楽になります。列設計の考え方はSharePointリストの列設計とビューにまとめています。

REST APIでアイテムを更新するときのtype指定とIf-Matchの412

同じ更新をREST APIで書くと、本文にリストごとの型名を入れる点が違います。REST を使用してリストとリストアイテムを操作するでは、型名を ListItemEntityTypeFullName から取得するよう指示しています。

# 型名を調べる（例：SP.Data.InquiryListItem）
GET https://contoso.sharepoint.com/sites/soumu/_api/web/lists/GetByTitle('問い合わせ台帳')?$select=ListItemEntityTypeFullName
Authorization: Bearer {sharepoint-token}
Accept: application/json;odata=nometadata

# ID=12 のアイテムを更新する
POST https://contoso.sharepoint.com/sites/soumu/_api/web/lists/GetByTitle('問い合わせ台帳')/items(12)
Authorization: Bearer {sharepoint-token}
Accept: application/json;odata=nometadata
Content-Type: application/json;odata=verbose
If-Match: "{取得時のETag}"
X-HTTP-Method: MERGE

{ "__metadata": { "type": "SP.Data.InquiryListItem" }, "Title": "請求書の再発行（対応済み）" }

If-Matchに取得時のETagを入れると、その後に誰かが同じアイテムを更新していた場合に412が返り、上書き事故を防げます。* を指定するかヘッダーを省くと、差分を確認せずに上書きされます。OAuthのBearerトークンで呼ぶ場合、旧来のアドインで必要だった X-RequestDigest は不要です。アイテム一覧の取得は既定で100件ずつ返り、$skip は効かないため、次ページは応答に含まれるリンクでたどります。

250MBを超えるファイルはアップロードセッションと320KiBの倍数で送る

GraphのPUT contentは1回の呼び出しで送れるファイルが250MBまでです。それより大きいファイルや、回線が不安定な環境からの送信はcreateUploadSessionで分割します。

POST /sites/{site-id}/drive/items/root:/契約書/2026.pdf:/createUploadSession で uploadUrl を受け取る
ファイルを5〜10MiBずつ、320KiB（327,680バイト）の倍数に区切ってuploadUrlへPUTする
各PUTに Content-Range を付け、202が返れば nextExpectedRanges の位置から続ける
最後の断片で201か200が返れば完了。404ならセッションが消えているので最初からやり直す

uploadUrlは認証済みのURLなので、PUTにAuthorizationヘッダーを付けると401になることがあります。区切りを320KiBの倍数にしないと、最後の断片を送った後の確定で失敗する場合があるというのが、公式の説明です。10MiBを超えるファイルは最初からこの方式に寄せておくと、処理を1本にまとめられます。

連携をSharePoint APIで自作する条件とPower Automateで済む場面

自作に進む条件：基幹システム連携・大量処理・サイト単位の権限

APIで連携を作るべきなのは、次のどれかに当てはまる場合です。販売管理や会計など社外製品のデータを毎日SharePointに取り込む、1日に数万件のアイテムやファイルを処理する、アプリのアクセス先を特定サイトに絞るよう監査で求められている。この3つは、ノーコードの仕組みでは再試行や権限の粒度を細かく制御できません。

ACS廃止で止まった旧アドインの移行も、ここに入ります。認証の差し替えだけでは動かず、Entra IDへの登録、証明書の発行、Sites.Selectedの割り当て、UI部分のSPFxへの置き換えを組み合わせる必要がある作業です。当社では、既存連携の棚卸しからEntra ID移行、Graphでの作り直しまでをMicrosoft 365・Copilot導入支援としてお受けしています。止まっている連携の一覧があれば、移行の順番と工数を具体的にご提案できます。

見送る場面：リスト1つの通知や承認ならPower Automateで足りる

リストにアイテムが追加されたらTeamsに通知する、申請を上長に回して承認結果を列に書き戻す、といった1つのリストで完結する処理には、APIを書きません。Power AutomateのSharePointコネクタで数十分で作れ、保守も業務部門に任せられます。

自作のコードは、証明書の更新、ライブラリの更新、スロットリング対応を誰かが持ち続ける必要があります。処理件数が1日数百件以下で、連携先がMicrosoft 365の中に閉じているなら、その維持費のほうが高くつくという判断です。トリガーの選び方と無限ループの防ぎ方はPower AutomateのSharePoint連携の実装ガイドで解説しています。

よくある質問

SharePoint APIについて、連携を検討している開発担当者や情シスからよく寄せられる質問をまとめました。

SharePointのREST APIは廃止されたのですか？

廃止されていません。2026年4月2日に終了したのは、Azure ACSによる認証と、SharePointアドインの仕組みです。Microsoftの告知ページは、REST API、CSOM、JSOM、SPFxは廃止の対象外と明記しています。ACSで発行したクライアントIDとシークレットを使っていた連携は、Entra IDにアプリを登録し直し、アプリ専用なら証明書で認証する形に変えれば、REST APIをそのまま呼べます。

SharePoint APIとMicrosoft Graph APIは別物ですか？

入口が違うだけで、扱うデータは同じSharePointのサイト、リスト、ファイルです。Graphの sites や drives の呼び出しは、内部でSharePointのREST v2エンドポイントに変換されて処理されます。Graphは1つのトークンでTeamsやOutlookにも届き、スロットリングの消費も少ないため、新規開発で優先するのはGraphです。Graph全体の権限設計と呼び出し方はMicrosoft Graph APIの権限設計と呼び出し手順で解説しています。

SharePoint APIの利用に追加料金はかかりますか？

サイト、リスト、ファイルを読み書きする通常のREST APIとGraph APIの呼び出しに、Microsoft 365のライセンス以外の料金はかかりません。代わりに、テナントのライセンス数に応じたリソースユニットの上限があり、ライセンス1,000以下のテナントでは1アプリあたり1分1,250ユニットです。上限を超えた分は課金ではなく429で拒否されるため、大量処理ではRetry-Afterに従う実装が必要になります。

SharePointの検索をAPIで行うにはどうすればよいですか？

検索には専用の窓口があり、Graphなら Microsoft Search API の search/query、RESTなら _api/search/query を使います。リストアイテムの取得APIで条件を付けて探す方法は、インデックスの無い列だと5,000件のしきい値に当たるため、サイトをまたいだ全文検索には向きません。2つの検索APIの違いとページングの書き方はMicrosoft Search APIの使い方で詳しく扱っています。

SharePointにHTMLのページをAPIで作れますか？

モダンページは、Graphの sitePage 作成APIでタイトルとテキストWebパーツのHTMLを渡して作り、publish を呼んで公開します。ただし置けるWebパーツは公式の一覧にあるものに限られ、スクリプトを含む独自のHTMLを埋め込む用途には使えません。独自の表示が必要ならSPFxでWebパーツを作ります。ページ作成のリクエスト例はSharePointサイトの作り方とGraph APIでのページ作成に載せています。