AIが出題し、AIが採点する"記述式AWSクイズ"を作ってみた

好きなクイズ番組は「クイズ世界はSHOW by ショーバイ!!」の畑野です。

本記事では、LLM-as-a-Judgeの概念を採用し、AWS公式情報のみを根拠とした記述式AWSクイズアプリを構築した取り組みを紹介します。

生成AIを「問題作成者」だけでなく「評価者」としても活用し、評価基準（rubric：採点観点のチェックリスト）を明示した上でスコアリングを行う構成としました。

またハルシネーションを抑制するため、AWS Knowledge MCP Serverを用いたRAG構成を採用し、推論はAmazon Bedrock（Converse API）経由で実行しています。

このクイズアプリは社内イベント SREフェス で公開したものです。
フェスのテーマが「課や部を超えた交流」だったため、回答は選択式ではなく、あえて記述式を採用しました。
私たちはAWS専業クラウドインテグレーターであるため、「知識でバトルする」形式が最も盛り上がると考えました。

アプリのソースコードは本記事の最後の方にリンクしています。

SREフェスとは
AWSクイズ企画の設計思想
構成図
設計のポイント
出題レベルのバランス
"知識量"ではなく"思考力"を試す工夫
クイズ例
盛り上がったクイズ
やってみて分かったこと
改善したいポイント
- 今後の発展構想
ソースコード
まとめ

SREフェスとは

SREフェスは、SRE案件を担当している課や部を横断して取り組みを共有する社内イベントです。普段は交わらないメンバー同士が、SREという共通テーマで交流することを目的としています。知見の共有だけでなく、「横のつながり」を生み出すことが大きな狙いです。

AWSクイズ企画の設計思想

チーム戦・記述式にすることで、自然と議論が生まれる設計にしました。早押しや選択問題ではなく、チームで答えを導くプロセスを採用することで、「知っている人が答える」ではなく、「チームで考える」ことを促す仕組みです。

構成図

CloudFrontをエントリポイントとし、静的コンテンツはS3、APIは、API Gateway（HTTP API）+ Lambdaで構成しています。図には記載がありませんが、社内イベント用途のためAWS WAFをCloudFrontにアタッチし、IP制限を行い、ユーザー認証は実装していません。

カテゴリを選択し、レベルを100～400の間でクイズを生成します。クイズをランダムかつリアルタイム生成することで、ライブ感を狙いました。

また各チーム名と得点をリアルタイムで表示することで、バトル感をかき立てています。

回答を入力し、回答ボタンを押下すると、スコアとフィードバックコメントが表示されます。正否判断は評価基準を設けることで、どの要点を満たした回答かを判断し、得点化しています。

また正解を確認したい方向けに、送信後に模範解答を表示する機能も実装しています。余談ですが、問題をGPT系モデルに丸投げして回答を作ると、評価基準を満たさないと加点されないため、100点にならないことが多かったです。

一見「正しそうな回答」と、「評価基準を満たす回答」は必ずしも一致しないことが分かりました。評価設計が曖昧だと、LLMは「もっともらしい回答」を出力してしまうことも実感しました。

設計のポイント

LLM-as-a-Judge設計における考慮点

記述式クイズの採点をルールベースで実装することも検討しましたが、以下の課題がありました。

似たような表現の網羅が困難（定義が複雑化する）
観点を含んでいれば点数化したい
「なぜそうなるか」という説明力を評価したい

結果、本アプリでは問題生成と採点をLLMに委ねるLLM-as-a-Judgeの概念を採用しました。*1
採点は評価基準を明示した上で行い、スコアに信頼性を持たせています。

生成用と採点用でtemperatureやmaxTokensを分けて調整し、将来的なモデル差し替えが可能な構成としています。*2
また、Guardrailsも環境変数指定で適用できるようにしています。

採点プロンプト設計

採点時には評価基準として以下を明示しています。

必須観点（正解判定に必須）
加点対象観点（より深い理解を示す内容）
減点要素（よくある誤解）

temperatureは0に近い値に設定し、再現性を重視しました。
再現性とコスト効率を考慮し、推論は1回のみとしています。

RAG構成とハルシネーション抑制

本アプリではベクトルDBは利用しておらず、AWS公式情報を明示的に取得してプロンプトへ挿入しています。クイズ生成および評価基準の根拠は、AWS Knowledge MCP Serverから取得した公式情報のみをコンテキストとして与えています。コンテキスト設計としては下記を考慮しています。

不要な情報は除外
問題カテゴリごとに取得範囲を限定
トークン上限を考慮し、重要部分のみ抽出

ハルシネーション対策としては、

公式情報を必須参照
根拠記載を促すプロンプト設計
Guardrailsを環境変数で有効化可能

生成AIを「万能な知識源」として扱うのではなく、信頼できる一次情報を中心に据える設計思想を重視しました。

それぞれの詳細な解説は後述のリポジトリにまとめております。

出題レベルのバランス

問題の難易度は100〜400のスコア帯で設定しました。
初級者も参加できる問題と、上級者が唸る問題を混在させています。
誰か一人が無双するのではなく、チーム全員が関われる構成を意識しました。

"知識量"ではなく"思考力"を試す工夫

単純なサービス名当てではなく、「なぜそうなるのか」を問う問題を中心にしました。
曖昧な回答でも要点を押さえていれば加点されるよう、評価基準を設計しています。
暗記力よりも、理解力と説明力が試される形式にしています。

クイズ例

カテゴリとレベルから動的に生成することができます。
例では、カテゴリーはSecurity、レベルは100としています。
即答はなかなか難しいのではないでしょうか。

盛り上がったクイズ

ネットワーク構成をVPCピアリング、トランジットゲートウェイ（TGW）にするかについて、コストを抑えつつ将来的な拡張性を考慮して、選んだ理由まで答えるというものです。例えば、フルメッシュ構成の複雑性や、ルーティングの集中管理といった観点が論点になるかと思います。

やってみて分かったこと

記述式にしたことで、自然と議論が生まれました。
難しすぎると手が止まり、簡単すぎると盛り上がらないため、「チーム内に1人はヒントを持つ人がいる」程度の難易度が最適だと感じました。テックリードに若手が「なぜそう考えるのですか？」と問いかける場面は、双方にとって学びのある時間でした。

イベントでは6チーム、計4問を出題しました。クイズ1問あたりの推論時間は平均23秒、トークンはtotalTokensが平均約2800（ログ例では2,569 tokens）、当日の総コストは$1.41でした。 CloudWatch Logsには1処理ごとに下記のようなログが出力されます。

"metrics": {
  "latencyMs": 23141
},
"usage": {
  "inputTokens": 1087,
  "cacheReadInputTokens": 0,
  "cacheWriteInputTokens": 0,
  "outputTokens": 1482,
  "totalTokens": 2569
}

改善したいポイント

ライブ感を演出するためにクイズ生成をリアルタイムで行いましたが、生成に20～30秒ほどかかります。 Bedrockのバッチ推論で事前に生成して、その中からランダムで選ぶ方がユーザー体験的には良かったかもしれません。*3

今後の発展構想

クイズを事前生成する場合は、キャッシュ設計も併せて検討すると、応答時間の短縮やBedrockのコスト削減に有効だと考えています。あとは、学習用途にも転用できそうなため、回答例を集めて、回答者に応じた適切なクイズ生成を行う仕組みを取り入れると、AWS認定資格の取得を目指す方への教材としても利用できそうです。