SCOA体験模試
コンテンツ＆供給システム 仕様書 v1.1

1. 全体像 — 何が、どこから、どう配られているか

SCOA体験模試も「①問題を作る」「②正本として版を固める」「③配る」の3層です。SPI・公務員と同じ正本リリース・同じ出題workerに相乗りしていますが、SCOAだけは問題型を「カード」として定義し、そのカードを指定して出題するという組み立て方をします。この節の記載はすべて 2026-07-26 に本番URL・本番R2を叩いて実測したもので、§2 以降（2026-07-23 時点）より新しい状態を表します。差分は節末にまとめました。

1-1. 体験10問がどう組まれるか

SCOAの出題は、SPI・公務員の「試験種の科目配分＋単元の重み」とは違い、体験版レシピ（profile_id = scoa-a-trial）が「1問目はこのカード、2問目はこのカード」と順番に指定する方式です。実測した応答には、レシピ自体の改竄検知用に blueprint_sha256 が付いていました。

※ 各スロットの選択方式は exact（カードを名指し）です。したがって出題の構成は毎回同じで、中の問題だけが入れ替わります。

2. 現在の状態

fact本番未公開です。コード上でも裏付けが取れています。

3. コンテンツ仕様

4. 問題型カード（14枚）

SCOAの特徴は、問題型を YAMLの「カード」として定義している点です。カードには生成器の参照先・難易度・1セットあたりの上限・誤答の設計方針・解説様式・実物SCOAとの突合状態が機械可読に書かれており、量産CLIがこれを読んで動きます。

G10（記号系列）だけが量産から機械除外されています。3層の品質ゲートは通過し承認済みですが、「SCOAの問題型カタログでの裏付けが薄い」という理由で突合状態が weak となっており、量産CLIが「承認済み かつ 突合が weak でない」ものだけを抽出する仕組みのため自動的に外れます。型として採用するかは判断待ちです。

5. 量産と検品

python3 -m spi_generator.scoa.batch --seed <整数> --per-card 12 --out <dir>

  ① カード13枚を抽出（G10は自動除外）
  ② カードごとに問題を生成
       シード = seed×100000 + カード番号×1000 + 連番 + リトライ回数
       → 同じシード・同じカード順なら全問がバイト単位で再現する
       → 1問を差し替えても他問の再現性が壊れない設計
       失敗時は最大10回リトライし、理由を記録
  ③ L1 構造検品（全問・自動）
       選択肢の重複なし／正答と選択肢の整合／解説の段数／誤答タグ4件必須
       テンプレート型はさらに正答を再計算して照合
  ④ L2 人力抜き取り用の材料を生成
       設問と選択肢だけを転記した「独立解き直しシート」と正答キーを別ファイルで出力
       ※CLIはL2の合否を判定しない（人間が解いて突合する）
  ⑤ L3 機械lint
       解説様式のマーカー検査／同一説明文が3問以上に出たら定型文汚染と判定
       「計算ミスに注意」等の類型固有性ゼロの汎用文言を検出

  ⑥ 公開可否の判定（fail-closed）
       ブロッカーを「品質」と「供給」に分類し、
       品質ブロッカーが1件でもあれば公開用ファイルを昇格させず非0終了する

fact実際の量産では13カード×12問＝156候補のうち11件がブロックされ、145問が成立しました。ブロックの内訳は時事バンクの在庫切れ2件（バンクに10件しかない）と正多面体の類似枯渇9件（似た形しか作れなくなった）で、誤答由来のブロックはゼロです。

知識問題34問には事実監査の台帳があり、問題内容のハッシュと監査結果を突き合わせて合格分だけを通す仕組みになっています（台帳エントリ34件＝バンクの知識問題数と一致）。

6. 配信面と図解

6-1. 出題ロジック

出題レシピはハードコードせず外部JSONに切り出し、モジュール読み込み時にスロット数と上限を自己検証して不整合なら即座に停止する作りです。空間把握は1セッションあたり最大1問に機械制約されています（図形問題ばかりになるのを防ぐため）。重複回避は1セッション内で効きますが、セッションをまたいだ出題多様性の保証はありません（複数回受けると同じ10問が再び出る可能性）。

6-2. 図解専用のサニタイザ

SCOAの解説図は段階的に完成していくアニメーションで、SVG内に CSS を埋め込む必要があります。既存の共通サニタイザは <style> を無条件でブロックするため描画できず、専用サニタイザを新設しています。

課題リリース前監査で、名前付き実体参照の一部が未対応との指摘が出ています（§8-1）。

7. 本家SCOAとの関係

fact複製でないことは全問の由来情報に機械的に刻まれています。各カードに「オリジナル生成（実物SCOA問題の複製・流用なし）」、各問題に style_note: "SPI生成器流用。SCOA-A実物の形式適合は未担保" と type_hypothesis_status: "3ソース突合前" が自動付与されます。

形式の規約は、公務員過去問917問・自社バンク1,262問・対策サイト3件以上の突合から「5肢択一」「設問語尾は〜はどれか」「1問30秒〜1分」を確定しています。ただし実装側の選択肢数が全カードで5肢に揃っているかは未検証（§8-6）。

品質保証の体制は、人間講師の監修が当面困難という判断から、AI講師による3層ゲート（構成的な正答保証 → 独立AIによる解き直し → 解説品質のAI監査）に切り替えています。人間講師の盲検監査は投入後の後追いとする方針です。

8. 課題 — 全12件

9. SPIラインからの申し送り（デプロイ前必読）

2026-07-23 に SPI ラインで外販対応を行いました。そこで確立した型と、踏んだ落とし穴を引き継ぎます。SCOAで作り直す必要はありません。

9-1. 着手順の推奨

1. 生成器の正答位置シャッフル（§8-12）— 共通基盤の修正。ここを直すと知識・時事バンクの再生成でSCOAのカードも直る
2. 恒久ID体系への移行（§8-4）— 公開前の今が最安
3. 内容ハッシュへの figures 追加（8-2）— 正本収載の前提
4. 正本リリースへの収載（§8-5）
5. リリース前監査の残ブロッカー2件（§8-1）

9-2. 🔴 収載前に必須の修正：内容ハッシュに図を含める

SPIで作った系譜台帳の内容ハッシュは、現在本文／問題文／選択肢／正答／解説の5要素で計算しており、図を含んでいません。SPI正本には図フィールドが存在しないため実害ゼロでしたが、SCOAで確実に破綻します。

対応：spi_bank_build/lineage/core.py のハッシュ入力へ figures を追加し、重複判定キーにも含める。正規化は「SVG文字列そのもの」ではなく、描画に影響しない差分（空白・属性順・id採番）を除去した正規形とすること。整形の揺れで版が切られると改訂履歴がノイズで埋まります。

9-3. やってはいけない検査

問題文の冒頭60字一致を、重複の出荷停止条件にしてはいけません。SPI正本7,537問で500件が該当し、うち推論476件は数値だけ違う正常なパラメトリック問題でした。停止条件にすると健全な問題を大量に弾きます。

出荷停止にしてよいのは 「NFKC正規化した 本文＋問題文＋選択肢（順序込み）＋図 の完全一致」だけ。冒頭60字一致は警報（レポート出力）に留めてください。

9-4. 流用できる資産

9-5. SPIで実際に踏んだ落とし穴

• デプロイ正路が存在しなかった：出題workerも外販APIもデプロイゲートに未登録で、事故時に戻す手段がありませんでした。SCOAで新しいworkerを出すなら、コードより先に登録を。
• 本番稼働中のコミットが origin に無かった：ローカルが失われたら本番のソースが復元できない状態でした。
• 初回のデプロイで promoter が権限で止まりました：昇格プロセスが台帳を読めず失敗。消費者ゼロのworkerを最初に通してリハーサルにしたので、実利用のあるworkerで踏まずに済みました。SCOAも未公開のうちに正路を1回通しておくことを勧めます。
• 正本バンクはgitignoreされていて世代が残りません：spi_bank_build/* は除外対象で、上書きすると前の版が復元不能です（本日、正答位置の是正で是正前の版を1つ失いました）。バンクを書き換える前に必ずスナップショットを取ってください。
• 外部レビューが出荷を止めました：設計レビュー（Fable）と敵対レビュー（sol）を通した結果、外販API側に「正解を抽出できる経路」が見つかり、NO-GO判定になりました。自分のテストが緑でも、外の目を入れる価値があります。

9-6. デプロイ前チェックリスト（SCOA向け）

1. 変更前のバンクをスナップショット保全したか（checksumと出所つき）
2. ハッシュに figures を含める修正を入れたか（入れないと収載でビルドが止まる）
3. 全カードの正答位置をカード単位で検査したか（尺度単位の集計では偏りが隠れる）
4. リリース前監査の残ブロッカー（サニタイザの名前付き実体参照・プレビュー公開ゲート）を潰したか
5. サイトマップからプレビューURLを除外したか
6. 公開フラグを反転する前に、デプロイ正路を1回通してリハーサルしたか
7. ロールバック手順を書いたか（フラグを戻して再デプロイ／リリースポインタの書き戻し）
8. 受験ログを取る仕組みを入れたか（§8-10。データを取り逃すと較正ができません）