ポップンの譜面をTexTage風に見れるサイトを作りました。
↓↓↓
pop'n music ポップンミュージックの譜面をTexTage風に見れるサイトを作成しました
— 副会長 (@ShinnichiPr) 2026年2月13日
譜面の拡大縮小やランダム配置入替などの機能があります
譜面は順次追加中です。よろしくお願いしますhttps://t.co/7JsFYGWILY
忙しい人向け解説
IIDXでいうところのTexTage [テクステージ] (てふたげ) みたいなサイトです。レベル・シリーズ・曲名やジャンル名で絞り込んで、見たい譜面をタップすればノーツの配置が出てきます。
記事では主に裏側の仕組みとかの話をしますが、「サイトの中身だけ知りたい」という方はあとは触ってもらえれば大丈夫です。
なにができるか
譜面の拡大・縮小ができます
一列表示もできます
ミラーやランダムもできます
ノーツの見た目も変えられます
ナイトモードも用意しているので見やすい方で見てください
以上がざっくりした紹介です。
以下は裏側の話になります。
裏側の仕組み
このサイトの譜面データは、
①トップページ [ポップンミュージック上級攻略Wiki]様に掲載されている、有志の方々が作成している譜面画像
②自分で撮影した譜面動画
が原料です。一部になりますが③動画サイトでも確認作業を行いつつ作っています。現在46以上の既存楽曲はほとんど①ですが、今後は②が中心になっていくと思います。
①はwikiをご覧になったことある方はご存じかと思いますが、あの画像をプログラムに食わせて、ノーツの位置や小節構造を機械的に読み取っています。
機械学習とかAIとかで読み取ってる？と思われるかもしれませんが、ここの認識処理自体はそういう大層なものではなくて、色と座標をもとにしたルールベースの画像処理です。赤いピクセルがこの辺にあれば赤ノーツ、青ければ青ノーツ、という素朴な判定をひたすら積み重ねています。AIの話は別にあるので後で書きます。
①画像がデータになるまで
処理の流れをざっくり説明します
まずwikiから譜面画像を集めてきて一覧に出します。（↓は管理用画面の一覧の感じ）
画像の中からノーツを色で検出し、「何色のノーツがどの座標にあるか」を記録します。検出したら白で塗りつぶします
次に小節線を検出します。ここで「小節線がどの座標にあるか」を記録します。
最後に、小節線の位置とノーツの位置関係から「〇小節目の〇レーンのXXにノーツがある」という情報を割り出していきます。
元の画像ではノーツと小節線が重なっているので、両方同時にきれいに検出するのが難しいです。だから最前面にあるノーツを消してしまって、残った小節線や拍線から改めてグリッド構造を検出する、という二段構えになっています。他にもBPMやロングノーツの検出があるので実際はもう何度か検出＆加工を繰り返しています。
情報が割り出せたら最終的に構造化データとして吐き出します。ここまでが自動処理で、1譜面あたり30秒ぐらいの処理です。
ただ精度に関して言うと良いというわけでもなくて、検知精度としては体感90％ぐらいといったところです。読み込ませて一発で100％正確に検出できる譜面はせいぜい2/3ぐらいで、残りは数ノーツ～数百ノーツのズレが発生します。ノーツ同士が近すぎて1個にまとまって検出したり、ロングポップ君の始点と終点がズレたり、小節線がノーツに完全に隠れて検出できなかったりなどです。
あと、譜面画像は作成者の方々の作風や見せ方のこだわりもあり、フォーマットが微妙に違ったりするので、どちらかというとそういう画像に対応するチューニング作業がメインでした。ありがたいことに近年作成された画像はかなりフォーマットが統一されていて検出がしやすいのですが、特に古めの画像が厄介だったりします。
なので残り1/3の正確じゃない譜面も、最終的には自分の目で確認して、おかしいところを手直ししています。
残りの10％を修正して完全自動化するとなると、多分処理すべき例外事項が増えまくって改修が終わらなくなるので、これぐらいがいい塩梅だと思っています。
そのため手作業で譜面を簡単に直せるように管理画面を整備するのに注力しました。htmlとjsで作っているブラウザで動くデータ編集画面です。
②動画がデータになるまで
続いて動画から検出を超シンプルに説明します。こちらはまだ譜面画像がない新曲や低難易度がメインです。今後はこっちをメインに据える予定です。
まずはプレーがてら動画を撮ります。
動画を射影変換して、フレームごとにノーツ、小節線を検出し、「このフレームのこのノーツと次のフレームのこのノーツが同じ」というような特定処理を行います。
「ノーツ/小節線が〇秒に出現する」という情報から「〇小節目の〇レーンのXXにノーツがある」という情報を割り出していきます。
あとは画像から検出したときと同じフォーマットに変換します。
最後に目視で確認しながら同じく管理画面で修正します。要するにコマ送りで画像検出をやるという①と同じことをやっています。使っているライブラリもOpenCV(cv2)で一緒です。
ちなみになぜ動画サイトではなくわざわざ撮りに行っているのかというと、もちろんポップンにお金を落とす目的もあるのですが、実用面でも撮影した動画の方が検出精度が高いからです。
フレームレートが安定している、スキンや色味が毎回同じ、動画サイト特有の画質の劣化がない、などメリットがあり、直撮りの方が優秀だったりします。
最終的にやっていることは譜面画像と同じく譜面を起こす作業なのですが、1ノーツずつ手打ちせずにすんでいる点が違いです。
そもそもなぜこんなことをしているのか — 構造化の話
もしかしたら「画像をそのまま貼ればいいのに、なんでわざわざデータに変換してるんだ」と思った方もいるかもしれません。ここではなぜその手間をかけているのかを説明します。
譜面画像は人間が見るためにデザインされたものです。人間の目には非常に分かりやすく、9レーンにノーツが並んでいて、下から上に時間が流れていて、色とレーンで押す場所が分かります。プレイヤーなら一目で「ここは同時押し」「ここは階段」と読めます。
一方でコンピュータにとって画像は色のついた点の集合体に過ぎないので、譜面画像を人間のようには全く解釈できません。
ここでやっていることは、画像から検知したノーツ情報を特定のフォーマットに変換（構造化）することです。データとして「何がどこにあるか」を明示してやると、コンピュータ側で扱いやすくなります。
手書きの楽譜とMIDIデータの違いのようなもので、どちらも同じ曲を表現しているけど、手書きの楽譜をスキャンし編集するのは骨が折れます。MIDIなら音の高さも長さも全部数値で入っているので、テンポ変更も移調もすぐできます。
このサイト（や、おそらくTextageも）同様の仕組みで拡大縮小やランダムを実装しています。
AIを利用した開発体制
このサイトの開発期間はだいたい3週間です。コードのほぼすべてをAIが書いています。そして私はそのコードをほとんど見てもいません。
使っているのはCursorというコーディングツールの月額$60（約9,000円）のPro+プランで、エディタの中にAIアシスタントが常駐していて、指示を出すとコードを書いてくれる、という仕組みです。
私の役割は設計と方向指示と最終判断です。「この処理はこういうアプローチでやってくれ」「出力はこういう形式にしてくれ」と方針を出すのが自分の仕事、それを受けてコードを書くのがAIの仕事という割り振りです。書かれたコード自体を逐一レビューすることもしていません。
ではコードを見ないで何を見ているかというと、処理結果になります。たとえば「この曲でノーツが1400個検出されるはずなのに1387個しかない」とか「この小節の3拍目にノーツが2個あるはずなのに動画ではマーキングされていない」とか、そういう目に見える結果の検証に時間を使っています。大事なのは、AIに人間が見て分かるデバッグ情報を出力させることです。処理の途中経過を可視化させて、それを見て正しいかどうか判断します。コードの正しさはコードを読んでも分からないことが多いですが、結果の正しさは譜面を知っているプレイヤーなら見れば分かります。私の判断できる形に持っていく/持ってこさせる、ということに時間を割いた形です。
また、「AIにコードを書かせた」というと最近はそんなに珍しい話なくなってきましたが、このサイトの場合は構想や設計の段階からAIに壁打ちしてもらっています。「この認識処理、こういうアプローチとこういうアプローチがあると思うんだけどどっちがいいか」「こういう画像でこういう不具合が出る、原因として何が考えられるか」みたいな相談を延々とやっていて、設計の意思決定にもAIが関わっています。要は「作らせて → 結果を見て報告して → 方針を修正させて → また作らせて」の繰り返しになります。
Cursorには月額$20のProプランもあって、コードを書かせるだけならそちらでも一応できます。ただ、構想から設計からゴリゴリAIに投げるやり方を採用したので、$20のプランだと使える量が全然足りず、かなりの部分を自力で補う必要が出てきそうでした。開発期間は3倍どころではなく伸びるでしょうし、そもそも延々と完成しないかも、という雰囲気があったので早々に上のプランに切り替えました。
人間よりAIの方が10倍質の良い実装を100倍のスピードでやってくれるので、ちょっと人間が手伝おうとするだけでかなりコストに跳ね返ってきます。
維持費の話 — このサイトを動かすのにいくらかかっているか
個人サイトは「維持費」や「更新の手間」が要因で死ぬことが多々あると思います。作っている間は楽しいものの、公開してしばらくすると月額の請求書が届き始めて、アクセスも伸びず、そのうち面倒になって放置・閉鎖のパターンです。
今のところこのサイトの維持費はドメイン代の年間約1,500円だけになります。アクセスが集中して過負荷になるとか、ポップンのアプデで急に1000曲追加されたりとかしない限りはずっとこれで行く予定です。
安い理由は大仰な構成にしてないからです。普通にWebサービスを作ろうとすると、データベースを用意して、APIサーバーを立てて、フロントエンドとバックエンドを繋いで、それをクラウドにデプロイして...みたいな構成になりがちです。構成が立派になればなるほど月額コストは膨らんでいきますし、そのどこかが壊れたらサイトが止まります。
このサイトではそういう構成を全部やめまして、100%静的なファイルだけで動いています。ホスティングにはGitHub PagesとCloudflareを使っていて、どちらも無料枠の範囲内です。ファイルを置いているだけなので壊れる箇所もほとんど無く、仮に自分が半年ぐらい放置しても、サイトは特に問題なく動き続けます。
これは技術的に「すごいことをやる」の逆で、むしろ「すごいことをやらない」という選択です。データベースもAPIサーバーも使わず、静的ファイルだけで成立する設計にしたことで、維持に必要な注意力とお金を限りなくゼロに近づけています。個人サイトで一番大事なのは作ることではなくて続けられることだと思っているので、なるべく飽きても放置しても死なないように意識はしました。作ってないものから不具合は出ないので、なんやかんや「作らなくて良いものは作らない」のが良いですね。
こういう機能が欲しい・こういう譜面情報が知りたいとかあったらこちらからどうぞ↓
