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

Spotify Web APIでできるのは、曲・アルバム・アーティスト・ポッドキャストのメタデータ取得、カタログ検索、自分のプレイリストの作成と編集、ライブラリへの保存、再生の操作です。ただし2026年2月11日に開発モード（新しく作ったアプリの既定の状態）の仕様が大きく変わり、アプリ所有者のSpotify Premium加入が必須になったうえ、他ユーザーのプレイリスト一覧や、自分が所有者でも共同編集者でもないプレイリストの曲一覧、複数曲の一括取得、アーティストの人気曲、popularity（人気度）の値が使えなくなりました。この記事では2026年9月時点の公式ドキュメントをもとに、今のアプリでできること・できないことを先に整理し、Client IDの取得、redirect URIの設定、認証フロー、Pythonでの検索、429エラーの対処までを順に説明します。

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

• できること（開発モード）：1件ずつのメタデータ取得、検索（1回最大10件）、自分のプレイリストの作成・編集、ライブラリの保存と取得、よく聴く曲やアーティスト・最近再生した曲の取得、再生の操作（操作される側のユーザーがPremiumの場合のみ）。
• できないこと：Recommendations・Related Artists・Audio Features・Audio Analysis（2024年11月27日以降の新規アプリ）。一括取得・新譜とカテゴリ一覧・アーティストの人気曲・他ユーザーのプロフィールとプレイリスト、popularityやfollowersの値（2026年2月以降の開発モード）。
• 料金と人数：呼び出し単位の料金表は無い。代わりに開発モードはアプリ所有者のPremium加入が必須で、使えるのは1アプリ5ユーザーまで。拡張クォータモードの申請は2025年5月15日から法人のみ・月間アクティブユーザー25万人以上が条件。
• 認証：ユーザーのデータを扱わないならClient Credentials、扱うなら認可コードフロー（ブラウザ・モバイルはPKCE）。Implicit Grantとhttp://localhostのredirect URIはもう使えない。
• 期限：アクセストークンは1時間、リフレッシュトークンはユーザーの認可から6か月で失効する。

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

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

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

再生の開始・一時停止・スキップ・音量変更などのPlayer APIは、公式リファレンスに「Spotify Premiumのユーザーでのみ動作する」と明記されています。無料プランのユーザーはこれらのAPIで再生操作できないため、操作ボタンを無効化するなど、Premium利用者向けの機能であることが分かる設計にします。オーディオブックは米国・英国・カナダ・アイルランド・ニュージーランド・オーストラリアの市場に限られ、日本のmarket=JPでは返りません。

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

2024年11月の廃止の対象は、同日以降に登録したアプリと、拡張申請を出していない開発モードの既存アプリです。Audio Featuresでテンポやdanceabilityを分析する解説記事はいまも検索上位に多く残っていますが、これから作るアプリでは再現できません。

2026年2月の変更は、新規の開発モードアプリに2月11日、既存の開発モードアプリに3月9日から適用されました。エンドポイントだけでなくレスポンスのフィールドも減っており、曲・アルバム・アーティストのpopularity、アーティストのfollowers、GET /meのemail・country・productが返りません。一度削除されたexternal_idsは2026年3月の変更で復活したため、ISRCによる楽曲の突き合わせは引き続きできます。プレイリストの中身（items）は、自分が所有するか共同編集者になっているプレイリストでしか返らず、他人の公開プレイリストはタイトルなどのメタデータだけになります。

開発モードでは作れない用途：人気順ランキング・他人のプレイリスト分析・AI学習

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

用途によっては規約の側で止まります。2025年5月15日発効のSpotify Developer Terms（バージョン10）は、SpotifyのプラットフォームやコンテンツをAI・機械学習モデルの学習に使うこと、モデルに取り込むことを禁じています。取得したデータを広告ネットワークやデータブローカーへ渡すこと、運用に必要な範囲を超えてデータベース化することも禁止事項です。楽曲データを集めて分析・学習に回したい場合は、Spotify以外のデータ源を先に検討してください。

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

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

許可リストに入っていないユーザーは、ログイン自体はできてもAPIを呼ぶと403が返ります。以前は25人まで登録できたため、社内の検証やβテストの人数計画は見直しが必要です。2026年2月時点で既に6人以上を登録していたアプリは、その人数をそのまま保持できます。

拡張クォータモードは、2025年5月15日から法人からの申請だけを受け付けています（公式のQuota modes）。条件は法人登録があること、公開済みで稼働中のサービスであること、月間アクティブユーザー25万人以上、Spotifyの主要市場で提供していること、商業的な実現性、規約の順守です。Spotifyは告知の中で、それまでの拡張申請の95%超がセキュリティ・プライバシー・ライセンスの基本基準を満たしていなかったと説明しています。新規の個人開発アプリを不特定多数のSpotifyユーザー向けに提供する計画では、個人のまま拡張クォータモードへ申請できないことを前提に判断してください。

アプリ作成とClient ID・Client Secretの取得手順

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」で再発行できます。Secretを安全に置けないアプリは、後述のPKCEを使えばSecretなしで認可コードフローを組めます。

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か月で失効し、アクセストークンを更新しても延長されないと説明されています。長く動かすアプリには、6か月ごとにユーザーを同意画面へ戻す再認可の導線を最初から組み込んでおきます。トークンの寿命やローテーションの設計はリフレッシュトークンの更新フローと寿命の設計で整理しています。

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の形で表示します。このコードは、429のあとに再試行する流れと、10件未満でページ送りを止める流れを、Spotifyの応答形式をまねたローカルのモックサーバーで確認しました（Python 3.9＋requests）。以前の解説記事によくあるt["popularity"]での並べ替えは、開発モードでは値が返らずKeyErrorになります。

429エラーとquota超過の対処

Spotifyのレート制限は、直近30秒のローリング窓に入った呼び出し数で判定されます。超えると429が返り、通常はRetry-Afterヘッダーに待つべき秒数が入っているので、その秒数だけ待ってから再試行します。

開発モードにはこれとは別にquota（呼び出し枠）があり、エンドポイントのグループごとに共有の上限がかかります。2026年7月の変更で、quotaはClient ID単位ではなく開発者アカウント単位で数えるようになりました。アプリを25個に分けても枠は増えません。quotaを超えたときも429ですが、本文のreasonがQUOTA_EXCEEDEDになるので、上のコードのように区別して処理を止めます。

一括取得の廃止によって、50曲の情報を集めるのに50回のリクエストが必要になりました。公式のレート制限ガイドはいまも「一括取得APIを使って呼び出しを減らす」と勧めていますが、開発モードではその手段がありません。代わりに使えるのは、プレイリストの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）の従量課金と使い方｜単価・レート制限・実装を解説