2026-08-02 のレビューで、実装バグではなく コンセプト上の緊張 として挙がった点。判断が要るので Issue として残す。
問題
system-spec §8.3 が正直に書いているとおり、窓内・同一マシンでの忠実な転写は防げない。学生が手元のスマホで LLM を開き、答えを見ながら自分で打鍵すれば proof は完全に valid になる。
つまり TypedCode が実効的に排除するのは「コピペと一括生成」であって「AI 利用」ではない。
この gap を埋める役割は ADR-0023 の判断により分析層と人間の読み手へ委譲されているが、その分析層は W5 の運用ゲート (実測 FPR が許容内と示されるまで heuristic を review に昇格させない) により advisory プレースホルダ据え置き。
結果として「今日の TypedCode が試験に追加する実効的な保証は何か」が説明しにくくなっている。
なぜ問題か
判断そのもの (防げないものを防げると言わない・判定しない) は正しい。問題は 期待値調整が製品の説明面に落ちていないこと。
- README は「AI 生成や自動コピーを防ぎたいプログラミング試験」を主用途に挙げる。教員はこれを「AI 利用を防げる」と読む可能性が高い
- ランディング (
/) の 4 モード比較カードは能力差を見せるが、「各モードで何が保証され、何が保証されないか」の非対称までは伝えていない
教員が過大な期待で導入し、後で「AI を防げないじゃないか」となるのが最悪の失敗モード。逆に正確に伝えられれば「コピペ・一括生成の排除 + 過程の可視化 + T0 束縛」は十分に価値がある。
やること (案)
- README / ランディングに「TypedCode が防ぐもの / 防がないもの」を明示する短い節を置く (spec §8.3 の要約を、教員が読む場所に持ってくる)
- モード比較カードに保証レベルの列を足す
- 「AI 生成や自動コピーを防ぎたい」という表現を、実際に防げる範囲の表現に直す
関連: #230 (README の overclaim 修正) と同じ PR で扱ってもよい。
2026-08-02 のレビューで、実装バグではなく コンセプト上の緊張 として挙がった点。判断が要るので Issue として残す。
問題
system-spec §8.3 が正直に書いているとおり、窓内・同一マシンでの忠実な転写は防げない。学生が手元のスマホで LLM を開き、答えを見ながら自分で打鍵すれば proof は完全に valid になる。
つまり TypedCode が実効的に排除するのは「コピペと一括生成」であって「AI 利用」ではない。
この gap を埋める役割は ADR-0023 の判断により分析層と人間の読み手へ委譲されているが、その分析層は W5 の運用ゲート (実測 FPR が許容内と示されるまで heuristic を
reviewに昇格させない) により advisory プレースホルダ据え置き。結果として「今日の TypedCode が試験に追加する実効的な保証は何か」が説明しにくくなっている。
なぜ問題か
判断そのもの (防げないものを防げると言わない・判定しない) は正しい。問題は 期待値調整が製品の説明面に落ちていないこと。
/) の 4 モード比較カードは能力差を見せるが、「各モードで何が保証され、何が保証されないか」の非対称までは伝えていない教員が過大な期待で導入し、後で「AI を防げないじゃないか」となるのが最悪の失敗モード。逆に正確に伝えられれば「コピペ・一括生成の排除 + 過程の可視化 + T0 束縛」は十分に価値がある。
やること (案)
関連: #230 (README の overclaim 修正) と同じ PR で扱ってもよい。