PRODUCT NOTE / 検証
クイズと試験問題が 5,855 件、書籍の原稿が 4 冊。どちらも「ビルドが通る」ことと「中身が正しい」ことが別で、しかも全部を読み直すことはできません。
このノートは、その状態で何を機械に任せ、何を人が読み、事実をどう確かめているかの現時点での解です。うまくいかなかった決め方も残しています。
| 対象 | 問題・教材文 5,855 件（クイズ 2,797 問 ／ 試験問題・教科書の節・用語 1,619 件 ／ 音声つき教材文 1,439 文）と、書籍 4 冊ぶんの原稿 |
|---|---|
| 道具 | 形式テスト（アプリごと）／ 問題の生成スクリプト ／ 送り読みのレビュー画面 3 本 ／ 原稿の検査 4 本（禁止語・日本語校正・実物の露出・数値の正本）／ 音読 |
| この解の要点 | 機械に合否を出させない。機械は形式を落とし、残りを怪しい順に並べるところまで。合否は人が持ち、事実は出典が持つ |
| このノートの範囲 | 判断だけ。社内の事例は役割語に置き換えてあり、固有名・実テーブル名・課題番号は載せていない |
| 最終更新 | 2026-09-12 |
| 関連 | Dotpile（クイズ） ・ Certly（試験対策） ・ 社内 AI エージェントの設計 |
テストは形式までしか見られない。ID の重複も、誤答が 3 つあることも、正解が誤答に混ざっていないことも機械で分かるが、「その答えは本当に正しいか」「解説はそれを説明できているか」は人が読むしかない。
そして 2,000 問を机の前で読み切ることはない。だから機械の仕事を「合否を出すこと」から「読む順を作ること」へ変えた。
事実の側は出典・数値の正本・実行履歴との照合で持ち、人はその上を送り読みする。
問題を 100 問から 2,797 問へ、原稿を 1 章から 4 冊へ増やすと、検証の壊れ方が変わる。少ないうちは「全部読む」で成立していたものが、ある時点から誰も通しで読まなくなる。
読まれないまま増えるので、間違いは足された順に溜まっていく。
この状態で起きることが 3 つある。
いちばん効いたのは道具ではなく、層を分けて、各層が見られないものを明記したことだった。書いていないと、次に読む人（と半年後の自分）が「検査が通っているから大丈夫」と読む。
| 層 | 何を見るか | 道具 | この層では見られないもの |
|---|---|---|---|
| 1. 機械で落とす | 形式・スキーマ・ID の重複・誤答の数・正解が誤答に混ざっていないか・数値の一致・日本語の質 | アプリごとの形式テスト、原稿の検査 4 本 | 書いてあることが事実かどうか |
| 2. 機械で並べる | 怪しさ。重み付きの札を立てて、読む順を作る | レビューデータの生成（札は 16 種） | 合否。機械は札を立てるだけで、判定はしない |
| 3. 人が読む | 日本語として読めるか、その誤答の理由に納得できるか | 送り読みのレビュー画面 3 本 ／ 原稿は目と耳 | 全部は読めない。だから 2 で順番を作る |
| 4. 出典が持つ | 数字と事実の出どころ、いつ時点のものか | 問題ごとの出典 URL、原稿の出典一覧、数値の正本 | 出典そのものの誤り。取得日で腐りを見るしかない |
3 層目の「耳」は原稿にだけ使う。目で読むと脳が補完するが、耳では補完が効かない。
読点のない長い文、同じ語尾の連続、主語の迷子が一発で引っかかる。章の Markdown から読み上げ用のテキストを起こして音声にし、倍速で流す。
コードブロックも表も URL もそのまま読ませてはいけない（5 分で聞くのをやめることになる）ので、音で意味を持つものだけ残す処理を挟んでいる。
機械の検査と人の送り読みで、見る対象を重ねない。ID の重複・正解の数・誤答の一行の欠け・出典 0 件・章 ID の綴り違いは全部ビルドが落とす。
レビュー画面に出すのは「日本語として読めるか」「その誤答の理由に納得できるか」だけにした。
572 問足したときも、テストは 1 行も直さずに通った。
かわりに「同じ問いが二度出てこない」「誤答すべてに一行がある」「正解が誤答の中に混ざっていない」「ID が 3 桁ゼロ埋め」など、壊れると遊べなくなる性質を全問について見ている（24 項目）。
全体の 1 割を超えて当たる札は目印にならない。「解説が 20 字未満」は 1,512 問中 375 問に点いた。
別の教材では「別名に日本語」が 314 件中 209 件、「非公式の出典」が 496 件中 441 件に点いた（MDN や RFC を引くのが正しい場面だった）。
半分に札が付いた一覧は誰も見ない。
3 つ落として、残した札に重みを付けた。英訳の欠けは重み 0 にしてある —— 496 件中 476 件が未訳なので、重みを持たせると怪しい順がそれだけで埋まって、読むべきものが沈む。
数えたい未訳は言語の絞り込みで見る。
ID は中身を直しても変わらないので、ID だけ見ていると古い OK が残り続ける。逆に出荷物まるごとのハッシュで見ると、1 問直しただけで 356 問が要再確認に落ちる。
指紋は項目ごとに持つ必要がある。
音声つきの教材では指紋を 2 本に分けた。音声のファイル名は本文のハッシュなので引き直しても名前が変わらない。
本文の指紋とは別に、音声の中身の指紋を持たせて、文面の直しと音声の引き直しがそれぞれ独立に「要再確認」を立てるようにした。
強調記号の開き・閉じは前後の文字種で決まる。日本語は助詞がそのまま続くので、この規則に実際に当たる。
素朴な正規表現で畳むと、アプリでは記号のまま出る箇所がレビュー画面でだけ太字になり、壊れているものを壊れていないと報告してしまう。
乱数のシードを問題ごとに固定したので、2 回流しても差分が出ない。誤答は「同じ地方 → 同じ大陸 → 全体」の 3 段で近いものから引く（ありえない選択肢が混ざると消去法で解けてしまう）。
素材テーブル自身にも検査を置き、隣接が片方向だけ書かれている・順位と値の並びが食い違う・誤答を作れるだけの国が大陸に残っていないを弾く。
2 位や上位 3 件を問うのは、下位と十分離れているときだけにした（僅差だと統計の更新で正解が入れ替わり、問題が嘘になる）。
2 値で持つと、分からないものが OK か NG のどちらかに紛れる。仕様が読めないものを憶測で NG にすると、直す側の工数が無駄になる。
判定する人に要るのは「NG を出す勇気」ではなく「保留する権利」だった。
件数の絶対値は可否と対応しない（教材コードを載せる本ほど多く鳴る）。使い方を 2 つに限った —— コードを載せないと決めた本では許可済みを除いて 0 に保つ、載せる本では鳴った箇所が教材用か実物かを人が 1 件ずつ判定する。
ここは機械には分からない。
上の 8 つは、どれも事実かどうかは見ていない。「日本語として読める」「形式が正しい」と「書いてあることが本当」は別で、後者を機械で判定する方法は持っていない。持っているのは、後から追えるようにしておくための仕掛けだけ。
試験対策アプリでは出典 URL が無い問題は出荷しないことにして、ビルドが弾く。クイズアプリでは統計と実測値の 244 問にだけ付け、手書きジャンルには付けないと決めた。
小説や花の問題は常識で答えられるぶん、リンク切れの管理コストのほうが大きくなる。付けない範囲も決めておかないと、付いていない問題が「漏れ」なのか「そう決めた」のか分からなくなる。
きっかけは「埼玉県は 7 つの都県と接する」という解説を疑われたことだった。実際には正しかったが、そのとき「どこの数字か」を答えられなかった。
順位を問う問題は年で答えが入れ替わるので、出典が言えないものは検証も修正もできない。付けると決めた 244 問は、あわせて一次資料から機械で数字を抜き直し、手で書き写す工程を無くした。
官公庁の統計は商用利用できるが出典の記載が条件なので、この対応は有償化の下地にもなっている。
書籍側では出典一覧を付録に置き、1 件ごとに次の欄を埋める。
| 欄 | 意味 |
|---|---|
| 発表日 | 出典側が公表した日 |
| 取得日 | 実際に開いて数値を確認した日。ここが規律の本体 |
| 規模と手法 | n・対象・調査方法。これが書けない出典は使わない |
| 限界 | 出典自身が述べている適用範囲の限界 |
賞味期限の起点は発表日ではなく取得日になる。AI 関連の調査は 1 年で古びるので、取得日が古びた項目は改訂のたびに引き直す。
あわせて、採らなかった数字と、採らなかった理由を同じ付録に 1 節置いている。採った数字だけ並べると、選び方そのものが検証できない。
書籍をまたいで出てくる実測値は、「値・意味・正本の本・掲載を許す本」の 4 列で 1 か所に持ち、機械で照合する（いま 21 件）。
ブレるのは値より意味のほうが多い —— 同じ 250.9 時間でも、受益者で割った数字と業務カテゴリで割った数字を取り違える。
だから「意味」の列を必ず書かせている。検査は「許していない本に出ていないか」と「正本の側に記載があるか」の両方を見る。
社内で動かしている AI エージェントでの話（固有名は伏せる）。問い合わせへの回答に「■確認したこと: ○○を直接確認」と書かせ、点検役にレビューさせていたが、実際にはそのデータを一度も参照していない回答が本番に出た。
点検役が見ていたのは開示の有無だけで、開示の正しさは一切見ていない。
対策はプロンプトに注意書きを足すことではなく、根拠欄に書かれた参照先と、そのターンの実行履歴を機械で突き合わせることにした。履歴に無いものが 1 つでもあれば無条件で差し戻す。この照合を作るときに要った条件が 3 つある。
採点役を立てるときは、材料を実際に実行したコマンドとその出力・差分そのものに限り、実装者の説明や意図を材料にしない。判断がつかない場合は FAIL にする（UNKNOWN は PASS ではない）。
書いた本人に採点させない。ループエンジニアリング実践ガイドに置いてある型で、これはいまのところ人が 1 件ずつ回していて、問題バンクに対してバッチでは動かしていない。
まとまった量で回したのは多言語の翻訳レビューだけで、言語ごとに敵対的に洗い出させて「高（学習内容として誤り・文字化け）／中（事実の不整合・用語不統一）／低（文体・体裁）」で分類させた。
全角プラス記号や波ダッシュの混入、「3 音節以上は more / most」と書きながら例が 2 音節、母音の列挙が五十音順になっている、といったものが出た。
凡例を先に決めておかないと、指摘の山だけが残って直す順が決まらない。
もう 1 つ、新しい検査は一度わざと失敗させてから信用する。壊した状態で落ちることを見ていない検査は、通っていることが何の証拠にもならない。検査を足したときは「これでも見つからないもの」を同じ場所に書いておく。
このノートを書くために測り直して、自分の穴が 4 つ見つかった。直す前に書いておく。
社内で運用しているシステムの事例は、社名・製品名・人名・テーブル名・課題番号を伏せ、役割語に置き換えて書いています。件数はいずれも公開時点の実測値で、数え方はアプリのリポジトリ側のスクリプトが持ちます。
記述は運用上の判断の整理であり、特定の構成を推奨するものではありません。
