LLM-as-judge

Platform City では、デプロイされたアプリケーションの品質や合否を LLM に判定させる手法（LLM-as-judge）を意図して採用しませんでした。プラットフォームが実施する自動検証は、決定論的な CI パイプラインとヘルスチェック（/healthz）のみに限定しています。どちらも同一の入力に対しては、常に寸分違わぬ同一の判定結果を返します。

採用を見送った背景と技術的理由

参加者側の AI エージェントが生成するコードや振る舞いは、本質的に非決定的（確率的）です。もしその検証にも LLM を用いてしまうと、「非決定的な判定者が、非決定的な生成物を評価・統制する」という二重の確率構造を抱え込むことになります。

もし判定結果に誤りやブレが生じた際、それがコード生成側の不備なのか、あるいは判定者側のプロンプトやモデルの揺らぎによるものなのかを客観的に切り分ける手法は確立されていません。この再帰的な評価ループをいかに安定させるかという問いは、学術研究や産業界の先端事例においてもいまだ明確な合意が得られていない難問です。

100 人以上のエンジニアが同時に参加する一発勝負のカンファレンスにおいて、挙動が予測できない未解決の課題を抱えたまま本番運用を迎えることは、システム破綻の極めて大きなリスクとなります。だからこそ私たちはこのイベントにおいてその問題をあえて解かない決断を下し、決定論的な検証のみで確実に成立するスコープへと設計を絞り込みました。

決定論的な代替アプローチ

プラットフォームが課すデプロイの通過条件は、以下の 3 つに集約されています。

1. 静的解析（lint）をクリアすること
2. 自動テストをすべてパスすること
3. アプリケーションの /healthz エンドポイントが正常に応答すること

これらの条件は、生成モデルの確率的なブレや判定者のコンディションに一切左右されません。万が一条件を満たさなかった場合でも、「どの工程で、何が期待と食い違っていたのか」が明確なシグナルとしてエージェントにフィードバックされます（詳細は 検証シグナル を参照）。

なお、コードの品質向上や気づきを促す仕組みとして、GitLab Duo による AI レビューの受講をマージの必須条件として組み込んでいます。ただし、これも AI レビューの内容によってデプロイの合否を自動判定しているわけではありません。「AI によるレビューを一度通過させた」という客観的なプロセスの事実のみを検証しており、指摘事項をどのようにコードへ反映させるかは、参加者とエージェント自身の判断に委ねられています。

決定論的検証がもたらす信頼性

合否判定の仕組みが決定論的であるからこそ、イベント当日におけるプラットフォームの挙動を運営側が正確に予測できます。同一のエラーに対しては常に同一の原因が返却され、同一の修正を施せば確実にテストを通過します。エージェントが自信を持って自律的な修復ループを回し続けられるのは、この揺るぎない一貫性がプラットフォーム側に担保されているからに他なりません。