AI審査員「Judgie-AI」をOSS公開——マネーフォワードエンジニアがハッカソン審査をGeminiで全自動化した全記録

記事のサマリー（TL;DR）

• Money Forward India の鈴木陽介氏が、社内ハッカソン「Code Forward 2026」の審査負担軽減を目的にGeminiベースのAI審査プラットフォーム「Judgie-AI」を自作・本番投入
• 起業家・エンジニア・UXデザイナー・PM・VCの5ペルソナが多角評価し、中間コーチング最大3回・異議申し立て機能・日英バイリンガル出力を実装。参加者推奨度は4.62/5（5点満点）
• ソースコードは yosuke1024/Judgie-AI としてOSS公開済み。ハッカソン以外にもStartup Pitch Review・Hiring・Architecture Reviewなど汎用テンプレートを提供

生成AI×社内ハッカソン運営を検討する国内SaaS・IT企業への示唆

社内ハッカソンやアイデアソンの審査コストは、参加者数が増えるほど審査員の負荷と評価品質のばらつきという二重の問題を生む。今回の事例は「AI審査員を単なる採点ツールではなく、中間コーチングと異議申し立てを組み込んだ成長サイクル」として設計した点が核心だ。

kintone や Salesforce で業務プロセスを管理している企業では、提案評価・採用面接フィードバック・アーキテクチャレビューなど「複数の専門視点が必要だが属人化しやすい」評価業務への応用が現実的な候補になる。公開済みの Hiring Template や Architecture Review Template はそのまま転用できる出発点を提供している。

CloudRun＋SQLite という軽量構成で動作する設計のため、AWS Lambda や Google Cloud Run を既に使っている国内企業のインフラ担当は比較的低コストで試験導入できる。Railway ワンクリックデプロイにも対応しており、数分で立ち上がる。

詳細

はじめに — 審査員を引き受けた瞬間に生まれた「英語の不安」

Money Forward India のシニアエンジニアディレクター・鈴木陽介氏は、社内ハッカソン「Code Forward 2026」の審査員を依頼された直後から一つの問題に直面した。英語でのリアルタイムフィードバックだ。

プレゼンを聞きながら理解し、コードを読み、納得感のある品質と情報量のフィードバックを英語で返す——母語なら直感で判断できることが第二言語では一拍遅れる。聞き取りに注意を割けば構造分析の余裕がなくなり、フィードバックを書く時間が足りなくなる、という連鎖が容易に予想できた。

着想 — 審査プロセス自体をハックする

「競技者がプロダクトを作るハッカソンで、審査員がプロダクトを作ってはいけないルールはない」。この発想から、ソースコードやデモ動画をAIに投げて複数の専門家ペルソナで多角的なフィードバックを日英両言語で自動生成し、自分は「判断」に集中するという構造を設計した。

当初は「ハッカソン当日の早朝から半日で突貫実装してデプロイする」計画だったが、開催が1週間延期になったことで状況が変わった。時間制限のロックが外れた結果、「その場しのぎの突貫ツール」は開発期間中に本格的なAI審査プラットフォームへと進化した。

完成した「Judgie-AI」の主な機能

設計の核心 — ペルソナ駆動のAI審査

Judgie-AI の設計で最も重要だったのは「一つのAIが採点する」のではなく「複数の専門家ペルソナが議論する」構造にした点だ。

各AI審査員には明確なバックストーリーと専門性が与えられている。

ハッカソン審査で最も難しいのは「多角的に見る」ことだ。技術的に優れていてもビジネスインパクトがなければ意味がなく、ビジネスモデルが良くてもコードがスパゲッティなら実現性に疑問が残る。AIに5つの異なるレンズを持たせることで、人間の審査員が見落としがちな視点を補完する。

競技者体験の設計 — 採点マシンにはしたくなかった

**コンサルテーション（中間コーチング）**では、チームが最終提出前に最大3回のAIコーチングを受けられる。前回のフィードバックをコンテキストとして次の評価に渡すため、「前回指摘したセキュリティの問題は改善されたか」「新しく追加された機能のUXはどうか」といった追跡型の評価が可能になる。Consultation 1 → 2 → 3 → Final とスコア推移が折れ線グラフに表れることで、ゲーミフィケーションとしてチームのモチベーションを高める設計だ。

「異議あり！」機能は半分エンタメ・半分本気の設計だ。AIの評価が一方通行だと「なぜこのスコアなのか」をモヤモヤ抱えたまま終わる。反論の機会を与えることで評価への納得感が生まれる。「スコアそのものよりも納得感のほうが重要」というのが設計者の考えだ。

バイリンガル対応はこのプロジェクトの原点かつ最も本質的な機能だ。Geminiへの出力指示では管理者が設定した各出力言語ごとにフィールド名へサフィックスを付けさせ（英日運用なら _en / _ja のペア）、UIで表示言語を即時切り替えできる。競技者は英語フィードバックを受け取りつつ日本語でも確認でき、審査員は日本語を「下書き」として参照しながら英語で議論に参加できる。

管理者向けAIチャットでは、アップロード済みのソースコード・動画・PDFを参照しながらAIに直接質問できる。ハルシネーションを防ぐため「コンテキストに含まれない情報については”わからない”と答えること」という制約をプロンプトに明示している。

実戦投入 — 本番での稼働結果

延期後のハッカソン本番でJudgie-AIを実戦投入した結果、参加チームが成果物をアップロードすると、AI審査パネルがソースコードや動画を解析し、日英のフィードバックを高速生成した。

審査員の鈴木氏は「プレゼンを聞く前に、すでにJudgie-AIを通して提出内容のほぼすべてを把握していた」と述べている。英語で理解・記述することから解放され、ほとんどの時間を「アイデアの価値を考える」本来の判断業務に使えた。

実際の反響 — 定量データ（5点満点）

利用者コメントからは「初回提出の時点で自分たちでは気づけなかった改善点を指摘してもらい、取り込んだらスコアが100%まで伸びた」「複数のフロントエンド・バックエンド構成だったが評価が一部のフォルダに偏った（技術実装評価の精度課題）」などの声があった。

高評価以上に設計者が嬉しかったのは、複数のチームがAIフィードバックを取り込んでプロダクトそのものを改善していた事実だ。審査員を助けるために作ったツールが、チームの成長を後押しするコーチになっていた。

反省点と技術スタック上の課題

セッション管理とフレームワーク選定ミス：当初「自分一人の半日突貫」を想定していたため Streamlit を採用した。しかしStreamlit はセッション永続化や認証まわりの作り込みが得意なフレームワークではなく、延期後の本格稼働フェーズでバグが発生した。OSS公開版ではUI・フレームワーク周りを見直し済み。

パフォーマンス面の考慮不足：本番は CloudRun＋SQLite＋Litestream の最小構成で臨んだ。Litestreamの制約によりコンテナのAutoScaleには非対応で、締め切り数時間前のアクセス集中を十分に処理しきれなかった。次回はDB部分をRDSなどに切り出し、負荷集中時のAutoScaleに対応する方針だ。

フィードバックの妥当性：「業務改善（社内オペレーションの効率化）」を目的としたチームと「ビジネス（新規顧客価値の提案・マネタイズ）」を目的としたチームが混在していた。AI審査パネルの評価軸はビジネス・革新性寄りに設定されていたため、業務改善チームには評価軸が噛み合わない指摘になったケースがあった。次回は参加カテゴリごとに評価軸を分ける設計が有効と分析している。

OSSとして公開・今後の展開

Judgie-AI は yosuke1024/Judgie-AI として GitHub に公開済み。Railway でのワンクリックデプロイに対応しており、READMEのデプロイリンクから数分で利用可能になる。

OSS公開にあわせ、ハッカソン以外のユースケースを想定した汎用テンプレートを JSON 形式で追加した。GitHub Gist に公開したテンプレートは URL 指定で自由に読み込める。

現在公開中のテンプレート：

• Startup Pitch Review Template
• Hiring Template
• Architecture Review Template

評価基準とペルソナを入れ替えるだけで、ハッカソン以外の評価業務に転用できる汎用AIレビュープラットフォームとして機能する設計だ。テンプレートが増えるほどプラットフォームとしての幅と深さが広がる構造になっている。Issue・Pull Request・Gistへのテンプレート投稿という形での貢献を設計者は呼びかけている。

次回予告

次回のブログ記事では、鈴木氏が自身に「コードを1行も書かない」というルールを課し、AIの中に14人の仮想専門組織（CEO AI・UXデザイナー・ホワイトハッカー・法務など）を立ち上げてGoogle Play / App Store へのリリースまで駆け抜けたAI食事記録アプリ「PixMeal」の開発体験記が公開される予定だ。数週間以内に公開予定。