結論から書く。AWS Certified AI Practitioner（AIF-C01）の学習で、Claude Code に本番形式の模試を 65 問つくらせたところ、複数選択問題の正解が「A と B」に極端に偏っていた。13 問中 11 問（85%）が「AB」で、内容を理解しなくても機械的に得点できる状態だった。さらに 4 問は「2 つ選べ」なのに正しい記述が 3 つあり、採点そのものにも 1 問取り違えがあった。
この記事は、その偏りを採点前に機械的に検出する方法と、AI に問題セットを量産させるときの品質検証チェックリストをまとめたものだ。AWS 資格の話に見えて、中身は「LLM に選択式の問題集をつくらせる人全員」に効く内容になっている。学習プロセス全体の振り返り（前資格からの学習規律の転送）は note 側に書いた（末尾にリンク）。
何が起きたか: 複数選択の正解が「AB」に固まっていた
本番前日の最終リハーサル用に、Claude Code に 65 問の模試を生成させた。答え合わせをしていて、複数選択問題（「正しいものを 2 つ選べ」タイプ）の正解が続けて「A と B」なのに気づき、複数選択とケース問題を全部数えてみた。結果がこれだ。
| 正解パターン | 問題数 | 割合 |
|---|---|---|
| AB | 11 問 | 85% |
| AC | 2 問 | 15% |
| それ以外（C 以降が正解に含まれる） | 0 問 | 0% |
| 合計（複数選択・ケース問題） | 13 問 | 100% |
C・D・E が正解に一切登場しない。つまり、この模試は「複数選択なら、とりあえず A と B を選ぶ」だけで 13 問中 11 問を正解できる。模試の一番の仕事は理解度を測ることなのに、それが成立していなかった。正答率は高く出るが、その高さは実力ではなく攻略パターンで説明できてしまう。
気づいたきっかけは大したものではない。3 本目の模試を解いている途中、「あれ、さっきの問題もその前の問題も、なんか同じパターンが続いてるな」とふと引っかかっただけだった。そこで初めて手を止めて、複数選択とケース問題を全部数え直してみた。
なぜ偏ったのか: 「正しい選択肢から先に書く」手順の構造リスク
偏りの原因は、AI の作問手順そのものにあった。振り返ると、複数選択問題は次の順序でつくられていた。
- まず「正しい記述」を 2〜3 個思いつく
- それを選択肢の先頭（A, B, C…）から順に並べる
- 残りの選択肢に誤った記述を埋める
この手順には 2 つの構造的なバグが埋め込まれている。
- 正解が前方に集中する: 正しい記述を A から順に置くので、正解は自然と A・B に寄る。ランダム化の工程がどこにもない
- 正しい記述を書きすぎる: 「2 つ選べ」という制約を、選択肢を書き終えた後に検算していないので、勢いで正しい記述を 3 つ書いてしまう
人間が問題集をつくるときは、無意識に正解位置を散らしたり「2 つ選べだから正しいのは 2 つ」と数え直したりする。ところが LLM に「良い選択式問題をつくって」とだけ頼むと、この暗黙の検算工程が丸ごと抜け落ちる。LLM は指示されていない検証を勝手にはやらない、という当たり前のことが、正解位置の偏りという形で表面化したわけだ。
もう一つの不備: 「2 つ選べ」なのに正しい記述が 3 つ
正解位置の偏りを調べる過程で、より深刻な不備も見つかった。複数選択 13 問のうち 4 問（31%）で、選択肢に正しい記述が 3 つ含まれていた。設問文は「2 つ選べ」なのに、正解候補が 3 つある。これは受験者側からは正解が確定できず、採点も破綻する。私はこの 4 問を採点対象から外し、有効 61 問で正答率を再集計した。
正解位置の偏り（①）と正解数の矛盾（②）は、別々のバグに見えて、根っこは同じ「書き終えた後に数え直していない」だ。①は位置を数えていない、②は個数を数えていない。どちらも、生成の後にカウントによる検算を挟めば機械的に潰せる。
AI が採点した結果にも取り違えがあった
作問だけでなく、採点にもバグがあった。同じ模試の答え合わせで、ある 1 問が「不正解」として集計されていたのに、自分の解答が正しいはずだと引っかかった。確認すると、採点側の取り違えだった。指摘して正解に直した。
ここが今回いちばん腑に落ちたところだ。問題をつくった AI も、採点した AI も間違えていて、それを拾ったのは解いている人間の側だった。「AI に任せれば検証もいらない」ではなく、「AI に任せるほど、人が最後に数える工程が効いてくる」。作問・採点を AI に寄せて効率を取るなら、その分だけ human-in-the-loop の検算を意図的に設計しておく必要がある。
AI に問題セットをつくらせるときの品質検証チェックリスト
今回の 2 つの不備は、いずれも生成後に機械的なカウントを 1 回挟めば検出できる。資格の模試に限らず、LLM に選択式の問題セットを量産させる場面すべてに使えるチェックリストとして一般化しておく。
生成後・利用前に必ず走らせる検算
- 正解位置の分布を数える: 全問の正解を集計し、特定の位置（A / B）に偏っていないか確認する。選択肢が n 個なら、正解位置はおおむね均等にばらけているのが健全
- 複数選択は正しい記述の数を数え直す: 「2 つ選べ」なら正しい記述が厳密に 2 つか。設問文の指示個数と、選択肢内の正解候補の数が一致しているか
- 並べ替え問題は順序が一意に定まるか確認する: 実務上どちらの順序も成立し得る手順（例: データ収集とモデル選定の順）は、解が割れて不備になりやすい。設問文で順序を制約するか、その問題を避ける
- 採点結果を鵜呑みにせず、最低数問は自分で答え合わせする: AI の採点にも取り違えは起こる。全問は無理でも、自信のある問題が誤答扱いになっていないかは目視で拾える
作問プロンプト側に最初から埋め込む指示
- 「正解の選択肢を A〜E のランダムな位置に配置し、特定位置に偏らせないこと」を明示する
- 「複数選択は、選択肢を書き終えた後に正しい記述の数を数え、設問文の指示個数と一致することを確認してから確定すること」を明示する
- 「各問について、正解位置の分布と正解数の検算結果を出力に付記すること」を求める（検算を出力させると、人間側のレビューが一気に楽になる）
ポイントは、検証を「後工程の人間の善意」に頼らず、プロンプトの中に検算そのものを組み込むことだ。私はこのチェックリストを、模試生成に使っているプロンプト集に項目として追記した。次からは、同じ偏りが生成の時点で弾かれる。
まとめ
AI に選択式の問題集をつくらせると、正解位置の偏り・正解数の矛盾・採点の取り違えという 3 種類のバグが、いずれも「生成後に数え直さない」ことから同時に発生し得る。今回はたまたま本番前日に気づけたが、それは日頃から採点結果を自分の手で確かめる癖があったからで、仕組みで担保されていたわけではなかった。
対策はシンプルで、生成後にカウントベースの検算を 1 回挟むこと、そしてその検算をプロンプト側に最初から埋め込むことだ。LLM は指示していない検証を勝手にはやってくれない。逆に言えば、検証を指示に落とし込めれば、この種の不備は生成の時点で潰せる。残っている課題は、この検算を「毎回手で走らせる」から「生成パイプラインに常設する」へどこまで自動化できるか、だと思っている。
よくある質問
Q: AI に模擬試験をつくらせたら、そのまま使っていいですか？
A: 正答率だけを見て信じないほうがいい。今回、Claude Code につくらせた AIF-C01 模試では、複数選択 13 問中 11 問（85%）の正解が「A と B」に偏り、4 問は「2 つ選べ」なのに正しい記述が 3 つあった。生成後に、正解位置の分布と正解数を機械的に数える検算を挟むのがおすすめだ。
Q: 正解が特定の選択肢に偏るのはなぜですか？
A: LLM は「正しい記述を先に思いつき、それを A から順に並べる」手順で作問しがちで、正解位置をランダム化する工程がプロンプトに書かれていないと抜け落ちるからだ。作問プロンプトに「正解を A〜E のランダムな位置に配置し、偏りを検算して出力に付記すること」を明示すると軽減できる。
Q: AI の採点結果は信用できますか？
A: 採点にも取り違えは起こる。今回も 1 問、正解を誤答として集計していたのを目視で見つけて訂正した。全問は無理でも、自信のある問題が誤答扱いになっていないかは人が拾える。作問・採点を AI に寄せるほど、人が最後に数える工程を意図的に設計しておくとよい。
Q: このチェックリストは AWS 資格以外にも使えますか？
A: 使える。正解位置の分布を数える・指示個数と正解数の一致を確かめる・生成物のカウント検算をプロンプトに埋め込む、という考え方は、LLM にテストケースやダミーデータなど「セット」を量産させる場面すべてに適用できる。中身は AWS 固有ではなく、LLM 生成物の品質検証一般の話だ。