Roblox OA（2026年）：出題内容と突破のポイントを解説

Roblox のオンラインアセスメントに通れば、リクルーターから連絡が来ます。通らなければ、多くの場合そこで選考は終わります。OA は時間制限つきの自動採点コーディングテストで、最近の候補者の報告では、ソフトウェアエンジニアや新卒向けの職種では CodeSignal 形式のアセスメントが多いと言われていますが、プラットフォームや形式は採用サイクルごとに変わります。このガイドで扱うのは OA の段階だけです。当社の問題バンクにある実際の Roblox のアセスメントに出る問題の種類、採点が何を見ているか、サンプルが通るコードでも失敗する理由、提出後に何が起きるかを解説します。選考全体については、Roblox ソフトウェアエンジニア面接ガイドと Roblox データサイエンティスト面接ガイドをご覧ください。

重要ポイント

• 当社のバンクにある Roblox OA の問題は、実装量の多いシミュレーションに偏っています。崩れるグリッド、歩き回るロボット、パースが必要なログなどです。珍しいアルゴリズムを知っていることより、40〜80行の正しいコードを素早く書けることのほうが重要です。
• スコアを決めるのは隠しテストです。目に見えるサンプルは通っても、隠された大きな入力で O(n²) になる解法や、境界のタイムスタンプで壊れる解法は、理由の説明もなく不合格と採点されます。
• 当社のバンクでは、Roblox の SWE と ML のスクリーニングを通して2つのパターンが繰り返し出ています。ウィンドウ集計（ヒットカウンター、レートリミッター）と、更新ストリームのもとでの集計です。deque の削除境界を迷わず書けるようになるまで、両方を練習してください。
• 入力の制約が「コマンド文字列が 10^9 回繰り返される」となっている場合、採点側は「シミュレーションせず、不変条件を証明せよ」と伝えています。このサインに気づけることは、暗記したどのテンプレートよりも価値があります。
• プラットフォーム、制限時間、問題数はサイクルごとに変わります。多くの職種で従来は CodeSignal 形式でしたが、このガイドを含むどんなガイドよりも、届いた招待メールを信頼してください。

Roblox OA の実際（そして、どんな説明をどこまで信頼すべきか）

まず前提を断っておきます。これは重要な点です。オンラインアセスメントの運用面は、どの企業の選考プロセスでも最も安定しない部分です。以下の内容は、最近の候補者の報告と当社のバンクに寄せられた問題に基づくもので、あなたの招待内容を保証するものではありません。

そのうえで、最近の報告に見られる傾向です。Roblox は従来、ソフトウェアエンジニアや新卒向けの職種に CodeSignal 形式のアセスメントを送ってきました。当社のバンクにあるデータサイエンティスト向けのアセスメントの1件は、候補者自身が Python または R を選べる CodeSignal 形式の環境だったと明確に述べています。CodeSignal の General Coding Assessment の形式は、従来、難易度が上がっていく4問を約70分で解くものでした。そのスコアレポートを企業側がどう読むかは、当社の CodeSignal OA ガイドで詳しく解説しています。招待状に別のプラットフォームが書かれている場合は、Codility・HackerRank・CodeSignal の比較で、候補者にとって何が変わるのかを確認できます。

実用上の注意が2つあります。1つめに、CodeSignal のアセスメントでは画面やカメラによる監視が行われることがよくあります。ルールが細かいため、別の記事 CodeSignal は画面を録画する？ 2026年の監視・カメラ・本人確認のルールにまとめました。フラグを立てられてからではなく、開始前に読んでください。2つめに、このページは意図的に OA のみを扱っています。Amazon で Amazon OA ガイドを用意しているのと同じ切り分けです。電話面接以降の内容は、上記にリンクした Roblox の総合ガイドにあります。

ここからが変わらない部分です。どのプラットフォームで出題されるとしても、当社のバンクにある Roblox OA の問題の内容は驚くほど一貫しています。このガイドの残りでは、その内容を扱います。

シミュレーションが得意分野

Roblox での出題 — 数字のグリッドで連続部分を検出して崩す 数字の m×n グリッドが与えられます。まず、同じ数字が3つ以上横または縦に並んでいる連続部分をすべて見つけ、各連続部分の開始セルと長さを、行、列の順に報告します。次に、いずれかの連続部分に属するセルをすべて取り除き、残った数字を各列の中で下に落とし、上から補充します。

これは3マッチゲームのエンジンを小さくしたもので、ゲームプラットフォームに応募する人にとっては意外ではないはずです。アルゴリズムとして深いところはありません。自分の持つ状態を壊さずに、2段階の変更を実行できるかを試す問題です。

多くの候補者が失敗する間違いは、連続部分を探している最中にセルを削除してしまうことです。1つのセルが横の連続部分と縦の連続部分の両方に属することがあるため、スキャン中に削除すると、2つめの連続部分が検出できなくなります。正しい形は「マークしてから変更する」です。1回目のパスですべての連続部分のセルを集合に集め、2回目のパスで削除して重力を適用します。重力の処理自体は、列ごとに書き込みポインタを下から進めて、残った数字を下にコピーし、残りを埋める形になります。

どちらの段階も時間は O(mn) で、マークした集合のための空間も O(mn) です。もっと凝った方法に手が伸びそうになったら、やめてください。採点が求めているのは整った状態管理であり、抽象化を足すたびにオフバイワンのバグを仕込む場所が増えます。

同じ系統のやさしい問題も、当社の Roblox バンクにあります。キャラクターは目的地に到達できるか？は、障害物のあるグリッド上の単純な BFS で、4方向、スタート1つ、ゴール1つです。OA ではウォームアップの問題で、ここで失点する唯一の原因は、セルを訪問済みにするタイミングを、キューから取り出すときではなくキューに入れるときにするのを忘れることです。取り出すときにマークし、キューから出てきた訪問済みのセルをスキップするガードもなければ、重複がフロンティアごとに増えていき、アルゴリズム自体は「正しく」ても、隠された大きなグリッドで制限時間を超えます。

入力が 10^9 なら、不変条件を証明する

Roblox での出題 — ロボットの経路をシミュレートして有界かどうかを判定する ロボットは原点で北を向いて始まり、G（1歩前進）、L、R（90°回転）からなるコマンド文字列を実行します。文字列を終えると、最大 10^9 回まで繰り返します。1回分の実行後の位置と向きを返し、文字列が永遠に繰り返される場合に軌跡がある有界な領域内にとどまるかを判定してください。

パート (a) は10行のシミュレーションです。パート (b) が本題で、制約にある 10^9 は、繰り返しをシミュレートしても終わらないと採点側が伝えているのです。

見つけることが期待されている議論はこうです。文字列を1回実行して、正味の変位 d と最終的な向きの2つを見ます。d が (0, 0) なら、ロボットは出発点に戻っており、以降のどの周回も同じループをたどります。d が 0 以外でも向きが変わっていれば、2回または4回の周回のあとで回転が合成されて北に戻り、前回から 90°、180°、270° 回転した各変位が打ち消し合ってゼロになります。d が 0 以外で、かつ向きがまだ北のままの場合にだけ、ロボットは直線に進み続けて永遠に離れていきます。

def is_bounded(s: str) -> bool:
    x = y = 0
    dx, dy = 0, 1              # facing north
    for c in s:
        if c == 'G':
            x, y = x + dx, y + dy
        elif c == 'L':
            dx, dy = -dy, dx   # rotate left 90°
        else:                  # 'R'
            dx, dy = dy, -dx   # rotate right 90°
    return (x, y) == (0, 0) or (dx, dy) != (0, 1)

時間は O(|s|)、空間は O(1) で、入力が何回の繰り返しを要求しても変わりません。"GL" で追ってみましょう。1回の周回で (0, 1) に着き、西を向きます。4回の周回で正方形を描いて原点に戻ります。有界であり、関数の結果も一致します。

当社のバンクには、Roblox が出題したさらに意地の悪い変種もあります。繰り返しありのロボット経路の有界性を設計するで、障害物と、直前の命令を繰り返す数字コマンドが加わります。何が変わるのかを正直に認識してください。障害物があると、きれいな回転の議論は成り立ちません。1周目でふさがれていた一歩が、2周目では空いている地形になりうるからです。救いになるのは状態の繰り返しです。ロボットの向きは、遅くとも4周ごとに開始時の向きに戻るので、各周回の終了後に (位置, 向き) の状態を記録します。状態が一度でも繰り返されたら、軌跡は循環しており、有界です。この議論には名指しすべき穴があります。繰り返しが見つからなかったことは、何周まで確認すればよいかの上限を示せない限り何の証明にもならないので、停止の根拠をまだ示す必要があります。この穴を自分から口にして認めることこそ、この問題がシニアレベルの力量を見極めようとしているポイントです。

ウィンドウ集計はどの職種にも出てくる

Roblox での出題 — 直近のリクエストカウンターを実装する Web サービス用のインメモリのヒットカウンターを作ります。hit(timestamp) はリクエストを記録し、getHits(timestamp) は過去5分間に入ったヒット数を返します。タイムスタンプは非減少の順に届き、同じタイムスタンプに複数のヒットが入ることがあります。

これは機械学習エンジニアのスクリーニングで報告されたもので、ほぼ同じ構造がソフトウェアエンジニアからも報告されています。つまり、Roblox は職種を問わずウィンドウ集計を使い回しているということです。すべてのゲーム体験にリクエストの追跡と乱用の制限が必要な、Roblox の事業にそのまま当てはまります。

きれいな解法は、(タイムスタンプ, 件数) のペアを入れた deque と、実行中の合計です。getHits では、先頭のタイムスタンプが timestamp - 300 以前である間、先頭から削除します。

from collections import deque

class HitCounter:
    def __init__(self):
        self.q = deque()       # [timestamp, count] pairs
        self.total = 0

    def hit(self, ts: int) -> None:
        if self.q and self.q[-1][0] == ts:
            self.q[-1][1] += 1
        else:
            self.q.append([ts, 1])
        self.total += 1

    def getHits(self, ts: int) -> int:
        while self.q and self.q[0][0] <= ts - 300:
            self.total -= self.q.popleft()[1]
        return self.total

各タイムスタンプは deque に1回入り、1回出るだけなので、どちらの操作も償却 O(1) です。空間は直近のクエリ以降の異なるタイムスタンプの数に比例します。削除は遅延実行で、deque が整理されるのは getHits が走るときだけなので、クエリが来るたびにウィンドウ内のタイムスタンプに落ち着きます。隠しテストの罠は削除の境界です。ここでの「過去5分間」は半開区間 (ts − 300, ts] を意味するので、ちょうど ts - 300 のヒットは範囲外です。<= を間違えると、見ることのないテストで落ちます。

Roblox での出題 — スライディングウィンドウ方式のレートリミッターを実装する 同じ考え方を、より実践的にしたものです。allow(userId, timestampMs) は、直近の W ミリ秒以内にユーザーごと最大 N 件のリクエストだけを許可し、各リクエストが受理されたかどうかを返します。フォローアップでは、制限をユーザーごとかつゲームごとに拡張します。

ヒットカウンターからの強化点は2つです。1つめは、状態がユーザーごとの deque の辞書になり、フォローアップでは辞書のキーを (userId, gameId) のペアに変えるだけなので、キーが関数の引数1つになるようにコードを構成することです。2つめは、定番の間違いです。拒否されたリクエストは記録しません。ユーザーが上限を超えているとき、拒否された試行が枠を占有してはいけません。そうしないと、連打するクライアントが自分で永遠に締め出されます。削除し、len(dq) < N を確認し、そのあとでのみ追加します。

厳密なスライディングウィンドウは、アクティブなキーごとに O(N) のメモリを使います。フォローアップの議論で述べておく価値があるのは、Roblox の規模では固定ウィンドウのカウンターやトークンバケットに移行し、境界のわずかな不正確さを受け入れることになる、という点です。ただし OA の採点が求めているのは厳密な版です。どちらを求められているかを見極めることも、試験の一部です。

更新を受ける集計：クエリの構成から構造を選ぶ

Roblox での出題 — 最も収益の高いエクスペリエンスを追跡する ゲームエクスペリエンスに対する一連の操作を処理します。'U' は名前付きのエクスペリエンスに利益の差分を適用し、'Q' は現在最も収益の高いものを尋ねます。すべてのクエリへの答えを返してください。

罠は、いかにも思いつく解法にあります。利益の辞書と、実行中の (best_name, best_value) のペアを持ち、'U' のたびに更新して、クエリには O(1) で答えます。差分が正のサンプルならすべて通ります。ところが隠しテストで現在の首位に負の差分が渡されると、キャッシュした最大値は古くなり、次点を O(1) で見つける方法はありません。プロンプトには差分が正だという制限はなく、目に見えるサンプルは穏やかなものが多いので、隠しテストでは少なくとも一度は首位が転落すると考えてください。

現実的な選択肢は3つあり、どれが正解かは操作の構成によります。

遅延ヒープは、すらすら書けるようにしておくべき解法です。更新のたびに新しい (−profit, name) のエントリを push して、削除は決してしません。クエリでは、記録された利益が辞書と食い違うエントリを、先頭が最新になるまで pop します。

import heapq
from collections import defaultdict

profit = defaultdict(int)
heap = []                       # (-profit, name), possibly stale

def update(name: str, delta: int) -> None:
    profit[name] += delta
    heapq.heappush(heap, (-profit[name], name))

def query() -> tuple[str, int]:
    while True:
        p, name = heap[0]
        if -p == profit[name]:
            return name, -p
        heapq.heappop(heap)     # stale, discard

古くなったエントリはそれぞれ最大1回しか pop されないので、m 回の操作を通した総作業量は O(m log m) にとどまります。面接官スタイルのフォローアップで同点について聞かれたら、ルール（たとえば辞書順で最小の名前）を明確に決めて、ヒープのキーを (−profit, name) としてそこに織り込みます。そうすれば Python のタプルの順序が自動で処理してくれます。

ログの問題：正確にパースしてから数える

Roblox での出題 — ログから最も頻出するコールスタックを見つける シングルスレッドのプログラムのログには、関数の開始と終了が記録されています。コールスタックが変化していく様子を再構築し、開始のたびにスタックを文字列としてスナップショットし、最も多く現れたスナップショットとその回数を返してください。

インフラ寄りのパース問題は Roblox のスクリーニングで繰り返し出ており、エンジニアがゲームサーバーのテレメトリに実際に多くの時間を割く会社らしい出題です。アルゴリズムはスタックと Counter ですが、得点は正確さで決まります。スナップショットは開始の後だけで、終了の後には決して取らない。終了では pop し、入力が整っているかどうかは、プロンプトが保証する範囲でのみ信頼する、という点です。

声に出して指摘しておく価値のある細部が1つあります。スタックを文字列に結合するコストは、開始ごとに O(depth) なので、n 個のイベントと最大深さ d に対して全体のパスは O(n·d) になります。OA なら問題ありません。フォローアップでスケールを迫られたら、スタックの状態をインクリメンタルにハッシュして各スナップショットを O(1) にするのが答えで、代償としてハッシュ衝突を扱う必要があります。また、関数名に現れえない区切り文字を選ぶか、結合した文字列ではなくスタックのタプルで Counter のキーを作ってください。タプルなら曖昧さの問題を完全に避けられます。

もっと単純な類似問題も、当社の Roblox バンクにあります。最も頻出するログ呼び出しを見つけるは単純な頻度カウントで、フォローアップは同点、top-k（ヒープなら O(n log k)）、ストリーミングです。OA でこれほど簡単に見える問題が出たら、見えているタスクは最低限のクリア条件にすぎず、フォローアップの制約こそが本題です。

隠しテストがスコアを決める。そしてフォローアップがその隠し場所を教えてくれる

Roblox での出題 — 桁和のバケットの最大サイズを求める [low, high] のすべての整数について桁和を計算し、その和でグループ分けします。最大のグループのサイズを返してください。示されているフォローアップは、範囲が非常に大きいとき、すべての数を調べずに済ませられるか、というものです。

素朴なループは O((high − low) · digits) で、空間はわずかです。10^10 未満の数の桁和はすべて 1..90 に収まるからです。目に見えるサンプルは範囲が小さいので、すべて通ります。フォローアップの一文は、隠しテストがどこにあるかを採点側が伝えているものです。列挙では時間切れになるほど幅の広い範囲です。

スケールさせる答えは桁 DP です。f(N, s) を、[0, N] の整数のうち桁和が s のものの個数と定義し、N の桁をたどりながら各位置でプレフィックスを下回る数を数えて求めます。そうすると各バケットは f(high, s) − f(low − 1, s) になり、全体のコストは O(digits × 90 × 10) で、実質的に定数です。OA の中で完全な桁 DP を書く必要はめったにありません。自動採点が評価するのはコードが通した内容だけですが、スケールさせる方針を示すコメントは1分で書けて、あとで人間がレポートを読むときにはきっと役に立ちます。

このパターンは一般化でき、Roblox OA にとって最も有用な発想の転換です。この記事でここまでに挙げた失敗はすべて、隠しテストでの失敗です。キューから取り出すときに訪問済みにすることによる O(n²) の BFS、ヒットカウンターの <= による削除境界、キャッシュした最大値を取り残す負の差分、10^9 回のロボットの繰り返しのシミュレーションなどです。どれもサンプルでは失敗しません。体系的なチェックリストは、解答が隠しテストケースで失敗する理由とデバッグ方法の詳しい解説にあります。要点は、提出前に次の3つを問い直すことです。制約が許す最大の入力、プロンプトのウィンドウや範囲の定義にあるすべての境界値、そしてサンプルがたまたま満たしている暗黙の前提（ソート済み？ 正？ 一意？）です。

データサイエンティストの OA はコーディングと統計

Roblox での出題 — 4つの DS コーディングタスクを実装する Python または R を選べる CodeSignal 形式のアセスメントで、4つの独立したタスクがあります。そのうちの1つは、両側の2標本 z 検定に必要なサンプルサイズを求めるものです。過去の配列から指標の標準偏差を推定し、それを有意水準、検出力、検出したい最小効果量と組み合わせます。

データサイエンスの職種を受けるなら、OA は LeetCode の問題が4問というわけではありません。動くコードとして表現しなければならない統計です。検出力分析のタスクでは、グループあたりのサンプルサイズの式は n = 2σ²(z₁₋α/2 + z_power)² / Δ² で、σ は過去の観測値から推定し、結果は切り上げます。コーディングの中身は簡単です。試されているのは、「alpha = 0.05、power = 0.8」から、公式集なしで正しい z 分位点（1.96 と 0.84）にたどり着けるかどうかです。

DS のバンクにはグラフ系の問題もあります。再帰を使って最大フォロー深度を求めるでは、ソーシャルグラフのフォローの辺が与えられ、開始ユーザーから DFS でたどれるフォローの最長の連鎖を求めます。コードを書く前に確認しておくべきことは、サイクルがあったらどうなるかです。A が B をフォローし B が A をフォローすると再帰が無限に続きます。訪問済みの集合でガードするのか、プロンプトがサイクルを除外しているのかで、解法全体が変わります。聞かれる前に自分から指摘できれば、コードを書くだけの人と、本番のデータを経験したデータサイエンティストの差が出ます。OA 後の分析ケースの面接を含む DS の選考全体は、冒頭にリンクした Roblox データサイエンティスト面接ガイドにあります。

10日間の対策プラン

この OA に3か月は要りません。必要なのは、上記のパターンを、時間のプレッシャーの中で、実際に使う言語で、的を絞って繰り返すことです。

1〜2日目：シミュレーションに慣れる。 上のセクションにあるグリッド崩しとロボットの有界性の問題を、時間を計らずに解きます。目標は、状態を壊すバグをゼロにすることです。マークしてから変更する、力任せよりも不変条件で考える、を徹底してください。

3〜4日目：ウィンドウ集計。 ヒットカウンター、次にゲームごとの拡張つきのレートリミッターです。どちらも空のエディタから2回書いてください。2回目はそれぞれ15分以内で書けるはずです。

5〜6日目：集計とログ。 遅延ヒープを使った最高収益トラッカー、次にコールスタックのカウンターです。進めながら、コメントでトレードオフを説明する練習をしてください。一部のプラットフォームはコードを人間のレビュアーに見せるからです。詳しくは当社の技術面接のルーブリック解説で扱っています。

7〜8日目：時間を計った本番リハーサル。 4問、70分で、本番の試験が監視つきならカメラもオンにします。制約を再現することが大切です。OA で落ちる原因は、知識不足よりもペース配分のほうが多く、ペース配分は時計を使ったリハーサルでしか直せません。

9〜10日目：自分のコードを壊してから休む。 リハーサルの解答を使って、採点側がやるような方法で失敗させてみます。最大の入力、境界のタイムスタンプ、負の値、要素が1つだけのケースです。そのあとはやめて、招待メールを読み直し、監視のルールを確認し、カメラと接続をテストしてください。

OA のあと

OA 後の典型的な流れは次のとおりです。

返事が来るまでの期間はコホートによって大きく異なり、ボーダーラインのスコアは、どちらの結果よりも長く審査中のままになることがあります。1週目の沈黙を不合格と受け取らないでください。招待状にスケジュールの記載がなかった場合は、リクルーターに尋ねましょう。

スコアの使われ方について、知っておくべきことが2つあります。1つめに、CodeSignal のようなプラットフォームは、企業に合否の1ビットだけでなく問題ごとのレポートを渡します。難しい問題の部分点が白紙より評価されることもあり、アセスメントの途中での時間配分の考え方が変わります。2つめに、OA で高得点でも、それはオンサイト面接には引き継がれません。電話面接とバーチャルオンサイトの各ラウンドでは、リアルタイムの問題解決、コミュニケーション、そして（シニアの職種では）システムデザインが試されますが、OA はそのどれも測っていません。OA を突破したら、すぐに対策の軸を切り替えてください。冒頭にリンクした Roblox ソフトウェアエンジニア面接ガイドが、電話面接以降の流れを扱っています。

PracHub で練習する

身につけたいスキルの順に、実際の Roblox の問題に取り組んでみましょう。

• 変更を伴うグリッドシミュレーション — 数字のグリッドで連続部分を検出して崩す：状態を壊さずに、マークしてから変更する2段階の処理。
• 力任せよりも不変条件による推論 — ロボットの経路をシミュレートして有界かどうかを判定する：10^9 回の繰り返しという制約を、2行の証明に変える。
• スライディングウィンドウの状態 — スライディングウィンドウ方式のレートリミッターを実装する：キーごとの deque、削除の境界、拒否されたリクエストの罠。
• 更新を受ける集計 — 最も収益の高いエクスペリエンスを追跡する：クエリの構成から再スキャンと遅延ヒープを選び、負の差分に耐える。
• 正確なログのパース — ログから最も頻出するコールスタックを見つける：細部に得点がかかるスタックの再構築。
• 確率的な推論 — シャッフルモードのシーケンスを検出する：観測された曲順が、重複なしのシャッフルと整合するかを判定します。タイピングよりも推論が中心の、Roblox では珍しい問題です。

会社別にタグ付けされた問題バンク全体は PracHub の問題一覧にあり、アルゴリズムの問題は コーディングとアルゴリズムに、プラットフォーム別のガイドはリソースにまとまっています。

実際の Roblox の問題を学習ループにする

上で紹介した Roblox の問題は、読み物としてではなく、順番に解くことで最も役に立ちます。どの問題にも同じ4ステップのループを使えば、練習から次の改善につながる根拠が得られます。

リンク先の問題は、正しさを確認するために1回、中断しない1つのタイマーで1回、解いてください。2回目は、最初の実装を暗記するのではなく、制約かエッジケースを少なくとも1つ変えてみましょう。