Umoja (ぐるディス)

「文字にはわからないことがある」

就職活動のグループディスカッション（GD）は、不思議な選考です。エントリーシートや学歴では分からない「その場でどう考え、どう話し、どう人と合わせるか」を見られる、数少ない場面です。それなのに、練習する場所はほとんどありません。友達同士で練習しても、ドタキャンが出たり、レベルが合わなかったり、議論を壊してしまう人が混ざったりします。そして何より、終わったあとに客観的なフィードバックがもらえない。

企業の側にも悩みがあります。GD の選考には人事や現場の社員が何人も張り付く必要があり、評価は面接官によってばらつきます。

Umoja（ウモジャ）は、この2つをまとめて解くために作っている、GD のオンライン評価プラットフォームです。キャッチフレーズは「文字にはわからないことがある」。名前の Umoja はスワヒリ語で「団結・調和」という意味で、みんなで1つの結論を作る GD の考え方に合わせて選びました。以前は「ぐるディス（GruDis）」という名前で、2026年5月に今の名前に変えています。

チーム「Beyond GD.」で開発していて、僕は全体の設計と実装の大部分を担当しています。まだ一般には公開していません。

どんなサービスか

参加者はオンラインのルームに集まり、カメラとマイクをつないで GD をします。お題の提示や時間の管理は AI が進行役として受け持ち、議論が終わると、AI が一人ひとりの発言を評価してくれます。

大事にしている考え方は3つあります。

• 学歴やエントリーシートを、公開するプロフィールから完全に外す。 見てもらうのは GD で発揮した力だけです
• 評価のデータは、プラットフォームが勝手に企業へ渡さない。 企業に送るかどうかは参加者本人が決めます。企業から受け取った一回限りのコードを入力して、初めて送信が成立します
• フォローやいいねのようなソーシャル機能は持たない。 人気や人間関係が評価に混ざらないようにするためです

マッチの種類は、目的に合わせて5つ用意する予定です。ランダムな相手と練習する「レギュラーマッチ」、友達同士でやる「フレンドマッチ」、選考に直結する本番の「ガチマッチ」、企業が主催する「イベントマッチ」、そして AI の参加者を相手に一人で練習する「プライベートマッチ」です。最初は4人で1つのお題を議論する形式から始めています。

4つの AI

Umoja の中では、役割の違う AI が4つ働きます。

1. GD 評価 AI — 発話の時間、論理性、リーダーシップなどを数値にしてグラフで見せる、一番大事な AI です
2. 進行 AI — お題を出し、時間を管理し、議論のフェーズを進めます。実際の選考で人事が議論に口を挟まないのと同じで、議論の中身には介入しません
3. パーソナル AI — たまった評価をもとに、GD のスキルを伸ばすための相談に乗るコーチです
4. ボット AI — プライベートマッチで、役割に応じて立ち回る AI の参加者です（これは実現できるかを検証しながら進めている構想です）

AI のモデルは、特定の1社に固定しない方針にしています。呼び出す部分を薄い共通の窓口にまとめておき、設定を変えるだけで最新のモデルに差し替えられるようにしてあります。

中身の話

画面と軽い API は Next.js（App Router）で作り、Vercel で動かしています。ログインとデータベース、マッチングの待ち行列には Supabase を使っていて、マッチングの状態はリアルタイムで購読しています。ビデオ通話と録音は、WebRTC の基盤である LiveKit に任せています。1つのルームは最大でも12人（GD の仕様上それ以上にはならない）なので、ルームごとに広がっていく LiveKit の作りと相性がいいのです。

評価は、会議が終わってから裏で回す

GD の評価には時間がかかります。録音を文字に起こし（Whisper 系のモデル）、その文字起こしを AI に読ませて一人ひとりを評価する。この処理はサーバーレス関数の実行時間の上限（60秒）に収まらないので、評価だけは別のサーバー（Railway）で5分ごとに動く定期処理に切り出しています。

ここで、通知（Webhook）で「会議が終わったよ」と知らせてもらう方式ではなく、定期的にデータベースを見に行って「終わっているのにまだ評価されていないルーム」を探す方式を選びました。通知は1回取りこぼすとそのルームの評価が永遠に作られませんが、見に行く方式なら、次の回で必ず拾い直せるからです。録音は一時的にクラウドストレージに置き、処理が終わったらすぐに消しています。

評価 AI を、台本で試験する

評価 AI が正しく評価できているかを確かめるために、架空の GD の会話ログを15本用意しています。議論が順調に進む回、一人が発言を独占する回、全員が黙ってしまう回、時間切れになる回、そして他人を攻撃して議論を壊す「クラッシャー」が混ざる回などです。

たとえばクラッシャーの台本では、4人のうち1人が他の人の発言を見下したり、揚げ足を取ったりします。ここで確かめたいのは、その人を正しく低く評価できるかだけではありません。周りの3人が議論を立て直そうとした行動を、ちゃんと加点できるか。クラッシャーがたまに良いことを言ったとき、それに引きずられて甘く評価しすぎないか。「攻撃的な反論」と「正当な反対意見」を区別できるか。台本ごとに「こう評価されるべき」という期待値を書いておき、AI の出力と突き合わせています。

本番のデータベースを、誰も手元で触らない

チームで開発するようになって最初に決めたのが、本番のデータベースを共有しないことでした。各自が Docker で本番と同じ構成のデータベースを手元に立て、テーブルの定義はすべてコードとして管理し、レビューを通ったものだけを本番に反映します。うっかり本番のデータを壊したり、レビューなしで定義を変えたりする事故を、仕組みの側で起こらなくするためです。本番へのデプロイも自動では走らないようにしてあり、確認してから手で出しています。

これから

今は練習用のマッチを中心に、評価 AI の精度を上げているところです。GD の評価が、入社してからの活躍とどれくらい結びつくのかをデータで示せるようになることが、このサービスの一番大きな目標です。