一歩ずつ、確実に。

「何をするか」は、かなり固定できるようになっていた

AIにGitHubを操作させるとき、最初は自然言語のルールだけで事故を防ごうとしていた。対象Repository、branch、操作内容、人間の承認範囲を確認し、実行前にもう一度読み返す。そこから、予定している操作を機械可読な状態として残すSurface PlanやAction Intentへ進み、さらに実行するtoolと引数まで事前に固定するCommand Lockを追加した。

狙いは単純だった。AIが直前で別の操作を思いついても、固定済みの計画と一致しなければ止める。「気をつける」ではなく、「実行前の契約」として残すところまで強くした。

それでも、Issueを作るはずがファイルを作った

New-Type-D-Systemの問題量産作業で、Issueを作成する操作をCommand Lockへ保存し、read-backでも正しいtool名を確認した。その状態から実行すると、実際には別のファイル作成toolが呼ばれた。同じ種類の失敗が4回続き、意図しない小さなファイルが作られた。

作られたファイルはすぐ削除し、branchに不要な差分が残っていないことを確認した。その後、tool経路を読み直して新しい実行境界からやり直すと、本来のIssue作成は成功した。さらに別の工程でも、Gitのblob操作のつもりが通常のファイル作成へ流れたり、Issue作成のつもりがPull Request作成へ流れたりする同系統のズレが観測された。

ここで、Guardの守備範囲が見えた

保存されていた予定は間違っていなかった。Command Lockの中身も、実行したかった操作を指していた。それでも違うtoolが選ばれた。つまり、ルールや状態管理は「AIが何を実行すべきか」を固定できても、その契約どおりのtoolしか物理的に通れない実行器まで自動的に作ってくれるわけではない。

これはかなり重要な境界だった。判断層が正しくても、dispatch層で別の操作が選ばれれば事故は起きる。逆に、実行器だけを強く縛っても、その前の計画が間違っていれば精密に間違った操作を通すことになる。「意図」「実際に選ばれた操作」「結果」を別々に観測する必要がある。

事故をゼロにできなくても、被害を残さない仕組みは効いた

今回の失敗では、read-back、対象branchの差分確認、expected-headによる保護、独立レビューなどが別々に働いた。誤操作そのものは起きたが、異常な結果をそのまま次工程へ昇格させず、最終的な制作branchへ不要な差分を残さずに復旧できた。

安全設計を「間違えないAIを作ること」だけで考えると苦しくなる。間違った選択を検出する、実行結果を読み返す、意図と結果が違えば次へ進ませない、復旧後も証拠を残す。こうした層を重ねると、失敗を前提にしながら壊れにくくできる。

次に必要なのは、ルールを増やすことではない

今回の観測だけで、原因を特定のAIモデル構造へ帰属することはできない。少なくとも分かったのは、自然言語ルール、計画状態、Command Lockまで整えても、実行経路がそれらを強制しない環境では別toolが選ばれ得るということだった。

次に見るべきなのは、さらに「絶対に間違えるな」と書くことではない。固定したAction Intentから許可されたtoolへしか進めない実行境界をどこに置くか。その強制を入れたとき、速度や柔軟性とどの程度トレードオフになるかを観測する。AIを賢く説得する研究から、AIが触れるレバーそのものを設計する研究へ、一段進んだ。

遅かったのは、問題を解くAIではなく、問題を取りに行く経路だった

New-Type-D-Systemで20問の学習セッションを試したとき、Question Bankから問題を取り出して出題準備をする部分に時間がかかっていた。問題数が増えるほど、毎回AIが大きなデータを読み、必要な問題を探し、会話へ持ち込む方式は重くなる。

ここで方針を変えた。Question Bankの正本はGitHubに残す。ただし、毎セッションでAIが正本全体を読むのはやめる。ローカルPythonが必要な表示情報だけをキャッシュし、そこから問題を選んでSQLiteへセッションとして固定する。AIは、その固定済みセッションを使って学習者と会話する。

キャッシュには、正答を入れない

高速化のためにローカルへ複製したのは、問題ID、revision、問題文、選択肢など、出題に必要な情報だけにした。正答位置、正答、解説、採点情報は入れない。キャッシュは便利な第二の正本ではなく、revisionと元データのblob identityに結び付いた使い捨ての表示用投影として扱う。

この分離には速度以外の意味もある。出題中のAIが最初から正答を握っている範囲を減らせる。学習者へ見せる情報と、採点するときだけ必要な情報を別の経路にすることで、answer leakageの境界も分かりやすくなった。

124問から20問を固定するまで、約15ミリ秒だった

Easy問題124件をpresentation-only cacheへ置き、全124件の読み込み、20問の選択、SQLiteへの書き込み、read-back検証までを計測した。合計は14.913ミリ秒だった。内訳は、キャッシュ読み込み約1.9ms、選択約1.4ms、SQLite作成・20問書き込み約9.6ms、read-back検証約2.0ms。

この数値は本番サービス全体の応答速度ではない。ローカル環境で、Question Bank取得からセッション固定までのFast Pathだけを切り出したPoCの結果だ。それでも、LLMへ大きなQuestion Bankを毎回渡す必要がないことは十分に確認できた。

20問を最後まで出してから、初めて採点情報を取りに行った

次に、同じpresentation-only cacheとSQLiteを使って20問の連続出題を行った。出題中は採点情報を取得せず、20問ぶんの回答を保持する。20問が終わったところで回答20件をSQLiteへ保存し、read-backで一致を確認してから、GitHub上の正本Question Bankから採点情報を取得した。保存件数は20/20だった。

今回の20問選択はPoCとしてキャッシュ先頭から取ったもので、正式なSession Composerの選択ロジックではない。速さを確認するための実験と、どの問題を出すべきかを決める学習ロジックは分けて考えている。

AIサービスだからといって、全部をAIにやらせる必要はなかった

実験前は、AIがQuestion Bankを読んで、問題を選び、出題し、回答を覚え、最後に採点する流れを一つにまとめやすかった。動かしてみると、その中にはAIである必要がない処理がかなりある。IDの照合、revision確認、問題の固定、回答の保存、read-backは、決定的なコードの方が速くて検証しやすい。

AIに残したいのは、学習者の言葉を受け取り、詰まり方を考え、説明やヒントを調整する部分だ。高速化を進めた結果、AIの仕事を増やすのではなく、AIにしかやってほしくない仕事だけを残す設計へ近づいた。

この後

次は、このFast Pathを正式なCandidate Pool / Session Composerと接続し、問題選択の方針を置き換えずに高速化だけを担当させる。Question Bankのrevisionまたはsource blobが変わったときだけキャッシュを再構築し、正本と高速な実行状態を混ぜないまま、実際の学習セッションで速度と復旧性を見ていく。

「300問作る」は、300回生成すれば終わりではなかった

New-Type-D-Systemでは、G検定向けのEasy問題を実用最低ラインとして300問まで増やすことにした。生成AIに1問作らせるだけなら難しくない。数十問までなら、既存のQuestion Bankを見ながら足りないところを追加する方法でも何とかなる。

問題は量が増えた後だった。次に何を作ればいいかを決めるたびにQuestion Bank全体を読み直し、「この範囲は何問あるか」「まだ薄い概念はどこか」を探し直す。生成より探索に時間がかかり、再開するたびに同じ確認を繰り返すようになった。

最初に、数えている単位そのものを間違えた

Knowledge Graphには、概念同士のRelation Clusterと、問題生成の単位になるQuestion Familyがある。途中でこの数を混同し、140というCluster数をFamily数のように扱って説明していた。再確認すると、current graphのQuestion Familyは141で、そのうちBridgeが17、基礎問題の生産対象になるFoundationが124だった。

ここで、「毎回AIに数え直させる」こと自体が問題だと分かった。正しい数を一度確認しても、次のTurnでまた巨大なBankから復元するなら、同じ誤認と探索コストが戻ってくる。

問題ではなく、Question Familyを生産単位にした

そこでIssueにProduction Ledgerを作り、Foundation 124 Familyを固定の生産単位にした。各Familyへ基礎問題を2問ずつ用意すれば248問。残り52問は、coverageや出題rotationを補うreserveとして後から配る。合計300問という目標を、124個の進捗状態へ変換した。

Ledger上では、各Familyが0/2、1/2、2/2のどこにいるかを追う。次に作る対象はBank全体の再検索ではなく、この状態から決まる。作った後は問題本文を眺めて「たぶん増えた」と判断せず、validationとpromotionの完了までを進捗へ含める。

先に全範囲へ1問ずつ配るSweep方式にした

124 Familyを順番に2問ずつ完成させると、序盤の範囲だけ厚くなり、後半は0問のまま長く残る。そこでSweep 1では全124 Familyへまず1問ずつ配り、Sweep 2で2問目を配ることにした。reserve 52問はその後に回す。

この方式なら、途中で開発が止まっても最低限のcoverageが広く残る。進捗も「いま何問あるか」だけでなく、「何Familyへ到達したか」で見られる。問題数とcoverageを別の指標として扱えるようになった。

Sweep 1は、124 / 124 Familyまで完走した

2026年10月26日、Sweep 1はFoundation 124 Familyすべてへ1問ずつ到達した。独立レビュー、validation、merge後のmain確認まで通し、canonical Question Bankは124 validated Easyになった。まだ各Familyは1/2なのでbaseline完成は0/124。次はSweep 2で2問目を埋めていく。

ここまで来ると、300という数字の見え方も変わる。300問は単なるファイル数ではなく、「124の基礎領域をどこまで均等に覆い、その上で52問をどう補強へ使うか」というProduction Planになった。

大量生成では、AIの記憶より台帳の方が重要になる

生成AIは、目の前の1問を作る能力は高い。しかし大量生産では、「前に何を作ったか」「何が未完了か」「どこまで検証されたか」を毎回会話から復元させると急に弱くなる。人間の制作現場で進行表や在庫表が必要なのと同じだった。

AIにたくさん作らせるほど、プロンプトよりProduction Ledgerの比重が上がる。生成を速くする前に、生産単位を固定し、完了条件を決め、未完了を外に残す。それだけでAIは「毎回全部を思い出す作業」から解放され、生成そのものへ戻れる。

この後

次はSweep 2で124 Familyを2/2へ進める。その後、52問のreserveをどのFamilyへ配るかは、単純な均等割りではなく、coverage、出題rotation、実際の学習結果を見ながら決める。300問を完成させることより、増え続けても全件再読なしで管理できる生産系になるかを見ていく。