AI に BPM を尋ねる機能を、Cloudflare の Clairic で速くした

「AI に BPM を尋ねる」は、曲名（音声ファイルから BPM を測ったあとなら、そのファイル名）を入れると Web を検索し、検索結果から BPM の候補を取り出して並べる機能です。この取り出す部分を、OpenAI の gpt-5-mini から、Cloudflare が出したばかりの Clairic に替えました。Clairic は、文から値を取り出すことに絞ったモデルです。正解の BPM を 1 つめに出せた曲は少し増え、取り出しにかかる時間は 4 秒台から 0.4 秒ほどになっています。

Clairic とは

Clairic は、Cloudflare が 2026 年 10 月 19 日にプレビューとして出したモデルです（Cloudflare のブログ）。文章を書かずに、入力から決まった型（文字・数など）の値だけを取り出します。

渡すのは、読ませる文（API の項目名は state）と、取り出したい項目（fields）です。項目ごとに、文字・数・日付・期間・リストなどの型と、何を取り出すかの説明を書きます。

{
  "state": "User input: YOASOBI アイドル\n\nSearch results:\n[1] Key, tempo & popularity of アイドル By YOASOBI | Musicstax\n…",
  "fields": {
    "bpm": { "type": "number", "integer": true, "instructions": "The BPM of the song named in the user input…" },
    "song_name": { "type": "text", "instructions": "The title of that song…" },
    "other_bpms": { "type": "list", "items": "number", "instructions": "Other BPM values for the same song…" }
  }
}

返ってくるのは、項目ごとの値と、入力に値がない確率（p_null）、確信度です。文章を生成しないので、モデルが書いた JSON を読み解く処理は要りません。Cloudflare は、同じく Cloudflare の判定のモデル Clef と組み合わせる使い方を勧めています。Clairic が値を取り出し、Clef がその値で判断し、文章が要るところだけ LLM に書かせる、という分担です。Metronome.fm では、判定には Clef ではなく、すでに使っていた Jev（後で書きます）を使っています。

料金は入力 100 万トークンあたり $0.10 で、出力の料金は書かれていません。Clairic は Workers AI のモデルなので、Metronome.fm がほかの AI を呼ぶのに使っている Cloudflare の AI Gateway から、そのまま呼べます。

検索結果から BPM を取り出す

「AI に BPM を尋ねる」は、3 つの段で動いています。

1. 入力が曲名やファイル名として探せるかを、判定だけをするモデル Jev で分類する（曲名と関係ない入力は、1 日に使える回数を減らさずに、書き直しを促す）
2. 入力に「BPM」を付けて、Linkup で Web を検索する（上位 5 件）
3. 検索結果から BPM の候補を取り出す

替えたのは 3 つめです。これまでは gpt-5-mini に、検索結果から曲名・アーティスト・BPM の組を最大 10 個、JSON で書かせていました。

Clairic のリストには、文字・数・日付しか入れられません。「曲名・アーティスト・BPM」の組は並べられないので、いちばん確かな 1 曲の BPM・曲名・アーティストを取り、同じ曲のほかの BPM（版違いや、倍・半分のテンポ）を数のリストで取ることにしました。同じ曲でも、どの音符を 1 拍と数えるかで、倍や半分の BPM が書かれていることがあります。

Clairic だけでは足りなかったところ

最初に、多くの人が調べそうな曲名 13 件と、録音のファイル名 3 件を混ぜた 16 件で、gpt-5-mini と比べました。曲の 13 件のうち 12 件で、1 つめの BPM が gpt-5-mini の候補と同じでした。外れたのは次のようなところです。

曲ではない入力にも BPM を返す

「practice take 2」「20261008_練習」のような録音のファイル名でも、Clairic は BPM を返しました。検索結果に出てきたメトロノームのページの「60 BPM」を拾っていて、確信度も 0.83 と高く出ます。Clairic は文の中の値を取り出すだけなので、それが頼まれた曲の BPM かどうかまでは判断しません。

そこで、「検索結果に、頼まれた曲の BPM があるか」を Jev にも聞くようにしました。Jev は、yes か no で答える問いに、yes の確率を返します。Clairic と同時に呼ぶので、待ち時間はほとんど増えません。Jev の yes の確率は、曲の 13 件が 0.98 以上、曲ではないファイル名 3 件が 0.00 で、はっきり分かれました。yes が 0.5 より低ければ、候補を空にします。

読み違えた BPM

「01 Bohemian Rhapsody (Remastered 2011)」では、BPM を 744 と答えました。確信度は 0.12 で、正しく取り出せたものは 0.46 以上でした。そこで、1 つめの BPM は確信度が 0.3 より低ければ捨てます。ほかの BPM のリストも、値ごとに確信度が返るので、1 つずつ同じ 0.3 を境に捨てています。

曲名を URL の文字から取ってしまう

画面には曲名も出します。「YOASOBI アイドル」の曲名を、Clairic は「aidoru」と答えました。検索結果のタイトルには「アイドル」とあるのに、songbpm.com の URL（/@yoasobi/aidoru-…）の文字をそのまま曲名にしていました。いまは、Clairic に渡す文から URL を抜いています。抜くと、「アイドル」「Lemon」「夜に駆ける」のように、タイトルどおりの名前になりました。

正解のわかっている 49 曲で比べる

gpt-5-mini と同じ答えかを見るだけでは、どちらが正しいかはわかりません。BPM の正解がわかっている曲として、フリー素材の曲を多く公開している作曲者 Kevin MacLeod の 49 曲を使いました（BPM も作曲者が公開しています）。「Kevin MacLeod 曲名」で尋ねて比べ、検索結果は両方に同じものを渡しています。表の上の 4 行は重ならない分け方で、足すと 49 曲です。「候補のどこかに正解」は、2 つめ以降の候補も含めて数えた別の数です。

正解は Clairic + Jev のほうが 4 曲多く、違う BPM を出したのは半分以下でした。違う値が出ると、使う人はそれを正しいと思って使ってしまいます。候補なしなら、別の書き方で探し直せます。一方、gpt-5-mini は版違いを多く並べるので、候補のどこかに正解がある曲は少し多くなっています。

正解の BPM が検索結果の文に書かれていた曲は、49 曲中 39 曲ほどでした。残りの 10 曲ほどは、どちらのモデルでも当てようがありません。また、この 49 曲はフリー素材の曲で、多くの人が調べる曲ではありません。最初の 16 件をここまでの直しを入れた形で比べ直すと、gpt-5-mini と同じ答えが 14 件でした。

費用

1 回尋ねるのにかかる費用は、開発用の環境で呼んだときの AI Gateway のログから、1 回あたりに割って出しました。取り出しの費用は検索結果の長さで変わるので、16 件と 49 曲の両方の値を幅で書いています。

取り出しの部分は半分以下になりましたが、費用の大半は検索なので、合計では 1 割ほどの差です。Clairic は 1 回の呼び出しの中で項目を 3 回に分けて読み、毎回検索結果を全部読みます。そのため、1 回の取り出しの入力は、16 件では平均 5,000 トークンほどになりました。それでも単価が安いので、gpt-5-mini より安く済みます。

Clairic はプレビューなので、呼び出しが失敗したとき（429 や通信エラー）は、サーバーのログに警告を残し、gpt-5-mini で取り出し直すようにしています。コードでは、どちらで取り出すかを定数 1 つで切り替えられます。

AI に BPM を尋ねてみてください

アプリのメニューの「AI › AIにBPMを尋ねる」か、A キーで開きます。曲名やアーティスト名を入れて探し（50 文字まで）、候補の「適用」を押すと、その BPM になります。音声ファイルから BPM を測ったあとに尋ねると、ファイル名がそのまま入り、曲名を含むファイル名ならその曲を探せます。

使い方は、マニュアルの「AI と音声で BPM を探す」の章にまとめています。音声ファイルやマイクの音からテンポを測る方法も、同じ章にあります。