リスト ランダム並べ替え (シャッフル + チーム分け)

シャッフル対象のリストが持つ情報の機微性

「リストをシャッフルする」という操作は単純に見えますが、シャッフル対象のリスト自体が機密情報を含むことがあります。社員名のリストからチーム分けする、顧客 ID のリストから抽選する、プロジェクト候補のリストから優先順位を決める — これらのリストはそれぞれ組織構造・顧客データ・内部戦略に紐づく情報です。

オンラインのシャッフルツールに貼り付けると、そのリストがサーバー側で受信されます。サービス側の実装がクライアントサイドのみで完結しているかどうかは、ユーザーが外部から確認する方法がありません。広告モデルのサービスでは行動データの収集が行われるケースがあり、入力内容がその対象になる可能性があります。

アップロード型シャッフルサービスのリスク

シャッフルの操作自体はアルゴリズムとしては単純で、ブラウザ内の JavaScript で完全に実現できます。にもかかわらず「シャッフル ランダム オンライン」で検索すると上位に出るサービスの多くはサーバーサイドの API を経由します。理由の一つは広告収入のためにページビューを稼ぐ設計があるからで、入力フォームにリストを貼り付けてサブミットする操作がサーバーへのリクエストになります。

「社員全員の名前でシャッフル抽選を行い、その結果が第三者のサーバーログに残る」という状況は、個人情報保護の観点から避けるべきです。特にシードを指定して再現可能な抽選を行う場合、シードとリストの組み合わせが外部に漏れると結果の操作有無を検証しにくくなります。

Fisher–Yates と Mulberry32 PRNG がブラウザ内で完結する

このツールは Fisher–Yates アルゴリズム (Durstenfeld 最適化版) をブラウザ内の JavaScript で実装しています。シードを指定した場合は Mulberry32 (32-bit シードベース PRNG、周期 2^32) を使い、シードが同じなら入力が同じであれば常に同じ結果を再現します。シードを空欄にした場合は crypto.getRandomValues をベースにした安全な乱数源を使用します。

入力リスト・シード・シャッフル結果のいずれもブラウザのページメモリにのみ存在し、ネットワーク通信は発生しません。社員リスト・顧客 ID・プロジェクト名などの機密情報を含むリストでも安全にシャッフルできます。

透明性のある抽選・チーム分けのための使い方

シードを公開しておくと、抽選後に「同じシードと同じリストで再実行すれば結果が一致する」ことを誰でも検証できます。くじ引きの公正性を後から示したい場面、チーム分けに不満が出た時に「同じシードで再現できる」と示したい場面で有効です。シード値をあらかじめ参加者全員に公開しておく、または公開情報 (その日の日付など) をシードにする設計にすると、より透明性が高まります。事前に重複行を除いておきたい場合は line-dedupe を、シャッフル後にアルファベット順で並べ替えたいときは line-sort を続けて使えます。

Fisher–Yates の偏りと Mulberry32 PRNG の特性

Fisher–Yates シャッフル (Knuth shuffle) は配列末尾から先頭に向かって走査し、各位置 i で [0, i] の整数を一様にサンプルして当該要素と入れ替える、O(n) 時間・O(1) 追加メモリのアルゴリズムです。重要なのは「[0, i] から一様にサンプルする」点で、ここを Math.floor(Math.random() * n) で近似すると n が 2 の冪でない場合に modulo bias (剰余偏り) が入り、特定の順列がわずかに多く出力されます。本ツールは Mulberry32 の場合は state / 2^32 を 32-bit 整数空間として扱い、crypto.getRandomValues の場合は rejection sampling (Uint32 を取り直す) で偏りを排除しています。

Mulberry32 は 32-bit のシードを入力に取り、state += 0x6D2B79F5; let t = state; t = Math.imul(t ^ (t >>> 15), t | 1); t ^= t + Math.imul(t ^ (t >>> 7), t | 61); という形の混合関数を回す軽量 PRNG です。周期は 2^32 ≈ 43 億で、暗号用途には使えませんが PractRand などの統計テストはパスします。リスト長が数百〜数万程度の抽選には十分な品質ですが、リスト長 N が大きく N! が 2^32 を超える (N ≥ 13) と、Mulberry32 で出せる順列は理論上の全順列の一部分でしかなくなります。シードなし (crypto) を使えばこの制約はありません。

抽選の公正性、コミットメントスキーム、よくある落とし穴

公正な抽選の運用上のベストプラクティスは、(1) シードを抽選前にコミットする (シード値の SHA-256 ハッシュを先に公開し、抽選後に元のシードを開示)、(2) 候補リスト (入力) も抽選前に確定・公開する、(3) シード自体は予測不能な公開情報 (将来のブロックチェーンブロックハッシュ、抽選当日終値、Drand など) から導出する、の 3 点です。これにより主催者が「結果を見てからシードを選ぶ」攻撃 (grinding attack) を排除できます。逆にやってはいけないのは、シードを主催者が任意に選んで結果だけ公開する運用で、これだと参加者は再現不能なため検証できません。

落とし穴として、(a) リストに見えない trailing whitespace や全角空白があると重複除去オプションでも同一視されず別項目になる (本ツールは LF / CRLF を内部正規化しますが空白は保持)、(b) 「N 人ずつ」のチーム分けで余り人数の扱いがツールによって異なる (本ツールは最後に小さなチームを作る方式で、人を捨てません)、(c) 「シードを再利用するとリストが少し変わっても全く違う結果が出る」ことに注意 (Fisher–Yates は最初の要素位置から消費するため、入力末尾を 1 つ追加しただけでも前半の swap 列が違う数列を消費し、結果が変わる)、があります。決定論的に「ある人だけ常に最初」のような結果を作るには、シャッフル後に固定位置への配置を別ステップで行う必要があります。