AI生成は入れたけれど全自動公開はやめた: bulk-material-generator運用設計

はじめに

記録時点: 2026-02

教材作成の初速を上げるため、AI補助で一括生成できる仕組みを導入しました。 導入自体はうまく進みましたが、公開まで自動化すると運用事故が増える兆候がすぐ出ました。

この記事で扱う範囲

• 自動化範囲をどこで止めるかの判断
• 失敗時に確定データへ混ざらない設計
• 実務で回るレビュー導線の作り方

導入直後に見えたリスク

問題は「生成できるか」ではなく「生成結果をどう扱うか」でした。

• 生成成功を公開可否と同義で扱うと、品質確認の入口が消える
• 一部崩れた出力が混ざると、後修正のコストが急増する
• 生成、レビュー、公開が同一フローだと責務が曖昧になる

速度は上がっても、運用の回復力が下がる状態でした。

境界の決め方

この回では「自動化できるか」ではなく「壊れた時に戻せるか」で境界を決めました。

自動化した範囲

• 下書き生成
• 構成案の組み立て
• 再生成

人の判断を残した範囲

• 公開可否の最終判定
• 見た目確認が必要な調整
• 失敗時の例外判断

実装で効いたガード

1. 生成を即確定しない

確認段階を必須にし、明示操作がなければ確定状態へ進まないようにしました。

type DraftState = "generated" | "reviewing" | "approved" | "rejected";
 
function canPublish(state: DraftState, hasHumanApproval: boolean): boolean {
  return state === "approved" && hasHumanApproval;
}

2. 失敗時の退避経路を先に作る

応答崩れや整合不良が出た場合は、確定へ進めず下書きへ戻す設計にしています。

function resolveFailurePath(result: GenerationResult): "retry" | "back-to-draft" {
  if (result.isPartial || result.hasSchemaError) return "back-to-draft";
  return "retry";
}

3. レイアウト事故が出やすい項目は固定運用にする

自動最適化で可変にせず、確認可能な範囲で固定して扱いました。

見送った案

1. 生成完了後に自動公開まで一気に通す

初速は上がりますが、事故時の被害が大きくなるため採用していません。

2. 失敗ケースを後処理バッチで吸収する

短期は楽でも、運用負荷を先送りするだけになるため見送りました。

3. 低信頼結果でも自動で公開候補へ積む

審査負荷がむしろ増え、公開判断の質が下がるため不採用です。

運用で固定したチェック

この回の判断が次に効いたこと

「境界で止める」方針は、次の記事でもそのまま使っています。

• API移行で画面を止めないためにやったこと: 認証エラーの揺れを潰す
• タグ機能導入後に分類が揺れたので運用ルールを作り直した話

まとめ

bulk-material-generator では、生成の自動化は強く進めつつ、公開判断は人の責務として残しました。 「どこまで自動化するか」より「どこで止めるか」を先に決めたことが、速度と品質の両立に効いています。