【ITニュース解説】I built a headless Spotify CLI that sequences better playlists than the app — and survives Spotify renaming its API mid-flight

Spotifyの公式アプリは、新しい音楽を見つけることには優れているが、プレイリストの曲順を整理することには課題がある。例えば、イベントのために2時間のプレイリストを作ったのに、アプリが「セット」の概念を理解していないため、バラードの直後にアップテンポな曲が来てしまうような経験は多くの人がしているだろう。この課題を解決するために開発されたのが、「setlisted」というオープンソースのコマンドラインツールだ。

setlistedは、ユーザーインターフェース（画面）を持たず、コマンド（命令文）を打ち込むことで操作する「ヘッドレス」なツールである。このツールは、Spotifyアプリではできない3つのことを実現する。一つ目は、同じ曲ばかりが繰り返されない「発見ミックス」を作成することだ。Spotifyのアルゴリズムが繰り返し提案するようなお馴染みの曲だけでなく、より幅広い楽曲を探索するプレイリストを作ることができる。二つ目は、イベント向けに正確な時間（例えば90分）に合わせたプレイリストを作成することである。アプリのように大まかな長さではなく、指定した時間にぴったり合うように曲を選んでくれるため、手動で調整する手間が省ける。そして最も興味深いのは三つ目の機能で、これは曲の「メタデータ」だけを使って、プレイリストに自然な「流れ」を作り出すことだ。ウォームアップから始まり、徐々に盛り上がり、ピークに達し、そしてクールダウンへと続くような一連の曲順を自動で組んでくれる。この機能はsetlistedが独自に作成したプレイリストだけでなく、ユーザーがSpotifyにすでに持っているどんなプレイリストに対しても適用できる。つまり、バラバラに並べられた曲の集まりを、一つの美しい流れを持ったセットに変えることができるのだ。このツールは特定のジャンルに限定されず、ジャズラップからアフロビーツまで、様々なジャンルの音楽に対応できる。これは、個々の曲のジャンルではなく、「セット全体の流れ」という抽象的な構造に基づいて曲順を考えるように設計されているからだ。

なぜ「メタデータだけ」という制約が重要なのか、これには重要な理由がある。プログラミングの現場で、他のサービスが提供する機能や情報（「API」と呼ぶ）を利用して何かを開発する場合、その情報がいつまでも安定して利用できるとは限らない。特に、曲の詳細な音響分析データやジャンルタグといった「リッチな情報」は、サービス提供側が開発者へのアクセスを制限する際、真っ先に利用できなくなる可能性が高い。setlistedは、このような状況を避けるため、長期間安定して提供されてきた「耐久性のあるメタデータ」だけを使って作られている。これは、もしAPIから一番便利な情報が突然提供されなくなっても、プログラムが完全に停止するのではなく、出力の質が少し下がる程度で済むようにするための設計原則である。この原則は、開発者が苦い経験から学んだ教訓に基づいている。

実際に開発の途中で、この原則の重要性を身をもって体験する出来事があった。setlistedがSpotifyのAPIからプレイリストの情報を読み取る際、突然意味不明なデータが返ってくるようになったのだ。エラーメッセージが出ないため、プログラムは問題なく動き続けているように見えたが、生成されるプレイリストは完全に間違っていた。原因はSpotify側のAPIの変更だった。APIが返す情報の中の、あるフィールド（データ項目）の名前が変更されていたのだ。さらに厄介なことに、古いフィールド名もまだ存在していたが、そこには以前のような曲のオブジェクトではなく、「True」というブーリアン値（真偽を示すデータ）が入っていた。そのため、setlistedは古いフィールド名を読み取り、ブーリアン値を曲のデータだと勘違いして処理を進めてしまっていた。プログラムはエラーを検出せず、期待するデータの形とは違うのに、それが間違っているとは気づかずに間違った出力を生成し続けたのだ。

この経験は、システムエンジニアを目指す上で非常に重要な教訓となる。APIは、サービス自体が停止しなくても、フィールド名の変更や、古いフィールドに異なる型の値を残すことで、プログラムを壊すことがある。この問題の解決策は、単に新しいフィールド名を使うだけでなく、プログラムが読み込んだデータの「型」を検証するようにすることだった。例えば、曲のデータが来るべき場所でブーリアン値が返された場合、それを間違いとして明確に検出する仕組みが必要だったのだ。このようなサイレントな変更は一度きりではなく、他にも開発者向けのメタデータが突然消失するといった形で発生し、いずれもプログラムの出力が微妙に間違っていることに気づくまで、問題は見えないままだった。

このような経験から、他社のAPIを利用してシステムを構築する際に役立つ四つの重要な原則が導き出された。一つ目は、「値の型を検証すること」だ。単にフィールドが存在するかどうかだけでなく、そのフィールドに期待する型のデータが入っているかを必ず確認する必要がある。フィールド名が変更され、古いフィールドにブーリアン値が残された場合でも、存在チェックやNULLチェックだけでは見破れないため、型チェックが不可欠となる。二つ目は、「耐久性のある情報に基づいて構築し、リッチな情報はボーナスとして扱うこと」だ。最も詳細で便利な情報は、制限の対象になりやすい。もしプログラムがこれらの情報に完全に依存している場合、APIの仕様変更一つで機能しなくなるリスクがある。そうではなく、基本的な情報で動作するように設計し、リッチな情報があればさらに良い出力ができる、という設計にすることが賢明だ。三つ目は、「フィールド名が変更された場合はサイレントな問題となるため、APIが生で返すデータを比較すること」だ。プログラムの出力が微妙に間違っているのにエラーが出ない場合、自分のプログラムのロジックを疑うのではなく、まずAPIが実際に返している生データを見て、フィールド名などに変更がないかを確認するべきである。そして四つ目は、「ヘッドレスで決定論的な設計にすること」だ。setlistedのようなコマンドラインツールは、同じ入力に対して常に同じ出力を返す「決定論的」な性質を持つ。これにより、「以前はこの入力でこの結果が出たのに、今は違う」という具体的な比較が可能になり、問題の原因特定が容易になる。グラフィカルなユーザーインターフェース（GUI）を持つツールの場合、なんとなく「おかしい」と感じるだけでは、問題の切り分けが難しいことがある。

setlistedはオープンソースとして公開されている。もしあなたがイベント用のプレイリストを作ったり、新しい音楽の発見ミックスを試したり、あるいはただプレイリストに自然な流れを持たせたいと考えるなら、このツールはまさにそのために作られている。そして、Spotifyが次にAPIをこっそり変更しても、動作し続けるように設計されている。このツールから音楽の楽しみだけでなく、APIを扱う上での重要なエンジニアリングの教訓を学べるだろう。特に、自分が制御できない外部のAPIからデータを読み込む際には、必ずそのデータの型をチェックすること、そして将来的に利用できなくなる可能性が高いフィールドに安易に依存しないこと。この二つの習慣だけで、ブーリアン値が曲だと騙されて過ごした午後のような無駄な時間を避けられるはずだ。