【ITニュース解説】2% bias, 98% noise: what I built, and cut, for a hackathon judging engine

ハッカソンというイベントでは、参加者が短期間でアイデアを形にし、その成果を競い合う。このニュース記事は、そんなハッカソンの審査を公平かつ効率的に行うための「審査エンジン」を、開発者がどのように作り、どのような判断を下したかについて語るものだ。開発期間はわずか72時間、一人の開発者がAIコーディングエージェント（Claude Code）を使い、多くの決断を下しながらプロジェクトを進めた。

開発の出発点となったのは、実際にあったハッカソンの審査データから導き出された「2%の偏り（バイアス）と98%のノイズ」という分析結果だった。これは、審査員の評価のばらつきを分析したもので、「この審査員は全体的に甘い」といった個人の傾向が全体の評価に与える影響が約2%に過ぎず、残りの98%は、あるプロジェクトを好きになる審査員と嫌いになる審査員がいるといった、個々のプロジェクトに対する個人的な感覚や、予測できない要素（ノイズ）によるものだということだ。この「2%」という小さな数字が、エンジンの設計において何を優先し、何を切り捨てるかの重要な判断基準となった。

審査エンジンの基本的な考え方は、「プロジェクトの本当のレベル」に「審査員の甘さや厳しさ（leniency）」と「ノイズ」が加わってレビュー結果が生まれる、というシンプルなモデルに基づいている。本来であれば、個々の審査員の甘さや厳しさを補正することで、より公平な評価に近づけたいところだ。しかし、今回のハッカソンデータでは、一人の審査員が担当したプロジェクト数が少なかった（平均で約4件）ため、個々の審査員の甘さを補正しようとしても、その影響はごくわずかだった。例えば、5段階評価で補正できるのは最大でも0.06点程度で、これは「エンジンが何もしていないように見える」ほどの小さな変化だった。これは、データが少なすぎると、審査員の個性なのか、たまたま担当したプロジェクトが良かったのか悪かったのか、区別がつきにくいという現実を物語っている。

しかし、エンジンが完全に無力というわけではない。もし一部の審査員が意図的に甘い採点をした場合（例えば、3人の審査員が他の審査員より0.6点甘く採点したとする）、その結果生じる評価のばらつきはエンジンによって修正され、元の状態に近い公平な評価に戻すことができた。また、特定の審査員がすべての評価項目で同じ点数（例えばすべて4点）をつけた場合、その審査員の評価を除外すると、全体のプロジェクトランキングに大きな変動が生じることが判明した。そのため、審査エンジンはこのような「フラットな審査員」を自動的に特定し、その評価を除外する機能を持つ。ただし、この除外は「静かに行われる」のではなく、必ず「フラグ」として表示され、主催者がその理由を確認し、必要であれば元に戻せるようになっている。これは、もし正直な審査員がたまたま同じような点数をつけた場合でも、誤って除外されないようにするための配慮だ。

開発過程では、いくつかの機能が検討されたものの、最終的に実装が見送られた。一つは「プロジェクトの勝率を表示する機能」だ。「プロジェクトXが1位になる確率は63%」といった表示は、一見すると魅力的だ。しかし、シミュレーションの結果、本来ならどのプロジェクトも優劣がないはずの状況でも、この機能が根拠なく「優勝候補」を作り出してしまうことが分かった。不確実な情報を「事実」のように提示してしまうことは避けるべきだという判断から、この機能は削除された。

二つ目は「エンジンが次の審査ペアを自動選択する機能」だ。複数のプロジェクトを比較してどちらが良いかを判断する「ペアワイズ比較」という審査方法において、エンジンがこれまでの審査結果をもとに最適なペアを自動で選び出すというアイデアだ。しかし、期待したほどの効果（手動で選ぶよりも3点以上正しく優勝者を特定できること）が得られなかったため、開発は中止された。

三つ目は「失格機能」だ。これは開発終盤にAIエージェントによって構築されたが、テストが十分に行われていなかったこと、そして一度失格にしたプロジェクトを復活させると、その後のペアワイズ比較のデータが破棄されてしまうという問題が発覚したため、締切の数時間前に見送られた。未テストの機能を、優勝者を決定する重要な部分に組み込むことはリスクが高いと判断されたのだ。

「勝率表示機能」の代わりに導入されたのは、「トップは接戦で判定不能か？」という問いに対して「はい」か「いいえ」で答えるシンプルな機能だ。エンジンは、持っている不確実性（誤差の範囲）から、ランキングを4,000回再計算する。その結果、現在のトッププロジェクトが3,800回未満しか1位にならなかった場合、そのトラック（カテゴリ）は「接戦で判定不能」と判断され、最終的な決定は人間の審査員に委ねられる。これは、不確かな情報をあたかも事実のように見せるのではなく、「現時点ではっきりとした差はない」という事実を正直に伝える方法だ。シミュレーションでは、本当に差がない場合にはほとんど優勝者を特定せず、本当に差がある場合でも「判定不能」と正直に判断することが多かった。

エンジンの信頼性を確保するために、入念なテストが繰り返された。特に重視されたのは、エンジンが出す「この評価は95%確実です」といった数値（誤差範囲）が、本当にその通りの信頼性を持っているかということだ。最初のテストでは、意図的に誤差範囲を半分に狭めた「壊れたエンジン」でも、簡単にテストをパスしてしまった。これは、明らかに分かりやすい採点（例えば、誰もが満点をつけるようなプロジェクト）がテスト結果全体の平均を上げてしまい、本当に確認したい「微妙な採点」におけるエンジンの精度を見誤らせていたためだ。この経験から、テストはより厳密になり、特に「95%から99%確実」といった、判断が微妙な範囲の精度に絞って検証するようになった。さらに、「既知の悪い入力に対しては必ず失敗する」という条件を設けることで、テスト自体の信頼性を高めた。

開発は主にAIコーディングエージェント「Claude Code」によって行われ、開発者は全体の方針決定と最終的な調整に専念した。機能ごとに別々の開発環境（Git worktree）を使い、全てのテストをパスし、主催者のチェックもクリアするまでメインのコードには統合しないという厳格なルールで進められた。開発中にいくつかのトラブルも発生した。例えば、AIエージェントがファイル削除の許可を待って長時間停止してしまう問題に対しては、夜間はファイルを削除しないようにする、という運用ルールで対応した。また、コマンドの記述ミスによる予期せぬシステム停止や、コードのマージによる修正の取り消しといった問題も、ルールの見直しや事前確認の強化によって解決された。

もちろん、この審査エンジンも万能ではない。例えば、二人の審査員が互いに有利な採点をするような不正行為は、個々の審査員の「甘さ」として認識され、通常の意見の不一致と区別することは難しい。また、システム外部でデータベースファイルを改ざんされた場合の監査ログの信頼性や、意図的に全てのプロジェクトを「接戦で判定不能」と主張する審査員の意図を完全に把握することも難しい、といった限界も認識されている。しかし、これらの限界を理解した上で、利用者がより公平な審査結果を得られるよう、開発者は常に改善を続けている。