Spotify Web APIでできること一覧と使い方｜2026年の開発モード制限・Client ID取得・OAuth認証

Spotify Web APIでできるのは、曲・アルバム・アーティスト・ポッドキャストのメタデータ取得、カタログ検索、自分のプレイリストの作成と編集、ライブラリへの保存、再生の操作です。ただし2026年2月11日以降に作った開発モード（新しく作ったアプリの既定の状態）のアプリには新しい制限がかかり、所有者のSpotify Premium加入が必須で、他ユーザーのプレイリスト一覧、複数曲の一括取得、アーティストの人気曲、popularity（人気度）の値は使えません。それより前に作った開発モードのアプリは、Premium必須と人数の上限だけが2026年3月9日から適用され、エンドポイントと項目の変更は延期されています。この記事では新しい制限がかかるアプリを前提に、2026年10月時点の公式ドキュメントをもとに、できること・できないことを先に整理し、Client IDの取得、redirect URIの設定、認証フロー、Pythonでの検索、エラーの対処までを順に説明します。

まとめ：Spotify Web APIでできることと2026年の利用条件

• できること（開発モード）：1件ずつのメタデータ取得、検索（1回につき検索種別ごとに最大10件）、自分のプレイリストの作成・編集、ライブラリの保存と取得、よく聴く曲やアーティスト・最近再生した曲の取得、再生の操作（操作される側のユーザーがPremiumの場合のみ）。
• できないこと：Recommendations・Related Artists・Audio Features・Audio Analysis（2024年11月27日以降の新規アプリ）。一括取得・新譜とカテゴリ一覧・アーティストの人気曲・他ユーザーのプロフィールとプレイリスト、popularityやfollowersの値（2026年2月11日以降に作った開発モードのアプリ。既存アプリはこの部分が延期中）。
• 料金と人数：呼び出し単位の料金表は無い。開発モードはアプリ所有者のPremium加入が必須で、使えるのは1アプリ5ユーザーまで。拡張クォータモードの申請は2025年5月15日から法人のみ・月間アクティブユーザー25万人以上が条件。
• 認証：ユーザーのデータを扱わないならClient Credentials、扱うなら認可コードフロー（ブラウザ・モバイルはPKCE）。Implicit Grantとhttp://localhostのredirect URIはもう使えない。
• エラー：401はトークンの期限切れ、403は許可リストに入っていないユーザー、429はレート制限か開発モードのquota超過を最初に疑う。
• APIが要らない場合：曲やプレイリストをWebページに貼って聴かせるだけなら、Web APIではなくEmbed（埋め込みプレーヤー）で足りる。

Spotify Web APIでできること・できないこと（2026年10月時点）

Spotifyが公開している2026年2月のWeb API変更履歴には、開発モードで引き続き使えるエンドポイントの一覧が付いています。下の表はそれを用途ごとにまとめたものです。拡張クォータモードのアプリは2026年2月の変更の対象外で、従来のエンドポイントとフィールドをそのまま使えます。

開発モードで使える機能とエンドポイント

この範囲で作れるのは、たとえばSpotifyが返す自分の上位曲・上位アーティストを期間別に表示する聴取傾向ダッシュボード、検索条件に合う曲を集めて自分のアカウントにプレイリストを作るツール、自分用の画面やボタンから再生・スキップを操作するリモコンです。曲のexternal_idsにはISRC（国際標準レコーディングコード）が入りますが、これを使って他の配信サービスへデータを渡す用途は、後述のDeveloper Policyの制限に当たらないかを先に確認します。

再生の開始・一時停止・スキップ・音量変更などのPlayer APIは、公式リファレンスに「Spotify Premiumのユーザーでのみ動作する」と明記されています。無料プランのユーザーには操作ボタンを無効にしておきます。また、Player APIによる再生制御にも商用ストリーミング統合の禁止が適用され、Premium加入だけで商用利用が許可されるわけではありません。オーディオブックは米国・英国・カナダ・アイルランド・ニュージーランド・オーストラリアの市場に限られ、Client Credentialsでmarket=JPを指定した場合は返りません。ユーザーアクセストークンを使う場合は、marketの指定よりユーザーのアカウントに設定された国が優先されます。

返ってくる項目と返らない項目：popularityの削除とaccount_idの追加

2026年2月の変更はエンドポイントだけでなく、レスポンスの項目も削っています。公式の移行ガイドは「項目が無い場合に備えてコードを直す」よう求めています。開発モードで返る主な項目と、返らなくなった項目は次のとおりです。

external_idsは2026年2月にいったん削除と告知されたものの、3月の変更で復活しました。2026年5月にはGET /meにaccount_idが加わり、公式は自社サービスのアカウントとひも付けるときはidではなく、変わらない識別子であるaccount_idを使うよう案内しています。emailが返らなくなったため、ログイン後にメールアドレスで会員を照合していた設計は作り直しが必要です。

使えなくなった機能：2024年11月と2026年2月の廃止

2024年11月の廃止の対象は、同日以降に登録したアプリと、拡張申請を出していない開発モードの既存アプリです。Audio Featuresでテンポやdanceabilityを分析する解説記事はいまも検索上位に多く残っていますが、これから作るアプリでは再現できません。2026年2月の変更は、2月11日以降に作った開発モードのアプリに最初から適用されています。それ以前からある開発モードのアプリについては、告知記事の3月9日の追記で、Premium必須・ユーザー数・Client ID数の制限は予定どおり適用し、エンドポイントの変更は延期すると発表されました。移行ガイドの日程表は「3月9日に既存アプリを移行」のままですが、2026年10月13日時点で開発者ブログに新しい適用時期の告知はありません。既存アプリでも、いずれ同じ制限がかかる前提で移行ガイドのチェックリストを済ませておくのが安全です。

作れない用途：人気順ランキング・他人のプレイリスト分析・AI学習・事業者向け製品

popularityで曲を並べる人気ランキング、他ユーザーの公開プレイリストを集めて傾向を分析するツール、数百曲を一括取得して処理するバッチは、どれも開発モードの制限に正面からぶつかります。個人や小規模なチームがこれらを作るならSpotify Web APIは選ぶべきではありません。拡張クォータモードなら従来のエンドポイントが使えますが、申請できるのは月間アクティブユーザー25万人以上の法人だけです。

用途によっては規約の側で止まります。2025年5月15日発効のSpotify Developer Terms（バージョン10）は、SpotifyのプラットフォームやコンテンツをAI・機械学習モデルの学習に使うこと、モデルに取り込むことを禁じています。取得したデータを広告ネットワークやデータブローカーへ渡すこと、運用に必要な範囲を超えてデータベース化することも禁止です。同じ日に発効したDeveloper Policyは、店舗や従業員向けなど事業者が使う製品、音声でSpotifyを操作するアプリ、ゲームやクイズ、他サービスへのデータ移転（利用者本人のデータとプレイリストのメタデータを除く）を作ってはならない用途に挙げています。楽曲データを集めて分析・学習に回すなら、Spotify以外のデータ源を探すほうが早道です。

Web APIを使わずに済む用途：Embedと Web Playback SDK

Webサイトに曲・アルバム・プレイリスト・ポッドキャストのプレーヤーを埋め込むだけなら、Web APIを使う必要はありません。ただし、ブラウザや暗号化メディアの設定などによって、Embedの再生が短いプレビューに限られる場合があります。Spotify Embedsは、Spotifyのアプリから取得したHTMLを貼る方法、エピソードの読み込みや再生・一時停止をJavaScriptから制御するiFrame API、ユーザーが共有したリンクを埋め込みに変換するoEmbed APIの3通りを用意しています。

ブラウザの中でSpotifyの音源そのものを再生したい場合は、Web Playback SDKを使います。ブラウザをSpotify Connectの再生端末にするJavaScriptライブラリで、利用者にはSpotify Premium（モバイル専用のPremiumプランは対象外）が必要です。公式ページには、Spotifyの書面による事前承認なしに商用プロジェクトで使ってはならないとも書かれています。社外向けのサービスに組み込む計画なら、開発に入る前にこの条件を確認してください。画面のないRaspberry PiやLinuxの機器を再生端末にしたい場合は、2026年8月13日に公開されたSpotify Soloistという選択肢もあります。コマンドラインで動くSpotify Connectの再生端末で、セットアップにはPremiumアカウントが要り、ローカルのWebSocket APIから再生・一時停止・音量・キューを操作できます。

料金と利用条件：開発モードと拡張クォータモードの違い

Spotify Web APIには呼び出し単位の料金表が公開されておらず、APIの利用で課金されるしくみはありません。その代わり、公式ドキュメントのWeb APIトップには「Web APIの利用にはSpotify Premiumアカウントが必要」と書かれており、開発モードのアプリは所有者のPremiumが切れた時点で動かなくなります（再加入すると復帰）。

以前は許可リストに25人まで登録できたため、社内の検証やβテストの人数計画は見直しが必要です。2026年2月時点で既に6人以上を登録していたアプリは、その人数をそのまま保持できます。

拡張クォータモードは、2025年5月15日から法人からの申請だけを受け付けています（公式のQuota modes）。条件は法人登録があること、公開済みで稼働中のサービスであること、月間アクティブユーザー25万人以上、Spotifyの主要市場で提供していること、商業的な実現性、規約の順守です。個人開発のアプリを不特定多数のSpotifyユーザーに公開する計画は、個人のまま拡張クォータモードへ申請できない前提で立ててください。外部サービスの利用規約と認証方式を踏まえた連携の設計は、API開発・システム連携の支援でも相談を受けています。

Client ID・Client Secretの取得手順（Spotify for Developersダッシュボード）

ダッシュボードでのアプリ作成とClient IDの取得

1. Spotify for Developersのダッシュボード（developer.spotify.com/dashboard）にSpotifyアカウントでログインする。
2. 「Create app」を押し、App name・App description（どちらもユーザーの同意画面に表示される）とRedirect URIsを入力する。使うAPIを尋ねる項目では「Web API」を選び、Developer Terms of Serviceに同意して保存する。
3. 作成したアプリの「Settings」を開き、Client IDとClient Secretを控える。
4. 自分以外にも使わせる場合は、Settingsの「User Management」タブで相手の名前とSpotifyのメールアドレスを登録する（最大5人）。

Client IDは認可URLにも載るアプリの識別子で、秘密情報ではありません。Client Secretは認証に使う鍵なので、サーバー側の環境変数やシークレット管理サービスに置き、リポジトリやブラウザ・モバイルアプリのコードには埋め込みません。漏れた疑いがあるときは、アプリの画面の「ROTATE」で再発行できます。1つの開発者アカウントで作れるアプリは25個までです。Secretを安全に置けないアプリは、後述のPKCEを使えばSecretなしで認可コードフローを組めます。

連携アプリのアクセス権の解除：spotify.com/account/apps

利用者が自分のアカウントに連携しているアプリを解除する画面は、開発者向けのダッシュボードとは別にあります。公式サポートの「他のアプリでSpotifyを使う」によると、アカウントの［アプリ］ページにログインし、該当するアプリで［アクセス権を削除する］を押すと連携が切れます。開発中に同意画面のスコープを変えて試し直すときや、テストユーザーの認可をやり直すときにもこのページを使います。

redirect URIの設定：localhostが使えない理由と127.0.0.1の書き方

Spotifyは2025年2月12日に認証まわりのセキュリティ要件の引き上げを告知し、2025年4月9日以降に作られたアプリには新しいredirect URIの検証を自動で適用しました。既存アプリの移行期限だった2025年11月27日を過ぎたため、現在はすべてのアプリが次の要件に従います。

• redirect URIはHTTPSにする。HTTPが許されるのはループバックアドレスだけ。
• ループバックはhttp://127.0.0.1:PORTかhttp://[::1]:PORTのようにIPで書く。localhostは登録できない。
• ループバックIPに限り、ポート番号なしで登録しておき、認可リクエスト側で動的に割り当てたポートを付けられる。
• それ以外は、認可リクエストのredirect_uriがダッシュボードの登録値と完全に一致しなければならない。

エラーの文言で原因が分かれます。「INVALID_CLIENT: Insecure redirect URI」はlocalhostや非ループバックのHTTPを使っているときに出るので、上の表のとおりIPかHTTPSへ書き換えます。「INVALID_CLIENT: Invalid redirect URI」は登録値とリクエストの値が一致していないときの表示で、末尾のスラッシュ、ポート番号、httpとhttpsの違いを1文字ずつ照合すると大半は見つかります。iOSアプリでカスタムスキームを使う場合は、すべて小文字で、そのアプリ固有のスキームにし、my-app-login://callbackのようにパスまで含めます。

認証フローの選び方：Client Credentials・認可コード・PKCE

Spotifyが実装しているOAuth 2.0のフローは、認可コード、PKCE付き認可コード、Client Credentialsの3種類です。以前あったImplicit Grant（response_type=token）は2025年11月27日にサポートが終了しました。

Client Credentialsによる検索・メタデータ取得用トークンの発行

ユーザーのログインを挟まずに、アプリ自身のトークンを発行する方法です。Client IDとClient SecretをBasic認証で送ると、1時間有効なアクセストークンが返ります。

curl -X POST "https://accounts.spotify.com/api/token" \
  -u "$SPOTIFY_CLIENT_ID:$SPOTIFY_CLIENT_SECRET" \
  -d "grant_type=client_credentials"

# 応答例
{"access_token":"BQD...","token_type":"Bearer","expires_in":3600}

このトークンで呼べるのは、ユーザー情報を含まないエンドポイントだけです。/meで始まるプレイリスト・ライブラリ・再生の操作はエラーになるため、ユーザーのデータが必要になった時点で認可コードフローへ切り替えます。

認可コードフローとPKCE：プレイリスト編集・再生操作の認可手順

ユーザーをSpotifyの同意画面へ送り、戻ってきた認可コードをトークンと交換します。PKCEでは、43〜128文字のランダムなcode_verifierを作り、そのSHA-256ハッシュをパディングなしのBase64URL形式に変換し、code_challengeとして認可リクエストに付けます。流れの全体像は認可コードフローの実装手順で詳しく扱っています。

# 1. ユーザーを同意画面へ送る（改行は説明用）
https://accounts.spotify.com/authorize?response_type=code
  &client_id=CLIENT_ID
  &scope=playlist-modify-private%20user-library-read
  &redirect_uri=http%3A%2F%2F127.0.0.1%3A8080%2Fcallback
  &state=RANDOM_STATE
  &code_challenge_method=S256
  &code_challenge=CODE_CHALLENGE

# RANDOM_STATE は認可要求ごとに生成して保存する。
# コールバックの state が保存値と一致する場合だけ code を交換する。

# 2. 戻ってきた code をトークンに交換する
curl -X POST "https://accounts.spotify.com/api/token" \
  -d "grant_type=authorization_code" \
  -d "code=AUTH_CODE" \
  -d "redirect_uri=http://127.0.0.1:8080/callback" \
  -d "client_id=CLIENT_ID" \
  -d "code_verifier=CODE_VERIFIER"

スコープは同意画面に並ぶ権限そのものなので、必要な分だけ要求します。代表的なのは、公開プレイリストの編集playlist-modify-public、非公開プレイリストの編集playlist-modify-private、ライブラリの読み書きuser-library-read・user-library-modify、再生の操作user-modify-playback-state、よく聴く曲の取得user-top-readです。POST /me/playlistsはpublicの既定値がtrueなので、falseを指定せずに作るとplaylist-modify-publicが要ります。

アクセストークン1時間・リフレッシュトークン6か月の期限

アクセストークンの有効期限は3600秒（1時間）で、APIにはAuthorization: Bearer アクセストークンのヘッダーで渡します。期限が切れたら、認可コード系のフローで受け取ったrefresh_tokenをgrant_type=refresh_tokenで送って新しいトークンを得ます。PKCEの場合はボディにclient_idを、通常の認可コードの場合はBasic認証のヘッダーを付けます。

見落としやすいのはリフレッシュトークン自体の寿命です。公式のトークン更新ガイドでは、ダッシュボードで登録したアプリのリフレッシュトークンはユーザーが認可した時点から6か月で失効し、アクセストークンを更新しても延長されないと説明されています。失効したリフレッシュトークンを送ると、トークンエンドポイントは400と{"error": "invalid_grant"}を返します（2026年6月18日の告知。既存アプリへの適用は7月20日から）。このときは再試行せず、保存したトークンを捨ててユーザーを同意画面へ戻します。トークンには発行日時が含まれないため、最初に認可された日時を自前のデータベースに記録しておくと、期限前に再認可を促せます。トークンの寿命やローテーションの設計はリフレッシュトークンの更新フローと寿命の設計で整理しています。

Pythonで検索APIを使うコード：フィールドフィルタとlimit 10件の上限

GET /searchは、qにフィールドフィルタを書くと絞り込めます。artist:とyear:はアルバム・アーティスト・曲の検索に使え、年はyear:1955-1960のような範囲指定もできます。genre:はアーティストと曲、track:とisrc:は曲、upc:とtag:new（直近2週間の新譜）はアルバムだけが対象です。

2026年2月の変更でlimitの上限は50から10へ、既定値は20から5へ下がりました。10件を超えて取りたいときはoffset（0〜1000）でページを送ります。Client Credentialsのトークンにはユーザーの国がないため、marketを指定しないとコンテンツが「利用不可」として扱われる点にも注意が要ります。

import base64
import os
import time

import requests

TOKEN_URL = "https://accounts.spotify.com/api/token"
API_BASE = "https://api.spotify.com/v1"


def get_token():
    client_id = os.environ["SPOTIFY_CLIENT_ID"]
    client_secret = os.environ["SPOTIFY_CLIENT_SECRET"]
    basic = base64.b64encode(f"{client_id}:{client_secret}".encode()).decode()
    r = requests.post(
        TOKEN_URL,
        headers={"Authorization": f"Basic {basic}"},
        data={"grant_type": "client_credentials"},
        timeout=10,
    )
    r.raise_for_status()
    return r.json()["access_token"]  # expires_in は 3600 秒


def api_get(token, path, params, max_retry=3):
    for _ in range(max_retry + 1):
        r = requests.get(
            f"{API_BASE}{path}",
            headers={"Authorization": f"Bearer {token}"},
            params=params,
            timeout=10,
        )
        if r.status_code != 429:
            r.raise_for_status()
            return r.json()
        # QUOTA_EXCEEDED は通常のレート制限と区別し、この例では再試行せず止める
        try:
            error_body = r.json()
        except ValueError:
            error_body = {}
        if error_body.get("error", {}).get("reason") == "QUOTA_EXCEEDED":
            raise RuntimeError("development mode の quota を超過")
        if _ == max_retry:
            break
        time.sleep(int(r.headers.get("Retry-After", "5")))
    raise RuntimeError("429 が続いたため中断")


def search_tracks(token, q, pages=3):
    tracks = []
    for page in range(pages):
        data = api_get(token, "/search", {
            "q": q, "type": "track", "market": "JP",
            "limit": 10, "offset": page * 10,  # limit の上限は 10
        })
        items = data["tracks"]["items"]
        tracks.extend(items)
        if len(items) < 10:
            break
    return tracks


if __name__ == "__main__":
    token = get_token()
    for t in search_tracks(token, "artist:YOASOBI year:2023"):
        print(t["name"], t["album"]["release_date"], t["external_urls"]["spotify"])

環境変数SPOTIFY_CLIENT_IDとSPOTIFY_CLIENT_SECRETを設定して実行すると、条件に合う曲を最大30件、曲名・発売日・Spotifyの再生URLの形で表示します。このコードは、Spotifyの応答形式をまねたローカルのモックサーバーに対して動かし、1回目の429でRetry-Afterの秒数だけ待って再試行すること、10件・4件と返ったところでページ送りを止めること、QUOTA_EXCEEDEDで処理を止めることを確認しました（2026年10月13日、Python 3.9.6＋requests 2.32.5）。以前の解説記事によくあるt["popularity"]での並べ替えは、開発モードでは値が返らずKeyErrorになります。

エラーの対処：401・403・429とquota超過

Web APIはHTTPのステータスコードで失敗の種類を返します。公式のAPI callsの定義に、開発モードで起きやすい原因を重ねると次のように読み分けられます。

403は見落とされやすいエラーです。開発モードのアプリには許可リストに登録していないユーザーでもログインできてしまいますが、そのユーザーのトークンでAPIを呼ぶと403が返るとQuota modesに書かれています。テストユーザーを増やしたのに動かないときは、User Managementへの登録と5人の上限を先に確認します。

レート制限は、直近30秒のローリング窓に入った呼び出し数で判定されます。超えると429が返り、通常はRetry-Afterヘッダーに待つべき秒数が入っているので、その秒数だけ待ってから再試行します。開発モードにはこれとは別にquota（呼び出し枠）があり、エンドポイントのグループごとに共有の上限がかかります。2026年7月の変更で、quotaはClient ID単位ではなく開発者アカウント単位で数えるようになったため、アプリを25個に分けても枠は増えません。quotaを超えたときも429ですが、本文のreasonがQUOTA_EXCEEDEDになるので、上のコードのように区別して処理を止めます。

一括取得が使えないアプリでは、曲IDが50個あればGET /tracks/{id}を50回呼ぶことになります。公式のレート制限ガイドが勧める一括取得は開発モードでは使えないため、代わりにプレイリストのsnapshot_idを控えて変更がないときは再取得しない方法と、画面に必要な曲だけを取る設計で呼び出しを減らします。取得結果を手元に長く溜めることは、規約の「運用に厳密に必要な範囲を超えて保存しない」という条件に触れるため、キャッシュは一時的なものに留めます。

よくある質問

Spotify Web APIは無料で使えますか？

呼び出し単位の料金はありません。ただし開発モードのアプリは所有者のSpotify Premium加入が必須で、Premiumが切れるとアプリが止まります。再生操作のAPIは、操作されるユーザーもPremiumである必要があります。

開発モードのアプリは何人まで使えますか？

1アプリあたり5ユーザーまでで、ダッシュボードのUser Managementで名前とメールアドレスを登録した人だけが使えます。それ以上に広げる拡張クォータモードは、2025年5月15日から月間アクティブユーザー25万人以上の法人だけが申請できます。

RecommendationsやAudio Featuresの代わりはありますか？

公式の代替エンドポイントはありません。2024年11月27日以降に作ったアプリでは、Recommendations・Related Artists・Audio Features・Audio Analysisのいずれも使えません。取得した楽曲データでAIモデルを学習させて代わりにすることも、Developer Termsで禁止されています。

他人のプレイリストの曲一覧は取得できますか？

新しい制限がかかる開発モードのアプリでは、自分が共同編集者になっているプレイリストを除いて取得できません。GET /users/{id}/playlistsは廃止され、GET /playlists/{id}/itemsやGET /playlists/{id}のitemsが返るのは、自分が所有するか共同編集者になっているプレイリストだけです。

Pythonで使うにはライブラリが必要ですか？

Spotify専用のラッパーライブラリは必須ではありません。本文のコードでは外部ライブラリのrequestsを使うため、実行前にpython -m pip install requestsでインストールします。ラッパーライブラリを使う場合は、2026年2月の変更（/itemsへの改名、PUT /me/libraryへの統合、一括取得の廃止）に対応した版かをリリースノートで確かめてください。

関連記事

• OAuth 2.0とは？仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説
• 認可コードフローとは？認可リクエストからトークン交換までの実装手順と検証設計を解説
• リフレッシュトークンとは？トークンローテーションの仕組みと更新フロー・寿命設計を実装者向けに解説
• API認証の設計｜方式選定マトリクスとトークン寿命・監査ログの決め方
• X API（旧Twitter API）の従量課金と使い方｜単価・レート制限・実装を解説