【ITニュース解説】Three Judges Scored the Same Project Twice. They Disagreed With Themselves by 1.11 Points.

ハッカソンでは、多くのチームが短期間で魅力的なプロジェクトを開発し、その成果は審査によって順位付けされるのが一般的です。しかし、この「順位付け」という行為が、実は非常に繊細で難しい問題を含んでいることを、あるハッカソンプロジェクトの評価システム開発事例が示しています。今回解説するシステム「Evenhand」は、そうした課題に正面から向き合い、データが示す限界を正直に受け入れることで、より信頼性の高い評価を目指したものです。

DOGFOOD 2026というハッカソンイベントでは、参加チーム自身がイベント運営プラットフォームを構築するという面白い試みがなされました。Evenhandは、そのプラットフォームの一つとして開発されたのですが、主催者が用意したサンプルデータには巧妙な「罠」が仕掛けられていました。それは、「Dry Harbour」という一つのプロジェクトが、二つの異なるID（prj_07とprj_41）で二重に登録されていたことです。これは、審査システムがこのような重複を正しく検知し、二重に評価しないかを試すためのものでした。

この罠が、システム開発者にとって非常に重要な発見をもたらしました。サンプルデータ上の架空の3人の審査員が、この重複したプロジェクトの両方を評価したのですが、結果を見ると、同じ審査員が同じプロジェクトを評価したにもかかわらず、平均で1.11点もの差が生じていたのです。Evenhandが持つ統計モデルでは、同じ作業を二度評価した場合の妥当なずれは0.68点程度と予測されていましたから、これはモデルが予測するよりもはるかに大きな「自己不一致」であり、審査員の採点がどれほど不安定であるかを示すものでした。通常、一人の審査員が同じものを二度評価する機会はほとんどないため、このような自己不一致を測定できるのは非常に珍しいことです。この発見は、「データに含まれるシグナル（明確な差）は、私たちが思っているよりもずっと小さいかもしれない」という警鐘となり、Evenhandの設計思想に大きな影響を与えました。

この自己不一致の発見を受けて、Evenhandは信頼できるランキングを構築するために様々な工夫を凝らしました。まず、審査員の採点の厳しさや甘さを補正する一般的な方法として「Zスコア」というものがありますが、この方法にはいくつかの問題がありました。例えば、すべてのプロジェクトに同じ点数を与える審査員や、レビュー数が極端に少ない審査員がいる場合、Zスコアを計算すると分母がゼロになったり、不正確になったりして、これらの審査員が結果的にランキングから黙って除外されてしまうことがあったのです。Evenhandではこの問題を解決するため、「リッジ回帰」というより高度な統計モデルを採用しました。これは、プロジェクト自体の品質や、各審査員の採点の傾向（甘いか厳しいか）を同時に推定し、さらにデータが少ない場合でも極端な評価に引っ張られすぎないよう調整する手法です。これにより、どんな審査員もランキングから黙って削除されることなく、その評価が適切に反映されるようになりました。

また、審査員の評価内容の監視にも工夫がありました。当初、Evenhandのダッシュボードでは「すべてのプロジェクトに同じような平均点をつける審査員」に警告を出す機能があったのですが、異なる評価項目で異なる点数をつけていても、偶然全体としての平均点が同じになるケース（例えば、3/5/3と3/4/4と5/4/2の平均がすべて3.67になる場合）で誤って警告が出てしまうことがありました。そこで、Evenhandは各評価項目ごとの点数を比較するよう修正し、本当にすべての項目で同じ点数をつけている審査員だけを正しく検知できるようにしました。

重複プロジェクトの扱いはデータの整合性を保つ上で重要です。Evenhandでは、重複プロジェクトを見つけた際に、単純に古い方を削除するのではなく、古いプロジェクトにしか存在しないレビューがあれば、それを新しいプロジェクトに移動させるようにしました。これにより、一人の審査員の唯一のレビューが失われることを防ぎ、すべてのデータが有効に活用されるように配慮しました。データベースの設計においても、重複する提出物が一時的に存在することを許容しつつ、最終的には一つの「生きている」提出物だけが有効になるような複雑なインデックスを導入しています。

システム開発における環境問題も浮上しました。Evenhandは「ネットワークなしで動作する」という要件がありましたが、データベースとの接続に使われる「Prisma」というツールが、インストール時のOpenSSLバージョンと実行時のOpenSSLバージョンが異なると、起動時に足りないバイナリをインターネットからダウンロードしようとすることが判明しました。開発者のマシンでは常にネットワークがあるためこのバグは気づきにくいものでしたが、本番環境でオフラインで起動する際に問題となります。このため、ビルド時にOpenSSLのバージョンを統一し、もし必要なバイナリがなければビルド自体を失敗させることで、ランタイムでネットワーク接続を試みる事態を未然に防ぎました。

そして、Evenhandが最も重要視したのは「データが持つ限界を正直に伝える」ことです。Evenhandのモデルは、単純な平均点予測と比べて、隠されたレビューを0.9%しか改善できませんでした。これは、データ自体に明確な「シグナル」が非常に少なく、40ものプロジェクトを細かく順位付けするほどの情報が含まれていないことを意味します。そのため、Evenhandは「プロジェクトが17位になった」といった具体的な順位付けは行いません。代わりに、統計的に差がないと考えられるプロジェクトを「タイグループ」としてまとめ、このデータからは「上位16プロジェクトと下位24プロジェクトの二つのグループに分けられる」という結果を提示します。これは、データが持つ精度以上の主張をしない、というEvenhandの設計思想の表れです。

さらに、Evenhandは透明性と信頼性を高めるための仕組みも備えています。システムが生成したすべてのランキング結果は、その入力データと出力結果のハッシュ値を記録する「レシート」として機能します。これにより、誰かが結果を改ざんしようとしても、ハッシュ値の不一致によってその変更が発覚するようになっています。また、正規化の証明ドキュメントは、コードから自動的に生成され、コードとドキュメントの間にわずかな差異でもあればテストが失敗するように設定されています。これは、システムが「今、計算していること」と「それが文書化されていること」が常に一致していることを保証するための工夫です。

セキュリティ面でも徹底した「拒否」の原則が貫かれています。例えば、ある審査員が別の審査員のスコアを見ようとした場合、システムはデータベースを検索する前に、アクセスを要求している審査員にその権限があるかどうかを判断し、権限がなければすぐに拒否します。これにより、悪意のあるユーザーが有効なユーザーIDを探ることを防ぎます。また、データベースやAPIを外部ネットワークから物理的に隔離することで、万が一コードに外部への接続を試みる記述があったとしても、実行時にそれが不可能となるようにしました。

開発を通じて、いくつかの反省点もありました。特に、数学モデルの精度を極限まで高めるために多くの時間を費やしましたが、データのシグナルが弱かったため、その努力がランキング結果に目に見えるほどの変化をもたらさなかったことです。開発チームは、その時間を監査ログの改ざん防止機能（ハッシュチェイン）のような、より根源的なシステムの信頼性向上に費やすべきだったと後悔しています。

このEvenhandの事例から、システムエンジニアを目指す初心者が学ぶべき重要な教訓は多岐にわたります。ランキングを公開する前に、テスト・リテスト（審査員の自己不一致）を測定し、データにどれだけの「ノイズ」が含まれているかを把握すること。自分のモデルが、単純な平均予測よりもどれだけ優れているかを正直に公開すること。システムが行う補正が、誰をランキングから除外する可能性があるのかを常に意識すること。そして、権限チェックはデータベース検索前に行い、セキュリティを強化すること。さらに、コードから自動的にドキュメントを生成し、システムが何をしているかを明確にすること。そして最後に、システムが「できないこと」や「未実装の機能」を明確にリストアップし、正直に伝えること。

Evenhandは、単なるハッカソンの採点システムにとどまらず、データが持つ限界を理解し、その上で誠実に情報を伝えるシステムの設計思想と、システム開発におけるリアルな課題とその解決策、そして反省点までをも示してくれました。どのようなシステムを開発する上でも、この「誠実さ」と「透明性」の精神は非常に重要だということを教えてくれる良い事例です。