OsuGAIの開発：AIが生成するosu! standard beatmap

OsuGAIは、DanceGAIにとって初めてのosu! standard向けモデルです。osu! standardはosu!の元祖モードで、ヒットサークル、スライダー、スピナーがプレイフィールド全体に配置されます。本日、osu! mania向けのManiaGAIと並んでベータ版として公開しました。このレポートでは、OsuGAIが譜面をどう表現しているか、何から学んだか、どう学習したか、何を測定したか — そして同じくらい率直に、まだ何がうまくいっていないかを説明します。

osu! standardがosu! maniaより難しい理由

osu! maniaの譜面は、レーンに並んだノーツです：ジェネレーターが決めるのは、ノーツがいつ来るか、そして4〜9レーンのどれに落ちるかです。osu! standardでは、すべてのオブジェクトに512 × 384のプレイフィールド上の位置もあり、プレイヤーはそこまで動かなければなりません。そのため、maniaにはない問題が3つ加わります：

• 2次元の動き。オブジェクト間の間隔、ジャンプの角度、流れこそが、standard譜面の良し悪しの大部分を決めます — しかもそれらは連続的な値であり、いくつかのレーンから選ぶものではありません。
• スライダーの形状。スライダーは長さと速度を持ち、ときには往復もする曲線です。音楽にも、周囲のオブジェクトにも合っていなければなりません。
• 読みやすさ。オブジェクトは叩く前に現れ、重なり、スタックします。タイミングが完璧でも、読むのが不可能な譜面はありえます。

表現：まずゲームプレイ、エディターのオブジェクトはその次

モデルにosu! standardを教えるいちばん素直な方法は、エディターのオブジェクト —「(x, y)にサークル」「この制御点を持つスライダー」— を与えることです。私たちも最初はその系統を試しました。OsuGAI v1はそうせず、譜面をプレイされるときの姿で記述し、あとからオブジェクトに戻します。1拍は5つのトークンで表されます：

• インタラクショントークン1つ：その拍の間のボタンの状態を、1拍あたり48セルでサンプリングしたもの — 押しているか離しているか、それだけです。タップは短い押下、スライダーやスピナーは長い押下です。このトークンは学習譜面で最も頻度の高い4,096通りの48セルパターンのどれかで、学習データの拍の99.87%、ホールドアウトの拍の99.69%をカバーします。
• 空間トークン4つ：その拍の中の最大4つの瞬間に、カーソルがどこにあるか — すべての押下、すべての離し、そして残りは最も長いホールドを均等に分けた点です。位置は4ピクセル単位のグリッド（128 × 96セル）上にあるため、丸め誤差は最大でも2.83ピクセルです。使わないスロットは空になります。

つまり1拍あたり5スロットで、語彙は16,385トークン（4,096のボタンパターンと12,289の位置）の1つだけです。空間トークンが表す瞬間はボタンパターンだけから導かれるので、モデルがオブジェクトの種類を学ぶ必要はありません。

なぜ意図されたゲームプレイを、エディターの表現から切り離すのか？ 理由は2つあり、どちらも学習を始める前に人のリプレイで測定しました。1つ目に、エディター上の選択の多くはプレイでは見えません：カーソルだけから短いスライダーとサークルを見分けられたのは、43–45%の場合だけでした — つまりオブジェクト単位の細部はデコーダーが決めればよいことで、モデルが推測しなければならないものではありません。2つ目に、ゲームプレイの記述では重要な情報がほとんど失われません：理想化したボタン状態と人のカーソル軌跡から再構築した譜面は、オブジェクトを考慮した記述から再構築した譜面と同じくらい、ほかのプレイヤーのリプレイで叩かれていました（97.9%対98.0%）。代わりにプレイヤーの実際のボタン状態を使うと78.5%まで下がりました — 実際の押下はノイズが多すぎて学習に向かないため、ボタントークンは理想化しています。

学習データ

コーパスはRanked、Approved、Lovedのosu! standard譜面です — 117,920譜面のうち117,918譜面の変換に成功しました。検証データとホールドアウトは曲が重複しないように分けています：そこに含まれる曲は、学習データには一切出てきません。ManiaGAIと同じく、すべての譜面のタイミングはまず私たち自身のタイミング検出器のグリッドに移しているので、モデルは生成時に受け取るのと同じ種類のグリッドで学習します。難しいという理由で除外した譜面はありません。

カーソル位置の出どころ：osu!lazerのAutoのリプレイ

譜面ファイルに書かれているのはオブジェクトの位置であって、オブジェクト間でカーソルがどう動くかではありません。私たちは空間トークンを、osu!lazerのAutoのリプレイ — ゲームに組み込まれた完璧なプレイヤー — から導いています。そのカーソルのロジックをPythonに移植し、20譜面で実際のゲームと照合しました：264,716フレーム、フレーム数は同一、ボタンやスタックの不一致はゼロ、平均の差は0.014ピクセルです。91譜面のベンチマークでは、Autoのカーソル軌跡からデコードし直した譜面が、ほかのプレイヤーの人間のリプレイで99.7%叩かれていました。

正直に言うべき注意点が1つあります：Autoは人間ではありません。Autoは各スライダーの正確なパスをたどるので、そのカーソルは「元のスライダー形状を位置として書き出したもの」に近くなります — 元のスライダーパスの72%はAutoから4ピクセル以内で読み戻せますが、1人の人間のリプレイからでは1%です。そのためOsuGAI v1が学ぶのは、mapperがどこに物を置くかであって、人が実際にどう動くかではありません。

アーキテクチャ

1. 音楽
2. タイミンググリッド
3. Planner
4. Noter
5. デコーダー
6. .osu / .osz

OsuGAIはManiaGAIと同じエンジン（PlannerとNoterで解説）で動き、モード固有の部分だけを入れ替えています：

• Planner（流用）。以前のosu! standardの研究から変えていない小さな拡散モデルが、オブジェクトがまだ何もない段階で曲の各パートを設計します：その★レベルと、スタイルの記述 — スライダーの割合、角度の性格、間隔の不規則さ、ストリームの間隔、リズム — です。
• Noter（新規）。約6,410万パラメータのMaskGIT方式のTransformerが、プラン、音声、難易度設定（サークルサイズ、アプローチレート、オーバーオールディフィカルティ、スライダー速度）に従って、すべての拍の5つのトークンを埋めます。学習では、位置の完全一致の精度に加えて、目標から16ピクセル以内に収まった位置にも部分点を与えています。
• デコーダー（ルールベース、往復対応）。ゲームプレイをオブジェクトに戻します：押下はヒットサークルになり、長い押下は、カーソルが中心の周りを1.5拍以上回っていればスピナー、そうでなければスライダー — スライダーボールを予測された軌跡の近くに保てる、最も単純な直線、円弧、曲線 — になります。はっきりとした、等間隔の折り返しは往復スライダーになります。ニューコンボは固定のルールに従います。

学習：4ラウンド

Noterは以前のosu! standardモデルから初期化（ウォームスタート）し、時間上限付きのエポック4回（各約46分）を1ラウンドとして4ラウンド学習しました — RTX 4070 Ti SUPER（16 GB）1枚で合計約14時間、GPUメモリの使用量はピークで約6 GBです。各ラウンドの後に評価セットを生成しました：ホールドアウトの8曲 × 22通りの設定 = 176譜面です。

• 検証損失は、4ラウンドを通じて3.1389から2.9570に下がりました。
• 構造的な妥当性：どのラウンドでも、評価用の176譜面はすべて有効なosu! standard譜面でした — 正しいオブジェクトで、スロット違反もありません。
• 難易度とスタイルが反応する：8曲中8曲で、目標に合わせて実測★レートが上がり、4つのスタイル軸のそれぞれも8曲中8曲で譜面を正しい方向に動かしました — ただし、セクションごとにプランに従う力はまだ弱いままです。
• 決定的：同じ曲と同じシードからは、バイト単位で同一の.osuファイルが得られます。

速度。その開発用GPUでは、Flower Dance（4:22）の8難易度が、時間を計測した各段階 — 音声の準備、タイミング、音声特徴量、プランニング、そして約11〜12秒のノーツ生成 — を通して約16〜18秒かかりました。デコードとファイルの書き出しは、CPU上で譜面1つあたり平均約0.6秒加わります。これはローカルのベンチマークです：本番環境は別のクラウドGPUで動いており、OsuGAIの本番環境でのレイテンシはまだ測定していません。

制限事項

有効な譜面であることと、楽しい譜面であることは同じではありません。上の数字のどれも、OsuGAIの譜面が本気でプレイするのに良いものだとは言っていません。わかっている問題点は次のとおりです：

• 難易度の上振れ。譜面は目標より難しくなり、上の難易度ではずっと難しくなります：Flower Danceでは、目標7.43、8.71、10が、実測で9.28、13.49、13.99の★になりました。そのためWebサイトでは目標を★1–★6に限り、常に実測のレートを表示しています。
• 自分自身と交差するスライダー。最終ラウンドでは、生成されたスライダーの3.3%が自己交差しています（最初のラウンドの後は2.4%）。元の譜面では0.1%です。
• スライダー形状の不具合。一部のスライダーは速度の上限に達しており（最終ラウンドで2.8%）、往復スライダーは人の譜面より少なめです（スライダーの6.1%対21%）。
• Autoによる教師データ。カーソルの軌跡は人ではなくAutoのものです：モデルが学ぶのはオブジェクトの配置であって、人の動きではありません。
• オーバーフローと語彙のフォールバック。学習データの拍の0.58%は4つより多くの位置を必要とし、最初の4つだけが残されます。拍の0.13%は4,096のボタンパターンから外れ、最も近いものを使います。最も影響を受けるのは、非常に密度の高い譜面です。
• 人による幅広いテストプレイはまだ。これまでのチェックはすべて自動のもの、または記録されたリプレイにもとづくものです。それを始めるのが、このベータ版です。

次の予定

• より良い難易度の調整 — 信頼できる目標と、★の全範囲の復活。
• よりきれいなスライダー形状 — 自己交差や速度の頭打ちを減らし、より自然な往復に。
• 人のゲームプレイデータ — オブジェクトがどこにあるかだけでなく、人がどう動くかを学ぶ。
• より強いスタイル調整 — 平均としてだけでなく、セクションごとに譜面が従うバー。
• osu!のさらなるモード — ロードマップでは、次はosu! taikoとosu! catchです。

このモードは初めて？ ゲームそのものはosu! standardとは？で説明しています。OsuGAIがManiaGAIと共有するエンジンについてはテクノロジーのページをご覧ください。