EDUCARE — CONFIDENTIAL / 社外秘

新WEBテキスト生成パイプライン
要件定義書 v1.0

2026-07-28 ／ 起草: Claude Fable 5 ／ 決裁者: 敏
参考許諾: キヨ氏 educarelms（LMS＋テキスト自動生成パイプライン）／ 対象: 会員マイページ /webtext

結論（TLDR）

キヨ氏の educarelms から移植すべきは「3段階講義の自動生成パイプライン」の設計思想であり、サイトやコードそのものではない。我々の強み（認証付き配信基盤・検品済み問題バンク9,916問・fail-closed決定論ビルド・出題頻度データ）の上流に生成段を接ぎ、現状ゼロ本の講義本文83単元×3レベルと未完の例題51単元を、機械検品＋独立検算ゲート付きで量産する。第1弾は数的推理38単元×基礎/標準のパイロット。

1. 目的（定量）

工数減

500〜1,000h→検収のみ

講義249本＋例題51単元の人手執筆を生成に置換。人間はサンプリング検収 20〜30h に圧縮 inference

売上増

R1商品在庫の完成

現状は講義本文0本・例題28/83単元で商品として不完全 fact。83単元完全版が課金商品化の前提在庫

リスク減

来歴の全件記録

モデル・プロンプト版・日時・入力ハッシュを記録＝「自前構築の証跡」。営業秘密係争時の防御資産

利用者=Educare会員（公務員・SPI受験者）／対象業務=WEBテキストの制作→検品→配信。API推論費は概算数千円〜数万円規模 inference（Phase①で実測して確定）。

2. 現状（2026-07-28 実測）

我々の現行 /webtext fact

  • 正本 unit_content.json は12キーの箇条書き（what/approach/trap…）。通読できる講義本文が存在しない
  • 例題 leadExample は 28/83単元（全てバンク由来・書き下ろし0件）で停滞
  • 強み: 認証付きworker配信・決定論ビルド（webtext:sync）＋fail-closed機械検査（webtext:check）は堅牢
  • ⚠️ 実装はフィーチャーブランチのみ（develop未マージ）・ビルドが別レポの正本を絶対パス参照＝別環境で再現不能

キヨ educarelms（参考レポ・調査済み）fact

  • 基礎/標準/発展の3段階講義を難易度別プロンプトで書き分け（基礎=アルファベット変数禁止 等）
  • 著者役→編集者役の二段階生成＋解説プロンプトの不備自己申告（RETRY_REQUIRED）→自動リトライ
  • 冪等・中断再開可能な生成ループ／スキーマによるビルド時型契約
  • 採用しない点: 進捗はlocalStorageのみ・認証/DB/検算/paywall/デプロイ設定なし・Gemini CLI依存

3. ECRS（要望→要件の絞り込み）

観点判断
E 無くす①例題51単元・講義249本の人手執筆を無くす ②新規LMSサイト構築を無くす（既存の認証付きリーダーに載せる） ③人手の全数検品を無くす（機械＋独立AI＋サンプリングへ）
C 結合する①例題は既存問題バンク（検品済み9,916問）からの引当が第一・生成は不足分のみ ②単元マスターは既存タクソノミー正本と統合（新設しない） ③出題頻度データと結合し生成・検収の優先順を頻度順に
R 並べ替える生成→監修→機械検品→独立検証→正本昇格（人間ゲート）→決定論ビルド→配信 の一方向。生成物を直接配信しない
S 単純化する①CLI subprocessでなくAPI直＋構造化出力 ②第1弾は基礎/標準の2レベルに絞る（発展は第2弾）
問題の本質

「テキストを書く人手が無い」ではなく、「講義本文という商品在庫が存在せず、人手執筆では永遠に埋まらない」こと。ゆえに要件の中心は執筆支援ツールではなく、検品ゲート付きの量産パイプライン。

パイプライン全体像

単元マスター＋12キー素材＋頻度weight→ 生成（著者役）→ 監修（編集者役）→ 機械検品＋数値検算＋独立検証→ 正本昇格（人間サンプリング検収）→ webtext:sync（決定論）→ webtext:check 緑 → 配信

4. スコープ

含める: SPI 83単元の講義本文（基礎/標準、発展は第2弾）＋例題完備／生成パイプライン一式／schemaVersion 3 と既存 sync/check への統合／リーダーのレベルタブUI・能動想起演習UI。

含めない（将来の拡張想定・今回スコープ外）

項目理由
有料/無料の段階アクセス（P3・Stripe）有料商材PJ側の別工事。本PJはアクセス制御を触らない
他family（SCOA/公務員上級 等）への展開パイプラインはfamily非依存に作るが、コンテンツ生成はSPIのみ
動画連携・サーバー側進捗管理の新設別レーン（既存/trainingの進捗系と将来統合）
educare-admin Content Store（D1/R2一本化）移行既存構想の別レーン。本PJは静的同梱を維持
既存12キー正本の全面書き直し生成の入力素材として活かす
キヨレポのコード直接流用設計思想のみ移植と決定（CLI依存で全面書き直しになる／自前構築の証跡を汚さない）

5. 機能一覧（23機能・◎必須19）

必須度: ◎必須／○あるべき 　フェーズ: ①基盤＋38単元パイロット ②全83単元量産 ③UI改修＋正式リリース

A. 生成パイプライン基盤（TOSHI_HQ 側に新設）

ID機能仕様必須Ph
F-01単元マスター読込既存タクソノミー正本＋unit_content.json から生成対象を決定。頻度weightで優先順ソート新規マスターは作らない（C）◎①
F-02講義生成（基礎）12キー素材を文脈注入し通読型講義を生成。禁則: アルファベット変数禁止・具体的数字のみ・デスマス調◎①
F-03講義生成（標準）基礎の泥臭い解法との対比で公式・時短テクを導入する構成を強制。例題数値の事前検算指示◎①
F-04講義生成（発展）一般化・別解・上位試験レベル。頻度上位単元から○②
F-05監修パス著者と独立した編集者ペルソナで全文リライト（禁則違反・AI前置き・冗長の除去）◎①
F-06冪等・再開生成済みはスキップ。中断→再実行で欠損分のみ生成（manifest管理）◎①
F-07来歴記録全生成物に model／prompt版／入力ハッシュ／日時を JSONL 追記・git管理◎①

B. 例題・演習

ID機能仕様必須Ph
F-08バンク例題引当検品済み問題バンクから引当可能な単元を28→上限まで拡大（hash検証は現行踏襲）◎②
F-09書き下ろし例題生成バンクに適問が無い単元（現状51）のみ生成。選択肢・正答つき◎②
F-10解説生成＋自己申告ゲート解説側が問題不備を検出したら RETRY_REQUIRED→自動再生成（上限3回）。超過分は要人間判断リストへ◎②

C. 検品・品質保証（発見は機械・判定が人間）

ID機能仕様必須Ph
F-11機械検品スキーマ・禁則語・文字数レンジ・PII/ローカルパス漏洩・数式記法を生成段で検査◎①
F-12数値検算計算を含む例題・講義内例はコード実行による独立検算AI自己申告を数字にしない（過去問DB PJの確定教訓）◎②
F-13独立第2系統レビュー生成と別系統のモデルによる誤り検出パス独立2系統突合で誤り2割超を検出した過去問DBの型を踏襲○②
F-14検収シート出力人間サンプリング検収用一覧（頻度上位優先・NG理由欄）。一括 reviewed:true はしない○②

D. ビルド・配信統合（line-harness 側）

ID機能仕様必須Ph
F-15schemaVersion 3content に lecture_basic/standard/advanced を追加。未生成単元は現行v2表示に自動フォールバック（リリースをブロックしない）◎①
F-16sync/check 統合webtext:sync が新フィールドを決定論で取り込み、webtext:check の fail-closed 検査に講義の件数・スキーマ検査を追加◎①
F-17クロスレポ依存の是正正本→line-harness の受け渡しを絶対パス参照から「出力物のcommit＋ハッシュ照合」へ◎①
F-18最小表示パイロット38単元の講義本文を既存リーダーにプレーン表示（リッチUIは③）。stagingで実機確認可能に◎①

E. リーダーUI改修（apps/members）

ID機能仕様必須Ph
F-19レベルタブ基礎/標準/発展/演習のタブ構成＋URLハッシュでディープリンク◎③
F-20レベルフィルタ学習者がレベル表示を切替。設定は会員プロフィール（既存D1）に保存○③
F-21能動想起演習UI選択肢クリック→正誤表示→その後にのみ解説開示（学習科学的に優位なキヨ版UXを移植）◎③
F-22TOC/スクロールスパイ長文講義の見出しナビ○③
F-23/training 相互リンク維持既存 topic mapping（71組）を講義本文からも張る○③
フェーズ依存チェック済み（クラウドキュー要件の轍）

各フェーズの受入条件はそのフェーズ内の機能のみで充足する。①は F-15/16/17/18 を含むため「作ったが見えない」状態にならず、③のUIは②の全量が無くても F-15 のフォールバックで成立する。画面は既存2枚の改修のみ（新規画面なし）。ワイヤーフレームは③着手時の基本設計で作成し、要件定義では作り込まない。

6. 受入条件（検収項目・先行確定）

#条件検証方法
AC-1数的推理38単元×基礎/標準=76本が生成され、機械検品（F-11）全緑検品レポート添付
AC-2監修パスが全76本に適用され、禁則違反の機械検出0件禁則grep実測
AC-3生成中断→再実行で欠損分のみ生成される（冪等性）意図的中断テスト
AC-4全生成物に来歴（model/prompt版/日時/入力ハッシュ）が記録されているJSONL突合
AC-5webtext:sync 2回連続実行で byte 一致（決定論維持）・webtext:check 緑CI実測
AC-6staging /webtext で38単元の講義が表示され、未生成単元は現行表示で壊れない実機確認（PC/SP描画）
AC-7(Ph②) 例題83/83完備。数値検算一致率100%・独立レビューの致命指摘0件で出荷検算ログ・レビュー報告
AC-8(Ph②) 頻度上位からのサンプリング人間検収（最低10単元）で商品品質合格検収シート
AC-9(Ph③) レベルタブ・能動想起UIが実機（PC/SP）で動作。/training 遷移が退行しない実機E2E
AC-10本番デプロイは prod_deploy ゲート経由（素の wrangler deploy 禁止）デプロイログ

7. 進め方（2段階）

①要件確定: 本書の敏決裁（下の論点込み）→ 必要なら sol 敵対監査（クラウドキュー方式）。②実装: 1フェーズ=1工事で委任（F-ID単位で work order 化）。Phase①完了時点で品質とAPIコストの実測を報告してから②のGO判断。

8. 敏に決めてほしい論点（5点）

#論点推奨
Q-1第1弾の範囲: 数的推理38単元に絞るか、83単元同時か38単元パイロット（品質と実コストを実測してから量産）
Q-2「発展」レベルの位置づけ（SPI向けには過剰の可能性・公務員数的処理には有用）基礎/標準を必須、発展は②で頻度上位単元のみ
Q-3無料サンプル4単元（場合の数/確率/集合/構成比）の据置き or 拡大据置き（paywall PJ側で再設計）
Q-4webtext フィーチャーブランチの develop マージ商流（現状stagingは実験ブランチの手動デプロイ）Phase①着工前にマージして正式経路に載せる
Q-5生成・検証モデルと予算枠生成=Sonnet 5／監修=Opus・Fable／独立検証=Gemini（別系統）。①の実測後に②予算承認

正本: 02_SAP_Marketing/owned_business/educaredev/docs/WEBTEXT_GEN_PIPELINE_REQUIREMENTS_20260728.md ／ 偵察一次情報: private-org/educarelms（private・調査2026-07-28）・line-harness worktree wt-training-proto 実測 ／ 本ページは社外秘・noindex