こんにちは。Money Forward India/Senior Engineer Directorをしている鈴木陽介です。
英語でハッカソンを審査したくなかったので、AI審査員「Judgie-AI」を作りました。気づけば、それは審査員を助けるツールではなく、チームやプロダクトの成長を加速させるプラットフォームになっていたという話です。
結果として参加者からの推奨度は4.62/5、運営からは「審査負荷軽減」「審査支援」の両項目で4.67/5の評価を受けました。
はじめに — 審査員、引き受けたはいいけれど
先日、Money Forward Indiaの課題解決をテーマにした社内ハッカソン「Code Forward 2026」を開催しました。
光栄なことに、私も審査員を務めることになったのですが、引き受けた瞬間から「英語」というひとつの不安が頭を離れませんでした。
私は英語が苦手です。 そのため、英語で審査をすることに対して、正直かなり気が重かったです。
プレゼンを聞きながら理解し、コードを読み、競技者が納得する品質と情報量でのフィードバックを、すべて英語で返さなければなりません。 これは絶対に辛い作業です。
母語なら直感で判断して瞬時に言語化できることが、第二言語だと一拍遅れます。聞き取りに注意を割いている間にプロダクトの構造を分析する余裕がなくなり、フィードバックを書くのに時間がかかりすぎて次のチームの準備が間に合わない — そんな未来が容易に想像できました。
着想 — 審査プロセスをハックする
不安を抱えたまま数日が過ぎた頃、ふと思いました。
「審査プロセス自体を、ハックしてやろう」と。
競技者たちがプロダクトを作るハッカソンで、審査員がプロダクトを作ってはいけないルールなどありません。自分の弱点を技術で補えばいいと考えました。
ソースコードやデモ動画をAIに投げて、複数の専門家ペルソナで多角的にフィードバックを英語と日本語の両方で自動生成させる。人間の審査員である自分は、AIが出したフィードバックを「叩き台」として使い、本質的な判断に集中する。
「これだ」と確信しました。
最初、自分にひとつ縛りを課しました。コードは「ハッカソン本番と同じ日」に書き始める と決めました。 競技者と同じタイムボックスの中でやるのが筋だと思ったからです。当面やったのは設計だけでした。「何を作るか」「どんな構成にするか」「どんなペルソナのAI審査員がいると面白いか」など、思いついたアイデアをプレーンテキストにまとめておきました。ハッカソン当日の早朝から「一人ハッカソン」を開始し、午前中だけで一気に作り上げてデプロイする……そんなスリリングな計画を企てていたのです。
ところが、当初スケジュールの本番開始から1週間前、リスケが決まりました。
ぽっかりと空いた時間。「当日朝の半日突貫」という時間制限のロックが外れ、私の手元には脳内設計と高まった開発欲だけが残されました。 「せっかく時間ができたのだから、当初考えていたシンプルなAI審査ツールを、極限まで磨き上げてみよう」と思い立ち、ハッカソンの運営の合意を得て実装に着手しました。
ここから実装は延期期間のなかで走り出し、Judgie-AIはハッカソン開催より先に形を帯び、私の開発は当初のスコープを超えて暴走を始めました。
半日で作る予定でした。 しかし気が付いたら、AI審査員をはじめ、評価基準のカスタマイズ、異議あり機能、質問機能、多言語設定、テンプレート共有など、これだけの機能群をひと通り完成させていたのです。 どう考えても半日で作るツールじゃありません。
当初予定していた「その場しのぎの突貫ツール」は、延期期間の間に、みるみるうちに 「本格的なAI審査プラットフォーム」 へと進化していきました。
完成した「Judgie-AI」：AI審査プラットフォーム
完成したJudgie-AIは、チームの成果物（ソースコードのZIP、デモ動画、PDFスライドなど）をアップロードすると、複数の AI 審査員がそれぞれの専門的視点から評価とフィードバックを返すプラットフォームです。
主な機能
- ⚖️ AI審査員パネル機能 — 5人の専門家ペルソナ（起業家、エンジニア、UXデザイナー、PM、VC）が多角的に評価する機能
- 🔄 コンサルテーション（中間コーチング × 最大3回） — 前回のフィードバックをコンテキストとして引き継ぎ、チームの成長を追跡できる機能
- 📈 スコア推移グラフ機能 — 提出ごとのスコアを折れ線で表示し、改善の軌跡を可視化する機能
- 🏆 リーダーボード機能 — チームごとのスコアをランキング表示し、ハッカソン全体の熱量を高める機能
- 🙋 「異議あり！」機能 — AIの評価に納得できなければ、1回だけ反論を投げられる機能。異議を申し立てたあとは、AI審査員が再議論して回答する
- 🌐 多言語フィードバック機能 — 出力言語は管理者が設定。プロンプトで言語別フィールド（例:
_en/_ja）を揃えて生成し、UIで表示言語を切り替えできる機能 - 🧾 Markdownエクスポート機能 — 審査フィードバックとDBの情報をレポートとして出力する機能。後から振り返りできる形で持ち帰ることができる
設計の核心 — ペルソナ駆動のAI審査
Judgie-AIの設計で最も重要だったのは、「一つのAIが採点する」のではなく「複数の専門家ペルソナが議論する」 という構造です。
私はプライベートプロジェクトで複数のAIペルソナを用いた開発の有効性は実感していました。AIに明確な役割と専門性を与えると、アウトプットの質が劇的に変わります。これをハッカソン審査に応用しない手はありませんでした。
AI審査員たちには、それぞれ明確なバックストーリーと専門性を与えました。
| ペルソナ | 役割 | 視点 |
|---|---|---|
| Alex | 連続起業家 | PMFを嗅ぎ分ける。「それはビタミンか？ペインキラーか？」(「なくてはならないものか、あると嬉しいものか」の意味) |
| David | プリンシパルエンジニア | 15年の本番障害経験。コード品質とセキュリティに妥協しない |
| Lisa | UXデザイナー（認知心理学PhD） | ユーザーの認知負荷に異常に敏感。ピクセル単位の完璧主義 |
| Sarah | シニアPM | 「なぜそれを作ったのか」を問い続ける。スコープ管理の鬼 |
| Marcus | VC | 5,000件のピッチを聞いてきた男。最初の60秒で判断する |
なぜペルソナを設定する必要があるのでしょうか。 ハッカソンの審査で最も難しいのは「多角的に見る」ことです。技術的に優れていてもビジネスインパクトがなければ意味がありませんし、ビジネスモデルが良くてもコードがスパゲッティなら実現性に疑問が残ります。人間の審査員が一人で、ましてや不慣れな英語でこれをやるのは大変です。しかし、AIに5つの異なるレンズを持たせれば、自分が見落としがちな視点を補完してくれます。
競技者体験の設計 — 採点マシンにはしたくなかった
Judgie-AIは単なる「採点マシン」ではありません。競技者の体験として設計したのは、最終提出までの成長サイクルです。
コンサルテーション（中間コーチング）
チームは最終提出の前に、最大3回まで「AIコーチング」を受けられます。ポイントは、前回のフィードバックをコンテキストとして次の評価に渡すことです。「前回指摘したセキュリティの問題は改善されたか？」「新しく追加された機能のUXはどうか？」など、AIが前回の指摘を踏まえて評価し、チームの成長を可視化します。
スコア推移が折れ線グラフで見えるのは、ゲーミフィケーションとして有効と考えました。Consultation 1 → 2 → 3 → Finalと改善の軌跡がスコアに表れると、チームのモチベーションが明らかに上がるはずです。
「異議あり！」— 納得感の設計
AIの評価に納得できなかったら、チームは1回だけ反論できます。AI審査パネルが過去の評価コンテキストを踏まえて再議論し、回答できます。
これは半分エンタメですが、半分は本気で設計しました。AIの評価が一方通行だと、競技者は「なぜこのスコアなのか」をモヤモヤ抱えたまま終わります。反論の機会を与えることで、評価に対する納得感が生まれます。審査において、スコアそのものよりも納得感のほうが重要だと私は考えています。
バイリンガル — このプロジェクトの原点であり、最も本質的な機能
そもそもこのプロジェクトの出発点は「英語への不安」でした。だから、バイリンガル対応は飾りではなく、最も本質的な機能です。
Geminiへの出力指示では、管理者が設定した各出力言語ごとにフィールド名へサフィックスを付けさせ、すべてのフィードバック項目をその言語で埋めさせます（例として英日運用なら _en / _ja のペア。言語の組み合わせが変わればサフィックスもそれに合わせます）。どの言語を要求するかは、管理者がイベント単位で決められます。 閲覧側は設定済みの言語から表示を切り替えるだけで即時にそれぞれの言語のフィードバックを確認できます。
これにより、競技者は英語のフィードバックを受け取りつつ日本語でも確認でき、審査員の私は日本語のフィードバックを「下書き」として参照しながら英語で議論に参加できます。
これが、このプロジェクトの原点にして最も欲しかった機能です。
管理者向けAIチャット — 審査員の「もっと聞きたい」に応える
審査員として使うことを想像し、すぐに欲しくなった機能があります。提出されたソースコードについて、AIに直接質問できるチャットです。
プレゼンやデモでは見えない、バックエンドで使用しているライブラリやセキュリティ、設計の意図といった疑問についても、チームの成果物を熟知したAIにそのまま投げかけることができます。
動画やPDFを事前にアップロードしてあるので、AIは実際のソースコードを参照しながら回答します。ハルシネーションを防ぐため、「コンテキストに含まれない情報については”わからない”と答えること」という制約も明示的にプロンプトに入れました。
エクスポート — 「審査の記録」をチームが持ち帰れるように
Judgie-AIには、審査内容とDBに蓄えた情報をまるごとMarkdownでエクスポートできる機能も入れました。
この環境は恒久的にあるわけではありません。ずっと保持し続けるには、インフラや運営コストが必要になります。それでも、ハッカソンが終わったあとに「審査フィードバックを見返したい」「チーム内で振り返りに使いたい」という競技者は必ずいるはずです。
そこで、各チームの審査フィードバックをレポートとしてMarkdownで出力できるようにし、手元に残せる形にしました。
さらに、Judgie-AIが持っているデータをMarkdownとして落として NotebookLM に読み込ませることで、Googleのインフラを利用しながら、今後もずっとチームのナレッジとして活用できる運用もイメージしています。
実戦投入 — ハッカソン本番での稼働
そして迎えた、延期後のハッカソン本番。 すでに開発を終えていたJudgie-AIを、満を持して実戦投入しました。
参加チームが成果物をアップロードすると、AI審査パネルがソースコードや動画を解析し、日英のフィードバックを爆速で生成します。
ハッカソンの最後にチームのプレゼンを聞く前に、実は私はJudgie-AIを通して、提出内容のほぼすべてを把握していました。発生した疑問点もJudgie-AIを通して、確認もできていました。
結果として、私はほとんどの時間は「英語でアイデアを理解する」ことではなく、「そのアイデアの価値を考える」ことに使えました。
その効果は、想像以上に大きかったと感じました。 審査員としての仕事を英語で理解すること、書くことから、本来の判断することに戻せたと思います。 最初は英語力を補うツールとして作りました。AIが複数の視点からレビューを返してくれることで、自分一人では見落としていた論点にも気付けました。審査そのものの品質も上がっていたと思います。
実際の反響 — 競技者はどう受け止めたか？
ハッカソン終了後、競技者にアンケートを取りました。AI審査員という「未知の体験」に対して、競技者たちの反応は想像以上にポジティブでした。
定量データ（5点満点）
| カテゴリ | 質問 | 平均 |
|---|---|---|
| 競技者向け | Judgie-AIパネルによる評価は妥当だと思いますか？ | 4.27 |
| 競技者向け | Judgie-AIパネルからのフィードバックは、製品の改善に役立ちましたか？ | 4.46 |
| 競技者向け | Judgie-AIは、ハッカソン全体の体験をより魅力的なものにしましたか？ | 4.51 |
| 運営向け | Judgie-AIは、審査の時間や負担を軽減するために役に立ちましたか？ | 4.67 |
| 運営向け | Judgie-AIは、審査の助けになりましたか？ | 4.67 |
| 共通 | 他のハッカソンでもJudgie-AIの利用を推奨しますか？ | 4.62 |
利用者からの生の声
- ペルソナごとに違う視点で見てくれるのがすごく良かった。アイデア自体も新鮮で、結果の見方が多面的になった
- 初回提出の時点で、自分たちでは気づけなかった改善点を具体的に指摘してくれて、取り込んだらスコアが 100% まで伸びた。最終提出の完成度が一段上がった実感がある
- 「AIが審査員」という発想が面白いし、提案が実用的だった。品質をいろんな観点からチェックできて、振り返りにも役立った
- ひとつだけ気になったのはセッションが永続化されていない点で、ハードリロードや数分放置の後に再ログインが必要だった
- ペルソナや複数の観点で結果をチェックできるのが素晴らしいアイデアだった。最初の提出時点で、自分たちでは思いつかなかった改善案をもらえ、それを取り入れた結果スコアが 100% まで伸びて、良い形でプロジェクトを仕上げられた
- 品質をさまざまな視点から理解できてとても有用だった。フィードバックコメントも役に立ち、各審査員のスキル説明も多面的で、幅広い観点をカバーしていた
- Judgie_AI自体は良かったが、改善してほしい点がある: (1) AIのスコアリングと人間の審査は見え方が異なる可能性があり、リーダーボードがあると印象に影響しうるので、リーダーボードは必ずしも良いとは限らない。(2) アップロード後に、別の（自分たちのものと全然違う）プロジェクトとして解析されてしまったことがあった
- 各パラメータの点数が低い場合に、何を改善すべきかが明確に分かると、参加者が改善に集中できて良い
- 審査観点ごとに別エージェントがいて、それぞれがコメントするのが良かった
- ハッカソンで選んだトピックも評価に含め、トピック間の重み付けを反映したリーダーボードがあると、より魅力的かもしれない
- 技術実装の評価が少しバギーに感じた。複数のフロントエンド、複数のバックエンド（FastAPI中央サーバ、Slack、DBなど）や専用Slackフォルダがある構成だったが、評価がSlackフォルダ中心になり、他の実装が見落とされているように見えた
- 一方で、操作感やスコアリングは分かりやすく、事前準備が進むことで締切直前の審査負荷軽減につながったのが良かった
中間コンサルテーションでスコアが上がっていくゲーム要素や、リアリティあるAIペルソナのフィードバックは、ハッカソン全体の熱量を高めるのに寄与したと思っています。
しかし、本当に嬉しかったのは評価が高かったことではありません。何よりも嬉しいのがJudgie-AIのフィードバックが複数のプロダクトのアイデアを後押しできていたことです。Judgie-AIは審査を効率化するために作ったツールでした。ところが実際には、複数のチームがAIからのフィードバックを取り込み、プロダクトそのものを改善していました。
審査員を助けるために作ったはずのツールが、気が付くとチームの成長を後押しするコーチになっていたのです。
反省点
セッション管理とフレームワークの選定ミス
私1人の半日ハッカソンを想定していたため、本番稼働までの技術スタックは、ひたすら「速さ」と「セットアップの手軽さ」に振り切りました。そのために利用したStreamlitはセッション永続化や認証まわりの作り込みが得意なフレームワークではなく、どちらかというと小規模・短命なツールに向いています。最初速度優先で採用したものの、延期になって速度優先の前提は崩れており、より堅牢なセッション管理がしやすい構成へ切り替えるべきでした。小手先の改修で臨んでしまったせいでバグが発生しました。ここは改善して、よりストレスなく使えるものにしていきたいと思います。
パフォーマンス面の考慮不足（締め切り直前のアクセス集中）
今回はCloudRun+SQLite+Litestreamという構成でハッカソンに臨みました。全て1つのコンテナの中で動作が完了する最小構成で、インフラ費用を抑えることができます。一方でLitestreamの制約でコンテナのAutoScaleには対応できません。Streamlitのセッションの問題もありましたし、正直そんなに利用されるとは思っていなかったため、AutoScaleに対応しない方針とし、この構成を採用しました。
実際にハッカソンのほとんどの時間で問題なく動いていました。しかし、締め切り数時間前の処理は十分に処理しきれていませんでした。締め切り直前にアクセスが集中することはちょっと想像すれば分かるはずですね。甘かったです。
次回使う時はDB部分はRDSなどに切り出し、負荷集中時のAutoScaleに備えたいと思います。
フィードバックの妥当性について
フィードバックを有用と考えている人とそうでない人はチームによって傾向が存在しました。有用性を感じた人が支配的でしたが、いくつかのチームでは有用ではなかったようです。ただこれはJudgie-AIの課題というより、ハッカソンの運営上の課題と分析しています。
このハッカソンに2通りのチームが存在していました。
- 業務改善: “社内オペレーションの効率化、既存プロセスの自動化”
- ビジネス: “新規顧客価値の提案、マネタイズや市場性を含む検討”
AIの審査員パネルはビジネスや革新性という評価軸を与えられて評価をしているため、そのようなフィードバックを与えます。しかし、日頃の業務の改善を目的としていたチームにとっては、評価軸が噛み合わない指摘になるでしょう。
ただJudgie-AIでは評価軸は予め競技者に共有されています。これは、むしろクリアでフェアな評価をしているということであり、人間より優れている部分とも考えられます。人間だったら前提の評価軸をずらしてアドバイスを送っていたでしょう。
次回は前提を統一したり、参加カテゴリ（業務改善/新規事業）ごとに評価軸を分けられるようにすると、納得感がさらに上がるかもしれません。
振り返り — OSSとして世界に放流します
Judgie-AIは、私が抱えていた「英語での審査が不安」という個人的な課題から生まれました。しかし、ハッカソン・評価という場において、世界中の人が抱える普遍的な課題を支援できるようなソフトウェアになる可能性があります。まずは、ハッカソンの運営を楽にし、競技者により豊かで公平なフィードバックを届けるため、ソースコードを GitHub の yosuke1024/Judgie-AI に置き、OSS（オープンソース）として公開します。
こちらは速度に全振りしたため発生していたセッション管理の問題を解消した改良版です。上記のアンケート結果は、ハッカソン本番で実際に使ったバージョンのものです。 OSSとして公開している版では、本番で問題になったセッション管理とフレームワーク周りを改めて手を入れています。UIやフレームワークも見直しました。Railwayでデプロイできるようにしており、READMEにデプロイリンクも記載しています。数分で利用可能になるはずです。
更なる進化
実は開発のなかで、とてもエキサイティングな気づきもありました。このフォーマットは、ハッカソンだけに閉じたものではない、ということです。評価基準とペルソナを入れ替えれば、より汎用的なAIによる評価プラットフォームになると確信しました。
OSS公開の準備にあたり、ハッカソン向けに考えていたテンプレート共有を、コードを変えずに誰でも公開・読み込みできる形へ広げました。Judgie-AIはさらに進化しました。
- JSON テンプレート — ハッカソン以外を想定したペルソナや評価基準をJSONで定義し、テンプレートとして選べるようにした
- Gist 連携 — テンプレートをGitHub Gistに公開すれば、そのURLから自由に読み込めるようにした
現在、ハッカソン以外に以下のテンプレートをGistで公開しています。
勢いに乗って、テンプレート公開用のマーケットプレイスまで作ってやろうかと本気で検討しましたが……いやいや、まだ誰も使っていないソフトウェアで気が早いと我に返り、そこは手を引きました。
公開したあとも、テンプレートが増え、入れ替わるほどにJudgie-AIは進化します。ハッカソン以外の用途向けのペルソナや評価基準が共有されればされるほど、プラットフォームとしての幅と深さが伸びていくはずです。
ただJudgie-AIにもまだ課題があります。AIが出す評価の品質がどうなるかは、実際に回してみるまで分かりませんでした。ちゃんと筋の通った評価になるだろうか。皆に高すぎる点数ばかりつけないだろうか。正直、そこは心配でした。ハッカソンで一度実績を積み、競技者からの評価も高かったことで、少なくともこのハッカソン向けのテンプレートは、公式テンプレートとして公開してよい手応えを得られました。
とはいえ、今後テンプレートを増やしていくとき、「その品質をどう担保するか」という問いに対する答えは、まだ私の手元にはありません。Judgie-AIは実験の途中であり、実績もまだ足りません。実際のプロンプトを眺めれば、「もっとこうすればいいのに」と思う方も多いはずです。
多くの人と一緒に、より便利に使えるものにしていくことが私の望みです。IssueやPull Request、あるいはGistに載せたテンプレートの紹介でも構いません。この不確実な実験を、皆さんと一緒に信頼できる形のプラットフォームへ育てていけたら、それ以上に嬉しいことはありません。
📢 【次回予告】コードを1行も書かずに、AIの専門家組織とアプリをリリースした話
今回のJudgie-AIの「複数ペルソナによる審査議論」という設計。実は、Judgie-AIの5人の審査員は、文中でも触れた私がプライベートで開発したAI食事記録アプリ 「PixMeal」 の時に作った14人のAI専門家組織の副産物でした。
次回のブログでは、自分自身に「コードを1行も書かない」というルールを課し、AIの中に14人の仮想専門組織（CEO AI、UXデザイナー、ホワイトハッカー、法務など）を立ち上げてGoogle Play/App Storeへのリリースまで駆け抜けた開発体験記を公開します。こちらもただの開発体験記を超えてかなり暴走してしまい、 超大作なブログ記事になりそうです。
数週間以内に公開予定ですので、もし今回のJudgie-AIが面白いと思っていただけたら、私のXのフォローや、GitHubのStarをしてお待ちいただけると嬉しいです！
採用について
Money Forward Indiaでは、このように「目の前の課題や不条理を、AIや最新の技術スタックを使って自らハックしていく」情熱を持ったエンジニアを募集しています。 私自身、英語で審査をするのが嫌だったので、その不条理をツールで解決しました。Money Forward Indiaには、そうした「課題を受け入れる」のではなく「課題そのものを作り変える」エンジニアを求めています。 もしこの話に少しでも共感したなら、きっと一緒に面白いことができるはずです。ぜひお話ししましょう。
